MSA 아키텍쳐의 이해

MSA는 Micro Service Architecture의 줄임말로, 독립적으로 배포가 가능한 각각의 기능을 수행하는 서비스로 이루어진 프레임워크라 볼 수 있다.

MSA는 하나의 큰 아키텍쳐를 작은 애플리케이션으로 분리하여 독립적으로 배포 및 변경이 가능하도록 만든 아키텍쳐.

MSA는 해당 아키텍쳐의 등장 배경을 알면 보다 쉽게 이해할 수 있다.

MSA의 등장 배경

MSA가 등장하기 전 대부분의 소프트웨어는 Monolithic Architecture의 형태로 개발이 되어져왔다.
Monolithic Architecture는 소프트웨어의 모든 구성요소가 하나의 프로젝트에 통합되어 있는 형태이다.
Monolithic Architecture의 경우 단순한 아키텍처 구조로 인해 개발에 용이하고, 어떤 서비스이던지 개발되어 있는 환경이 동일하기 때문에 개발 및 배포가 간단하고 로드 밸런스를 이용하여 로드 부하를 나눠 가지는 방식으로 진행하기 때문에 확장성이 쉽다는 장점이 있다.

그러나 규모가 큰 서비스의 경우 Monolithic Architecture는 치명적인 한계가 존재한다.

• 서비스의 규모가 커질수록 전체 시스템의 구조의 파악에 어려움이 생긴다.
• 수정사항이 작더라도 전체를 다시 빌드한 후 배포해야한다.
  (이때문에 배포 시간이 오래 걸린다.)
• 모든 구성요소가 하나로 통합되어 있기 때문에 기술 스택이 한번 결정되면 바꾸기 어렵다.
• 같은 이유로 하나의 프로젝트로 통합되어 있기 때문에 많은 양의 코드가 몰려있어 구조를 이해하기 힘들고 유지 보수가 힘들다.
• 전체 애플리케이션의 확장은 쉽지만, 각 컴포넌트를 독립적으로 확장하기에 어렵다.

이러한 단점을 전반적으로 살폈을 때, Monolithic Architecture는 유저의 요구사항을 빠르게 적용할 수 있도록 서비스를 수정하는 Cycle term이 길다는 점에서 비즈니스 민첩성이 떨어진다는 것을 파악할 수 있다.
물리적 서버에 의존하던 on-premise 서버 기반의 Monolithic Architecture의 문제점들을 보완하기위해 클라우드 환경을 통해 서버를 구성하는 MSA가 등장하게 되었다.

MSA의 특징

MSA Architecture

MSA는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 형태를 말한다. MSA는 API를 통해서만 상호작용할 수 있으며, 서비스의 end-point를 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다.

• 각각의 서비스는 크기가 달라질 뿐, 하나의 모놀리식 아키텍쳐와 유사한 구조를 가진다.
• 각각의 서비스는 독립적으로 배포가 가능하다.
• 각각의 서비스는 다른 서비스에 대한 의존성이 작아야 한다.
• 각 서비스는 개별 프로세스로 구동되며, REST API와 같은 가벼운 방식으로 통신되어야 한다.

MSA의 장점

• 각각의 서비스가 모듈화되어 있어 API등을 통해 통신한다. 각각 개별의 서비스 개발을 빠르게 할 수 있으며, 유지보수 또한 쉽게 할 수 있다.
• 마이크로 서비스 단위로 기술 스택을 다르게 구성할 수 있다.
• 서비스 별로 독립적인 배포가 가능하다. 따라서 모놀로식에 비해 지속적인 배포 CD가 가볍다.
• 각 마이크로 서비스는 서비스의 부하에 따라 개별적으로 Scale-Out이 가능하다.

MSA의 단점

• 모놀로식에 비해 많이 복잡하다. 서비스가 분산되어있기때문에 내부 시스템의 통신을 어떻게 가져가야할지 일일이 정해야 한다. 특히 통신 장애 및 서버 부하가 걸릴 경우 트랜젝션을 어떻게 유지할 것인지에 대해 결정하고 구현해야한다.
• 서비스 간에 호출 시 API를 사용하기 때문에 통신 비용과 지연시간이 증가한다.
• 데이터가 여러 서비스에 걸쳐 분산되므로 한번에 조회하기 어렵고, 데이터 정합성을 관리하기 어렵다.
• 통합 테스트 및 END-TO-END 테스트 단위로 들어갈 경우 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 든다.
• MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스가 다르고, 각 서비스 간 연결 시 통신이 포함되기 때문에 트랜잭션을 유지하는 것이 어렵다.

이러한 이유로, MSA를 선택할 때에는 프로덕트의 구조와 시기에 따라 적절한 아키텍쳐를 선택해야 한다.

MSA? Monolithic?

하여, 다음과 같은 관점을 비교하여 장점이 더 많은 경우 MSA 아키텍처로 전환하는 것이 적절하다.

1. 모놀리식에 비해 MSA 아키텍쳐가 더 비용을 절감할 수 있는가?
2. MS를 요구할만큼 시스템 복잡도가 높은가?(MS가 외려 서비스의 생산성을 해치지는 않는가)
3. 개발팀에게 개발과 운영을 동시에 할만큼의 인프라가 준비되어 있는가?
4. 배포를 충분히 자주하고 있는가?
   MSA의 특성은 빠른 변화에 대응하기 위함인데, 배포가 자주 일어나지않는다면 매우 비효율적일 것.

MSA의 구조

MSA는 크게 내부 아키텍쳐와 외부 아키텍쳐로 나눌 수 있으며, 상단 이미지의 남색 부분은 내부 아키텍쳐, 회색 부분은 외부 아키텍쳐를 의미한다.

내부 아키텍쳐의 구조

내부 아키텍쳐는 내부의 서비스와 관련된 아키텍쳐로, 내부의 서비스를 어떻게 잘 쪼개는지에 대한 설계와 관련이 있다. 내부 아키텍쳐는 다음을 고려해야한다.

• 마이크로 서비스를 어떻게 정의할 것인가?
• DB 접근 구조를 어떻게 설계할 것인가?
• Micro Service 내 API를 어떻게 설계할 것인가?

내부 아키텍쳐는 비즈니스, 서비스, 시스템마다 각각의 특성이 있기 때문에 표준이 정해져있지 않다. 이때문에 MSA를 설계하는 데에 있어 가장 어려운 부분이기도 하다.

외부 아키텍쳐의 구조

외부 아키텍쳐의 구조는 크게 5가지가 있다.

• External Gateway
• Service Mesh
• Container Management
• Backing Service
• Telemetry
• CI / CD Automation

External Gateway

외부 게이트웨이는 전체 서비스의 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기위한 요소이다. 사용자 인증 및 권한 정책 관리 등을 수행하며, API 게이트웨이가 가장 핵심적인 역할을 한다.

external gateway

API 게이트웨이는 서버의 최앞단에 위치하여 모든 API 호출을 받는다. API 호출을 인증한 후, 적절한 서비스에 메시지를 전달한다.

Service Mash

Service Mash는 마이크로 서비스 구성요소 간의 네트워크를 제어하는 역할을 한다. MSA 내부에서 Micro Service 간의 통신을 담당하며, 이를 위해 Service Discovery, Routing, 트래픽 관리 등을 진행한다.

Container Management

각각의 애플리케이션의 개발환경을 관리하기 위해 컨테이너 기반 애플리케이션 운영을 기본으로 하며, 유연성과 자율성을 가진다.

Backing Service

Backing 서비스는 애플리케이션이 실행되는 가운데, 네트워크를 통해 사용할 수 있는 모든 서비스를 일컬으며 MySQL과 같은 데이터베이스, 캐시 시스템, SMTP 서비스 등 애플리케이션과 통신하는 Attached 자원을 지칭하는 포괄적인 개념이다.

대표적인 Backing 서비스의 예로 메시지 큐가 있으며, 메시지의 송신자와 수신자가 직접 통신하지 않고 큐를 이용해 비동기적으로 통신한다. 만약 메시지 큐를 사용하지 않는 결합 구조일 경우, 여러 서비스를 걸치는 실시간 트랜잭션을 처리할 때 하나의 서비스가 죽으면 트랜잭션이 끊어지기 때문에 해당 서비스 요청을 보존할 수 없다는 큰 문제가 발생한다.

Telemetry

tele(먼 거리) + metry(측정) 의 축약어로, 상당수의 마이크로 서비스가 분산환경으로 운영되는 상황에서 서비스의 상태를 일일이 모니터링하고 이슈에 대응하기 위해 환경을 구성하는 역할을 한다.

CI / CD Automation

지속적인 통합과 배포가 계속되는 MSA의 특성 상 코드의 기능 충돌 방지와 릴리즈 시간 단축을 위한 CI CD 구축은 필수나 다름없다.

CI CD Automation process