인프런 - AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
+ 요즘 개발자를 위한 시스템 설계 수업 (길벗)
메시지 큐 (Message Queue)
데이터를 비동기적으로 전달하기 위한 큐 시스템
Producer는 데이터(메시지) 생산을 Consumer는 처리를 담당합니다.
느린 작업을 분리하여 병렬 처리함으로써, 비동기 작업으로 시스템 성능 및 확장성을 크게 개선할 수 있습니다.
구성요소
Producer : 메시지를 생성, 큐에 삽입
Queue : 메시지를 저장하는 버퍼
Consumer : 큐에서 메시지를 가져와서 처리
Broker : 메시지를 관리하고 전달 (rabbitmq, kafka)
특징
비동기성 : 프로듀서와 컨슈머가 독립적으로 동작
내구성 : 메시지가 손실되지않게 보장
확장성 : 컨슈머 수를 늘려서 병렬처리를 가능케 합니다.
Queue System (큐 시스템)
큐 시스템은 큐 자료구조를 가진 모든 형태의 시스템이나 자료구조를 포괄적으로 의미합니다.
프로그램 내부의 메모리에서만 동작하더라도 큐 시스템이라고 볼 수 있습니다.
<> 메시지 큐 : 큐 시스템 원리를 사용해서 독립된 어플리케이션이나 서버끼리 데이터를 메시지 형태로 주고받을 수 있게 하는 미들웨어
큐를 활용하는 이점
부하관리 : 생성자와 소비자 사이에서 완충 역할을 하여 메시지가 폭등해도 시스템이 과부하나 영향을 주지 않습니다.
구성요소간 결합도 낮추기 : 각 부분이 독립적으로 동작합니다.
신뢰성과 일관성 : 큐를 사용하면 메시지가 안전하게 처리되도록 할 수 있습니다.
분산 큐 (Distributed Queue)
단일 큐 시스템 (단일 노드)가 아닌 여러 서버(멀티 노드)에서 동작하게 하는 큐 시스템입니다.
| 구분 | 일반 큐 시스템 (단일 노드) | 분산 큐 시스템 (클러스터) |
| 아키텍처 | 단일 서버에서 동작 | 여러 서버(Broker)가 클러스터로 묶여 동작 |
| 확장성 | 수직 확장 (Scale-Up: 서버 스펙 업) | 수평 확장 (Scale-Out: 서버 대수 추가) |
| 장애 대응 | 서버 다운 시 전체 시스템 마비 (SPOF) | 일부 노드가 죽어도 다른 노드가 대체 (HA) |
| 데이터 보관 | 메모리 또는 단일 디스크 의존 | 노드 간 데이터 복제(Replication)로 안전함 |
| 성능 (처리량) | 단일 서버의 한계치까지만 처리 가능 | 파티셔닝을 통해 수백만 TPS 이상 병렬 처리 |
| 대표 예시 | Redis Queue, 단일 노드 RabbitMQ | Apache Kafka, Amazon SQS, RabbitMQ Cluster |
분산 큐의 주요 특징
큐 관리자 : 큐에서 메시지 분배를 책임지는 핵심 구성요소
메시지 저장소 : 소비자가 메시지를 처리하기 전까지 보관되는 공간
로드밸런싱
장애 허용과 복구 : 시스템에 문제가 생겨도 안전하게 작동해야 합니다.
확장성 : 메시지와 소비자가 늘어도 성능 저하 없이 효과적으로 처리하고 확장 가능해야합니다.
분산 큐 시스템 아키텍처
메시지 전달 보장 방식 (Delivery Guarantees)
분산 환경에서는 네트워크 단절이나 서버 다운이 언제든 발생할 수 있습니다.
따라서 메시지 큐 시스템은 장애 상황에서 메시지를 어떻게 처리할지에 대한 3가지 보증 수준을 제공합니다.
| 보증 수준 (Level) | 핵심 개념 | 특징 (유실 / 중복) | 실무 활용 예시 |
| At-most-once (최대 한 번) |
메시지를 전송한 후 수신 확인(Ack)을 기다리지 않고 넘어감 | 유실: 발생 가능성 있음 중복: 절대 없음 |
초당 수만 건씩 쏟아지는 로그 수집, 인프라 상태(메트릭) 모니터링 |
| At-least-once (최소 한 번) |
수신 확인(Ack)이 올 때까지 메시지를 안전하게 재전송함 (기본 설정) | 유실: 절대 없음 중복: 발생 가능성 있음 |
주문 처리, 결제 요청, 알림 발송 등 데이터가 사라지면 안 되는 핵심 백엔드 |
| Exactly-once (정확히 한 번) |
트랜잭션 등을 활용해 유실과 중복 없이 완벽하게 단 1회 처리 보장 | 유실: 없음 중복: 없음 (단, 구현이 어렵고 성능 저하 큼) |
절대 1원의 오차도 허용되지 않는 은행 결제 및 금융 정산 파이프라인 |
분산 메시지 큐의 내부 동작 원리
대규모 트래픽을 처리하는 현대의 분산 메시지 큐(특히 Kafka 기반의 이벤트 스트리밍 플랫폼)는
성능과 확장성을 극대화하기 위해 다음과 같은 아키텍처 패턴을 사용합니다.
토픽(Topic)과 파티션(Partition)을 통한 트래픽 분산
토픽(Topic) : 메시지를 목적이나 성격에 따라 분류하는 논리적인 주제입니다.
파티션(Partition) : 하나의 토픽에 데이터가 너무 많이 몰리면 서버 한 대가 감당할 수 없습니다.
그래서 하나의 토픽을 여러 개의 파티션으로 쪼개어(Sharding) 여러 브로커 서버에 고르게 분산시킵니다.
이를 통해 트래픽이 늘어나면 단순히 파티션 개수와 브로커 서버를 늘려 무한에 가까운 수평 확장(Scale-Out)이 가능해집니다.
각 파티션 내부에서는 FIFO 원칙에 따라 메시지의 순서가 보장됩니다.
메시지 모델
큐 시스템의 메시지 전달 모델은 크게 한 명만 처리(Point-to-Point)하는 방식과 모두에게 방송(Pub/Sub)하는 방식으로 나뉩니다.
일대일 모델 (Point-to-Point) : 같은 소비자 그룹에 속한 워커들은 메시지를 서로 나누어 가집니다.
특정 파티션의 데이터는 그룹 내의 오직 한 워커만 읽을 수 있어, 작업이 중복 처리되는 것을 막습니다.
발행-구독 모델 (Pub/Sub) : 서로 다른 소비자 그룹은 각각 독립적으로 전체 파티션의 메시지를 모두 수신할 수 있습니다.
사례) 메시지 큐 + OLAP 데이터베이스
대규모 사용자 행동데이터(Clickstream), 인프라 로그, 시스템 메트릭을 수집 분석할 때
실무에서는 메시지 큐(Kafka, RabbitMQ 등)과 OLAP 데이터베이스 (Amazon Redshift, Google BigQuery 등)를 결합한 아키텍처를 표준처럼 사용합니다.
[ 웹/앱 서버 ] ──(실시간 로그)──▶ [ 메시지 큐 (Broker) ] ──(버퍼링/배치)──▶
[ 소비자 (ETL/Logstash) ] ──(Bulk Insert)──▶ [ OLAP (Redshift) ]
서버에서 Redshift로 바로 전달하지않고 중간에 메시지 큐를 두는 이유는,
1. OLAP 데이터베이스의 쓰기 특징 최적화
Amazon Redshift와 같은 OLAP DB는 수억 건의 데이터를 읽고 분석(Query)하는 데는 엄청나게 빠르지만,
데이터베이스 구조상 한 줄씩 실시간으로 데이터를 밀어 넣는(Row-by-row Insert) 작업에는 매우 취약합니다.
-> 메시지 큐가 데이터를 임시로 모아두고 소비자는 데이터를 청크로 묶어 Redshift에 한번에 적재 합니다.
2. 폭발적인 트래픽 완충
이벤트나 특정 기간 트래픽 폭주 시 댐역할을 해줍니다.
데이터 웨어하우스(Redshift)는 본인들이 처리 가능한 속도와 용량에 맞춰 데이터를 순차적으로 Pull 합니다.
3. 데이터 파이프라인 고가용성 및 유실 방지
타겟 DB가 일시적으로 죽어 있더라도, 앞단의 큐 시스템(특히 Kafka 같은 분산 큐)이 데이터를 디스크에 안전하게 보관하고 있습니다.
ect..
차후에는 kafka, KRaft, kafka stream, apache flink 등을 정리해볼까합니다.
'devops' 카테고리의 다른 글
| 일관된 해싱, 해시 링, 해시 슬롯 (0) | 2026.06.02 |
|---|---|
| [시스템설계] 분산캐싱 (1) | 2026.06.01 |
