AWS Section 21-2. AWS 서버리스: Lambda

Lambda Logging & Monitoring

AWS Lambda는 CloudWatch와 통합되어 있으며, 실행 중에 발생하는 로그와 메트릭을 수집하여 모니터링할 수 있다.

• CloudWatch Logs
  • Lambda 함수의 모든 실행 로그는 AWS CloudWatch Logs에 저장된다.
  • Lambda 함수가 CloudWatch Logs에 로그를 기록하려면, 해당 함수에 CloudWatch Logs에 기록할 수 있는 권한이 있는 IAM 역할이 부여되어 있어야 한다.
  • 이를 위해 AWSLambdaBasicExecutionRole과 같은 관리형 역할이 필요하다.
• CloudWatch Metrics
  • Lambda 함수의 메트릭은 AWS CloudWatch Metrics에 표시된다.
  • 메트릭 항목
    • 호출 수 (Invocations)
    • 실행 시간 (Durations)
    • 동시 실행 수 (Concurrent Executions)
    • 오류 수, 성공률, 스로틀 (Error count, Success Rates, Throttles)
    • 비동기 전송 실패 (Async Delivery Failures)
    • Iterator Age (Kinesis와 DynamoDB 스트림의 경우)

 

Lambda Tracing with X-Ray

• Active Tracing을 Lambda 구성에서 활성화하면 X-Ray가 자동으로 작동한다.
  • X-Ray는 분산 추적 시스템으로, 서비스 간 호출을 추적,모니터링하는 데 사용된다.
• Lambda가 X-Ray 데몬을 실행하여, 추적 데이터를 X-Ray 콘솔로 전송할 수 있다.
• AWS X-Ray SDK를 코드에 포함하여 추가적인 기능을 활용할 수 있다.
• Lambda 함수는 X-Ray와 통신하기 위해 AWSXRayDaemonWriteAccess라는 IAM 역할이 필요하다.
• X-Ray와 통신하는 데 사용되는 환경 변수
  • _X_AMZN_TRACE_ID: 추적 헤더 정보를 포함.
  • AWS_XRAY_CONTEXT_MISSING: 기본값은 LOG_ERROR.
  • AWS_XRAY_DAEMON_ADDRESS: X-Ray 데몬의 IP 주소 및 포트 정보.

 

Customization At The Edge

• Edge Computing
  • 사용자의 지리적 위치에 따라 코드를 가까운 서버에서 실행함으로써 지연 시간을 최소화하는 방법
• 엣지에서의 함수를 실행할 수 있는 함수: CloudFront Functions, Lambda@Edge.
• 엣지 함수는 전역적으로 배포됨
• use case : CDN 콘텐츠 사용자 정의
• 필요한 만큼만 비용 지불.
• Full Serverless

 

CloudFront Functions & Lambda@Edge Use Cases

• 사용 사례
  • 웹사이트 보안 및 개인정보 보호.
  • 엣지에서 동작하는 동적 웹 애플리케이션.
  • 검색 엔진 최적화(SEO).
  • 오리진 및 데이터 센터 간 지능형 라우팅.
  • 엣지에서의 봇 완화 및 실시간 이미지 변환.
  • 사용자 인증 및 권한 부여, A/B 테스트, 사용자 우선 순위 지정, 사용자 추적 및 분석.

 

CloudFront Functions

• CloudFront Functions 특징
  • JavaScript로 작성된 가벼운 함수.
  • 밀리초 미만의 시작 시간으로 대규모, 지연이 민감한 CDN 사용자 정의에 적합.
  • 뷰어 요청 및 응답만 변경.
  • 사용 예시: 뷰어 요청이 들어오면 이를 수정하거나, 뷰어로 응답을 전달하기 전에 응답을 수정.

• Viewer Request와 Viewer Response 단계에서만 동작
• 즉, 클라이언트에서 CloudFront로 요청이 들어올 때와 응답이 클라이언트로 돌아가기 전에 요청과 응답을 변경할 수 있음!!

 

Lambda@Edge

• Lambda@Edge 특징
  • NodeJS 또는 Python으로 작성.
  • 수천 개 요청/초 처리 가능.
  • 뷰어 요청 및 응답, 오리진 요청 및 응답까지 모두 처리 가능.
  • 리전 간 배포: AWS 리전(us-east-1)에 작성된 함수는 CloudFront의 위치에 복제됨.

• Viewer Request, Viewer Response뿐만 아니라, Origin Request와 Origin Response 단계에서도 동작할 수 있습니다. 즉, 클라이언트와 오리진 서버 간의 모든 요청과 응답을 처리할 수 있

 

 

CloudFront Functions vs Lambda@Edge

CloudFront Functions와 Lambda@Edge의 기능적 차이점

• CloudFront Functions는 JavaScript, Lambda@Edge는 NodeJS와 Python을 지원.
• 요청 수: CloudFront Functions는 초당 수백만 건, Lambda@Edge는 수천 건.
• 실행 시간: CloudFront Functions는 밀리초 미만, Lambda@Edge는 최대 10초.
• 트리거: CloudFront는 Viewer 요청/응답만, Lambda@Edge는 Viewer와 Origin 모두 트리거 가능.

 

 

CloudFront Functions vs Lambda@Edge - Use Cases

• CloudFront Functions 사용 사례
  • 캐시 키 정규화, 헤더 조작, URL 리디렉션, 인증 및 권한 부여.
  • 매우 짧은 실행 시간(1밀리초 미만)으로 경량 작업에 적합.
• Lambda@Edge 사용 사례
  • 실행 시간이 더 길고 CPU, 메모리 조정 가능.
  • 외부 네트워크 서비스에 대한 액세스 필요 시 적합.
  • 파일 시스템 또는 HTTP 요청 본문 액세스 가능.

Lambda@Edge는 더 복잡한 작업과 긴 실행 시간, 외부 리소스와의 상호작용이 필요할 때 주로 사용되며, CloudFront Functions는 속도와 효율이 중요한 간단한 작업에 사용됨

비용 측면에서 CloudFront Functions가 더 저렴하며, Lambda@Edge는 용량에 따라 비용이 증가할 수 있다

 

 

Lambda 기본 배포의 작동

Lambda 함수가 공용 리소스(예: DynamoDB)에는 접근할 수 있지만, VPC 내의 사설 RDS에는 접근할 수 없다

• Lambda는 기본적으로 사용자 VPC 외부에서 실행된다.
• 즉 RDS, ElastiCache 등 VPC 내부의 리소스에 액세스에 접근할 수 없다.
  • Lambda가 기본적으로 VPC에 연결되지 않기 때문
• 외부 API나 DynamoDB 같은 공용 리소스는 기본적으로 접근 가능하다.
  • Lambda 함수는 공용 인터넷과 연결되어 있기 때문

 

 

Lambda VPC 설정

Lambda가 사설 서브넷에 배포되고, ENI를 통해 VPC 내의 RDS에 접근

• VPC ID와 서브넷, 보안 그룹을 정의해야 한다.
• Lambda는 서브넷 내에 ENI(Elastic Network Interface)를 생성한다.
• VPC 리소스에 접근하려면 AWSLambdaVPCAccessExecutionRole이 필요하다.

 

Lambda VPC 설정 시 인터넷 접근

Lambda가 사설 서브넷에 배포되어 있고, NAT를 통해 외부 API에 접근할 수 있는 설정을 보여줌

• VPC 내의 Lambda 함수는 인터넷에 접근할 수 없다.
• NAT 게이트웨이 또는 NAT 인스턴스가 있어야 사설 서브넷에서 인터넷 접근이 가능하다.
• WS 서비스에 접근하기 위해서는 VPC 엔드포인트를 사용할 수 있음
  • Lambda가 외부 API뿐만 아니라, AWS 서비스인 DynamoDB와 같은 리소스에도 안전하게 접근할 수 있게 해줌
• But 공용 서브넷에 Lambda를 배포하더라도 공용 IP를 할당받지 못한다.
  • 즉 공용 서브넷에 배포되더라도 NAT를 거쳐야 외부와의 연결이 가능하다는 점.⭐

 

Lambda가 VPC 내에서 인터넷에 접근하기 위해서는 NAT 게이트웨이 설정이 필요

AWS 서비스에 접근하기 위해서는 VPC 엔드포인트 설정을 추가해야 한다는 점

But 공용 서브넷에 Lambda를 배포하더라도 공용 IP를 할당받지 못하므로 공용 서브넷에 배포되더라도 NAT를 거쳐야 외부와의 연결이 가능하다는 점

 

Lambda Function Configuration

• Lambda 함수의 RAM 설정 범위는 128MB에서 10GB까지 확장 가능하며, 1MB 단위로 증가시킬 수 있다.
• RAM을 늘릴수록 vCPU 크레딧도 증가하며, 1,792MB에서 1개의 vCPU와 동일한 성능을 갖는다.
• 1,792MB 이상을 설정하면 다중 스레딩을 이용하여 최대 6개의 vCPU를 사용할 수 있다.
• 애플리케이션이 CPU에 의존적이라면 RAM을 늘려서 성능을 최적화할 수 있다.
• 타임아웃 기본값은 3초이며, 최대 15분(900초)까지 설정 가능하다.

 

Lambda Execution Context

• Execution 컨텍스트는 Lambda 함수 실행 시 외부 의존성을 초기화하는 임시 런타임 환경
  • 데이터베이스 연결, HTTP 클라이언트 등을 설정할 수 있으며, 이를 통해 다음 호출에서도 재사용할 수 있어 실행 시간이 단축된다.
• 이 컨텍스트는 /tmp 디렉토리를 포함하며, 일시적인 데이터를 캐싱하는 데 유용하다.

 

Initialize outside the handler

Lambda 함수에서 핸들러 외부에서 초기화하는 방법

• BAD
  • 핸들러 내부에서 매번 새로운 연결을 시도하는 것은 비효율적이며, 성능 저하를 초래할 수 있다.
• GOOD
  • 데이터베이스 연결이나 HTTP 클라이언트 등의 DB 연결을 핸들러 함수 외부에서 설정해서 한 번만 연결한다. >> 함수 호출 시 재사용하는 것이 모범 사례 !!

 

Lambda Functions /tmp space

• Lambda 함수에서 작업 시 큰 파일을 다운로드하거나 디스크 공간이 필요할 때 /tmp 디렉토리를 사용할 수 있다.
• 최대 10GB까지 사용할 수 있다.
• Execution Context가 유지되는 동안 그대로 남아 있어서, 다음 함수 호출 시에도 재사용하여 캐시로 활용할 수 있다.
• 영구적으로 데이터를 저장하려면 Amazon S3를 사용하는 것이 좋다.
• /tmp 디렉토리의 데이터를 암호화하려면 KMS 데이터 키를 생성해야 한다.
  • /tmp 디렉토리 : Lambda 함수가 임시 파일을 저장하거나 빠르게 데이터를 처리할 수 있는 공간으로 활용

 

Lambda Layers

Lambda Layers

• 외부 종속성을 재사용할 수 있게 해주는 기능
• 여러 Lambda 함수에서 공통으로 사용되는 라이브러리나 패키지를 매번 함수와 함께 배포할 필요 없이 Layer로 분리하여 효율적으로 관리할 수 있다.
  • Custom Runtimes (사용자 지정 런타임)
    • 람다 계층을 사용하여 특정 언어를 지원하지 않았던 경우에도 새로운 언어로 람다 함수를 실행할 수 있다.
    • GitHub에서 제공하는 런타임 사용 가능
      • C++: aws-lambda-cpp
      • Rust: aws-lambda-rust-runtime

• 라이브러리 파일을 Lambda 함수와 함께 포함시킨 경우
• 총 패키지 크기가 30.02MB
• 모든 의존성을 함수와 함께 배포하기 때문에 비효율적

 

• Layer로 중복되는 라이브러리를 분리
• lambda_function_1.py (왼쪽)
  • Lambda 함수는 20KB로 줄어든다, 나머지 라이브러리들은 계층으로 만들어 각각 10MB, 30MB로 나누어진다.
• lambda_function_2.py (오른쪽)
  • 또 다른 Lambda 함수가 같은 Layer를 재사용하는 경우. 새로운 함수는 불필요한 라이브러리를 포함하지 않으므로 패키지 크기가 60KB로 줄어든다
  • (여러 애플리케이션이 동일한 계층을 재사용 가능)

Layer를 사용하면 패키지 크기를 줄이고, 중복된 라이브러리를 효율적으로 관리할 수 있다 (효율적인 배포, 종속성의 재사용성)

 

 

Lambda – File Systems Mounting

EFS (Elastic File System)

• VPC 내에서 동작하는 Lambda 함수가 네트워크 파일 시스템을 사용할 수 있게 해주는 서비스
• Lambda 함수를 VPC 내에서 실행하고, EFS 파일 시스템을 로컬 디렉토리로 마운트할 수 있다 ( >> Lambda가 상태 유지, 공유 파일 시스템 사용 가능하도록 해줌)

Lambda 함수는 두 개의 가용 영역에 배포되어 있으며, Private Subnet에서 동작. 각 Lambda 함수는 EFS Access Point를 통해 EFS 파일 시스템에 연결됨

• EFS Access Points
  • Lambda에서 EFS에 접근할 때 EFS 액세스 포인트를 반드시 사용해야 한다.
  • (EFS에 접근하는 엔드포인트 역할)
  • EFS 파일 시스템에 대한 효율적/ 관리 가능한 접근 경로를 제공
• Lambda 인스턴스 하나당 EFS 연결이 하나 필요하므로 Lambda 인스턴스가 많아지면 EFS 연결 제한과 연결 버스트 한도에 주의해야 한다.

 

Lambda – Storage Options

Lambda는 다양한 스토리지 옵션을 제공. 각 옵션은 특성에 따라 적절하게 선택

• Ephemeral Storage (/tmp)
  • 최대 크기: 10GB
  • 임시적인 스토리지로 Lambda 함수가 종료되면 삭제
  • 동적으로 콘텐츠를 생성하고 파일 시스템 조작이 가능
  • 가장 빠른 데이터 접근 속도를 제공하지만, 함수 간에는 공유되지 않음
• Lambda Layers
  • 최대 크기: 계층당 250MB까지 5개 계층을 지원 (함수당 최대 1.25GB)
  • 내구성이 있어 지속되고, 정적인 종속성을 재사용하는 데 적합
  • IAM 권한으로 접근을 제어하며, 계층 내 데이터는 공유 가능
• Amazon S3
  • 탄력적인 스토리지로 크기에 제한이 없음
  • 동적으로 객체 데이터를 저장하며, 다양한 API (GET, PUT 등)를 통해 액세스할 수 있음
  • 가격은 S3의 스토리지, 요청, 데이터 전송 요금을 따름
  • 함수 간에 데이터를 공유할 수 있으며 빠른 접근 속도를 제공
• Amazon EFS
  • 파일 시스템 기반 스토리지로 탄력적이며, 모든 파일 시스템 조작을 지원
  • Lambda가 VPC 내에서 실행될 때 사용되며, 파일 시스템을 필요로 하는 대규모 작업에 적합
  • 빠른 데이터 접근이 가능하며, 모든 Lambda 호출에서 공유

 

 

Lambda 동시성과 스로틀링

 

Lambda 동시성 한도

• 동시성 한도: 기본적으로 Lambda는 최대 1,000개의 실행을 동시에 처리할 수 있음

• 예약된 동시성(Reserved Concurrency): 특정 Lambda 함수에 대해 동시에 실행할 수 있는 수를 제한할 수 있다. 이 제한을 초과하면 Lambda는 스로틀링을 유발한다.
• Throttle 발생 시
  • 동기 호출: ThrottleError - 429 오류가 반환된다.
  • 비동기 호출: 자동으로 재시도가 이루어지며, 실패가 계속되면 Dead Letter Queue(DLQ)로 보내진다.

더 높은 동시성 한도가 필요한 경우, AWS 지원을 통해 요청 가능

 

 

 

예약된 동시성이 없는 경우의 문제

• 예약된 동시성을 설정하지 않으면 한 함수가 1,000개의 동시 실행을 모두 사용할 수 있어, 다른 함수들이 스로틀링될 수 있다.
• EX) 
  • 로드 밸런서를 사용하는 고수요 애플리케이션이 모든 동시 실행을 소비하면, API 게이트웨이 기반 애플리케이션이나 SDK/CLI를 사용하는 애플리케이션이 스로틀링될 수 있다.
  • 이런 경우 여러 애플리케이션이 동일한 동시성 한도를 공유하므로, 작은 애플리케이션이 더 큰 애플리케이션에 의해 성능 저하를 겪게 된다.

 

동시성과 비동기 호출

• Lambda의 동시성 한도를 초과할 경우, 비동기 호출이 스로틀링된다.
• Lambda는 스로틀링된 호출을 지수 백오프 방식으로 최대 6시간 동안 재시도한다.
• 이를 통해 바로 처리할 수 없는 요청도 나중에 처리할 수 있는 기회를 갖게 된다. (DLQ로 보내짐)

콜드 스타트(Cold Start)와 프로비저닝된 동시성

• 콜드 스타트
• : 새로운 Lambda 인스턴스가 시작될 때 코드가 로드되고 외부 리소스가 초기화됩니다. 이 과정은 시간이 걸리며, 첫 번째 요청은 나머지 요청보다 높은 지연 시간을 겪게 된다.
• 프로비저닝된 동시성: 애플리케이션 오토 스케일링을 통해 동시성을 자동으로 관리할 수 있다.
• : 함수가 호출되기 전에 미리 동시성을 할당하여 콜드 스타트가 발생하지 않도록 한다. (모든 호출에서 지연 시간을 최소화)

 

예약된 동시성과 프로비저닝된 동시성의 차이

• 예약된 동시성(Reserved Concurrency)
  • 각 함수에 대해 동시 실행 한도를 설정하여 다른 함수에 영향을 주지 않도록 하는 방식이다.
• 프로비저닝된 동시성(Provisioned Concurrency)
  • 특정 시점에서 일정한 동시 실행 환경을 미리 할당하여 콜드 스타트 없이 항상 빠르게 처리될 수 있도록 한다.

콜드 스타트를 방지하고 일정한 성능을 유지하고 싶다면 프로비저닝된 동시성을 활용하는 것이 효과적

다양한 함수들이 하나의 동시성 한도를 공유하는 상황을 방지하려면 예약된 동시성이 효과적

 

 

<언어별 종속성 패키징 방법>

• Node.js: npm, node_modules 디렉터리 사용
• Python: pip --target 옵션 사용
• Java: 관련 .jar 파일 포함
• 람다 함수는 코드와 종속성을 모두 함께 압축해야 한다,
• 파일 크기가 50MB 이하이면 바로 람다에 업로드가 가능하지만,
• 50MB 초과 시에는 Amazon S3에 업로드하고 람다에서 이를 참조하게 된다.
• 네이티브 라이브러리를 사용하는 경우, 먼저 Amazon Linux에서 컴파일이 필요하다.
• 참고로 AWS SDK는 모든 람다 함수에 기본적으로 포함되어 있으므로, 별도로 패키징할 필요가 없다.

 

Lambda와 CloudFormation

 

Lambda와 CloudFormation – 인라인 방식

 

종속성이 없는 매우 단순한 함수에 사용하는 것이 적합

 

인라인 코드를 사용한 Lambda 함수의 CloudFormation 템플릿 예시

• 코드가 직접 템플릿 내에 포함되어 있으며, Code.ZipFile 속성으로 선언되어 있음
• Lambda 코드를 인라인으로 작성할 수 있으며, CloudFormation 템플릿에 포함시킬 수 있다.
• Code.ZipFile 속성을 사용하여 매우 간단한 코드를 인라인으로 작성할 수 있지만, 외부 종속성을 포함할 수 없다.

 

Lambda와 CloudFormation – S3를 통한 방식

• Lambda 코드를 Amazon S3에 저장한 뒤, CloudFormation 템플릿에서 S3 버킷을 참조하여 함수를 정의할 수 있다.
• 이를 위해서는 S3 버킷 경로와 버전 정보 등을 CloudFormation에 설정해야 한다
• Lambda 코드가 업데이트될 경우, 버전 정보도 함께 업데이트해야 함수를 업데이트할 수 있다

S3에 저장된 Lambda 코드를 참조하는 CloudFormation 템플릿 예시

• 코드를 S3 버킷에 업로드하고, S3Bucket과 S3Key를 CloudFormation에서 참조하게 된다.

 

 

Lambda와 CloudFormation – 여러 계정에서 S3를 통한 방식

• 여러 AWS 계정에서 S3에 저장된 Lambda 코드를 공유하고 배포할 수 있다.

여러 AWS 계정 간에 S3 버킷을 통해 Lambda 코드를 공유하고 배포하는 구조

• 여러 계정에서 같은 Lambda 코드를 사용하려면
  • 계정 1에서 Lambda 코드가 저장된 S3 버킷에 대한 정책을 설정하고,
  • 계정 2와 계정 3에서 CloudFormation과 실행 역할이 해당 버킷에 접근할 수 있도록 허용해야 한다.
• 각 계정은 S3 버킷에 접근할 수 있는 권한을 가지며, 실행 역할을 통해 CloudFormation을 실행할 수 있다.

Lambda Container Images

• Lambda 함수는 ECR(Amazon Elastic Container Registry)에서 최대 10GB의 컨테이너 이미지로 배포할 수 있다.
• 복잡한 종속성 지원: 패키지 종속성, 데이터 세트 등을 포함한 복잡한 종속성을 컨테이너에 패킹할 수 있다.
• 베이스 이미지: Lambda 런타임 API를 구현하는 베이스 이미지가 Python, Node.js, Java, .NET, Go, Ruby 등 여러 언어에 대해 제공된다.
• 직접 이미지 생성 가능: Lambda 런타임 API를 구현하기만 하면 직접 베이스 이미지를 만들 수도 있다.
• 로컬 테스트 가능: Lambda Runtime Interface Emulator를 사용해 컨테이너 이미지를 로컬에서 테스트할 수 있다.
• 통합된 워크플로우: 컨테이너 이미지를 사용하여 애플리케이션을 구축, 게시, ECR에 전송하고 Lambda에서 배포할 수 있다.

애플리케이션 코드와 종속성을 포함한 컨테이너 이미지를 빌드 -> ECR에 게시 → Lambda로 배포하는 과정

 

Lambda Container Images 예제

AWS에서 제공하는 베이스 이미지 를 사용해 Lambda 컨테이너 이미지를 생성하는 Dockerfile

• Dockerfile 을 통해 컨테이너 기반의 Lambda 함수를 쉽게 배포할 수 있다.

 

Lambda Container Images – Best Practices

• AWS 제공 베이스 이미지 사용
  • Amazon Linux 2 기반의 안정적인 베이스 이미지를 사용하는 것이 좋다.
  • 이미 Lambda 서비스에 의해 캐시되어 있어 데이터를 더 빠르게 가져올 수 있다.
• 멀티 스테이지 빌드
  • 빌드 과정에서 불필요한 파일이나 단계는 제거하고 최종적으로 필요한 아티팩트만 남기는 방식으로 컨테이너 크기를 줄일 수 있다.
• 안정적인 것부터 자주 변경되는 것까지 계층화
  • 가장 자주 변경되는 요소는 빌드의 마지막 단계에 두어야 불필요한 빌드를 최소화할 수 있다.
• 단일 리포지토리 사용
  • 큰 계층을 가진 Lambda 함수는 단일 리포지토리를 사용하여 중복 계층을 피하고 효율적인 저장 및 배포가 가능하다.

 

AWS Lambda Versions

Lambda 함수는 버전 관리를 통해 안정적인 배포와 롤백을 지원

$LATEST는 수정 가능한 기본 버전, V1과 V2는 배포 후 생성된 Immutable (변경 불가) 버전

• 작업은 항상 $LATEST에서 수행됨 (수정 가능한 버전)
• 배포 시: $LATEST에서 새로운 버전을 생성 (Immutable, 수정 불가)
• 버전 특징:
  • 각 버전은 고유 ARN을 가짐
  • 버전별로 코드 및 설정은 고정됨
  • 이전 버전으로 쉽게 롤백 가능

 

AWS Lambda Aliases

• Alias(별칭): Lambda 함수 버전의 "포인터"
  • 예: DEV, TEST, PROD 별칭
• 별칭의 기능
  • Canary 배포: 트래픽을 여러 버전에 비율로 분배 가능
  • 이벤트 트리거와 목적지에 안정적 설정 제공
• 별칭의 특징
  • 변경 가능 (mutable)
  • 자체 ARN을 가짐
  • 주의: 별칭은 다른 별칭을 참조할 수 없음🌟

• DEV, TEST, PROD 별칭이 각각 다른 버전($LATEST, V1, V2)을 가리킴
• PROD 별칭은 Canary 배포를 통해 95%는 V1으로, 5%는 V2로 트래픽을 분배

 

 

Lambda & CodeDeploy

• CodeDeploy
  • Lambda 별칭(alias)에 대한 트래픽 전환을 자동화하는 기능을 제공한다.
  • CodeDeploy는 SAM 프레임워크에 통합되어 있음
• 트래픽 전환 전략
  • Linear: 일정 시간마다 트래픽을 점진적으로 증가시킨다.
    • 예: Linear10PercentEvery3Minutes
  • Canary: X%만 먼저 테스트한 후, 이후에 100%로 전환한다.
    • 예: Canary10Percent5Minutes
  • AllAtOnce: 모든 트래픽을 즉시 전환힌다 (위험성이 큼).
• Pre & Post Traffic Hooks: Lambda 함수의 상태를 체크하는 후크를 통해 트래픽 이동 전후의 Lambda 함수 상태를 확인하고 문제가 있을 경우 롤백이 가능하다.

• 그림에서 보여주는 건 PROD 별칭이 V1에서 V2로 트래픽을 점진적으로 이동하는 과정을 나타낸다.
• X%가 늘어날 때마다, 트래픽의 일부가 V2로 전환되고 나머지는 V1으로 이동한다.

 

 

Lambda & CodeDeploy – AppSpec.yml

• Lambda와 CodeDeploy를 통합하여 배포하기 위해 AppSpec.yml 파일을 사용한다.
• 주요 매개변수
  • Name: 배포할 Lambda 함수의 이름 (필수).
  • Alias: Lambda 함수 별칭의 이름 (필수).
  • CurrentVersion: 현재 트래픽이 가리키는 Lambda 함수 버전.
  • TargetVersion: 트래픽이 이동할 Lambda 함수 버전.

AppSpec.yml 파일의 예시

현재 버전은 1 / 대상 버전은 2로 설정되어 트래픽이 이동

 

 

Lambda – Function URL

• Lambda 함수에 대해 전용 HTTP(S) 엔드포인트가 제공됨.
• 고유 URL이 생성되며, 이는 변경되지 않음.
• HTTP 클라이언트를 통해 함수 호출 가능 (웹 브라우저, curl, Postman 등).
• PrivateLink는 지원하지 않으며, 퍼블릭 인터넷을 통해서만 접근 가능.
• 자원 기반 정책(Resource-based Policies) 및 CORS 구성을 지원.
• 예약된 동시성 기능을 통해 실행량을 조절할 수 있음.

 

Lambda 함수가 클라이언트로부터 HTTPS 요청을 받는 구조

 

Lambda – Function URL Security

• Lambda 함수 URL 보안은 리소스 기반 정책과 CORS 설정을 통해 관리된다.
• 리소스 기반 정책은 계정, CIDR, IAM 주체 등에 따른 권한을 설정할 수 있다.
• CORS 설정은 다른 도메인에서 Lambda 함수 URL을 호출할 때 필요하다.

다른 도메인에서 Lambda 함수 URL을 호출할 때 CORS 설정 방법

 

 

Lambda – Function URL Security (AuthType NONE)

• AuthType NONE 설정 시 Lambda 함수 URL에 퍼블릭 액세스가 허용된다.
• 퍼블릭 액세스 권한을 설정할 때도 리소스 기반 정책이 항상 적용된다
• 퍼블릭 및 인증되지 않은 사용자가 Lambda 함수에 접근할 수 있다

AuthType NONE 설정 / 블릭 액세스를 허용하는 리소스 기반 정책을 사용하여 Lambda 함수 URL이 호출되는 과정

 

 

Lambda – Function URL Security (AuthType AWS_IAM)

• AuthType AWS_IAM 설정 시 IAM을 통해 Lambda 함수 URL에 대한 요청을 인증하고 승인한다.
• 같은 계정 내에서는 자격 증명 기반 정책(Identity-based Policy) 또는 리소스 기반 정책이 필요하다.
• 교차 계정의 경우, 두 계정 모두에 대해 자격 증명 기반 정책과 리소스 기반 정책이 허용되어야 한다.

계정 간의 Lambda 함수 URL 호출 과정에서 리소스 기반 정책과 자격 증명 기반 정책이 적용되는 과정

 

Lambda and CodeGuru Profiling

• CodeGuru Profiler를 사용하여 Lambda 함수의 런타임 성능에 대한 통찰을 얻을 수 있다.
• CodeGuru는 프로파일러 그룹을 생성하며, Java와 Python 런타임에 대해 지원된다.
• AWS Lambda 콘솔에서 프로파일링을 활성화할 수 있다.

<프로파일링 활성화시>

• CodeGuru Profiler 계층이 Lambda 함수에 추가된다.
• 함수에 환경 변수가 설정된다.
• AmazonCodeGuruProfilerAgentAccess 정책이 IAM 역할에 추가된다.

CodeGuru Profiler가 함수의 성능 데이터를 수집하는 과정

Lambda 제한 사항

실행 제한

1. 메모리 할당: 128MB에서 10GB까지, 1MB 단위로 증감.
   • 메모리가 늘어나면 vCPU도 더 많아짐.
2. 최대 실행 시간: 900초 (15분).
   • 15분 이상 소요 시 람다에 적합하지 않은 워크로드.
3. 환경 변수 크기 제한: 최대 4KB.
4. 임시 저장 공간 (/tmp): 최대 512MB.
5. 동시 실행: 기본 최대 1,000건 (별도 요청 시 증대 가능).
6. 배포 제한 : ZIP 파일 크기 최대 50MB (압축되지 않은 파일은 250MB).
   • 대형 파일은 /tmp 공간 사용 권장.

RAM 30GB 필요, 실행 시간 30분 이상, 또는 3GB 이상의 파일 처리와 같은 요구사항은 람다에 적합하지 않음. (시험⭐)

 

AWS Lambda 모범 사례

1. 핸들러 외부에서 많은 작업 수행
   • 핸들러가 실행되는 시간을 최소화하기 위함
   • 데이터베이스 연결, AWS SDK 초기화, 종속성/데이터셋 로드는 함수 핸들러 외부에서 처리.
2. 환경 변수 사용
   • 데이터베이스 연결 문자열, S3 버킷 이름 등 코드에 직접 입력 금지.
   • 민감한 정보는 KMS로 암호화하여 환경 변수로 설정.
3. 배포 패키지 최소화
   • 패키지를 나눠서 관리하고, 필요한 라이브러리만 포함.
   • Lambda 계층(Layer)을 사용해 라이브러리 재사용 고려.
4. 재귀적 코드 금지
   • Lambda 함수가 자기 자신을 호출하지 않도록 주의.