메시지 브로커를 이용한 비동기식 통신

Review: 프로세스 간 통신

• 요청을 보내는 즉시 수신자로부터 응답이 오길 기대하는 "동기적 방법"
  • 클라이언트-서버 아키텍처의 REST(HTTP)가 대표적

 

• 요청을 일단 보내놓고 수신자가 받을 때까지 보관했다가 처리하는 "비동기적 방법"
  • 수신자가 받기 전에 누군가는 메시지를 보관해놓아야 한다 → 메시지 브로커 (메시지 큐)

 

메시지 브로커가 필요한 이유

 > 분산 애플리케이션에서 프로세스 간의 느슨한 결합(loosely coupled)을 제공하는 것이 가장 큰 장점

  > 그렇다면 강하게 결합된 시스템에서의 단점은 무엇일까요? 서로 연결되어 있는 시스템 중 한 곳에서 장애가 발생했을 때 그 장애가 연결된 다른 시스템들에 영향이 감

 

그러나 중간에 메시지 브로커가 있다면, 한 시스템의 장애가 다른 시스템에 주는 영향을 줄일 수 있음

 

주요 용어

• 메시지를 보내는 사람이 생산자(producer), 메시지를 받는 사람이 소비자(consumer)
• 메시지를 보내는 것을 발행(publish), 메시지를 받는 것을 소비(consume)

 

메시지 브로커의 특징

• 프로그램 간의 직접 연결 없음: less dependency, fault tolerant
  • 소비자 프로세스가 죽어있어도 생산자는 메시지를 보낼 수 있음
  • 생산자 프로세스가 죽어있어도 소비자는 메시지를 수신할 수 있음

 

• 메시지 브로커에 있는 메시지는 소비자(수신자)가 꺼낼 때까지 안전하게 보관됨: durability
  • (프로세스가 죽어 있어도) 메시지는 소비하기 전까지는 사라지지 않음
  • 따라서, 프로그램 간 통신은 시간과 독립적임

 

• 통신이 이벤트에 의해 구동될 수 있음
  • 큐의 상태에 따라 프로그램을 제어. 예를 들어 메시지가 큐에 도착하는 즉시 프로그램이 시작되도록 설정할 수 있음. 또는 예를 들어 큐에서 특정 우선순위 이상의 메시지가 10개가 되거나 임의의 우선순위의 메시지가 10개가 될 때까지 프로그램이 시작되지 않도록 지정할 수 있습니다.

 

• 확장에 용이함
  • 메시지 브로커는 여러 큐를 만들거나, 수평적으로 확장하여 메시지 부하 증가를 처리할 수 있습니다.

 

메시지 브로커의 단점

• 프로세스 간의 직접 연결에 비해 아키텍처가 복잡
  
  

메시지 브로커 선택의 기준

 > 메시지 브로커의 종류로는 Apache Kafka, Amazon Kinesis, Amazon SQS 등이 있음. 어떤 메시지 브로커를 선택해야 할 경우, 다음 기준으로 선택하면 좋음.

• 프로그래밍 언어 지원 여부
• 메시징 표준 지원 여부
• 메시지 순서 보장 여부
• 전달 보장 여부: 어떤 종류의 전달을 보장하는가?
• 영속성: 브로커가 고장 나도 문제가 없도록 메시지가 디스크에 저장되는가?
• 내구성: 소비자가 메시지 브로커에 다시 접속할 경우, 접속이 중단된 시간에 전달된 메시지를 받을 수 있는가?
• 확장성
• 지연 시간

 

여기서 잠깐!!

메시지 브로커의 두 가지 방식인 Queue 방식과 Topic 방식은 어떤 차이가 있나요?

Queue 방식은 일대일 통신을 위해 사용됩니다. 메시지를 수신하는 대상이 하나뿐이며, 메시지 큐에 저장된 순서대로 메시지가 전달됩니다. 즉, 메시지를 보내는 측에서는 목적지를 명시하고, 이에 해당하는 메시지 큐에 메시지를 전송합니다. 이러한 방식은 다른 프로세스나 시스템에서 메시지를 받을 필요가 없을 때 사용됩니다.

Topic 방식은 일대다 통신을 위해 사용됩니다. 메시지를 수신하는 대상이 여러 개이며, 메시지 구독자들 중에서 해당 주제와 일치하는 구독자에게 메시지를 전달합니다. 메시지를 보내는 측에서는 토픽을 명시하고, 해당 토픽에 구독한 모든 메시지 구독자들에게 메시지를 전송합니다. 이러한 방식은 브로드캐스트나 다른 시스템에 대한 이벤트 전송 등에서 사용됩니다.


메시지 서비스로는 대표적으로 Apache Kafka와 Amazon SQS, Amazon Kinesis가 있습니다. 각각은 어떤 차이가 있나요?

대규모 분산 시스템에서 실시간으로 대량의 데이터를 처리할 수 있는 기능을 제공

아키텍처:
Apache Kafka: 분산형 스트리밍 플랫폼으로, 대량의 데이터를 높은 처리량과 지연 시간 없이 처리할 수 있도록 디자인되었습니다. 브로커, 프로듀서, 컨슈머 등으로 구성되어 있습니다.
Amazon SQS: 분산형 메시지 대기열 서비스로, 메시지를 큐에 보내고 이를 소비하는 애플리케이션 간에 비동기 메시지를 전송할 수 있습니다.
Amazon Kinesis: 분산형 스트리밍 데이터 서비스로, 대규모 데이터 스트림을 수집, 처리 및 분석할 수 있습니다. Kinesis Streams, Kinesis Firehose, Kinesis Analytics로 구성되어 있습니다.

지원하는 프로토콜:
Apache Kafka: TCP, REST, gRPC
Amazon SQS: HTTP/HTTPS, AWS SDKs
Amazon Kinesis: HTTPS, AWS SDKs

메시지 보존 기간:
Apache Kafka: 기본적으로 메시지를 보존하며, 보존 시간은 토픽 별로 설정 가능합니다.
Amazon SQS: 메시지를 보존하는 기간은 14일 이하입니다.
Amazon Kinesis: 보존 기간을 설정할 수 있으며, 기본적으로 24시간 이내의 데이터만 저장합니다.

가용성:
Apache Kafka: 주키퍼를 통해 분산 환경에서 높은 가용성을 제공합니다.
Amazon SQS: 여러 AZ에서 데이터를 복제하여 고가용성을 제공합니다.
Amazon Kinesis: 여러 AZ에 걸쳐 스트림 데이터를 복제하여 고가용성을 제공합니다.

스트리밍 데이터 처리:
Apache Kafka: 스트림 처리에 특화된 디자인으로, 실시간 데이터 분석 및 처리에 유리합니다.
Amazon SQS: 메시지 대기열에 의해 상대적으로 느린 처리 속도를 보입니다.
Amazon Kinesis: 스트리밍 데이터를 높은 처리량과 실시간으로 처리할 수 있도록 디자인되었습니다.


웹 서비스에서 메시지 브로커(메시지 큐)를 이용해 비동기적인 방법이 활용되는 사례를 하나 이상 찾아보고, 어떻게 활용되는지 설명하세요.

웹 서비스에서 메시지 브로커를 이용해 비동기적인 방법을 활용하는 대표적인 사례는 이벤트 드리븐 아키텍처(Event-driven architecture, EDA)입니다. EDA는 이벤트 발생 시 이벤트 핸들러가 처리하는 방식으로 비동기적으로 동작합니다. 이때, 메시지 브로커를 이용하면 이벤트 핸들러가 이벤트를 즉시 처리하지 않더라도 메시지 큐에 이벤트를 넣어두고 나중에 처리할 수 있습니다.

예를 들어, 온라인 주문 시스템에서 주문이 완료되면 주문 서비스에서 이벤트를 발생시켜 주문 완료 이벤트를 메시지 브로커에 전송합니다. 이후에는 결제 서비스, 재고 관리 서비스, 배송 서비스 등이 이벤트 핸들러로 등록되어 있어 메시지 브로커에서 주문 완료 이벤트를 받으면 각 서비스에서 필요한 처리를 비동기적으로 수행할 수 있습니다.

이를 통해 주문 서비스에서 주문 완료 이벤트를 처리한 후, 결제, 재고 관리, 배송 등의 서비스에서 필요한 작업을 비동기적으로 처리하므로, 처리 시간이 짧아지고 서비스의 가용성도 높아집니다. 또한, 서비스 간의 결합도를 낮추므로 시스템의 유연성도 향상됩니다.

이와 같이 메시지 브로커를 이용한 비동기적인 방식은 다양한 웹 서비스에서 활용되며, 대규모 분산 시스템에서 실시간으로 대량의 데이터를 처리할 수 있는 기능을 제공합니다.