silver's develop note

DDD의 전략적 설계

silver_sun — Mon, 8 Apr 2024 20:04:55 +0900

DDD에는 전략적 설계와 전술적 설계라는 개념이 존재한다. 그 중 DDD 의 핵심이라고 말할 수 있는 전략적 설계에 대해 작성해본다.
(유튜브 영상 "[NHN FORWARD 22] DDD 뭣이 중헌디?" 와 "도메인 주도 설계로 시작하는 마이크로서비스 개발" 서적을 참고하였다. )

설계	전략적 설계	전술적 설계
범위	전반적	특성 바운더리 컨텍스트
목적	문제 도메인을 해결영역으로.	풍부한 도메인 모델 적용
메타포	전쟁에서 전략	전투에서 전술
주요패턴	바운터리 컨텍스트, 유비쿼터스 언어, 애그리거트, 도메인 이벤트
수행 방식	접근법	상대적으로 방법론에 가까움

DDD의 전략적 설계

비지니스 응집성을 고려하여 컨텍스트를 구분하고 나누어 설계한다.

컨텍스트는 어디서부터 시작이 되는 걸까?

비지니스 도메인에서 발생하는 상황들을 문제 도메인으로 추출하고, 해당 문제 도메인를 가지고 문제 공간을 만들어 문제 공간에서 정의된 것들을 해결 공간으로 바꾸는 과정이 전략적 설계의 큰 흐름이라고 할 수 있다.

[NHN FORWARD 22] DDD 뭣이 중헌디?

비지니스 도메인 : 현실 세계
문제 도메인 : 소프트웨어 세계

라고 이해해도 좋다.

위 말을 풀어서 이야기하자면, 현실에서 우리가 고민하게 되는 비지니스 적인 문제들 중, 소프트웨어로 해결하고자 하는 것이 있다면 그것들을 문제 공간으로 추출하고, 소프트웨어에서 어떻게 해결할 수 있을지 고민하고 해결하는 과정이다.

이 과정에서 컨텍스트가 생기기 시작하는데, 컨텍스트를 추출하기 위해서는 우선 도메인 추출이 되어야한다.

그 전에, DDD에서 말하는 핵심 중에 하나인 유비쿼터스 언어를 집고 넘어가자.

유비쿼터스 언어 (Ubiquitous-Language) (도메인 언어)

유비쿼터스 언어 (도메인 언어) : 특정 도메인의 의도를 명확히 파악, 반영하고 도메인의 핵심 개념을 잘 전달할 수 있는 언어를 협업 구성원들이 약속하고 통용적으로 사용하는 언어.

이러한 유비쿼터스 언어를 사용하라고 말하고 있는데, 이 말은 즉, 각 개념들을 지칭하는 말들을 약속하여 모두 동일하게 사용하자는 뜻이다.
(ex. 서비스를 이용하는 유저 : "회원" 이라고 부르자.)

이런 유비쿼터스 언어를 조직에서 사용하여 커뮤니케이션하고 모델 정제를 지속할 수 있는 것이 DDD의 전략적 설계의 핵심이라고 할 수 있다.

도메인의 추출

도메인 전문가, 개발자 등등 해당 도메인을 담당하는 모든 조직원이 모여, 문제 도메인에서 여러개의 하위 도메인을 도출한다.(하위 도메인 : 서브 도메인)

서브 도메인을 도출했다면, 그것들을 가지고 서브 도메인의 성격을 구분한다.

서브 도메인은 세 가지로 구분할 수 있다.

핵심 서브도메인 : 차별화를 만들 비지니스 영역. 우선순위가 높다. 소프트웨어 개발에서 전략적으로 가장 큰 투자가 필요한 영역.
지원 서브도메인 : 핵심 서브도메인을 지원하기 때문에, 비지니스에 있어 필수적이지만 핵심은 아닌 영역.
일반 서브도에인 : 비지니스적으로 특화된 영역을 아니나, 전체 비지니스 솔루션에는 필요한 영역.

인터넷 예매라는 문제 도메인을 하위 도메인으로 분리한다. (하위 도메인 : 서브 도메인)

[NHN FORWARD 22] DDD 뭣이 중헌디?

분리한 서브 도메인이 각각 어떤 성격의 도메인인지, 서브 도메인의 성격을 추출한다.

[NHN FORWARD 22] DDD 뭣이 중헌디?

예시 상황에서는

예매 : 핵심 서브도메인
상품, 도면 : 지원 서브도메인
회원 : 일반 서브도메인

으로 구분하였다.

이렇게 서브 도메인까지 도출이 되었다면, 해결 공간으로 이동하여 직접적인 소프트웨어 해결 방안을 모색하기 시작한다.

해결 공간

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

해결공간에서 모델들 사이에 경계를 만들어주는 것.
(이곳에서도 역시 유비쿼터스 언어의 사용이 중요하다! - 바운디드(경계)가 달라지면 사용되는 유비쿼터스 언어도 달라질 수 있다. )

바운디드 컨텍스트를 활용하면, 작업 중 모호해질 수 있는 모델의 무결성을 지켜준다.

1. 동일한 언어로 되어있는 서로 다른 개념들이 존재할 경우

바운디드 컨텍스트를 사용하므로써 동일한 언어임에도 각각의 개념들의 의미가 명확해진다.

[NHN FORWARD 22] DDD 뭣이 중헌디?

각각의 바운디드 컨텍스트 안에서 개념 모델의 의미가 명확해졌다.

2. 동일한 개념 모델이지만, 여러 곳에 의존해야할 경우

[NHN FORWARD 22] DDD 뭣이 중헌디?

넓은 영역으로 하나의 모델이 의존하므로 해당 모델이 상당히 큰 복잡도를 지니게 된다.

[NHN FORWARD 22] DDD 뭣이 중헌디?

각각의 바운더리 컨텍스트 안에서 필요한 만큼만 참조하여 모델의 복잡도가 줄어들었다.

모델은 소프트웨어나 컨텍스트 안에서 해결해야할 문제에 대해서만 알고 있으면 된다.
=> 이것이 바로 모델의 목적이라고 할 수 있다.

바운디드 컨텍스트 별 전술 설정

[NHN FORWARD 22] DDD 뭣이 중헌디?

각 서브도메인이 가지는 성격에 맞게 바운디드 컨텍스트 별 전술을 설정할 수 있다.

역콘웨이의 전략

콘웨이의 법칙?
소프트웨어의 구조는 해당 소프트웨어를 개발하는 조직의 구조를 따라간다.

그렇다면 "역"콘웨이의 법칙이란?

-> 개발하는 조직의 구조를 소프트웨어의 구조에 맞추는 것.

위와 같은 상황이라면, 핵심 도메인이 되는 예매 바운디드 컨텍스트 쪽에 조직내의 실력자들을 배치하고, 비용을 투자한다.
중요도가 낮은 일반 도메인은 외부업체를 쓰거나 하는 방식으로 해당 작업에 대한 비용을 낮춘다.

컨텍스트 맵 (Context-Map)

바운디드 컨텍스트 사이의 매핑 다이어그램을 그린 것.

컨텍스트 맵 : https://silvers-dev-note.tistory.com/52 참고

DDD 에 대한 오해

- DDD는 MSA 와 직결된다?

모델을 쪼개는 그림이 유사하여 많이 결합해서 사용하는 것이지, MSA를 한다고 해서 무조건 DDD를 적용해야하는 것은 아니며, DDD라고 해서 무조건 MSA 를 구현하는 것은 아니다.

- DDD는 방법론이나 기술이나 구현 영역이다.

해당 발언들은 DDD의 전술적 설계에 국한된 표현으로 생각할 수 있다. 흔히 많은 개발자들이 DDD의 핵심인 전략적 설계는 잘 생각하지 않고 보다 개발,코딩과 근접한 전술적 설계만을 많이 생각하고 하는 표현들인데, 사실 DDD의 핵심은 전략적 설계이고 굳이 정하여 말한다면 방법론,기술 보단 추상적인 철학이나 접근법으로 바라보는 것이 좋다.

DDD는 결국 비지니스 소프트웨어를 수행하기 위한 철학인 것 같다. 단지 개발에만 국한되는 것이 아니라 일하는 방식, 협업, 조직 체계, 아키텍처 등등 모든것을 아우르고 소개하고 있으니 말이다.

컨텍스트 맵(Context Map) 작성하기

silver_sun — Mon, 8 Apr 2024 16:47:22 +0900

컨텍스트 맵?

시스템을 구성하는 컨텍스트 간의 매핑 관계를 표시한 다이어그램.

컨텍스트 맵을 그리는 정형화된 규칙은 따로 없는 것 같다. 팀에서 서로 이해할 수 있게 정의하고 표현하면 될 것으로 보인다. 그러나 각 컨텍스트 사이에 존재하는 개념을 이해하고 있어야 컨텍스트 맵을 그릴 수 있기 때문에, 사용하게 되는 각 개념에 대해 소개한다.

컨텍스트 맵 그리는 방법

컨텍스트 맵에서 사용되는 표기 패턴.

공유 커널(Shared Kernel)
- 두 개 이상의 컨텍스트 사이에 공통적인 모델을 공유하는 관계.
- ex) 공통 라이브러리

공유 커널(Shared Kernel)

Tip : 공유 커널에 해당하는 부분에서 변경사항이 발생할 경우, 여러 컨텍스트에 영향을 미치기 때문에 한 팀에서 관리하고 공유하는 것이 좋다.
소비자-공급자(Customer-Supplier)
- 정보를 공급하는 컨텍스트, 정보를 공급받는 컨텍스트의 관계. 공급자는 upsteam, 소비자는 downstream 으로 표기한다.
- 흐름은 상류 → 하류의 흐름만 가능하고, 상류에서 변경사항이 생긴다면 하류에서는 해당 변화를 따라야한다.
- 소비자가 원하는 기능을 공급자가 제공할 수 있도록 구현해야한다.
- 소비자는 공급자의 변화에 직격타를 맞지 않도록 내부를 보호할 수 있는 완충지대를 만들어야한다. (OHS)

소비자-공급자(Customer-Supplier)

순응자(Confirmist)
- 소비자-공급자와 유사하지만, 상류에서 하류의 요구를 지원하지 않거나 못하는 경우 사용한다.
- 이런 상황에서는 하류는 상류에서 제공하는 모델을 그대로 사용한다.

충돌 방지 계층(ACL; Anti-Corruption Layer)
- 충돌 방지 계층은 하류에서 상류의 영향을 받을 때 하류 고유 모델을 지키기 위한 번역 계층. 여기선, 상류와 하류의 차이를 번역하고 하류 모델의 독립성을 유지시킨다. 즉, 상류의 변화로 인해 하류의 모델이 영향을 받지 않도록 보호하는 것.
- 보통 레거시 → msa 로 전환하려고 할 때 많이 쓰이는 패턴이라고 한다. (충돌 방지 계층을 두어 msa 로 전환을 준비하고 추후에는 해당 계층을 없애고 상류-하류를 연결하면 된다.)

충돌 방지 계층(ACL; Anti-Corruption Layer)

공개 호스트 서비스(OHS; Open Host Service)
- 바운디드 컨테스트에 대한 접근을 제공하는 프로토콜이나 인터페이스를 정의한다.
- 이 프로토콜은 하류의 컨텍스트가 상위 컨텍스트에서 제공하는 기능을 용이하게 사용할 수 있도록 공개돼 있다. 보통 다른 컨텍스트에서 사용할 수 있는 공유된 API 가 여기에 해당한다.

공개 호스트 서비스(OHS; Open Host Service)

발생된 언어(PL; Published Language)
- 하류에서 상류의 기능을 사용할 수 있도록 정의해놓은 문서화된 정보 교환 언어다. XML 이나 JSON 스키마로 표현될 수 있으며, 주로 공개 호스트 서비스(OHS)와 짝을 이뤄사용된다.

발생된 언어(PL; Published Language)

비동기 이벤트(Async)
- 메시지 브로커를 통한 비동기 통합. 결과적 일관성을 바라본다. 개발 난이도가 상승할 수 있다.

컨텍스트 맵의 예

이벤트 스토밍(Event Storming)

silver_sun — Sat, 6 Apr 2024 13:23:43 +0900

이벤트 스토밍(Event Storming)

구성원이 모두 모여, 벽이나 화이트 보드 같은 넓은 공간에 포스트잇(메모지)를 붙여가며 비지니스에서 발생할 수 있는 여러 이벤트들을 정리하는 브레인 스토밍으로 알베르토 브란돌리니가 고안해낸 설계 기법이다.

각 정의 개념마다 원하는 색깔을 지정하여 한 눈에 보기 좋게 구분한다.

정의할 개념들.

(색상은 알베르토 브란돌리니가 정의한 색상들이다. 색상이 중요하다기보단, 내용이 중요한 것이니 조직에서 원하는 바가 있다면 변경하여도 무관할 것.)

도메인 이벤트
- 발생한 사건. 과거시제동사로 표현한다.
- 오렌지색
커맨드
- 도메인 이벤트를 트리거하는 명령.
- 파란색
외부 시스템
- 도메인 이벤트가 호출하거나 괜계가 있는 레거시 or 외부 시스템
- 분홍색
액터
- 개인 or 조직의 역할
- 노란색. 메모지의 사이즈는 작은 크기로 지정.
애그리거트
- 도메인 이벤트와 커맨드가 처리하는 데이터. 상태가 변경되는 데이터.
- 노란색
정책
- 이벤트 조건에 따라 진행되는 결정
- 라일락색 (연보라, 옅은 자색)
읽기 모델
- 도메인 이벤트 액터에게 제공되는 데이터
- 초록색
사용자 인터페이스
- 스케치 형태의 화면 레이아웃
- 흰색
핫스팟
- 의문, 질문, 미결정 사항
- 보라색

이벤트 스토밍 진행 순서

1. 도메인 이벤트 찾기

이벤트명은 과거동사로 작성한다.
비지니스의 어떤 상태를 생성, 변경, 삭제하는 요소를 생각하여 작성한다.
왼쪽에서 오른쪽으로 시간의 흐름 순으로 붙인다.
- 이벤트가 연쇄적으로 발생하는 경우는 바로 옆에 붙인다.
- 같은 시점에 비지니스 조건에 따라 대체적으로 발생할 수 있는 이벤트는 아래쪽에 붙인다.

2. 외부 시스템/ 외부 프로세스 찾기

이벤트를 도출하다가, 레거시 시스템이나 외부 시스템과의 연계를 통해 업무의 흐름이 진행되는 것이 생겼을 때 작성한다.
시스템 이름을 명사 형태로 작성한다.
분홍색 스티커에 작성하여 해당되는 이벤트의 우측 상단에 붙이고 화살표로 이어준다.

3. 커맨드 찾기

도메인 이벤트를 동작하게 하는 것들을 파란 스티커에 작성한다.
명령형, 동사 형대로 작성한다.
ex) [회원 가입됨] 에서 [회원가입] 커맨드를 도출.

4. 핫스팟 찾기

이벤트 스토밍을 진행하며 생기는 모든 의문점, 미결정 사항들을 보라색 스티커에 작성하여, 문제가 되는 위치에 붙인다.

5. 액터 찾기

커맨드를 실행할 수행자/조직을 지정하는 것.
- 업무 담당자를 지정하는 것이 아니라, 비지니스 시나리오 상에서 해당 커맨드를 어떤 사람이 실행하게 될까? 를 생각하여 작성하는 것이다. ( ex. 회원가입은 게스트가 한다.)
추상적인 개념이 아니라, 실제로 비지니스를 수행하는 구체적인 역할을 고려하여 작성한다.
노란색의 작은 포스트잇에 작성하여 해당하는 커맨드의 좌측 하단에 붙인다.

6. 애그리거트 정의하기

애그리거트명은 도메인의 실체 개념을 표현할 수 있는 단어로 지정한다.
노란색 스티커에 작성하여 이벤트와 커맨드 사이의 상단에 겹쳐 붙인다.

7. 바운디드 컨텍스트 정의하기

이름이 같거나 유사한 애그리거트가 붙어있는 것들끼리 묶어, 다른 애그리거트와 경계를 만든다.
각 바운디드 컨텍스트들이 가지고 있는 애그리거트 중 적절한 것을 골라 바운디드 컨텍스트명을 지정해준다.
바운디드 컨텍스트를 정의한 후, 각 컨텍스트사이의 연관 관계와 정책들을 도출한다.
- 정책은 다음과 같이 정의할 수 있다.
- [도메인 이벤트] 할 때는 항상 [커맨드] 한다.
- 정책은 이벤트 뒤에 따라오는 반응적인 비지니스 로직으로, 커맨드를 동작하게 한다.

8. 컨텍스트 매핑하기

각 바운디드 컨텍스트 간의 관계를 컨텍스트 맵으로 표현해본다.’
컨텍스트 간에 항상 일관된 데이터가 필요한 관계는 동기 호출로 표현하고, 결과적 일관성으로 충분히 처리 가능한 관계는 비동기 방식의 호출로 표현한다.

이벤트 스토밍 해볼 수 있는 사이트

https://labs.msaez.io/#/courses/fea33dd0-8030-11ed-9757-3db21672e322/1f2deec0-c856-11ed-aa53-950d34db487f/ddd-google-drive-associate

MSA Easy

labs.msaez.io

https://miro.com/ko/

Miro | 혁신을 위한 시각적 작업 공간

Miro는 팀이 프로젝트를 관리하고, 제품을 디자인하고, 미래를 함께 만들어가는 혁신을 위한 시각적 작업 공간입니다. 전 세계 6천만 명 이상의 사용자와 함께하세요.

miro.com

DDD를 곁들인 마이크로서비스 아키텍처 설계

silver_sun — Fri, 5 Apr 2024 17:14:03 +0900

아키텍처를 설계하고, 좋은 코드를 작성하는 방법에 대해 고민하는 과정들은 결국 "좋은" 소프트웨어를 구현하기 위한 것일 것이다.

그렇다면 아키텍처를 구상해보기 전에, "좋은" 소프트웨어란 무엇일까에 대해 집어보자.

좋은 소프트웨어 시스템?

소프트웨어의 가치는 행위 가치와 구조 가치로 나뉘고, 소프트웨어를 정말로 부드럽게(Soft) 만드는 것은 구조 가치이다.
Clean Architecture - Robert C. Martin

☝ 행위 가치 : 소프트웨어의 기능
☝ 구조 가치 : 소프트웨어 아키텍처

로버트는 코드와 설계의 구조를 깔끔하게 만들려는 생각을 하지 않고 기능 구현만 목적으로 삼으면 소프트웨어가 엉망이 된 상황에 대처하는 데 더 많은 비용이 든다며 구조 가치. 즉, 아키텍처 설계에 대한 중요함을 강조한다.

이 말을 다른 시야로 해석한다면 결국 책에서 말하고 있듯, “기능이 잘 동작하는 것과 더불어 이해하기 쉽고 변경하기 쉬운 시스템” 을 만드는 것이 중요하다는 의미로 해석된다.

개발자의 역할은 문제 영역의 비즈니스 로직을 분석 및 이해하고 프로그래밍 언어라는 도구로 잘 표현하는 일이다. 여기서 잘 표현한다는 것은 기능이 잘 동작하는 것과 더불어 이해하기 쉽고 변경하기 쉬운 시스템을 만드는 것을 의미한다.
도메인 주도 설계로 시작하는 마이크로서비스 개발 - 3장 중…

기능이 잘 동작하며, 유지보수에 유연하고, 변화에 빠르고 부드럽게 대응 할 수 있는 시스템을 만들자.

그러한 시스템을 만들기 위해서는 어떤 것들을 고려해야 할까?

관심사의 분리 (separation of concerns)
- 비지니스 로직과 기술 로직을 구분하자.
- 데이터베이스 중심의 아키텍처에서 벗어나자. (비지니스 중심의 아키텍처를 지향하자.)
  - 데이터베이스 중심의 아키텍처를 기반으로 작업을 하게 된다면, 중심이 되는 곳이 데이터베이스이기 때문에 클라우드 인프라를 사용하는 가장 큰 장점인 자동 스케일 아웃이 의미가 없어진다. 백날 애플리케이션을 확장해봤자, 결국 부하가 가장 크게 일어나는 곳은 데이터베이스이기때문에 얻을 수 있는 효과가 미미하다.
비지니스 중심의 아키텍처.
- 헥사고날 아키텍처
- 클린 아키텍처

마이크로서비스 아키텍처

MSA와 유사한 구조를 가진다는 DDD 설계 방식을 따르는 헥사고날 아키텍처, 클린 아키텍처를 참고하여 다음과 같은 아키텍처 규칙들을 도출할 수 있다.

지향하는 관심사에 따라 응집성을 높이고 관심사가 다른 영역과는 의존도를 낮춘다.
업무 규칙을 정의하는 비지니스 로직 영역을 다른 기술 기반 영역으로부터 분리하기 위해 노력한다.
세부 기술 중심, 저수준의 외부 영역과 핵심 업무 규칙이 정의된 고수준의 내부 영역으로 구분한다.
고수준 영역은 저수준 영역에 의존하지 않게 해야하며, 저수준 영역이 고수준 영역에 의존하게 한다.
저수준 영역은 언제든지 교체, 확장이 가능해야하고 이 같은 변화가 고수준 영역에 영향을 줘서는 안 된다.
자바처럼 인터페이스 및 추상 클래스를 지원하는 언어의 경우 저수준 영역의 구체 클래스가 고수준 영역의 추상 인터페이스에 의존하게 하는 의존성 역전의 원칙을 적용한다.
인터페이스는 고수준의 안정된 영역에 존재해야하며, 저수준의 어댑터가 이를 구현한다.

마이크로서비스 예시

내부 영역

내부 영역에서는 업무 규칙을 정의한다. 도메인 모델 패턴을 사용하여 내부 로직을 구현한다.

내부 영역 구조

인터페이스 : 정의 했던 아키텍처 규칙에 맞게, 인터페이스는 고수준 영역에 존재하고 저수준의 외부 어댑터가 인터페이스를 구현하게 설계되어있다.
- 서비스 인터페이스
- 레포지토리 인터페이스
- 도메인 이벤트 인터페이스
- 프록시 인터페이스
서비스 : 도메인을 활용하여 시스템의 흐름 처리.
도메인 : 비지니스 개념을 표현.

내부 영역 구현 방식

Aggregate 사용.
Aggregate : 개념적으로 연관된 도메인들을 묶어 놓은 것.

애그리게이트를 사용하며, 다음과 같은 규칙들을 소개한다.

애그리게이트 루트만 참조한다.
애그리게이트 내 상세 클래스를 바로 참조하지 않고 루트를 통해 참조해야한다. 수정할 때도 마찬가지다.
애그리게이트 간의 참조는 객체를 직접 참조하는 대신 기본키를 사용한다. (JPA 기준 : 엔티티 필드값으로 연관관계 매핑을 걸어 참조하지 말고, PK를 갖게한다.)
기본키를 사용하면 느슨하게 연관되고 수정이 필요하지 않은 애그리게이트를 함께 수정하는 실수를 방지한다.
하나의 트랜잭션으로 하나의 애그리게이트만 생성 및 수정한다.

외부 영역

외부 영역은 내부 영역의 인터페이스를 구현하는 여러 어댑터들로 구성된다.

API 어댑터
클라이언트와 주고 받는 REST API 관리.
API Proxy 어댑터
타 마이크로서비스의 API 를 호출하는 어댑터. 호출하려는 서비스에 구현되어있는 방식에 맞게 통신방법을 선택한다. (ex. REST, SOAP, Socket.io etc…)
DB 어댑터
- ORM (Object Relation Mapping) - ex. JPA, Spring Data JPA
- SQLM (SQL Mapping) - ex. Mybatis
두 가지 방법 중 선택하여 사용한다. (자바를 사용하는 경우 기준)
도메인 이벤트 발행 어댑터
도메인에서 이벤트가 발생했을 경우 메세지 브로커로 이벤트를 발행시키는 어댑터.
도메인 이벤트 핸들러 (이벤트 수신 어댑터)
메세지 브로커에서 해당 도메인에 관련된 이벤트가 발생되었을 경우 수신해 올 어댑터.

DDD를 적용한 전략적 설계

DDD의 전략적 설계 : https://silvers-dev-note.tistory.com/53 참고

유비쿼터스 언어

DDD 의 전략을 도입하여 마이크로서비스를 설계함에 있어서, "유비쿼터스 언어" 라는 개념이 등장한다.

또한, 이렇게 도메인에서 비지니스 적으로 정의한 용어를 코드에서 동일하게 사용하도록 하자.
그렇게해서 헷갈림없이 누구나 동일한 용어를 사용할 수 있어야한다.

컨텍스트

도메인과 서브도메인을 설계하여 바운더리 컨텍스트를 구분하고, 컨텍스트 맵을 작성하자.
컨텍스트 맵 : https://silvers-dev-note.tistory.com/52

서브도메인
- 핵심 서브도메인 : 차별화를 만들 비지니스 영역. 우선순위가 높다. 소프트웨어 개발에서 전략적으로 가장 큰 투자가 필요한 영역.
- 지원 서브도메인 : 핵심 서브도메인을 지원하기 때문에, 비지니스에 있어 필수적이지만 핵심은 아닌 영역.
- 일반 서브도에인 : 비지니스적으로 특화된 영역을 아니나, 전체 비지니스 솔루션에는 필요한 영역.

서브도메인으로 구성한 컨텍스트 맵

서브도메인-컨텍스트 맵의 예.

세부 설계

마이크로서비스를 세부적으로 설계하는 방법을 순차적으로 기입해보겠다.

비지니스 이해 (비지니스에 대한 이해가 없다면 앞으로의 과정을 수행할 수 없다.
이벤트 스토밍을 통해 바운디드 컨텍스트 분류.
- 이벤트 스토밍 : https://silvers-dev-note.tistory.com/51
모델링
- 프론트엔드 모델링
  - 아키텍처 정의
  - 표준 레이아웃 정의
  - UI 레이아웃 설계
  - UI 디자인 및 UI 레이아웃 반영
  - 이벤트 설계
- 백엔드 모델링
  - 이벤트 스토밍을 통해 도출된 결과물을 가지고 패키지 구조 및 아키텍처 설계
  - API 설계
  - DDD의 전술적 설계를 이용한 도메인 모델링

DDD가 결합된 마이크로서비스 아키텍처를 요약한다면 다음 그림과 같다고 볼 수 있을 것 같다.

참고 서적

- 도메인 주도 설계로 시작하는 마이크로서비스 개발

도메인 주도 설계로 시작하는 마이크로서비스 개발 part 2-2.

silver_sun — Mon, 1 Apr 2024 20:58:53 +0900

2-1 에 이어 작성한다. (https://silvers-dev-note.tistory.com/46)

2.3~2.4 마이크로서비스의 아키텍처와 패턴

외부 아키텍처
- 인프라 영역, 플랫폼 영역, 애플리케이션 영역
내부 아키텍처
- 비지니스 애플리케이션(백엔드 서버 구성이라고 볼 수 있다.)

마이크로서비스를 구현하기 위한 방법과 패턴

크게 인프라, 플랫폼, 애플리케이션. 이렇게 3가지 단으로 나누어 패턴을 분류하고 있다.

인프라

컨테이너
- 애플리케이션을 분리하여 여러개의 작은 서비스를 배포해야하는 마이크로서비스 특성에 맞게, 컨테이너 환경에 사용하여 인프라를 구성하는 것이 좋다. (책에서는 가장 많이 쓰이는 도커를 예시로 들고 있다.)
컨테이너 오케스트레이션
- 여러개의 컨테이너들을 보다 손쉽게 관리하기 위해 컨테이너 오케스트레이션 툴을 사용하는 것이 좋다. (책에서는 쿠버네티스를 예시로 들고 있다.)
- 컨테이너 오케스트레이션은 확장, 장애 대응, 모니터링 등 다양한 기능들을 지원한다.
다양한 클라우드 인프라 서비스
- AWS, Azure, GCP 등 많은 곳에서 클라우드 서비스를 제공하고 있다. 상용화된 클라우드 서비스들이 상당히 많아 비용, 기술, 형태 등등 나에게 맞는 것을 찾아 효율적으로 사용할 수 있다.
  - IaaS(Infrastructure As a Service)
    - 가상 머신, 스토리지, 네트워크 같은 인프라를 필요한 만큼 적시에 제공하는 서비스. 사용자는 이러한 인프라를 이용해 개발 환경을 구성한 후 애플리케이션을 배포한다.
    - 예 ) AWS EC2, GCP Compute Engine, Azure VM
  - CaaS(Container as a Service)
    - 컨테이너 기반 가상화를 사용해 컨테이너를 업로드, 구성, 실행, 확장, 중지할 수 있는 서비스. 애플리케이션을 바로 구동할 수 있는 환경을 제공한다는 점에서 PaaS와 유사하지만, 다른 환경에도 이식 가능한 컨테이너 기반 가상화를 제공한다.
    - 예 ) AKS(Azure Kubernetes Service), AWS EKS, GKE, AWS ECS
  - PaaS(Platform as a Service)
    - 복잡함 없이 애플리케이션을 곧바로 개발, 실행, 관리할 수 있는 플랫폼 환경을 서비스 형태로 제공한다. IaaS 위에 실제로 애플리케이션이 실행될 수 있는 미들웨어나 런타임까지 탑재된 환경이라 생각하면 된다.
    - 예 ) Azure Web App, Google App Engine, Cloud Foundry, Heroke …
- 클라우드 서비스는 크게 3가지 유형으로 나뉘고, 책에서는 유형별로 먼저 탐색을 하면 필요한 서비스를 찾는 것에 도움이 될 것이라고 안내하고 있다.

플랫폼

MSA 시스템을 구성하는 수많은 마이크로서비스를 하나하나 수동으로 빌드하고 배포하는 비효율적인 과정을 없애기 위해 자동화할 수 있는 플랫폼 패턴을 가져가는 것이 중요하다.

CI/CD 파이프라인 설계
- 책에서 예시로 보여주는 배포 파이프라인 절차

이처럼 배포 파이프라인 절차를 정하고, 클라우드 서비스를 이용하여 하나의 파이프라인을 수많은 마이크로서비스 서버에 적용할 수 있다.
(예를 들어, yml 파일에 파이프라인 절차를 작성하고 해당 yml 파일을 마이크로서비스를 관리하는 클라우드 서비스에 사용하여 세부적인 정보들만 각 서버에 맞는 환경변수로 작성해준다면 동일한 파이프라인을 손쉽게 여러 곳에 적용할 수 있다. )
마이크로서비스 관리/운영 패턴
- 마이크로서비스를 도입하여 성공한 대표적인 사례 중 하나가 넷플릭스이다. 넷플릭스에서는 자신들이 어떤 식으로 마이크로서비스를 구성하고 관리하였는지 오픈소스를 통해 공유하고 있다. (넷플릭스 OSS)
- 넷플릭스 OSS를 쉽게 사용할 수 있도록 스프링진영에서 개발한 것이 스프링 클라우드이다. 스프링 부트 + 스프링 클라우드의 조합은 마이크로서비스를 비교적 쉽게 구축할 수 있는 대표적인 관리/운영 패턴으로 자리매김하고 있다.
서비스 디스커버리 패턴
- 백엔드 MSA 서비스의 명칭과 유동적인 IP정보를 매핑하고, 매핑된 정보를 저장하는 저장소를 두어 관리하는 패턴.
API 게이트웨이 패턴
- 클라이언트가 API 를 호출할 수 있는 단일 진입점(게이트웨이)을 만들어, 클라이언트는 해당 진입점으로만 요청을 취하고, 진입점에서 요청에 알맞는 서버로 요청을 보내는 방식.
- 게이트웨이에 모든 API 요청에 대한 공통 기능을 수행하도록 구현한다면 더욱 효율적인 게이트웨이를 사용할 수 있다.
  - API 게이트웨이에서 할 적절한 기능
    - 레지스트리 서비스와 연계한 동적 라우팅, 로드 밸런싱
    - 인증 / 인가
    - 로그 집계 및 로깅
    - 메트릭 데이터 추출 및 확인
    - 트레이싱 서비스와 연계한 서비스 추적.
    - 모니터링 서비스와 연계한 장애 격리(서킷 브레이커 패턴)
API 게이트 웨이는 스프링 클라우드의 spring API gateway service 를 통해 비교적 쉽게 구현할 수도 있다
쿠버네티스 + 인그레스 조합으로도 구현할 수 있다.
BFF 패턴
- BFF(Backend For Frontend) = 프런트엔드를 위한 백엔드 패턴으로, 웹, 앱 등등 … 클라이언트 유형에 따라 진입점(게이트웨이)를 설정하는 방식이다.
- 이러한 방식을 통해서 각각의 클라이언트에게 꼭 필요한 기능들만 체크할 수 있게 할 수 있고, 공통된 부분들은 공통 게이트웨이를 통해 공통적으로 묶어 처리할 수 있다.
- 클라이언트마다의 진입점을 분리해놓았기 때문에 각 클라이언트에 변경사항이 발생했을 경우에 타 클라이언트에 영향을 미치지 않고 작업할 수 있다.
외부 구성 저장소 패턴
- 데이터베이스 연결 정보, 파일 스토리지 정보 같은 외부 환경 설정 정보들을 외부 저장소에 저장하고, 해당 외부 저장소를 사용하는 방식.
  스프링에서는 spring Config 를 이용하면 보다 손쉽게 구현할 수 있다. 쿠버네티스에서는 이러한 방식을 쿠버네티스 ConfigMap 으로 제공하고 있다.
인증/인가 패턴
- 인증 / 인가는 공통된 보안이므로 모든 MSA 서버마다 구현하는 것은 상당히 비효율적이다. 그렇기에 인증 / 인가를 제공하는 서버 하나를 구현하고 인증 / 인가가 필요할 땐 해당 서버를 통하는 방식이다.
  
  일반적으로 MSA에서는 다음과 같은 패턴들을 사용한다고한다.
- 세션 방식
  - 각자의 서비스에 세션을 저장하지 않고, 공유 저장소에 세션을 저장하고 모든 서비스가 동일한 사용자 데이터를 얻도록 한다. (보통 세션 저장소로는 레디스나 멤캐시드를 사용한다.)
- 토큰 방식

토큰 방식

- ➕ OAuth 를 사용하여 타 애플리케이션과 나의 인증 서버를 연계하는 방법도 있다.

서킷 브레이커 패턴
- 장애가 발생한 서비스를 격리해서, 타 서비스에 영향을 미치지 않도록 처리할 수 있는 방법.
1. 임계값 설정
  1. 요청 실패에 대한 임계값을 설정하고 해당 값이 초과하면, 장애가 발생한 해당 서비스를 호출하려는 모든 시도를 실패하게 만들어, 어차피 실패할 요청에 대한 응답을 기다리는 대기 시간을 발생하지 않도록 한다.

폴백(fallback) 메서드 지정

폴백 메서드를 지정해두면 폴백 메서드가 자연스럽게 장애를 처리하고, 사용자는 특정 서비스에 장애가 발생했는지 눈치채지 못하게 된다. 폴백 메서드는 장애 발생시 대체할 수 있는 로직을 구현해놓을 수 있기 때문에 어떻게 구현을 해놨느냐에 따라 사용자는 장애 발생여부를 전혀 눈치채지 못할 수도 있다.

폴백 메서드(fallback method)특징
Fallback 메서드는 일반적으로 서비스 호출이 실패하거나 예외를 발생시킬 때 호출되는 대체 메서드이다. 주로 분산 시스템에서 사용되며, 일부 서비스가 다른 서비스와 통신할 때 발생할 수 있는 장애 상황에 대비하여 구현된다.

특징
비상 상황 대처: 주요 서비스 호출이 실패했을 때, 대체 로직을 수행하여 시스템의 안정성을 보장한다. 이를 통해 전체 시스템의 성능을 유지하고 서비스 중단을 최소화할 수 있다.
설정 가능한 대체 로직: Fallback 메서드는 호출자가 원하는 대체 동작을 수행하도록 구현된다. 이를 통해 장애 상황에 대한 적절한 대응을 설정할 수 있고, 일반적으로는 기본값 반환, 캐시된 데이터 사용, 다른 서비스를 호출하는 등의 대체 동작을 수행한다.
서비스 내결함성: Fallback 메서드를 사용하면 일부 서비스의 장애가 전체 시스템에 영향을 미치는 것을 방지할 수 있다. 장애가 발생한 서비스 대신 대체 로직을 수행함으로써 사용자에게 최소한의 서비스를 제공할 수 있다.
코드 유연성: Fallback 메서드를 사용하면 코드의 유연성을 높일 수 있다. 서비스 간 의존성을 최소화하고, 각 서비스가 자체적으로 장애를 처리할 수 있도록 구성할 수 있다.

주의
Fallback 메서드가 일부 기능을 임시로 대체하는 것이므로, 장애가 해결되면 반드시 해당 기능을 복원해야한다.
Fallback 메서드가 호출되는 경우를 모니터링하고 로깅하여 시스템의 상태를 파악할 수 있어야 한다.

모니터링과 추적 패턴
- 당연하게도 애플리케이션의 장애를 감지할 수 있는 모니터링 기능의 필요하다. 그러나 마이크로서비스 특성상 장애 발생 시 서킷 브레이커 같은 패턴을 사용하게 되는데, 그러러면 모든 마이크로서비스들의 상태를 파악해야만한다. 즉, 모든 마이크로서비스를 한 눈에 모니터링 할 수 있는 방법이 필요하다.
- Spring Cloud - Hystrix Dashboard
  스프링 클라우드를 사용한다면, 스프링 클라우드의 라이브러리인 히스트릭스를 이용해, 손 쉽게 대시보드를 구성할 수 있다.

Hystrix Dashboard

이외에도 자바 진영에서는 Resilience4j 를 이용할 수도 있다.
쿠버네티스를 사용한다면 이스티오를 사용할 수도 있다.

- 자세한 내용은 공식문서 참고. 3. Circuit Breaker: Hystrix Clients

분산 트레이싱 서비스

책에서는 집킨이라는 오픈소스 프로젝트를 예시로 들고 있다.스프링 클라우드의 분산 트레이싱 서비스인 Sleuth 과 호환이 가능하다. 스프링 클라우드를 사용한다면, 의존성만 추가해주면 집킨을 손 쉽게 구현할 수 있다.
implementation 'org.springframework.cloud:spring-cloud-sleuth-zipkin'
집킨 → https://zipkin.io/

분산 트레이싱 서비스
분산된 마이크로서비스 아키텍처에서 서비스 간 통신을 추적하고 모니터링하기 위한 도구. 각 요청의 수명을 추적하여 성능 문제를 해결하고, 시스템의 동작을 이해하는 데 도움을 줄 수 있다.
Zipkin, Jaeger, AWS X-Ray, OpenTelemetry 등이 있다.

로그 집계 패턴
- 서버가 탄력적으로 변화하는 마이크로서비스에서는 로그가 끊여서는 안되며 이벤트 스트림으로 처리가 되어야 한다. 또한, 특정 인프라나 기술에 의존하게 되지 않도록 로그 스트림과 비지니스 서비스는 분리되어, 서로에게 관여하지 않아야 한다.책에서는 대표적으로 ELK 스택을 설명하고 있다.
  그래서 MSA 에서는 중앙화된 로그 집계 패턴을 사용한다.
- ELK (Elasticsearch Logstash Kibana)
  - Elasticsearch
    - 분산형 검색/분석 엔진
    - 정형, 비정형, 위치 정보, 메트릭 등 원하는 방법으로 검색을 수행하고 결합 할 수 있다.
  - Logstash
    - 로그 집합기
    - 데이터 처리 파이프라인. 다양한 소스에서 동시에 데이터를 수집해 변환한 뒤, 특정 보관소로 데이터를 보낸다.
  - Kibana
    - 시각화
    - 히스토그램, 막대 그래프, 파이차트 등을 표현. 위치 데이터, 시계열 분석, 그래프 관계 탐색 등을 지원한다.
(개인 경험으로, 분산 트레이싱 서비스처럼 요청의 수명을 추적하는 기능 또한 ELK 를 통해서도 확인 할 수 있었다. 상세한 API 호출 내역를 확인 할 수 있고, 어떤 class 를 통하는지 등등 상세한 내역을 확인 할 수 있다. )
서비스 메시 패턴
- 초창기 MSA 를 구현할때에는 API 게이트웨이, 서비스 레지스트리, 컨피그 서비스와 같이 운영 관리를 위한 여러 개의 기반 서비스를 별도로 각각 만들어야했다. 하지만 최근, 서비스 메시 패턴을 통해 그러한 번거로움을 줄일 수 있게 되었다.
  책에서는 대표적인 서비스 메시 패턴 구현체로 이스티오(Istio)를 설명한다.
  - 이스티오 Istio
    - 서비스 디스커버리, 라우팅, 로드 밸런싱, 로깅, 모니터링, 보안, 트레이싱 등의 기능을 제공한다.
    - 기본적으로 이스티오는 쿠버네티스에 탑재되어 서비스 메시 기능을 지원한다.
    - 이스티오는 애플리케이션이 배포되는 컨테이너로부터 완전히 격리되어 별도의 컨테이너로 배포되는 사이드카(Sidecar)패턴을 적용하고 있다.

애플리케이션

마이크로 서비스 통신 패턴
- 비동기 통신 방식을 사용하자.
  비동기 방식은 동기방식처럼 응답을 기다리지 않기 때문에, 완결성을 보장 할 수 없다. 그래서 우리는 메세지 브로커를 활용한다.
  메세지 브로커는 프로듀서, 컨슈머 사이에 구독이 발생하고, 구독하고 있는 컨슈머들에게 프로듀서가 메세지를 전달하는 방식의 메커니즘을 지니고 있다. 대표적인 메세지 브로커는 Kafka, RabbitMQ, ActiveMQ 등이 있다.
- 메세지 브로커는
  - 처리 규모에 따라 확장이 가능하다.
  - 통신하는 서비스들이 물리적으로 같은 시스템에 위치할 필요가 없다.
  - 서비스들끼리 프로세스를 공유할 필요가 없다.
  - 서비스들이 동시에 동작하지 않아도 된다.
  ⇒ 서비스 요구 사항에 따라 유연하고 탄력적으로 반응할 수 있다.
저장소 분리 패턴
- 각 마이크로서비스는 각자의 비지니스를 처리하기 위한 데이터를 직접 소유해야한다는 방식이다. 즉, 각 마이크로서비스는 마다의 DB를 지니도록 한다.
  - 정보은닉
    - 다른 서비스에 직접 노출하지 않고 각자가 공개한 API를 통해서만 접근한다.
  - 폴리글랏 저장소
    - 저장소가 격리돼 있기 때문에 각 저장소를 자율적으로 선택할 수 있다.
  - 영향도
    - 데이터를 통한 변경의 파급 효과를 줄여, 서비스를 독립적으로 만든다.
- 그렇기 때문에 다음과 같은 효과를 가질 수 있다.
분산 트랜잭션 처리 패턴
- 각 마이크로서비스 마다 DB를 지니고 있게 된 만큼 데이터 일관성을 지키는 것 또한 어려워졌다. 이렇게 나뉘어진 환경에서 일관성을 지키기 위해서는 분산된 서비스를 하나의 트랜잭션으로 묶지 않고, 각 로컬 트랜잭션과 보상 트랜잭션을 이용해 비지니스 및 데이터 정합성을 맞출 수 있다. 그러한 패턴으로 사가(Saga) 패턴이 있다.
- 이벤트 처리를 통해, 트랜잭션을 나누고 이벤트의 응답값을 통해 롤백이나 다음 과정을 진행하는 등의 액션을 선택하는 방식으로 구성한다.
CQRS 패턴
- CQRS (Command Query Responsibility Segregation) (CQRS에 대한 내용은 포스팅 참고.)
  1. 하나의 저장소에 쓰기 모델과 읽기 모델을 분리하는 방식으로 쓰기 서비스와 조회 서비스를 분리.
  2. 물리적으로 쓰기 저장소와 조회 저장소를 분리.
  쓰기 모델에서 업데이트가 발생하면 읽기 모델에도 해당 사항이 반영되어야할 것이다. 이러한 부분 역시, 이벤트를 통하여 처리한다. (이러한 방식을 이벤트 주도 아키텍처라고 한다고 한다.)그냥 API 를 가지고 통신해도 될텐데 왜 CQRS 패턴을 사용하는걸까?하지만 CQRS 패턴을 도입한다면, 그때그때 이벤트를 발생시켜 주문 내역(R)을 생성할 수 있다.
- API 통신으로 인해 하나의 주문 내역을 만들기 위해서는 제품, 주문, 고객, 배송 4가지의 서비스와의 통신이 필요하다. 주문 내역은 그 4가지 서비스와 비교적 강한 결합을 띄고 있는 것이다.
- 이벤트를 통한 처리이기때문에 하나의 모델로써 관리하는 것처럼 즉각적으로 반영될 수 없겠지만, 어느 시점이 되면 결과적으로 일치하게 되고, 책에서는 결과적 일관성을 추구하는 것이라고 설명하고 있다.
- CQRS 방식을 통해, 쓰기 모델과 읽기 모델을 다음과 같이 두 가지 방법으로 설계할 수 있다.

이벤트 소싱 패턴이벤트 소싱 패턴은 CQRS 패턴의 연장선으로, 쓰기 최적화를 수행할 수 있는 방법으로, 데이터의 상태 트랜잭션 자체를 저장하는 전략이다.

event_id	entity_state	entity_type	data
100	장바구니 생성됨	장바구니	{….}
101	품목 1 추가됨	품목	{….}
102	품목 2 추가됨	품목	{….}
103	품목 1 삭제됨	품목	{….}

이벤트 저장소를 따로 생성하여, 이벤트가 발생하면 해당 저장소로 이벤트 row 를 생성한다.이 전략으로 얻을 수 있는 이점

메세지 브로커와 데이터베이스를 분리하지 않고 하나로 사용할 수 있다.
메세지를 보내는 등.. 부가적인 과정이 없어, 복잡성이 줄고 쓰기 속도가 향상된다.
상태를 저장하기 때문에 정확한 감사 로깅을 제공받을 수 있다.
객체의 예전 상태를 파악하고 재구성하는 것이 간단해진다.
외부 애플리케이션으로 이벤트를 전달하는 것도 간단해진다.

변경이 이루어져야하는 모든 서비스들은 이벤트 저장소를 바라보고 있다가, 자신에게 맞는 이벤트 row 가 생성됐을 경우 작업을 수행하는 구조이다.
설명하자면, 다음과 같이 해당 트랜잭션이 가지는 상태 자체를 저장한다는 말이다.
데이터는 원자성을 지켜야하는데, 이벤트 소싱 패턴을 통해 CQRS 패턴을 사용하면서도 원자성을 지킬 수 있다. (데이터베이스에 데이터를 저장하는 과정과 읽기 서비스로 메세지를 보내는 작업을 언제나 완전하게 진행하여 함께 실행되도록 하는 것이다.)
프론트와 서버사이에도 마이크로서비스를 위한 패턴이 필요하다.

MSA 프로젝트 레퍼런스

https://www.dtoncloud.com/landing/board_customerCase_list.html?bltnNo=11569663449355

https://devocean.sk.com/blog/techBoardDetail.do?ID=163544

CQRS

silver_sun — Mon, 1 Apr 2024 19:57:46 +0900

CQRS (Command Query Responsibility Segregation)

흔히 CRUD (생성, 조회, 업데이트, 삭제) 라고 불리우는 기본적인 4가지 기능들을 상태 변경 명령(CUD), 조회 쿼리(R) 이 두 가지로 나누어 관리하는 방법이다. 명령 모델 (CUD) 와 조회 모델 (R) 을 각각 설계한다.

탄생 배경

기존의 CRUD 아키텍처는 데이터베이스에 쿼리를 하고 업데이트를 하는데에 동일한 Domain Model을 사용합니다. 예를들어 주문 시스템의 Domain Model 은 주문(order)입니다. 주문을 할때에는 배송정보도 필요하고, 상품정보도 필요하고, 추천상품 정보, 고객정보 등 다양한 정보들이 필요합니다. 최초 설계에는 주문만 처리하려고 만들었지만, 유지보수 및 신규 서비스가 생겨나면서 점점 초기 설계와는 다르게 변질이 되어갑니다. 이는 UX 가 발전하고, 사용자의 요구사항이 늘어나고, 비지니스가 복잡해 지는 상황에서는 생기게 되는 문제입니다.

이러한 상황들을 관찰해 보니, 비지니스 로직은 대부분 데이터 변경 (CUD) 에서 처리되고, 조회(Read) 은 단순 데이터 조회가 대부분이 되는것을 볼 수 있었습니다. 이것을 하나의 Domain Model 에서 처리하게 되니, 필요치 않은 외부 속성들과의 연계등의 복잡도가 증가하게 되는 원인을 발견 하였습니다.

이러한 문제를 해결하기 위하여 명령과 조회를 분리하는 방법을 고안하였고 이렇게 나온 방법이 CQRS 입니다. DDD(Domain-driven design) 에서 Object Model 방법론을 해결하기 위하여 CQRS 가 사용되었습니다.

- MSA School

설계 형태

쿼리 수준에서만 명령과 조회를 구분하나 데이터베이스는 동일하게 사용.
하나의 데이터베이스 안에서 테이블을 각각 설계.
서로 다른 데이터베이스로 설계.

장점

유연한 모델링
- 명령 모델(Command Model)과 쿼리 모델(Query Model)을 분리함으로써, 각각의 요구 사항에 맞게 모델링 및 로직을 최적화할 수 있다.
성능 최적화
- 명령과 쿼리에 대한 부하가 다를 경우, 각각에 대한 확장을 독립적으로 고려할 수 있습니다. 이를 통해 시스템의 성능을 최적화할 수 있다.
응답성 향상
- 비동기적으로 처리되는 명령 모델과 미리 계산된 결과를 사용하는 쿼리 모델을 통해 응답 속도를 향상시킬 수 있다.

단점

추가적인 복잡성
- 명령과 쿼리를 분리하면서 두 개의 모델을 유지해야 하므로 개발 및 유지보수에 대한 복잡성이 증가할 수 있다.
일관성 관리 어려움
- 명령과 쿼리 모델이 독립적으로 유지되기 때문에 데이터 일관성을 유지하기 위해 추가적인 노력이 필요할 수 있다.
학습 곡선
- CQRS는 전통적인 CRUD 기반의 아키텍처와 다른 접근 방식을 채택하므로, 팀 내의 학습 곡선이 존재할 수 있다.

참고자료.

https://github.com/microsoftarchive/cqrs-journey

https://www.msaschool.io/operation/integration/integration-six/

도메인 주도 설계로 시작하는 마이크로서비스개발 part 2-1.

silver_sun — Sun, 31 Mar 2024 04:15:34 +0900

2장 MSA의 이해

MSA에서 지켜져야할 특성에 맞게 MSA아키텍처를 효율적이고 올바르게 구성할 수 있는 방법들을 알아본다.

2.1 리액티브 선언: 현대 애플리케이션이 갖춰야 할 바람직한 속성들

리액티브 시스템에 대해서는 여기를 참고.

책에서는 리액티브 시스템에서는 아키텍처 유연성을 갖추는 것이 필수적인 요소라고 말하고 있고 메세지 기반으로 동작하는 방식이 아키텍처 유연성을 충족시켜준다고 한다.

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

어떻게 해야 아키텍처가 유연성을 지킬 수 있을까? 느슨한 결합의 아키텍처를 통해 아키텍처 유연성을 만족시킬 수 있다.

2.2 강 결합에서 느슨한 결합의 아키텍처로의 변화

예전에 만들어진 많은 아키텍처 구조에서, 아키텍처의 각 구성요소들이 강하게 결합되어 있는 것을 볼 수 있다.

강한 결합
- 아키텍처 구성요소에 변경사항이 생겼을 경우, 해당 부분 외에도 애플리케이션의 상당수를 변경하게 되는 결합.

강한 결합이 되어있을 경우, 변경사항에 대해 많은 것을 고려해야하고 그렇기에 많은 리스트를 얻는 작업이 발생하므로 쉬게 변경하거나 확장할 수 없다.
예전에는 아무래도 특정 솔루션을 기반으로 기술을 직접 구현하는 폐쇄적인 방식으로 작업을 했었기 때문에 강한 결합이 발생할 수 밖에 없었을 것이다.
하지만 현재에는 클라우드 환경이 발달하며, 다양한 제품들이 출시 되고, 그 제품들끼리의 호환성을 제공하는 경우가 많기 때문에 다양한 벤더의 제품, 오픈소스등을 이용하여 유연한 아키텍처를 구성하기 좋은 환경이 되었다.

⇒ 시대의 흐름에 따라 다양한 기술의 변화가 일어나기때문에, 아키텍처는 이러한 기술의 흐름을 지속적으로 체크하고 따라가야한다.

CNCF (Cloud Native Computing Foundation) 에서는 매분기마다 클라우드 기반의 애플리케이션을 구축하는 데 사용되는 지형도를 업데이트 해주고 있다고 한다. 해당 지형도를 보면 얼마나 많은 오픈소스들이 존재하는 지, 특징은 어떠한 지 한 눈에 확인할 수 있다.

CNCF 에서 제공하는 클라우드 지형도 : https://landscape.cncf.io/

CNCF Landscape

landscape.cncf.io

도메인 주도 설계로 시작하는 마이크로서비스개발 part 2-2 https://silvers-dev-note.tistory.com/48

도메인 주도 설계로 시작하는 마이크로서비스개발 part 1.

silver_sun — Fri, 29 Mar 2024 09:40:45 +0900

1장 아마존 비지니스 민첩성의 비밀

1.1. 성공한 인터넷 기업들과 비지니스 민첩성

성공한 기업들은 자신들의 “비지니스 민첩성”을 기업 성공의 가장 큰 요인으로 꼽는다.
비지니스 민첩성이란 어떤 것이고, 어떻게 실현할 수 있을까?

비지니스 민첩성

책에서 말하는 비지니스 민첩성은 “민첩성”이라는 단어 그대로, 빠르게 대응하는 것을 의미한다.
예시로, 아마존에서는 초 당 약 1.5번의 배포가 발생한다고 한다. 이 말은, 0.66초에 1번씩 비지니스 개선이 발생한다는 것이다. 아주 빠르게 문제점을 개선하고, 기능을 보완하고, 고객에게 휼륭한 서비스를 제공하게 되는 것이다.

비지니스 민첩성을 위해서는 중요한 3가지 요소가 있다고 말한다.

프로세스
- 점진 반복적인 개발 프로세스가 필요.
아키텍쳐
- 유연하고 자동화된 개발 환경이 필요.
조직문화
- 자율적인 업무 기능 팀과 개발 문화가 필요.

다음 3가지 요소를 충족시킬 수 있는 방법은 무엇일까?

클라우드 인프라
- 클라우드 인프라 환경이 발달하며 기업들에서는 이러한 민첩성을 보다 쉽게 이끌어낼 수 있게 되었다. 클라우드 환경이 아닌 물리적인 온프레미스 환경이라면 개발인원이 작업을 시작하기 전에 작업환경을 구성하는 것부터가 긴 시간을 소요하게 될 것이다. 이후 서비스 인프라를 구성하는 작업을 진행 할 때에도 처음부터 차근차근 쌓아올려야하기 때문에 그 또한 긴 시간이 필요할 것이다.
- 더 이상 물리적인 공간이 필요없을 뿐더러, 이미 클라우드 서비스를 제공하는 기업들에서 인프라 구성에 필요한 것들을 구현해놓았기 때문에 개발인원들은 각자의 환경에 맞는 설정 값만 세팅해주면 전보다 훨씬 간편하고 빠른 시간 내에 서버 인프라를 구성할 수 있다.
- 클라우드 서비스들에서는 이러한 과정을 생략할 수 있도록 도와준다.게다가 클라우드 서비스는 각각의 인프라 환경을 하나하나 쪼개어 각각의 서비스로 제공하기 때문에 필요한 것들만 골라서 이용할 수도 있다. → 비용 절감의 효과를 볼 수 있다!

효율적이고 유연하게 대응하는 서버.
- 서버를 유연하게 사용하자.
  - 대부분의 서비스들은 24시간 365일 트래픽이 일정하지 않다. 예를 들어, 이커머스 서비스라면 세일기간, 인기 브랜드 상품 출시, 인기 상품 재입고 등등 특정 상황이 벌어졌을 때 트래픽이 상승할 것이다.
    상승하는 트래픽에 서버가 다운되면 안되니, 상상할 수 있는 최고의 트래픽 상황에 맞게 서버를 세팅해야 할까?
    그건 최고의 방법이라고 할 수는 없다. 트래픽이 상승하지 않는 시간이 훨씬 길 것이고, 그렇다면 그 기간만큼의 유휴 리소스가 발생하게 된다. 그것은 즉, 비용을 낭비하게 된다는 것이다.
    비용을 낭비하지 않고, 유연하게 대응할 수 있는 Scale-up & Scale-out 을 사용하자.
- 효율적이고 유연하게 대응하는 서버.
  - 서버를 scale-up/out 을 할 경우 서버를 통째로 복제하고 확장하게 된다. 리소스를 마냥 키워놓는 것 보단 유연한 방법이 될 수 있겠지만, 이 보다 더 효율적이고 휼륭한 방법이 있다.
    서비스에서 발생하는 기능들을 공통된 부분끼리 묶어, 애플리케이션을 여러 덩어리로 분리하고, scale-up/out 을 각각의 덩어리마다 발생하도록 적용시키는 것이다.
  - 애플리케이션을 분리하지 않은 체로 서버를 스케일 업/아웃 할 경우

애플리케이션을 분리하지 않은 체로 서버를 스케일 업/아웃 할 경우

- - 애플리케이션을 분리하여 트래픽이 몰리는 노드만 스케일 업/아웃 할 경우

애플리케이션을 분리하여 트래픽이 몰리는 노드만 스케일 업/아웃 할 경우

훨씬 더 높은 효율성을 가지고 유연한 서버 대응을 할 수 있을 것이다.
이처럼 민첩성을 끌어올리기 위해서는 클라우드 환경을 도입하고, 클라우드 네이티브 애플리케이션을 구성하는 것이 좋다.

클라우드 네이티브 클라우드 인프라에 효과적으로 어울릴 수 있도록 독립적으로 분리되어 배포될 수 있는 조각으로 구성 된 애플리케이션.
애플리케이션을 조각으로 분리하지 않고 한 덩어리로 클라우드 환경에 올라가는 것은 “클라우드 프렌들리” 라고 한다. (피보탈Pivotal에서 붙인 이름들이라고 한다.)

거의 모든 서비스가 클라우드 환경을 사용하고 있는 요즘, 우리는 하나의 애플리케이션을 조각조각 분리하여 사용하는 클라우드 네이티브 한 구조를 가진 마이크로서비스를 따라 애플리케이션을 제작할 것이다.

1.2 마이크로서비스란 무엇인가?

하나의 단위로 개발되는 일체식 애플리케이션인 모노리스(monolith)와 달리 애플리케이션이 여러개의 조각으로 분리되어 각각 조각들이 별개의 인스턴스로 로딩되는 방식이다.

마이크로서비스 아키텍처 스타일은 하나의 애플리케이션을 작은 서비스 스위트로 개발하는 접근 방식으로, 각 서비스는 자체 프로세스에서 실행되며 경량 메커니즘으로 통신하고, 종종 HTTP 리소스 API를 사용합니다. 이러한 서비스는 비즈니스 기능을 중심으로 구축되며 완전 자동화된 배포 도구를 통해 독립적으로 배포될 수 있습니다. 이러한 서비스는 서로 다른 프로그래밍 언어로 작성되고 서로 다른 데이터 저장 기술을 사용할 수 있으며, 중앙 집중식 관리가 최소화됩니다. In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

- James Lewis and Martin Fowler (2014)

https://martinfowler.com/microservices/

마이크로서비스 기본 개념도

장점

모듈성과 유연성
- 각각의 마이크로서비스는 특정 기능이나 업무 영역을 담당하므로 모듈성이 높고 독립적으로 개발, 배포, 확장할 수 있습니다. 이는 애플리케이션을 더 유연하고 쉽게 확장할 수 있도록 돕습니다.
기술 다양성
- 각 마이크로서비스는 독립적으로 개발되므로 서로 다른 기술 스택을 사용할 수 있습니다. 이는 팀이 최적의 도구와 기술을 선택하여 특정 요구 사항에 가장 적합한 솔루션을 개발할 수 있도록 합니다.
빠른 개발 및 배포
- 작은 규모의 서비스로 분해되어 있기 때문에 개발 시간이 단축되고 더 빠른 배포가 가능합니다. 또한, 변경 사항이 하나의 서비스에 영향을 미치지 않도록 보장할 수 있어 더 빠른 이터레이션과 릴리스가 가능합니다.
확장성
- 마이크로서비스는 독립적으로 확장할 수 있으므로 특정 서비스에 대한 요구량이 높아지는 경우 해당 서비스만 확장하여 대응할 수 있다.
고가용성과 견고성
- 하나의 서비스가 실패해도 다른 서비스에 영향을 미치지 않고 시스템 전체가 계속 작동할 수 있다. 이는 고가용성과 시스템의 견고성을 향상시킬 수 있다.
변경 관리 용이성
- 마이크로서비스는 작고 단일 책임을 가지고 있기 때문에 변경을 관리하기 쉽다. 하나의 변경이 다른 서비스에 영향을 미치는 경우가 적어 전체 시스템을 변경하는 것보다 훨씬 안정적으로 변경을 수행할 수 있다.

단점

복잡성
- 여러 개의 작은 서비스로 분해되어 있기 때문에 전체 시스템의 복잡성이 증가한다. 서비스 간의 통신, 데이터 일관성 유지, 분산된 로깅 및 모니터링 등을 관리해야 한다.
테스트 및 디버깅의 어려움
- 서비스 간의 상호작용 및 의존성으로 인해 테스트 및 디버깅이 어려울 수 있습니다. 분산된 환경에서의 문제 해결은 더욱 어려울 수 있다.
네트워크 부하
- 마이크로서비스 아키텍처는 여러 서비스 간의 통신이 필요하므로 네트워크 부하가 증가할 수 있다. 특히, 마이크로서비스 간의 통신이 느릴 경우 전체 시스템의 성능에 영향을 미칠 수 있다.
데이터 관리의 어려움
- 서비스 간의 데이터 일관성을 유지하기 위한 데이터 관리가 어려울 수 있다. 데이터의 소유권 및 업데이트, 트랜잭션 경계 등을 관리해야 한다.
운영 복잡성
- 여러 개의 서비스를 운영하고 모니터링하는 것은 복잡할 수 있습니다. 서비스의 확장성, 가용성, 장애 복구 등을 관리하기 위한 운영 팀의 노력이 필요.
개발자의 추가적인 책임
- 각 서비스는 독립적으로 개발되고 운영되기 때문에 개발자는 서비스 간의 상호작용, 데이터 일관성 등을 고려해야 합니다. 이는 추가적인 책임과 학습 곡선을 의미할 수 있다.

1.3 마이크로서비스를 위한 조건은 무엇인가?

책에서는 다음 6가지가 필요하다고 말한다.

직업 분류가 아닌 업무 기능 중심의 팀
자율적인 분권 거버넌스, 폴리글랏을 이용한 관리.
프로젝트가 아닌 제품 중심의 개발 생명주기.
인프라 자동화 개발 환경
통합 저장소가 아닌 분권 데이터 관리
실패를 고려한 설계 (이슈에 대응 할 수 있는 설계)

한정헌님이 작성하신 서문 내용 중 공감이 가고 동의하는 내용이 많았다

2000년 인터넷 업계의 개발자로 시작한 첫 3년 동안은 내가 무엇인가를 창조하고 있다는 생각에 코딩이 마냥 즐겁기만 했고…중략 ... DB와 UI 중심의 설계에서 개발자의 창의력은 전혀 필요하지 않았고 컨베이어 벨트의 노동자처럼 던져준 테이블 명세와 화면 명세를 보고 그것을 이어주는 비슷비슷한 코드를 찍어내는 역할만 해야 했다. 납기 수준의 압박으로 대부분의 코드는 개선없이 기존 레거시 코드를 새로운 언어로 컨버전한 수준이었다.

- 도메인 주도 설계로 시작하는 마이크로서비스 개발

그 시점에 느낀 소프트웨어에 대한 내 생각은 좋은 소프트웨어란 빠른 비지니스 변화를 지원해야 하지만 그것을 위해 소프트웨어를 만드는 개발자도 힘든 야근이나 장시간 노동을 해서도 안 되며, 그러기 위해서는 복잡성을 제거하고 유연한 설계가 필요하다는 것이었다. 빠른 변경을 포용할 수 있는 쉽고 도메인 응집성이 있고 단순하면서 아름다운 설계. 그런 설계에서 비로소 개발자의 노력도 절감되고 긍지와 보람을 느낄 수 있을 것 이라 생각한다.

- 도메인 주도 설계로 시작하는 마이크로서비스 개발

Reactive System 리액티브 시스템

silver_sun — Tue, 20 Feb 2024 11:18:29 +0900

Reactive System 리액티브 시스템

reactive system ⇒ 반응형 시스템.

확장성이 뛰어나고 반응성이 빠른 시스템을 구축하는 데 중점을 둔 소프트웨어 아키텍처이다.

리액티브 시스템의 설계원칙은 리액티브 선언문에 잘 기록되어있다.

우리는 시스템 아키텍처에 대한 일관성 있는 접근이 필요하며, 필요한 모든 측면은 이미 개별적으로 인식되고 있다고 생각합니다. 즉, 응답이 잘 되고, 탄력적이며 유연하고 메시지 기반으로 동작하는 시스템 입니다. 우리는 이것을 리액티브 시스템(Reactive Systems)라고 부릅니다.
리액티브 시스템으로 구축된 시스템은 보다 유연하고, 느슨한 결합을 갖고, 확장성 이 있습니다. 이로 인해 개발이 더 쉬워지고 변경 사항을 적용하기 쉬워집니다. 이 시스템은 장애 에 대해 더 강한 내성을 지니며, 비록 장애가 발생 하더라도, 재난이 일어나기 보다는 간결한 방식으로 해결합니다. 리액티브 시스템은 높은 응답성을 가지며 사용자 에게 효과적인 상호적 피드백을 제공합니다.

- 리액티브 선언문 https://www.reactivemanifesto.org/ko*

용어집 - 리액티브 선언문

www.reactivemanifesto.org

리액티브 시스템의 4가지 주요 특징.

Responsive(응답성)
- 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공.
Resilient(탄력성)
- 장애가 발생하거나 부분적으로 고장 나더라도 시스템 전체가 고장 나지 않고 빠르게 복구하는 능력.
Elastic(유연성)
- 시스템의 사용량에 변화가 있더라도 균일한 응답성을 제공하는 것을 의미. 시스템 사용량에 비례해서 자원을 늘리거나 줄이는 능력.
Message Driven(메세지 구동)
- 비동기 메시지 전달을 통해 위치 투명성, 느슨한 결합, 논블로킹 통신을 지향하는 것을 의미.

리액티브 시스템에서는 비동기&논블로킹 방식을 채택하여 사용한다. 따라서 I/O 작업처럼 시간 비용이 크게 발생할 수 있는 작업에서 큰 이점을 얻을 수 있다.

메시지 기반의 방식이기 때문에 메시지 이벤트를 활용하여 다양한 외부 요소들과 결합하기 용이하다.

장단점

장점

반응성(Responsiveness)
- 리액티브 시스템은 빠른 응답 속도를 제공합니다. 비동기 및 논블로킹 방식으로 요청을 처리하고, 이벤트에 반응하여 즉각적으로 결과를 반환합니다. 이를 통해 사용자 경험을 향상시키고, 시스템의 신뢰성을 높일 수 있습니다.
확장성(Scalability)
- 리액티브 시스템은 수평 및 수직 확장이 용이합니다. 비동기 및 병렬 처리를 통해 많은 수의 요청을 동시에 처리할 수 있으며, 요청이 증가함에 따라 시스템을 쉽게 확장할 수 있습니다.
탄력성(Resilience)
- 리액티브 시스템은 장애에 대한 견고한 구조를 가지고 있습니다. 오류가 발생해도 시스템은 계속해서 동작하며, 자동으로 회복하거나 다른 경로를 통해 요청을 처리할 수 있습니다.
경제성(Efficiency)
- 리액티브 시스템은 리소스를 효율적으로 활용할 수 있습니다. 비동기 및 논블로킹 방식으로 작업을 처리하므로 리소스의 낭비를 최소화하고, 시스템의 성능을 최적화할 수 있습니다.
확장성(Scalability)
- 리액티브 시스템은 다양한 환경과 플랫폼에서 사용할 수 있습니다. 클라우드 환경에서는 가변적인 리소스를 활용하여 시스템을 유연하게 운영할 수 있고, 마이크로서비스 아키텍처에서는 각 서비스를 독립적으로 확장할 수 있습니다.
호환성(Compatibility)
- 리액티브 시스템은 기존 시스템과의 호환성을 유지하면서 새로운 기능을 추가할 수 있습니다. 기존 시스템을 점진적으로 리액티브 아키텍처로 변환하거나, 리액티브 기술을 기존 시스템에 통합할 수 있습니다.

단점

학습 곡선
- 리액티브 프로그래밍과 리액티브 시스템을 이해하고 구축하는 것과 비동기 프로그래밍과 함수형 프로그래밍의 개념을 이해하는 것에 대한 학습 비용이 상대적으로 크다.
디버깅의 어려움
- 리액티브 시스템은 비동기적이며 병렬적인 동작을 수행하기 때문에 디버깅이 어려울 수 있다.
오버헤드
- 논블로킹 및 비동기 작업을 지원하기 위해 추가적인 오버헤드가 발생할 수 있다. 이는 추가적인 코드 작성, 메모리 사용, CPU 리소스 등으로 나타날 수 있으며, 이로 인해 성능 저하의 가능성이 있다.
복잡성 증가
- 비동기적이고 병렬적인 동작을 수행하기 위해 작성된 코드들에서 복잡성이 증가 할 수 있다. 이로 인해 코드의 가독성과 유지보수성이 저하될 수 있다.
리소스 관리
- 리액티브 시스템은 많은 수의 동시 요청을 처리할 수 있지만, 이로 인해 리소스 관리가 어렵다. 특히 동시성 제어, 메모리 사용, 스레드 관리 등의 측면에서 고려해야 할 사항이 많다.

요약

리액티브 시스템 = 급변하는 상황에 빠르게 대응하고 적응할 수 있는 시스템이다.

높은 응답성을 가진다.
메세지 기반으로 동작한다.
탄력적이고 유연하다. = 장애나 변화에 빠르게 대응할 수 있다.
비동기&논블로킹&메세지 기반의 방식으로, 마이크로아키텍처와 결합하기 좋다.
상대적으로 러닝커브가 높기 때문에 장점만을 바라보고 리액티브 시스템을 적용하는 것은 오히려 위험할 수 있다.