[AWS] Serverless Service - Lambda 편 (3)

참고: https://www.youtube.com/watch?v=xmacMfbrG28 

---

(Asynchronous)

Poller: 큐에서 이벤트 가져와서 데이터 처리

• event
  • SQS에서 얻은 페이로드를 전달하여 Lambda Function을 동기 호출
  • 장애 발생 시 재시도 관리
  • 정기적으로 하트비트 보내기
  • Lambda Function 실행 결과 데이터를 Destination configuration에 지정된 AWS 서비스로 전송
• stream
  • 샤드를 구독하고 대상 Lambda Function의 메타데이터, 배치 크기 변경을 모니터링
  • 스트리밍 소스에서 데이터를 수신하고 배치 규칙(배치 크기, 배치 창 설정)에 따라 Lambda Function을 시작
  • 스로틀링이 발생하면 재시도
  • 정기적으로 하트비트 보내기
  • 스트리밍 소스가 비활성화되거나 삭제될 때 Poller 할당 삭제

State Manager / Stream Tracker: Scaling 관리(Poller 및 event/streaming source)

Leasing Service: 이벤트 소스 또는 스트리밍 소스에서 작동하도록 Poller 할당(Poller unhealty 표시되면 새로 할당)

 

Event Processing - Handling Asynchronous and Event Based Invokes

• 사용자가 ALB에 Lambda 비동기 실행 (InvocationType = Event 지정)을 요청
• ALB가 Front End Invoke에 요청을 전달
• Front End Invoke가 SQS에 메시지 보내기(SendMessage)
• 대상 대기열을 폴링하는 Poller가 SQS에서 메시지를 수신 (ReceiveMessage)
• Poller가 Front End Invoke에 Lambda의 동기화 호출을 요청
• 이 후의 흐름은 동기 호출과 같다

 

Event Destinations - Providing Callbacks After Processing

• 사용자가 ALB에 요청을 발행 ~ Poller가 동기 호출을 할 때까지 이전의 비동기 호출 시퀀스와 유사
• 동기 호출의 결과 (성공 / 실패)에 따라 Event Destinations에 지정된 리소스에 대해 Poller가 메시지를 전달
• Poller는 SQS에서 메시지를 삭제 (DeleteMessage)

 

Scaling Up and Down - Incoming Event Volume

State Manager - Leasing Service를 활용

State Manager는 대기열과 관련 Poller를 확장하여 수신된 이벤트를 Lambda Functions에 설정된 concurrency 까지 처리할 책임이 있음

• State Manager가 SQS의 메시지를 확인
• State Manager가 SQS 변경을 감지하고 Lambda Function의 동시 실행 수가 큰 경우 Leasing Service에 Poller 할당을 요청하여 새로운 큐 생성
• Lambda Function의 동시 실행 수가 작 으면 기존 큐를 그대로 사용
• Leasing Service는 DynamoDB에 Poller 할당 정보 작성
• State Manager는 지정된 리소스에 여러 개의 Poller를 할당하여 중복성을 보장
• Poller는 DynamoDB에서 할당 정보를 읽고 대기열 폴링을 시작

 

Handling Errors

Leasing Service: 정기적으로 Poller의 상태확인을 수행, heartbeat 안보낸 poller 감지 후 새 poller 할당

• 이벤트 소스를 처리하도록 할당된 Poller가 중지됨
• Leasing Service는 한 점 기간 내에 Poller에서 하트비트가 전송되는지 확인
• 하트비트가 전송되지 않은 경우 Leasing Service는 새로운 Poller를 할당
• 새 Poller가 할당 정보를 읽고 이벤트 소스 처리를 시작

 

Retry Policies

이벤트 수명: 0초 ~ 6시간

재시도 횟수 0 ~ 2 번

ex) retry 1번, DLQ 설정 O

• 사용자가 ALB에 요청을 발행 ~ Poller가 동기 호출을 할 때까지는 위의 동기 호출 순서와 유사
• Front End Invoke에서 오류가 반환됨
• Poller는 대기 시간이 지나면 다시 동기화 호출을 시도
• Front End Invoke에서 오류가 반환됨
• Poller는 DLQ에 메시지 보냄 (SendMessage)
• Poller는 SQS에서 메시지 삭제 (DeleteMessage)

---

(Stream: Poll-based)

Stream Processing

• 사용자가 Kinesis에 레코드 추가
• Kinesis의 샤드에 할당 된 Poller가 레코드를 얻는다
• Front End Invoke에 Lambda의 동기화 호출

 

• Stream Tracker가 이벤트 소스 (Kinesis 샤드 등)의 상태를 읽는다
• Stream Tracker가 Leasing Service에 Poller 할당을 요청
• 할당된 Poller는 이벤트 소스 샤드 구독을 시작

 

Scaling Up and Down - Incoming Event Volume

스트리밍 소스가 활성화된 경우 활성 샤드 수에서 필요한 Poller 수 계산/결정

Stream Tracker는 스트림을 처리하는 데 필요한 동시 실행 수를 계산하고 Leasing Service에 추가 Poller 요청

https://aws.amazon.com/jp/blogs/compute/new-aws-lambda-scaling-controls-for-kinesis-and-dynamodb-event-sources/

• Stream Tracker가 listShardsAPI를 호출하여 샤드 수 변경을 감지
• Stream Tracker는 Leasing Service를 통해 Poller 수를 조정
• Leasing Service는 DynamoDB에 Poller 할당 정보를 쓴다
• Poller는 DynamoDB에서 새 할당 정보를 읽고 샤드 구독을 시작

 

Handling Errors - Stream

DLQ, Exponential Backoff 지원

스트리밍 소스를 순서대로 처리하고 처리에 실패한 배치는 레코드가 만료될 때 까지 처리를 재시도

• 사용자가 Kinesis에 레코드 추가
• Kinesis의 샤드에 할당 된 Poller가 레코드를 얻는다
• Front End Invoke에 Lambda의 동기화 호출
• 처리가 실패하고 Front End Invoke가 Poller에 오류를 반환
• Poller는 실패한 배치를 두 개의 배치로 분할하고 다시 Front End Invoke에 Lambda의 동기 호출을 수행
• 두 배치 중 하나가 성공하면
  • Front End Invoke가 Poller에게 성공을 반환
  • Front End Invoke가 Poller에 오류를 반환
• Poller는 재시도 후 오류가 반환된 배치를 DLQ에 보낸다

---

Lambda - Scale Out(Provisioned Concurrency)

왜 Provisioned Capacity가 아닌가?

• 용량은 하드웨어에 의존한다.
  • 특정 워크로드에 필요한 용량은 하드웨어 성능에 따라 다르다. 하드웨어가 새로운 CPU, 더 빠른 메모리로 변경되면 그에 따라 필요한 용량도 변경됨.
  • 이는 고객이 하드웨어 성능에 대한 이해가 필요하다. → 서버리스의 의미에서 벗어남
• 내결함성
  • 용량 모델은 호스트 및 AZ 장애를 고려하여 AZ 장애가 발생했을 때에도 충분한 용량을 얻을 수 있도록 설계해야함
• 용량 모델에서 비즈니스 로직 변경이 용량 사용 효율에 영향을 줄 수 있다.
  • 비즈니스 로직 구현 팀이 기능을 추가하면 프로비저닝 된 용량에서 얻은 처리량이 변경된다.

Scale Up

• 실행 환경이 확장되면 cold start 발생 → 지연 시간 발생(EC2나 컨테이너 기반)
• Lambda의 경우 concurrency 기반으로 scale-up

 

우수한 웹 서비스 구축하려면..

• 부하 제어: 처리량이 떨어지기 시작하는 전환점을 초과하지 않도록 제어
• 빠른 Scale: 빠르게 확장 및 용량 추가가 가능해야한다.
• 사전 프로비저닝 가능: Provisioned Concurrency 사용