JVM 시작 시간, 330초에서 3초로 줄이기

CRaC으로 워밍업을 마친 JVM의 프로세스 상태를 저장하고 새 파드에서 복원해, 파드 준비 시간을 약 330초에서 2~3초로 줄임 기존에는 파드마다 부팅과 JIT 워밍업을 반복해 CPU 여유 용량을 상시 확보해야 했고, 장애 복구와 오토스케일링도 5분 넘는 준비 시간에 제약받았음 적용 후 전체 배포 시간은 약 20분에서 4분, 정상 상태 파드 CPU는 기존 기준의 약 20% 로 줄었으며 오토스케일링이 가능해짐 실제 운영에서는 CPU 명령어 기능 불일치로 여러 파드의 JVM이 시작하지 못했으며, CRaC 적용 전 정상 이미지로 빠르게 롤백해 트래픽을 복구함 동적 오토스케일러 아래에서는 같은 노드 그룹이나 인스턴스 유형도 하드웨어 동일성을 보장하지 않으므로, 체크포인트 생성 시 기준 CPU 기능 집합을 명시적으로 고정해 복원 호환성을 확보함 JVM 워밍업을 매번 반복하는 비용 Java 프로세스는 처음에 바이트코드 인터프리터로 코드를 실행하고, JIT 컴파일러가 자주 실행되는 코드를 관찰해 점점 더 적극적인 최적화 단계의 네이티브 기계어로 컴파일함 워밍업은 JVM이 이런 최적화를 통해 실행 속도를 확보하는 과정이며, 실제 시간과 CPU를 소비함 배포, 오토스케일링, 파드 교체, 공격으로 인한 재시작 때마다 이 비용을 처음부터 다시 부담함 해당 서비스는 파드 부팅에 약 75초, 실제 트래픽을 맡길 수 있을 때까지 워밍업에 약 245초가 걸렸고, 전체 준비 시간을 약 330초로 잡았음 파드를 몇 개씩 순차 교체하므로 전체 배포에는 약 20분이 필요했음 단순 재시작도 배포만큼 느렸음 워밍업의 CPU 급증이 프로덕션 트래픽과 겹칠 수 있어, 파드 수명 동안 한 번 발생하는 비용을 감당하려고 CPU 여유 용량을 하루 종일 유지했음 공격이나 트래픽 급증으로 파드가 종료되면 대체 파드도 약 330초를 기다려야 해, 가장 중요한 순간에 평균 복구 시간(MTTR) 이 악화됐음 새 파드가 유용해지기까지 5분 넘게 걸려 부하에 대응하는 오토스케일링이 실질적인 도움이 되지 않았으며, 새벽 3시에도 고정 규모와 충분한 용량을 유지했음 대안의 한계와 CRaC의 작동 방식 GraalVM 네이티브 이미지는 거의 즉각적인 시작을 제공하지만, 해당 접근에서는 상당한 재작성과 워밍업 이후 JIT의 최대 처리량 포기가 대가였음 AppCDS는 더 작고 안전한 변경으로 클래스 로딩을 가속하지만, 주요 비용인 JIT 단계별 최적화, 인라인 캐시, GC 휴...