마이크로서비스 패턴 7장

모놀리식 -> 마이크로서비스로 넘어가게 되면, DB를 분리하기 때문에 조인이 불가능하고, 관련하여 데이터를 모아서 서비스에 전달해야한다.

API 조합 패턴 응용 쿼리

API 조합 패턴은 데이터를 가진 서비스를 호출한 후 그 반환 결과를 조합.

쿼리 작업의 API 조합기 역할을 누가 맡을지 결정해야 함. 세 가지 옵션이 존재
1. 서비스 클라이언트를 API 조합기로 임명하는 것
2. 애플리케이션의 외부 API가 구현된 API 게이트웨이를 API 조합기로 만들기
3. API 조합기를 스탠드얼론 서비스로 구현하는 것

API 조합 패턴 응용 쿼리의 문제

API 조합 패턴 응용 쿼리는 매우 편리하나, 쿼리를 구현할 때 흔히 다음 세 가지 난관에 봉착하게 됩니다.

• API를 조합하여 여러 서비스에 흩어진 데이터를 조회하려면 값비싸고 비효율적인 인-메모리 조인을 해야 합니다.
> 데이터가 흩뿌려져 있는 경우, 모아서 조인을 해야하는 경우가 생김

• 데이터를 가진 서비스는 필요한 쿼리를 효율적으로 지원하지 않는 DB에, 또는 그런 형태로 데이터를 저장합니다. 
> 공간 인덱스를 제공해주지 않는 서비스에서, 공간 정보를 넣는 경우

• 관심사를 분리할 필요가 있다는 것은 데이터를 가진 서비스가 쿼리 작업을 구현할 장소로 적합하지 않다는 뜻입니다.

CQRS 개요

CQRS(커맨드 쿼리 책임 분리)는 이름처럼 관심사의 분리/구분에 관한 패턴입니다. 이 패턴에 따르면 영속적 데이터 모델과 그것을 사용하는 모듈을 커맨드와 쿼리, 두 편으로 가릅니다(그림 7-8). 조회(R) 기능(예: HTTP GET)은 쿼리 쪽 모듈 및 데이터 모델에, 생성/수정/삭제(CUD) 기능(예: HTTP POST, PUT, DELETE)은 커맨드 쪽 모듈 및 데이터 모델에 구현하는 것입니다. 양쪽 데이터 모델 사이의 동기화는 커맨드 쪽에서 발행한 이벤트를 쿼리 쪽에서 구독하는 식으로 이루어집니다.

CQRS는 RDBMS를 기록 시스템으로 활용하면서 텍스트 검색 엔진(예: 일래스틱서치)을 이용하여 텍스트 검색 쿼리를 처리하는 대중적인 접근 방식을 이벤트를 기반으로 일반화한 것.

CQRS의 장점

• 마이크로서비스 아키텍처에서 쿼리를 효율적으로 구현할 수 있습니다.
> 조인 필요 X

• 다양한 쿼리를 효율적으로 구현할 수 있습니다.
> 여러가지 뷰 생성 가능

• 이벤트 소싱 애플리케이션에서 쿼리가 가능합니다.
> CQRS는 이벤트 소싱의 중요한 한계(이벤트 저장소는 기본키 쿼리만 지원)를 극복.

• 관심사가 더 분리됩니다.
> 쿼리와 커맨드를 분리함으로써 관심사가 더 분리됨

CQRS의 단점

• 아키텍처가 더 복잡합니다.

• 복제 시차(replication lag)를 처리해야 합니다.
> 이벤트를 발행하는 시점과 쿼리 쪽이 이벤트를 받아 뷰를 업데이트하는 시점 사이에 지연이 발생.