# Chandy-Lamport에서 Asynchronous Barrier Snapshotting까지

> 분산 스냅샷의 고전 Chandy-Lamport가 Flink의 Asynchronous Barrier Snapshotting과 RisingWave의 epoch barrier로 이어지는 흐름을 정리한 학습 노트입니다.

- Canonical URL: https://jerrylog.dev/ko/blog/chandy-lamport-to-abs
- Date: 2026-10-17
- Author: Jerry
- Language: ko
- Topic: 소프트웨어 엔지니어링 / 데이터 엔지니어링
- Tags: distributed-systems, stream-processing, flink, risingwave, checkpoint

---

스트림 처리 엔진은 장애가 나도 "정확히 한 번" 처리한 것처럼 결과를 복구해야 합니다. 그러려면 계속 흐르는 시스템 전체의 상태를 어느 한 시점에 일관되게 찍어 둘 수 있어야 합니다. 멈추지 않고 돌아가는 분산 시스템에서, 전체 상태를 어떻게 한 장의 사진처럼 찍을 수 있을까요?

## 일관된 스냅샷 문제

- 각 프로세스가 각자 상태를 저장하면 왜 틀리는가: 송금 예시에서 돈이 사라지거나 두 번 세어지는 경우
- consistent cut의 정의: 받은 메시지는 보낸 기록이 있어야 한다
- 전역 시계를 쓸 수 없는 이유

## Chandy-Lamport 알고리즘 (1985)

- 전제: 채널은 FIFO이고 메시지를 잃지 않는다 (Chandy & Lamport, 1985)
- marker 규칙
  - 시작 프로세스는 자기 상태를 기록하고 모든 출력 채널로 marker를 보낸다
  - marker를 처음 받은 프로세스는 자기 상태를 기록하고, 그 채널의 상태를 비어 있음으로 기록한 뒤 marker를 보낸다
  - 이미 기록한 프로세스는 marker가 올 때까지 그 채널로 들어온 메시지를 채널 상태로 기록한다
- 왜 채널 상태까지 기록해야 하는가: 이동 중인(in-flight) 메시지
- 시스템을 멈추지 않는다는 점

## 스트림 처리로 옮기면 생기는 문제

- 데이터플로는 프로세스가 아니라 operator의 DAG다
- 채널 상태를 그대로 저장하면 in-flight 레코드가 많아 스냅샷이 커진다

## Asynchronous Barrier Snapshotting (Flink, 2015)

## 참고문헌

- Chandy, K. M., & Lamport, L. (1985). Distributed snapshots: Determining global states of distributed systems. ACM Transactions on Computer Systems, 3(1), 63–75. https://doi.org/10.1145/214451.214456

*이 글은 아직 작성중입니다. 완성되면 이어서 공개합니다.*