MSA 이론 정리

Micro Service Architecture(MSA)

Domain Driven Design(DDD 도메인 주도 설계)

Event Driven Architecture(이벤트 주도 설계) : DDD패턴의 일부로 생각하고, DDD로 설계된 시스템을 독립적으로 분산시키기 위한 분산 비동기 아키텍처 패턴임.

 

[ MSA가 왜 필요한가? ]

 

---

[ Domain Driven Design ]

 

유비쿼터스언어로 작성

 

DDD란 비지니스적으로 접근하여 최종적으로는 아래와 같이 Service를 구분하고 코드로 구현하기 위한 설계를 목적으로 함.

DDD의 목표 그림

 

 

---

DDD 방법론을 적용하기 위해서 우리는 이벤트 스토밍 기법을 활용할 수 있음.

[ 이벤트 스토밍 ]

 

 

 

 

 

 

스티커 유형

예시

 

 

 

도메인 이벤트(Domain Event) - 주황색

가장 먼저 우리 서비스에서 발생하는 비즈니스 이벤트를 도출합니다. 용어의 네임스페이스를 굳이 나누려 하지 말고 가급적 현업이 사용하는 용어를 그대로 사용(Ubiquitous Language)하여 오렌지색 스티커에 이벤트를 기술하고 이를 벽면에 붙입니다.

비즈니스 이벤트는 과거형으로 작성하는데 도메인 내부에 상태가 변화되고 난 결과가 이벤트 입니다.

 

하나의 에그리게잇에서 나온 이벤트를 메세지큐(Kafka, RabbitMQ, ActiveMQ 등)에 발행하는 비동기 방식.

 

 

 

Policy (정책)

 

ex) 이벤트 발생시 다른 커맨드를 트리거하는 정책을 정의

또는 다른 시스템을 동작시키는 기준 등을 정의함.

 

 

 

 

 

커맨드 (Command) - 파란색

Account Changed 도메인 이벤트 왼쪽에 changed Account라는 커맨드를 붙임 (해당 도메인 동작을 발생시키는 이벤트)

 

커맨드는 모든 도메인 이벤트에 들어갈 필요는 없음. (결제 승인/거부 같은 경우에는 외부시스템에서 받아옴)

 

 

 

Actor (User 역할) - 노란색

해당 이벤트를 동작하게 만드는 주체를 표시함. ex) User, Customer, Manager, Buyer 등

 

 

 

 

핫스팟(Hot Spot) - 붉은색

ex) 사용자가 계정을 등록했는데, 나중에 탈퇴했다가 재등록을 할때 제약사항을 줘야하지 않을까? 이러한 이슈를 제시하기 위한 스티커

 

 

 

 

 

외부 시스템(External System) - 라일락/핑크

ex) Oauth와 같은 SNS 로그인 연동, 신용정보 조회 등 외부서비스와 처리할 경우.

 

 

 

 

 

 

 

엔티티/에그리게잇(Entity/Aggregate)

 

 

 

 

 

 

 

 

 

Bounded Context 식별 (바운디드 컨텍스트 식별)

 

 

 

 

Bounded Context 매핑 (바운디드 컨텍스트 매핑)

 

 

 

 

 

 

서브 도메인 식별 - 핵심 서브도메인 / 일반 서브도메인 / 지원 서브도메인

상품 등록, 추천 서비스 : 쇼핑몰의 핵심은 상품 등록과 상품을 구매하기 위한 추천 기능이라고 판단함.

배송 서비스 : 외부 배송업체를 배송정보를 Link로 보여줄거기 때문에 일반도메인으로 구분함.

지원 서비스 : 핵심 도메인과 관계가 있는 서비스로, 구매 후기와 회원가입은 상품관련 밀접한 관련이 있기 때문에 지원서비스로 구분.

 

 

 

 

MicroService 식별 (마이크로서비스 식별)

Bounded Context로 매핑된 정보를 기반으로 구매와 결제는 같은 구매서비스로 매핑하였지만,

결제서비스는 외부와의 연동을 통해 거의 수정사항이 발생하지 않아 

구매서비스와 같이 자주 개선하고 배포하는데 빌드만 느려지고, 규모만 커지는 단점이 발생함.

-> 따로 다른 마이크로서비스로 분리하여서 최종 결론.

 

 

 

 

 

 

 

마이크로서비스 식별 완료

 

 

 

 

 

마이크로서비스 매핑

 

 

Read Model (읽기 모델)

 

 

마이크로서비스 명세

마이크로서비스의 상세한 API 호출, Data, UI 등 개발자 수준에서 간단하게 이해할 수 있도록 작성.

 

 

 

 

명세를 통한 헥사고날 아키텍쳐 적용 (예시)

 

---

전술적 설계 (전략적 설계 완료)

 

 

 

마이크로서비스 내부 구조 설계

 

헥사고날 아키텍처는 도메인 영역과 외부 기술 영역을 완벽하게 분리하기 위해서 필요한 구조.

  1)고유한 비지니스 개념을 표현하는 도메인 모델, UI, DB 등 기술을 분리하는 것.

  2)이후에 빠르게 변화하는 기술의 변경과 대체를 쉽고 빠르게 수행.

 

 

Domain Modeling (도메인 모델링)

이론적으로 완성된 도메인을 기반으로, 소스코드로 구현하기 위한 세부사항 정의 단계

 

예시

 

 

 

 

엔티티(Entity)

 

 

값 객체(VO/Value Object)

 

 

 

Standard Type (표준타입)

 

enum방식의 데이터 구분값

 

 

 

에그리게잇(Aggregate) 

Entity중에서 가장 Domain 정보를 담고있는 객체를 루트에그리게잇이라고 함.

하나의 주문 서비스에서 주문event가 발생하면 하나의 트랜잭션으로 가는데

Log정보 저장, 주문정보 저장, 제품정보 저장 등 여러개의 에그리게잇(트랜잭션)으로 묶어서 각자 따로 처리함.

( SRP(Single Responsibility Principle) 단일 책임 원칙을 따름 )

 

서로 다른 에그리게잇끼리 참조할때는 VO(식별자)를 통해서 가져와야함.

 

 

 

저장소 레퍼지토리 (Repository)

Repository는 도메인과 DB사이를 사이에 두고 데이터만 양쪽에 맞춰주는 어뎁터 역할을 함.

DB가 변경되어도 도메인은 건드리지않고, 레포지터리만 수정함으로 DB변화에 유동적임.

 

 

 

<엔티티>
엔터티(Entity)는 다른 엔티티들과의 특성을 구별할 수 있는 식별자를 가진 객체이다

<에그리게잇>
생명주기안에서 도메인 객체의 무결성을 지키는 단위 패턴
트랜잭션의 일관성을 만드는 단위

<에그리게잇/엔티티>
에그리게잇 = N개 이상의 엔티티
루트에그리게잇은 N개의 엔티티중에서 가장 도메인에 가까운 단위
에그리게잇의 모든 구성요소는 biz규칙을 따르면서 db에 일관성있게 처리됨.

 

 

 

---

충돌 방지 계층(Anti Corruption Layer)

ACL은 MSA로 개발하지만 기존의 Legacy시스템을 사용해야 하거나, MSA로 조금씩 이전하는 단계에서 사용하는 방식이다.

 

 

CQRS (Command Query Responsibility Segregation)

핵심 비지니스 명령(Command)와 조회(Query)를 분리.

 

왜 필요한가?

광고 리스팅을 조회할때 만약에 CQRS패턴으로 되어있지않고, Rest API방식으로 되어있다면

조회할때마다 광고 서비스가 장애 발생시에 광고 리스팅도 정상으로 동작하지않는 문제가 발생함.

 

배달의민족 CQRS

광고 정보 및 가게 정보 Create,Update,Delete 관련된거는 따로 가지고,

Select 조회성 데이터만 따로 View전용 서비스로 빼서 서비스를 운영중임.

 

 

 

 

 

 

 

 

 

 

 

 

이론 공부 완료시, 해당 영상을 통해서 실무 MSA대한 이해와 시야를 넓히는데 큰 도움이 될 수 있음.

- 김영한 배민서비스개발팀 :  https://youtu.be/BnS6343GTkY  [배달의민족 마이크로서비스 여행기]

 

1. A과제를 하면 매출이 100억을 벌고,

B과제(Legacy시스템 MSA 전환 또는 다가올 미래에 대한 서비스 안정성 pjt)를 하면 장애가 해결되고, 시스템 안정성이 높아지지만

회사에 비용이 막대하게 발생함 -> 당연히 B과제는 우선순위가 떨어짐.

또한 B과제를 진행하더라도 비지니스 요구사항은 계속 들어오는데 `달리는 마차에 바퀴를 갈아끼운다`라고 불림.


2. 우리 시스템에서 CQRS패턴을 적용할게 없나?


3. 현재 Oracle 엄청난 양의 DB를 어떻게 RDB, NoSQL로 옮길건가?

- 배치를 통해서 무한 insert쿼리 활용



4. 꼭 MSA를 해야하나요?

규모의 경제가 되야 도입이 가능하다.

시스템 규모, 트래픽, 사용자도 많아야함.

Monolithic에 비해서 10배 가까이 비용이 더 발생할 수 있는데 그걸 감당하고 해야하는 이유를 찾아야함.