msaschool - msaschool

MSA 성숙도 모델 & 적용 레벨

MSA 아키텍처는 서비스 독립성, 데이터 분리성, SW 아키텍처 수준에 따라 4 단계(Early, Inception, Expanding, Mature)로 구분합니다.
처음부터 MSA를 구축하는 경우(Greenfield Project)는 Mature 단계를 목표로, 기존 모노리스를 MSA로 전환하는 경우(Brownfield Project)는 점진적으로 성숙도를 높여가며 적용할 수 있습니다.

12st 쇼핑몰의 구현 관점별 MSA 성숙도 적용 레벨은 다음과 같습니다. (노란색 표시)

구현 관점 Early (Lv1) Inception (Lv2) Expanding (Lv3) Mature (Lv4)

기능

분해
기능과 유즈케이스 단위로 분리
- 비즈니스 역량은 도출한 비즈니스 기능과 유즈케이스 단위로 분리가능 서비스별 인터페이스 정의
- 추출 된 각 유스 케이스와 인터페이스를 통해 액세스 할 데이터에 대해 잘 정의 된 인터페이스를 가짐. 도메인 Context 분리
- Ubiquitous language 가 다른 bounded context간의 커뮤니케이션 시, Anti-corruption layer를 통해 수행 도메인 기반 이벤트
- 구체화된 보기, 읽기 쓰기를 위한 별도의 모델(CQRS) 구축

데이터 2PC 사용 가능
- ACID 기반의 트랜잭션을 유지합니다. Canonical Data Model 를 지향 Scheme per Service
- 각각의 서비스는 자신만의 Scheme를 가짐
- 서비스들과 다중 엔터프라이즈 데이터 저장소 간의 트랜잭션이 적은 조정으로 이루어짐 DBMS per Service
- 완전히 분산된 데이터 관리
- 서비스별 다른 유형의 DBMS 사용이 가능한 폴리글랏 퍼시스턴스를 지향 Event-Driven Archi. - 이벤트 기반 데이터 관리, 이벤트 소싱 및 커멘드 쿼리
- 일시적으로 데이터에 일관성이 없는 상태가 존재할 수 있으나, 일정 시간이 지나면, 데이터가 도착하여 다시 Consistency를 충족

SW
아키텍처 UI/UX : Server Side rendering,
Session based 보안,
단일 언어(eg. Spring framework) UI/UX : Server Side rendering,
Session cluster 적용,
MSA 지향 언어(eg. Spring Boot) UI/UX : Client Side rendering,
Token based 보안, OAuth2,
폴리글랏 Language UI/UX : Client Side rendering+MVVM,
Token based 보안, OAuth2,
폴리글랏 Language + Service Mesh

Infra

스트럭처
지속적인 빌드, 지속적인 통합 운용 지속적인 딜리버리와 배포, 로그의 중앙 집중화 컨테이너 사용(도커), 컨테이너 오케스트레이터(k8s), 외부 구성(유레카, 주키퍼) 자동 프로비저닝을 갖춘 PaaS기반 솔루션

배포 설치 스크립트 구동, 호스트 당 멀티 서비스 인스턴스 VM 당 하나의 서비스 인스턴스
클라이언트 사이드 로드 벨런싱
서버사이드 로드 벨런싱 Immutable 서버, 컨테이너 당 하나의 서비스 인스턴스, blue/green 배포 멀티 클라우드 및 멀티 데이터 센터 지원

팀구조 개발, QA,릴리즈, 운영이 분리된 하나의 기능 팀 공유된 서비스 모델로 팀 공동 작업
내부 소스 공개 서비스별 프로덕트 팀(PO, UI/UX 디자이너, 개발자) Cross Functional한 플랫폼 팀 업무 기능별 혹은 도메인별 팀들이 모든 관점에서 책임을 수반. "네가 구축한 것은 네가 운영합니다."

구현 관점	Early (Lv1)	Inception (Lv2)	Expanding (Lv3)	Mature (Lv4)
기능 분해	기능과 유즈케이스 단위로 분리 - 비즈니스 역량은 도출한 비즈니스 기능과 유즈케이스 단위로 분리가능	서비스별 인터페이스 정의 - 추출 된 각 유스 케이스와 인터페이스를 통해 액세스 할 데이터에 대해 잘 정의 된 인터페이스를 가짐.	도메인 Context 분리 - Ubiquitous language 가 다른 bounded context간의 커뮤니케이션 시, Anti-corruption layer를 통해 수행	도메인 기반 이벤트 - 구체화된 보기, 읽기 쓰기를 위한 별도의 모델(CQRS) 구축
데이터	2PC 사용 가능 - ACID 기반의 트랜잭션을 유지합니다. Canonical Data Model 를 지향	Scheme per Service - 각각의 서비스는 자신만의 Scheme를 가짐 - 서비스들과 다중 엔터프라이즈 데이터 저장소 간의 트랜잭션이 적은 조정으로 이루어짐	DBMS per Service - 완전히 분산된 데이터 관리 - 서비스별 다른 유형의 DBMS 사용이 가능한 폴리글랏 퍼시스턴스를 지향	Event-Driven Archi. - 이벤트 기반 데이터 관리, 이벤트 소싱 및 커멘드 쿼리 - 일시적으로 데이터에 일관성이 없는 상태가 존재할 수 있으나, 일정 시간이 지나면, 데이터가 도착하여 다시 Consistency를 충족
SW 아키텍처	UI/UX : Server Side rendering, Session based 보안, 단일 언어(eg. Spring framework)	UI/UX : Server Side rendering, Session cluster 적용, MSA 지향 언어(eg. Spring Boot)	UI/UX : Client Side rendering, Token based 보안, OAuth2, 폴리글랏 Language	UI/UX : Client Side rendering+MVVM, Token based 보안, OAuth2, 폴리글랏 Language + Service Mesh
Infra 스트럭처	지속적인 빌드, 지속적인 통합 운용	지속적인 딜리버리와 배포, 로그의 중앙 집중화	컨테이너 사용(도커), 컨테이너 오케스트레이터(k8s), 외부 구성(유레카, 주키퍼)	자동 프로비저닝을 갖춘 PaaS기반 솔루션
배포	설치 스크립트 구동, 호스트 당 멀티 서비스 인스턴스	VM 당 하나의 서비스 인스턴스 클라이언트 사이드 로드 벨런싱 서버사이드 로드 벨런싱	Immutable 서버, 컨테이너 당 하나의 서비스 인스턴스, blue/green 배포	멀티 클라우드 및 멀티 데이터 센터 지원
팀구조	개발, QA,릴리즈, 운영이 분리된 하나의 기능 팀	공유된 서비스 모델로 팀 공동 작업 내부 소스 공개	서비스별 프로덕트 팀(PO, UI/UX 디자이너, 개발자) Cross Functional한 플랫폼 팀	업무 기능별 혹은 도메인별 팀들이 모든 관점에서 책임을 수반. "네가 구축한 것은 네가 운영합니다."