#0 들어가기 앞서..EC2와 비교한 Lambda
EC2는 알다시피 클라우드 가상 서버라서 프로비저닝이 필요한데 프로비저닝을 할 메모리와 CPU크기가 제한된다.
지속적으로 실행되어야하니 최적화를 하려면 효율적으로 시작시키거나 중단해야 하는데 그렇게 하지 않으면 인스턴스에 어떤 일이 생기든 관계가 없이 EC2는 지속적으로 실행되어버린다.
오토 스케일링 그룹으로 스케일링할 수는 있는데 문제의 요지는 자동으로 서버를 추가하고 제거하는 그런 귀찮은 작업을 쭉 해야한다는 것이다.
...
여기서 AWS Lambda라는 것이 있는데 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행된다.
(제한 시간이 있어서 실행 시간이 짧다고는 하는데 최대 15분 남짓이라 그렇게 짧진 않다)
그리고 Lambda를 사용하지 않을 시에 람다 함수가 실행되지 않고 비용 역시도 함수가 실행되는 동안 청구되고 호출 받으면 온디멘드로 실행이 된다!
그리고 마지막으로 오토 스케일링이다.
=> 더 많은 Lambda함수가 동시에 필요로 하는 경우에 자동으로 프로비저닝해서 Lambda함수를 늘려준다😀
#1 Lambda 장점을 더 알아보자
위에서 설명했던 장점보다 더 많은 장점이 있는데 이 챕터에서 더 살펴보려고 한다.
✅ 가격 책정이 쉽다 :
Lambda가 수신하는 요청의 횟수에 따라서 과금이 되는데 즉, Lambda가 실행된 만큼만 청구가 돼서 책정하기 쉽다.
✅ 다양한 서비스와 통합이 가능하다.
🏋️♂️<서비스별 어떤 방식으로 통합될까?>🏋️♂️
- API Gateway : API Gateway는 REST API를 생성하고 Lambda함수 호출
- Kinesis : Lambda를 이용해서 바로 데이터를 변환
- DynamoDB : 트리거를 생성할 때 사용되는데 데이터베이스에 어떤 일이 생기면 Lambda함수가 작동
- S3 : 파일이 생성될 때 사용
- CloudFront : CloudFront용 Lambda는 Lambda@Edge인데 찾아보면 좋다.
- CloudWatch와 EventBridge : AWS 인프라에 어떤 일이 생기고 그 상황에 대응하고자 할 때
(예 : 파이프라인이 끊기거나 상태가 바뀔 경우 등) 상황에 따라 자동화를 실행하려고 Lambda함수를 씀
- SNS : 알림과 SNS 토픽에 대처할 수 있다.
- SQS : SQS 대기열 메세지를 처리할 수 있다.
- Cognito : 예를 들어 사용자가 데이터베이스에 로그인할 때마다 응답하게 할 수 있다.
예시 1) 썸네일 생성
S3 버킷이 있는데 여기서 바로 썸네일을 생성하고 싶을 때 S3에 새 이미지가 업로드되는 이벤트가 생기면 S3 이벤트 알림을 통해 Lambda함수가 작동하게 된다. 그리고 Lambda함수에는 썸네일을 생성하는 코드가 있는 상태이고(직접 생성해야 함) 해당 썸네일은 다른 버킷이나 같은 버킷으로 푸시/업로드 된다 -> 원래 이미지보다 더 작은 크기로도!
또한 Lambda함수는 몇몇 데이터를 DynamoDB에 삽입할 수 있는데 이미지 이름, 크기, 생성 날짜 등 삽입될 것이고 Lambda 덕분에 기능이 자동화되어 이미지가 업로드될 때마다 생성되는 이벤트에 대한 반응형 아키텍처를 설계할 수 있다.
예시 2) CRON(크론) 작업
CRON이란 EC2 인스턴스에서 작업을 생성하는 방법(추가로 CRON은 가상 서버에 실행되어야 함)인데 CloudWatch이벤트 규칙이나 EventBridge규칙을 만들고 어떤 해당 시간의 트리거를 정해서 람다 함수와 통합하면 아무 일도 안할 때(인스턴스가 실행되지 않거나 CRON이 아무 일도 안 할 때)의 인스턴스가 낭비되는 것을 줄이고 테스크를 효율적으로 수행할 수 있게 해준다.
✅ 여러 가지 프로그래밍 언어를 사용할 수 있어서 자유로운 편이다.
✅ 함수 당 최대 10GB의 RAM을 프로비저닝할 수 있다 :
상황에 맞춰 함수의 RAM을 증가시키면 CPU나 네트워크 품질, 성능이 함께 향상될 것이다.
✅ Lambda Container Image(람다 컨테이너 이미지)를 지원한다 :
컨테이너 이미지 자체가 Lambda의 Runtime API를 구현해야 한다.
즉, 아무 컨테이너 이미지나 Lambda에서 실행되지는 않고 컨테이너 이미지를 만들 때 전제 조건이 필요하다.
(Lambda에 컨테이너를 실행해야 하는 경우엔 해당 컨데이너에 Lambda Runtime API를 구혆지 않으면 ECS나 Fargate에서 컨테이너를 실행해야 한다.)
#2 람다 간단하게 실행해보기
<람다 생성하기>
여기서 새로운 이벤트를 추가하려면 파란색 박스 'test'를 클릭한다.
이렇게 코드를 배포하고 작동시키는데 매끄럽게 실행될 뿐만 아니라 자동으로 스케일링되며 완전한 서버리스이다!
+) 추가로 통합기능이 CloudWatch인데 이것을 설정하면 유료이긴 하지만 람다함수의 모든 호출 기록, 최근 기록등을 볼 수도 있고 코드에 예외(오류)를 발생시키면 오류가 생겼다고 보고한다. 즉, 람다는 모든 유형의 오류를 보고하고 클라우드워치를 통해서 오류가 일어난 로그가 어딘지 확인할 수 있는 것이다.
'AWS' 카테고리의 다른 글
VPC에 대해 조금 더 자세히 알아보자 (1) - VPC를 알기 전, 간단히 CIDR에 대하여 (1) | 2024.04.12 |
---|---|
AWS Lambda에 대해 더 살펴보자 (2) - Lambda Snap Start, CloudFront 함수와 Lambda@Edge 차이점까지 (0) | 2024.04.10 |
각 서비스에 맞는 아키텍처는 무엇일까? - 서버리스로 블로그 웹앱의 아키텍처를 설계해보자 (0) | 2024.04.08 |
각 서비스에 맞는 아키텍처는 무엇일까? - WordPress 웹앱의 아키텍처를 개선하면서 설계해보자 (0) | 2024.04.01 |
각 서비스에 맞는 아키텍처는 무엇일까? - 옷 쇼핑몰 웹앱의 아키텍처를 개선하면서 설계해보자 (0) | 2024.03.31 |