MSA (Micro service architecture) vs monolithic

마이크로서비스(microservice)는 애플리케이션을 느슨히 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.
다소 어려운 부분이 있어 MSA 가 나오기 이전의 아키텍처를 살펴보겠습니다.

monolithic architecture

monolithic architecture 라고 불리우는 기존 아키텍쳐인데요, 하나의 또는 다수의 WAS 에 모든 컴포넌트가 하나의 인스턴스에 올라가있는 형태 입니다.

모든 컴포넌트가 하나의 프로젝트 Git Repository에 구성이 되어 있죠.

이러한 아키텍처는 하나의 컴포넌트에 문제가 발생되었을 때 다른 모든 서비스가 문제가 되는 상황이 발생하곤 합니다.

또한 특정한 서비스에 부하가 많이 걸리는 경우 그 특정 서비스에 대해 부분적인 확장이 어려워 전체 서비스에 대해 scale-out 이나 scale-up 을 해줘야 하는 단점이 있습니다. 

특히 common 과 같은 공통 모듈이 있는 경우 각각의 컴포넌트가 하나의 모듈에 강결합으로 연결이 되어 있어 서비스의 변경이 매우 어렵고, 수정 시 장애 영향도를 파악하기 힘듭니다.

작은 변경에도 높은 수준의 테스트 비용이 발생하며, 조직(개발자, 파트, 팀) 이 성장할 수록 배포의 대기 시간이 증가하게 되거나 big bang 형태로 배포를 해야하는 위험이 있습니다. 

MSA (Micro service architecture)

마이크로 서비스 아키텍쳐의 구조는 다음과 같은 모양을 따릅니다.

각 컴포넌트는 서비스 형태로 구현이 되고 API 를 이용하여 타 서비스와 통신을 합니다. 

배포 관점에서도 각 서비스는 각 WAS 에 독립적으로 배포가 됩니다. 확장을 위해서는 각 인스턴스는 scale-up 이 가능해지며, 앞단에 로드 밸런서를 배치하여 서비스의 로드를 분산 시킬 수 있습니다.

모노리틱 아키텍처에서는 하나의 스키마(데이터베이스) 에 모든 컴포넌트의 데이터를 저장을 했습니다.

마이크로 서비스 아키텍처의 경우 서비스가 API 부터 데이터베이스까지 분리하여 독립된 데이터베이스를 갖게 됩니다. 물리적으로 다른 DBMS 를 사용 할 수도 있겠지만 같은 데이터베이스를 사용하는 경우에도 스키마를 나누어 사용 합니다. 

이 경우 각 서비스들은 서로 의존성이 없고 독립적으로 운영이 가능하지만 다른 컴포넌트의 데이터를 API 를 통해서만 가져와야 하기 때문에 성능 문제를 발생 시킬 수 있고 이기종간 데이터베이스 트랜잭션이 보장 되지 않을 수 있습니다.

API Gateway

api Gateway 는 마치 프록시서버처럼 api 들 앞에 모든 api 에 대한 end point 를 통합하고 추가적인 기능도 제공하는 미들웨어 입니다. 

api gateway 로 크게 두 가지 문제점을 해결 할 수 있습니다.

1. Orchestration

open api의 mash up과 같은 개념입니다. 여러 개의 서비스를 묶어서 하나의 새로운 서비스를 만들 수 있는데요, 포인트 적립과, 물품 구매라는 서비스가 있을 때, 이 두 개의 서비스를 묶어서 “물품 구입시 포인트 적립”이라는 새로운 서비스를 만들어 낼 수 있습니다. 이러한 orchestration 기능은, api gateway를 통해서 구현될 수 있습니다.

2. Cross cutting function handling

API에 대한 인증 (Authentication)이나, Logging과 같은 공통 기능을 서비스 컴포넌트 별로 중복 개발해야 하는 비효율성을 유발할 수 있습니다.  api gateway에서 이러한 공통 기능을 처리하기 되면, api 자체는 비지니스 로직에만 집중을 하여 개발에 있어서의 중복 등을 방지 할 수 있습니다.

 

마이크로서비스 아키텍처의 장단점

 

분산 트랜잭션

모노리틱 아키텍처 같은 경우는 여러 서비스를 묶어 문제가 있으면 전체를 rollback 을 하면 되었는데,
API 기반의 마이크로 서비스 아키텍쳐의 경우는 여러 서비스를 하나의 트랜잭션으로 묶는 것이 불가능해졌습니다. 

첫번쨰로 마이크로 서비스 아키텍쳐의 경우, 금융이나 제조와 같이 트랜잭션 보장이 중요한 엔터프라이즈 시스템보다는 대규모 처리가 필요한 B2C 형 서비스에 적합하기 때문에, 아키텍쳐 스타일 자체가 트랜잭션을 중요시 하는 시나리오에서는 적절하지 않습니다.

두번째는 보상 트랜잭션 입니다. 예를들어 계좌 이체 시 돈을 뺀 후, 다른 계좌에 넣다가 에러가 났을 경우에, 명시적으로, 돈을 원래 계좌로 돌려주는 에러 처리 로직을 구현하면 됩니다.

세번재는 복합 서비스를 활용하는 방법이 있는데, 복합 서비스란 트랜잭션을 묶어야 하는 두개의 시스템을 트랜잭션을 지원하는 네이티브 프로토콜을 이용해서 구현한 다음 이를 API로 호출 합니다.

마지막으로 XA(eXtended Architecture)와 같은 분산 트랜잭션 프로토콜을 써서 서비스를 개발하거나 또는 SAP나 Oracle 아답터와 같이 트랜잭션을 지원하는 네이티브 아답터를 사용하는 방법이 있으나 이는 다시 강결합이 발생되는 구조이므로 꼭 필요하지 않은 경우라면 사용하지 않는 것이 좋습니다.