N° 01 — 목록
'Exactly-Once' (2)
-
Software Architecture/Distributed SystemsDistributed Systems - 08. 멱등성·정확히 한 번
멱등성과 정확히 한 번 — "exactly-once" 함정 파헤치기2020년 한 결제 시스템에서 같은 결제가 두 번 처리된 사고가 터졌다. 사용자는 한 번 결제했는데, 계좌에서 두 번 빠져나갔다. 조사해보니 — 네트워크 지연으로 결제 서비스가 응답을 못 받은 클라이언트가 재시도했고, 결제 서비스는 같은 요청을 두 번 처리했다. "이런 건 왜 생기나. exactly-once 보장하면 되지 않나?"라는 질문이 자연스럽다. 이 질문에 대한 답이 이 글의 핵심이다. 결론부터 말하면 — end-to-end exactly-once는 매우 어렵고, 대부분 at-least-once + 멱등성으로 달성한다. "exactly-once"를 마케팅 문구처럼 쓰는 시스템은 사실 이 조합을 숨기는 것이다.비유로 감 잡기 — 우편..
-
Data & Platform/Event StreamingKafka - 08. delivery semantics
"Kafka는 exactly-once인가요" — 질문이 틀렸다"Kafka는 exactly-once를 보장하나요?" — Kafka를 배우면 누구나 받는 질문이다. 답은 "무엇의 exactly-once인지에 따라 다르다"다. 단일 partition 쓰기(idempotent)는 exactly-once다. consume-process-produce 패턴(EOS)도 exactly-once다. 하지만 시스템 외부(DB)까지는 아니다. 이 질문이 틀린 이유는 "exactly-once"를 메시지 자체의 마법 같은 속성으로 생각하기 때문이다. 실제로는 "출력 메시지와 consumer offset을 한 트랜잭션으로 묶어 원자 commit"하는 설계 패턴의 결과다.전달 보장은 at-most-once, at-least-onc..