마이크로서비스패턴[2] — 2장
2장 분해전략
1장 모놀리식 지옥에서 벗어나라
2장 분해 전략
3장 프로세스 간 통신
4장 트랜잭션 관리: 사가
5장 비즈니스 로직 설계
6장 비즈니스 로직 개발: 이벤트 소싱
7장 마이크로서비스 쿼리 구현
8장 외부 API 패턴
9장 마이크로서비스 테스트 1부
10장 마이크로서비스 테스트 2부
11장 프로덕션 레디 서비스 개발
12장 마이크로서비스 배포
13장 마이크로서비스로 리팩터링
(너무 늦게 올림…)
2. 분해전략
MSA를 말하기 이전에 소프트웨어 아키텍처를 먼저 생각하고 이해해야한다.
컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 엘리먼트와 그들 간의 관계, 그리고 이 둘의 속성으로 구성된 시스템을 추론하는 데 필요한 구조의 집합이다. — Documenting Software Architectures(Len Bass)
위 문장에서 추론할 분해전략의 핵심은 엘리먼트의 분해와 파트간의 연관관계를 어떻게 잘 풀어낼 것인지가 중요하다는것을 알 수 있다.
2.2.1. 아키텍처 스타일
MSA를 구성하는 어플리케이션의 아키텍쳐 스타일은 여러가지가 있지만 그중 예전방식의 Layered architecture와 책에서 구현하고자 하는 Hexagonal architecture에 대한 내용을 보자.
- 계층화 아키텍처 스타일(Layered architecture)
전형적인 아키텍처 스타일로 Presentation Layer/Business Logic Layer/ Persistence Layer의 3계층으로 구성되어 있으며, 어플리케이션 개발시 자주 사용된다.
- Presentation Layer: 사용자 인터페이스 또는 외부 API가 구현된 계층
- Business Logic Layer: 비즈니스 로직 계층
- Persistence Layer: DB 상호 작용 로직이 구현된 계층하지만 몇가지 단점이 존재하는데,
- 표현 계층이 하나뿐이다.
> 호출하는 시스템이 많을 경우 고민 - 영속화 계층이 하나뿐이다.
> DB가 여러개일 경우 고민 - 비즈니스 로직 계층을 영속화 계층에 의존하는 형태로 정의한다.
> DB 디펜던시에 의존하기때문에 DB가 없는 테스트가 어려움.
- Hexagonal(육각형) 아키텍처 스타일(Hexagonal architecture)
기존 Layered architecture의 표현 계층 대신 비즈니스 로직을 호출하여 외부의 요청을 처리하는 Inbound adapter와 외부 어플리케이션을 호출하는 Outbound adapter를 둠으로써 비즈니스로직이 어댑터에 의존하지 않는다는 것이 위 Hexagonal architecture의 가장 중요한 특장점이다.
이렇게 분리를 함으로써 비즈니스 로직만 테스트하기 유용해지고, Inbound adapter와 Outbound adapter로 시스템간의 교류를 통제함으로써 각각의 역할과 책임이 분리된다고 이해할 수 있다. 이런 Hexagonal architecture은 MSA를 이루는 각 서비스들의 아키텍처를 기술하는 가장 좋은 방법이라고 한다.
책에서 설명하는 모놀리식형태의 FTGO 어플리케이션을 MSA로 재구성할 경우 위 그림과 같이 DDD(Domain-driven design)에 대응하여 서비스가 분리된다는 것을 확인할 수 있다. 서비스가 분리되더라도 각자의 서비스들은 제공하거나 제공받는 REST API를 통해서만 접근할 수 있다는 점도 모듈성이 보장된다는 점을 알 수 있다.
2.2. MSA를 위한 어플리케이션 아키텍처의 정의
개발에 들어가기 이전에 설계하는 단계는 매우 중요하다. 어플리케이션을 잘게 나누고 시작하는것이 아닌, 어플리케이션에 접근하는 관점을 점차 확장시켜나가는 것이 마이크로서비스 아키텍처를 정의하는 과정이다.
1단계. 시스템 작업 식별
첫번째는 시스템 작업을 기술하기 위해 필요한 ‘합의된 어휘’를 제공하는 핵심 클래스로 구성된 도메인 모델을 생성하는것이다.
‘합의된 어휘’란 이해관계자들이 공유할 수 있는 용어라고 생각하면 이해하기 쉽다.
그리고 정리된 용어와 기능들로 클래스를 도출하고, 도출된 클래스들로 도메인 모델을 만들 수 있다.
도메인 모델을 도출한 다음 각 클래스들의 역할을 정의해봄으로써 전체적으로 어플리케이션이 무슨 일을 하는지 알 수 있게 되기 때문에 아키텍처를 정의하는데 유용하다.
2단계. 서비스 정의
서비스들을 분해하는 방법은 비즈니스에 따라 나누는 방법과 하위 도메인 패턴별로 분해하는 방법이 있다. 그중 책에서는 하위도메인 패턴별 분해 기법을 사용하는데 DDD에 있는 하위도메인 개념과 bounded context 개념을 사용해서 서비스를 분해하는 방식을 설명한다.
하위도메인이라는 개념을 통해 공용으로 사용되는 클래스들을 제거하여 분해하기 수월하게 하고, 결국 서비스들을 쉽게 분해할 수 있게 된다.
서비스를 분해하는 과정에서 아래의 장애물들이 걸림돌이 된다.
은총알은 없지만 서비스를 분해하는 과정에서 오는 장점도 있다는 점을 인지하며 알아두자.
- 네트워크 지연
- 동기 통신으로 인한 가용성 저하
- 여러 서비스에 걸쳐 데이터 일관성 유지
- 데이터의 일관된 뷰 확보
- 분해를 저해하는 만능 클래스
