GKE 팟 스냅샷 운영 계약 설계

AI 추론 서버나 격리 샌드박스가 느리게 시작되는 이유를 컨테이너 이미지 다운로드 하나로 설명하기는 어렵다. 모델 가중치를 읽어 GPU 메모리에 올리고, 런타임을 초기화하고, 요청을 받을 준비가 됐다는 신호까지 내야 하기 때문이다. 트래픽이 짧게 치솟을 때 이 과정을 새 복제본마다 반복하면, 팀은 응답 대기 시간을 감수하거나 미리 켜 둔 가속기 용량을 유지하는 선택지 사이에 놓인다.

Google Cloud는 2026년 9월 21일 GKE Pod snapshots를 소개하며 실행 중인 워크로드의 상태와 CPU·GPU 메모리를 저장한 뒤 필요할 때 복원할 수 있다고 밝혔다. 발표에 인용된 벤치마크의 최대 89% 시작 지연 감소와 모델별 시간은 특정 모델·환경에서의 벤더 측정값이다. 따라서 이 글은 그 숫자를 다른 클러스터의 성능 약속으로 옮기지 않는다. 대신 새 기능이 바꾸는 실제 운영 질문, 즉 “준비된 상태를 무엇으로 정의하고 언제까지 신뢰할 것인가”를 정리한다.

1. 새 기능이 바꾸는 것은 이미지가 아니라 실행 상태의 출발점

원문 사실 카드

공식 블로그는 팟이 충분히 초기화된 뒤 상태를 한 번 캡처하고, 이후 복제본이 이 상태에서 복원되도록 설명한다. 일반적인 확장에서는 각 복제본이 모델 가중치와 런타임을 독립적으로 준비한다. 스냅샷 경로에서는 준비가 끝난 한 팟이 기준점이 된다. 이 차이는 단순한 컨테이너 캐시보다 넓다. 문서상 캡처 대상은 애플리케이션 메모리와 파일 시스템까지 포함할 수 있다.

하지만 “상태”는 곧바로 안전하거나 최신이라는 뜻이 아니다. 기준 팟이 외부 비밀을 메모리에 들고 있었는지, 시작 뒤 받는 설정이 바뀌는지, 연결 중인 데이터베이스 세션을 어떻게 다루는지에 따라 같은 스냅샷이라도 복원 적합성이 달라진다. 스냅샷은 준비 시간을 없애는 마법이 아니라, 초기화 시점의 상태를 복제 가능한 산출물로 승격하는 일이다.

공식 CRD 문서는 PodSnapshotStorageConfig와 PodSnapshotPolicy 두 리소스로 구성을 나눈다고 설명한다. 전자는 Cloud Storage 버킷·경로·토큰 소스를, 후자는 선택자·저장소 구성·스냅샷 범위·트리거·보존을 다룬다. CRD 레퍼런스의 PodSnapshot 상태에는 작업 성공·실패를 나타내는 조건과 저장 경로가 남는다. 즉 운영자가 볼 대상은 새 팟의 시작 시간뿐 아니라 캡처가 실제로 끝났는지와 어느 정책이 그 상태를 만들었는지다.

작동 원리 해설

초기화가 완료된 워크로드는 스냅샷 신호를 보낸다. GKE는 정책에 맞는 팟의 메모리와 파일 시스템 상태를 캡처하고, 그 결과를 구성된 Cloud Storage 위치로 올린다. 이후 새 팟이 같은 정책의 스냅샷을 사용해 배포되면, 처음부터 애플리케이션 초기화 코드를 모두 밟는 대신 저장된 상태에서 출발한다. 수동 트리거와 워크로드 트리거가 모두 지원되므로, 준비 완료를 플랫폼이 추측하게 하기보다 애플리케이션이 안전한 지점을 알리는 설계가 중요하다.

이 방식은 특히 동일한 의존성과 초기 데이터가 반복되는 추론 복제본, 또는 비신뢰 코드를 별도 환경에서 실행하는 샌드박스에 맞는다. Agent Sandbox 안내서는 빠른 시작, 장기 작업 재개, 중간 계산과 대화 맥락의 보존, 동일한 초기 상태에서의 재현을 사용 사례로 든다. 다만 이 문서가 예시로 설명하는 샌드박스 경로는 GKE Sandbox를 전제로 하며, 모든 팟이 같은 제약과 지원 범위를 갖는다고 읽어서는 안 된다.

2. 기능 발표와 도입 판단을 분리하는 표

변경점·버전 차이

표의 왼쪽은 제품 문서의 사실이고, 오른쪽은 이 글이 제안하는 도입 검토 항목이다. 이 구분은 중요하다. 예를 들어 버킷을 지정할 수 있다는 사실은 해당 버킷의 접근 제어가 이미 적절하다는 뜻이 아니다. tokenSource는 기본 podKSA와 멀티테넌시용 federatedP4SA를 지원하지만, 어떤 신원에 어느 경로의 읽기·쓰기를 줄지는 조직의 IAM 모델과 분리해 검토해야 한다.

또한 rootfs-only가 지원된다는 이유만으로 항상 더 안전하거나 더 빠르다고 단정할 수 없다. 애플리케이션이 메모리에서만 유지하는 초기화 결과가 있다면 그 범위로는 기대한 복원이 되지 않을 수 있다. 반대로 전체 팟 상태가 필요하지 않은데도 넓은 범위를 기본값으로 잡으면, 저장·권한·폐기해야 할 정보의 범위를 불필요하게 키운다. 기능의 범위 선택은 성능 스위치가 아니라 데이터 분류 결정이다.

▲ 저장소·권한·보존 규칙과 PVC 변경 경로를 구분해 검토해야 하는 관계를 보여줍니다.

3. 복원 가능성과 데이터 일관성은 같은 질문이 아니다

실패 모드 대신 검증 절차를 먼저 둔다

가장 놓치기 쉬운 지점은 팟의 캡처 시점과 외부 상태의 시간이 다를 수 있다는 사실이다. CRD 문서는 PVC를 쓰는 워크로드에서 postCheckpoint: resume을 선택한 뒤 동일 볼륨이 변경되면 복원이 실패할 수 있다고 경고한다. 팟이 체크포인트 후에도 계속 실행되고, 그 사이 볼륨 내용이 달라졌다면 메모리·파일 시스템의 한 시점과 PVC의 다른 시점을 결합하려 하기 때문이다.

다음 절차는 공식 운영 절차가 아니라, 이 제약을 배포 전에 드러내기 위한 편집부 제안이다.

1. 범위 확인: 복제할 팟의 메모리·루트 파일 시스템·PVC·외부 서비스 의존성을 목록으로 적는다. “팟 전체”라는 말만으로 영속 데이터까지 동일 시점이 된다고 가정하지 않는다.
2. 준비 신호 확인: 초기화가 끝났고 캡처해도 되는 시점을 워크로드 신호 또는 수동 트리거 중 하나로 정한다. 배포 직후라는 시간 조건만으로 준비 완료를 판정하지 않는다.
3. 권한 경로 확인: 선택된 Kubernetes 서비스 계정이 필요한 버킷 경로에만 접근하는지, 스냅샷 컨트롤러 권한과 분리되는지 확인한다. Agent Sandbox 예시는 Workload Identity Federation과 IAM 구성을 단계로 안내한다.
4. 복원 시험: 새 팟을 복원한 뒤 애플리케이션의 준비 상태, 필요한 파일, 외부 연결의 재수립을 관측한다. 캡처 성공 상태만으로 서비스 준비 성공을 대신하지 않는다.
5. PVC 변형 시험: PVC를 쓰는 경우 체크포인트 뒤 변경이 있는 경로와 없는 경로를 구분해 시험한다. 실패가 관측되면 정책의 postCheckpoint 동작이나 워크로드의 쓰기 순서를 재검토한다.
6. 폐기 확인: 보존 기한과 그룹별 최대 개수를 정하고, 만료 후 실제 저장 객체와 권한이 함께 정리되는지 확인한다.

여기서 관측 신호는 최소한 PodSnapshot의 조건, 저장소 경로, 복원된 팟의 준비 상태, 애플리케이션 로그, 그리고 비용·보존 정책의 변경 기록이어야 한다. “스냅샷을 만들었다”와 “새 복제본이 요청을 처리할 준비가 됐다”는 서로 다른 관측값이다.

복원 시험은 평상시의 한 번 성공으로 끝내기보다, 배포 이미지나 초기 설정을 바꾼 뒤에도 다시 수행하는 편이 낫다. 기준 팟이 오래된 라이브러리·정책·초기 데이터로 만들어졌다면 기술적으로 복원에 성공해도 새 배포의 의도와 어긋날 수 있다. 따라서 스냅샷의 생성 시점과 그때의 워크로드 버전을 결정 기록에 함께 남기고, 변경이 발생하면 새 기준 스냅샷이 필요한지 검토해야 한다. 이 역시 기능이 자동으로 보장하는 동기화가 아니라 팀이 정할 운영 규칙이다.

4. 스냅샷이 맞지 않는 경우와 대안 경로

반론·대안 경로

초기화가 병목처럼 보여도 스냅샷이 첫 해법이 아닐 수 있다. 새 복제본마다 필요한 입력이 크게 달라진다면 공유 가능한 준비 상태가 작다. 상태가 외부 시스템의 빠른 변경에 강하게 묶여 있다면, 오래된 메모리를 복원하는 복잡성이 시작 시간 이득보다 커질 수 있다. 또한 제품 도입 조건을 충족하지 못하거나 GKE Sandbox 제약이 워크로드와 맞지 않는 경우에는 지원되는 경로 자체가 아니다.

그럴 때는 모델 가중치·컨테이너 이미지를 미리 배치하거나, 초기화 과정을 더 작은 단계로 나누거나, 요청 경로의 동시성·큐잉·용량 계획을 조정하는 편이 낫다. 공식 블로그도 팟 스냅샷을 긴 초기화 단계가 있는 워크로드에 적용할 수 있다고 설명하지만, 이것이 모든 자동 확장 문제를 대체한다는 뜻은 아니다. 특히 외부 상태 동기화가 주된 병목이라면 팟 내부 상태를 빠르게 복원해도 전체 준비 시간은 기대만큼 줄지 않을 수 있다.

따라서 의사결정은 “콜드 스타트가 존재하는가”가 아니라 “동일한 준비 상태를 여러 번 복원해도 서비스 의미가 유지되는가”에서 시작해야 한다. 이 질문에 답하지 못했다면, 먼저 계측과 초기화 경로 분해가 필요하다.

5. 도입 전에 남길 짧은 결정 기록

결정 기록 양식

아래 양식은 GKE의 필수 설정이 아니라, 스냅샷 채택 여부와 복원 범위를 팀이 다시 확인할 수 있게 하는 편집부 제안이다. 실제 운영 정책·보안 검토·변경 승인 절차를 대체하지 않는다.

# Pod snapshot 도입 기록

- 워크로드와 버전: 
- 반복되는 초기화 단계와 준비 완료 신호: 
- 캡처 범위: whole-pod / rootfs-only / 선택 근거
- 스냅샷에 포함하면 안 되는 상태: 
- 저장 버킷·경로·접근 주체: 
- 트리거: workload / manual / 선택 근거
- PVC 또는 외부 상태의 시간차와 시험 결과: 
- 복원 성공의 관측 신호: 
- 보존 기한·그룹별 최대 개수·폐기 책임자: 
- 중단 또는 롤백 조건: 
- 재검토 날짜와 담당자:

스냅샷의 가치는 대기 시간을 짧게 만들 가능성에만 있지 않다. 준비된 실행 상태를 명시적인 정책과 기록 아래에 두면, 팀은 왜 이 상태를 복제해도 되는지, 어디에 남는지, 언제 폐기하는지를 설명할 수 있다. 반대로 그 설명이 없다면 빠른 복원은 관리되지 않은 상태 복제에 가까워진다. GKE Pod snapshots를 평가할 때 마지막 질문은 “얼마나 빨리 뜨는가”가 아니라 “복원한 상태의 범위와 책임을 우리가 검토했는가”여야 한다.

출처와 적용 범위

• GKE Pod snapshots 공식 발표 — 2026년 9월 21일 발표된 기능의 목적, CPU·GPU 메모리를 포함한 상태 저장·복원, 벤더 벤치마크의 범위를 확인했다.
• Pod snapshot CRD 레퍼런스 — 저장소 구성, 선택자, 범위, 트리거, 보존, 상태 필드를 확인했다.
• Agent Sandbox에서 Pod snapshots 저장·복원 — 지원 버전, Agent Sandbox 예시의 제약, 캡처·업로드 과정, 신원·권한 구성과 사용 사례를 확인했다.