메시지 큐와 이벤트 스트림

이벤트는 메시지다

메시지 중심 시스템에서는 각 컴포넌트가 명확히 정해진 수신자에게 메시지를 보낸다. 즉, 발신자는 메시지를 "누구에게 보낼지"를 알고 있고, 이를 직접적으로 전달한다. 반면, 이벤트 중심 시스템에서는 컴포넌트가 특정 발신자로부터 이벤트를 수신하고, 모든 관심 있는 소비자에게 이벤트를 공유한다. 이벤트 중심 시스템은 누가 받을지에 대해 신경 쓰지 않고, 시스템 전체에 "이런 일이 일어났다!"라고 알리는 방식이다.

메시지는 시스템 구성 요소 간의 통신 방법을, 이벤트는 시스템 전체의 동작 방식을 나타낸다. 따라서 메시지를 주고받는 기술을 이용해 이벤트 발생에 따라 시스템이 반응하는 구조를 구현할 수 있다. 즉, 메시지는 이벤트를 전달하는 수단이며, 이벤트 중심 시스템은 이를 “변화의 신호”로 해석해 다양한 컴포넌트가 독립적으로 반응하도록 설계된다.

 

메시지 유형

• 명령(command): 컴포넌트의 상태 변경을 요청하기 위해 전송되는 메시지다. 명령을 받은 컴포넌트는 명령이 유효하면 상태를 변경한다.
• 이벤트(event): 컴포넌트의 상태가 변경되었을 때 전송되는 메시지다. 이벤트에는 상태 변경에 필요한 데이터가 포함되며, 나중에 소비자가 조회 가능한 형태로 퍼블리싱 인프라를 통해 배포된다.
• 쿼리(query): 컴포넌트로부터 정보를 얻기 위해 전송되는 메시지로, 발신자 주소를 포함하여 회신이 가능하도록 구성된 특별한 유형의 메시지다.
• 응답(response): 쿼리에 대한 회신 메시지로, 쿼리 처리 컴포넌트는 답장을 생성하여 지정된 발신자 주소로 전송한다.

 

메시지 큐와 이벤트 스트림 비교

메시지 큐

• A 지점에서 B 지점으로 메시지를 안정적으로 전달하는 것을 목표로 한다.
• 메시지는 그 자체로 의미 있는 단일 작업 단위이며, 서로 간에 연속성이나 흐름이 없다.
• 여러 소비자가 하나의 큐에서 메시지를 경쟁적으로 소비하며, 하나의 메시지는 하나의 소비자만 처리한다.
  • 부하 분산과 처리량 개선을 위해 소비자를 수평 확장할 수 있다.
• 소비자가 메시지를 성공적으로 처리하면 메시지는 즉시 삭제된다.
  • 소비자가 처리할 때까지 메시지를 보관하는 임시 저장소 역할을 수행한다.
  • 메시지의 전달은 정확히 한 번 또는 최소 한 번을 보장한다.
• FIFO 큐로 메시지의 순서를 보장할 수 있다.
• 특정 시간이나 간격으로 수행하는 작업을 예약 및 관리할 수 있다.

 

이벤트 스트림

• 시간에 따라 발생하는 이벤트를 실시간으로 처리하고, 향후 재처리가 가능하도록 이벤트 흐름을 저장하고 관리하는 것이 목표다.
• 개별 이벤트는 각각 의미를 가지며, 시간적·논리적 연속성을 가진다.
• 여러 소비자가 동일한 토픽/채널을 구독하여 독립적으로 이벤트를 소비할 수 있다.
• 이벤트를 논리적 그룹(토픽)의 파티션으로 나누어 처리하며, 소비자 그룹 내에서 파티션을 분산 처리하여 처리량과 확장성을 높인다.
• 이벤트는 소비 후에도 저장되어 과거 이벤트의 재생 및 재처리가 가능하다.
  • 실시간 데이터 처리 및 분석이 필요한 시스템에 적합하다.
  • 포인터 또는 오프셋을 사용하여 이벤트 간 탐색이 가능하다.
  • 하나의 이벤트는 여러 번 전달될 수 있다.

 

메시지 큐의 한계와 이벤트 스트림의 해결책

• 확장성: 메시지 큐는 여러 노드 간 상태 동기화가 복잡해 확장성이 떨어진다. 이벤트 스트림은 파티션 기반의 분산 구조를 통해 쉽게 확장할 수 있다.
• 안정성: 메시지 큐는 소비 후 즉시 메시지를 삭제하므로 시스템 장애 시 메시지 유실 위험이 있다. 이벤트 스트림은 장기간 이벤트를 보관하고 재생할 수 있어 안정성이 높다.
• 성능: 메시지 큐 시스템은 디스크 기반의 저장 및 읽기 방식으로 인해 I/O 병목 현상이 발생할 수 있다. 이벤트 스트림은 지속적인 데이터 흐름과 병렬 처리 구조를 통해 높은 처리량과 낮은 지연을 동시에 제공한다.

 

Kafka 메시지 큐인가, 이벤트 스트리밍 플랫폼인가?

stack overflow의 질문: Is Kafka a Message Queue or a Message Broker?

 

Kafka는 메시지 큐처럼 보이는 기능을 일부 포함하고 있으나, 본질적으로는 이벤트 스트리밍 플랫폼이다. Kafka는 이벤트를 저장하고 재생하며, 스트림 처리를 지원하는 고급 기능을 갖추고 있다.

Kafka가 메시지 큐로 오해받는 이유는 다음과 같다.

• 메시지 발행과 구독 구조가 메시지 큐와 유사하다.
• 최소 한 번 이상(at-least-once) 전달 및 단일 소비자 그룹 내에서 정확히 한 번 소비가 가능하다.
• 높은 처리량과 낮은 지연을 지원하여 메시지 큐의 성능 요건을 충족한다.

그러나 Kafka는 근본적으로 메시지 큐와 다르다.

• 소비된 메시지를 삭제하지 않고 설정된 보존 기간 동안 디스크에 로그로 저장하여 재생할 수 있다.
• 여러 소비자 그룹이 같은 토픽을 독립적으로 구독할 수 있으며, 각 소비자 그룹이 독립적인 오프셋을 유지한다.
• Kafka Streams나 ksqlDB와 같은 도구와 결합하여 실시간 스트림 처리 및 분석이 가능하다.

따라서 Kafka는 메시지 큐 기능의 일부를 포함하지만, 전체적으로는 이벤트 중심의 데이터 처리 플랫폼으로 정의된다.

 

• 참고 자료
  • https://medium.com/@gokerakce/choosing-the-right-messaging-approach-event-streaming-or-message-queues-17c3f047ebd5
  • https://www.geeksforgeeks.org/message-queues-vs-event-streams-in-system-design/
  • https://thenewstack.io/choosing-between-message-queues-and-event-streams/
  • https://www.linkedin.com/pulse/differences-between-message-queue-event-stream-frank-lieu/
  • https://doc.akka.io/libraries/guide/concepts/message-driven-event-driven.html