Microservice Architecture

출처: https://engineering.linecorp.com/ko/blog/detail/319

       http://bcho.tistory.com/948

- Monolithic Architecture: 하나의 애플리케이션 내에 서비스를 담는 개발 방법론으로서, 개발, 배포, 확장을 단순화하는 장점이 있다.

1. 정의:

   하나의 애플리케이션을 서비스 단위로 구분하여 하나의 기능에 대해 여러 서비스를 조합하여 제공하며 독립적으로 개발, 배포, 확장할 수 있는 개발 방법론.

2. 장점:

   - 코드 이해와 수정이 쉬워진다.

   - 어떤 기능에서 문제가 발생하더라도 다른 기능에 영향을 주지 않아 장애 처리가 쉬워진다.

3. 단점:

   - 성능 저하

     ㄴ서비스간의 호출을 API 통신을 이용하기 때문에 값을 json이나 xml에서 프로그래밍에서 사용하는 데이타 모델 (java object등)으로 변환하는 marshalling 오버헤드가 발생하고 호출을 위해서 이 메세지들이 네트워크를 통해서 전송되기 때문에 그만한 시간이 더 추가로 소요된다.

   - 메모리 요구량 증가

     ㄴ각 서비스를 독립된 서버에 분할 배치하기 때문에, 중복되는 모듈에 대해서 그만큼 메모리 사용량이 늘어난다.

   - 테스팅이 어려워진다.

     ㄴ서비스들이 각각 분리가 되어 있고, 다른 서비스에 대한 종속성을 가지고 있기 때문에, 특정 사용자 시나리오나 기능을 테스트하고자 할 경우 여러 서비스에 걸쳐서 테스트를 진행해야 하기 때문에 테스트 환경 구축이나 문제 발생시 분리된 여러개의 시스템을 동시에 봐야 하기 때문에 테스팅의 복잡도가 올라간다.

   - 운영이 어려워진다.

     ㄴ서비스 별로 서로 다른 기술을 사용할 수 있으며, 시스템이 아주 잘게 서비스 단위로 쪼게 지기 때문에 운영을 해야할 대상 시스템의 개수가 늘어나고, 필요한 기술의 수도 늘어나게 된다.

   - 서비스 간의 트랜잭션 처리가 어려워진다.

     ㄴMonolithic Architecture에서는 RDBMS를 사용하면서 하나의 애플리케이션 내에서 트랜잭션이 문제가 있으면 쉽게 데이타베이스의 기능을 이용해서 rollback을 할 수 있었다. 여러개의 데이타베이스를 사용하더라도, 분산 트랜잭션을 지원하는 트랜잭션 코디네이터 (JTS – Java Transaction Service)등을 이용해서 쉽게 구현이 가능했는데, API 기반의 여러 서비스를 하나의 트랜잭션으로 묶는 것은 불가능 하다. 쉽게 예를 들어서 설명을 하면, 계좌에서 돈을 빼는 서비스와, 계좌에 돈을 넣는 서비스가 있다고 하자. 이 둘은 API를 expose했을 때, 계좌에서 돈을 뺀 후, 계좌에 돈을 넣기 전에 시스템이 장애가 나면, 뺀 돈은 없어지게 된다. Monolithic Architecture를 사용했을 경우에는 이러한 문제를 트랜잭션 레벨에서 롤백으로 쉽게 해결할 수 있지만 API 기반의 Microservice Architecture에서는 거의 불가능하다. 

  이러한 문제를 해결하기 위해서 몇가지 방안이 있는데,

  그 첫번째 방법으로는 아예 애플리케이션 디자인 단계에서 여러개의 API를 하나의 트랜잭션으로 묶는 분산 트랜잭션 시나리오 자체를 없애는 방안이다. 분산 트랜잭션이 아주 꼭 필요할 경우에는 차라리 모노리틱 아키텍쳐로 접근하는 것이 맞는 방법이다. 앞서도 언급했듯이 마이크로 서비스 아키텍쳐의 경우, 금융이나 제조와 같이 트랜잭션 보장이 중요한 엔터프라이즈 시스템보다는 대규모 처리가 필요한 B2C 형 서비스에 적합하기 때문에, 아키텍쳐 스타일 자체가 트랜잭션을 중요시 하는 시나리오에서는 적절하지 않다.

  그럼에도 불구하고, 트랜잭션 처리가 필요할 경우, 트랜잭션 실패시 이를 애플리케이션 적으로 처리해 줘야 하는 데, 이를 보상 트랜잭션(compensation transaction)이라고 한다. 앞의 계좌 이체 시나리오에서 돈을 뺀 후, 다른 계좌에 넣다가 에러가 났을 경우에, 명시적으로, 돈을 원래 계좌로 돌려주는 에러 처리 로직을 구현해야 한다.

  마지막 방법으로 복합 서비스 (composite service)라는 것을 만들어서 활용하는 방법이 있는데, 복합 서비스란 트랜잭션을 묶어야 하는 두개의 시스템을 트랜잭션을 지원하는 네이티브 프로토콜을 이용해서 구현한 다음 이를 API로 노출 시키는 방법이다.

두개의 데이타 베이스는 XA(eXtended Architecture)와 같은 분산 트랜잭션 프로토콜을 써서 서비스를 개발하거나 또는 SAP나 Oracle 아답터와 같이 트랜잭션을 지원하는 네이티브 아답터를 사용하는 방법이다. 기존에 SOA에서 많이 했던 접근방법이기는 하나, 복합 서비스를 사용할 경우, 복합서비스가 서로 다른 두개의 서비스에 걸쳐서 tightly coupled하게 존재하기 때문에, 마이크로 서비스 아키텍쳐의 isolation(상호 독립적)인 사상에 위배되고 서비스 변경시에 이 부분을  항상 고려해야 하기 때문에 아키텍쳐상의 유연성이 훼손되기 때문에 꼭 필요하지 않은 경우라면 사용하지 않는 것이 좋다.