2장 : MSA의 이해

## 리액티브 선언 

응답성 : 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공

탄력성 : 장애가 발생하거나 부분적으로 고장나더라도 시스템 전체가 고장나지 않고 빠르게 복구

유연성 : 시스템의 사용량에 변화가 있더라도 균일한 응답성을 제공, 시스템 사용량에 비례해서 자원을 늘리거나 줄이는 능력

메시지 기반 : 비동기 메시지를 전달을 통해 위치 투명성, 느슨한 결합, 논블로킹 통신을 지향

4가지 요소는 상호 보완적, 급변하는 상황에 적응할 수 있는 시스템을 요구하는 것

아키텍처 유연성 : 시스템을 구성하는 구성요소 간의 관계들이 느슨하게 맺어져 있어 언제든지 대체되거나 추가 확장될 수 있는 특성 

 

## 강 결합에서 느슨한 결합으로의 변화

특정 벤더 중심 아키텍처는 검증된 유명 제품군을 통해 품질이 보장되나, 해당 제품에 의존한다는 점에서 특정 기술에 락인되어 쉽게 변경하거나 확장하지 못한다는 단점이 있다.

최근에는 특정 벤더에 의존할 필요가 적어짐. 오픈소스 기반으로 한 상용 제품들의 품질이 높아지고, 오픈소스 제품 간 호환성이 좋아졌기 때문

예전에는 검증된 기술이나 솔루션을 기반으로 기술을 직접 구현하는 폐쇄적인 방식인 것에 비해 최근의 아키텍처 설꼐는 필요한 영역에 적절한 솔루션을 선택하고 조합하는 개방적인 방식으로 변화

 

## MSA 외부/내부 아키텍처

MSA 외부 아키텍처 : 핵심 서비스 내 백엔드 서비스를 제외한 인프라, 플렛폼, 애플리케이선 영역에 있는 구성요소 및 해당 요소 간 관계를 정의한 것

외부 아키텍처는 MSA가 운영되는 환경을 정의

내부 아키텍처 : 실제로 비즈니스가 실행되는 비즈니스 어플리케이션, API, 비즈니스 로직, 이벤트 발행, DB 저장 처리 등을 어떻게 구조화하는가에 대한 내용

 

## MSA 구성요소 및 패턴

 

### 인프라 구성 요소

MSA를 지탱하는 하부 구조 인프라를 구축하는데 필요한 구성요소

HW,SW, 네트워크, OS, 스토리지 등 모두 포함

- 퍼블릭/프라이빗 클라우드 환경, 베어 메탈 : 상관 없으나 클라우드가 추세

- VM과 컨테이너 : 컨테이너 추천

- 컨테이너 오케스트레이션

 

### 서비스 유형별 대표적인 클라우드 서비스

Iaas(Infrastructure as a Service): VM, 스토리지, 네트워크 같은 인프라를 제공 : Ec2, GCP Compute Engine 

CaaS(Cantainer as a Service) : 컨테이너 기반 가상화를 사용해 컨테이너를 관리하는 서비스, 다른 환경에도 이식 가능한 컨테이너 기반 가상화 제공 : AKS, EKS, GKE, ECS 등

PaaS(Platform as a Service) : 복잡함 없이 애플리케이션을 곧바로 개발, 실행, 관리하는 플렛폼 : Cloud Foundry, Heroku, Elastic Beanstalk

 

### 플렛폼 패턴

인프라 위에서 MSA 운영과 관리를 지원하는 플렛폼 차원의 패턴

DevOps 환경 구성, 개발, 테스트 배포 등을 자동화

CI : 지속적 통합

CD : 지속적 제공/배포

 

#### MSA와 스프링 클라우드 서비스 연계 흐름

1. 모든 MSA는 인프라에 종속되지 않도록 환경 설정 정보를 Config 서버에서 가져와야

2. 로딩과 동시에 서비스 레지스트리에 자신의 서비스 명과 클라우드 인프라에게 할당받은 물리 주소 매핑

3. 클라이언트가 API 게이트웨이를 통해 MSA에 접근, API 게이트웨이는 적절한 라우팅 및 부하 관리를 위한 로드 밸런싱 수행

4. 게이트웨이에서 각 MSA 접근을 위한 주소를 알기 위해 서비스 레지스트리 검색

5. 게이터웨이에서 해당 서비스의 권한 여부를 파악하기 위해 권한 서비스를 연계해 인증/인가 처리

6. 전체적인 모니터링 서비스와 추적 서비스를 의해 모니터링

 

#### 서비스 레지스트리, 디스커버리 패턴

서비스 디스커버리 패턴 : 클라이언트가 여러 개의 MSA를 호출하기 위해서는 최적 경로를 찾아주는 라우팅 기능과 적절한 부하 분산을 위한 로드 밸런싱 기능 제공

 

서비스 레지스트리 패턴 : MSA의 명칭과 유동적인 IP 정보를 저장하는 보관소 사용

 

게이트 웨이 패턴 : 단일 진입점을 만들어 놓고 다양한 서비스에 접근하게 만듬. 

게이트웨이 기능

- 동적 라우팅, 로드 밸런싱

- 인증/인가

- 로그 집계 서비스와 연계한 로깅

- 메트링

- 트레이싱 서비스와 연계한 서비스 추적

- 모니터링 서비스와 연계한 장애 격리(서킷 브레이커)

 

BFF 패턴 :  진입점을 하나로 두지 않고 FE 유형에 따라 각각 두는 패턴 BFF를 두고 이후에 통합적인 API 게이트웨이를 두는 경우도 있음

외부 구성 저장소 패턴 : 서비스 설정을 외부 저장소에 두는 패턴. 배포 환경이 매번 달라지기 때문에 환경 설정 정보는 코드와 완전히 분리되어 관리해야 한다는 원칙이 있음

 

#### 인증/인가 패턴

중앙 집중식 세션 관리 : 기존 모노리스 방식에서 가장 많이 사용했던 방식. 서버 세션에 사용자의 로그인 정보 및 권한 정보를 저장하고 이를 통해 APP 인증/인가를 판단

클라이언트 토큰 : 세션은 중앙 서버에 저장, 토큰은 사용자 브라우저에 저장, 토큰은 사용자의 신원 정보를 가지고 있고 서버로 요청을 보낼 때 전송되어 서버에서 인가 처리를 진행 (JWT)

 

서킷 브레이커 패턴 : 장애가 발생한 서비스를 격리해서 유연하게 처리

모니터링과 추적 패턴 (Zipkin)

중앙화된 로그 집계 패턴 : 로그를 이벤트 스트림으로 처리 (ELK)

 

서비스 매시 패턴 : MSA 문제 영역 해결을 위한 기능(디스커버리, 서킷 브레이크, 추적, 로드 밸런싱 등)을 비즈니스 로직과 분리해서 네트워크 인프라 계층에서 수행하게 하는 서비스 (아스티오 Istio)

사이트카 패턴 : APP이 배포되는 컨테이너에 완전히 격리되어 변도의 컨테이너로 배포

 

 

### 애플리케이션 패턴

MSA 애플리케이션을 구성하는 데 필요한 패턴

 

UI 컴포지트 패턴, 마이크로 프런트엔드 패턴 : 프레임 형태의 부모 창을 통해 각 프런트앤드를 조합해서 동작, 부모 서비스는 틀만 가지고 있고, 실제 각 기능 표현은 마이크로 프런트엔드 조각에 구현하게 함.

#### MSA 통신 패턴 :

동기 통신 : 요청을 하면 바로 응답이 오는 방식 -> 응답이 올때까지 대기해야

비동기 통신 : 요청을 보내고 응답을 기다리지 않음. 완결성을 보장하기 위해 메시지큐 사용

 

저장소 분리 패턴 : 각 MSA는 각자의 비즈니스를 처리하기 위한 데이터를 직접 소유해야 함. 그렇기에 자신이 소유한 데이터는 다른 서비스에 직접 노출하지 않고 각자가 공개한 API를 통해서만 접근 가능.

- 비즈니스 정합성 및 데이터 일관성을 어떻게 보장하는 것인가가 관건

 

#### 분산 트랜젝션 처리 패턴:

2단계 커밋 기법 : 분산 트랜젝션에 포함되어 있는 노드가 전부 커밋/롤백 되는 것 : 락인 걸려서 성능 안좋아짐

SAGA 패턴 : 각 서비스의 로컬 트랜젝션을 순차적으로 처리 , 각 분산 서비스를 하나의 트랜젝션으로 묶지 않고, 각 로컬 트랜젝션과 보상 트랜젝션을 이용해 데이터 정합성을 맞추는 것

보상 트랜젝션 : 어떤 서비스에서 트랜젝션 처리에 실패할 경우 그 서비스의 앞선 서비스에서 처리된 트렌잭션을 되돌리게 하는 트랜젝션

 

결과적 일관성 : 데이터의 일관성이 실시간으로 맞지 않더라도 어느 일정 시점이 됐을 때 일관성이 만족하게 되는 것

 

CQRS 패턴 : 읽기와 쓰기 분리

일반적인 비즈니스 모델에서는 입력, 수정, 삭제가 조회보다 훨씬 적게 쓰임

읽기와 조회 서비스를 분리할 수 있고, 더 나아가 아예 물리적으로 트렌젝션을 분리 가능.

시스템 부하를 줄이고 조회 대기 시간을 줄이는 엄청난 이점을 누림

 

이벤트 소싱 패턴 : 객체 상태를 데이터 모델에 맞춰 계산하지 않고, 상태 트렌젝션 자체를 저장

- 메시지 브로커와 데이터 저장소를 분리하지 않고 하나로 사용 가능 

- 복잡한 과정이 없어 쓰기 속도가 훨씬 빠름 

- 스트림 저장소에는 오로지 추가만 가능하게 하여 이벤트들이 쌓이게 만들고, 구체회 시점에서 트랜젝션을 바탕으로 상태를 계산해서 구성