SAP-C02 Q491 · Serverless

Question

한 회사에서 대기 시간에 민감한 애플리케이션을 개발하고 있습니다. 애플리케이션의 일부에는 가능한 한 빨리 초기화해야 하는 여러 AWS Lambda 함수가 포함되어 있습니다. Lambda 함수는 Java로 작성되었으며 라이브러리를 로드하고, 클래스를 초기화하고, 고유 ID를 생성하기 위한 핸들러 외부의 초기화 코드를 포함합니다. 스타트업 성능 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

Accepted Answer

문제의 핵심 요구사항을 분해하면:

1️⃣ **대기 시간에 민감** → 콜드 스타트 최소화 필수
2️⃣ **Java로 작성** → Java는 JVM 특성상 콜드 스타트가 가장 긴 런타임 (수 초~10초+)
3️⃣ **초기화 코드가 핸들러 외부에 존재** → 라이브러리 로드, 클래스 초기화, 고유 ID 생성
4️⃣ **비용 효율적** → 최소 비용으로 스타트업 성능 충족

**정답 D가 모든 요구사항을 충족하는 이유:**

🔹 **Lambda SnapStart 사용**: Init 단계 완료 후 메모리+디스크 상태의 스냅샷을 찍어 캐싱. 이후 호출 시 스냅샷에서 복원하므로 JVM 초기화를 건너뛰어 콜드 스타트를 ~90% 단축.

🔹 **사전 스냅샷 후크(beforeCheckpoint) 추가**: 라이브러리 로드와 클래스 초기화 같은 무거운 작업을 스냅샷에 포함시켜 복원 시 재실행 불필요. CRaC(Coordinated Restore at Checkpoint) API를 활용.

🔹 **고유 ID 생성 코드를 핸들러로 이동**: ⚠️ 이것이 핵심 포인트! SnapStart는 스냅샷을 여러 실행 환경에서 재사용하므로, Init 단계에서 생성된 고유 ID는 **모든 복원 인스턴스에서 동일한 값**이 됨. 이는 고유성(uniqueness)을 깨뜨림. 따라서 매 호출마다 고유해야 하는 값은 반드시 핸들러 안에서 생성해야 함.

🔹 **게시된 버전에 SnapStart 활성화**: SnapStart는 **$LATEST가 아닌 게시된 버전**에서만 작동함. 버전을 게시해야 스냅샷이 생성됨.

🔹 **비용 효율적**: S

📖 해설

✅ 정답 분석

❌ 오답 분석

📘 핵심 개념

🏗️ 아키텍처

⚙️ 운영 관점

💰 비용 관점

🔒 보안 관점

🎯 시험 팁