성능 향상을 위한 메시지 큐 도입

📌  성능 향상을 위한 메시지 큐 도입

JMeter 테스트에 대한 1차 목표를
      현재 Error 발생률 : 57.7%
      1차 목표 : Error 발생률 0%
      -> 시간이 얼마가 걸리든 상관없이 모든 유저가 응답을 받을 수 있도록 하려고 함.
으로 설정하였다.

 

📍 대기열 시스템이 필요한 이유

지금 서비스에서는 JMeter 테스트 시 시간도 오래걸리고 요청에 대해 모두 응답을 성공적으로 보내지 못한다. 서버가 한번에 처리할 수 있는 요청의 수가 제한적이기 때문이다. 서버에 동시에 과도한 요청이 들어올 경우, 서버는 이것들을 모두 처리하려고 하지만, 한번에 처리할 수 있는 요청의 수가 제한적이므로 일부 요청을 처리하지 못하는 문제가 발생한다. 따라서, 서버가 바로 처리하지 못하는 요청을 일시적으로 저장해두었다가 순차적으로 처리할 수 있도록 대기열 시스템을 도입해야한다. 즉, 모든 유저가 성공적인 응답을 받을 수 있도록 대기열 시스템을 도입하고자 한다.

 

📍 Message Queue (메시지 큐)

 Message Queue는 서버리스 및 마이크로 서비스 아키텍처에 사용되는 비동기식 서비스 대 서비스 통신 형태이다. 메시지는 처리되고 삭제되기 전까지 대기열에 저장된다. 각 메시지는 하나의 소비자가 한 번만 처리한다. 메시지 대기열은 규모가 큰 처리 작업을 결합 해제하고, 버퍼링 또는 배치 작업을 수행하고, 급변하는 워크로드를 원활하게 지원하는 데 사용될 수 있다.

 Message Queue 는 "메시지", 즉 애플리케이션에서 다른 애플리케이션이 이용할 수 있도록 생성하는 데이터 패킷을, 전송되는 순서대로, 이용하는 애플리케이션에서 해당 메시지를 처리할 수 있는 상태가 될 때까지 저장한다. 그러면 메시지는 수신 애플리케이션에서 준비될 때까지 안전하게 대기할 수 있다. 즉, 네트워크나 수신 애플리케이션에 문제가 생기더라도 메시지 큐에 있는 메시지는 사라지지 않는다.

 

장점

• 안정적인 메시지 전달: 메시지 큐를 사용하면 애플리케이션 간의 비즈니스 크리티컬 메시지가 사라지지 않고 수신 애플리케이션에 단 한 번만 전달되도록 할 수 있다. 이러한 기능이 있으면 별도의 중복 제거나 손실 방지 로직이 필요하지 않는다.
• 애플리케이션 간 연결성: 일부 메시지 큐 솔루션에서는 메시지 암호화, 트랜잭션 속성을 비롯하여 애플리케이션과 서비스 간의 각종 통신 요소를 다룰 수 있다. 그러면 애플리케이션 개발이 간소화되고, 상이한 아키텍처 간의 연동이 가능해진다.
• 다기능: 메시지 큐 솔루션은 Java, Node.js, COBOL, C/C++, Go, .NET, Python, Ruby, C# 등 다양한 언어를 지원할 수 있다. MQTT, AMQP, REST 등 다양한 애플리케이션 프로그래밍 인터페이스(API)와 프로토콜도 지원할 수 있다.
• 복원성: 비동기식 메시징에서는 애플리케이션 관련 오류가 시스템에 영향을 미치지 않도록 보장한다. 시스템의 한 구성요소가 멈추더라도 나머지 다른 구성요소는 계속 큐와 연결하면서 메시지를 처리할 수 있다. 그러면 시스템 전체의 안정성이 어느 한 부분의 오류로 인해 영향을 받을 가능성이 줄어든다.
• 강화된 보안: 메시지 큐에서는 모든 메시지를 식별하고 인증할 수 있다. 일부 메시지 큐 솔루션은 메시지가 저장될 때, 전송될 때, 또는 아예 처음부터 끝까지(end-to-end) 메시지를 암호화하도록 설정할 수도 있다. 이는 애플리케이션 및/또는 인프라 전반의 보안에 기여할 수 있다.
• 통합 파일 전송: 일부 메시지 큐 솔루션은 파일 전송과 같은 부가 기능도 제공한다. 이는 파일 전송 솔루션이 쓰이는 엔터프라이즈 환경에서 FTP의 대안이 될 수 있다.

 

📍 대기열을 만드는 방법

Kafka, RabbitMQ, AWS SQS/SNS, Redis 등 많은 방법이 있었다.

그 중 Apache Kafka, RabbitMQ, Redis를 비교하여 선택하였다.

	Apache Kafka	RabbitMQ	Redis
메시지 크기	압축 및 계층형 스토리지로 최대 1GB의 메시지 크기를 지원한다.		더 작은 메시지 크기를 지원한다.
메시지 전송	구독자는 대기열에서 메시지를 가져온다.		Redis 서버는 연결된 가입자에게 메시지를 푸시한다.
메시지 보존	검색 후 메시지를 보존한다.	메시지 사용을 모니터링한다. 메시지가 사용되면 RabbitMQ 브로커는 사용된 메시지를 삭제한다. RabbitMQ는 메시지 우선 순위를 지원한다.	메시지를 보관하지 않는다.
성능	초당 최대 수백만 개의 메시지를 실시간으로 전송한다.	초당 수천개의 메시지를 전송한다.	Redis 서버가 다른 구독자에게 메시지를 보내기전에 회신을 기다려야 하기 때문에 처리량이 줄어든다.
지연 시간	짧은 지연 시간. 기본적으로 데이터 복제로 인해 Redis보다 약간 느리다.	지연시간이 짧다.	작은 크기의 메시지를 배포할 때 지연 시간이 매우 짧다.
이벤트 저장 in Queue	이벤트를 삭제하지 않고 스트림에 저장함으로 영속성(durability)이 보장되고, 재처리가 가능하다.	메세지가 성공적으로 전달되었다고 판단될 경우 메세지가 큐에서 삭제되기 때문에 재처리가 어렵다	저장하지 않음. 심지어 channel에 이벤트가 도착했을 때 해당 채널의 subscriber가 존재하지 않으면 이벤트 사라짐
장점	분산 시스템으로 설계되어 대량의 실시간 데이터 스트림을 처리하는 데에 최적화되어 있습니다.	메시지 전달의 신뢰성이 높다.	다양한 데이터 타입을 지원하므로, 복잡한 데이터 구조를 효율적으로 처리할 수 있다.
단점	설정과 관리가 복잡할 수 있다. 메시지 전달의 신뢰성이 RabbitMQ만큼 높지 않을 수 있다.	메모리 기반 메시지 브로커로서, 대량의 데이터를 처리하는 데에 제한이 있을 수 있다.	메모리 용량을 초과하는 데이터를 처리하는 데 제한적이다. 애플리케이션이 종료되거나 장애가 발생하면 데이터가 손실될 수 있다.

 

 

Kafka : 대용량 데이터에 대해서 처리해야 할 때

RabbitMQ : 신뢰성있는 메시지 전달이 중요할 때

Redis : 빠른 응답이 필요하거나 캐싱이 필요할 때

 

 

 

⭐
결과적으로, 대용량 데이터 처리에는 Kafka를 사용하는 것이 더 적합하다고 판단하였다.

-> 데이터를 대기열에 넣음으로써 높은 트래픽 급증으로 인해 평소보다 더 오래 걸리더라도 데이터가 유지되고 결국 처리될 것이라고 확신할 수 있다.

 

 

 

 

 

 

 

 

 

 

References :https://aws.amazon.com/ko/message-queue/?nc1=h_lshttps://www.ibm.com/kr-ko/topics/message-queueshttps://aws.amazon.com/ko/compare/the-difference-between-kafka-and-redis/https://jungyu09.tistory.com/14https://aws.amazon.com/ko/compare/the-difference-between-rabbitmq-and-kafka/https://aws.amazon.com/ko/compare/the-difference-between-rabbitmq-and-kafka/

https://velog.io/@mdy0102/MQ-%EB%B9%84%EA%B5%90-Kafka-RabbitMQ-Redis