[MSA] MSA 역량 모델

마이크로 서비스는 표준 아키텍처나 표준 역량 모델이 부재입니다.

따라서 벤더 사 및 도서 등에서 역량 모델을 제공하고 있습니다.

 

 

예시 역량 모델) Rajesh RV 역량 모델

https://www.amazon.com/-/ko/gp/product/B01N3YVPJH/reef=dbs_a_def_rwt_hsch_vapi_tkin_p1_i1 

Amazon.com: Spring 5.0 Microservices - Second Edition: Scalable systems with Reactive Streams and Spring Boot eBook : V, Rajesh

 

예시 역량 모델을 보면 총 22개의 서비스로 구분되어 분리되어있습니다.

또한 22개의 서비스를 다시 큰 틀(역량)로 4개로 구분하여 분리하고있습니다.

 

 

• Supporting Capabilities (지원 역량) : 지원 기술 및 설계 패턴
• Core Capabilities (핵심 역량) : 서비스 별 배포되는 SW 패키지에 필수 요소
• Process & Governance Capabilities (프로세스 및 통제 역량) : DevOps 및 문서화 등
• Infrastructure Capabilities (인프라스트럭처 역량) : 컨테이너 및 컨테이너 오케스트레이션

 

Core Capabilities (핵심 역량)

단일 서비스 내에 패키징 되는 SW 컴포넌트들

예) 서비스 Listener, Endpoint, 서비스의 구현, 데이터 저장

 

 

서비스 Listener

• HTTP 등의 Listener 가 어플리케이션에 내장되어 있어야 합니다.
  • Web Server, Web Application Server
  • Spring Boot 와 같은 Self Contained 방식이 필요할 수 있음
• 이전에는 tomcat 등의 WAS 가 설치되어 있고 앱을 WAS에 배포하는 형식이였습니다.
• MSA 의 민첩한 배포, 운영의 장점을 살리기 위해서는 자체 내장형 Listener 가 필요합니다.

 

Endpoint

• HTTP 요청을 받아 처리 할 API 가 어플리케이션 내부에 있어야 합니다.
• 다양한 프로토콜 사용 가능
• 동기 / 비동기 방식 모두 사용 가능

 

서비스 구현

• 각 서비스의 핵심 로직을 구현
• 서비스의 로직은 단일 책임의 원칙을 지켜야 합니다.
• 서비스 로직은 최대한 응집도 높게 구현되어야 합니다.
• 계층형 아키텍처를 사용하는 것이 좋습니다.
• Hexagonal Architecture
  • 어플리케이션을 외부 기술과 분리시키는 패턴
• 비즈니스 핵심 로직이 외부 시스템에 영향을 받지 말아야 합니다.
  • DB를 무엇을 쓰던 비즈니스 핵심 로직이 변경되지 말아야 합니다.
  • Queue를 뭘 쓰던 비즈니스 핵심 로직이 변경되지 말아야 합니다.
  • 모바일 / 웹 등 UI에 따라서도 비즈니스 핵심 로직은 변경되지 말아야 합니다.

 

데이터 저장

• 각 서비스 마다 상태나 데이터를 저장할 데이터 소스가 있어야 합니다.
• 데이터 소스는 하나의 서비스에 한정되어야 합니다.
• 다양한 기술을 이용 가능 - Polyglot Persistence, NoSQL

 

 

Infrastructure Capabilities (인프라스트럭처 역량)

성공적인 MSA 구축 / 운영을 위해서는 인프라 역량이 필수적입니다.

예) 클라우드, 컨테이너 런타임, 컨테이너 오케스트레이션

 

 

클라우드

• 전통적 인프라 구성 (기존)
  • On Premise
  • 데이터 센터
• 클라우드 (최신)
  • On Demand
  • 대용량 확장 가능한 환경
• 프로세스
  • 장기 수요 예측
  • 용량 산정
  • 하드웨어 주문
  • 데이터 센터 입고
  • OS 설치, 네트워크 설정 등
• 몇 번의 클릭만으로 리소스 사용 가능
  • Auto Scaling 으로 자동화된 Provisioning
• 다양한 자원 / 서비스 제공
  • 컴퓨팅 자원, DB, NoSQL, Big Data, AI

 

컨테이너 런타임

• 각 서비스들이 다양한 기술 사용
• 수백 수천 개의 인스턴스에 배포할 수 있어야 합니다.
• 컨테이너 기술을 이용하여 빠른 환경 구성 및 배포가 필요합니다.
  • 컨테이너 이미지에는 런타임과 코드가 동시에 존재합니다.
• 대표적 기술 : Docker

 

컨테이너 오케스트레이션

• 많은 수의 컨테이너의 관리 역량이 필요합니다.
• 배포, 모니터링 등 운영 관리 비용을 최소화 하기 위함입니다.
• 대표적 기술 : Kubernetes, ECS, Mesos/Marathon

 

 

Supporting Capabilities (지원 역량)

Service Discover

• MSA를 도입하면 서비스 개수 및 인스턴스 개수가 급증할 수 있습니다.
  따라서 전체 Topology가 복잡해질 수 있습니다.
• 한 서비스에서 다른 서비스를 호출 시 물리적인 정보를 유지하는 것이 비효율적입니다.
• 중앙에서 시스템의 모든 서비스에 대한 정보를 유지
• 새로운 인스턴스가 생성되면 중앙 에이전트에게 자신의 정보를 등록
• 서비스 간에는 다른 서비스의 물리적인 주소를 유지하지 않습니다.
• 유연하게 인스턴스 및 서비스를 추가 삭제 가능합니다.

 

Config Server

• 기존에는 설정 정보를 자체 설정 파일(Pom.xml)이나 OS 환경 변수로 관리했습니다.
• MSA 를 도입하면 설정 관리가 복잡해집니다.
• 환경마다 매번 새롭게 빌드 / 패키징을 해야 되는 문제점이 있습니다.
• 서비스의 인스턴스가 100개라면 100개 모두 재배포가 필요합니다.
• 설정 파일이 잘못 관리 되면 서비스 장애 발생 가능성이 높습니다.
• 이러한 설정 관리에 대한 어려움을 완화시키기 위해 설정 정보를 Application 파일에서 완전히 분리시킵니다.
  • 중앙 Config Server 에서 설정 관리를 하고, 저장 BackEnd 로는 Git, DBMS 를 사용하기도 합니다.
  • 서비스는 Application 기동 될 때 중앙 서버에서 Config 정보를 Fetch
  • 설정 정보 변경 시 서비스 재배포 없이 반영 가능

 

Service Gateway

• 다양한 서비스들에 대한 단일 진입점
• 인증, 인가, 로깅, 필터링 등의 공통 처리 수행
• 서비스에 문제 발생 시 요청을 차단하거나 대안 경로로 변경하는 등의 기능

 

SW Defined Load Balancer

• MSA 에서는 인프라 토폴로지가 매우 복잡합니다.
  • 서비스 / 인스턴스 개수가 많고 서비스 간 의존성이 복잡하기 때문입니다.
  • 인스턴스들의 제거, 생성이 매우 빈번하게 일어날 수 있기 때문이기도 합니다.
• 전통적 로드밸런서 사용은 비효율적입니다.