MSA(Micro Service Architecture)
하나의 클라이언트(UI)에 기능별로 세분화된 여러 서버를 사용하는 것. 모바일 게임 접속 → 인증서버를 통해 인증 → 커뮤니케이션 서버 → 컨텐츠 서버 → PVP서버 .. 여러 서버에서 데이터를 받아서 클라이언트에 뿌려줌.
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.
가장 최근 온라인 구매 사이트에 방문했던 때를 떠올려 보세요. 제품을 검색하기 위해 사이트에 있는 검색창을 사용했을 것입니다. 이러한 검색이 하나의 서비스가 됩니다. 또한 구매자 선호도 데이터베이스에서 추출한 관련 상품에 대한 추천 내역을 볼 수 있습니다. 그것 역시 하나의 서비스입니다. 온라인 장바구니에 항목을 추가하셨나요? 마찬가지로, 그것 또한 하나의 서비스입니다.
이렇듯 마이크로서비스란 애플리케이션의 핵심 기능이며 다른 서비스들과 독립적으로 작동합니다. 그러나 마이크로서비스 아키텍처는 애플리케이션의 핵심 기능을 유연하게 결합할 뿐만 아니라, 불가피한 장애, 향후 확장 여부 및 새로운 기능 통합에 대비할 수 있도록 서비스 간 커뮤니케이션 및 개발팀의 구조를 조정하는 것입니다.
Monolithic 아키텍처
기존 legacy System의 경우 monolithic 아키텍처를 따르는 large 어플리케이션들은 다음과 같은 개발/운영상의 문제들에 직면하게 됩니다.
- 일부 모듈의 변경사항 때문에 전체 어플리케이션 개발/운영 프로세스와 패키징에 영향을 준다.
- 모듈별 특성에 맞는 신기술 또는 구조를 적용하기 어렵다.
- 모듈별 확장이 어렵다.
MSA의 특징
마이크로서비스 아키텍처의 특징은 다음과 같습니다.
-
애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공한다.
-
각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로서비스는 비즈니스 영역의 한 부분에서만 책임을 담당한다. 그리고 여러 애플리케이션에서 재사용할 수 있어야 한다.
-
마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.
-
애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
-
작고 독립적이며 분산된 마이크로서비스를 사용해 조직은 명확히 정의된 책임 영역을 담당하는 소규모 팀을 보유할 수 있다. 이 팀들은 애플리케이션 출시처럼 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.
MSA의 장단점
Microservice가 등장한지는 꽤 되었지만, 사실 중요성을 인지한지는 그리 오래되지 않았습니다. 다만 최근 MSA의 급격한 성장세에 너도나도 뛰어들고 있는 추세입니다. 그렇다면 왜 MSA를 사용하는가에 대한 의문을 갖게되는데요.
바로 다음과 같은 이유입니다.
- 작은 서비스들로 나누고, 각 서비스를 독립적으로 만듦 → loosely-coupled (이로 인해 오는 장점)
- 대용량 분산 환경에 적합
- 복잡도 감소
- 유연한 배포
- 재사용성 → 확장성
- 서비스별 hw/sw 플랫폼/기술의 도입 및 확장이 자유롭다.
- 개발자가 이해하기 쉽고 개발/운영 매 단계의 생산성이 높다.
- 지속적인 개발/디플로이가 biz capability 단위로 관련된 소수의 인원의 책임하에 이루어질 수 있다.
- fault isolation 특성이 좋다.
Microservice의 장점은 위와 같이 강력하지만 이는 단순히 장점만 포함하고 있는 것은 아닙니다. Microservice를 성공적으로 활용하기 위해서는 아래와 같은 문제에 대한 대책을 사전에 마련해야 합니다.
| 단점 | 보완방법 |
|---|---|
| 장애추적, 모니터링, 매지징이 어렵다. | Sleuth등과 ELK, EFK등의 서비스를 연동하여 사용하는 방안 고려 |
| 여러 서비스에 걸쳐져 있는 feature의 경우, 트랜잭션을 다루기 어렵다. | 보상 트랜잭션 또는 부분적으로 composite 서비스로의 병합 고려 |
| 여러 서비스에 걸쳐져 있는 feature의 경우, 테스팅이 복잡하다. | 테스팅 계획 및 방법에 노력 투자. |
| 서비스 간 dependency가 있는 경우 릴리즈가 까다롭다. | 관련 개발조직 간 roll-out 계획 마련 및 dependency의 명백한 관리 |
| 서비스 개수가 많고 유동적이기때문에 Continuous Integration/Delivery 및 서비스 관리 상의 문제가 발생할 수 있다. | 서비스 레지스트리, 모니터링, 개발~디플로이 자동화 기술 고려 (PaaS 고려) |
| monolith로 시작한 시스템을 Microservices로 전환할 때 큰 고통이 수반될 수 있다. | B2C웹 또는 SaaS 어플리케이션은 처음부터 Microservices 및 서비스별 조직 구성 고려 |
