Kafka vs SQS 비교하기

실무에서 담당하고 있는 서비스에서의 메시지 큐 서비스로 Kafka와 NiFi로 호출하는 SQS 두 서비스를 혼합해 사용하고 있다. 물론 서비스 내에서도 파트가 나뉘어져 있어 한 파트는 Kafka, 한 파트에서는 SQS를 사용하고 있긴 하다. 하지만 한 서비스에서 서로 다른 메시지 큐 서비스를 사용하고 있는게 작업자 입장에서는 관리하기도 불편하고, 신규 인력이 들어왔을 때도 서비스를 이해하기 어렵게 만드는 요인이라고 생각했다.

그래서 하나의 서비스로 통합하자고 의견을 내게 됐고, 그러면서 두 서비스 중 어느 서비스를 사용하는 것이 효과적일지 알아보며 두 서비스를 비교하게 되었다. 이번 포스팅은 Kafka와 SQS, 두 메시지 큐 서비스를 비교해보며 각 서비스가 어떤 특징과 이점을 갖는지 탐구하는 내용을 담아보았다.

주요 요점

• Kafka는 실시간 데이터 처리 및 분석에 최적화된 분산 이벤트 스트리밍 플랫폼으로, 높은 처리량을 위한 파티셔닝 모델과 효율적인 데이터 Consuming을 위한 Consumer 그룹이 특징
• SQS는 보안성과 확장성을 갖춘 호스팅 큐 시스템을 제공하며, 두 가지 유형의 큐(Standard 및 FIFO)를 통해 다양한 메시지 순서와 전달 요구 사항을 충족할 수 있음
• SQS와 Kafka는 메시징 모델, 확장성, 성능에서 크게 다르다. SQS는 단순한 애플리케이션에 적합한 Point-to-point 모델이며, Kafka는 실시간 대규모 데이터 작업을 처리하는 데 탁월한 Publish-Subscribe 모델을 사용한다.

Kafka에 대하여

Kafka 개요

Kafka는 고용량의 데이터를 처리하고 실시간 데이터 파이프라인과 스트리밍 애플리케이션을 구축할 수 있는 오픈 소스 분산 이벤트 스트림 처리 플랫폼이다. 높은 처리량, 내구성, 분산 환경을 위한 설계를 통해 대량의 실시간 데이터를 처리하는 시스템에 적합하다. Kafka의 분산 아키텍처는 확장 가능하고 결함에 견딜 수 있는 데이터 스트리밍 애플리케이션을 구축하는 데 탁월하다.

Kafka의 주요 기능

• 높은 처리량 : 고용량의 데이터를 효율적으로 처리하도록 설계됨
• 내구성과 신뢰성 : 데이터를 디스크에 저장하고 클러스터 내에서 복제하여 데이터 손실 방지
• 유연한 Consumer 그룹 : 복잡한 처리 파이프라인과 토픽 별 여러 Consumer 지원
• 확장성 및 성능 : 파티셔닝 및 복제는 확장성과 성능에 중요한 역할

Kafka의 주요 도입 이유

• 이벤트 중심 시스템 : 이벤트 중심 아키텍처 구현에 이상적임
• 실시간 데이터 처리 : 분석 및 모니터링 애플리케이션에 효과적임
• 로그 집계 : 다양한 서비스로부터 로그 수집 및 처리에 좋음

Kafka를 사용하기 유리한 / 불리한 경우

• 유리한 경우 : 높은 처리량 요구를 갖춘 대규모 분산 환경
• 불리한 경우 : 소규모 또는 단순한 애플리케이션에는 지나치게 복잡할 수 있음

SQS에 대하여

SQS 개요

SQS는 AWS에서 제공하는 완전 관리형 메시지 큐 서비스로, 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리하고 확장하도록 설계되었다. SQS는 큐 인프라 관리가 필요 없도록 하여 분산 소프트웨어 구성 요소 간의 효율적인 통신을 보장한다.

SQS 주요 기능

• 원천 관리형 서비스 : 메시징 인프라의 관리나 유지 보수가 필요 없음
• 확장성 : 수요를 처리하도록 자동으로 확장
• 두 가지 유형의 큐 : 최대 처리량을 위한 Standard 큐와 순서 보장을 위한 FIFO 큐
• AWS 통합 : 다른 AWS 서비스와 통합에 원활함

SQS의 주요 도입 이유

• 마이크로서비스 분리 : 시스템 내 구성 요소 분리를 통해 신뢰성 증가
• 서버리스 애플리케이션 : AWS 람다와 동작하여 서버리스 아키텍처 지원
• 단순 작업 큐 : 비동기 작업 관리

SQS를 사용하기 유리한 / 불리한 경우

• 유리한 경우 : 설정이 간단한 큐잉 애플리케이션인 경우
• 불리한 경우 : 복잡한 스트리밍이나 광범위한 시스템 제어가 필요한 경우

비교

Kafka와 SQS는 비동기 통신 및 확장성을 위해 설계되어 대량의 메시지를 효율적으로 처리하며 데이터 손실을 방지한다. 하지만 설정 복잡성에서 차이가 있으며, Kafka는 수동 구성에 반해 SQS는 완전 관리형 접근 방식을 제공한다.

Kafka는 고용량의 데이터를 효율적으로 처리, 긴 메시지 보존 및 다양한 데이터 형식 지원과 같은 기능을 제공하지만 수동 구성이 필요하다. SQS는 AWS 내에서 간단한 애플리케이션에 적합한 완전 관리형, 사용량 기반 요금제를 제공한다.
Kafka의 확장성은 브로커와 파티션에 의존하는데 반해, SQS는 메시지 볼륨에 따라 자동으로 조정된다.

결론

Kafka와 SQS 중 어느 것을 선택할지는 프로젝트에 따라 달라질 것으로 보인다. Kafka는 고용량, 실시간 데이터 스트리밍 및 복잡한 이벤트 처리 시스템에 이상적이다. 하지만 SQS는 단순한 큐잉 목적으로, 특히 AWS 생태계 내의 애플리케이션 및 관리형 서비스가 필요한 경우에 더 적합하다.
현재는 Kafka를 사용하는 파트, SQS를 사용하는 파트로 현 체제로 유지될 것으로 보인다. 하지만 추후에는 앞서 언급했던 관리의 용이함 및 애플리케이션의 확장성과 같은 이유로 Kafka로 통합하지 않을까 싶다.

참고 자료

SQS vs Kafka Comparison for Modern Developers
Kafka vs SQS - svix