해결하지 못한 문제

🚨 Stomp Message Broker

🔍 원인 분석

• message broker가 유지하는 세션의 요청 수를 감당하지 못해 session time out 발생
• spring 내부 message broker를 사용함으로써 heap memory 부족 현상 발생

🛠️ 해결 시도 및 고민

• 외부 브로커를 통한 해결 시도
  • RabbitMQ vs Kafka
    • RabbitMQ : 메시지 전용 브로커로써 전통적인 Message Queue 방식 지원
    • kafka : 분산 스트리밍 플랫폼으로 실시간 스트림 처리 및 데이터 통합을 위한 connector api등 다양한 기능 제공
  • 메세지 브로커로써의 기능에 초점을 맞춰 RabbitMQ를 선택

1. RabbitMQ의 성능 테스트

   • 단일 노드 일 때 스프링 message broker 보다 좋지 않은 성능 지표가 나옴

     

     • RabbitMQ는 Queue를 만들어 메세지들을 관리하기 때문에 기존의 simple broker 보다 더 많은 메모리가 필요
     • 대용량 요청을 처리하기 위해 broker의 확장도 필요

   → rabbitMQ 클러스터 환경 구축의 필요성

2. RabbitMQ 클러스터 환경 구축

   • 요청에 대한 분산 처리가 제대로 이루어지지 않음
     • 클러스터 환경을 구축하면 각 rabbitMQ에 동일한 queue가 생성되고 자동적으로 분산 처리가 될 것이라고 오해
   • 실제 동작
     • 동일 이름의 queue는 생성 불가, queue는 3개의 rabbitMQ 중 하나의 노드에만 생성
     • 로드밸런싱 불가, 하나의 노드에만 요청이 들어가는 문제 발생

3. 추후 시도할 수 있는 부분

   • 각각의 rabbitMQ에 queue를 생성하여 샤딩을 하는 것과 같이 데이터를 분산 처리