MSA - MicroService Architecture 마이크로 서비스 아키택처

MSA를 설명하기 앞에 Monolithic Architecture에 대해 설명하겠다. (MSA가 등장한 이유)

 

Monolithic Architecture

 

Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다. 서비스를 구성하는 구성요소 비즈니스 로직, DB, UI 등은 논리적으로 모듈화하고 개발이 완료된 것을 하나의 결과물로 하나의 패키지에 담아 빌드하고 배포하는 방법입니다. 이런 방식을 어플리케이션으로 치면 모놀리식 어플리케이션이라 하며, 웹의 경우  Java라고 하면 일반적으로 Tomcat이나 Jetty의 웹서버에  WAR파일로 빌드되어 WAS에 배포하는 형태를 말한다.

프로젝트가 작고, 단순하고, 단기적으로 운영될 수록 좋다.

 

특징 및 장점으로는

여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있다.

Architecture가 간단하다.

유지보수가 용이하다

주로 소규모 프로젝트에서 사용된다.

 

하지만 일정 규모 이상의 서비스, 혹은 수백명 이상의 개발자가 투입되는 프로젝트에서 Monolithic Architecture는 한계를 보인다. 

단점으로는

개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 생겼을 때 등

부분 장애가 서비스 전체의 장애로 확대될 수 있다.

Monolithic Architecture에서는 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기 때문에 부분 Scale-out(여러 server로 나누어 일을 처리하는 방식)이 어렵다.

선정했던 framework가 Spring이면 blockchain 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적이다. (한 프레임워크에 종속적)

 

대규모 프로젝트에서의 단점

여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있어 서비스의 변경이 어렵고, 수정에 대한 영향 파악이 어렵다.

서비스/ 프로젝트가 커질수록 영향도 파악 및 전체 시스템 구조 파악이 어렵다.

작은 변경에도 높은 수준의 테스트 비용이 발생하기도 하며, 많은 사람이 하나의 시스템을 개발하여 배포하기 때문에 영향을 줄 수 밖에 없다.

프로젝트가 커짐에 따라 빌드 시간 및 테스트 시간, 배포시간이 기하급수적으로 늘어난다.

 

대규모 프로젝트에서의 Monolithic Architecture의 단점을 보완하기 위해 MSA가 등장하게 되었다. 기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise 서버 기반의 Monolithic Architecture에서 이제는 클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있다. 

 

그림으로 먼저 본다면 Monolithic Architecture와 MSA의 차이점은 이러하다.

MSA (MicroService Architecture)

MSA는 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크이다.

완전히 독립적 배포가 가능하고, 다른 기술 스택(개발 언어, 데이터베이스트 등)이 사용 가능한 단일 사업 영역에 초점을 둔다.

Monolithic Architecture와는 반대로 서비스나 프로젝트가 크고, 복잡하고, 장기적으로 운영될 수록 좋다.

MSA는 API를 통해서만 상호작용할 수 있다. 즉, MSA는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. MSA는 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 Kafka 등을 이용한 message stream을 주로 사용한다. 마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.

 

제대로 설계 된 MSA는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다. 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포, 영역의 한 부분에서만 책임을 담당한다.

 

어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다. 

 

각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모노리틱 아키텍쳐와 유사한 구조를 가진다.

 

MSA의 장점

 

특정 서비스에 대한 확장성이 용이하여 클라우드 사용에 적합한 아키텍쳐다.

 

어플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공하기 때문에 여러 어플리케이션에서 재사용할 수 있다.

 

각각의 서비스는 모듈화가 되어있으며 이러한 모듈까리는 RPC 또는 message-driven API등을 이용하여 통신한다. 이러한 MSA는 각각 개별의 서비스 개발을 빠르게 하며, 유지보수도 쉽게할 수 있도록 한다. 

 

팀 단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있다. 회사가 java의 spring 기반이라도 MSA를 적용하면 node.js로 블록체인 개발 모듈을 연동이 가능하므로 신기술 적용이 유연하고, 다양한 언어 사용 가능, 서비스를 polyglot하게 개발/운영 할 수 있다.

 

서비스별로 독립적 배포가 가능하다. 그래서 배포 시 전체 서비스의 중단이 없다. (다른 서비스에 대한 의존성이 최소화) 요구사항을 신속하게 반영하여 빠르게 배포가 가능하다.

각 서비스의 부하에 따라 개별적으로 scale-out이 가능하다. 메모리, CPU적으로 상당부분 이득이 된다.

각 서비스는 개별 프로세스로 구동, REST와 같은 가벼운 방식으로 통신, 부분적 장애에 대한 격리가 수월하다.

 

 

MSA의 단점

 

MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 한다.

 

서비스 간 호출 시 API를 사용하기 때문에 통신 비용, Latency가 그만큼 늘어난다.

 

모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스가 각각 달라 트랜잭션을 유지하기 어렵고, 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵다.

 

통합 테스트가 어렵다. 서비스 1개를 재배포 한다고 하면 다른 서비스들과의 연계가 정상적으로 이루어지고 있는지도 확인해야하기 때문에 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.