I. 대용량 분산 웹 서비스 위한, MSA의 개념
- 소프트웨어를 독립적으로 배치 가능 단위로 분리하여 시스템을 구성하는 아키텍처
II. MSA 구성요소
가. MSA 구성도
- API G/W는 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 상세 비교
| 항목 | SOA | MSA |
|---|---|---|
| 공통점 | – 기능을 서비스 단위로 분해 – 느슨한 결합, 조립 통한 새로운 서비스 제공 | |
| 관계 | – 서비스 단위(큰 개념) | – 경량화, 실용화 |
| 기반기술 | – 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 체계 마련 |