[Udemy][day-47] Section21 : AWS 서버리스 : Lambda - 1
#AWS Certified Developer Associate
269. AWS Lambda - 섹션 소개
새로운 developer 시험에는 서버리스 문제가 많이 나온다고 함
270. 서버리스 소개
서버를 관리할 필요가 없음 - they just deploy code and functions
초기의 서버리스는 FaaS(Function as a Service) 를 의미했음
서버리스는 aws lambda 가 처음 임 - 지금은 서버를 프로비저닝 하지 않은 이상 DB, 메세징, 스토리지도 서버리스에 포함됨
서버리스란 것은 서버가 없는게 아니라 서버가 보이지 않거나 서버를 프로비전 하지 않은 것을 의미함
Serverless in AWS
s3 에서 정적 컨텐츠 접속
cignito 는 사용자 신원 정보가 보관된 곳
api 게이트웨이를 통해 사용자는 rest api 를 작동하고, api 게이트웨이는 람다 함수를 작동시킴
람다 함수는 dynamoDB 에서 데이터를 저장하고 또 검색함
271. AWS Lambda 개요
람다는 가상의 함수이다
- 관리할 서버 없이 그냥 코드를 프로비저닝 하고 함수를 실행함
시간 제한이 있어서 실행 시간이 짧음
- 최대 15분
on-demand 로 실행됨
- 람다를 사용하지 않으면 람다 함수가 실행되지 않고 비용 역시 함수가 실행될 때만 청구될 것이며 호출할 때 온디멘드로 실행됨
오토 스케일링
- 더 많은 람다 함수가 동시 처리될 경우, aws 가 자동적으로 더 많은 람다 함수를 프로비저닝 해줌
Benefits of AWS Lambda
Easy Pricing
- 람다가 수신하는 요청의 숫자에 따라 청구됨 (이는 호출 숫자 및 컴퓨팅 시간에 따름)
- 프리티어 에서도 람다를 넉넉하게 제공해줌 (람다 요청 1백만개, 컴퓨팅 시간 40만GB)
Intergrated with the whole AWS suite of services
Intergrated with many programming languages
CloudWatch 모니터링 통합도 쉬워짐
함수당 더 많은 리소스를 프로비저닝 하려면 함수당 최대 10GB의 램을 프로비저닝 할 수 있음
만약 람다함수의 RAM을 향상시키면 CPU 와 네트워크의 품질 및 성능도 함께 향상됨
AWS Lambda language support
Node.js (JavaScript)
Python
Java (Java 8 compatible)
C# (.NET Core).
Golang
C# / Powershell
Ruby
Costom Runtime API (커뮤니티 지원, ex. Rust)
Lambda Container Image
- 컨테이너 이미지 자체가 람다의 런타임 API 를 구현해야 하기에 람다에서 실행되는 다른 컨테이너 이미지와 다르다고 함
- ECS 와 Fargate 는 여전히 임의의 도커 이미지를 실행하는 것에 더 많이 사용됨
- 람다에 컨테이너를 실행해야 할 경우, 해당 컨테이너가 람다 런타임 API 를 구현하지 않으면 ECS 나 Fargate 에서 컨테이너를 실행해야 함
AWS Lambda Intergrations Main ones
람다 통합 중 주요 기능
API 게이트웨이는 REST API 를 생성하고 람다 함수를 호출함
Kinesis 는 람다를 이용해 바로 데이터를 변환함
DynamoDB는 트리거를 생성할 때 사용됨
S3 - 람다 함수가 언제든 작동할 수 있음
CloudFront 용 람다는 Lambda@edge 임 - 이후 배운다고 함
CloudWatch Events 혹은 EventBridge 에서는 AWS 의 인프라에 어떤 일이 발생하고 그 일에 대응하려고 할때 자동화를 실행하기 위해 람다 함수를 사용함
Cognito 는 사용자가 데이터베이스에 로그인 할 때 응답함
Example : Serverless CRON Job
CRON 이 동작하지 않는 시간은 낭비됨
CloudWatch 규칙 와 람다를 통합해 테스크를 수행하여 리소스 낭비를 막을 수 있음
AWS Lambda Pricing : example
https://aws.amazon.com/ko/lambda/pricing/
서버리스 컴퓨팅 – AWS Lambda 요금 – Amazon Web Services
aws.amazon.com
람다 요금 링크
호출 당 청구 (pay per calls)
- 첫 백만개 요청은 무료
- 이후 백만개의 요청에 대해 20 센트($0.20)가 과금됨
시간 당 청구 (pay per duration) (1ms 단위)
- 한달간 첫 40만 GB-seconds 동안의 컴퓨팅 시간은 무료
- GB-seconds 는 함수가 1GB RAM 을 가질 때 실행 시간이 400,000초 이다
- 함수의 RAM 이 8배 작은 128MB 크기라면 실행 시간은 8배가 길어짐
- 무료 기간 이후에는 600,000GB-seconds 당 $1 가 과금됨
걍 존나 쌈
272. AWS Lambda - 실습
람다 콘솔의 시작페이지로 가면 작동 방식 콘솔이 있는데 여기서 간단한 코드들로 람다를 출력해볼 수 있다
이벤트에 대한 lambda 응답으로 들어가면 여러 리소스에서 부터 람다 함수가 호출되는 방식을 확인할 수 있다
다음 함수 생성으로 가서
이번 실습에서는 블루 프린트 방식으로 함수를 생성 한다고 함
이후 구성으로 들어가서
이름을 demo-lambda 로 해주고
모두 기본값으로 놓고
생성
이후 생성된 람다 함수를 테스트하는 테스트 이벤트를 새로 생성해준다
테스트 클릭
이름은 DemoEvent 로 해주고 생성
다시 테스트를 눌러보면
이렇게 테스트 결과가 출력된다
샘플 코드 몇가지를 람다에 업로드했고 람다로 아주 빠르게 실행한 결과이다
개발자의 입장에서 자동으로 스케일링, 배포되는 편리한 서버리스 서비스
REPORT RequestID 에 Billed Duration 은 2ms 로 나오는데 과금된 실행 시간을 의미한다
이후 람다 콘솔에서 구성(configurations) 로 들어가서 편집으로 들어가보면
기본 환경을 설정할 수 있는데
기본적인 메모리량을 정할 수 있고
강의에서 없었지만 임시 스토리지를 구성할 수 있다
제한 시간(time-out) 시간을 설정할 수 있는데 최대 15분이라고 한다
모니터링 탭에서 클라우드 워치와 클라우드 워치 로그 지표들을 확인할 수 있다고 한다
코드를 배포하고 에러가 발생했을 경우 클라우드 워치 로그에서 자세한 오류 원인을 확인할 수 있다
추가로 코드 탭에서 런타임 설정을 편집해서 다른 버전의 런타임을 선택해서 사용할 수 있다고 하며
로그 쓰기 작업을 위해
람다가 열할을 생성해서 권한을 부여한다
여기서 권한을 추가로 설정해줄 수 있다고 한다
273. Lambda 동기식 호출 (Synchronous Invocations)
람다 함수의 첫 번째 호출
CLI, SDK, API Gateway, ALB 를 사용한다면 동기식 호출을 사용하는 것
- 결과는 바로 리턴됨
- 에러 핸들링은 클라이언트 사이드에서 해결해야 함 (재시도 , 지수 백오프 전략 등)
동기식 : 사용자가 결과를 기다리게 되는 직접 호출임을 의미함
274. Lambda 동기식 호출 실습
CLI 로 동기식 호출을 실습할 것이기 때문에 클라우드쉘로 접속
명령어로 이 도쿄 리전에서 사용할 수 있는 람다 함수의 목록을 확인
서울은 클라우드 쉘을 사용할 수 없어서 도쿄리전에서 진행
[cloudshell-user@ip-10-4-80-153 ~]$
[cloudshell-user@ip-10-4-80-153 ~]$
[cloudshell-user@ip-10-4-80-153 ~]$ aws lambda invoke --function-name demo-lambda --cli-binary-format raw-in-base64-out --payload '{"key1": "value1", "key2": "value2", "key3": "value3" }' response.json
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
[cloudshell-user@ip-10-4-80-153 ~]$ ls
response.json
[cloudshell-user@ip-10-4-80-153 ~]$ cat response.json
"value1"[cloudshell-user@ip-10-4-80-153 ~]$명령줄에서 함수 이름을 자기 함수 이름으로 바꿔준다음 호출해보면
response.json 에 결과가 리턴된다.
275. Lambda 및 Application Load Balancer
Lambda Intergration with ALB
람다 함수는 CLI 나 SDK 로 호출할 수 있음
인터넷에 호출시킬때? - HTTP 혹은 HTTPS 엔드 포인트에서 사람들이 사용할 수 있도록
- ALB 사용 (or an API Gateway)
람다 함수를 대상 그룹(target group) 에 등록해야 함
- 클라이언트들이 HTTP 혹은 HTTPS 형태로 ALB 를 호출하고 요청을 보낼 수 있음
ALB to Lambda : HTTP to JSON
alb 에서 람다로 갈 때 http 는 json 문서로 변환됨
request payload json 문서 상단에 elb 정보가 기재되어있음
key/value pair 로 이루어진 response header 를 포함함
Lambda to ALB conversions : JSON to HTTP
위와 유사하게 람다 함수도 JSON 문서로 된 뭔가를 보냄
- 그럼 ALB 가 이를 다시 HTTP 로 변환해줌
key/value pair 로 이루어진 response header 를 포함함
body 태그와 isBase64Encoded 인지 여부 플래그
ALB Multi-Header Values (다중 헤더 값)
alb 설정을 통해 다중 헤더 값을 갖도록 할 수 있음- 쿼리 스트링을 쉽게 표시하기 위해 같은 값을 지니는 다수의 헤더, 혹은 쿼리 스트링을 입력할 경우여러개의 해더와 쿼리 스트링 매개변수를 람다함수로 된 배열로 변환해 줄 수 있음
276. Lambda 및 Application Load Balancer 실습
람다 콘솔로 돌아가서 함수를 처음부터 새로 만든다고 한다이후 alb 로 람다를 테스트 한다고 함
함수 이름은 lambda-alb 로 해주고런타임은 python 3.8을 선택
이후 모두 기본값으로 해주고 함수 생성
생성 완료 됬으면 EC2 콘솔로 이동해서 로드밸런서 탭으로 이동ALB 를 생성
이후 기본 vpc 의 3개 가용영역을 모두 선택해주고 기본값으로 서브넷을 설정
보안그룹은 22, 80 인바운드가 모두 열려있는 보안그룹을 새로 만들어서 적용해줌
라우팅은 80번 기본값 그대로 적용
타겟 그룹을 새로 만들어준다
람다 함수 타입으로 설정해주고 이름은 tg-lambda
만들었던 람다함수를 선택해주고 버전은 최신으로 선택
이후 요약 확인 후 타겟 그룹 생성
alb 생성 화면으로 돌아와서 만들어준 타겟그룹을 선택
람다 콘솔로 돌아와서
python 코드를 살짝 바꿔주고 테스트를 시켜보면
print 부분을 추가했기 때문에 function logs 에 결과가 출력되는 것을 확인
이제 alb 가 프로비저닝을 마치고 alb 의 dns 주소로 접속하면 파일이 하나 다운로드 되고
람다 결과를 가져오게 된다.
파일이 다운로드되는 이유는 람다 함수가 alb 에 맞는 특정 코드를 돌려주도록 설정하지 않았기 때문
구글에 lambda application load balancer aws 를 검색하면
https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/services-alb.html
Application Load Balancer에서 AWS Lambda 사용 - AWS Lambda
Application Load Balancer에서 AWS Lambda 사용 Lambda 함수를 사용하여 Application Load Balancer의 요청을 처리할 수 있습니다. Elastic Load Balancing은 Application Load Balancer의 대상으로 Lambda 함수를 지원합니다. 로드
docs.aws.amazon.com
위 aws 문서를 찾을 수 있는데 여기서 example response format 을 찾아서 복사
이렇게 alb 에서 요청하는 응답 문서 형식으로 바꿔주고
다시 dns 로 접속하면
이제 람다 함수의 결과가 웹 브라우저에 바로 표시된다
람다 함수에 입력된 이벤트가 뭔지 확인해본다고 한다
모니터링 탭으로 가서 logs 에 제일 최근 로그의 로그스트림으로 접속
실행된 로그를 살펴보면
targetGroupArn 과 elb 를 확인할 수 있고 여러 헤더들이 정보를 포함하고 있는 것을 확인할 수 있다
header 이후엔 body 를 확인할 수 있고
httpMethod 도 확인할 수 있다 - GET
path 는 / 이다
이제 다중 해더 값을 실습한다고 한다
타겟그룹 콘솔로 가서
속성 탭에서 다중 해더 값이 off 되어있는데 on 으로 바꿔준다
이후 alb dns url 뒤에
이렇게 2개 헤더를 임의로 넣어서 엔터
그럼 또 파일이 하나 다운로드 된다
다시 cloudwatch 로 가서
name 안에 배열로 리턴됨을 확인할 수 있다
리소스 기반 정책에 의해 alb 에서 람다 함수를 호출할 수 있으며 람다의 구성 탭 아래에서 확인할 수 있다
디테일로 들어가보면 arn 에 target group 이 기재되어 호출 가능하게 된다
이 강의 이후 alb 는 삭제했다
277. AWS Lambda@Edge 개요
또 다른 람다 동기식 호출
CDN 을 통해 CloudFront 를 배포했다고 가정
각 엣지 로케이션과 함께 글로벌 람다 함수를 사용하고 싶을 때
혹은 요청이 애플리케이션에 도착하기 전에 필터링 하고 싶을 때
Lambda@Edge 는 CloudFront CDA 를 통해 특정 지역이 아니라 세계 각지에 람다 함수를 배포하기 위함
- 즉각 반응하는 애플리케이션을 위해 사용
- 서버 관리 필요 x , lambda 는 전역으로 배포됨
- CDN 에 있는 모든 것을 수정할 수 있음
- 사용한 것에 대해서만 비용 지불
CloudFront 요청과 응답을 바꾸기 위해 사용
엣지에는 4가지 람다 함수가 있음
유저는 cloudfront 엣지 로케이션에 말을 걸고 cloudfront 는 origin 으로 요청함
이때 람다@엣지 가 수정할 수 있는 것
viewer request - cloudfront 가 뷰어, 사용자로부터 요청을 받았을 경우 이 요청을 수정할 수 있음
origin request - 이 요청은 cloudfront 가 오리진으로 전달하기 전인 요청임
origin response - cloudfront 가 오리진으로부터 응답을 받았을 경우 이를 수정할 수 있음
viewer response - 뷰어 응답을 수정할 수 있음, cloudfront 가 뷰어에게 응답하기 이전의 요청을 말함
뷰어 요청과 뷰어 응답이라는 람다 함수를 사용할 경우 오리진에 요청을 보내지 않고도 뷰어에 대한 응답을 생성할 수 있다는 의미
람다@엣지를 사용한 글로벌 애플리케이션
use cases
웹사이트 보안 및 개인정보 보호
엣지에 대한 다양한 웹 애플리케이션
검색 엔진 최적화인 SEO (Search Engine Optimization)
오리진과 데이터센터 사이 지능적인 라우팅
엣지의 bot 을 완화할 수 있음
실시간으로 이미지를 변형할 수 있음
A/B 테스팅
오리진 도달 전에 사용자를 인증하고 권한을 부여할 수 있음
사용자 우선순위
사용자 추적, 분석
278. Lambda 비동기식(Asynchronous Invocations) 호출 및 DLQ
람다함수를 뒤에서 불러오는 서비스를 위한 것
S3, SNS, CloudWatch Event 등
예시
S3 버킷이 있고 새 파일에 대한 S3 이벤트 알람이 있을 때
이게 람다 서비스로 이동하고 비동기식이기 때문에 어떤 일이 일어나게 될 텐데
이벤트는 내부의 이벤트 대기열에 위치하게 됨
람다함수는 이 이벤트 대기열을 읽게 됨
그럼 람다 함수는 이 이벤트들을 처리하려고 시도함
만약 뭔가 문제가 생길 경우 람다함수는 자동으로 3번의 재시도를 함
- 첫 재시도는 문제 직후, 두번째는 1분 후 , 세번째 재시도는 2번째 재시도 발생 후 2분 후
람다함수에 멱등성이 없다면 큰 문제로 이어질 수 있음 - 람다함수는 멱등적이여야 함
- 멱등성이란 여러번의 시도로 나온 결과가 모두 같은 것
재시도가 발생하면 CloudWatch 로그에서 로그 엔트리가 복제됨 - 람다함수가 게속 재시도 하기 때문
DLQ(Dead-Letter Queue) 를 재시도가 끝난 뒤에 정의할 수 있음
- 만약 재시도가 실패했고 재시도로 인해서 성공이 절대 불가능한 경우 람다함수가 이벤트를 sqs 나 sns 로 보내서 나중에 처리가 되도록 하는 것
비동기식 호출을 사용하는 이유
- 비동기식 호출만 사용이 가능한 일부 서비스
- processing 속도를 높여야 하는 상황에서 결과를 기다릴 필요가 없다면 예를들어 1,000개의 파일이 동시에 처리되도록 해서 각각의 결과를 기다리지 않아도 문제가 없을 때 사용
비동기식 서비스 종류
Amazon S3
SNS
CloudWatch Events / EventBridge
CodeCommit (new branch, new tag, new push)
CodePipeline (파이프라인 중에 다른 람다 함수를 호출하고 람다함수는 codepipeline 을 콜백해야 함)
CloudWatch Logs (log processing)
SES (Simple Email Service)
CloudFormation
AWS Config
AWS IoT
AWS IoT Events
279. Lambda 비동기식 호출 실습
비동기식 호출을 사용하는 이유는 결과를 다시 반환하지 않아도 되게끔 하기 위함
이전에 만들었던 demo-lambda 함수를 사용하고 cloudshell 로 접속
코드를 수정해서 일부러 오류가 나게끔 설정
클라우드셸로 이동해서 비동기식으로 invoke 해주고 cloudwatch log 로 이동해서 확인해보면
[cloudshell-user@ip-10-4-87-89 ~]$ aws lambda invoke --function-name demo-lambda --cli-binary-format raw-in-base64-out --payload '{"key1": "value1", "key2": "value2", "key3": "value3" }' --invocation-type Event response.json
{
"StatusCode": 202
}
[cloudshell-user@ip-10-4-87-89 ~]$상태는 202로 나오지만
클라우드 워치 로그에서는 에러를 확인할 수 있다
즉 함수의 실패 성공과 상관없이 비동기식 호출의 상태값은 202가 나옴
그 대신 DLQ 를 설정할 수 있음
람다 함수 콘솔에서 구성으로 이동해서 비동기식 호출 메뉴에 들어가보면
위처럼 재시도 횟수나 처리되지 않은 이벤트 유지 시간을 설정할 수도 있다
DLQ 지정을 위해 sqs 를 선택하고 큐를 하나 선택해줬는데 오류가 발생했다
함수가 sqs 에서 sendmessage 를 호출하기에 충분한 권한이 없기 때문
역할에 권한을 추가해줘야 하기 때문에 구성 탭의 권한 메뉴로 들어가서 역할로 들어가준다
여기에 정책을 연결해 줄 예정
편하게 fullaccess 로 연결해주면 람다함수가 sqs 대기열에 작성할 권한이 생긴다
다시 클라우드셸에서 비동기식 호출을 하게되면 람다함수는 2번의 재시도를 실행하고 그래도 실패한다면 위에서 지정해준 dlq 로 메세지가 가게 된다
cloudshell 에서 asynchronous invoke 해주고 sqs queue 로 이동해보면 (메세지 재시도 시간 때문에 4분이 소요된다고 함)
클라우드워치 로그 스트림에서 requestid 가 1c 로 시작하는 요청이 2번 실패한 것을 확인
dlq 에서 메세지를 폴링해보면 메세지를 확인할 수 있고
속성에 가보면 someting went wrong 과 requestid 가 동일한 것을 확인할 수 있다
280. Lambda 및 CloudWatch Event / EventBridge
서버리스 CRON 이나 Rate 로 클라우드워치와 람다를 통합할 수 있음
EventBridge 규칙을 생성한 뒤 예를들어 1시간 마다 람다 함수가 작업을 수행하도록 트리거링 하는 것
혹은
CodePipeline EventBridge 규칙을 생성할 수도 있음 - CodePipeline 의 상태가 바뀔 때마다 이를 감지해 람다 함수가 작업을 수행하도록 호출
281. Lambda 및 CloudWatch Event / EventBridge 실습
실습을 위해 새로 함수를 만들어 준다
함수 이름은 lambda-eventbridge
런타임은 python 3.8 로 하고
역할을 새로 만들어주는 기본값을 선택해주고
생성
람다 함수가 생성되는동안 eventbridge 규칙을 만들어 준다
이 규칙은 매분 람다 함수를 트리거 할 예정이다
이름은 DemoRuleLambdaEveryMinute 로 해주고
규칙 유형을 '일정' 으로 하고 다음
위처럼 반복 일정을 선택해주고
일정 유형을 rate 기반으로 선택해 준다
강의와는 ui 가 많이 다르긴 한데 대충 넘어갔다
대상은 lambda 로 선택해주고
아래에서 아까 만든 람다함수를 선택해줬다
이후 모두 기본값으로 놓고 규칙 생성
이러면 이 규칙은 매 1분마다 람다 함수를 호출하게 될것이다
그런데 강의와 다른 건
강의에선 함수에 대한 입력값은 알아서 기본값으로 해주는것 같은데
업데이트가 되었는지 입력값을 이렇게 직접 쓰도록 JSON 편집기를 포함하고 있었다
강의에서 처럼 람다 함수 콘솔 메인에 트리거로 클라우드 워치가 표시되지도 않았고
강의에선 입력값으로 버전정보나 여러 정보가 나왔지만 역시 확인이 되지 않았다
그냥 넘어가자
282. Lambda 및 S3 이벤트 알림
s3 이벤트 알림 - 객체가 생성, 제거, 복구, 복제가 일어날 때 알림을 해주는 기능
접두어와 접미어로 필터링이 가능
use case :
- s3 에 업로드된 모든 이미지 파일의 썸네일을 생성하는 등
s3 이벤트 알림은 보통 이벤트를 몇 초 만에 전달하지만 종종 1분 이상이 걸릴 수 있음
이벤트 알림을 하나도 놓치지 않으려면 버킷의 버저닝을 활성화 시켜야 함
- 하나의 오브젝트에 동시에 두 개의 작성이 일어나느 경우, 하나의 알림밖에 받지 못 할 수도 있음
283. Lambda 및 S3 이벤트 알림 - 실습
람다 함수를 새로 만들어 줬다
이름은 lambda-s3
런타임은 파이썬 최신버전
함수 생성
그리고 s3 버킷도 새로 하나 만들어 줬다
이름은 demo-s3-event-yeonwoo
람다 함수와 같은 리전인지 확인해주고
버킷 생성
이후 속성에서 이벤트 알림 생성으로 들어가서
이름을 invokeLambda 로 해주고
유형을 모든 객체 생성으로 설정해줬다
이후 대상을 람다 함수로 지정해주고
위에서 만든 함수를 선택해줬다
저장
이전 실습에선 확인 못했던 트리거가 이번에는 확인되었다
s3 가 트리거로 추가된 모습
람다 함수의 코드는
import json
def lambda_handler(event, context):
print(event)
return {
'statusCode': 200,
'body': json.dumps('Hello from Lambda!')
}위처럼 바꿔줘서 어떤 이벤트가 들어오는지 확인한다고 한다
람다 함수의 구성의 권한 탭에 들어가보면
리소스 기반 정책 설명에 항목이 추가되어 있는데
위처럼 s3 에서 호출하고
버킷 arn 도 확인할 수 있다
이제 s3 에 객체를 하나 업로드 하면
람다 함수 모니터링 탭에 로그가 발생하고
클라우드워치 로그의 로그 스트림으로 들어가보면
위 처럼 로그를 확인할 수 있다
리전 및 ObjectCreated:Put 이벤트 , 누가 만들었는지 등이 보이고
버킷 이름과 버킷 arn 도 확인할 수 있다
이런 event 를 s3 가 람다로 보내기 때문에 이를 활용할 수 있다고 한다
284. Lambda 이벤트 소스 매핑
동기식, 비동기식 호출 이외 람다가 이벤트를 처리하는 방법
kinesis data streams
SQS & SQS FIFO queue
DynamoDB Streams
레코드가 소스에서 풀링되어야 한다는 것
- 람다가 서비스에 레코드를 요청해야 그 레코드가 반환됨
- 람다가 이 서비스들로부터 폴링을 해야한다는 의미
- 이런경우 람다 함수는 동기적으로 호출됨
만약 kinesis 가 있고 람다가 kinesis 와 통합하려 할때 이벤트 소스 매핑이 내부적으로 생성됨
그럼 이 매핑이 kinesis 를 폴링하게 되고 kinesis 에서 반환된 결과를 받아옴
이벤트 소스 매핑에 람다가 처리할 데이터가 생기면 이벤트 배치를 통해 람다 함수를 동기적으로 호출하게 됨
소스 매퍼의 두가지 범주 Stream and Queue
- streams & lambda
kinesis 데이터 스트림과 dynamoDB 스트림에 적용됨
스트림은 이벤트 소스 매핑이 일어나 각 샤드에 대한 반복자를 생성함
샤드 레벨에서 아이템을 순차적으로 처리함
새로운 아이템만 읽기를 하거나 샤드 시작 위치 혹은 특정한 타임스탬프 부터 읽도록 구성이 가능
아이템은 스트림으로부터 제거되지 않으며 kinesis 와 dynamoDB 의 다른 소비자들이 데이터를 읽을 수 있음
use case
- 낮은 트래픽 : 배치 윈도우를 사용해 처리 전에 레코드를 축적함
- 높은 트래픽 : 람다가 샤드 레벨에서 동시에 여러 배치를 처리하도록 설정
- 동일한 샤드에서 다수의 람다 함수가 배치를 처리할 수 있도록 하는 병렬적 구성이 가능함
- 샤드당 최대 10개의 배치 프로세서를 가질 수 있음
- 파티션 키 레벨에서 각 배치가 순차적으로 처리되게 됨
error handling
기본적으로 함수가 오류를 반환하면 함수가 성공하거나 배치내의 아이템이 만료될 때까지 모든 배치가 다시 처리됨
- 배치에 오류가 생기면 처리가 중단될 수 있음
오류가 해결될 때까지는 오류의 영향을 받는 배치의 처리가 중단됨
에러 핸들링 구성 :
- 이벤트 소스 매핑이 오래된 이벤트를 폐기하도록 구성 가능
- 재시도 횟수 제한
- 오류 시 배치 분할 (람다 시간 초과 문제가 생기는 경우 사용)
오래된 이벤트를 폐기하는 경우에도 그 이벤트 전체가 목적지로 전달됨
- queue & lambda
대기열은 SQS 및 SQS FIFO 에 사용됨
SQS 대기열은 람다의 이벤트 소스 매핑으로 폴링됨
배치가 반환될 때마다 이벤트 배치를 통해 람다 함수가 동기적으로 호출됨
SQS 의 경우 이벤트 소스 매핑이 긴 폴링을 이용해 SQS 를 폴링함
배치 크기는 1에서 10 메세지까지 지정이 가능함
대기열 표시 시간초과를 람다 함수 시간초과의 여섯 배로 설정하는게 권장사항임
DLQ 를 사용하는 경우
- DLQ 를 람다가 아닌 SQS 대기열에 설정해야 함
- 람다용 DLQ 는 비동기식 호출에만 작동하기 때문
- 위 경우가 실패하는 경우 람다 목적지 기능을 쓸 수도 있긴하다
FIFO 대기열, 즉 선입선출을 사용하는 경우에는 람다가 순차적 처리를 지원함
대기열을 처리하기 위해서 스케일링 될 람다 함수의 수는 활성 메세지 그룹의 숫자와 동일함 (groupID setting)
표준 대기열을 사용하면 아이템이 순서대로 처리되지 않을 것
표준 대기열에서 람다는 대기열의 모든 메세지를 읽을 수 있도록 최대한 빠르게 스케일링 됨
대기열에 오류가 발생하면 배치는 개별 아이템으로서 대기열로 반환될 것이고 원래 배치와 다른 그룹에서 처리될 수 있음
가끔 이벤트 소스 매핑이 함수 오류가 일어나지 않았음에도 불구하고 대기열로부터 같은 아이템을 두번 수신할 수도 있는데 그런 경우 람다함수에서 아이템이 처리되도록 해야 함
람다에서 아이템이 처리되면 람다는 대기열에서 아이템을 삭제함
소스 대기열을 구성하여 처리되지 않은 아이템들을 DLQ 로 보낼 수 있음
Lambda Event Mapper Scaling
kinesis data streams & DynamoDB streams :
- 각 스트림 샤드 당 람다 호출은 한번
- 병렬 처리를 사용한다면 샤드 당 동시에 10개 배치까지 처리할 수 있음
SQS Standard :
- 스케일링 업을 위해 추가하는 인스턴스가 분당 60개이므로 매우 빠른 처리 속도
- 초당 동시에 처리되는 배치량은 최대 1000개이다
SQS FIFO :
- 그룹 ID 가 같은 메세지는 무조건 순서대로 처리됨
- 람다 함수는 활성 메세지 그룹의 수만큼 스케일 업
285. Lambda 이벤트 소스 매핑 실습(SQS)
역시 새로 람다 함수를 만들어 줬다
이름은 lambda-sqs 이고 런타임은 python 최신
이후 생성
sqs queue도 새로 만들어 줬다
이름은 lambda-demo-sqs 이고 standard 유형으로 해줬다
이후 모두 기본값으로 놓고 생성
이제 람다 함수가 SQS 대기열에서 메세지를 회수할 수 있도록 한다고 함
람다 콘솔에서 add triger 를 눌러서 트리거를 추가해주자
서비스는 sqs 를 찾아 선택해주고
대기열도 아까 만들어줬던 대기열로 선택해줬다
배치 크기는 단일 배치에서 몇개의 메세지를 수신하도록 할 지 정해준다고 한다
배치 기간(batch window) 는 함수를 호출하기 전 레코드를 수집할 시간을 초단위로 지정하는 것이라고 한다
근데
- 생성하는 동안 오류가 발생했습니다 trigger. The provided execution role does not have permissions to call ReceiveMessage on SQS
이렇게 에러가 나온다
람다 함수 콘솔에서 구성의 권한으로 이동해서 역할에 정책을 연결해줄거다
위처럼 정책 연결을 해주고 트리거를 생성해보면 정상적으로 생성된다
코드는 이벤트를 프린트 하도록 print(event) 를 추가해주고 deploy
이후 sqs 로 가서 메세지를 보내본다고 한다
대충 본문에 메세지 속성도 아무거나 주고 전송
이후 람다 함수의 모니터링 탭으로 들어가서 클라우트 워치로 이동 로그스트림이 확인되고 들어가보면
로그가 발생해있다
로그를 보면 body 에 메세지로 써놨던 본문이 확인되고
messageAttributes 에 인자로 줬던 name 인 foo 와 value 인 bar 가 stringvalue 로 들어가있는것을 확인할 수 있다
메세지 전송 시간, 이벤트 소스(sqs) 도 확인할 수 있다
sqs 의 메세지 정송 및 수신 메뉴로 들어가보면 사용 가능한 메세지가 0개로 나오는데
이는 람다 함수가 메세지를 처리하고 삭제했기 때문에 폴링할 메세지가 없다는 뜻이다
이후 트리거를 비활성화 시켜놔야 한다고 한다
지속적으로 비용이 발생하거나 sqs 처리량에 영향을 미칠 수 있다고 함
강의에서는 비활성화 시키라고만 했지만
비활성화 버튼을 찾을 수 없어서 그냥 삭제해줬다
그리고 kinesis 트리거도 살펴봤다
소비자 항목은 만약 소비가 애플리케이션을 만들 수 있는 향상된 팬 아웃 소비자가 있는 경우 소비자 향상 모드를 활성화 할 수 있다고 한다
batch size 는 한번에 읽을 레코드의 양이고
batch window 는 더 큰 배치를 생성할 때 람다 함수 호출 전 대기 시간이 필요한 경우에 사용된다
시작 위치는 최신 데이터를 읽을지 , 가장 오래된 데이터를 읽을지, 아니면 람다 함수의 특정 타임스탬프에서 읽을지 결정함
너무 길어서 2개로 나눠서 포스팅