[업무지식] MSA (Micro Service Architecture) 이해하기

안녕하세요 서후아빠입니다. ^_^

이번 세션은 마이크로 서비스에 대해서 업무적으로 필요한 최소한의 개념에 대해서 간단히 정리해 보았습니다.

MSA 프로젝트를 성공적으로 수행하기 위해서는 고객 담당자 역할이 중요합니다. 자세한 내용은 본문을 참고하시기 바랍니다.

---

MSA 개요

Micro Service 핵심 : 스스로 돌아 갈 수 있는 작은 서비스, 독립적 배포 가능 (서비스 지향 아키텍처(SOA))

  - 참고 URL : https://martinfowler.com/articles/microservices.html

MSA 특징

  - API로만 통신 : 서비스 접근점(End point)를 API 형태로 노출

  - 하나의 기능만 수행

  - 애플리케이션은 항상 기술 중립적 프로토콜 사용 : 다양한 언어와 기술로 구축 가능

  - 가벼운 통신 아키텍처(REST 등) 및 메시지 스트림(Kafka 등) 사용

Monolithic Architecture : MSA 반대 개념,  소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태   - 소규모 프로젝트에 적합하며, 유지보수가 용이   - 규모 커질수록 시스템 파악이 어려워 유지보수 어려움 : 구조 파악, 변경, 배포, 확장, 장애 등 실제 현장에서는 지연 등의 이슈로 3rd party API Gateway를 도입하거나 API Gateway 대신에 ELB로 노출합니다.

MSA 장단점

구분	내용
장점	서비스간 의존성이 최소화되어 서비스별 개별 배포 가능 : 전체 서비스 중단 불필요 부분 서비스의 장애가 전체 서비스 장애로 연결되지 않음 특정 서비스에 대한 확장 용이 신기술 적용 용이
단점	상대적으로 복잡하여 설계의 어려움 API를 통한 서비스간 호출로 통신비용 및 Latency 증가 서비스 분리로 테스트 및 트랜잭션 복잡도 증가 여러 서비스에 분산된 데이터로 인하여 조회 및 데이터 정합성 관리의 어려움

MSA 아키텍처

Inner Architecture 설계 시 고려사항 (위 그림에서 남색 부분)

  - 비즈니스, 서비스간 종속성, 배포 용이성, 장애 대응, 운영 효율성 고려한 서비스 정의 (ex: 주문과 장바구니 분리여부)

  - 데이터베이스 정합성 보장 마련을 고려한 DB 액세스 구조 설계 

  - 서비스 내 API 설계 

  - 논리적인 구성요소들의 레이어 방식

Outer Architecture 기능

  - External Gateway : 호출된 API를 인증(권한 정책 관리, 사용자 인증)하여 적절한 서비스로 전달

  - Service Mesh : 마이크로 서비스 구성요소간 네트워크 제어 (라우팅, 트래픽 관리, 보안 등)

  - Rumtime Platfrom의 Container management : MSA에 적합한 Container base 운영 관리 

  - Backing Service : 애플리케이션 동작하며 통신하는 모든 서비스

  - Telemetry : 원격 모니터링(ex : CloudWatch), 로깅(ex : Amazon Elastic Search), 트레이싱(ex : Amazon X-Ray) 등

  - CI/CD Automation : 지속적인 통합/배포 자동화

트레이싱 (tracing) : 프로그램의 실행에 관한 정보를 기록하기 위한 로깅의 특별한 사용, 이 정보는 보통 프로그래머가 디버깅 목적으로 사용

External Gateway의 API Gateway vs Service Mesh

구분	API Gateway	Service Mesh
라우팅 주체	서버	요청하는 서비스
라우팅 구성요소	별도의 네트워크를 도입하는 독립적인 API Gateway	서비스 내 sidecar로 Local 네트워크 스택의 일부
로드 밸런싱	단일 접근점 (end point)  API Gateway 내 밸런서 기능 구성 통해 수행	Service Registry에서 서비스 목록 수신 sidecar에서 밸런싱 알고리즘 통해 수행
분석	API에 대한 사용자 및 공급자에 대한 모든 호출	Mesh 내 모든 마이크로서비스 구성요소

Service Mesh

구분	내용
Mesh-Native Code	프레임워크 기반의 프로그래밍 모델 : Service Mesh 구현하는데에 특화된 Code 필요 Microsoft Azure Service fabric, lagom, SENECA 등
Mesh-Aware Code	프레임워크 라이브러리를 사용 Spring Cloud, Netflix OSS(Ribbon/Hystrix/Eureka/Archaius), finagle 등   ※ Netfilix의 Prana는 sidecar 형태로 동작
Mesh-Agnostic Code (권고)	sidecar proxy 형태로 동작 : Service Mesh와 무관하게 Code 작성 가능 Istio/Envoy, Consul, Linkerd 등

sidecar proxy    - 서비스에 대한 모든(In/Out) 네트워크 트래픽 처리, 서비스 호출 시 sidecar proxy 통해 호출   - 개발자가 별도의 작업없이 서비스 연결뿐만 아니라, 로깅, 모니터링, 보안, 트래픽 제어 등 가능

일반적인 기능 

  - Service Discovery 

  - Load balancing (지연시간 기반 / 대기열 기반 )

  - Dynamic Request Routing

  - Circuit Breaking

  - 암호화 (TLS)

  - 보안

  - Health check, Retry and Timeout

  - Metric 수집

Service Mesh를 구현하기 위해서는 고객 담당자가 애플리케이션에 대해서 아주 상세하게 알고 있어야 합니다.  MSA 설계 자체는 근본적으로 고객이 현재의 애플리케이션을 쪼개는 작업이기 때문에 제대로 설계되지 않으면 특정 마이크로 서비스 배치 작업 중에 전체 서비스 장애를 초래할 수 있기 때문입니다. 만약, 고객 담당자가 애플리케이션에 대해서 상세하게 모르는 경우는 절대로 MSA 아키텍처 사업을 진행하면 안됩니다.

Backing Service

MSA는 서비스간 결합도 낮아야 하므로 Message queue 활용한 비동기 통신 패턴 많이 사용

  - Message Queue(MQ) : 메세지 발행하는 생산자(producer, publisher), 메세지 받는 소비자(consumer, subscriber) 사이에 위치

  - Micro Service 이벤트(장애 발생, 트래픽 증가, 소스 반영 등) 발생 시 Micro Service 오케스트레이션 진행 : 마이크로서비스의 신규 생성, 재생성, 서비스 인스턴스의 삭제 등의 작업 빈번히 발생

  - MQ 종류 : Apache Kafka, RabbitMQ, ActiveMQ 등