스트림 처리는 사건이 발생한 시간, 시스템이 그 사건을 본 시간, 아직 오지 않은 사건이 없다고 추정하는 시간을 서로 다른 상태로 다룹니다. watermark와 checkpoint를 함께 이해해야 늦은 데이터의 정정과 장애 복구를 같은 집계의 두 문제로 섞지 않게 됩니다.
늦은 사건의 대기 기한과 정정 정책
10:00~10:01의 매출을 집계하는데 10:00:50 사건이 10:01:20에 도착할 수 있습니다. event time은 사건에 부여한 발생 시각이고 processing time은 실제 처리 시각입니다. 네트워크·재시도·clock skew 때문에 둘은 다릅니다.
watermark는 특정 시각 이전 사건이 충분히 도착했다고 보는 진행 추정·source 계약입니다. 늦은 사건이 물리적으로 더는 올 수 없다는 증명이 아닙니다. window의 잠정·확정·정정 정책을 별도로 정합니다.
Watermark와 Allowed Lateness의 기준
예를 들어 watermark가 window end를 통과하면 잠정 결과를 내고 end+30초를 통과하면 state cleanup·최종판을 만드는 정책을 택할 수 있습니다. 이는 처리 벽시계로 정확히 30초 뒤라는 뜻이 아니며 실제 엔진의 trigger·allowed lateness·watermark 의미를 확인해야 합니다.
| 상황 | 정책 선택 | 비용 |
|---|---|---|
| 늦지만 허용 창 안 | 집계 갱신·추가 결과 | 중복·정정 수신 처리 |
| 창 밖 지연 | drop·side output·정정판 | 손실 또는 보정 책임 |
| 유휴 source | watermark에서 제외하는 idle 정책 | 복귀 후 오래된 사건 처리 |
| 미래 timestamp | 허용 범위 검증·격리 | 잘못된 조기 마감 방지 |
partition별 watermark의 최소를 사용하면 하나의 멈춘 source가 전체 진행을 막을 수 있습니다. idle로 제외하면 결과는 빨라지지만 그 source가 나중 옛 사건을 보내는 경우를 처리해야 합니다. 미래 시각 입력으로 모든 window를 조기에 닫지 않도록 출처·범위를 검증합니다.
그림을 글로 읽기
- event time이 있는 사건
- 지연·역순 도착
- window state·watermark 판단
- 잠정·확정·정정 버전 출력
- event time이 있는 사건 → 지연·역순 도착: 전달 시간
- 지연·역순 도착 → window state·watermark 판단: ID·시각 검증
- window state·watermark 판단 → 잠정·확정·정정 버전 출력: 마감 정책
Checkpoint 상태와 입력 위치의 복구 경계
상태 합계가 offset 100까지 반영됐는데 복구 위치를 90으로 저장하면 91~100을 다시 더할 수 있습니다. 상태는 90인데 입력 위치가 100이면 효과를 건너뜁니다. state snapshot과 partition별 다음 입력 위치를 일관된 복구 기준으로 저장해야 합니다.
엔진이 barrier를 사용한다면 각 입력 경계가 state snapshot과 함께 처리될 때까지 맞추는(aligned) 방식인지, 진행 중인 channel state까지 함께 저장하는(unaligned) 방식인지에 따라 복구 때 필요한 입력이 달라집니다. 어떤 엔진이 barrier·channel state·aligned·unaligned snapshot을 지원하는지는 구현 계약을 확인해야 하며, source offset을 모든 partition을 관통하는 하나의 시간 번호로 취급하면 안 됩니다.
복구 기준에는 window state·timer·dedup뿐 아니라 serializer·계산 버전의 호환 정보도 포함될 수 있으므로, 하나라도 빠졌을 때 재시작 결과가 같은지 확인해야 합니다.
복구 예를 수치로 쓰면, snapshot의 합계에는 offset 100까지 반영됐는데 재개 위치만 91로 저장되면 91100을 다시 더해 중복됩니다. 반대로 합계에는 90까지만 반영됐는데 재개 위치가 101이면 91100의 효과를 빠뜨립니다. 따라서 재시작 후 기대 결과는 “state와 다음 offset이 같은 처리 경계를 가리키는가”로 판정해야 합니다.
내부 Exactly-once와 외부 Sink의 경계
예를 들어 checkpoint 직후 작업이 외부 DB에 쓰거나 HTTP 결제를 보냈는데 프로세스가 멈추면, state와 입력 위치는 복구돼도 그 외부 효과를 다시 실행할 수 있습니다. transactional sink를 쓰거나, sink가 지원한다면 같은 효과를 식별하는 stable effect key를 함께 보내고, outbox나 결과 조회처럼 해당 sink의 commit 경계에 맞는 방법을 써야 합니다. 그래서 checkpoint 성공만으로 메일·HTTP 결제·외부 DB 효과가 정확히 한 번 적용됐다고 결론 내릴 수 없습니다.
checkpoint가 자주 실패하면 정상 처리율이 높아도 재작업 구간이 커집니다. 마지막 성공 나이·state 크기·저장 대역폭·checkpoint 시간·source 보관 범위를 관찰합니다. 코드·state serializer를 바꿀 때 old snapshot 복구와 rollback이 가능한지도 시험합니다. 필요한 입력이 retention 밖이면 새 원본 snapshot·대사가 필요합니다.
정기 작업의 예정 회차와 실제 실행
한 시간 멈춘 scheduler가 매 10분 회차를 모두 보충해야 하는 정산과 최신 cache 갱신 한 번이면 되는 작업은 다릅니다. (job_type, 예정 회차, scope) 같은 논리 키로 같은 회차 중복을 막고, 미실행·보충·건너뜀·진행·완료를 기록합니다.
밀린 모든 회차를 한꺼번에 시작하면 복구 중 정상 요청을 굶길 수 있어 별도 동시성·대기·우선순위 예산을 둡니다. 이전 실행이 아직 남았을 때 skip·queue·중첩 허용 중 정책을 정합니다. lease 만료는 옛 실행 종료가 아니므로 효과·완료에 generation·멱등 키를 적용합니다.
현지 cron은 DST의 없는 시각·중복 시각과 timezone·캘린더 규칙을 포함해야 합니다. 예정 시각의 ID와 로컬 elapsed timeout을 구분하고 wall-clock jump로 같은 회차가 두 번 생기지 않게 합니다.
복구 결과와 마감 이후 정정의 대조
역순·허용 창 안팎·idle 복귀·미래 시각·snapshot 중단·sink 성공 후 실패·중복 scheduler를 합성 입력으로 시험합니다. 합계·입력 위치·출력 version·원장 효과·예정 회차별 결과를 대조합니다. 현재 작업에서는 스트림 엔진이나 실제 정기 작업 복구를 실행하지 않았습니다. 본문은 시간과 상태 복구의 설계 설명입니다.