AWS MSK 벤치마킹

AWS MSK(Amazon Managed Streaming for Apache Kafka)는 이름에서 알 수 있듯이 Apache Kafka를 AWS에서 완전관리형(Managed Service)으로 제공하는 서비스다. 이 MSK를 RabbitMQ, AWS SQS, AWS Kinesis, Apache Kafka 플랫폼들과 비교하여 벤치마킹을 해본다.

메시지 큐와 메시지 스트리밍

간단 설명

유형	플랫폼	요약
이벤트 스트리밍	Apache Kafka, AWS MSK, AWS Kinesis	불변의 분산 커밋 로그 기반. 고처리량, 데이터 재처리 가능, 다중 컨슈머 지원.
메시지 큐	AWS SQS	메시지를 저장하고 소비 후 삭제. 높은 확장성, 서버리스 운영, 메시지 순서 보장 선택적.
메시지 브로커	RabbitMQ	Exchange와 Binding을 통한 복잡한 라우팅 및 중개. 전통적인 큐 모델, 낮은 지연 시간.

이벤트 스트리밍 플랫폼

1. 데이터의 지속적인 흐름과 기록에 포커스
2. 대규모의 연속적인 데이터를 실시간으로 처리하는 데 적합
3. 데이터를 장기간 보존하여 여러 애플리케이션이 독립적으로 동일한 데이터를 소비하고 과거 데이터를 재처리할 때 용이

메시지 큐

1. 메시지의 일회성 전달과 작업 분배에 포커스
2. 단순한 작업 분배 및 워크플로우 분리에 용이

운영 리소스 트레이드오프

1. AWS SQS: 완전히 서버리스 형태로 제공되며, 인프라 설정 및 유지 관리가 전혀 필요 없다. 상기 5개 플랫폼 중 가장 낮은 운영 오버헤드와 리소스를 자랑한다.
2. AWS Kinesis: 완전 관리형 서비스로, 인프라가 AWS에 의해 완전히 추상화된다. 최근에는 Kinesis에 On-Demand의 도입으로 샤드 관리가 제거되었기 때문에 용량 관리에 대한 고민이 완전히 해소되었다.
3. AWS MSK: Apache Kafka의 관리형 버전으로, 브로커 인프라의 관리(패치, 고가용성 등)를 AWS에 위임한다. 사용자는 Kafka 구성 및 애플리케이션 배포에만 집중할 수 있어, 자체 호스팅보다 운영 리소스가 절감된다.
4. Apache Kafka / RabbitMQ (Self-Managed): 높은 유연성을 제공하지만, 클러스터링, 메타데이터 관리(Zookeeper), 확장, 패치 적용, 장애 복구 등 상당한 운영 담당자와 인프라 관리가 필요하다.

각 플랫폼 아키텍처 및 분석

1. AWS SQS

AWS SQS는 컨슈머가 큐를 능동적으로 확인하여 메시지를 가져가는 Polling 방식 기반

Standard 큐와 FIFO 큐의 역할 분리

SQS는 다양한 요구사항에 대응하기 위해 두 가지 유형의 큐를 제공한다.

1. Standard 큐: 높은 처리량을 목표로 하며, 메시지는 최소 한 번 이상 전달되지만, 메시지 순서는 최선 노력으로만 보장된다. 즉, 중복 메시지 처리에 대한 멱등성을 컨슈머 애플리케이션에서 필수로 구현해야한다.
2. FIFO 큐: 메시지의 엄격한 순서 보장과 단일 전달 보장을 제공한다. 이는 Standard 큐에 비해서 상대적으로 낮은 처리량을 가지지만, 순서가 민감한 거래나 주문 처리 시스템에 적합하다.

Visibility Timeout

컨슈머가 큐에서 메시지를 가져가면, 해당 메시지는 즉시 삭제되지 않고 설정된 Visibility Timeout 시간(최대 12시간) 동안 다른 컨슈머가 볼 수 없도록 숨겨진다. RabbitMQ의 경우에는, 컨슈머가 메시지를 ack 하기 전에 실패하면 메시지가 즉시 큐로 반환되지만, SQS의 Visibility Timeout은 특정 호출자에 묶여 있지 않다. 이 설계는 장시간 실행되는 작업을 처리할 때, 작업자가 중단되더라도 외부 상태 관리 서비스 없이 다른 작업자가 나중에 작업을 이어받아 완료할 수 있게 할 수 있다. 이는 분산 시스템에서 장기 실행 작업을 처리하는 아키텍처를 단순화할 때 도움을 줄 수 있다.

2. Apache Kafka / AWS MSK

Apache Kafka는 고처리량과 실시간 분석에 특화된 분산 이벤트 스트리밍 플랫폼이다. 핵심은 토픽과 파티션으로 구성된 불변의 커밋 로그 구조다.

• 확장성 및 순서: 데이터는 파티션에 분산 저장되며, 파티션 내에서만 순서가 보장된다. 시스템의 확장성은 파티션 수에 따라 증가한다.
• 데이터 보존 및 재처리: 메시지는 컨슈머가 소비한 후에도 삭제되지 않고 구성된 기간동안 보존된다. 이는 여러 컨슈머가 독립적으로 데이터를 처리하고, 필요한 경우 과거 데이터를 재처리할 수 있도록 지원하며, 이벤트 소싱 아키텍처에 도입하기 적합하다.
• 메시지 전달 모델: Kafka는 컨슈머의 오프셋을 기반으로 데이터를 능동적으로 가져가는 Polling 방식을 사용한다.

MSK와 Self-Managed Kafka의 운영적 차이

자체 관리형 Apache Kafka는 하이브리드 또는 멀티 클라우드 환경에서 최고의 유연성을 제공하지만, Zookeeper 관리, 브로커 인프라 설정, 확장, 패치 등의 운영 복잡도가 매우 높다. AWS MSK는 이러한 운영 오버헤드를 AWS가 관리하면서도 Kafka API와의 100% 호환성을 유지하여 마이그레이션 및 AWS 통합에 유리하다.

3. AWS Kinesis

Kinesis는 Kafka와 유사하게 불변 이벤트 로그를 핵심으로 하며, AWS 환경에 깊이 통합된 실시간 데이터 스트리밍 솔루션이다.

• 확장 단위: Kinesis는 샤드를 확장 단위로 사용하며, 각 샤드는 초당 1MB 또는 1,000 레코드의 쓰기 용량을 가진다. 샤드 내에서는 순서가 보장되며, 동일한 파티션 키를 가진 레코드는 순서대로 처리된다.
• 내구성 및 보존: Kinesis는 데이터를 3개의 가용 영역에 동기적으로 복제하여 높은 가용성을 보장하고 데이터 보존 기간은 최대 365일까지 설정이 가능하다.
• AWS 통합: Kinesis는 AWS Lambda, Kinesis Data Analytics, Kinesis Firehose 등 다른 AWS 서비스와의 높은 호환성을 제공하여 AWS 중심의 실시간 분석 파이프라인 구축에 유리하다.

Kinesis On-Demand의 역할 변화

Kinesis는 과거에 샤드 관리가 필요하여 운영 복잡성이 존재했지만, Kinesis On-Demand 모드의 도입으로 이러한 복잡성이 제거되었다. On-Demand 모드는 용량 관리가 필요 없는 서버리스 모델을 제공하며, 최대 10 GBps의 쓰기 처리량과 200 GBps의 읽기 처리량까지 자동으로 확장된다.(Auto Scaling)

4. RabbitMQ

RabbitMQ는 AMQP, MQTT, STOMP 등 다양한 프로토콜을 지원하는 전통적인 메시지 브로커다. 주요 아키텍처 강점은 Exchange와 Binding을 이용한 복잡하고 유연한 메시지 라우팅이다.

• 메시지 전달 모델: Exchange에 메시지가 전달되면, 정의된 Binding 규칙에 따라 큐로 라우팅되고, 컨슈머에게 메시지가 능동적으로 전달되는 Push 기반이다. 이 Push 기반 방식은 일반적으로 지연 시간이 낮은 서비스에 적합하다.
• 삭제 모델: 전통적인 RabbitMQ 큐는 컨슈머가 메시지를 소비하고 Ack하면 큐에서 메시지가 삭제된다.

RabbitMQ Streams의 아키텍처 융합

RabbitMQ v3.9 이후 도입된 Stream Queues 기능은 전통적인 큐 모델을 넘어 Kafka와 유사한 불변 로그 아키텍처를 제공한다. 이 Streams는 영구적이며 복제되어 메시지가 삭제되지 않으며, 여러 컨슈머가 독립적으로 데이터를 읽을 수도 있다. 그렇기 때문에 RabbitMQ의 역할을 단순 브로커에서 고처리량 스트리밍 플랫폼으로 확장시킬 수도있다.

기술적 성능 및 데이터 보장성 벤치마킹

성능 메트릭 비교: Throughput, Latency, 및 확장성

구분	SQS	Kinesis (On-Demand)	AWS MSK	Apache Kafka	RabbitMQ
최대 Throughput	High (API Rate)	Very High (10 GBps Write)	Extremely High (3X Standard Kafka)	Very High	High (Thousands/sec)
Latency 특성	Variable (Polling Interval)	Low (Milliseconds)	Very Low	Very Low	Very Low (Push)
메시지 크기 한계	256KB	1MB	수십 MB	수십 MB	수십 MB
확장 용이성	Extremely Easy	Easy (On-Demand)	Easy (Managed Scaling)	Difficult (Manual partitioning, operational complexity)	Difficult (Cluster management)

Kafka, MSK, Kinesis는 기본적으로 고처리량 시나리오를 위해 설계되었으며, MSK는 표준 Kafka 대비 3배 높은 처리량을 제공하여 대용량 스트리밍에서 가장 강력한 성능을 제공한다. 반면에, RabbitMQ는 Push방식을 사용하여 메시지 전달 시의 지연 시간(Low Latency)을 낮추는 데 포커스를 맞춘다. 따라서 대규모 로깅이나 실시간 분석처럼 전체 데이터 볼륨이 중요하면 Kafka/MSK/Kinesis를, 즉각적인 알림이나 작업 요청 처리 속도가 중요하면 RabbitMQ가 적합하다. SQS는 서버리스 확장성 덕분에 볼륨 처리가 용이하지만, 메시지 크기 제한(256KB)과 Polling 방식의 특성상 지연 시간이 가변적일 수 있다.

데이터 무결성

메시지 순서 보장

• SQS FIFO: Message Group ID를 사용하여 엄격하고 전역적인 순서 보장을 제공하며, Exactly-Once 처리를 지원한다.
• Kafka/MSK/Kinesis: 고처리량을 위해 샤딩/파티셔닝을 사용하므로, 순서는 파티션 또는 샤드 내에서만 보장된다. 전역 순서가 필요한 경우 파티션을 하나만 사용해야 하지만, 이는 확장성을 포기해야 할수도 있다.
• RabbitMQ: 일반적으로 큐잉 순서대로 메시지를 전달한다.

데이터 보존 및 재생

• 스트리밍 플랫폼: Kafka/MSK, Kinesis는 데이터를 장기간 보존하며 컨슈머가 자신의 오프셋을 관리하여 데이터를 여러 번 재처리할 수 있다. 특히 MSK는 사실상 무제한 스토리지를 제공한다.
• 큐잉 플랫폼: SQS 및 전통적인 RabbitMQ 큐는 작업 완료 및 분배를 위해 설계되었기 때문에 메시지 소비 후 즉시 삭제되므로 데이터 재처리가 절대 불가능하다.

권장 사항

아키텍처를 선택할 때에는 각 플랫폼의 기술적 사양과 비즈니스 요구사항에 따라 이루어져야 한다.

사용 사례 시나리오	핵심 요구사항	최적 플랫폼	근거
분산 마이크로서비스 간 비동기 작업 분리	At-least-once 전달, 높은 가용성, 단순 큐잉	AWS SQS (Standard)	서버리스, 무한한 스케일링, 운영 오버헤드가 없어 단순 작업 큐에 가장 비용이 효율적
실시간 대규모 데이터 수집/분석 파이프라인	고처리량, 데이터 재처리, 장기 데이터 보존	AWS MSK	Kafka의 이벤트 스트리밍 아키텍처를 기반으로 하며, MSK Express는 3배 높은 처리량과 무제한 저장소, 빠른 복구 속도를 제공하여 고성능 분석에 최적
AWS Native 환경에서의 실시간 스트리밍	AWS Lambda, Kinesis Data Analytics 등 AWS 네이티브 서비스와의 간편한 연동	AWS Kinesis (On-Demand)	AWS 서비스와의 통합이 깊고 용이하며 On-Demand 모드는 샤드 관리 복잡성을 제거하여 운영을 간소화
금융 거래, 주문 처리 등 엄격한 순서 및 단일 전달 보장	전역 순서 보장, Exactly-Once Delivery	AWS SQS (FIFO)	엄격한 순서와 단일 전달을 보장하며, 메시지 중복 문제를 제거하여 결제 및 주문 처리 등 높은 무결성이 요구되는 시스템에 거의 필수
복잡하고 유연한 메시지 라우팅 및 레거시 프로토콜 연동	다양한 프로토콜(AMQP, MQTT), 다이내믹 라우팅 규칙	RabbitMQ	Exchange와 Binding을 이용한 복잡한 라우팅 구조가 RabbitMQ의 핵심 강점이며 다양한 레거시 프로토콜 지원은 통합에 유리
장시간/상태 비저장 비동기 작업 처리	장기간 작업 가시성 유지, 작업자 실패 시 복구 메커니즘	AWS SQS (Standard)	확장된 Visibility Timeout (최대 12시간) 기능을 통해 외부 상태 관리 없이도 장시간 작업의 내결함성을 구현 가능
클라우드 중립성 확보 및 운영 환경의 완전한 제어	클라우드 종속성 회피, 특정 고도화된 Kafka 기능 사용	Apache Kafka	AWS 종속성을 피하거나 하이브리드 환경 운영, 또는 고도로 커스터마이징된 Kafka 설정이 필요