Kafka를 사용하는 이유
1. 비동기 처리가 가능한 메세징 플랫폼
주문 시스템처럼 여러 단계(주문 접수, 배송, 알림, 결제 등)가 연계된 복잡한 로직을 모두 동기 트랜잭션으로 처리하면, 중간 단계(예: 배송, 알림 등)에서 장애나 지연이 발생할 때 전체 주문 흐름이 느려지고, 클라이언트는 응답을 기다리며 UX도 나빠집니다. Kafka 같은 메시지 브로커를 도입하면 ‘주문 접수’만 빠르게 처리하고 곧바로 클라이언트에 응답을 반환, 나머지(배송, 알림, 결제 등)는 각자의 Consumer가 독립적으로 비동기 처리하게 할 수 있습니다. 이렇게 하면 서비스의 UX와 안정성이 크게 높아지고, 각 단계별 서비스도 확장성과 장애 격리에 유리하게 구축할 수 있습니다.
2. 느슨한 결합으로 확장성 있는 플랫폼
Kafka는 단순한 비동기 지원 도구와는 다르게 확장성과 느슨한 결합성을 제공합니다.
예를 들어, WebClient는 Java에서 HTTP 비동기 통신을 지원하지만, HTTP 비동기 통신은 요청-응답 주체가 1:1로 강하게 결합돼 있고한 번 보낸 요청/응답은 다른 소비자가 소비할 수 없습니다. 반면 Kafka는 이벤트를 발행하고 나서 여러 Consumer가 원하는 시점에, 원하는 방식으로 각자 독립적으로 메시지를 소비할 수 있으므로 발행자와 소비자 간의 결합도가 낮아지고, 시스템 확장성도 획기적으로 높아집니다.
3. 안전성 있는 예외처리
발행자와 소비자가 강하게 결합이 되어 있지 않기 때문에 발행자는 소비자가 원하는 기능을 제대로 소비했는지 확인 할 길이 없다. 이러한 기능은 확장성에는 장점이지만 안정성에는 약점이라고 할 수 있다.
Kafka는 이런 약점도 여러가지 기능을 통해 보완한다. 이런 예를 생각해보자. 주문 시스템에서 발행자는 주문 이벤트를 발행하면 알림 소비저가 알림 메세지를 보내는데 컨슈머에서 호출한 알림 API가 예상치 못한 이유로 알림을 보내지 못할 수가 있다.
이런 문제 상황을 해결 할 수 있는 방법으로 간단하게 Spring Kafka의 재시도/백오프 설정(yml/코드로 설정 가능)으로 요청 실패시 반복 횟수를 지정해서 다시 요청을 하도록 설정할 수 있다. 요청 횟수를 초과해서 시도했음에도 알림이 성공하지 못할 수가 있는데 이럴경우에는 DLQ 패턴으로 지정된 횟수 초과실패시 별도의 DLQ토픽으로 자동으로 이동하고 운영자가 직접 DLQ토픽에서 메세지를 조회해서 별도의 컨슈머로 수동/자동 재처리를 통해 메세지를 소비할 수 있다.
마지막으로 오프셋 수동관리를 통해 해결할 수 있는데(기본은 자동 커밋) 세밀한 관리를 위해 ”메세지 처리 성공시만 오프셋 커밋 적용“을 해서 실패하면 오프셋 그대로 다음에 소비/재시도 가능하게 해결할 수 있다.
