debzium /
kafka outbox pattern, Transactional outbox pattern
분산시스템에서 2번 write 되는 상황을 해결해준다.
예를 들어, 하나의 작업(operation) 이 ‘db write opertion’ 과 ‘message notification’ 을 갖고 있는 작업이라면, db 에 한번, message 쪽에 이렇게 두번의 write 를 해야 한다.
이 경우 failure(실패)가 날 때 data 의 일관성이 깨진다.(inconsistent), 그래서 이 작업은 atomically 하게 이뤄져야 한다.
예를 들어보자, 만약 가입을 완료하면, 가입완료 email을 보내는 작업이 있다고 하자.
- user table에 row를 만들고,
- email worker에게 email 을 보내라고 한다.(email event)
우리는 user 가 생성됐다면, email 이 나갔다고 확신하고 싶지만, 위 2개중 1개가 실패하면 data 가 inconsistent 하게 된다.
1. DB table 을 이용
outbox table 을 하나 만들고, email event 를 저장한다.(timestamp, sequence number), 그리고 이 table 의 변동사항을 보고, kafka event 를 보내는 것이다.(당연히, 이 작업을 하는 worker가 필요하다.)
2. Change Data Capture(CDC)를 이용하는 방법
- Implementing the Outbox Pattern - DZone
- Outbox with Debezium and Kafka — The hidden challenges | by Victor Perepelitsky | Yotpo Engineering | Medium
여긴 outbox 에 표시를 하고, 그러면 그것이 transaction 이 log 에 기록되고, 이 log 의 Change Data Capture(CDC)를 보고, kafak event 를 보내는 방법을 취한다.
다만 위 2개의 글에서 이야기하는 방식은 ref.1 에서 이야기하는 Using CDC 와 조금 차이를 보인다.
ref.1 에서는 user table 의 row 가 만들어지면, 그것에 대한 binary log 등을 CDC로 사용해서 kafka 에 event 를 보내도록 한다. 하지만 위의 2개의 글에서는 user table 에 insert 가 끝나고, outbox table 에 다시 insert 를 하게 하고, 그 outbox table 의 CDC 를 이용해서 kafka를 보낸다.
둘다 틀린 접근은 아니다. db 에 기록을 남기느냐 마느냐는 선택의 문제인듯 하다.
kafka 에 send 를 확인하고 나서, user table 을 insert 하는 방식
’kafka 에 send 를 확인하고 나서, user table 을 insert 하는 방식’은 어떨까 ?
이것의 문제는 kafka send 가 성공하고나서, user table의 insert 가 실패하는 경우다. 이 경우 rollback 이 불가능하다.
댓글 없음:
댓글 쓰기