Serverless 내부: Cold Start와 Firecracker MicroVM

graph TD
    A["Physical Server (Metal)"] --> B["KVM (Kernel-based VM)"]
    B --> C["Firecracker MicroVM 1"]
    B --> D["Firecracker MicroVM 2"]
    C --> E["User Code A (Java)"]
    D --> F["User Code B (Python)"]
    
    style A fill:#f9f,stroke:#333
    style C fill:#bbf,stroke:#333
    style D fill:#bbf,stroke:#333

┌──────────────────────────────────┐
│     Lambda 함수 (사용자 코드)       │  ← 신뢰할 수 없는 코드
├──────────────────────────────────┤
│   Guest Kernel (최소 리눅스)       │  ← 커스텀 최소 커널
├──────────────────────────────────┤
│   Firecracker VMM (Rust)          │  ← 메모리 안전 언어
├──────────────────────────────────┤
│   KVM (하드웨어 가상화)            │  ← CPU 레벨 격리
├──────────────────────────────────┤
│   Jailer (seccomp + cgroups)      │  ← syscall 필터링 + 리소스 제한
├──────────────────────────────────┤
│   Host Linux Kernel               │
└──────────────────────────────────┘

sequenceDiagram
    participant Requester
    participant AWS_Lambda as "Lambda Service"
    participant Firecracker as "MicroVM (Worker)"
    
    Requester->>AWS_Lambda: 1. Invoke Function
    
    rect rgb(240, 240, 240)
    Note over AWS_Lambda, Firecracker: 🥶 Cold Start Phase
    AWS_Lambda->>AWS_Lambda: Download Code (S3)
    AWS_Lambda->>Firecracker: 2. Boot MicroVM
    Note right of Firecracker: ~125ms (Lightning Fast)
    
    Firecracker->>Firecracker: 3. Init Runtime (JVM/Node)
    Note right of Firecracker: 🐢 Heavy Lifting (수초 소요)
    Firecracker->>Firecracker: 4. Init User Code (Static Block)
    end
    
    Firecracker->>Requester: 5. Execute Handler & Return

# SAM template 예시
MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: java21
    SnapStart:
      ApplyOn: PublishedVersions  # SnapStart 활성화

// SnapStart에서는 스냅샷 시점의 상태가 복원됩니다.
// 따라서 아래 항목들은 복원 후 재초기화가 필요합니다:

public class MyHandler implements RequestHandler<String, String> {
    
    // ❌ 위험: 스냅샷 시점의 커넥션이 복원됨 → 이미 끊어진 커넥션
    private static Connection dbConn = DriverManager.getConnection(...);
    
    // ✅ 안전: CRaC 훅으로 복원 시 재연결
    @Override
    public void afterRestore(Context<? extends Resource> context) {
        dbConn = DriverManager.getConnection(...);  // 복원 후 재연결
        // 난수 시드도 재초기화 (보안!)
        SecureRandom.getInstanceStrong();
    }
}

일반 Java:  .java → .class → JVM이 해석하며 실행 (느린 시작)
GraalVM:    .java → 네이티브 바이너리 → 직접 실행 (빠른 시작)

# Spring Boot + GraalVM Native Image 빌드
./mvnw -Pnative native:compile

# 또는 Docker 이미지로
./mvnw spring-boot:build-image -Pnative

GraalVM이 적합한 경우:
✅ Cold Start가 사업적으로 중요 (API Gateway 뒤의 동기 호출)
✅ 메모리 비용 절감이 필요
✅ 리플렉션 사용이 적거나 미리 파악 가능
✅ 서버리스 또는 CLI 도구

JVM이 나은 경우:
✅ 장시간 실행되는 서비스 (JIT가 빛남)
✅ 리플렉션 의존이 큰 프레임워크 사용
✅ 빠른 개발 루프(빌드→테스트) 필요
✅ Warm Start가 주류 (트래픽이 일정)

# 프로비저닝된 동시성 설정
MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    ProvisionedConcurrencyConfig:
      ProvisionedConcurrentExecutions: 10  # 항상 10개 Warm 유지

public class Handler {
    // ❌ 나쁜 예: 요청마다 DB 연결 (Cold + Warm 모두 느림)
    public void handleRequest() {
        Connection conn = DriverManager.getConnection(...);
        try {
            // 쿼리 실행
        } finally {
            conn.close();
        }
    }
}

public class Handler {
    // ✅ 좋은 예: 전역 변수는 재사용됨 (Warm Start에서 0ms)
    private static final AmazonDynamoDB dynamoDB = 
        AmazonDynamoDBClientBuilder.standard().build();
    
    // HTTP 클라이언트도 재사용 (커넥션 풀 유지)
    private static final OkHttpClient httpClient = new OkHttpClient.Builder()
        .connectionPool(new ConnectionPool(5, 5, TimeUnit.MINUTES))
        .build();
    
    public void handleRequest() {
        // dynamoDB, httpClient는 Warm Start에서 재사용
    }
}

번들 크기가 Cold Start에 직접 영향:
- S3에서 코드 다운로드 시간 ∝ 패키지 크기
- 클래스 로딩 시간 ∝ 클래스 수

✅ 실무 가이드:
  - spring-boot-starter 대신 필요한 모듈만 (spring-web, spring-jdbc)
  - 사용 안 하는 의존성 제거 (mvn dependency:analyze)
  - Layer로 공통 의존성 분리 (Lambda Layers)
  - Uber-jar 대신 proguard/shade로 불필요 클래스 제거

┌──────────────────────────┐
│     함수 코드 (500KB)      │  ← 자주 변경, 빠른 배포
├──────────────────────────┤
│  Layer 1: 공통 SDK (10MB)  │  ← 드물게 변경, 캐시됨
├──────────────────────────┤
│  Layer 2: 유틸 (2MB)       │  ← 드물게 변경, 캐시됨
└──────────────────────────┘

장점:
- 함수 코드만 500KB → 배포 속도 20배↑
- Layer는 한 번 다운로드 후 캐시됨
- 여러 함수가 같은 Layer 공유 가능

메모리  CPU 할당        비용/ms         Cold Start
128MB   ~0.08 vCPU     $0.0000000021   느림 (CPU 부족)
512MB   ~0.33 vCPU     $0.0000000083   보통
1024MB  ~0.58 vCPU     $0.0000000167   빠름
1769MB  1.0 vCPU       $0.0000000289   빠름 (CPU 전체)
3008MB  2.0 vCPU       $0.0000000491   가장 빠름

⚠️ 역설: 메모리를 올리면 비용이 내려갈 수 있습니다!
  128MB × 10초 = $0.0000000021 × 10,000ms = $0.000021
  512MB × 1초  = $0.0000000083 × 1,000ms  = $0.0000083 ← 더 저렴!

# SAR에서 배포 후 실행
# 다양한 메모리 설정으로 자동 테스트 → 최적점 찾기
aws lambda invoke --function-name powerTuner \
  --payload '{"function":"arn:aws:lambda:...:myFunc","num":20,"powerValues":[128,256,512,1024,1769]}'

// Lambda에서의 구조 로깅 (JSON)
public class OrderHandler implements RequestHandler<APIGatewayProxyRequestEvent, ...> {
    
    private static final Logger log = LoggerFactory.getLogger(OrderHandler.class);
    
    public APIGatewayProxyResponseEvent handleRequest(
            APIGatewayProxyRequestEvent event, Context context) {
        
        // 요청 컨텍스트를 MDC에 추가
        MDC.put("requestId", context.getAwsRequestId());
        MDC.put("functionName", context.getFunctionName());
        MDC.put("remainingTimeMs", 
            String.valueOf(context.getRemainingTimeInMillis()));
        
        log.info("주문 처리 시작", 
            kv("orderId", orderId),
            kv("userId", userId),
            kv("amount", amount));
        
        try {
            Order order = processOrder(event);
            
            log.info("주문 처리 완료",
                kv("orderId", order.getId()),
                kv("processingTimeMs", elapsed));
                
            return response(200, order);
            
        } catch (Exception e) {
            log.error("주문 처리 실패",
                kv("orderId", orderId),
                kv("errorType", e.getClass().getSimpleName()),
                kv("errorMessage", e.getMessage()));
                
            return response(500, "Internal Server Error");
        } finally {
            MDC.clear();
        }
    }
}

// AWS X-Ray로 분산 트레이싱
@Tracing  // Powertools for Lambda
public Order processOrder(OrderRequest request) {
    
    // 서브세그먼트: DB 호출 추적
    return TracingUtils.withSubsegment("DynamoDB.putItem", subsegment -> {
        subsegment.putAnnotation("orderId", request.getOrderId());
        return dynamoDB.putItem(request.toDynamoItem());
    });
}

동기 (API Gateway → Lambda):
  Client → API GW → Lambda → DB → Response
  ✅ 간단, 즉시 응답
  ❌ Cold Start가 사용자 체감에 직결

비동기 (이벤트 → Lambda):
  Client → API GW → SQS → Lambda → DB
  ✅ Cold Start가 사용자에게 안 보임
  ✅ 자동 재시도, DLQ
  ❌ 즉시 응답 불가 (비동기이므로)

💡 실무 원칙:
  - 사용자 응답이 필요한 GET/조회 → 동기
  - 결제/주문 처리 → 비동기 (SQS 버퍼)
  - 파일 처리/이메일 → 비동기 (S3 이벤트)

하나의 이벤트 → 여러 Lambda 동시 실행

       ┌→ Lambda A (이메일 발송)
SNS →  ├→ Lambda B (재고 차감)
       └→ Lambda C (분석 이벤트 기록)

장점: 각 함수가 독립적으로 실패/재시도
주의: 순서 보장 없음, 멱등성 필수

의사결정 흐름도:

트래픽이 하루 대부분 0인가?
  → Yes → Lambda (비용 0)
  → No → 평균 동시 요청이 10개 이상인가?
           → Yes → ECS/Fargate (비용 효율)
           → No → Lambda (운영 편의)

실행 시간이 15분을 넘는가?
  → Yes → ECS/Step Functions
  → No → Lambda 가능