[독서 기록] 도메인 주도 설계로 시작하는 마이크로서비스 개발, 1~2장

 

 

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

넷플릭스, 우버, 아마존, 쿠팡 등의 대규모 인터넷 서비스를 제공하는 회사들의 애플리케이션은 어떤 구조로 만들어졌을까? 가상화되고 유연하게 변경되는 클라우드 인프라에 최적화된 애플리케이션 형태는 무엇일까? 이러한 질문의 해답이 되는 애플리케이션 형태가 바로 마이크로서비스이며, 마이크로서비스는 클라우드 환경에서 가장 진화된 애플리케이션 형태다. 이 책은 마이크로서비스 개발에 입문하고자 하는 분들을 위해 전반적인 마이크로서비스 아키텍처의 개념과 주요 패턴들을 소개하고 마이크로서비스 개발 방법으로 가장 주목받는 도메인 주도 설계를 살펴본다. 특히 도메인 주도 설계의 업무 분석 및 설계 기법인 이벤트 스토밍을 통해 업무를 빠르게 분석하고 마이크로서비스를 도출 및 설계하는 방법을 소개한다. 이 책은 초심자도 쉽게 이해할 수 있게 마이크로서비스의 전반적인 개념을 설명한 후 실제 마이크로서비스 개발을 위한 아키텍처 정의, 마이크로서비스 도출, 도메인 모델 설계, 구현, 빌드 및 배포와 같은 마이크로서비스 개발 활동들을 단계별로 알아본다.

저자

한정헌, 유해식, 최은정, 이주영

출판

위키북스

출판일

2021.04.08

 

 

 

11.6초 아마존이 어플리케이션을 배포하는 주기 

- 2p 

 

 

빠른 배포 주기는 비즈니스의 민첩성을 간접적으로 보여주는 지표라고 할 수 있다.

- 3p 

 

클라우드는 여러 개의 서버 장비가 모여 논리적으로 하나처럼 관리된다. 즉, 레고처럼 조각 조각이 모여 하나의 큰 덩어리가 되고 쉽게 분리되기도 한다. 애플리케이션도 이러한 형태라면 효율성을 극대화할 수 있다. 특히 이러한 애플리케이션이 탑재되는 클라우드 인프라는 사용한 단위 만큼만 비용을 지불하므로 애플리케이션 블록이 작으면 작을수록 효율적이다.

- 5p 

 

스케일 업은 기존 시스템 자체의 물리적 용량을 증가시켜 성능을 높이는 방법이다. 

스케일 아웃은 기존 시스템광 용량이 같은 다수의 장비를 병행 추가해서 가용성을 높이는 방법이다. 즉, 사용량을 분산시켜 전체적인 장애 없이 운영되게 한다.

- 6p 

 

 

쇼핑몰 시나리오 ->

시스템 운영자는 타임세일 기간에 밀려올 트래픽에 대비하려고 쇼핑몰 시스템의 용량을 증설하려 한다. 

 

- 첫 번째 단계는 스케일 업 작업이다. 전체 시스템의 트래픽 최대치를 계산해서 대용량 처리가 가능하도록 시스템 용량을 증설하는 것이다. 그럼에도 예상 트래픽을 초과해 시스템이 다운될 수 있다.

- 두 번째 단계는 확장 탄력성을 보장하는 스케일 아웃을 설정하는 것이다. 이 경우 CPU나 메모리의 트래픽 양이 한계 수치에 도달하면 시스템의 인스턴스를 설정된 개수로 복제해서 증가시킨다. 즉, CPU 사용량이 70% 이상으로 증가하면 1개였던 인스턴스가 2개로 늘어난다. 그럼 사용량이 2대의 인스턴스로 적절히 분산된다.

- 6p 

 

 

그런데 이 모든 서비스의 시스템 용량을 증설하고 사용량이 몰리면 이 모든 것을 복제할 필요가 있을까? 당연히 낭비다. 세일 이벤트를 담당하는 조각만 용량이 증설되고 사용량에 따라 복제되어 트래픽에 대비하면 된다. 

 

그럼 어떻게 해야 할까? 앞에서 언급했다시피 전체가 한 덩어리로 묶여 있는 애플리케이션을 레고 블록처럼 분리하면 된다.

- 7p 

 

- 첫 번째 단계에서 운영자는 타임세일 서비스만 분리돼 있으므로 타임세일 서비스의 용량만 고려해서 증설한다. (스케일 업)

- 두 번째 단계에서는 독립된 타임세일 서비스의 사용량을 고려해서 트래픽이 증가하면 타임세일 서비스 인스턴스만 복제되도록 설정한다. (스케일 아웃) 

 

-7p 

 

 

클라우드 플랫폼 중 하나인 클라우드 파운드리를 서비스하는 피보탈에서는 이처럼 큰 덩어이로 클라우드 환경에 올라갈 수 있게만 한 애플리케이션을 클라우드 친화 애플리케이션이라 하고, 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션을 클라우드 인프라에 가장 어울리고 효과적이라는 의미로 클라우드 네이티브 애플리케이션이라 부른다. 그리고 궁극적으로 '클라우드 프렌들리'에서 '클라우드 네이티브'로 전이해야 한다고 말한다.

- 7p 

 

 

 

특정 서비스를 구축하는 데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 가리켜 '폴리글랏(Polyglot)하다'라고 표현한다. 클라우드 등의 가상 인프라가 지닌 유연성이 이를 가능하도록 지원한다.

 

여기서 이러한 폴리글랏 저장소 같은 특성을 통해 CBD/SOA가 추구했지만 미흡했던 모듈화를 비로소 실현할 수 있었던 MSA와 CBD/SOA와의 차이를 발견할 수 있다. CBD/SOA의 접근법에서는 애플리케이션은 모듈별로 분리했으나 데이터 저장소까지는 분리하지 못했다. 따라서 데이터의 강한 결합으로 애플리케이션도 독립적으로 사용하기가 힘들었다. 그러나 MSA에서는 SOA에는 없었던 다음의 두가지 개념으로 모듈화 방식을 강화했꼬 이를 진정으로 실현한다.

 

1. 서비스별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화한다. 즉, 다른 서비스의 저장소에 접근하는 수단은 API 밖에 없다. 

 

2. REST API 같은 가벼운 개방형 표준을 사용해 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용할 수 있다. 

 

- 11-12p 

 

 

아마존에서는 이런 팀을 'two pizza team'이라고 표현하는데, 이는 피자 두 판으로 서로 빈번히 의사소통하며 함께 식사할 수 있는 정도의 팀원 수를 의미하며, 한 팀에 다양한 역할을 수행하는 사람들이 모여 있으며 개발과 운영을 동시에 수행하는 팀이다.

- 13p 

 

"you build it, you run it"

- 14p

 

개발 생명주기의 변화: 프로젝트가 아니라 제품 중심으로 

- 15p

 

 

 

빌드/배포 파이프라인은 일반적으로 '소스코드 빌드' -> '개발 환경 배포' -> '스테이징 환경 배포' -> '운영 환경 배포'로 구성된다.

- 17p 

 

 

 

1. 주문 서비스가 주문 처리 트랜잭션을 수행한다.

 a. 동시에 주문 이벤트를 발행한다.

 b. 주문 이벤트가 메시지 큐로 전송된다.

 c. 배송 서비스가 주문 이벤트를 인식한다.

2. 배송 서비스가 주문 처리에 맞는 배송 처리 트랜잭션을 수행한다. (비즈니스 일관성 만족)

3. 배송 처리 트랜잭션 중 오류로 트랜잭션을 실패한다.

 a. 배송 처리 실패 이벤트를 발행한다.

 b. 배송 처리 실패 이벤트가 메시지 큐로 전송된다. 

 c. 주문 서비스가 배송 처리 실패 이벤트를 인식한다.

4. 주문 서비스는 주문 취소(보상 트랜잭션)를 수행한다. (비즈니스 일관성 만족) 

 

- 19p 

 

 

 

리액티브 선언의 4가지 요소 

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

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

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

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

- 25p 

 

 

 

MSA 구성 요소 및 패턴의 유형

- 인프라 구성 요소: 마이크로 서비스를 지탱하는 하부구조 인프라를 구축하는데 필요한 구성요소 

- 플랫폼 패턴: 인프라 위에서 마이크로서비스의 운영과 관리를 지원하는 플랫폼 차원의 패턴

- 애플리케이션 패턴: 마이크로서비스 애플리케이션을 구성하는 데 필요한 패턴 

- 30p 

 

 

 

가상머신과 컨테이너 환경의 차이 

차이점은 게스트 OS의 유무로 볼 수 있는데, 게스트 OS를 사용하는 가상 머신에서는 운영체제 패치 설치나 관련 라이브러리 설치 같은 오버헤드가 지속적으로 발생한다. 따라서 마이크로서비스 같은 작은 서비스를 패키지하고 배포하기에는 컨테이너 환경이 더 적합하다. 가장 대표적인 컨테이너 기술로는 필요 라이브러리나 실행 파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 도커(Docker)가 유명하고 가장 많이 사용된다.

- 32p 

 

 

 

컨테이너가 많아지면 그에 따라 컨테이너의 자동 매치 및 복제, 장애 복구, 확장 및 축소, 컨테이너 간 통신, 로드 밸런싱 등의 컨테이너 관리를 위한 기능이 필요해진다. 이러한 기술을 컨테이너 오케이스트레이션이라 한다. 

- 33p 

 

 

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

- IaaS(Infrastructure as a Service): 가상 머신, 스토리지, 네트워크 같은 인프라를 필요한 만큼 적시에 제공하는 서비스로서 사용자는 이러한 인프라를 이용해 개발 환경을 구성한 후 애플리케이션을 배포한다. 가상 서버, 가상 네트워크, 가상 스토리지라 생각하면 이해하기 쉽다.

예) AWS EC2, GCP Compute Engine, Azure VM

 

- CaaS(Container as a Service): 컨테이너 기반 가상화를 사용해 컨테이너를 업로드, 구성, 실행, 확장, 중지할 수 있는 서비스다. 애플리케이션을 바로 구동할 수 있는 환경을 제공한다는 점에서 PaaS와 유사하지만 다른 환경에도 이식 가능한 컨테이너 기반 가상화를 제공한다는 점이 다르다.

예) 마이크로소프트의 Azure Kubernetes Service(AKS), 아마존의 Elastic Kubernetes Service(EKS), Google Kubernetes Engine(GKE), AWS ECS 

 

- PaaS(Platform as a Service): 복잡함 없이 애플리케이션을 곧바로 개발, 실행 관리할 수 있는 플랫폼 환경을 서비스 형태로 제공한다. IaaS 위에 실제로 애플리케이션이 실행될 수 있는 미들웨어나 런타임까지 탑재된 환경이라 생각하면 이해하기 쉽다.

예) Azure Web App, Google App Engine, Cloud Foundry, Heroku, AWS Elastic Beanstalk 

 

- 35~36p 

 

 

 

수동 빌드/배포 과정에는 정말 많은 시간이 소요된다. 또한 마지막에 배포를 처리하는 배포 담당자는 보통 시스템 사용륭이 낮은 야간에 시스템을 장시간 멈추고 배포 작업을 진행하는 경우가 많다. 당연히 이러한 환경에서는 비즈니스 민첩성이 높을 수 없다. 따라서 이 같은 활동을 자동화할 필요가 생기는데, 특히 여러 개의 마이크로서비스를 배포해야 하는 환경에서는 배포가 잦을 수 밖에 없기 때문에 자동화가 절실하다.

 

자동화된 빌드나 배포 작업을 보통 CI/CD라고 하며, 여기서 CI는 지속적 통합(Continuous Integration)을 가리킨다. 

- 37p 

 

자동으로 통합하고 테스트하고 리포트로 남기는 활동 = CI

실행 환경에 자동으로 배포하는 것 = CD

- 38p 

 

 

빌드/배포 파이프라인은 통합 및 배포까지 이어지는 일련의 프로세스를 하나로 연계해서 자동화하고 시각화된 저랓로 구축하는 것을 말한다.

- 39p 

 

 

그림 2.14는 스프링 클라우드를 기반으로 한 아키텍처 구성이다. 앞에서 언급한 바와 같이 스프링 클라우드는 스프링 프레임워크를 개발하고 있는 피보탈에서 넷플릭스가 공개한 줄, 유레카, 히스트릭스, 리본 등의 넷플릭스 오픈소스를 스프링 부트 프레임워크 기반으로 사용하기 쉽게 통합한 것이다. 

 

 

 

- 43p 

 

 

1. 모든 마이크로서비스(스프링 클라우드 서비스를 포함한)는 인프라에 종속되지 않도록 데이터베이스, 파일 등에 저장된 환경 설정 정보를 형상관리 시스템에 연계된 'Config 서비스'에서 가져와 설정 정보를 주입한 후 클라우드 인프라의 개별 인스턴스로 로딩된다.

 

2. 로딩과 동시에 '서비스 레지스트리'에 자신의 서비스명과 클라우드 인프라부터 할당받은 물리 주소를 매핑해서 등록한다.

 

3. 클라이언트가 'API 게이트웨이'를 통해 마이크로서비스에 접근하고, 이때 API 게이트웨이는 적절한 라우팅 및 부하 관리를 위한 로드 밸런싱을 수행한다. 

 

4. 또한 API 게이트웨이에서 클라이언트가 마이크로서비스에 접근하기 위한 주소를 알기 위해 '서비스 레지스트리' 검색을 통해 서비스의 위치를 가져온다.

 

5. 동시에 API 게이트웨이는 클라이언트가 각 서비스에 접근할 수 있는 권한이 있는지 '권한 서비스'와 연계해 인증/인가 처리를 수행한다.

 

6. 이러한 모든 마이크로서비스 간의 호출 흐름은 '모니터링 서비스'와 '추적 서비스'에 의해 모니터링 되고 추적된다. 

 

- 44p 

 

 

각종 플랫폼 패턴 

 

 

프런트엔드 클라이언트가 여러 개의 백엔드 마이크로서비스를 어떻게 호출해야 할까? 또한 스케일 아웃을 통해 인스턴스가 여러 개로 복제됐다면 어떻게 부하를 적절히 분산할 수 있을까? 

 

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

-44p

 

 

여러 클라이언트가 여러 개의 서버 서비스를 각각 호출하게 된다면 매우 복잡한 호출 관계가 만들어질 것이다. 이러한 복잡성을 통제하기 위한 방법이 필요하다.

 

한가지 해결책은 API 게이트웨이다. ... 다양한 클라이언트가 다양한 서비스에 진입하기 위해서는 단일 진입점을 만들어 놓으면 여러모로 효율적이다.

- 46p 

 

 

BFF 패턴 : API 게이트웨이와 같은 진입점을 하나로 두지 않고 프런트엔드의 유형에 따라 각각 두는 패턴

외부 구성 저장소 패턴: 애플리케이션이 배포되는 환경이 매번 달라지기 때문에 코드에서 사용하는 환경 설정 정보는 코드와 완전히 분리되어 관리해야 한다는 원칙 

 

- 48 ~ 49p 

 

 

인증/인가 패턴

- 중앙 집중식 세션 관리

- 클라이언트 토큰

- API 게이트웨이를 사용한 클라이언트 토큰 

 

장애 및 실패 처리를 위한 서킷 브레이커 패턴 

 

모니터링과 추적 패턴 

 

중앙화된 로그 집계 패턴 

 

 

서비스 메시 패턴 

- 36 ~ 59p

 

 

애플리케이션 패턴 

 

- 모노리스식 프론트엔드 

- UI 컴포지트 패턴과 마이크로 프론트엔드 패턴 

 

마이크로서비스 통신 패턴

- 동기 통신 방식 

- 비동기 통신 방식 

 

비동기 방식의 이벤트 기반 아키텍처 : 이벤트를 생선하는 모듈과 이벤트에 대응하는 모듈을 분리하고 상호 독립적으로 동작하게 함으로써 병렬 처리 촉진 

 

저장소 분리 패턴

분산 트랜잭션 처리 패턴 

- 사가(Saga) 패턴 

 

데이터 일관성에 대한 생각의 전환: 결과적 일관성 

 

읽기와 쓰기 분리: CQRS 패턴 

 

쓰기 최적화: 이벤트 소싱 패턴 

 

 

59 ~ 80p