Micro Service Architecture

Micro Service Architecture (MSA)

• 독립적으로 디플로이할 수 있는 서비스들을 조합하여 큰 어플리케이션을 구성하는 아키텍처 패턴
• Gartner는 Inner Architecture와 Outer Architecture로 나눔
• Inner Architecture: Micro Service의 구조를 구현하기 위한 아키텍처
• Outer Architecture: Micro Service의 빠른 개발, 테스트, 배포, 운영과 확장성 확보를 위한 기능적, 운영 관점의 아키텍처. 서비스의 분산화로 인한 복잡도를 마이크로 서비스 외부에 위임

 

MSA의 구성 요소

1. API/Edge Gateway

• API Gateway는 API서버 앞단에서 모든 API 서비스들의 엔드포인트를 단일화하고 API에 관리 기능을 제공.
• API GW의 주요기능
  • 외부의 API 요청을 내부 API로 연계(Routing)
  • Service Mesh의 기능을 포함하여 API GW 또는 APIM으로 서비스 제공
  • 트래픽 관리
  • 권한 부여 및 액세스 제어
  • API 버전 관리
  • 모니터링

2. Service Mesh

• MSA의 핵심
• 서비스를 관리 및 운영하는 체계로 비즈니스 로직이 수행되면 이는 Database나 Message Queue등의 Backing service로 연결된다.
• 서비스에 대한 호출 및 트랜잭션 관리
• 주요 기능
  • 내부 서비스간 통신 관리 및 운용을 위한 서비스 제공
  • Service Router의 로드밸런싱
  • 서비스 식별(Service Discovery)
  • Configuration의 통합 관리

3. Container Management

• 마이크로 서비스를 물리적으로 적재하는 기반으로, 인스턴스를 실행하고 오케스트레이션하는 docker, kubernetes를 의미한다.
• 주요 기능
  • 컨테이너 자동 배치 및 복제, 로드밸런싱
  • 컨테이너 장애 복구/오토스케일링
  • 클러스터 외부 노출
  • 컨테이너 서비스 간의 인터페이스 제어

4. Backing Service

• 서비스 간 비동기 통신, 이벤트 전달 등을 위한 Message Queue / MOM 기반 서비스 제공
• 어플리케이션이 실행되는 가운데 서비스를 지원하는 서비스. 네트워크를 통해서 사용할 수 있는 모든 서비스를 지칭하기도 함
• database, message/queue, smtp, cache

5. Telemetry

• 분산된 서비스들의 status, 로그 확인 및 추적, 분석 효율성 확보를 위한 로그 취합/분석 도구
• 서비스와 연결된 모든 container에서 오는 container metric 추적
• application metric 수집

6. CI/CD

• 소스 commit부터 운영환경 배포시까지의 자동화된 절차와 도구

 

MSA의 장점

1. Polyglot Architecture

• 다양한 언어를 사용한 아키텍처. 프로그래밍 / DB가 각자 특성에 맞는 프로그래밍 언어 사용하여 더 좋은 품질의 서비스 제공

2. 실험과 혁신 유도

• 단순하고 크기가 작아 기업들이 적은 비용으로 새로운 프로세스, 알고리즘. 비즈니스 로직을 시험해볼 수 있음.
• 새롭고 실험적인 기능을 만들어 적용시켜보고 기대치에 부응하지 못하면 다른 마이크로 서비스로 변경하거나 대체 가능

3. 확장성

• 스케일 큐브(Scale Cube)

https://www.geeksforgeeks.org/the-scale-cube/

• x축 방향: 어플리케이션 복제하여 수평적 확장 
• y축 방향: 서로 다른 기능 분리(microservice)
• z축 방향: data partitioning, sharding
• y축 방향의 확장이 monolithic application에 적용되면 app에 담겨있던 기능들은 분리되어 비즈니스 기능에 맞게 더 작은 서비스들로 분리된다.
• y축 확장의 장점은 transaction에 대한 scale이 좋아지고, 결함을 고립시킬 수 있으며, cache hit rate를 증가시킨다.
• y축 확장의 단점은 이해하기 어렵고, 구현하는 데 많은 시간이 소요된다.

4. 대체 가능성

• monolithic architecture에서는 하나의 모듈을 교체할 때 시스템 영향도 파악이 어려워 많은 effort가 필요함.
• msa는 서비스 독립적으로 배포가 가능하기 때문에 대체가 쉬움

5. 유기적 시스템 구축 유도

• 유기적 시스템이란 시간이 지남에 따라 점점 더 많은 기능을 추가하면서 성장해가는 시스템
• 필요에 따라 서비스를 추가해도 기존 서비스에 미치는 영향도 최소화 가능

6. 기술 부채의 경감

• 수명이 다한 서비스에 교체애 대한 비용이 monolithic 구성보다 높지 않다.

7. 다양한 버전의 공존

• 서버를 무중단으로 버전 업그레이드 시에 이점이 있음.
• 기존 서비스와 신규 서비스가 공존한 상태에서 routing rule로 신규 버전의 서비스를 안정적으로 테스트/배포할 수 있다.(ex. canary deployment, blue/green)

 

MSA의 단점

1. 시스템의 복잡성

• 독립적인 서비스들의 협업을 통해 비즈니스가 처리되다 보니 시스템이 복잡하다.
• 한 비즈니스 프로세스를 파악하기 위해 여러 서비스들간의 협업을 파악해야 한다.

2. 트랜잭션 관리의 어려움

• 분산 환경이기 때문에 강력한 트랜잭션 일관성을 유지하기 어려움.
• 최종적인 일관성 제공을 위한 보상 트랜잭션 패턴과 같은 메커니즘이 필요함.
• 트랜잭션 무결성이 필요한 상황을 위한 메커니즘을 구현하는 데 많은 비용이 발생할 수도 있음.

3. 테스트의 어려움

• 의존성이 있는 서비스가 정상적이지 않은 경우에는 테스트가 어려움
• 개발자의 테스트 환경 구성 또한 어려움

4. 디버깅의 어려움

• 시스템의 문제가 발생했을 때 이를 파악하는 어려움
• 의존성 있는 모든 서비스들에 대해 문제 원인 파악을 수행해야 함