.[microservice patterns] 1. 모놀리식 지옥의 징후, 마이크로서비스 아키텍처를 도입해서 탈출하기 + 마이크로서비스 아키텍처 패턴 언어란?

서술방식 : definition + history + example

 

1. 모놀리식 지옥의 징후, 마이크로서비스 아키텍처를 도입해서 탈출하기 + 마이크로서비스 아키텍처 패턴 언어란?

2. 아키텍처의 중요성, 애플리케이션의 서비스단위 분해 패턴, 분해과정에서 마주치는 문제의 솔루션

3. 메세지 기반 비동기 통신  - 서비스간 통신을 위한 최적 패턴

4. 사가 패턴  - 데이터 일관성 유지 방법

5. DDD의 aggregate 및 도메인 이벤트 패턴  - 서비스 비즈니스 로직 설계

-  DDD : 도메인 주도 설계

6. 이벤트 소싱 패턴 - 비즈니스 로직 개발

7. API 조합 패턴, CQRS 패턴 - 분산 데이터 조회 쿼리

- CQRS(커맨드 쿼리 책임 분산)

8. 외부 API 패턴 - 외부 클라이언트 요청 처리

9 ~ 10. 자동화 테스트 - 테스트 피라미드, 단위테스트, 통합테스트, 컨슈머 주도 계약 테스트, 컴포넌트 테스트

11. 프로덕션 레디 서비스 개발 - 보안, 외부화 구성  패턴, 서비스 관측성 패턴(로그수집, 애플리케이션 지표, 분산추적)

12. 서비스 배포 패턴 - 가상머신, 컨테이너, 서버리스,  서비스 메시

13. 스트랭글러 애플리케이션 패턴 - 모놀리식 -> microservice 마이그레이션

---

 

용어

AWS SES : AWS Simple Email Service

monolith : 모놀리스, 일체형

Big Ball of Mud 패턴 : 진흙 잡탕 패턴

Foote, Yoder : Brian Foote and Joseph Yoder are computer scientists who popularized the term "Big Ball of Mud" in their 1997 paper of the same name

 

1. "작은" 모놀리식 아키텍처의 장점

- 개발이 간단함

- 애플리케이션을 쉽게 변경할 수 있음

- 테스트 쉬움

- 배포 쉬움

- 확장 쉬움

 

2. 모놀리식 지옥

- 애플리케이션이 성공하면, 추가 구현 할 스토리가 늘어나고, 코드베이스, 관리 오버헤드가 늘어남

- 단일 코드베이스는 소통/조정 오버헤드를 유발함

- 코드 커밋부터 프로덕션 배포까지 험난함. 변경분은 테스트를 위해 큐에서 대기함

- 방대함 때문에 수정/기능 구현이 갈수록 힘들고 오래걸림

 

소프트웨어 아키텍처는 기능 요건과 무나하다.

functional requirement(use case)는 어느 아키텍처든 구현할 수 있다.

아키텍처는 -ilities로 끝나는 갖가지 서비스 품질요건(비기능 요건; nonfuctional requirement)에 영향을 미친다.

소프트웨어 전달속도; maintainability, extensibility, testability

 

microservice architectrue 정의

- 애플리케이션을 확장큐브(X,Y,Z 축) 으로 확장시킬수 있는 것

• X : 수평복제 ; 부하분산한다. 단일 인스턴스 -> 다중인스턴스 
  • 애플리케이션 능력과 가용성 개선
• Z : 데이터분할; 단일파티션 -> 다중파티션. 요청의 속성에 따라 요청을 라우팅 한다.
  • 트랜잭션, 데이터 볼륨 처리에 좋음
• Y : 기능분해; 모놀리스 -> 마이크로서비스. 애플리케이션을 서비스 단위로 분해한다
  • 애플리케이션 복잡도 해결

- 중요한 것은 단위의 크기가 아니고, 각 서비스는 집중되고 응집된 책임을 맡고 있는 것이다.

 

---

 

1. "작은" 모놀리식 아키텍처의 장점

- 개발이 간단함

- 애플리케이션을 쉽게 변경할 수 있음

- 테스트 쉬움

- 배포 쉬움

- 확장 쉬움

 

2. 모놀리식 지옥

- 디팬던시 -> 복잡도 -> 난해한 코드 -> 개발속도(커밋,배포), 확장 난이도, 덩치에 따른 테스트 성 저하, 기술 도입 불가

 

3. 확장큐브 : 마이크로서비스 개념의 시작

- X축 : 인스턴스 단위(인스턴스 분산 할당)

- Z축 : 요청 단위(요청 분산 할당)

- Y축 : 기능 단위(기능 분산하여 개별 처리)

 

4. 마이크로서비스 형태

- 모듈성

-- 단위 = 서비스. 서비스와 API를 분명하게 정의해야 함.

-- 책임 경계 = API

-- 서비스마다 개별 DB : 스키마 변경, DB lock에 자유로움

 

- SOA(Service Oriented Architecture) 와의 차이

-- 기술스택 : SOAP, WS표준 + ESB(=smart pipe) VS 오픈소스+ dumb pipe(message borker, REST, gRPC ..)

-- 데이터 처리 : shared DB VS 자체 DB, 도메인 모델

-- 서비스 크기 : 서비스 몇 개(big) VS 서비스 수십 ~ 수백개

 

5. 마이크로서비스 장점/단점

- 장점 : CI/CD, 관리용이(작아서), 결함 격리, 기술 독립

- 단점 : 서비스 경계 나누는 난이도. 여러 서비스에 걸친 기능(분산시스템)

 

 

 

6. 패턴, 패턴언어

- 대부분의 결정은 코끼리가 내린다. 코끼리를 탄 사람은 코끼리한테 영향을 끼칠때도 있지만, 대부분 코끼리의 결정을 정당화하는 근거를 제공한다. 기술을 패턴 포맷으로 나타내면 감정을 극복한 상태에서 기술을 논할 수 있다.

 

- 패턴 : 특정 문제상황에 대한 재사용 가능한 해법

- 패턴언어 : 패턴의 집합

패턴은 적용가능한 맥락을 반드시 기술해야 한다. 솔루션의 측면도 기술하도록 강제한다.

 

- 상용 패턴의 구조

-- 강제조항(foces) : 반드시 처리해야 할 이슈(전부 충족할 수는 없고, 우선순위를 정해야 한다)

-- 결과맥락(resulting context) : 장점/단점/이슈

-- 연관패턴(related patterns) : 선행자/후행자/대안/일반화/세분화

 

7. MSA 패턴언어 : MSA 구성에 유용한 패턴의 모음집

 

패턴 계층

- 인프라 패턴(infrastructure pattern)

- 애플리케이션 인프라(application infrastructure)

- 어플리케이션 패턴(application pattern)

 

패턴 그룹

- 애플리케이션 분해: 비즈니스 능력/하위 도메인

- 통신: 통신스타일/디스커버리/신뢰성/트랜잭셔널 메시징/외부 API

- 데이터 일관성 (트랜잭션 관리) : 분산트랜잭션(2PC) -> 사가패턴

- 데이터 쿼리 : API조합 패턴(서비스 호출 결과를 조합), CQRS 패턴(데이터 레플리카 유지) 두가지 패턴 응용. 분산 쿼리 불가하기 때문

- 서비스 배포 : 패키징 포멧 수동 배포-> 배포 플랫폼(UI 관리, VM, 컨테이너, 서비리스 응용)

- 관측성(런타임 트러블 슈팅= 요청실패, 지연시간...) : 헬스체크/로그수집/분산추적/예외추적/애플리케이션 지표/ 감사 로깅

- 서비스 테스트 자동화(E2E는 피하고, 서비스간 조화테스트가 중요하다) : 컨슈머 주도 계약 테스트, 컨슈머 쪽 계약 테스트, 서비스 컴포넌트 테스트 

- 횡단 관심사 처리(모든서비스가 구축해야하는 것을 새로 구축 힘들다)  : 마이크로 서비스 섀시(chassis) 패턴

- 보안 : JWT(Json web Token). 보통, API게이트웨이가 인증 철이 후 서비스에 관련정보 전달함.

 

8. 프로세스(= 조직 + architecture)

- 시스템을 설계하는 조직은, 그들의 소통구조를 그대로 옮겨놓은 듯한 결과물을 낼 수 밖에 없는 한계가 있다. 크기가 N인 팀의 소통오버헤드는 N^2로 증가한다.

- 애자일 + CI/CD 도입해야 한다.

 

---

 

 

API Gateway = facade(관문) 패턴 구현