Mastering AWS Lambda SnapStart: Best Practices for State Handling and TTS Workloads

Lambda SnapStart를 켜면 “Init 시점의 모든 상태”가 스냅샷으로 얼어붙는다는 점이 핵심이다. 즉, 초기화 때 만든 소켓 연결, 난수(seed)·UUID, 임시 토큰/라이선스, 환경변수에서 파생된 캐시까지 그대로 복제되어 여러 실행 환경에 재사용될 수 있어. 그래서 TTS 런타임이 모델 시드나 라이선스를 Init에서 한 번만 세팅하면, 그 상태가 복제되어 고유성·랜덤니스·연결 상태가 미묘하게 꼬일 수 있다. (AWS Documentation)

권장 패턴 (요약)

• Lazy init / 핸들러에서 생성: UUID, 난수 seed, 임시 크레덴셜, per‑request 라이선스 토큰은 핸들러 진입 후 매 호출 시 갱신. (AWS Documentation)

• Runtime Hook 사용: 스냅샷 직전/복원 직후에 실행되는 훅으로(예: CRaC)
• beforeCheckpoint()에서 오픈 소켓/풀을 정리
• afterRestore()에서 연결 재수립, RNG reseed, 토큰 재발급 수행. (AWS Documentation)

• 네트워크 재검증: 초기화 단계에서 만든 DB/HTTP 클라이언트는 복원 후 반드시 ping/reconnect. 일부 SDK는 재개되지만 보장되지 않음. (Capital One)

• Priming은 ‘순수 캐시’만: 모델 로딩·DI 컨테이너 준비 같은 재현 가능 캐시만 미리 데워두고, 고유성이 필요한 값은 핸들러에서. (Amazon Web Services, Inc.)

TTS 런타임에 바로 적용

• 모델/사전/온디바이스 리소스: Init에서 프리로드(Priming OK).

• RNG/시드: afterRestore()에서 CSPRNG 재시드 후 사용(초기화 시 생성/캐싱 금지). (AWS Documentation)

• 라이선스/세션 키: 핸들러 진입 시 발급·검증, 복원마다 갱신.

• 소켓/풀(DB, Redis, S3, STT/TTS gRPC 등): 복원 직후 health‑check → 재연결. (Capital One)

메모용 체크리스트