이벤트와 메시지
- 메시지
- 메시지는 송수신자간에 전송하는 데이터의 단위
- 메시지 큐는 모든 메시지가 한 번만 전달된다는 것을 보장함
- 이벤트
- 이벤트는 발생한 사실을 알리는 역할을 하며 그 자체로는 명령이 아님
- 이벤트 기반 시스템에서는 이벤트가 발생하면 이를 구독한 모든 수신자에게 이벤트가 전달됨
- Kafka와 같은 것을 이벤트 스트리밍 플랫폼이라고 함
RabbitMQ vs NATS vs Kafka 비교표
| 기능/특징 | RabbitMQ | NATS | Kafka |
|---|---|---|---|
| 메시지 브로커 타입 | 메시지 브로커 (Message Broker) | 초경량 메시징 시스템 (Lightweight Messaging) | 분산 로그 시스템 (Distributed Log) |
| 메시지 모델 | 큐 기반 (Queue-based) | 퍼브/섭 (Pub/Sub) | 로그 기반 (Log-based) |
| 메시지 크기 | 기본적으로 제한 없음 | 기본 1MB(조정가능) | 기본 1MB(조정가능, 10MB이하 권장) |
| 메시지 유지 기간 | 기본적으로 메시지 소비 후 삭제 | 메시지 전달 후 삭제 | 설정된 기간 동안 유지 |
| 메시지 순서 보장 | 단일 큐 내에서는 보장, 다중 컨슈머 환경에서는 순서 보장 어려움 | 보장되지 않음 | 파티션 내에서는 순서 보장됨 |
| 메시지 재처리 | 소비 후 삭제되므로 직접 재처리 어려움 (DLX 활용 가능) | 기본적으로 불가능 | 컨슈머 오프셋 조정으로 자유롭게 재처리 가능 |
| ACK (메시지 확인) | 개별 메시지 수준에서 ACK 지원 (수동/자동) | ACK 없음 (At-Most-Once 모델) | 컨슈머가 오프셋(commit) 기반으로 관리 |
| 메시지 중복 방지 | message-id 기반 de-duplication 지원 | 중복 방지 기능 없음 | Idempotent Producer 기능 활용 가능 |
| TTL (메시지 만료) | 지원 | 지원하지 않음 | 지원 |
| 지연 메시지 지원 | Dead Letter Exchange(DLX) 활용 가능 | 지원하지 않음 | 기본적으로 지원하지 않음 |
| 메시지 우선순위 | 메시지 우선순위 설정 가능 | 지원하지 않음 | 지원하지 않음 |
| 트랜잭션 지원 | 메시지 단위 트랜잭션 (AMQP Transaction) | 지원하지 않음 | Exactly-Once 트랜잭션 지원 |
| 백프레셔 (Backpressure) | 기본적으로 지원되지 않음 (소비자 속도로 조절 가능) | 지원하지 않음 | 소비자 측에서 직접 처리 속도 조절 가능 |
| 다중 소비자 패턴 | 여러 소비자가 동일 큐에서 메시지 가져감 (로드밸런싱) | 모든 구독자가 메시지 수신 (Pub/Sub) | 하나의 소비자 그룹 내에서 한 개의 컨슈머에게만 전달 |
| 브로드캐스트 | 팬아웃(Exchange) 활용 가능 | 기본적으로 지원 (모든 서브스크라이버에게 메시지 전달) | 여러 소비자 그룹이 동일 메시지를 독립적으로 소비 가능 |
| 대규모 데이터 처리 | 성능은 좋지만 대규모 스트리밍보다는 적합하지 않음 | 초경량, 빠른 전송 속도에 적합 | 대용량 이벤트 스트리밍 최적화 |
| 클러스터링 & 스케일링 | 클러스터링 지원, 하지만 관리 복잡 | NAT Streaming(Server) 모드에서 가능 | 기본적으로 분산 시스템으로 설계됨 |
| 사용 사례 | 요청-응답 패턴, 비동기 작업 큐, 미들웨어 | IoT, 경량 메시징, 마이크로서비스 간 통신 | 로그 처리, 이벤트 스트리밍, 대용량 데이터 처리 |
Dead Letter Exchange (DLX)
- 메시지큐는 큐안에 메시지가 들어있을 때 무조건 소비를 해줘야 함
- 메시지에 소비가 안되고 계속 남아있을 때 Push 방식에서는 무한히 요청을 하게 되고 그러면 메시지 서버에 부하가 생겨서 다운이 될 수 있음
- 메시지가 거부된 경우
- 메시지의 TTL이 만료된 경우
- 큐의 최대 길이 제한을 초과하여 메시지가 삭제된 경우
- Quorum Queue(쿼럼 큐)에서 설정된 delivery-limit(최대 재전송 횟수)을 초과한 경우
- 그걸 방지하기 위해서 메세지 소비가 안될 상황에 DLX 큐를 생성해 메세지를 옮겨주는 장소임
토픽이란
- 메시지 브로커에서 토픽은 특정 유형의 메시지를 전달하기 위한 논리적인 채널
- 반면 이벤트 스트리밍 플랫폼에서 토픽은 이벤트 스트림을 분할하고 관리하기 위한 논리적인 단위
- Kafka에서 토픽은 파티션(partition)으로 나뉘며 각 파티션은 특정 순서대로 이벤트를 저장함
- 👇 Kafka에 토픽을 생성하고 이벤트를 발생시키는 예시 코드
from kafka import KafkaProducer
producer = KafkaProducer(bootstrap_servers='localhost:9092')
topic = 'user-activity'
message = b'User logged in'
producer.send(topic, message)
producer.flush()
print(f" [x] Sent message to {topic}")
producer.close()Kafka의 파티션
- 파티션은 데이터를 여러 서버에 분산시키는 것을 의미함
- 각 파티션은 브로커라 불리는 개별 서버에 저장됨
- 예를 들어, 토픽 user-activity가 3개의 파티션으로 나뉜다면 각 파티션은 다른 서버에 분산될 수 있음
- 파티션 내에서는 이벤트의 순서가 보장되지만 서로 다른 파티션 간에는 순서가 보장되지 않음
AWS SQS와 AWS SNS
- AWS SQS : Amazon Simple Queue Service
- AWS SNS : Amazon Simple Notification Service
AWS SQS (Simple Queue Service)
- SQS는 메시지를 큐에 넣어두고 나중에 이를 읽어 처리할 수 있게 하는 메시지 큐 서비스
- 프로듀서와 컨슈머가 비동기적으로 통신할 수 있도록 함
- FIFO(First In First Out) 큐를 사용하면 메시지의 순서를 보장할 수 있음
AWS SNS (Simple Notification Service)
- SNS는 하나의 메시지를 여러 수신자에게 동시에 전달할 수 있는 메시지 브로커 서비스임
- 메시지를 주제(topic)에 게시하고 이를 구독한 모든 수신자에게 푸시함
SQS와 SNS의 차이점
- 메시지 전송 방식 : SQS는 메시지를 큐에 넣어두고 컨슈머가 이를 읽어가는 방식(풀 모델), SNS는 메시지를 주제에 게시하고 구독자에게 푸시하는 방식(푸시 모델)임
- 목적 : SQS는 주로 비동기 작업 처리에, SNS는 실시간 알림 및 이벤트 분배에 적합함
- 메시지 전달 : SQS는 메시지를 하나의 수신자에게 전달하고, SNS는 여러 수신자에게 동시에 전달함
결론
- SQS를 사용해야 하는 상황 : 비동기 작업 처리, 작업 분산, 메시지 버퍼링이 필요할 때
- SNS를 사용해야 하는 상황 : 실시간 알림, 이벤트 브로커, 다수의 수신자에게 동시에 메시지를 전송해야 할 때