MSA (Micro Service Architecture)

I. 대용량 분산 웹 서비스 위한, MSA의 개념

  • 소프트웨어를 독립적으로 배치 가능 단위로 분리하여 시스템을 구성하는 아키텍처

 

II. MSA 구성요소

가. MSA 구성도

  • API Gateway는 API 통신 중계, 공통 기능 추상화 역할

나. MSA 구성요소

구성요소세부 기능설명
API G/W– 라우팅
– 로드밸런싱
– 상호 독립적 API 서비스 중계
– 인증/로깅, 공통기능 추상화
API
Servers
– 비즈니스
  기능 분리
– 배포 가능한 단위로 분리
– 개별 서비스를 API형태 구현
Database– RDB, SQL
– NoSQL 등
– 각 API 서버에서 사용
– 다양한 기술 기반 DB
I/F 및
통신
– HTTP
– REST, JSON
– 표준 기반 경량 인터페이스
– 표준 기반 통신 규약
Client– Web
– Mobile
– 클라이언트 Application
– MSA의 API 서비스 소비

 

III. SOA와 MSA 비교

가. SOA와 MSA 관계도

  • MSA는 SOA 사상에 근간을 두고 대용량 분산 웹 서비스에 맞는 구조로 경량화

나. SOA와 MSA 상세 비교

항목SOAMSA
공통점– 기능을 서비스 단위로 분해
– 느슨한 결합, 조립 통한 새로운 서비스 제공
관계– 서비스 단위(큰 개념)– 경량화, 실용화
기반기술– SOAP/XML– REST/JSON
적용대상– B2B기반 기업 시스템– B2C기반 대용량 분산
허브역할– ESB– API G/W
시장전개– 공급 벤더 기반 전개– 인터넷 기업 전개

 

IV. MSA 장/단점 및 도입 시 고려사항

가. MSA 장/단점

구분항목설명
장점최적 언어
선택
– 각 모듈은 독립적
– 모듈 최적 언어 선택
무제약
DB 선택
– 모듈 별 독립DB 보유
– 제약없는 DB 선택 가능
효율적
자원사용
– 모듈 별 서비스 특성
– 특성에 맞는 자원 할당
단점추적성
부족
– 대규모 프로젝트 기반
  서비스 추적성, 감시 어려움
속도
저하
– 단일 프로세스 간 통신에 비해
서비스 간 통신 처리 추가 필요
디버깅
어려움
– 연속 서비스 호출 관계
– 오류 탐지 및 디버깅 어려움

나. MSA 도입 시 고려사항

구분고려사항설명
아키
텍처
측면
서비스 단위– 독립적 서비스 단위 분리 기준
– 설계와 배포/관리 독립성 고려
API G/W 도입API G/W 도입여부, SPOF 고려
– 도입 시 안정성 확보 필요
Polyglot
프로그래밍
– 개별 API 서버 고가용성 구성
– API 서버 모니터링, LB 구성
자동화– 배포와 운영 자동화 위한 시스템적 측면 구성 고려
조직
측면
조직문화– MSA에 적합한 팀 빌딩
– 기존 조직문화의 저항
분산 거버넌스– MSA 적합 조직 관리 모델
– 기술 전략 가능 모델 고려
Cross Functional
Team
– MSA 아키텍처 적용 시 저항
– 데브옵스 구조에 대한 컨센서스
Alignment– 기능교차팀, 분산거버넌스 조율
– 연계 Alignment 체계 마련

 

콘텐츠 사용 시 출처 표기 부탁 드리고, 댓글은 큰 힘이 됩니다^^