728x90
메시징 시스템이란?
메시징 시스템은 발신자(Sender)와 수신자(Receiver) 간에 데이터를 메시지 형태로 교환하며, 어플리케이션 간 의존도를 낮추는 시스템입니다. 주로 비동기 통신을 지원하며, 실시간 데이터 스트리밍과 대규모 데이터 처리를 관리하는 데 사용됩니다.
메시징 시스템이 필요한 이유
1. 동기적 통신의 한계
기존 어플리케이션은 서로 직접 요청하고 직접 응답하는 구조였습니다. 이는 다음과 같은 문제가 있습니다.
- 하나의 시스템이 장애를 겪으면 전체 시스템이 영향을 받는 강한 의존성이 발생
- API 호출 중 서버가 응답하지 않으면 요청한 어플리케이션이 대기 상태에 빠짐
- 사용자 경험이 악화됨: 서버 응답 지연이 수 초만 발생해도 사용자 불만이 생김
예시: 서버가 다운되거나 느린 응답을 보이면, 사용자들은 해당 어플리케이션을 사용하지 않게 됩니다.
2. 강한 의존성
기존 시스템에서는 송신자와 수신자가 직접 연결되어 서로에게 강하게 의존했습니다.
- 수신자가 부하로 인해 비가용 상태가 되거나 오류가 발생하면 송신자가 보낸 데이터가 손실될 가능성이 높음
- 예를 들어, 결제 처리 중 데이터가 유실되면 치명적인 문제를 초래
- 또한, 코드 변경 시 연결되어 있는 어플리케이션의 코드를 변경해야하기에 유지보수가 힘들어짐
3. 과부하 및 처리량 증가
- 수신자가 대량의 요청을 동시에 처리해야 하는 경우, 과부하로 인해 서버가 다운될 수 있음
- 갑작스러운 트래픽 증가 상황에서도 안정적으로 시스템을 운영하기 어려움
4. 데이터 손실 방지
- 네트워크 장애나 시스템 다운 시 데이터 손실이 빈번히 발생
클라이언트의 장시간 대기 상태, 데이터 유실, 강한 의존성, 과부하 문제가 메시징 시스템이 필요한 주요 이유입니다.
메시징 시스템의 구조
- 메시지 브로커
- 메시징 시스템의 핵심 요소로, 생산자로부터 메시지를 받아 적절한 소비자에게 라우팅합니다.
- 생산자 (Producer)
- 메시지를 메시지 브로커에 보내는 어플리케이션 또는 시스템입니다.
- 소비자 (Consumer)
- 메시지를 메시지 브로커로부터 받아 사용하는 어플리케이션 또는 시스템입니다.
- 형식
- 메시지는 JSON, XML, 바이너리 데이터 등 다양한 형식으로 표현됩니다.
- 메시지 프로토콜
- 메시지의 형식, 구조, 내용을 정의하는 규칙입니다.
- 메시지의 전송, 수신, 처리 방법을 포함합니다.
- 메시지 큐
- 메시지 브로커가 메시지를 임시 저장하는 메커니즘입니다.
- 수신자가 준비되지 않은 경우에도 메시지를 안전하게 보관합니다.
- 메시지 토픽 (Topic : Pub/Sub)
- 생산자가 메시지를 게시하고, 구독자가 메시지 수신을 신청할 수 있는 명명된 채널입니다.
메시징 시스템의 동작 원리
- 메시지 생성
- 발신 애플리케이션에서 전달하려는 데이터를 메시지 형태로 생성합니다.
- 메시지는 JSON, XML, 바이너리 데이터 등 다양한 형식으로 표현됩니다.
- 메시지 전송
- 메시지를 메시지 브로커나 메시지 큐에 전송합니다.
- 브로커는 메시지를 수신하고 적절한 수신자에게 전달합니다.
- 메시지 큐잉
- 수신자가 즉시 처리하지 못하는 경우 메시지를 큐에 저장합니다.
- 큐는 메시지의 순서 보장 및 재시도 지원 기능을 제공합니다.
- 메시지 소비
- 수신자가 메시지를 큐에서 꺼내어(consume) 필요한 작업을 수행합니다.
- 메시지 처리가 완료되면 큐에서 삭제되거나 상태가 업데이트됩니다.
대표적인 메시징 시스템
- Apache Kafka
- 분산형 메시징 시스템으로, 대규모 실시간 데이터 스트리밍 및 로그 데이터를 처리하는 데 적합
- RabbitMQ
- AMQP(Advanced Message Queuing Protocol) 기반의 메시징 시스템으로, 메시지 라우팅 및 우선순위 처리에 강점
- ActiveMQ
- JMS(Java Message Service) 표준을 준수하는 메시징 시스템으로, 다양한 언어와 프로토콜을 지원
메시징 시스템의 단점
1. 복잡성 증가
- 메시징 시스템은 새로운 아키텍처를 도입하는 만큼 시스템의 복잡성을 증가시킬 수 있습니다.
- 메시지 브로커 설치 및 관리
- 메시지 큐 설정 및 모니터링
- 메시지 프로토콜과 형식 설계 등이 추가적으로 요구됨.
- 설계나 설정이 잘못되면 비효율적인 운영으로 이어질 수 있습니다.
2. 추가적인 인프라 비용
- 메시징 브로커와 큐를 운영하기 위한 서버 인프라가 필요합니다.
- 클라우드 기반의 메시징 시스템(Kafka, RabbitMQ 등)을 사용하는 경우에도 비용이 발생.
- 고가용성을 보장하기 위해 메시지 브로커를 복제하거나 분산 처리를 구현하면 비용이 더 증가할 수 있음.
3. 메시지 지연
- 메시징 시스템은 비동기 방식으로 동작하므로, 메시지가 즉시 전달되지 않고 지연될 가능성이 있음.
- 특히 대규모 트래픽 상황에서 큐에 쌓인 메시지가 소비자에 의해 처리될 때까지 시간이 걸릴 수 있음.
4. 운영 및 모니터링 필요
- 메시징 시스템은 설정과 모니터링이 중요합니다.
- 큐가 과도하게 쌓이거나 메시지가 유실되는 경우, 장애로 이어질 수 있음.
- 적절한 모니터링 도구와 경고 시스템이 필요.
- 예를 들어, Kafka는 파티션과 오프셋 등을 관리해야 하며 RabbitMQ는 큐의 상태를 지속적으로 확인해야 함.
5. 메시지 유실 가능성
- 설정이나 관리가 잘못될 경우 메시지가 유실될 가능성이 있음.
- 예: 브로커 장애, 네트워크 단절, 잘못된 큐 관리.
- 이를 방지하려면 내구성(durability)과 복제(replication) 설정이 필요하지만, 성능 저하를 초래할 수 있음.
6. 성능 병목 가능성
- 메시지 브로커 자체가 병목 지점이 될 수 있음
- 브로커의 처리량 한계를 초과하면 시스템 전체 성능이 저하될 위험이 있음
- 이를 해결하기 위해 분산형 메시징 시스템(예: Kafka)을 사용하나, 설정이 복잡해짐
7. 메시지 순서 보장 문제
- 일부 메시징 시스템에서는 메시지의 순서를 보장하지 않을 수 있음
- Kafka와 같은 시스템은 파티션 단위로만 순서를 보장
- 메시지 순서가 중요한 경우에는 별도의 설계가 필요
메시징 시스템 사용 시 조심해야 할 점
1. 적합한 시스템 선택
- 모든 메시징 시스템이 모든 요구사항에 적합하지 않음
- Kafka는 대규모 데이터 스트리밍과 로그 처리에 적합
- RabbitMQ는 메시지 라우팅 및 복잡한 워크플로 처리에 강점
- 요구사항에 맞는 시스템을 선택하지 않으면 불필요한 복잡성과 비용이 발생
2. 데이터 중복 처리
- 메시지 소비 중 장애가 발생하면 동일한 메시지가 다시 처리될 수 있음
- 일회성 처리(Exactly Once) 보장을 위해 추가적인 설계가 필요
3. 보안 문제
- 메시징 시스템이 민감한 데이터를 다룬다면 전송 암호화(TLS) 및 접근 제어가 필요
- 보안 설정이 미흡하면 데이터 유출 위험이 있음
4. 큐 관리
큐가 비정상적으로 커지면 성능 저하 및 메시지 전달 지연이 발생
- 큐 크기 제한 및 메시지 TTL(Time-To-Live)을 적절히 설정해야 함
5. 장애 복구 전략
- 브로커 장애 시 메시지 유실이나 지연이 발생할 수 있으므로, 장애 복구 전략과 백업이 중요
- 예: Kafka의 Replication Factor 설정
728x90