비동기 처리를 도입하고 나서 이런 생각을 해본 적 있으신가요?
"이제 API에서 이벤트만 발행하면 끝이지. 워커가 알아서 처리하겠지."
맞습니다. 처음에는 그렇게 동작합니다.
그런데 서비스가 커지면서 워커 인스턴스를 한 대에서 두 대, 세 대로 늘리는 순간 — 조용히 이상한 일이 벌어지기 시작합니다.
사용자가 분명히 최신 내용으로 수정했는데, DB에는 이전 값이 저장되어 있습니다. 로그를 봐도 에러는 없습니다. 이벤트도 정상적으로 발행됐습니다. 워커도 정상적으로 처리했습니다.
그런데 왜 데이터가 잘못됐을까요?
이 글은 그 원인과, 상황에 따라 어떤 해결책을 선택해야 하는지를 다룹니다.
어떤 메시지 브로커를 사용하든 워커를 여러 대 운영하는 이벤트 기반 환경이라면 눈여겨 보실 내용입니다.
사용자가 채팅 메시지를 작성하고 연속으로 두 번 수정합니다.
① 처음 작성: "ABC"
② 첫 번째 수정: "AB" (오타를 고침)
③ 두 번째 수정: "ABC123" (내용 추가)
사용자 화면에는 최종적으로 "ABC123" 이 보입니다. 당연히 DB에도 "ABC123" 이 저장되어 있겠죠.
그런데 나중에 DB를 확인해보니 "AB" 가 저장되어 있습니다.
에러 로그도 없습니다. 이벤트도 정상적으로 발행됐습니다. 워커도 정상적으로 처리했습니다.
왜 이런 일이 생겼을까요?
워커를 2대로 늘린 순간부터 이 문제가 시작됐습니다. 메시지 브로커는 로드 밸런싱으로 이벤트를 각각 다른 워커로 배달합니다.