메시지를 잃지 않으려면 (Delivery Guarantees)
어디까지 읽었는지 기록하는 시점을 언제로 잡느냐가 유실과 중복을 가릅니다. 처리하기 전에 먼저 기록하면 중간에 죽었을 때 그 메시지를 다시는 읽지 못하고(at-most-once), 처리한 뒤에 기록하면 죽었을 때 같은 메시지를 한 번 더 읽습니다(at-least-once). 카프카는 대개 후자를 택하고, 중복을 견디도록 처리 쪽을 멱등하게 만듭니다.
01 개념 한눈에 보기
Interactive Step-by-Step주문 네 건이 쌓여 있고, 컨슈머가 B를 읽으려는 참입니다. ▲ 가 B를 가리킵니다.
같은 상황을 순서만 바꿔 봅니다. ▲ 는 B를 가리키고 있습니다.
02 쉽게 이해하기
For Everyone택배를 받고 수령 도장을 언제 찍느냐와 같습니다. 열어 보기 전에 도장을 찍으면 물건이 잘못 왔어도 되돌릴 수 없고, 확인한 뒤 찍으면 도장을 찍기 직전에 쓰러졌을 때 다음 사람이 같은 상자를 또 확인합니다.
커밋을 먼저 하면 처리 도중 죽은 메시지는 영영 건너뜁니다(유실).
처리를 먼저 하면 커밋 전에 죽었을 때 재시작 후 같은 메시지를 다시 처리합니다(중복).
둘 다 없애려면 처리와 커밋이 하나의 트랜잭션이어야 하는데 비용이 큽니다.
그래서 실무에서는 at-least-once 를 택하고, 같은 메시지를 두 번 처리해도 결과가 같도록(멱등) 만드는 쪽이 일반적입니다.
- –결제·주문처럼 유실이 치명적인 처리 설계
- –중복 처리에 대비한 멱등 키 설계
- –커밋 주기와 장애 복구 시간의 트레이드오프 판단
03 자주 묻는 질문
FAQ메시지를 잃지 않으려면 (Delivery Guarantees)란 무엇인가요?+
어디까지 읽었는지 기록하는 시점을 언제로 잡느냐가 유실과 중복을 가릅니다. 처리하기 전에 먼저 기록하면 중간에 죽었을 때 그 메시지를 다시는 읽지 못하고(at-most-once), 처리한 뒤에 기록하면 죽었을 때 같은 메시지를 한 번 더 읽습니다(at-least-once). 카프카는 대개 후자를 택하고, 중복을 견디도록 처리 쪽을 멱등하게 만듭니다.
메시지를 잃지 않으려면 (Delivery Guarantees)은(는) 어디에 사용하나요?+
결제·주문처럼 유실이 치명적인 처리 설계, 중복 처리에 대비한 멱등 키 설계, 커밋 주기와 장애 복구 시간의 트레이드오프 판단
메시지를 잃지 않으려면 (Delivery Guarantees)를 쉽게 비유하면?+
택배를 받고 수령 도장을 언제 찍느냐와 같습니다. 열어 보기 전에 도장을 찍으면 물건이 잘못 왔어도 되돌릴 수 없고, 확인한 뒤 찍으면 도장을 찍기 직전에 쓰러졌을 때 다음 사람이 같은 상자를 또 확인합니다.