도메인 주도 설계로 시작하는 마이크로서비스 개발 #132
Description
1장. 아마존 비즈니스 민첩성의 비밀
- 스케일 업 (수직 확장): 시스템 자체의 물리적 용량을 증가시킨다.
- 스케일 아웃 (수평 확장): 다수의 장비를 병행 추가해서 가용성을 높인다.
- 모노리스: 하나의 단위로 개발되는 일체식 애플리케이션
- 마이크로서비스: 여러 서비스 인스턴스가 모여 하나의 비즈니스 애플리케이션을 구성.
- 각기 저장소가 다르므로 업무 단위로 모듈 경계가 명확하게 구분됨
- 폴리글랏 (Polyglot): 특정 서비스를 구축하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식
- 콘웨이 법칙 (Conway's law): 시스템의 모양이 팀의 의사소통 구조를 반영한다.
- 다기능 팀 (Cross-Functional Team): 업무 기능을 중심으로 기술이 다양한 사람들로 이루어진 하나의 팀
-아마존의 two pizza team - 2단계 커밋 (two-phase commit): 마이크로서비스에서는 사용하지 않음
- 결과적 일관성 (Eventual Consistency): 결국에는 두 데이터가 같아진다
- 내결함성 (Fault tolerance)
- 서킷 브레이커 패턴 (Circuit breaker pattern)
- 넷플릭스의 카오스 몽키 (Chaos monkey): 장애를 일부러 발생시키는 도구
2장. MSA의 이해
- 리액티브 선언문 (The Reactive Manifesto)
- 응답성 Responsive: 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공
- 탄력성 Resilient: 장애로 인해 시스템 전체가 고장나지 않고 빠르게 복구하는 능력
- 유연성 Elastic: 사용량에 변화가 있더라고 균일한 응답성을 제공하는 것
- 메시지 기반 Message Driven: 비동기 메시지 전달을 통해 위치 투명성, 느슨한 결합, 논블로킹 통신을 지향하는 것
- 클라우드 네이티브 컴퓨팅 재단 (CNCF)
- 클라우드 네이티브 지형도 (Cloud native landscape)
- https://landscape.cncf.io/
- MSA 외부 아키텍처 (outer architecture): 인프라, 플랫폼, 애플리케이션 영역에 있는 구성요소 및 관계를 정의
- MSA 내부 아키텍처 (inner architecture): 마이크로서비스가 제공하는 API, 비즈니스 로직, 이벤트 발행, 데이터 저장 처리 등을 어떻게 구조화해야 하는가에 관한 내용
- 마이크로 서비스 아키텍처 패턴
MSA 구성 요소 및 패턴
- 인프라 구성요소
- 플랫폼 패턴
- 애플리케이션 패턴
인프라 구성 요소
- Iaas (Infrastructure as a Service): 인프라를 가상으로 제공 (AWS EC2, GCP Compute Engine, Azure VM)
- CaaS( Container as a Service): 컨테이너를 업로드, 구성, 실행, 확장, 중지할 수 있는 서비스 (AKS, EKS, GKE, ECS)
- Paas (Platform as a Service): 인프라 위에 개발 환경까지 가상으로 제공 (Azure Web App, Google App Engine, Cloud Foundry, Heroku, AWS Elastic Beanstalk)
- SaaS (Software as a Service): 그 위에 애플리케이션까지 제공,
- VM vs Container
- Hypervisor vs Docker
- 컨테이너 오케스트레이션
- 컨테이너의 자동 배치 및 복제, 장애 복구, 확장 및 축소, 컨테이너 간 통신, 로드 밸런싱 등의 컨테이너 관리를 위한 기능
- Docker Swarm
- Apache Mesos
- Kubernetes
플랫폼 패턴
- DevOps: 개발과 운영을 병행할 수 있는 조직 또는 그 문화
- CI/CD
- Continuous Integration
- Continuous Delivery, Deployment
- 스프링 클라우드: 스프링 부트 + 넷플릭스 OSS
- 스프링 클라우드는 피보탈에서 넷플릭스가 공개한 줄, 유레카, 히스트릭스, 리본 등의 오픈소스를 스프링 부트 기반으로 사용하기 쉽게 통합한 것
- 서비스 디스커버리 패턴
- 라우팅: Zuul
- 로드밸런싱: Ribbon
- 서비스레지스트리: Eureka
- 쿠버네티스에서는 DNS, Service 로 제공
- API 게이트웨이 패턴
- Spring API Gateway Service 로 구현
- https://spring.io/projects/spring-cloud-gateway
- 쿠버네티스에서는 Service, Ingress Resources 로 제공
- Backend for Frontend 패턴
- 진입점을 프런트엔드의 유형에 따라 각각 두는 패턴
- 외부 구성 저장소 패턴
- Twelve Factor의 Config 원칙: 환경 설정 정보는 코드와 완전히 분리되어 관리해야 한다.
- Spring Cloud Config 로 구현
- https://spring.io/projects/spring-cloud-config
- 쿠버네티스에서는 ConfigMap 으로 제공
- 인증/인가 패턴
- 중앙 집중식: Redis, Memcached 를 사용한 세션 관리
- 클라이언트 토큰: JWT 사용
- 게이트웨이를 사용한 클라이언트 토큰
- 인증/인가를 처리하기 위한 별도의 인증 서비스 (auth service)를 사용
- 각 서비스는 인증/인가를 처리하지 않음
- 서킷 브레이커 패턴
- 장애가 발생한 서비스를 격리한다
- 폴백 메서드가 실행된다
- 모니터링과 추적 패턴
- 모니터링: Hystrix Dashboard
- 트레이싱: Zipkin
- 중앙화된 로그 집계 패턴
- Twelve Factor의 Logs 원칙: 로그를 이벤트 스트림으로 처리하라
- ELK 스택
- Elasticsearch: 분산형 검색, 분석
- Logstash: 데이터 처리 파이프라인
- Kibana: 시각화
- 서비스 메시 패턴
- 인프라 레이어로써 서비스 간의 통신을 처리
- 서비스 탐색, 서킷 브레이크, 추적, 로드 밸런싱 등의 패턴을 포함
- 대표적인 구현: 구글 이스티오 (Istio)
- 별도의 컨테이너로 배포되는 사이트카(Sidecar) 패턴을 적용
- 서비스 디스커버리, 라우팅, 로드 밸런싱, 로깅, 모니터링, 보안, 트레이싱 등의 기능 제공
- 컨트롤 플레인 기능에 의해 통제함
- 사이드카 구현체: 엔보이(Envoy)
- 마이크로서비스는 순수 비즈니스 로직에 집중
- 애플리케이션 패턴
- UI 컴포지트, 마이크로 프런트엔드 패턴
- 마이크로서비스 통신 패턴
- 동기
- 메시지 기반의 비동기
- RabbitMQ, Kafka, AWS SQS, AWS SNS, Azure Event Hub, Azure Event Grid,
- 저장소 분리 패턴
- 사가(Saga): 분산 트랜잭션 처리 패턴
- 로컬 트랜잭션과 보상 트랜잭션을 이용
- 롤백 대신 보상 트랜잭션 수행
- CQRS 패턴
- Command Query Responsibility Segregation
-명령 조회 책임 분리
- Command Query Responsibility Segregation
- 쓰기 최적화: 이벤트 소싱 패턴
- 상태 변경 이벤트를 계산해서 데이터 모델로 변경하지 않고, 바로 이벤트 저장소에 그대로 저장
- 저장소에서 변경과 삭제가 발생하지 않기 때문에 동시 업데이트 및 교착상태가 발생하지 않음
3장. 마이크로서비스 애플리케이션 아키텍처
- 관심사의 분리
- 기술과 비즈니스 로직을 분리했을 때 복잡성이 낮아지고 유지보수성도 높아진다.
- 데이터베이스 중심 아키텍처
- 정작 바쁜것은 데이터베이스이기 때문에, 애플리케이션을 아무리 스케일 아웃 해봐야 거둘 수 있는 효과가 미미하다
- 레이어드 아키텍처 (계층형 아키텍처)
- 티어: 물리적인 장비나 서버 컴퓨터 등의 물리층
- 레이어: 티어 내부의 논리적인 분할
- 의존성 역전 (DIP): 하위 계층의 변경으로부터 상위 계층을 보호함
- 헥사고날 아키텍처
- 클린 아키텍처
- 엔티티: 핵심 규칙과 데이터
- 유즈케이스: 시스템을 사용하는 처리 절차를 기술
- 세부사항: 유즈케이스를 감싸는 모든 것
- 트랜잭션 스크립트 패턴
- 비즈니스 행위를 수행하는 책임이 서비스에 있음
- 서비스에 중복되는 코드가 계속해서 생겨남
- 간단한 비즈니스를 처리할 때 적용
- 도메인 모델 패턴
- 도메인 객체가 데이터뿐만 아니라 비즈니스 행위를 갖는다.
- 데이터는 행위에 의해 은닉된다.
- 애그리거트 패턴
- 애그리거트 루트만 참조한다.
- 애그리거트 간의 참조는 객체 대신 키를 사용한다.
5장. 마이크로서비스 설계
- 설계의 결과물은 컨텍스트 맵
- 이벤트 스토밍을 통해서 시스템을 분석
- 컨텍스트 매핑
- 반드시 실시간 정합성이 필요한 경우가 아니라면 비동기 방식의 연계를 고려하는게 좋음
- DDD 전술적 설계
- 엔티티, 값 객체, 표준 타입, 애그리거트, 도메인 서비스, 도메인 이벤트
6장 이후
- 예제 코드 설명
- jHipster 를 사용한 프로젝트 생성 및 헥사고날 아키텍처에 맞게 튜닝하는 방법이 있음
- domain 영역의 구현에서 adapter 를 참조하는 코드가 있어서 외부를 참조하는 것 같아서 이상함
- 코드의 수준은 높은데 설명은 자세하지 않아서 별로임
서평
- 전체적인 큰 그림 잡는데는 도움이 됨
- 세부적인 사항은 다른 책을 봐야함
- 이벤트 스토밍 관련 내용은 참고할만함
- DDD, 클린 아키텍처, 헥사고날 아키텍처에 관한 선수 지식이 필요함