# AWS Lambda 아키텍처 및 이벤트 소스 트리거 본 문서는 AWS의 서버리스 컴퓨팅 서비스인 AWS Lambda의 아키텍처적 원리와 이벤트 소스 트리거의 동작 방식을 체계적으로 정리한 백과사전 스타일의 문서이다. Lambda는 서버 관리 없이 코드(funciton)를 이벤트에 의해 실행하는 컴퓨팅 모델을 제공한다. 이 문서는 Lambda의 핵심 구성 요소, 실행 모델, 트리거의 구성과 관리, 운영 패턴 및 실무 적용 사례를 포괄적으로 다룬다. --- ## 목차 - 개요 - 기본 용어와 개념 - 아키텍처 구성 요소 - 이벤트 소스 트리거의 유형 - 실행 모델, 성능 및 운영 - 배포, 버전 관리 및 운영 자동화 - 관측성, 디버깅 및 장애 처리 - 보안, 프라이버시 및 규정 준수 - 비용 및 최적화 전략 - 실무 패턴과 사례 - 한계와 주의점 - 결론 - 관련 문서 --- ## 1. 개요 AWS Lambda는 이벤트가 발생하면 자동으로 실행되는 함수(Function) 단위의 서버리스 컴퓨팅 서비스다. 개발자는 인프라 관리 없이 코드에 집중할 수 있으며, 이벤트 소스가 트리거가 되어 함수가 호출된다. Lambda의 실행은 임시 컨테이너에서 이루어지며, 요청 수와 실행 시간에 따라 비용이 청구된다. 핵심 특징 - 이벤트 주도(Event-driven) 실행 모델 - 관리형 실행 환경(서버 관리 필요 없음) - 다양한 런타임 및 컨테이너 이미지 지원 - 자동 확장 및 동시성 관리 - 세분화된 배포 및 운영 자동화 가능 --- ## 2. 기본 용어와 개념 - Lambda: 서버리스 컴퓨팅 서비스로, 코드(함수)를 특정 이벤트에 의해 실행한다. - Function: Lambda에서 실행되는 코드 단위. 이름은 보통 핸들러(예: handler)로 불린다. - Invocation: 함수가 실제로 실행되는 호출 이벤트. - Event: 함수 호출의 원천이 되는 데이터 구조. 예: S3 객체 업로드 이벤트, API Gateway의 요청 등. - Trigger(이벤트 소스 트리거): 이벤트를 생성하여 Lambda 함수를 호출하는 원천. - Event Source: Lambda를 트리거하는 AWS 서비스 또는 사용자가 보내는 커스텀 이벤트. - Event Source Mapping: 스트리밍/대기형 이벤트 소스로부터 Lambda가 메시지를 수신하도록 연결하는 구성. - Async vs Sync Invocation: 동기 호출은 즉시 응답을 기대하고, 비동기 호출은 이벤트를 큐에 저장하고 결과를 별도로 처리한다. - DLQ(Dead-Letter Queue): 처리 실패 시 메시지를 보관하는 큐(SQS/SNS 등). --- ## 3. 아키텍처 구성 요소 - 실행 환경(Execution Environment) - Lambda는 가상화된 컨테이너에서 함수 코드를 실행한다. - 초기 호출 시에는 핫 시작과 콜드 시작이 발생할 수 있으며, 이후 재사용 가능한 런타임 컨테이너가 유지될 수 있다. - 런타임(Runtime) - Python, Node.js, Java, Go, .NET 등 다양한 언어와 런타임 버전을 지원한다. - 패키징 및 배포 형식 - ZIP 아카이브 패키지 - 컨테이너 이미지(이미지 레지스트리 ECR에 저장) - 실행 컨텍스트 및 메모리 구성 - 함수에 할당된 메모리 양은 CPU 성능에 영향을 주며, 실행 시간과 비용에 직결된다. - 권한 및 IAM 역할 - 함수 실행 역할(IAM Role)과 트리거(이벤트 소스 매핑)에 필요한 권한 설정이 핵심이다. - 배포 관리 - 버전(Version)과 앨리어스(Alias)로 배포 버전을 관리하고, 트래픽 분할을 통해 점진적 롤아웃을 수행한다. - 모니터링 및 관측성 - CloudWatch Logs, CloudWatch Metrics, AWS X-Ray, Lambda Insights를 통해 실행 지표와 트레이스를 관찰한다. --- ## 4. 이벤트 소스 트리거의 유형 Lambda는 다양한 이벤트 소스에 의해 트리거될 수 있다. 이벤트 소스 트리거의 구성 방식은 소스와의 상호작용 패턴에 따라 다르다. - 일반 이벤트 소스(대기형) - S3: 객체 생성/삭제 이벤트로 Lambda 호출 - DynamoDB Streams: 변경 이벤트를 스트림으로 전달 - Kinesis Data Streams: 실시간 스트리밍 데이터를 처리 - SQS: 큐에서 메시지를 폴링하여 배치 단위로 처리 - SNS: 주제에 게시된 메시지를 구독자에게 전달하여 Lambda 호출 - EventBridge (이전의 CloudWatch Events): 이벤트 버스를 통해 규칙에 맞는 이벤트를 트리거 - API 및 게이트웨이 계열 - API Gateway: REST/HTTP API 요청을 Lambda로 전달 - ALB(Application Load Balancer): 인바운드 HTTP(S) 요청을 Lambda로 라우팅 - AppSync: GraphQL 구독/쿼리/뮤테이트를 Lambda로 처리 - 스케줄링 및 운영 이벤트 - CloudWatch Events/EventBridge 스케줄(크론 표현식 등) - Cron/예약된 작업을 Lambda로 실행 - 이벤트 소스 매핑(Event Source Mapping) - 스트리밍 소스 또는 대기형 소스에서 Lambda로 데이터를 가져오는 연결 구성 - 일반 설정 항목: 배치 크기(batch size), 시작 위치(starting position), 병렬화 인자(parallelization factor) 등 - 스트리밍 소스의 경우 시작 위치(예: TRIM_HORIZON, LATEST)와 데이터 배치의 처리 방식이 중요하다 - 동기 vs 비동기 호출 차이 - 동기 호출: 즉시 응답 필요 시 사용 (예: API Gateway → Lambda) - 비동기 호출: 이벤트를 큐에 저장하고 언제든 재처리 가능, 실패 시 DLQ로 전달 가능 --- ## 5. 실행 모델, 성능 및 운영 - 실행 모델 - Lambda는 필요 시 자동으로 스케일링되며, 이벤트 수에 맞춰 다수의 컨테이너가 병렬로 실행될 수 있다. - 핫 시작과 콜드 시작의 차이가 성능에 영향을 줄 수 있다. - 메모리와 CPU - 메모리 설정은 CPU 및 네트워크 대역폭에도 영향을 준다. 더 높은 메모리는 일반적으로 더 빠른 처리와 비용 증가의 균형을 요구한다. - 동시성 관리 - 계정 수준의 동시성 한계와 함수별 동시성의 제어를 통해 급격한 트래픽 증가를 관리한다. - Provisioned Concurrency를 사용하면 특정 함수에 대해 항상 일정한 동시성으로 안정적인 응답 시간을 보장할 수 있다. - 배치 처리와 데이터 흐름 - 스트리밍 소스의 경우 이벤트 소스 매핑의 배치 크기와 검사 주기의 최적화를 통해 처리 지연을 관리한다. - 배포 전략 - 버전/앨리어스와 가중치 기반 트래픽 분배를 활용해 점진적 롤아웃이 가능하다. - 롤백 및 모니터링으로 실패 시 신속하게 대응한다. --- ## 6. 배포, 버전 관리 및 운영 자동화 - 배포 도구 및 프레임워크 - AWS SAM, AWS CDK, Serverless Framework, CloudFormation 등을 사용하여 인프라를 코드로 관리한다. - 버전 및 앨리어스 - 함수의 새 버전을 생성하고 앨리어스를 통해 트래픽을 새 버전으로 점진적으로 이동시키는 전략이 일반적이다. - 트리거 구성의 재사용성과 관리 - 동일 트리거 구성을 여러 함수에 재사용하는 방법과, 트리거 설정 변경 시의 영향 분석이 필요하다. - CI/CD 파이프라인 - 빌드/테스트/패키징/배포를 자동화하고, 롤백 절차를 준비한다. --- ## 7. 관측성, 디버깅 및 장애 처리 - 로깅 및 모니터링 - CloudWatch Logs에 표준 출력/표준 에러 로그가 기록되며, 로그 그룹/스트림으로 분석 가능. - CloudWatch Metrics를 통해 초당 실행 수, 지연 시간, 에러 수 등을 모니터링. - AWS X-Ray를 통한 분산 추적으로 호출 흐름과 지연 원인을 파악. - Lambda Insights를 통해 런타임 내의 메모리 사용량, CPU 사용률 등의 심층 관측 가능. - 에러 처리 및 재시도 - 동기 Invocation에서는 실패 시 예외 응답이 반환될 수 있으며, 비동기 Invocation에서는 재시도 정책과 DLQ를 활용한다. - DLQ를 설정하면 실패한 이벤트를 SQS/SNS로 전달해 재처리 및 감사 가능성을 확보한다. - 장애 대응 - 핫 스왑(대체 함수 버전의 즉시 활성화), 모니터링 임계치 기반의 자동화된 알림, 재시도 정책 점검 등을 통해 가용성을 높인다. --- ## 8. 보안, 프라이버시 및 규정 준수 - 최소권한 원칙 - Lambda 실행 역할은 필요한 리소스에 대해서만 권한을 부여한다. - 네트워크 보안 - VPC 연결 시 서브넷/보안 그룹 설정으로 네트워크 트래픽을 제어한다. 필요한 경우 프라이빗 엔드포인트를 활용한다. - 데이터 암호화 - 환경 변수, 저장 데이터, 로깅 데이터 등에서의 암호화 및 키 관리(KMS)를 검토한다. - 컴플라이언스 - 데이터 지역성, 감사 로깅, 접근 제어 정책 등을 요구사항에 맞게 구성한다. --- ## 9. 비용 및 최적화 전략 - 비용 구성 - 계산 시간 요금: 일시적 실행 시간(초 단위)과 할당 메모리 양에 따라 청구된다. - 이벤트 소스 요금: 일부 소스(예: API Gateway, 일부 트리거)에서 별도 요금이 발생할 수 있다. - 최적화 포인트 - 메모리 크기와 런타임 성능의 균형 맞추기 - 불필요한 트리거 제거 및 배치 크기 조정 - Provisioned Concurrency 도입 여부 판단 - 콜드 스타트 완화 전략 적용 (예: 자주 사용되는 핸들러를 Warm-up 이벤트로 주기적으로 호출) --- ## 10. 실무 패턴과 사례 - 데이터 수집 및 스트리밍 파이프라인 - S3 이벤트나 DynamoDB Streams를 트리거로 사용하여 데이터 수집 및 실시간 또는 배치 처리 파이프라인 구성 - 서버리스 API 게이트웨이 백엔드 - API Gateway 또는 ALB를 통해 REST/HTTP API 요청을 Lambda로 처리하는 구조 - 이벤트 기반 워크플로우 - EventBridge를 중심으로 다수의 Lambda를 연결한 이벤트 버스 기반 설계 - Step Functions와의 연계로 복잡한 워크플로우 관리 - 서버리스 데이터 처리 애플리케이션 - Kinesis 또는 DynamoDB Streams를 이용한 실시간 분석 및 변환 파이프라인 --- ## 11. 한계와 주의점 - 실행 시간 제한 - Lambda 함수은 기본 실행 시간 제한이 있으며, 필요 시 연장 구성은 가능하나 무한 실행은 불가. - 실행 컨텍스트 재사용의 비결정성 - 콜드 스타트 여부는 예측하기 어렵고 트래픽 변화에 따라 달라진다. - 이벤트 전송의 정합성 - 이벤트의 중복 가능성을 고려한 idempotency 설계 필요. - Payload 크기 및 수신 제한 - 이벤트의 최대 페이로드 크기와 수신 한계에 대한 제약을 확인한다. --- ## 12. 결론 AWS Lambda는 이벤트 중심의 서버리스 컴퓨팅을 구현하는 강력한 플랫폼이다. 다양한 이벤트 소스 트리거를 통해 데이터 수집, 실시간 처리, API 백엔드 등 다양한 아키텍처를 구현할 수 있다. 핵심은 적절한 트리거 구성, 세밀한 권한 관리, 효과적인 관측과 재시도 정책, 그리고 비용 최적화이다. 이러한 요소를 조합하면 확장성과 가용성이 높은 서버리스 애플리케이션을 설계할 수 있다. --- ## 관련 문서 - 관련 문서: [[AWS SAM(서버리스 애플리케이션 모델) 소개]], [[EventBridge 아키텍처 및 이벤트 버스 설계]]