Lambda의 내부 동작 파헤치기

실행(Invoke) 방식

• Event
  • 예로 S3 Trigger -> Lambda
• RequestResponse
  • 예로 API Gateway -> Lambda

전역 변수(Global Scope)

## Global Scope

def gandler(event, context):
	## business login here
    return response

• 핸들러 함수 바깥의 영역은 콜드 스타트시(Init) 에서만 실행되는 부분.
  • 함수 종료후에도 Worker 노드가 종료되지 않는 이상, 메모리에 상주해 있음.
• 초기화(Initalization)에 관한 Task를 이 영역에 배치해서 적절하게 사용하면 AWS Lambda  퍼포먼스를 향상시킬 수 있음.
• 흔히 사용하는 RDB 커넥션 같은 경우 해당 커넥션 유지가 깨지게 되면 문제가 발생할 수 있기 때문에 일부 주의사항도 있음

AWS Lambda Invoke

• Invocation Type은 Event, RequestResponse, DryRun으로 나뉨
• Event는 Asynchronous방식, RequestReponse는 Synchronous방식이며 DryRun은 파라미터 및 권한을 검사해서 실행 가능 여부를 체크하는것
• 주의사항
  • Invocation Type이 Event인 경우 Lambda 함수가 성공했는지 여부를 알 수 없다(StatusCode : 202 형태로 리턴됨)
  • Event 타입인 경우는 함수를 호출했을때 별도의 큐(SQS)에 저장되며 비동기로 내부 Worker가 호출된다. 실행이 실패하면 내부적으로 다시 실행하지만 중복 실행등을 고려하여 반드시 멱등성을 고려하여 작성되어야함. 또한 실패한 경우 사용자는 알 수 없기 때문에 별도의 Dead-letter-Queue를 활성화 시켜 실패한 함수를 체크해야함.
• Event 방식으로 호출 되는 경우
  • Amazon S3, Amazon SNS, EventBridge(CloudWatch Event) 등
• RequestResponse 방식으로 호출 되는 경우
  • Amazon Kinesis, DynamoDB Streams, SQS, ALB, API Gateway

Lambda Firecracker

• AWS Lambda의 실행환경은 2015년부터 EC2 Instance 위에서 MicroVM을 올려놓고 실행시키는 방식이었음
  • AWS Lambda 소유의 EC2 Instance 위에 MicroVM을 올려놓고 그 위에 복수개의 AWS Lambda의 실행환경을 세팅하는 방식
  • 하나의 EC2 Instance 위에 복수개의 MicroVM을 올리고, 각 MicroVM 위에 복수개의 실행환경을 세팅 - MicroVM은 다른 고객들과 공유되지 않는다
• 현재는 Firecracker 기반으로, EC2 Bare Metal Instance위에 KVM 및 Firecracker를 올리고, Firecracker 위에 MicroVM을 올려두고 AWS Lambda 실행 환경을 세팅함
  • Bare Metal 위에 Host OS 및 KVM을 올리고, 이 위에 복수개의 Firecracker를 띄운다.
  • 하나의 Firecracker 프로세스는 다른 고객들과 공유되지 않는다

※현재는 위 모든과정이 1ms 내에 빌딩 되도록 지원하고 있다

네트워크 설정 방식

Hyperplane 이란?

• AWS 내부에서 사용되는 로드밸런싱
• S3 API의 로드밸런서 기반
• EFS에서는 초기부터 사용되고 있는 기술
  • API Gateway의 VPC Link, NLB, NAT Gateway등 다양한 서비스에서 사용되고 있음

💡 사실 EC2인스턴스의 Fleet 구성일 뿐, 필요에 따라 알아서 스케일 업/다운및 인/아웃 된다. Hyperplane에 액세스 가능한 ENI풀이 별도 존재(AWS 내부 별도 VPC내 존재함)

 

Lambda Invoke?

---

Event

1. LB를 통한 호출
2. Front 호출
3. SQS 저장
4. 내부 Poller 호출 및 worker 호출
   1. 실패시 dlq저장

RequestResponse

1. LB를 통한 호출
2. Front 호출
3. Worker Manager에서 Worker 호출
   1. 생성 되어 있는 worker가 없다면 Plancement를 통한 체크
   2. Plancement에 생성된 Worker가 없다면 init
   3. Worker Manager에 탐제
4. Worker 실행

Lambda@Edge

---

 

Cloud Front와 함께 결합하여 오리진 또는 뷰어 단에서 실행 되어 Header나 Parameter를 변복조 가능, 또한 User-Agent 헤더 기반으로 다른 객체 전송 하는 방식으로 쿠키, 캐시를 사용자 능동적으로 조절할 수 있음.

Builder, Deploy

---

• SAM
• CodeCommit, Deploy

SAM?

• Jetbrains, VS Code등 IDEA에 AWS Tool kit 제공
• Docker에 경량 실행 모델을 탑제하여 로컬 환경에서 빌드 및 디버깅 가능
• CodeDeploy와 연동 되어 블루/그린 배포 가능

제약 사항

---

1. 동시 실행에 대한 제약(1000개)
   1. 프로비저닝 가능하여 해당 기능을 활용한 동시성 제약 이슈 일부 해결
2. 전역 세션 유지시간 제한
3. 실행 용량 제한
   1. 기존 250~300mb였다가 최근 도커 이미지를 활용한 실행이 가능하여 10GB까지 가능함
   2. EFS를 활용한 마운트 가능
4. 실행시 메모리 제약
5. 실행 시간 제약(최대 15분)

1. LB를 통한 호출
2. Front 호출
3. Worker Manager에서 Worker 호출
   1. 생성 되어 있는 worker가 없다면 Plancement를 통한 체크
   2. Plancement에 생성된 Worker가 없다면 init
   3. Worker Manager에 탐제
4. Worker 실행

Lambda@Edge

---

Cloud Front와 함께 결합하여 오리진 또는 뷰어 단에서 실행 되어 Header나 Parameter를 변복조 가능, 또한 User-Agent 헤더 기반으로 다른 객체 전송 하는 방식으로 쿠키, 캐시를 사용자 능동적으로 조절할 수 있음.

Builder, Deploy

---

• SAM
• CodeCommit, Deploy

SAM?

• Jetbrains, VS Code등 IDEA에 AWS Tool kit 제공
• Docker에 경량 실행 모델을 탑제하여 로컬 환경에서 빌드 및 디버깅 가능
• CodeDeploy와 연동 되어 블루/그린 배포 가능

제약 사항

---

1. 동시 실행에 대한 제약(1000개)
   1. 프로비저닝 가능하여 해당 기능을 활용한 동시성 제약 이슈 일부 해결
2. 전역 세션 유지시간 제한
3. 실행 용량 제한
   1. 기존 250~300mb였다가 최근 도커 이미지를 활용한 실행이 가능하여 10GB까지 가능함(최근 자체적으로 10GB의 스토리지를 지원한다)
   2. EFS를 활용한 마운트 가능
4. 실행시 메모리 제약
   1. https://docs.aws.amazon.com/ko_kr/lambda/latest/operatorguide/profile-functions.html

Profiling functions with AWS Lambda Power Tuning - AWS Lambda

 

5. 실행 시간 제약(최대 15분)