Day 5 - Week 3 복습: Lambda 종합 시나리오로 실전 감각 다지기

결제 API Lambda 함수가 트래픽 급증 시 높은 레이턴시를 보인다. CloudWatch ConcurrentExecutions는 정상 범위이고, Duration P99이 3,000ms를 넘는 상황이다. 가장 가능성 높은 원인과 해결책은?

• AVPC ENI 생성 지연으로 매 호출이 느려진다 → Lambda를 VPC에서 분리한다 — Hyperplane ENI 이후 핫패스 ENI 생성이 없고 ConcurrentExecutions도 정상이라 원인 불일치
• B트래픽 급증 시 새 실행 환경이 생성되어 콜드 스타트가 발생한다 → Provisioned Concurrency 설정
• C메모리 부족으로 GC·스왑이 발생한다 → MemorySize를 10GB로 올린다 — 메모리 부족이면 OOM 에러와 Max Memory Used 포화가 먼저 보이나 그 징후가 없음
• DReserved Concurrency 상한에 걸려 큐잉된다 → Reserved 설정을 제거한다 — 그러면 Throttles 메트릭이 증가해야 하는데 Duration P99만 치솟아 증상과 다름

S3에 이미지가 업로드되면 Lambda가 썸네일을 생성해 같은 버킷의 thumbnails/ 디렉토리에 저장한다. 운영 중 Lambda가 무한 루프에 빠진 것을 발견했다. 원인과 해결책은?

• A썸네일 생성이 타임아웃 내에 끝나지 않아 같은 객체가 재처리된다 → 타임아웃을 900초로 늘린다 — 타임아웃이 늘어도 출력이 다시 입력 이벤트를 트리거하는 한 루프는 그대로
• Bthumbnails/ 디렉토리에 파일이 저장될 때 새 S3 이벤트가 발생해 Lambda가 다시 호출된다 → 이벤트 알림에 suffix 필터(*.jpg)를 추가하고 썸네일은 다른 확장자로 저장하거나, 입출력 버킷을 분리한다
• C동시성이 부족해 이벤트가 재시도 큐에 쌓여 반복 호출된다 → Reserved Concurrency를 1000으로 늘린다 — 동시성을 늘려도 자기 출력이 새 이벤트를 만드는 재귀 구조는 해소되지 않음
• D실행 역할에 s3:PutObject 권한이 없어 저장이 반복 재시도된다 → 역할에 S3 full access를 부여한다 — 권한 부족이면 무한 루프가 아니라 AccessDenied로 즉시 실패

주문 처리 시스템에서 Lambda가 SQS를 폴링해 주문을 처리한다. 배치 크기는 100이고, 하나의 주문이 외부 API 타임아웃으로 실패했다. 나머지 99개도 다시 처리되는 문제가 발생했다. 어떻게 해결하는가?

• ASQS 큐에 maxReceiveCount 기반 DLQ를 설정해 실패 메시지를 격리한다 — DLQ는 최종 실패 후에야 작동하고 나머지 99개의 재처리 자체는 막지 못함
• BESM의 비동기 재시도 횟수를 0으로 설정해 재시도를 끈다 — SQS ESM은 비동기 호출이 아니며 이 설정으로 부분 실패 격리가 되지 않음
• CReportBatchItemFailures를 활성화하고 Lambda가 실패한 메시지 ID만 batchItemFailures로 반환하도록 구현한다
• D배치 크기를 100에서 1로 줄여 메시지를 한 건씩 처리한다 — 부분 실패는 사라지나 호출 수가 100배로 늘어 비효율적

Java Spring Boot를 Lambda로 운영 중이다. 콜드 스타트가 3~5초에 달해 API 응답 SLA를 위반한다. 비용 효율적인 해결책은?

• A메모리를 10GB로 최대화해 vCPU를 늘리고 INIT을 가속한다 — CPU는 빨라지나 JVM 클래스 로딩이 지배적이라 3-5초 콜드 스타트가 충분히 줄지 않고 메모리 비용만 급증
• BLambda SnapStart를 활성화하고 버전/별칭을 통해 배포한다
• CProvisioned Concurrency를 1,000으로 설정해 항상 웜 인스턴스를 확보한다 — 효과는 있으나 실트래픽을 크게 초과하는 PC 1,000개라 비용이 막대
• DJava에서 Node.js로 런타임을 교체해 부팅을 줄인다 — 콜드 스타트는 개선되나 전체 코드 재작성이 필요한 대규모 리팩토링

Lambda 함수의 환경 변수에 DB 비밀번호를 저장했다. 보안팀이 이것이 기본 KMS 관리 키로만 암호화되어 계정 내 다른 팀도 잠재적으로 접근 가능하다고 지적했다. 가장 효과적인 해결책은?

• A비밀번호를 Base64로 인코딩한 뒤 환경 변수에 저장해 평문 노출을 막는다 — Base64는 암호화가 아니라 누구나 디코딩 가능해 보안 효과가 없음
• BAWS Secrets Manager로 이전하거나, 환경 변수를 팀별 고객 관리 KMS 키(CMK)로 암호화한다
• C환경 변수를 삭제하고 비밀번호를 코드에 상수로 하드코딩한 뒤 리포지토리 접근을 제한한다 — 소스에 비밀이 박혀 git 이력·배포 패키지로 더 광범위하게 노출
• D실행 역할에서 KMS 복호화 권한을 제거해 다른 팀의 접근을 차단한다 — 환경 변수 복호화가 막혀 함수 자체가 동작 불능이 됨

한 팀이 Lambda 함수에 Reserved Concurrency 500을 설정했다. 계정 전체 동시성 한도는 1,000이다. 다음 날 다른 팀의 함수가 급격한 트래픽 증가로 스로틀링됐다. 원인은?

• A다른 팀 함수의 코드 결함으로 동시 실행이 누수되어 스로틀링이 났다 — 코드 문제가 아니라 공유 풀이 차감된 구조적 원인
• BReserved Concurrency 500 설정으로 계정 공유 풀이 500으로 줄어, 다른 함수들이 총 500개밖에 쓸 수 없게 됐다
• CLambda 동시성 한도는 함수·팀별로 독립 할당되므로 한 함수의 예약이 다른 함수에 영향을 주지 않는다 — 실제로는 단일 계정/리전 풀을 공유
• D다른 팀 함수에 Provisioned Concurrency가 설정되지 않아 버스트를 견디지 못했다 — PC 부재는 콜드 스타트 이슈일 뿐 스로틀링의 원인이 아님

Lambda 함수가 Kinesis Data Streams를 폴링하는데, CloudWatch에서 IteratorAge 메트릭이 지속적으로 증가하고 있다. 무엇을 의미하며 어떻게 대응하는가?

• A함수 메모리 부족으로 처리가 지연되어 지표가 오른다 → MemorySize를 늘린다 — 메모리는 한 요인일 수 있으나 IteratorAge 증가의 근본은 소비 속도가 생산 속도에 못 미치는 처리량 격차
• BLambda가 Kinesis 스트림 레코드를 처리하는 속도가 생성 속도보다 느리다 → ParallelizationFactor 증가, 샤드 수 증가, 처리 로직 최적화
• CKinesis 스트림 레코드 보존 기간이 만료되어 lag이 커졌다 → 보존 기간을 7일로 늘린다 — 보존 기간은 데이터 만료 시점일 뿐 IteratorAge(미처리 lag)와 무관
• DESM 실행 역할에 Kinesis 읽기 권한이 부족하다 → KinesisFullAccess를 부여한다 — 권한 부족이면 폴링이 아예 실패하지 lag이 점진 증가하지 않음

여러 Lambda 함수에서 동일한 pandas, numpy 라이브러리를 사용한다. 각 함수의 ZIP 크기가 200MB에 달해 배포 속도가 느리다. 어떻게 개선하는가?

• A모든 함수를 하나의 큰 Lambda로 합쳐 의존성을 한 번만 패키징한다 — 단일 책임을 깨고 복잡도·blast radius가 커지며 배포는 더 무거워짐
• Bpandas, numpy를 Lambda Layer로 분리하고, 각 함수는 비즈니스 로직만 포함한다
• C모든 함수를 컨테이너 이미지(최대 10GB)로 전환해 라이브러리를 베이스 이미지에 굽는다 — 동작하나 레이어 대비 과하고 컨테이너 이미지는 Layer를 함께 쓸 수 없음
• D함수 메모리 설정을 낮춰 배포 패키지 크기를 줄인다 — MemorySize는 런타임 자원일 뿐 ZIP 크기와 전혀 무관

Lambda Destinations와 DLQ를 동시에 설정한 경우 어떻게 동작하는가?

• ADLQ가 Destinations보다 우선순위가 높아 실패 이벤트는 DLQ로만 전송된다 — 실제 우선순위는 반대로 Destinations가 DLQ를 대체
• BDestinations OnFailure가 설정되어 있으면 DLQ는 무시된다
• C두 설정이 모두 적용되어 동일한 실패 이벤트가 DLQ와 Destinations 양쪽으로 중복 전송된다 — 둘 중 Destinations만 적용되므로 중복 전송되지 않음
• D설정 충돌로 Lambda가 ConfigurationError를 던져 둘 중 하나만 남기도록 요구한다 — 둘 다 설정 가능하며 충돌 오류 없이 Destinations가 우선 적용

Lambda 함수 코드에서 DB 연결을 핸들러 함수 내부에 생성하고 있다. 운영팀이 DB 연결 수 급증으로 RDS Connection Limit 오류가 난다고 보고했다. 가장 효과적인 해결책은?

• ALambda 메모리를 줄여 동시에 뜨는 실행 환경 수를 억제한다 — 메모리는 연결 수와 무관하며 오히려 처리량만 떨어뜨림
• B핸들러 외부(글로벌 스코프)로 DB 연결 코드를 이동하거나, Amazon RDS Proxy를 사용한다
• CReserved Concurrency를 1로 설정해 동시 연결을 한 개로 강제한다 — 연결 폭증은 막으나 사실상 직렬 처리가 되어 처리량이 붕괴
• DRDS 인스턴스 크기를 키워 max_connections 한도를 높인다 — 한도만 늘릴 뿐 비효율적 연결 생성 패턴은 그대로라 근본 해결이 아님

Lambda 비동기 호출의 이벤트 나이(event age) 최대값은?

• A1시간
• B6시간
• C24시간
• D7일

Lambda 함수가 사내 온프레미스 데이터베이스에 접근해야 한다. 이 DB는 VPN 연결을 통해서만 접근 가능하다. 어떻게 구성하는가?

• ALambda Function URL을 발급해 그 엔드포인트로 온프레미스 DB와 통신한다 — Function URL은 함수를 인터넷에 노출하는 인바운드 HTTPS 엔드포인트일 뿐 사내망 아웃바운드 경로가 아님
• BLambda 함수에 Elastic IP를 직접 할당해 고정 IP로 VPN 터널을 통과시킨다 — Lambda에는 EIP를 붙일 수 없고 아웃바운드 고정 IP는 VPC+NAT로만 가능
• CLambda를 VPC에 연결하고, VPC에 Direct Connect 또는 Site-to-Site VPN으로 온프레미스 네트워크를 연결한다
• DLambda 실행 역할에 적절한 IAM 권한을 부여하면 AWS가 온프레미스까지 VPN을 자동 구성한다 — IAM은 권한 제어일 뿐 네트워크 경로를 만들지 못함