08:17 입실
인프라 구성 kafka(?) 관련해서 부하 분산 기법에 대해서 조사하기
Amazon Simple Email Service
신뢰할 수 있고 확장 가능한 이메일을 통해 업계 최저 수준의 요금으로 고객과 소통하기
이메일 발신, 수신 기능이 모두 있음.
Amazon Simple Notification Service
A2A 및 A2P 메시징을 위한 완전관리형 게시/구독 서비스
토픽을 발행하고, 이 토픽을 여러 주체가 구독하는 개념
핵심: 하나의 이벤트(메시지)에 대해서 다양한 프로토콜로 요청을 보냄.
완전관리형 메시지 대기열 - Amazon Simple Queue Service
다른 서비스에서 사용할 수 있도록 메시지를 잠시 저장하는 용도
SNS가 메시지를 여러 주체에게 일괄 발송하는 개념이라면, SQS는 큐에 저장해놓고 필요한 주체가 하나씩 꺼내가는 개념
일종의 대기열임. 예를 들어 메시지 큐가 없다면 어떤 작업을 수행해야 하는 인스턴스가 모두 죽은 경우, 해당 작업은 처리되지 못하고 사라짐. 하지만 메시지 큐가 있다면 인스턴스가 모두 죽으면 인스턴스에서 처리되지 못한 작업은 메시지 큐에 대기하고 있다가, 가용 인스턴스가 확보되면 메시지 큐에서 순차적으로 작업이 처리됨.
다수의 수신자에게 알림을 전송해야 하는 경우 SNS가 적합하고, 메시지의 순차적 처리가 필요한 경우 SQS가 더 적절
SNS는 해당 서비스가 구독 주체에게 메시지를 PUSH
SQS는 개별 주체가 메시지를 PULL
이벤트 브로커
오픈 소스 분산 이벤트 스트리밍 플랫폼
: 생산자는 소비자가 메시지를 검색했는지 여부에 관계없이 메시지를 대기열에 게시
메시지 브로커
오픈 소스 메시지 브로커
용어 정리
생산자: 정보는 게시하는 애플리케이션
소비자: 정보를 구독하고 처리하는 애플리케이션
장점: Kafka는 매우 높은 처리량을 지원하며, 데이터 스트리밍과 대규모 메시지 처리에 적합합니다. 분산 처리와 확장성이 뛰어나며, 대량의 데이터를 효율적으로 처리할 수 있습니다.
시나리오: Kafka는 요청이 폭발적으로 증가하는 상황에서 효과적입니다. 예를 들어, 사용자의 요청을 Kafka 토픽에 저장하고, 이를 소비하여 LLM에 전달, 그리고 결과를 다시 Kafka를 통해 전송할 수 있습니다.
장점: RabbitMQ는 메시지 큐잉과 라우팅에 특화되어 있으며, 메시지 순서와 신뢰성을 보장합니다. 또한, 다양한 메시지 전달 옵션을 제공합니다.
시나리오: RabbitMQ는 각 요청을 개별적으로 처리해야 하는 경우에 적합합니다. 예를 들어, 각 API 요청을 RabbitMQ 큐에 넣고, 처리 후 사용자에게 순차적으로 응답을 보낼 수 있습니다.
대규모 데이터 처리: Kafka가 더 적합할 수 있습니다. Kafka는 높은 처리량과 대규모 데이터 스트리밍에 최적화되어 있습니다.
개별 요청 처리 및 신뢰성: RabbitMQ가 더 적합할 수 있습니다. RabbitMQ는 메시지 순서와 전달을 보장하며, 보다 정교한 메시지 라우팅과 관리가 가능합니다.
kafka는 분산 스트리밍 플랫폼으로 메시지 브로커 시스템의 일종,
MQ는 메세지 큐잉 시스템.
순서가 보장될 필요는 없지만 엄청난 대규모 트래픽 처리에 적합
순서가 보장되고 신뢰성이 필요한 중요한 트랜잭션(금융 등)이나 시스템 간의 안정적인 메시지 전송에 사용
메시지 플랫폼은 두 가지로 나뉜다.
이벤트 브로커와 메시지 브로커(Kafka, Amazon Kinesis 등)
메시지 브로커는 메시지 브로커만 가능.(MQ)
이벤트 브로커는 이벤트와 메시지 브로커 둘 다 가능.