REST API vs Kafka 기반 메시지 큐: 성능과 메시지 유실 고려

1. 발주 시스템 개편 사례에서 얻은 생각

 

최근 올리브영 기술 블로그에서 발주 서비스 개편 사례를 읽었다. 기존에는 REST API 기반으로 동작하던 시스템이 Kafka 기반 메시지 큐로 전환되면서 성능과 안정성이 크게 개선되었다는 내용이었다. 이 글을 보면서 왜 기존의 REST API 방식으로는 한계가 있었는지, 그리고 Kafka가 어떤 특성을 통해 더 나은 성능을 보장했는지를 다시 생각하게 되었다.

 

이에 따라 본 포스팅에서는 REST API와 Kafka 메시지 큐의 구조적 차이를 정리하고, Kafka를 사용할 때 고려해야 할 메시지 유실 문제와 전달 보장 전략에 대해서도 함께 살펴보고자 한다.

 

 

2. REST API의 한계

2.1 요청-응답 블로킹 구조

REST API는 요청을 보내면 서버가 처리 후 응답을 줄 때까지 클라이언트가 대기해야 한다. 서비스가 복잡해지고 처리 시간이 늘어나면, 이 대기 시간이 곧 병목이 된다. 예를 들어 대량 발주 시스템에서는 요청이 쌓이면서 서버가 동시에 많은 작업을 처리하지 못하고 지연이 발생한다.

 

2.2 확장성 문제

트래픽이 늘어나면 서버를 수평 확장해야 한다. 하지만 REST API 구조에서는 로드 밸런싱, 세션 관리, 장애 전파를 함께 고려해야 하므로 관리 복잡도가 커진다. 서비스 간 의존성이 강하기 때문에 한 지점의 장애가 전체 시스템으로 전파될 수 있다.

 

2.3 실시간 처리의 한계

REST API는 대체로 요청 단위 트랜잭션 처리에 적합하다. 반면, 이벤트가 초당 수천~수만 건씩 발생하는 경우에는 실시간 스트리밍 처리에 한계가 있다.

 

 

3. Kafka가 제공하는 성능상의 이점

 

3.1 비동기 이벤트 스트리밍

Kafka는 퍼블리셔(Producer)가 메시지를 브로커에 보내면, 컨슈머(Consumer)가 이를 구독해 가져가는 방식이다. 이 과정은 요청과 응답이 동시에 묶이지 않으므로, 처리 속도가 빨라지고 유연성이 커진다.

 

3.2 높은 처리량과 낮은 지연

Kafka는 메시지를 배치 단위로 전송하고, 디스크에 순차 기록(append-only log)한다. 이 구조는 랜덤 접근보다 훨씬 빠르고 안정적이다. 실제 사례에서는 REST API 대비 지연 시간이 80% 줄어든 보고도 있다.

 

3.3 수평 확장성

Kafka는 데이터를 파티션 단위로 나누어 여러 브로커에 분산 저장한다. 컨슈머 그룹은 각 파티션을 병렬로 읽을 수 있어, 트래픽이 급증해도 브로커와 컨슈머 수를 늘려 쉽게 확장할 수 있다.

 

3.4 데이터 재처리 가능

REST API는 요청이 끝나면 결과를 되돌리기 어렵다. 반면 Kafka는 로그를 브로커에 일정 기간 보관하므로, 여러 컨슈머가 같은 메시지를 반복 소비하거나 과거 데이터를 다시 처리할 수 있다.

 

 

4. Kafka의 단점: 메시지 유실과 중복 문제

Kafka는 성능이 뛰어나지만, 메시지가 전송 도중 유실되거나 중복되는 문제가 발생할 수 있다. 이 때문에 전달 보장(Delivery Semantics) 개념이 중요하다.

 

전달 방식	설명	장점	단점
At-most-once	메시지를 한 번만 전송하고 확인하지 않는다	속도가 빠르다	메시지 유실 가능
At-least-once	ACK을 받고 실패 시 재시도한다	메시지 유실 없음	메시지 중복 가능
Exactly-once	Kafka 트랜잭션과 idempotent 프로듀서를 활용한다	유실·중복 모두 방지	설정이 복잡하고 성능 부담 존재

• 중복 허용 가능 서비스는 at-least-once를 적용하고, 컨슈머 단에서 중복 제거 로직(idempotency)을 구현하는 것이 현실적이다.
• 정확한 처리 보장 필요 서비스는 exactly-once를 고려해야 한다. Kafka는 트랜잭션 ID를 기반으로 메시지 처리와 오프셋 커밋을 원자적으로 묶어, 중복과 유실을 모두 막을 수 있다. 다만 이 경우 성능은 다소 떨어진다.

 

5. 운영 시 고려사항

Kafka를 안정적으로 운영하려면 몇 가지 핵심 요소를 반드시 고려해야 한다.

1. 보안: TLS/SSL 암호화, SASL 인증, ACL 권한 제어를 적용해야 한다. 그렇지 않으면 데이터 유출 위험이 크다.
2. 장애 대응: 브로커 다운, 네트워크 단절, 디스크 손상 등 다양한 장애 상황에서 메시지가 어떻게 처리되는지 혼돈 테스트를 수행해야 한다.
3. 파라미터 튜닝: acks, retries, max.in.flight.requests 값을 조정해 성능과 안정성을 균형 있게 유지해야 한다.
4. 모니터링: 브로커 상태, 오프셋 지연, 컨슈머 처리 속도 등을 꾸준히 추적해야 한다.

 

 

6. 결론

• REST API는 단순하고 친숙하지만, 대규모 이벤트 처리에는 한계가 있다.
• Kafka는 비동기 이벤트 스트리밍 구조로 설계되어 높은 처리량, 낮은 지연, 뛰어난 확장성을 제공한다.
• 하지만 메시지 유실과 중복 가능성이 있기 때문에, 전달 보장 전략을 설계 단계에서 명확히 선택해야 한다.
• 운영 단계에서는 보안, 장애 대응, 모니터링을 반드시 고려해야 안정적으로 운용할 수 있다.

 

따라서 REST API에서 Kafka로 전환하면 확실한 성능 향상을 얻을 수 있지만, 단순한 성능 비교만으로는 충분하지 않다. 메시지 전달 보장 수준을 서비스 특성에 맞게 설정하고, 운영 경험을 통해 안정성을 보강해야 한다.