용어정리
- MOM (Message Oriented Middleware, 메시지 지향 미들웨어)
- 독립된 어플리케이션 간에 데이터를 주고받을 수 있도록 하는 시스템 디자인
- 함수 호출, 공유메모리 등이 방식이 아닌, 메시지 교환을 이용하는 중간 계층에 대한 인프라 아키텍쳐 개념
- 분산 컴퓨팅이 가능해지며, 서비스간의 결합성이 낮아짐
- 지동기로 메시지를 전달하는 것이 특징
- Queue, Broadcast, Multicast 등의 방식으로 메시지 전달
- Pub/Sub 구조
- 메시지를 발행하는 Publisher(Producer), 메시지를 소비하는 Subscribe(Consumer)로 구성
- 독립된 어플리케이션 간에 데이터를 주고받을 수 있도록 하는 시스템 디자인
- Message Broker
- 메시지처리 또는 메시지 수신자에게 메시지를 전달하는 시스템이며, 일반적으로 MOM 기반으로 구축됨
- MQ (Message Queue, 메시지 큐)
- Message bBroker와 MOM을 구현한 소프트웨어 (RabbitMQ, ActiveMQ, Kafka 등)
- MOM은 메시지 전송 보장을 해야하므로 AMQP를 구현함
- AMQP (Advanced Message Queueing Protocol)
- 메시지를 안정적으로 주고박기 위한 인터넷 프로토콜
RabbitMQ, Kafka 등은 AMQP를 구현한 MOM 시스템이다.
메시징 시스템이란?
로그 데이터, 이벤트 메시지 등 API로 호출할 떄 보내는 데이터들을 처리하는 시스템
예를 들어, 다음과 같이 자동 메일을 발송 시스템이 있다고 가정하면,
- 회원가입을 했을 때, 이메일을 발송하는 MemberService
- 주문완료가 되었을 때, 이메일을 발송하는 OrderService
- 메일을 실제 발송하는 MailService
이렇게 서비스가 분리되었을 때 프로세스는 다음과 같이 처리될 수 있다.
- MemberService에서 회원가입, OrderService에서 주문완료 이벤트가 발생
- Messaging Client로 메일 전송에 필요한 데이터( 받는/보내는 사람 이메일 주소, 메시지 제목/내용 등.. )를 API 호출
- Messaging Client에서 MOM을 구현한 소프트웨어(ex. kafka)로 메시지를 생산
- MailService에서 메시지가 존재하는지 구독하고 있다가 메시지가 존재하면 메시지를 소비
- MailService에서 API 정보들을 통해 User에게 메일 발송
장점
- 서비스간의 결합성이 낮아지므로 각자의 비즈니스 로직에만 집중할 수 있다.
- 메시지 처리 방식은 Message Broker에 위임
- 각 서비스는 Client를 통해 메시지를 보내고 받기만 하면 됨
- 각 서비스는 비동기 방식으로 메시지를 보내기만 하면, Message Broker에서 순서 보장, 메시지 전송 보장 등을 처리
- 메시징 시스템이 잠깐 다운되어도 각 서비스에는 직접적인 영향을 미치지 않음
단점
- Message Broker 구축, 예를 들면 kafka 클러스터 구축에 필요한 금전, 인적 자원에 대한 비용
- 비동기의 양면성 - 정말 메시지가 잘 전달되었는가?
- 함수호출, 공유 메모리 사용 방식보다 메시징 시스템을 사용했을 때 호출 구간이 늘어나므로 네트워크 비용 발생
MOM, 메세지 지향 미들웨어(Message-Oriented-Middleware)
- 미들웨어: 어플리케이션들을 연결해 이들이 서로 데이터를 교환할 수 있게 해주는 소프트웨어
- 메시지 지향(=메시징 시스템): 메시지 API를 통해 각 분산되어 있는 어플리케이션간의 다리 역할을 함으로써 데이터를 교환 할 수 있도록 하는 시스템
메시지 지향 미들웨어란?
메시지를 통해 여러 분산되어 있는 시스템 간의 Connector 역할로 결합성을 낮추고, 이들이 서로 실시간 비동기식 데이터를 교환할 수 있도록 하는 소프트웨어
Message Queue 기반 패턴
메시지 대기열 패턴은 일종의 지점 간(peer to peer) 메시징 시스템이다. Queue 대기열의 메시지는 Consumer가 소비하면 지워지는 형태
소비하면 지워지는 형태라는 의미는 Producer 서버가 메시지를 Queue에 보내고 서버가 다운이 되도 Consumer가 소비하지 않았다면 Queue 대기열에 데이터가 존재한다는 걸 의미한다.
발행(Publish)-구독(Subscribe) 메시지 패턴
메시지 큐와 마찬가지로 메시지를 생산하는 Producer와 메시지를 소비하는 Consumer로 구성되어 있다.
차이점은 여러 소비자가 하나의 주제에서 각 메시지를 수신할 수 있다는 점. 또한 모든 Consumer가 메시지를 사용하는 경우에만 메시지가 대기열에서 지워진다.
kafka와 같은 메시징 시스템에는 메시지가 대기열에 있어야 하는 기간을 지정한 보존 정책이 있다. 따라서 메시지는 모든 Consumer가 소비하더라도 지정된 기간 동안 대기열에 사용할 수 있다.
언제 쓰이는가?
- 분산 시스템
- 여러 컴퓨터를 분산시켜 네트워크를 연결하여 데이터들을 나눠서 처리하면 서버의 과부하를 분산할 수 있으며, 성는개선과 장애요소를 최소화하기 위해 분산 시스템을 사용함
과거 분산 시스템의 단점과 웹 API 통신의 한계
과거 분산시스템의 단점
수많은 데이터를 처리하기 위하여 분산 시스템을 운영하였지만, 시스템이 거대해질수록 분산 시스템의 설계도의 복잡성 문제가 발생한다. 하나의 응용프로그램이 변경되면, 다른 응용프로그램에도 영향을 미쳐 분산 시스템 간의 결합도가 강한 단점을 가지고 있었다.
웹 API 통신의 특성
- MSA를 사용한 분산 시스템은 웹 API 서버로 요청 시 응답을 기다려야 한다.
- 여러 분산되어있는 서비스 간에는 실시간으로 비동기식으로 데이터를 처리해야 하기 떄문에 웹 API로도 비동기식 구현이 가능하지만 순서가 보장되지 않는다는 특성이 있다.
- 메시지를 보내는 A어플리케이션은 메시지를 보낼 때 B라는 어플리케이션의 목적지(도착점)을 알아야 통신할 수 있다.
- 두 어플리케이션간 불필요한 결합도가 발생되고, 응답을 취하는 B어플리케이션이 서버 장애시 요청되었던 데이터 때문에 A어플리케이션에게도 장애가 전파될 수 있다.
메시징 지향 미들웨어의 필요성
- 메시지 API는 비동기 프로토콜을 지원하며, 메시지 순서를 보장합니다.
- 메시지가 대기열에 전달되면, 응답을 즉시 할 필요가 없다.
- 메시지 대기열에 전달 된 상황이라면 메시지는 시스템에 보존되어 있어, 다른 어플리케이션간의 의존성이 낮게 된다.
Message Broker
송신자와 수신자 사이에서 메시지의 전달을 중재하는 컴퓨터 프로그램 모듈
메시지 브로커는 정형화된 메시지의 교환을 통해 어플리케이션간의 소통이 이뤚디는 네트워크 엘리먼드이다.
목적
메시지의 유효성, 정송, 라우팅을 위한 아키텍처 패턴
- 어플리케이션 사이의 커뮤니케이션 중재
- 어플리케이션간의 메시지 전달을 위한 상호 인식(mutal awareness)를 줄여 어플리케이션간의 결합성을 낮춘다(decoupling)
기능
- 엔드 포인트 분리
- NFR(non-functional requirement) 충조
- 중재함수 (intermediary function)의 간편한 재사용
- 하나이상의 목적지로의 메시지 라우팅
- 메시지의 형태 변형
- 메시지를 수집하여 여러 메시지로 분해하고 대상으로 보내 응답을 하나의 메시지로 재구성하여 사용자에게 반환
- 메시지 양 증가 또는 저장을 위한 외부 저장소와 상호작용
- 데이터 검색을 위한 웹 서비스 호출
- 이벤트 또는 에러의 응담
- 발행-구독 패턴을 활용한 컨텐츠와 토픽 기반 메시지 라우팅 제공
설계
- 허브 앤 스포크(hub and spoke)
중앙 서버가 통합 서비스를 제공하는 메커니즘으로 작동 - 메시지 버스(message bus)
메시지 브로커가 버스에서 작동하는 통신 백본 또는 분산 서비스