마이크로 서비스 아키텍처 (Microservices Architecture: MSA)

마이크로 서비스 아키텍처 (Microservices Architecture: MSA)는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 의미한다.

 

마이크로 서비스 아키텍처를 이해하기 위해서는, 모놀리틱 아키텍처(Monolithic Architecture)와 서비스 지향 아키텍처 (Service Oriented Architecture: SOA)를 함께 알아보자.

 

Monolithic vs SOA vs MSA

 

모놀리틱 아키텍처 (Monolithic Architecture)

 

Monolithic Architecture

 

모놀리틱 아키텍처 (Monolithic Architecture)는 기존의 전통적인 시스템 개발 스타일로, 하나의 애플리케이션 내에 모든 로직이 들어가 있는 구조로 구성되어 있다. 이렇게 구성된 애플리케이션의 소스 코드는 하나의 프로젝트로 구성되어 있으며, 단일 패키지로 배포되게 된다.

 

이러한 구성의 애플리케이션은 로컬 환경에서 개발하기 편리하고, 통합 테스트를 수행하기에도 가장 쉬운 구조이며, 모든 코드가 하나의 묶음으로 구성되어 있기 때문에 배포도 매우 간편하다.

소수의 개발 인원이 아주 간단한 애플리케이션을 개발하는 경우에는 모놀리틱 아키텍처가 전혀 문제 되지 않는다. 하지만 애플리케이션의 서비스가 지속적으로 성장하여 대형 시스템이 될 경우, 아래와 같은 다양한 문제점이 발생한다.

 

• 빌드 및 배포 시간, 서버의 기동 시간이 오래 걸린다.
• 부분적 스케일 아웃이 어렵다.
• 안정성이 떨어진다.
• 간단한 기능 하나를 추가하기 위해서 많은 줄의 코드를 수정해야 한다.
• 작은 코드 수정 하나에도 반드시 통합 테스트를 수행해야 한다.
• 부분의 장애가 전체 서비스의 장애로 이어진다.

 

서비스 지향 아키텍처 (Service Oriented Architecture: SOA)

 

Service Oriented Architecture

 

서비스 지향 아키텍처(Service Oriented Architecture: SOA)는 대규모 시스템을 구축할 때의 개념으로 업무상의 일 처리에 해당하는 소프트웨어 기능을 비즈니스적인 용도로 분류하고 기능 단위로 묶어서 하나의 표준 Interface를 통해 각각을 "서비스"로 조합하는 것을 의미한다. 즉, 비즈니스적으로 구분된 서비스들을 느슨하게 연결하며, 각 컴포넌트를 독립적으로 운영하여 조립이 가능하게끔 하며, 각각의 비지니스 로직을 재사용할 수 있도록 한다.

 

 

마이크로 서비스 아키텍처 (Microservices Architecture)

 

Microservices Architecture

 

"the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."
참조 : https://martinfowler.com/articles/microservices.html

 

마이크로 서비스 아키텍처(Microservices Architecture)는 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하고, 각각의 서비스들이 API를 통해 서로 통신할 수 있도록 설계하는 패턴을 말한다. 각각의 마이크로 서비스는 그 크기만 작을 뿐, 하나의 모놀리틱 아키텍처와 유사한 구조는 갖는다. 다만, 하나의 서비스에서 처리해야 하는 기능과 규모가 작기 때문에 이를 마이크로 서비스라고 부른다. 이러한 MSA는 대규모의 복잡한 애플리케이션을 더 빠르고, 더 자주 배포할 수 있도록 한다.

 

MSA는 애플리케이션을 서비스로 나눈 다는 점에서 서비스 지향 아키텍처(SOA) 스타일의 한 종류로 분류되기도 하지만, 나누어진 서비스들을 어떻게 연결하는 방법에 있어 SOA와 차이점을 갖는다. 먼저, SOA는 애플리케이션을 서비스로 나눈 후, ESB(Enterprise SErvice Bus)라는 미들웨어에서 연결하고 조립해서 만든 반면, MSA는 중앙 집중적인 ESB 대신 REST API 또는 경량화된 메세징을 이용하여 각 서비스 중심으로 처리한다. (더군다나 구축된 각 서비스의 API는 외부로 오픈하여 다른 서비스와 함께 더 큰 가치를 만들거나 판매할 수도 있다.)

현재 Amazon, Netflix, eBay, Daum 등 수많은 글로벌 회사에서 MSA를 활용하여 서비스를 제공하고 있으며, 다양한 클라우드 서비스 (Amazon - Lambda, ECS, Route 53, MS Azure - service Fabric, AKS, Function, Google GCP - App Engine 등)에서 MSA를 위한 플랫폼을 지원하고 있다.

장점

MSA는 다음과 같은 장점을 갖는다.

 

• Improved fault isolation: 개별 서비스의 오류로 다른 서비스들이 크게 영향을 받지 않는다.
• Eliminate vendor or technology: 필요에 따라 개별 서비스에 새로운 기술 스택을 시험해 볼 수 있는 유연성을 제공한다.
• Ease of understanding: 개발자는 각 서비스의 기능을 더 잘 이해할 수 있다.
• Smaller and faster deployment: 작은 크기의 코드를 더 빠르게 배포할 수 있다.
• Scalability: 서비스가 분리되어 있으므로, 전체 애플리케이션이 아닌 필요한 서비스만 적절한 시간 동안 보다 쉽게 확장할 수 있다.

단점

MSA는 다음과 같은 단점을 갖는다.

 

• Communication between services is complex: 각 서비스 간의 (API를 통한) 통신부에 대한 추가 구현 (실패에 대한 처리 등)이 필요하다. 또한 사용자 응답 시간이 늘어날 수 있다.
• More services equals more resources: 여러 데이터베이스의 트랜잭션 관리가 어려워진다.
• Global testing is difficult: 서비스를 테스트하기 전에 해당 서비스의 종속 서비스에 대한 상태 확인이 필요하다.
• Debugging problems can ba harder: 디버깅을 위한 로그 정보 등이 각 서비스 별로 분산되어 존재하므로, 디버깅이 어려울 수 있다.
• Deployment challengers: 배포 시 각 서비스들의 조정 (배포 순서 등)이 필요할 수 있다.

필요한 기술들

MSA를 잘 적용하기 위해는 각 서비스들 간의 통신, 데이터 관리, 배포 전략 등에 다양한 기술들이 필요하다.

 

• REST: 각 서비스들은 대체로 REST API와 같이 가벼운 프로토콜을 이용하여 통신한다.
• API Gateway: 각 서비스들이 서로를 직접 호출하는 것이 아니라, API Gateway를 거쳐 통신하도록 한다. API Gateway는 부하를 분산시키는 로드 밸런싱, 캐싱, API 미터링, 모니터링 등 다양한 기능을 수행한다.
• VM/Docker: 각 서비스들은 편리한 배포 및 확장을 위하여 가상 머신이나 Docker 컨테이너 상에서 동작한다.

이 밖에도 Asynchronous Messaging, Service Discovery, Distributed Database 등 다양한 기술들이 MSA를 위해 사용될 수 있다.