트래픽이 급증하는 시점에 API Gateway의 P99 Latency가 수 초(seconds) 단위로 치솟는 현상은 FaaS(Function as a Service) 아키텍처를 채택한 엔지니어링 팀이 마주하는 가장 흔한 병목입니다. 이는 단순히 애플리케이션 로직의 비효율성 때문이 아니라, 서버리스 플랫폼의 근본적인 수명 주기 관리 메커니즘인 콜드 스타트(Cold Start)에서 기인합니다. 물리 서버를 점유하지 않는 비용 효율성의 이면에는, 요청이 들어올 때마다 샌드박스 환경을 초기화해야 하는 Trade-off가 존재합니다.
1. 실행 환경의 생명 주기와 지연 시간 해부
콜드 스타트를 단순히 "처음 실행될 때 느리다" 정도로 이해해서는 최적화 포인트를 찾을 수 없습니다. AWS Lambda를 기준으로 내부 동작(Under the hood)을 살펴보면, 실행 환경은 크게 두 가지 단계로 초기화됩니다.
문제는 그 이후입니다. 함수 초기화(Function Init) 단계에서는 코드 패키지를 다운로드하고 압축을 해제한 뒤, 전역 변수(Global Scope)를 설정하고 의존성을 로드합니다. 우리가 제어할 수 있는 최적화의 80%는 바로 이 구간, 즉 사용자 코드의 로딩 및 초기화 단계에 집중되어 있습니다. VPC 내부에 Lambda를 배치할 경우 과거에는 ENI(Elastic Network Interface) 생성으로 인해 추가적인 지연이 발생했으나, 현재는 Hyperplane ENI 기술로 인해 이 오버헤드는 거의 무시할 수 있는 수준이 되었습니다.
2. 런타임 선택과 패키지 사이즈 최적화
런타임 언어의 선택은 콜드 스타트 성능에 결정적인 영향을 미칩니다. 일반적으로 인터프리터 언어(Node.js, Python)가 컴파일 언어(Java, .NET)에 비해 콜드 스타트 시간이 짧습니다. 하지만 이것이 항상 Node.js가 정답임을 의미하지는 않습니다. Java 진영에서는 SnapStart와 같은 기술로 JVM의 초기화 상태를 스냅샷으로 저장하여 복원하는 방식을 도입했습니다.
더 중요한 것은 배포 패키지의 크기입니다. 필요 이상의 라이브러리를 포함하면 I/O 대기 시간이 길어집니다. 아래는 런타임별 일반적인 콜드 스타트 특성을 비교한 데이터입니다.
| Runtime | Cold Start Latency (Avg) | Optimization Focus |
|---|---|---|
| Python / Node.js | < 500ms | Dependency Tree Shaking, Lazy Loading |
| Go (Compiled) | < 400ms | Binary Size Optimization |
| Java (Legacy) | > 2000ms | Heavy JVM Init overhead |
| Java (SnapStart) | < 500ms | CRaC (Coordinated Restore at Checkpoint) |
3. Provisioned Concurrency 설정과 비용 Trade-off
엔지니어링은 언제나 비용과 성능 사이의 줄타기입니다. Provisioned Concurrency(프로비저닝된 동시성)는 지정된 수의 실행 환경을 미리 초기화하여 메모리에 상주시키는 기능입니다. 이를 통해 콜드 스타트를 웜 스타트(Warm Start)로 전환할 수 있습니다. 이는 전자상거래의 플래시 세일(Flash Sale)이나 티켓팅 서비스처럼 예측 가능한 트래픽 스파이크에 필수적입니다.
하지만 유휴 상태(Idle)에서도 비용이 청구되므로, 모든 함수에 적용하는 것은 비효율적입니다. Auto Scaling 정책을 통해 트래픽 패턴에 따라 동적으로 동시성을 조절해야 합니다.
# AWS SAM Template Example: Provisioned Concurrency
Resources:
PaymentProcessorFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: payment/
Handler: app.handler
Runtime: nodejs18.x
# AutoPublishAlias 설정이 필수적임
AutoPublishAlias: live
DeploymentPreference:
Type: AllAtOnce
ProvisionedConcurrencyConfig:
ProvisionedConcurrentExecutions: 10
4. 코드 레벨의 아키텍처 최적화
인프라 설정을 넘어, 코드 작성 방식에서도 지연 시간을 줄일 수 있습니다. 핵심은 초기화 로직의 지연 실행(Lazy Loading)과 연결 재사용(Connection Reuse)입니다. AWS SDK나 데이터베이스 클라이언트와 같은 무거운 의존성은 핸들러 외부(Global Scope)에서 선언하되, 실제 연결은 요청이 들어올 때 확인해야 합니다. 그러나 TCP 연결 자체는 핸들러 실행 간에 유지되어야 합니다.
다음은 Node.js 환경에서 SDK 로딩을 최적화하는 Anti-Pattern과 Best Practice 비교입니다.
// [Anti-Pattern] Load entire SDK, increasing init duration
const AWS = require('aws-sdk'); // v2 style, heavy
const s3 = new AWS.S3();
exports.handler = async (event) => {
// Logic...
};
// ---------------------------------------------------------
// [Best Practice] Modular Import & Keep-Alive
// AWS SDK v3 allows modular imports to reduce package size
const { S3Client, PutObjectCommand } = require("<@aws-sdk/client-s3>");
// Initialize client outside handler to reuse TCP connection
const client = new S3Client({
region: "us-east-1",
// Node.js keeps connections alive by default in v3,
// but explicit configuration ensures predictable behavior.
});
exports.handler = async (event) => {
// Only business logic executes here
const command = new PutObjectCommand({ ... });
await client.send(command);
};
결론
서버리스 아키텍처에서의 콜드 스타트는 완전히 제거할 수 없는 물리적 한계입니다. 하지만 불필요한 의존성 제거, 적절한 런타임 선택, 그리고 Provisioned Concurrency의 전략적 사용을 통해 사용자 경험(UX)에 영향을 주지 않는 수준(Sub-second)으로 제어할 수 있습니다. 맹목적으로 모든 함수를 최적화하기보다, X-Ray와 같은 분산 추적 도구를 사용하여 실제 병목 구간이 Initialization인지 Execution인지 식별한 후 접근하십시오.
Post a Comment