마이크로서비스패턴[7] — 7장
7장 마이크로서비스 쿼리 구현
1장 모놀리식 지옥에서 벗어나라
2장 분해 전략
3장 프로세스 간 통신
4장 트랜잭션 관리: 사가
5장 비즈니스 로직 설계
6장 비즈니스 로직 개발: 이벤트 소싱
7장 마이크로서비스 쿼리 구현
8장 외부 API 패턴
9장 마이크로서비스 테스트 1부
10장 마이크로서비스 테스트 2부
11장 프로덕션 레디 서비스 개발
12장 마이크로서비스 배포
13장 마이크로서비스로 리팩터링
FTGO 어플리케이션의 레거시 프로젝트는 하나의 DB만 존재했었기 때문에 비교적 DB접근이 단순했지만, 마이크로서비스 아키텍처에는 분산되어있는 DB를 조회하기가 상대적으로 까다롭다.
마이크로서비스 아키텍처에서는 API 조합 패턴과 CQRS 패턴으로 나누어 쿼리를 구현한다.
7. 마이크로서비스 쿼리 구현
7.1. API 조합 패턴 응용 쿼리
각 Provider Service별로 DB가 존재하기 때문에 API 조합기를 통해서 서비스별로 쿼리를 호출하고 조합하는 형태로 결과를 조합할 수 있다.
마이크로서비스 아키텍처에서 쉽고 간단하게 쿼리를 구현할 수 있지만, 위의 모델은 아래와 같은 단점이 존재한다.
- 오버헤드 증가
결국 DB 쿼리를 여러번 실행해야 하기 때문에 네트워크 리소스가 더 많이 소모되고 운영 비용도 늘어난다. - 가용성 저하 우려
- 데이터 일관성 결여
여러 DB를 대상으로 여러 쿼리를 실행하기 때문에 일관되지 않은 데이터가 반환될 수 있다.
API 조합 패턴은 많은 쿼리 기능을 쉽게 구현할 수 있는 수단으로 아주 유용하다. 반면 효율적으로 구현하기 어려운(많은 데이터를 인메모리 조인) 경우는 CQRS 패턴으로 구현하는 편이 낫다.
7.2. CQRS 패턴
CQRS 패턴이란 관심사에 대한 분리/구분에 관한 패턴이다.
CQRS 패턴 이전에 기존 API조합패턴에서 DB는 조회를 효율적으로 지원하지 않는 DB에 데이터들을 넣거나, 값비싸고 비효율적인 인메모리 조인을 하거나, 쿼리작업에 불필요한 서비스가 호출되는 등의 많은 어려움들이 있었다.
- 커맨드와 쿼리의 분리
조회기능은 쿼리쪽 모듈 및 데이터모델에, 생성/수정/삭제는 커맨드 쪽 모듈 및 데이터 모델에 구현하는 방식으로 패턴을 분리한다. 그리고 양쪽 데이터 모델 사이의 동기화는 커맨드 쪽에서 발행한 이벤트를 쿼리 쪽에서 구독하는 방식으로 이루어진다.
- CQRS와 쿼리 전용 서비스
쿼리 서비스에는 커맨드 작업이 전혀 없는 오직 쿼리 작업만으로 구성된 API가 있고, 하나 이상의 다른 서비스가 발행한 이벤트를 구독하여 항상 최신 상태로 유지되는 DB를 쿼리하는 로직이 구현되어 있다.
쿼리 쪽 서비스는 여러 서비스가 발행한 이벤트를 구독해서 구축된 뷰를 구현하기 좋은 방법이다. 이런 뷰는 특정 서비스에 종속되지 않기 때문에 stand alone 서비스로 구현하는 것이 올바른 선택이다.
CQRS는 RDBMS를 저장용으로 활용하면서 텍스트 검색 엔진(elastic search)을 이벤트를 기반으로 일반화 한 것이라고 볼 수 있다. 다만 CQRS는 검색 엔진 뿐만 아니라 훨씬 다양한 종류의 DB를 활용할 수 있다는 차이점이 있으며, CQRS 쿼리쪽 뷰는 이벤트를 구독해서 거의 실시간으로 업데이트된다.
CQRS 장점
- 마이크로서비스 아키텍처에서 쿼리를 효율적으로 구현할 수 있다.
- 다양한 쿼리를 효율적으로 구현할 수 있다.
- 이벤트 소싱 어플리케이션에서 쿼리가 가능하다.
- 관심사가 더 분리된다.CQRS 단점
- 아키텍처가 더 복잡하다.
- 복제 시차를 처리해야 한다.( -> native mobile이나 SPA로 시차해소 가능)
7.3. CQRS 뷰 설계
CQRS 뷰 모듈에는 하나 이상의 쿼리 작업으로 구성된 API가 존재한다.
뷰 모듈을 개발할때는 설계에 필요한 몇가지 설계 결정이 필요하다.
- DB 선정과 스키마 설계
- DB 접근 모듈을 설계할 때 멱등성/동시 업데이트 등 다양한 문제를 고려해야한다.
- 기존 어플리케이션의 스키마 변경시 뷰도 효율적으로 변경될 수 있는 수단을 강구해야 한다.
- 뷰 클라이언트에서 복제 시차를 어떻게 처리할지 결정해야 한다.
