체크포인트와 세이브포인트
체크포인트와 세이브포인트 (Checkpoints vs. Savepoints)
개념적으로 Flink의 세이브포인트(savepoint)는 전통적인 데이터베이스 시스템에서 백업(backup)이 복구 로그(recovery log)와 다른 것과 유사하게 체크포인트(checkpoint)와 다릅니다.
출처: 문서
본문
개요 (Overview)
체크포인트의 주된 목적은 예기치 못한 작업(Job) 실패 시 복구 메커니즘을 제공하는 것입니다. 체크포인트의 생명주기는 Flink가 관리합니다. 즉, 체크포인트는 사용자 개입 없이 Flink가 생성·소유·해제합니다. 체크포인트는 자주 트리거되고 실패 복구에 의존하므로, 체크포인트 구현의 두 가지 주요 설계 목표는 ① 가능한 한 가볍게 생성하고 ② 가능한 한 빨리 복원하는 것입니다. 이러한 목표를 위한 최적화는 예를 들어 실행 시도 사이에 작업 코드가 변하지 않는다는 속성을 활용할 수 있습니다.
- 체크포인트는 애플리케이션이 사용자에 의해 종료되면 자동으로 삭제됩니다(체크포인트가 명시적으로 유지되도록 구성된 경우 제외).
- 체크포인트는 상태 백엔드별(네이티브) 데이터 포맷으로 저장됩니다(특정 백엔드에 따라 증분일 수 있음).
세이브포인트는 내부적으로 체크포인트와 동일한 메커니즘으로 생성되지만 개념적으로는 다르며, 생성과 복원이 조금 더 비쌀 수 있습니다. 세이브포인트의 설계는 특히 작업 변경과 관련해 이식성(portability)과 운영 유연성에 더 초점을 맞춥니다. 세이브포인트의 사용 사례는 계획된(planned) 수동 작업입니다. 예를 들어 Flink 버전 업데이트, 작업 그래프 변경 등이 있을 수 있습니다.
- 세이브포인트는 사용자만이 생성·소유·삭제합니다. 즉, Flink는 작업 종료 후나 복원 후에도 세이브포인트를 삭제하지 않습니다.
- 세이브포인트는 상태 백엔드와 무관한(표준, canonical) 포맷으로 저장됩니다. (참고: Flink 1.15부터 세이브포인트는 생성과 복원이 더 빠르지만 몇 가지 제한이 있는 백엔드별 네이티브 포맷으로도 저장할 수 있습니다.)
기능과 한계 (Capabilities and limitations)
다음 표는 다양한 세이브포인트와 체크포인트 유형의 기능과 한계를 개괄합니다.
- ✓ — Flink가 이 스냅샷 유형을 완전히 지원합니다.
- x — Flink가 이 스냅샷 유형을 지원하지 않습니다.
- ! — 이 연산은 현재 동작하지만 Flink가 공식적으로 지원을 보장하지 않으므로 어느 정도의 위험이 따릅니다.
| 연산 | Canonical Savepoint | Native Savepoint | Aligned Checkpoint | Unaligned Checkpoint |
|---|---|---|---|---|
| 상태 백엔드 변경 (State backend change) | ✓ | x | x | x |
| State Processor API (쓰기) | ✓ | x | x | x |
| State Processor API (읽기) | ✓ | ! | ! | x |
| 자족적이고 이동 가능 (Self-contained and relocatable) | ✓ | ✓ | x | x |
| 스키마 진화 (Schema evolution) | ✓ | ! | ! | ! |
| 임의 작업 업그레이드 (Arbitrary job upgrade) | ✓ | ✓ | ✓ | x |
| 비임의 작업 업그레이드 (Non-arbitrary job upgrade) | ✓ | ✓ | ✓ | ✓ |
| Flink 마이너 버전 업그레이드 (Flink minor version upgrade) | ✓ | ✓ | ✓ | x |
| Flink 버그/패치 버전 업그레이드 (Flink bug/patch version upgrade) | ✓ | ✓ | ✓ | ✓ |
| 재확장 (Rescaling) | ✓ | ✓ | ✓ | ✓ |
용어 설명:
- 상태 백엔드 변경 (State backend change) — 스냅샷을 찍을 때 사용한 것과 다른 State Backend를 구성하는 것.
- State Processor API (쓰기) — State Processor API를 통해 이 유형의 새 스냅샷을 만드는 능력.
- State Processor API (읽기) — State Processor API를 통해 기존 이 유형 스냅샷의 상태를 읽는 능력.
- 자족적이고 이동 가능 (Self-contained and relocatable) — 스냅샷 폴더 하나에 복구에 필요한 모든 것이 담겨 있고 다른 스냅샷에 의존하지 않아, 필요 시 다른 곳으로 쉽게 이동할 수 있다는 뜻.
- 스키마 진화 (Schema evolution) — 스키마 진화를 지원하는 직렬화기(예: POJO와 Avro 타입)를 사용하면 상태 데이터 타입을 변경할 수 있음.
- 임의 작업 업그레이드 (Arbitrary job upgrade) — 기존 연산자의 파티셔닝 타입(rescale, rebalance, map 등)이나 in-flight 레코드 타입이 바뀌어도 스냅샷을 복원할 수 있음.
- 비임의 작업 업그레이드 (Non-arbitrary job upgrade) — 작업 그래프 토폴로지와 in-flight 레코드 타입이 그대로라면 업데이트된 연산자로 스냅샷 복원이 가능함.
- Flink 마이너 버전 업그레이드 (Flink minor version upgrade) — 더 오래된 Flink 마이너 버전(1.x → 1.y)으로 찍은 스냅샷 복원.
- Flink 버그/패치 버전 업그레이드 (Flink bug/patch version upgrade) — 더 오래된 Flink 패치 버전(1.14.x → 1.14.y)으로 찍은 스냅샷 복원.
- 재확장 (Rescaling) — 스냅샷 생성 당시와 다른 병렬도(parallelism)로 스냅샷을 복원.