MSA 아키텍처 스타일

이벤트 기반 아키텍처 스타일 

MSA의 기본이며 많이 사용되는 아키텍처는 이벤트 기반 아키텍처 스타일이다.

이벤트 기반 아키텍처 스타일은 확장성이 뛰어나고 고성은 애플리케이션 개발에 널리 쓰이는 비동기 분산 아키텍처다.

 

동기랑 비동기의 차이는 업무 처리 속도이다. 

예를 들어 커피숍에 1명이 주문과 커피내리는 행위를 다 한다고 생각하면 1시간 동안 처리할 수 있는 주문량은 매우 적을 것이다.

하지만 주문자와 바리스타를 따로 고용하여 서로 맡은 업무만 처리하도록 하면 훨씬 많은 양의 주문를 받을 수 있고 손님이 몰릴때 상황에 맞게 주문자를 늘리거나 바리스타를 늘려 모든 주문량을 소화할 수 있게 확장할 수도 있을 것이다. 

 

이벤트 기반 아키텍처는 다른 아키텍처에 내장이 가능한다. 그 예로 이벤트 기반 마이크로서비스 아키텍처가 있다. 

 

이벤트 기반 아키텍처를 크게 두가지 형태가 있다.

1. 각 서비스가 자율적으로 이벤트를 처리하는 방식 

2. 하나의 통제 모듈을 통해서 하는 방식

 

아래 사진은 1번 방식에 대한 그림이다.

화면처럼 영역별 프로세스를 분리하여 내부 처리는 동기식으로 진행할 수 있고 각각의 분리된 마이크로서비스는 이벤트를 통해 비동기식으로 서로 통신하면서 업무처리 속도를 올릴 수 있다. 

 

주문, 배송, 메일링 처리를 하는 각각의 이벤트 프로세서가 있다고 생각하고 주문을 통해 주문처리가 완료되면 주문 완료 데이터를 이벤트 채널 큐에 넣는다. 그다음 배송과 메일링 프로세서가 해당 큐에 있는 주문완료 데이터를 가져다가 각자 배송과 고객 메일 전송 업무를 처리할 수 있다.

 

여기서 서비스별 이벤트를 발생하는 매개체인 이벤트채널로는 RabbitMQ, 카프카 등이 있다.

장점 : 성능, 확장성 (의존성이 없기 때문에), 응답성

단점 : 트랜잭션 통제 어려움, 교착상태, 데이터 비일관성, 에러처리 어려움 (메세지 유실, 통신 장애)

 

아래 그림은 2번째 방식인 중재자를 둔 오케스트레이션 이벤트 기반 아키텍처 스타일 그림이다.

이 방식은 1번 방식의 단점인 트랜잭션 관리의 어려움을 해결할 수 있다. 

중간의 이벤트 중재자를 통해 상태를 보고 처리 순서대로 이벤트를 발생시킴으로 데이터 비일관성이나 트랜잭션 관리의 어려움은 없지만, 

이벤트 중재자가 처리하는 부분에 대한 병목현상이 발생할 수 있고 확장성을 가져가기 어렵다.

이벤트 중재자는 보통 아파치 카멜, 스프링 인티그레이션을 사용한다.

 

공간 기반 아키텍처 스타일

이벤트 기반 아키텍처를 극대화한 아키텍처는 공간 기반 아키텍처 스타일이다.

올림픽 예매 시스템, BTS 콘서트 예매 시스템 같이 유저가 급격하게 많이 몰리거나 가늠하기 어려운 애플리케이션에 많이 사용하는 설계 방식이다. 

 

처리는 캐시를 통해 빠르게 처리하고 데이터 처리는 별도의 데이터 펌프를 통해 이벤트 채널에 데이터를 넣어두고 나중에 처리하여 속도가 굉장히 빠르며 트래픽이 몰리면 캐시 인스턴스만 복제하여 빠르게 대응할 수 있어 확장성이 매우 좋다. 

 

단, 데이터 처리를 나중에 진행함으로 데이터 일관성을 보장하기 어렵다.

 

이런 이벤트 기반 아키텍처 스타일은 대규모 서비스를 제공하는 쇼핑몰에서 많이 쓰이는데 예를 들어 아마존처럼 주문한 뒤 나중에 재고나 결제 상태를 보고 구매 확정을 안내는 경우 이벤트 기반 아키텍처로 설계되었을 확률이 높다.

 

마이크로서비스 기반 아키텍처 스타일

API 레이어가 필요하며 api 레이어는 스마트 endpoint 이면서 더미 파이프처럼 비즈니스 로직이 없이 가볍게 구성되어야 한다.

마이크로서비스에 각각 비즈니스로직을 넣어 각 엔드포인트들의 의존성을 낮춘다.

의존성이 낮다는건 각각 독립적이며 배포 및 유지보수가 쉽고 확장성을 높일 수 있다는 걸 의미한다.

 

마이크로서비스는 재사용보단 중복을 강조하는데 그 이유는 데이터베이스 격리를 위해서 필요하기 때문이다.

데이터 분리로 데이터 일관성을 맞추기 위해 이벤트 채널을 통해 데이터 동기화 작업을 진행한다.

 

최적의 아키텍처 스타일을 선택하기 위해선 아래의 내용을 고민해봐야 한다.

아키텍처 유형은 계속 변하고 새로운 유형들이 생기는데 그때마다 최신 아키텍처를 고집해야 할 필요는 없다.

회사의 도메인, 데이터 아키텍처, 조직 역량, 개발 프로세스에 따라 적절한 걸 선택해야 한다. 

 

크게 모노리스 vs 분산을 선택하고 데이터를 어디에 둘건지 서비스 간 통신 방법등에 따라 최적의 아키텍처를 선택하길 바란다.

 

 

 

[참고자료 및 강좌]

https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard

실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기 - 인프런 | 강의

이 글은 인프런 강좌 실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기 자료로 작성했습니다.