메시지 큐 대 스트리밍 시스템: 주요 차이점 및 사용 사례

데이터 처리 및 메시징 시스템의 세계에서 “큐”와 “스트리밍”과 같은 용어가 자주 등장합니다. 이들은 비슷하게 들릴 수 있으나, 각각의 목적은 다르며 시스템이 데이터를 처리하는 방법에 큰 영향을 미칠 수 있습니다. 이러한 차이를 간단히 설명해보겠습니다.

메시지 큐란 무엇인가?

고객이 온라인 또는 직접 주문을 하는 커피숍을 상상해보세요. 주문이 처리되면 고객에게 픽업 알림이 전송됩니다. 이 비유에서, 주문은 큐의 메시지처럼 작동하며, 바리스타는 각각의 주문을 처리하여 완료하면 큐에서 제거합니다. 이것이 바로 메시지 큐가 작동하는 방식입니다.

각 메시지는 독립적으로 처리해야 하는 개별 작업을 나타냅니다. 큐의 메시지는 순서대로 소비되며, 일반적으로 소멸성 소비입니다. 즉, 메시지가 처리되면 큐에서 삭제됩니다.

스트리밍 메시지란 무엇인가?

이제 음악이 계속 흐르는 라이브 콘서트를 상상해보세요. 스트리밍 메시지는 데이터의 지속적인 흐름과 실시간 처리를 중심으로 합니다.

• 주식 가격 모니터링: 거래자에게 실시간 업데이트 제공.
• 부정행위 탐지: 수상한 활동을 즉시 식별합니다.
• 고객 서비스 분석: 실시간으로 상호작용 및 감정 추적.

Apache Kafka에서 큐를 사용하는 이유?

Confluent에서는 다양한 데이터 워크로드를 위해 Apache Kafka를 보편적인 솔루션으로 만들어 독점 시스템에 대한 의존성을 제거하려고 합니다. 전통적인 메시징 시스템은 사용자가 순서와 속도 중에서 선택해야 할 때가 많습니다. Kafka는 이제 큐 지원을 도입하여 이 갭을 메우고 사용자에게 메시지를 순차적 또는 병렬로 처리할 유연성을 제공합니다.

이 추가 기능은 Kafka의 다기능성을 향상시켜 스트리밍 및 큐 기반 워크플로를 모두 지원하여 더욱 다양한 사용 사례에 대응할 수 있게 합니다.

Apache Kafka에서 큐는 어떻게 지원되는가?

Kafka는 각 메시지에 고유한 오프셋을 할당하는 로그 기반 아키텍처를 사용합니다. 소비자는 메시지를 순차적으로 읽으며, 이는 내결함성과 메시지 재생을 가능하게 합니다. 새로운 하이브리드 모델을 통해 Kafka는 전통적인 큐와 로그 기반 설계의 장점을 결합합니다:

• 병렬 처리: 여러 소비자가 동시에 메시지를 소비할 수 있습니다.
• 재생 가능성: 메시지는 복구 또는 재처리를 위해 재생될 수 있습니다.
• 높은 처리량: Kafka는 필요에 따라 비순차 처리도 가능하게 하며, 확장성과 신뢰성을 유지합니다.

Kafka의 소비자 그룹과 공유 그룹

Kafka에서는 소비자 그룹이 토픽에서 데이터를 소비하는 방법을 관리합니다. 각 소비자 그룹은 토픽의 파티션을 읽는 여러 소비자로 구성됩니다. 그룹 내에는 파티션과 소비자 간에 1:1 관계가 있습니다. 그러나 소비자 수가 파티션 수를 초과하면 확장이 비효율적일 수 있습니다.

공유 그룹은 전통적인 큐 시스템과 유사한 작업량에 더 유연한 접근 방식을 제공합니다. 여러 소비자가 같은 파티션을 읽어 데이터 공유 및 처리에 대한 더 세밀한 제어를 가능하게 합니다.

실제 사례: 소매 판매 행사

• 병렬 처리: 주문은 병렬 처리하기 위해 여러 작업자에게 배분됩니다.
• 동적 자원 할당: 시스템은 최고 부하 시 소비자를 추가하고, 수요가 적을 때 축소할 수 있습니다.
• 효율적 처리: 엄격한 순서가 필요하지 않은 빠른 주문 처리.