티스토리 뷰
1. What, 메시지 지향 미들웨어란?
1.1 미들웨어는 무엇인가요?
- 애플리케이션들을 연결해 이들이 서로 데이터를 교환할 수 있게 해 주는 소프트웨어
1.2 메시지 지향(=메세징 시스템)은 무엇인가요?
- 메시지API를 통해 각 분산되어 있는 어플리케이션간의 다리역할을 함으로써
데이터를 교환할 수 있도록 하는 시스템
1.3 고로, 메세지 지향 미들웨어란?
- 메시지를 통해 여러 분산되어 있는 시스템 간의 Connector 역할로 결합성을 낮추고,
이들이 서로 실시간 비동기식 데이터를 교환할 수 있도록 하는 소프트웨어
[MoM 구조]
1.4 메시지 전달방식
- Message Queue 기반 패턴
- 발행(Publish)-구독(Subscribe) 메세지 패턴
01. Message Queue 기반 패턴
- 메세지 대기열 패턴은 일종의 지점 간(peer to peer) 메시징 시스템입니다. Queue 대기열의 메시지는 Consumer가 소비하면 지워지
는 형태입니다. 소비하면 지워지는 형태라는 의미는 Producer 서버가 메시지를 Queue에 보내고 서버가 다운이 되도 Consumer가
소비하지 않았다면 Queue 대기열에 데이터가 존재한다는 걸 의미합니다. (우체국 시스템을 생각하시면 될 것 같습니다. 우편함에
우편물이 일종의 Message라고 하면 소비자가 우편함에서 꺼내가지 않는 이상 해당 우편물은 계속 우편함에 있습니다.)
02. 발행(Publish)-구독(Subscribe) 메세지
- Message Queue와 마찬가지로 메세지를 생산하는 Producer와 메세지를 소비하는 Consumer로 구성되어 있습니다. 하지만 차이점
은여러 소비자가 하나의 주제에서 각 메시지를 수신할 수 있다는 점입니다. 또한, 모든 Conumer가 메시지를 사용하는 경우에만
메시지가 대기열에서 지워집니다.
(Kafka와 같은 특정 메시징 시스템에는 메시지가 대기열에 있어야 하는 기간을 지정한 보존정책이 있습니다. 따라서, 메시지는 모든
Conumer가 소비하더라도 지정된 기간 동안 대기열에 사용할 수 있습니다.
위의 두 가지 패턴 방식은 3,4 번 목차에서 자세히 다루겠습니다.
2. When, 언제 왜 쓰이나요?
우선 분산 시스템 , 과거 분산 시스템 단점과 현 웹API 서버의 특성, 메세징 시스템이 필요성 순서로 정리하겠습니다
2.1 분산 시스템
- 정보화시대에 기업이 다루는 데이터는 점차 거대해져서 대용량 데이터와 대용량 트래픽을 발생시킬 수밖에 없습니다. 이런 대용량 데
이터들을 하나의 컴퓨터 환경에서 처리를 하기에는 무리가 있습니다. 그래서 여러 컴퓨터를 분산시켜 네트워크를 연결하여 데이터들
을 나눠서 처리하면 서버의 과부하를 분산할 수 있으며, 성능개선과 장애요소를 최소화하기 위해 분산 시스템을 사용합니다.
2.2 과거 분산 시스템의 단점과 웹API 통신의 한계
2.2.1 과거 분산시스템의 단점
- 수많은 데이터를 처리하기 위하여 분산 시스템을 운영하였지만, 시스템이 거대해질수록 분산 시스템의 설계도의 복잡성 문제가 발
생합니다. 하나의 응용프로그램이 변경되면, 다른 응용프로그램에도 영향을 미쳐 분산 시스템 간의 결합도가 강한 단점을 가지고 있
었습니다.
2.2.2 웹 API 통신의 특성
- 마이크로 서비스 아키텍처를 사용한 분산 시스템은 웹 API 서버로 요청 시 응답을 기다려야 합니다. 여러 분산되어 있는 서비스 간에
는 실시간으로 비동기식으로 데이터를 처리해야 하기 때문에 웹 API으로도 비동기식 구현이 가능하지만 순서가 보장되지 않는다는 특
성이 있습니다.
- 메시지를 보내는 A어플리케이션은 메시지를 보낼 때 B라는 어플리케이션의 목적지(도착점)을 알아야 통신 할 수 있습니다. 이런 부분
은 두 어플리케이션간 불필요한 결합도가 발생되고, 응답을 취하는 B어플리케이션이 서버 장애시 요청되었던 데이터 때문에 A어플리
케이션에게도 장애가 전파될 수 있습니다.
2.3 메세징 지향 미들웨어의 필요성
- 메세지 API는 비동기 프로토콜을 지원하며, 메시지 순서를 보장합니다.
- 메세지가 메세지 대기열에 전달이 되면, 응답을 즉시 할 필요가 없습니다. (ex 상기의 우체국 예제와 메일시스템) 이렇게 메시지 대
기열에 메시지가 전달이 된 상황이라면 메시지(데이터)는 시스템에 보존되어 있어, 다른 어플리케이션간의 의존성이 낮게 됩니다.
3. 메시지 시스템 기본 컨셉
https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingComponentsIntro.html
해당 URL을 참고로 번역한 내용입니다. 저작권 문제시 삭제하겠습니다. 오역이 있을 수도 있으니 양해부탁드립니다.
① Channels - 메시지 어플리케이션은 Producer와 Consumer를 연결하는 가상 파이프 채널을 통해 데이터를 주고 받습니다. 새로 설치된
메시지 시스템에는 Channel이 포함되어 있지 않음으로, Producer와 Consumer 어플리케이션을 통신이 가능하도록 Channel
을 만들어야 합니다.
② Messages - 메시지는 Channel에서 데이터의 원자성(= 더이상 쪼개지지 않는) 패킷입니다. 따라서, 데이터를 전송하기 위해서 어플리케
이션은 데이터를 하나 이상의 패킷으로 분할하고 각 패킷을 메시지로 감싸서 채널에 전송해야 합니다. Consumer 어플리케
이션은 수신하기 위해 메시지에서 데이터를 추출 해야합니다. 메시지 시스템은 성공할 때까지 반복적으로 메시지를 전달
하려고 노력하는 특징이 있습니다.(즉, 일부 장애 발생시 전체적인 지연은 있지만, 결국 메시지 수신이 성공한다는 걸 의미
합니다.)
③ Multi-step delivery - 가장 간단한 경우는 메시지 시스템은 Producer 어플리케이션에서 Consumer 어플리케이션으로 직접 메시지를
전달하는 경우입니다. 그러나, Producer 어플리케이션에서 메시지가 전송 된 후 Consumer 어플리케이션이 메시
지를 수신하기 전에 메시지에 대한 조치가 수행될 필요가 많습니다. Consumer는 Producer와 다른 메시지 형식
을 갖을 수 있기 때문에 메시지에 대한 검증과 형식을 변환해야 할 수 있습니다. Pipes와 Filters 아키텍처는 채널
을 사용하여 여러 처리 단계를 함께 묶을 수 있는 방법을 설명합니다.
④ Routing - 대규모 분산 시스템을 갖추고 있는 기업환경에서는 메시지가 최종 목적지에 도달하기 위해 여러채널을 거쳐야 할 수도 있습
니다. 이런 대규모환경에서는 메시지의 경로 또한 복잡해서 Producer가 메시지를 Consumer에게 어떤 채널로 전달 하는지
알 수가 없습니다. 대신에 채널 토폴로지 탐색과 최종 Consumer 또는 다음 라우터로 전달할 수 있는 Message Router에게
Producer는 메시지를 전송합니다.
⑤ Transformation - 여러 어플리케이션이 동일한 데이터 형식이 아닐 수도 있습니다. Producer 어플리케이션은 메시지를 한가지 방법으
로 포맷하여 보내지만, Consumer 어플리케이션은 메시지 다른 방식으로 포맷할 수도 있습니다. 이를 조정하기 위해
메시지는 메시지를 한 형식에서 다른 형식으로 변환하는 중간 필터인 메시지 변환기를 거쳐야 합니다.
⑥ EndPoints - 어플리케이션과 메시지 시스템을 인터페이스 할 수 있는 내장 기능이 없습니다. 어플리케이션이 어떻게 작동하는지, 그리
고 메시지 시스템이 어떻게 작동하는지 둘다 아는 코드 층을 포함해야 하며, 둘이 함께 작동하도록 연결되어야 합니다. 다
리역할을 하는 코드는 어플리케이션이 메시지를 보내고 받을 수 있도록 조정된 메시지의 끝점입니다.
이러한 공통적인 메세지 기본 컨셉을 바탕으로 RabbitMQ, Kafka, ActiveMQ 등 각 벤더사들의 방식으로 캡슐화하여 API를 제공한다는 것을 추측할 수 있습니다.
목차1 Reference
https://jins-dev.tistory.com/entry/Message-Oriented-Middleware-및-Message-Queue-에-대한-설명[Jins' Dev Inside]
https://fightingaf.tistory.com/entry/middleware [fightingaf]
https://www.quora.com/What-is-the-difference-between-message-queue-pattern-and-publish-subscribe
https://streaml.io/media/img/message-queuing
https://www.quora.com/What-is-the-difference-between-message-queue-pattern-and-publish-subscribe
목차2 Reference
목차3 Reference
https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingComponentsIntro.html
'기타' 카테고리의 다른 글
| Java 기반 Spring설정(2) - JPA (0) | 2019.12.23 |
|---|---|
| Java 기반 Spring설정(1) - ApplicationContext설정 (0) | 2019.11.29 |