메시지 기반 아키텍처는 대규모 및 복잡한 시스템에 아주 잘 맞는 설계 방식입니다.
이유는 다음과 같습니다.
1. 디커플링
메시지 기반 아키텍처는 서비스간 결합도를 낮춥니다.
온라인 쇼핑몰로 예를 들겠습니다. 주문 시스템, 재고 관리 시스템, 배송 시스템 등 여러 서비스로 구성될 수 있습니다. 이 서비스들이 서로 밀접하게 연결되어 있다면, 각 시스템은 다른 시스템의 상태와 행동에 대해 알아야하며, 이는 시스템 간의 강한 결합을 의미합니다.
예를 들어, 배송 시스템이 주문 시스템에 직접적으로 연결되어 있고, 주문이 이루어질 때마다 즉시 배송 프로세스를 시작한다면, 주문 시스템의 변경이 배송 시스템에 영향을 줄 수 있습니다. 주문 시스템에 문제가 발생하면 배송 시스템도 문제가 발생하거나, 주문 시스템의 로직이 변경되면 배송 시스템도 수정해야 할 수 있습니다.
그런데 메시지 기반 아키텍처를 도입하면 이러한 결합도를 낮출 수 있습니다. 주문 시스템이 주문이 발생했음을 메시지로 발행하고, 배송 시스템이 이 메시지를 구독해서 처리한다면, 두 시스템은 각자의 일을 독립적으로 처리할 수 있게 됩니다. 주문 시스템은 주문 처리 로직에만 집중하며, 배송 시스템은 배송 로직에만 집중할 수 있습니다.
이렇게 메시지를 통한 비동기 통신이 가능하면, 한 시스템의 변화가 다른 시스템에 미치는 영향을 최소화하며, 각각의 시스템을 독립적으로 확장하거나 수정할 수 있게 됩니다. 이것이 메시지 기반 아키텍처를 통한 디커플링의 예입니다.
2. 확장성
여기에서 주문 처리 시스템이 매우 많은 주문을 처리해야하는 경우를 생각해봅시다. 사람들이 블랙 프라이데이 같은 특정 시기에 많은 주문을 할 경우, 주문 처리 시스템에 많은 부하가 발생할 수 있습니다.
메시지 기반 아키텍처를 사용하면 이러한 확장성 문제를 해결할 수 있습니다. 주문이 발생할 때마다 주문 정보를 메시지로 변환하고 메시지 큐에 추가합니다. 그런 다음, 여러 개의 주문 처리 인스턴스가 동시에 메시지 큐에서 메시지를 가져와 처리할 수 있습니다.
증설된 시스템들은 Message Broker에 "Subscriber" 로 등록만 해주면 증설작업이 끝납니다.
이렇게 하면, 트래픽이 많이 발생하는 시간에는 주문 처리 인스턴스를 추가로 배포하여 처리 능력을 증가시킬 수 있습니다. 트래픽이 줄어들면 인스턴스를 줄여서 리소스를 절약할 수 있습니다. 이것이 메시지 기반 아키텍처를 통한 확장성의 예입니다.
이처럼, 메시지 기반 아키텍처는 시스템의 확장성을 향상시키고, 불규칙한 트래픽 패턴에 대응할 수 있게 해줍니다.
3. 높은 가용성
다시 온라인 쇼핑몰의 주문 처리 시스템과 배송 시스템 예시로 돌아가보겠습니다. 이 두 시스템이 강하게 연결되어 있다고 가정합시다. 이 경우, 배송 시스템에 문제가 생겨 5분동안 다운되면 주문 시스템에서 배송 시스템으로 5분동안 보낸 데이터가 유실될 수 있습니다.
하지만 이 두 시스템이 메시지 기반 아키텍처로 연결되어 있다면, 배송 시스템이 5분간 다운 되더라도 메시지 큐에 보낸 데이터가 쌓여있기 때문에 데이터가 유실되는 것을 방지할 수 있습니다.
주문 시스템은 주문이 발생할 때마다 메시지를 생성하고 이를 메시지 큐에 추가합니다. 이 때, 배송 시스템이 일시적으로 다운되어 있어도,
메시지 큐를 통해 데이터를 주고받기 때문에 주문 시스템에서 배송 시스템으로 보내는 데이터가 유실되는 것을 방지할 수 있습니다.
배송 시스템이 다시 정상 작동하게 되면, 메시지 큐에 있는 메시지들을 차례대로 가져와서 처리를 시작합니다. 이렇게 메시지 큐를 활용하면, 배송 시스템의 일시적인 다운으로 인한 데이터 유실 문제를 방지하고, 높은 가용성을 확보할 수 있습니다.
4. 비동기 통신
메시지 기반 아키텍처는 서비스 간의 통신을 비동기식으로 처리합니다. 이는 위에서 설명한 디커플링으로 처리한다는 의미입니다.
온라인 쇼핑몰의 주문 처리 시스템과 배송 시스템을 다시 예로 들어보겠습니다. 이 두 시스템이 메시지 기반 아키텍처로 연결되어 있다면, 주문 처리 시스템은 주문 정보를 메시지로 변환하고 메시지 큐에 추가하기만 하면 됩니다. 그 후, 이 메시지를 언제, 어떻게 처리할지는 배송 시스템이 결정합니다.
이렇게 비동기 통신을 통해 각 시스템은 서로 독립적으로 작동하며, 서로의 상태나 처리 시간에 영향을 받지 않습니다. 이는 서비스의 확장성, 유연성, 그리고 장애 격리를 향상시킵니다.
예를 들어, 배송 시스템이 잠시 부하가 많아 처리 시간이 길어져도, 주문 처리 시스템은 계속해서 주문 정보를 메시지로 생성하고 큐에 추가하여 지연 처리가 가능합니다.
메시지 브로커
메시지 브로커로는 RabbitMQ, Amazon SQS, Kafka 등이 있습니다.
RabbitMQ는 Advanced Message Queuing Protocol 를 지원하며 신뢰성이 좋습니다.
Kafka는 높은 처리량과 실시간 처리를 지원하며, 스트림 처리, 병렬처리가 가능합니다.
Amazon SQS는 AWS의 완전 관리형 메시지 큐 서비스로, 서버리스 아키텍처에 사용합니다.
'Architecture' 카테고리의 다른 글
Kafka의 고가용성: 장애 대응 및 데이터 손실 방지 (0) | 2023.08.08 |
---|---|
DB 성능 저하 해결 전략: 스케일링, 리플리케이션, 샤딩 그리고 클러스터링 (1) | 2023.08.04 |
자바 빌더 패턴: 객체 생성 (0) | 2023.07.22 |
자바 데코레이터 패턴과 람다 예외 처리: 코드 가독성을 높이는 방법 (0) | 2023.07.14 |
Sharding Storage + Spring + JPA (분산저장). 1부 (1) | 2023.03.25 |