Exactly-once?
주변에서 Jay Kreps 의 Kafka exactly-once 관련 작성한 글이 돌아다니길래 한 번 훑어 봤다. (영어 실력이 미천해서 정독은 정말 시간을 많이 들여야 되어서… 일단 먼저 훑어봄)
새로운 방법이라도 나온 건가 했는데, 일단 훑어본 걸로는 현재 사용되고 있는 방법을 사용하고 있는 듯 하다. 디테일에 대한 부분은 첫 링크의 Confluent 블로그 글이나 두번째 링크의 KIP 위키 페이지를 보는 것이 더 나아 보인다.
멱등성을 이용하거나 트랜잭션을 이용한 exactly-once 는 Storm trident 때부터 지원한 고전적인 방법이다.
단 한 번 보내는 게 아니라 여러 번 보내되 단 한 번의 시도만 유효하게 만드는 방법이 사용되기 때문에 exactly-once 가 아니라 exactly-once semantic 이라는 주장이 많이 있다. 일반적으로 데이터를 기록하는 연산이 멱등성을 가지고 있거나 트랜잭션을 지원해야 하는 제약사항이 있다.
다른 방법으로 deduplicating 이라고 해서 처리된 메시지의 unique key 를 보관하고 한 번만 처리하는 방법도 사용되고 있다. (Google MillWheel)
https://blog.acolyer.org/…/millwheel-fault-tolerant-stream…/
Storage 로써의 Kafka 는 side-effect 를 고민하지 않아도 되지만, Distributed computation framework 입장에서 보면 state 의 저장만 exactly-once 로 처리되는 것이지 전체 파이프라인이 한 번만 처리되는 게 아니기 때문에 중간 연산에 side-effect 가 없어야 유저가 기대하는 exactly-once 처럼 동작하게 된다.
exactly-once 는 결국 제약사항을 충족해야 달성할 수 있는 건데 정작 홍보할 때는 제약사항은 잘 언급되지 않는다. 그게 반대론자(?) 들이 exactly-once 에 대한 주장을 공격하는 이유 중 하나가 되기도 한다.
