MSA 서비스 구현 방법론

MSA 구현 패턴

1. API First Design

타 서비스나 화면에서 필요한 기능을 제공하는 인터페이스로 API를 식별

물리적으로 서비스가 분리되지만, runtime coupling이 발생하여 강결합 상태가 됨

--> API Gateway, Service Meshg, LB, Service Registry, Circuit breaker 등을 활용한 추가 구성 필요

 

 (1) 동기 호출 구성 : 직관적이며 이해하기 쉬움. callee가 항상 가용해야 함. 2PC가 가능함

 

 (2) 비동기 구성 : 응답이 필요없거나 트랜잭션 분리가 가능하거나 호출대상 API 처리 시간이 길 경우 사용

    --> callback 함수, 서비스 간 공유 cache/DB 를 활용하여 처리 결과 폴링

https://mangdan.github.io/api-first-design-and-development-1

API-Design First & Microservice 개발 1탄 - API 디자인 및 프로토타입

 

Synchronous / Asynchronous

Notification vs Request/Async Response

Publish/Sucscribe

분산 트랜잭션

NoSQL, MSA에 기반한 App 별 분리된 DB 사용, 서비스 간 데이터 일관성 필요

ACID 에 대응하는 BASE

Atomicity (원자성)

Consistency (일관성)

Isolation (독립성)

Durability (지속성)

BA (Basically Available)

S (Soft-State)

E (Eventually Consistency)

Compensating Transaction (보상 트랜잭션)

서비스 간 트랜잭션 처리 과정에서 실패/에러가 발생하는 경우, 명시적(프로그래밍)으로 실패에 대한 처리를 해야 한다.

SAGAS

1987년도 Hector Garcia-Molina 가 작성한 논문에서 제안된 용어이다.

Orchestration

중앙(한곳)에서 비즈니스와 트랜잭션을 제어하는 방법.
Command 기반으로 동작한다.

Choreography

상호간 서비스 실행 결과에 따라 정상/비정상 처리 결과에 따른 로직을 수행한다.
Event 기반으로 동작하며, 서비스들 간 발행/구독된 이벤트에 따라 로직이 실행됨.

분산 데이터 조회

API Composition

각 서비스들의 API를 호출하고, 그 결과를 조합하여 하나의 Response를 만들어 제공

CQRS (Command Query Responsibility Segregation)

Command와 Query를 분리하는 패턴 (저장과 조회를 분리)

데이터 복제 방식

CDC (Changed Data Capture)

Batch/ETL

Message Queue

MSA를 구성하는 기술들

API Gateway

https://aws.amazon.com/ko/api-gateway/

Service Mesh

https://www.redhat.com/ko/topics/microservices/what-is-a-service-mesh

Backing Service

https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-5Backing-Service-lqk3b7560w

MSA 제대로 이해하기-(5)Backing Service

 

 

---

 

MSA School

http://www.msaschool.io/operation/design/design-three/

---

MSA 핵심패턴만 빠르게 이해하기

출처 : https://happycloud-lee.tistory.com/154?category=902418

마이크로서비스 패턴: 핵심패턴만 빠르게 이해하기

 

비동기 메시지 기반 주문 처리

[ 출처 ]   https :// engineering-skcc.github.io /microservice%20outer%20achitecture/ inner-architecture-saga /

MSA 패턴 마인드맵 ([출처]  Microservices Patterns - Conceptual Map  by  Gabriel Moral)

 

 

https://happycloud-lee.tistory.com/188

MSA특성과 MSA 12 Factors 이해

 

 

 

 

---

이벤트 스토밍

 - 이벤트스토밍은 Event와 BrainStorming의 합성어로 Domain Expert와 개발 전문가가 함께 모여 워크샵 형태로 진행되는 방법론입니다. DDD 방법론 중, 복잡한 UML다이어그램이나 도구 없이 수행할 수 있어 MSA를 구현하는데 가장 최적의 방법론입니다.

 - 이벤트스토밍은 시스템에서 발생하는 이벤트를 중심(Event-First)으로 분석하는 기법으로 특히, Non-Blocking, Event-driven한 MSA 기반 시스템을 분석에서 개발까지 필요한 도메인에 대한 빠른 이해를 도모하는데 유리합니다.

---

도메인 주도 설계

1. 전략적 설계

  - 최근 MSA 에 대한 관심이 증가되고 있음. 마이크로 서비스를 구분해 내기 위해 DDD 가 다시 등장하며, 결국 바운디드 컨텍스트를 구분해 내어 MSA 구성 요소를 도출함

1.1. 바운디드 컨텍스트

   - 의미적으로 동일한 컨텍스트의 범위 (이커머스의 상품과 의료의 상품은 다름. 은행의 account 와 문학에서의 account 가 다름)

1.2. 유비쿼터스 언어 (보편언어)

   - 도메인 전문가와 개발자가 서로 다른 언어를 사용하면 대화에 혼선이 발생할 것이다.

   - 상호간 협업시 보편적으로 사용할 언어를 정의해야 한다.

   - 유비쿼터스 언어는 대화, 회의 ,문서 및 소스 코드에서도 사용되게 된다.

   - 용어집

1.3. 컨텍스트 매핑

   - 개별적인 "바운디드 컨텍스트"만 봐서는 전체 시스템을 이해하기 어려움

   - 나무가 아닌 숲을 봐야 하는데, 이 때 사용하는 것이 컨텍스트 맵, 컨텍스트 매핑이다

   - 컨텍스트 매핑 : 다수의 바운디드 컨텍스트의 경계를 정의하는 것

   - 컨텍스트 맵 : 컨텍스트 매핑을 큰 지도처럼 보여주는 다이어그램

 

• 공유커널 (shared kernel): 바운디드컨텍스트 사이에 공통 모델 공유하는 관계
• 고객공급자 유형(customer-supplier): 고객이 원하는 것을 공급자가 제공해주는 관계
• 준수자 유형(confirmist): 공급자의 모델을 그대로 따르는 방식의 관계
• 충돌방지계층(anti-corruption layer): 공급자 모델과 고객 모델 사이에 번역 계층을 만드는 방법
• 공개 호스트 서비스(open host service): 바운디드 컨텍스트에 접근할 수 있는 인터페이스를 정의하는 방법
• 발행된 언어(publiched language): 바운디드 컨텍스트의 규모와 상관없이 사용과 번역을 가능하게 하는 문서화된 정보교환언어를 제공하는 방법

 

2. 전술적 설계

  - 전략적 설계에서 정의한 도메인 모델의 세부 사항을 구현하는 과정

  - 도메인 객체 구현

  - 시스템 소프트웨어 내부 구조 상세 정의

  - 바운디드 컨텍스트 사이의 서비스 인터페이스 정의 등

2.1. 애그리거트

   - 서로 연관된 객체를 감싸는 경계를 정의

   - 앤티티와 값객체를 애그리거트로 모으고, 각각에 대한 경계를 정의하라.

   - 한 엔티티를 골라 애그리거트 루트로 만들고, 애그리거트 경계 내부의 객체에 대해서는 루트를 거쳐 접근할 수 있게 하라.

   애그리거트 밖의 객체는 루트만 참조할 수 있게 하라. (Service class? Proxy?)

2.2. 엔티티, 값객체

   - 엔티티는 도메인 모델을 구현한 도메인 객체이다.

   - 엔티티의 속성은 가변이며, 값객체는 불변이다.

   - JPA 의 엔티티가 아니다!!

2.3. 도메인 서비스

   - 엔티티의 행동으로 구분하기에 어색함을 해결하기 위해서 도메인의 행동을 별도의 객체로 분리해서 정의하는 방법

   - 소프트웨어가 중지되었다고 해서 사라지면 안됨

   - 어딘가에는 저장하고, 필요할 대 가져다가 사용해야 한다.

2.4. 애플리케이션 서비스

   - 소프트웨어에서 구현해야 하는 요구사항, 즉 유스케이스를 구현하는 서비스 객체

---

 

MSA를 적용한 응용시스템을 Agile한 방식으로 개발하고 DevOps 기술과 체계를 활용하여 운영하는 것이 바람직함

 

MSA

 - 클라우드 환경에 최적화된 아키텍처 스타일

 - 4가지 장점

  - 장애의 격리와 복구

  - 사용자 폭증에 대비한 확장성

  - 비즈니스의 긴급 반영

  - 신기술의 반영

 1. 목적

  독립적인 비즈니스 단위의 시스템 분산을 통하여 비즈니스 Agility 확보

  확장 가능한 시스템 아키텍처 구성을 통해 안정적인 운영 시스템 구축

  신기술 적용에 대한 유연성 확보

 2. MSA 아키텍처 정의(분산/확장형)

  배포가 용이한 단위의 시스템 분산

  비즈니스에 최적화된 독립적인 아키텍처 구성

  장애 대응에 안정적인 확장 가능한 시스템 아키텍처 구성

  선진 기술에 대한 적용 용이한 아키텍처 구축

---

MSA 전환 접근 전략

 - 빅뱅 방식

  - 전체 시스템을 MSA로 일괄 변환

  - 목표 아키텍처 및 시스템 방향성 제시

  - 향후 운영 조직에 대한 거버넌스 체계 등의 수립

  - 역량 부족, 잘못된 서비스 분리 등 실패 비용에 대한 위험성이 있음

 - 미트 인 미들

  - 사업 방향성에 따른 전체 시스템의 Big Picture 설계

  - 아키텍처 체계 및 표준 수립

  - 현행 시스템의 개선 시급성과 시스템의 방향성에 따라 점증적인 MSA 전환

  - 점진적인 접근으로 역할 확보 및 실패 비용 감소

 - 현행 시스템 중심 비즈니스 요구에 의한 점진적 전환

  - 운영 시스템의 Pain Point를 기반으로 일부 서비스 분리

  - Pain Point에 가장 알맞은 아키텍처 정의

  - 점증적 방식의 MSA 전환으로 실패 비용 감소

  - 비즈니스 확대시 아키텍처, 조직, 표준 등에 대한 한계가 존재함

---

MSA 서비스 도출 과정

1. 후보 서비스를 도출

1. 대상 업무를 기능 레벨로 분해하여 후보 서비스를 도출한다.
2. 조직 구성 (운영팀 등)에 따라 기능을 분해한다.
3. 공통 기능(업무)를 한곳에 모은다.
4. 분해된 기능 목록을 특정 레벨 기준으로 후보 서비스를 도출한다.  
5. bounded context 와 shared kernel 로 구분

2. 도출된 서비스 평가

1. 도출된 서비스를 평가한다.
2. 서비스의 현재 업무 연관도와 database (분산) 를 분석한다.
3. 업무 요건에 따라 평가 지표 항목을 정의한다.
   • 독립 배포 (서비스 간 연관도, 데이터 상관 관계 등)
   • 트랜잭션 증가 (데이터 용량, 증가 등)
   • 빠른 배포/반영 여부
   • 요구사항 변경 빈도 (업무변경)
   • 조직 구성 형태 (운영 조직)
   • business agility

3. 평가 결과에 따른 서비스 정의

1. bounded context 정의
2. shared kernel 정의
3. 서비스별 분산 데이터베이스 정의
4. 분산 또는 scale out 대상 정의
5. 서비스 별 아키텍처 정의

4. 설계

1. tobe 시스템 설계 : cqrs, circuit breaker, saga, 비동기 등
2. 데이터 설계 : 파티셔닝, 조인 등
3. shar kernel 설계시
   • DB 복제
   • Cache 활용
   • 배치, 리포트

• 신속하고 빠른 배포를 위해 분리
• 사용량 증가/폭증에 대비한 유연한 확장 구조를 위한 분리
• 장애 격리를 위해 분리
• 서비스 독립성을 고려하여 비동기 호출 설계 (noti, async response, pub/sub)
  • callee 서비스의 응답이 필요없거나, 처리시간이 오래 걸릴 경우 : ntification
  • 1:N 형태로 event 전달이 필요한 경우 : pub/sub
• 조회 업무가 대부분인 경우 CQRS로 분리 (데이터 정합성을 위해 DB 복제 사용. 데이터 복제는 event/message queue 활용, 통계/조회 업무 등) -> 필요한 데이터가 서비스 내에 존재하므로 API Composition과 달리 독립된 서비스 제공 가능
• 다수의 팀이 협업/설계하는 경우 shared kernel로 식별하여 통합 (공통 업무 등)
• 신기술 적용 및 검증을 용이하게 하기 위한 분리
• 실시간 데이터 정합성이 중요할 경우 서비스 통합 (2PC 가 중요하거나 기존 테이블 조인 분리가 어려울 경우)
• 서비스 간 프로세스 및 데이터 공유가 빈번할 경우 서비스 통합

5. 개선

---

 

Service Mesh

 - Service Mesh는 마이크로서비스 간 통신을 위해 각 서비스를 식별(Discovery)하고, 경로를 파악(Routing)하며, 로드 발란싱(Load Balancing)을 하고 전체 서비스의 장애 전파를 차단(Circuit Break)하며 Telemetry와 통합되어 로깅, 모니터링, 트래이싱 기능을 담당하는 계층입니다.

istio

 - istio는 IBM, Redhat, VMware, Google등이 참여해 개발한 Service Mesh(서비스 매쉬) 구현을 위한 오픈소스 솔루션입니다. istio는 마이크로서비스 간의 모든 네트워크 통신을 담당 할 수 있는 프록시인 Envoy를 사이드카 패턴으로 마이크로 서비스들에 배포한 다음, 프록시들의 설정 값 저장 및 관리/감독을 수행하고, 프록시들에 설정값을 전달하는 컨트롤러 역할을 수행합니다.

https://velog.io/@beryl/Istio-%EA%B0%9C%EB%85%90

Istio 아키텍처와 기능 이해하기

 

https://blog.naver.com/PostView.nhn?blogId=sharplee7&logNo=222157988958

istio와 envoy란

 

---

CQRS

조회 업무가 많을 경우, DB 분리

shared kernel 설계시,

- 변경이 거의 없는 코드값 같은 데이터 : cache

- 일정 시간 내에만 동기화 되면 되는 경우 : message queue

- 변경시 즉시 조회 (정합성 높은 경우) : API 연계 나 Shared DB

---

휴리스틱 예외 ***********************

 2단계 커밋 프로토콜에서는 휴리스틱 예외Heuristic Exceptions라고 정의한다.

 휴리스틱 예외는 제거할 수는 없지만 위의 경우 적절한 Timeout 시간을 설정하여 발생 가능성을 줄일 수 있다. 그래도 발생하는 경우에는 오류 로그를 파일이나 큐Queue로 큐잉하여 리포팅한다. 리포팅된 로그는 시스템 관리자(혹은 시스템)에 의해 해결함으로써 결과적으로 일관성을 유지한다.

 이런 방식은 단기적으로 일관성을 잃더라도(클라이언트 입장에서 주문을 성공했다고 받았지만 결제는 되지 않을 수 있다) 결과적으로는 일관성을 유지하는 모델을 결과적 일관성Eventual consistency이라고 한다.

---

Eventual Consistency (결과적 일관성, 최종 일관성)

 Try-Confirm/Cancle 에서, Confirm을 수신한 micro service에서 당장은 아니더라도 결국은 성공적으로 처리되는 것을 보장하는 것.

 - confirm 처리 중 실패시 로깅 -> 오퍼레이터 수작업

 - kafka 같은 queue 를 활용한 재처리

  : API confirm 200ok 전달 후 queue에 confirm 처리를 위한 메시지 발송 -> 자체 구독 -> 처리

---

결과적 일관성을 위한 주문/재고/결제 MSA 구성방법 예시

 

https://www.popit.kr/rest-%EA%B8%B0%EB%B0%98%EC%9D%98-%EA%B0%84%EB%8B%A8%ED%95%9C-%EB%B6%84%EC%82%B0-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B5%AC%ED%98%84-3%ED%8E%B8-tcc-confirmeventual-consistency/%EF%BB%BF

REST 기반의 간단한 분산 트랜잭션 구현 - 3편 TCC Confirm(Eventual Consistency) | Popit

출처 : https://www.popit.kr/rest-%EA%B8%B0%EB%B0%98%EC%9D%98-%EA%B0%84%EB%8B%A8%ED%95%9C-%EB%B6%84%EC%82%B0-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B5%AC%ED%98%84-3%ED%8E%B8-tcc-confirmeventual-consistency/%EF%BB%BF

---

SAGA 패턴

분산처리환경에서 2PC 대안으로 보상트랜잭션을 포함하는 트랜잭션 처리 방법

 https://azderica.github.io/01-architecture-msa/

[Architecture] MSA : SAGA 패턴이란 - Azderica

 

---

비동기메시징 이슈 및 해결방안

 https://happycloud-lee.tistory.com/155

비동기메시징 이슈 및 해결방안

 

---

쿠버네티스

https://kubernetes.io/ko/docs/home/

쿠버네티스 문서

 

 

---

MSA로 구성시 단점

다수의 micro App 으로 구성되므로, 구성요소 간 네트워크 트래픽이 비약적으로 증가됨 (모놀리틱과 비교하여)

- 네트워크 지연 발생

- 네트워크 트래픽 증가 (서비스 패킷 + 복제 + 하트비트 등 관리용 등등)

- 네트워크에 대한 신뢰성 문제 (네트워크 장애시, 또는 공격/해킹 등)

 

---

Service Mesh

네트워크 관련 비용 증가로 인해 통신 및 네트워크 기능을 어플리케이션 로직과 분리하여 제공하기 위한 인프라

- service discovery

- load bvalancing

- dynamic request routing

- circuit braking

- failure recovery

- health check

- metrics and telemetry

- authentication and security

 

PaaS 형태의 제공, Library를 활용한 API 활용, Sidecar proxy 형태 (istio/envoy )

 

---

Message Broker를 통해 데이터를 전달하게 되면, 2 Phase commit 이 불가능하게 된다. 

또한 NoSQL DB 를 사용하거나 서비스별 DB가 분리되어 있다면 2PC가 불가능하게 되어 데이터 정합성을 유지하기 위한 방법이 필요하다. --> SAGA , 재처리, 보상트랜잭션, Batch 기반 실패건 처리 등 필요

  - Orchestration 방식으로 중앙에서 보상처리 -> 구현이 쉬움

  - Choreography 방식으로 서비스들 간 message/event 를 pub/sub 해서 처리함

 

기존 모놀리틱 App를 MSA구조로 변경시 DB 분리가 될 수 있는데, 이 때 join 이 필요할 경우는 API Composition을 활용하거나, DB복제를 통해 CQRS 패턴 적용

 

 

 

---

 

 

 

 

좀 더 읽어보기

 https://dailyheumsi.tistory.com/267

 https://dailyheumsi.tistory.com/247?category=967637

 https://www.samsungsds.com/kr/insights/service_mesh.html

 https://medium.com/@SlackBeck/rest-%EA%B8%B0%EB%B0%98%EC%9D%98-%EA%B0%84%EB%8B%A8%ED%95%9C-%EB%B6%84%EC%82%B0-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B5%AC%ED%98%84-1%ED%8E%B8-a9bde62f4365?p=a9bde62f4365

https://rambling.synology.me:52601/d/s/n6Ku3laMpSzMUlRk59F98skxc8Wcg8Zt/CMnW_4XFvbqfGFXuPbZBxGbtr3f9n4fI-W7Ag_wN-OQk

https://www.nirs.go.kr/newsletter/2015-12/issue.html

정부통합전산센터 제12호 Newsletter