TIL

7장 마이크로서비스 쿼리 구현

• 여러 DB에 분산된 데이터를 조회하는 쿼리 작업은 구현하기 어렵다.
• 마이크로서비스 아키텍처에서 다음 두 가지 패턴으로 쿼리를 구현한다.
  • API 조합 패턴: 서비스 클라이언트가 데이터를 가진 여러 서비스를 직접 호출하여 그 결과를 조합
    • 가장 단순한 방법으로 가급적으로 이 방법이 좋음
  • CQRS 패턴: 쿼리만 지원하는 하나 이상의 뷰 전용 DB를 유지하는 패턴
    • API 조합 패턴보다 강력한 만큼 구현이 복잡

7.1 API 조합 패턴 응용 쿼리

7.1.1 findOrder() 쿼리

• findOrder()
  • 기본키로 주문 정보를 조회하는 메서드
  • 주문/지불 정보, 배달 정보 등이 포함
• 마이크로서비스 아키텍처이기에 여러 서비스에 데이터가 뿔뿔이 흩어져 있다.
  • 주문 서비스: 주문 기본 정보 (주문 내역, 주문 상태 등)
  • 주방 서비스: 음식점 관점의 주문 상태, 픽업 준비까지 예상 소요 시간
  • 배달 서비스: 주문 배달 상태, 배달 예상 정보, 현재 배달원 위치
  • 회계 서비스: 주문 지불 상태

7.1.2 API 조합 패턴 개요

• API 조합 패턴이 각 서비스를 호출 후 결과를 조합하는 과정에는 두 종류의 참여자가 개입한다.
  • API 조합기: 프로바이더 서비스를 쿼리하여 데이터를 조회한다.
    • API 조합기는 클라이언트, API 게이트웨이 또는 프런트엔드를 위한 백엔드 패턴의 변형일 수도 있다.
  • 프로바이더 서비스: 최종 결과로 반환할 데이터 일부를 갖고 잇는 서비스

7.1.3 API를 조합 패턴으로 findOrder() 쿼리 구현

• findOrder()는 단순히 기본키로 EQUI 조인 작업
• 주문 검색 조합기는 총 4개 서비스를 호출한 결과를 조합한다.
  • 주문 서비스: GET /orders/{orderId}
  • 주방 서비스: GET /tickets?orderId={orderId}
  • 배달 서비스: GET /deliveries?orderId={orderId}
  • 회계 서비스: GET /charges?orderId={orderId}
• 주문 서비스는 기본키로 Order를 조회하고, 다른 서비스는 orderId를 외래키로 자신의 애그리거트를 조회하는 것

7.1.4 API 조합 설계 이슈

• 어느 컴포넌트를 쿼리 작업 API 조합기로 선정할 것인가
• 어떻게 해야 효율적으로 취합 로직을 작성할 것인가

누가 API 조합기 역할을 맡을 것인가?

• 서비스 클라이언트(웹 애플리케이션)
  • 주문 상태 뷰를 구현한 웹 애플리케이션
  • 이 같은 클라이언트가 같은 LAN에서 실행 중이면 효과적으로 조회가 가능
  • 하지만 클라이언트가 방화벽 외부에 있고 네트워크가 느리다면 실용적이지 못하다.
• 애플리케이션의 외부 API가 구현된 API 게이트웨이
  • 쿼리 작업이 애플리케이션 외부 API 중 일부라면 이 방법이 타당
  • 방화벽 외부에서 접근하는 클라이언트(모바일 앱) 등가 API 한 번 호출로 조회 가능하기에 효율적
• 스탠드얼론 서비스
  • ex) 주문 검색 서비스
  • 내부적으로 여러 서비스가 사용하는 작업인 경우
  • 취합 로직이 너무 복잡해 게이트웨이의 일부로 만들기 곤란한 경우
  • 외부에서 접근 가능한 작업을 구현할 경우

API 조합기는 리액티브 프로그래밍 모델을 사용해야 한다

• 쿼리 작업의 반응 시간을 최대한 줄이려면 API 조합기가 프로바이더 서비스를 병렬 호출해야 한다.
• 하지만 어떤 프로바이더 서비스를 호출하기 위해 다른 서비스의 결과를 먼저 가져와야 하는 경우엔 일부는 순차 호출해야 한다.
• 순차/병렬 서비스 호출이 뒤섞인 로직은 복잡해질 수 있다.
• 성능/확장성 우수한 API 조합기를 작성하기 위해선 리액티브 설계 기법을 동원해야 한다.
  • 자바의 CompletableFuture, RxJava의 옵저버블 등

7.1.5 API 조합 패턴의 장단점

• 오버헤드 증가
  • 여러 서비스 호출, 여러 DB 쿼리는 오버헤드가 불가피
  • 컴퓨팅/네트워크 리소스가 많이 소모되고 운영 비용도 증가
• 가용성 저하 우려
  • 가용성은 더 많은 서비스가 개입할수록 감소한다.
  • 프로바이더 서비스 불능인 경우 가용성 증가 전략
    • 이전에 캐시한 데이터를 반환
    • 미완성된 데이터를 반환
• 데이터 일관성 결여
  • 여러 DB를 대상으로 쿼리를 실행하기에 일관되지 않은 데이터가 반환될 수 있다.
  • ex) 주문 상태가 CANCELLED이지만 주문의 티켓은 아직 취소되지 않았을 수도 있다.

7.2 CQRS 패턴

• 엔터프라이즈 애플리케이션 대부분은
  • RDBMS에 트랜잭션을 걸어 레코드를 관리
  • 검색 쿼리는 일래스틱서치나 솔라 등 검색 DB를 이용
• 커맨드 쿼리 책임 분리
  • 여러 서비스의 데이터를 가져오는 쿼리는 이벤트를 이용해 해당 서비스의 데이터를 복제한 읽기 전용 뷰를 유지한다.

7.2.1 CQRS의 필요성

• API 조합 패턴만으로는 다중 서비스의 데이터 쿼리를 효율적으로 구현하기 어렵다.

findOrderHistory() 쿼리 구현

• findOrderHistory()는 다음 매개변수를 통해 주문 이력을 조회한다.
  • consumerId
  • OrderHistoryFilter (시간, 상태, 음식점 및 메뉴 항목을 검색할 키워드 등)
• 모든 서비스가 필터/정렬 용도의 속성을 보관하는 것이 아니기에 API 조합기로 구현하기 까다롭다.
  • ex) 메뉴 항목을 저장하는 서비스는 주문, 주방 서비스 뿐이고 배달, 회계 서비스에선 메뉴 정보가 없기에 키워드로 필터링할 수 없다.
• API 조합기로 키워드 문제 해결하기
  • 배달, 회계 서비스의 모든 데이터를 가져온 후 주문, 주방 서비스 데이터와 인메모리에서 조인
  • 주문, 주방 서비스의 데이터를 조회하고 주문 ID를 통해 다른 서비스의 데이터를 요청
  • API 조합기로 해결하는 방법은 효율성이 많이 떨어진다.

어려운 단일 서비스 쿼리: findAvaliableRestaurants()

• 한 서비스의 쿼리도 구현하기 어려울 때가 있다.
  • 데이터를 가진 서비스에 쿼리를 구현하는 것이 부적절한 경우
  • DB 또는 데이터 모델이 효율적인 쿼리를 지원하지 않는 경우
• findAvailableRestaurants()
  • 주어진 시점, 위치로 배달 가능한 음식점을 검색하는 기능
  • 어려운 부분이 효율적으로 지리 공간 쿼리를 수행하는 작업이고 이는 DB 능력에 구현이 좌우된다.
  • MongoDB, Postgres, MySQL처럼 지리 공간 데이터를 지원하는 인덱스나 쿼리가 존재한다면 쉽다.
  • 하지만 DB가 지리 공간 기능을 지원하지 않는다면 그런 기능을 지원하는 DB 레플리카를 유지해야 한다.

관심사를 분리할 필요성

• 데이터를 가진 서비스에 쿼리를 구현하면 안 될 때도 있다.
  • 어떤 서비스에 쿼리할 데이터의 소유권이 있다고 쿼리를 구현해야한다는 보장은 없다.
• 한 서비스에 너무 많은 책임을 부여하지 않도록 고민해야 한다.
  • 가령 음식점 서비스 개발 팀의 주 임무는 음식점을 잘 관리하는 것이지 성능 좋은 대용량 쿼리를 구현하는 일은 아닐 것이다.

7.2.2 CQRS 개요

• MSA에서 쿼리를 구현할 때의 세 가지 난관
  • 여러 서비스의 데이터를 API 조합을 이용해 쿼리하면 비효율적인 인-메모리 조인이 필요
  • 데이터를 가진 서비스는 효율적인 쿼리를 지원하지 않는 DB에 데이터를 저장
  • 데이터를 가진 서비스가 쿼리 작업을 구현할 장소로 적합하지 않아 관심사 분리가 필요

CQRS는 커맨드와 쿼리를 서로 분리한다.

• CQRS (커맨드 쿼리 책임 분리)
  • 조회(HTTP GET)는 쿼리
  • 생성/수정/삭제(HTTP POST, PUT, DELETE)는 커맨드
  • 양쪽 데이터 모델 사이 동기화는 커맨드가 발행한 이벤트를 쿼리에서 구독하는 식으로 이루어진다.
• 비 CQRS에서는 CRUD 작업을 DB에 매핑된 도메인 모델로 구현한다.
  • 하나의 영속적 데이터 모델은 커맨드, 쿼리를 모두 지원
• CQRS 커맨드 도메인 모델은 CRUD 작업을 처리하고 자체 DB에 매핑한다.
  • 데이터가 바뀔 때마다 도메인 이벤트를 발행한다.
• CQRS 쿼리 모델은 다소 복잡한 쿼리를 처리하며 자체 DB를 가진다.
  • 도메인 이벤트를 구독하고 DB를 수정하는 핸들러가 있다.

CQRS와 쿼리 전용 서비스

• 쿼리 서비스
  • 커맨드 작업이 없는 오직 쿼리만으로 구성된 API가 존재
  • 이벤트를 구독하여 DB를 항상 최신으로 유지하는 로직 존재
  • 특정 서비스에 종속되지 않기에 스탠드얼론 서빗스로 구현하는 것이 좋다.
• CQRS는 RDBMS를 기록 시스템으로 활용하며너 텍스트 검색 엔진을 이용해 쿼리를 처리하는 방식을 이벤트 기반으로 일반화한 것

7.2.3 CQRS의 장점

• MSA에서 쿼리를 효율적으로 구현 가능
  • API 조합 패턴의 비효율적 쿼리를 효율적으로 구현할 수 있다.
• 다양한 쿼리를 효율적으로 구현 가능
  • 각 쿼리가 효율적으로 구현된 하나 이상의 뷰를 정의해 단일 데이터 저장소의 한계를 극복할 수 있다.
• 이벤트 소싱 애플리케이션에서 쿼리가 가능
  • 쿼리 서비스는 이벤트 스트림을 구독해 항상 최신 상태를 유지한다.
• 관심사가 더 분리된다.
  • 커맨드/쿼리 양쪽 모두 관리하기 간편해진다.

7.2.4 CQRS의 단점

• 아키테처가 더 복잡하다.
  • 별도의 데이터 저장소를 관리해야 하하기에 운영 복잡도 가중
• 복제 시차를 처리해야 한다.
  • 쿼리 쪽이 이벤트를 받아 뷰를 업데이트하면서 지연이 발생한다.
  • 이전 버전의 애그리거트를 쿼리하게 될 수도 있는 것

7.3 CQRS 뷰 설계

• CQRS 뷰 모듈 구성 요소
  • 하나 이상의 쿼리 API
  • 발행된 이벤트를 구독해 최신 상태로 DB를 유지하는 이벤트 핸들러
  • 뷰 DB에 접근하는 데이터 접근 모듈
  • 뷰 DB
• 뷰 모듈 개발 시 중요한 설계 결정
  • DB를 선정하고 스키마를 설계
  • 데이터 접근 모듈 설계 시 멱등/동시 업데이트 등을 고려
  • 기존 애플리케이션에서 새 뷰를 구현하거나 스키마를 변경할 경우 뷰를 효율적으로 (재)빌드할 수 있는 수단 강구
  • 뷰 클라이언트에서 복제 시차를 어떻게 처리할지 결정

7.3.1 뷰 DB 선택

SQL vs NoSQL

• NoSQL은 CQRS 뷰와 잘 맞다.
  • NoSQL은 트랜잭션이 제한적이고 범용적인 쿼리 능력은 없지만 유연성, 성능/확장성에선 RDB보다 뛰어나다.
  • CQRS 뷰는 단순 트랜잭션과 고정된 쿼리만 실행하기에 NoSQL 제약 사항에 영향을 받지 않는다.
• SQL DB가 CQRS 뷰 DB로 타당한 경우도 있다.
  • 최신 하드웨어의 RDBMS는 성능이 좋고 대부분 개발자는 SQL DB에 더 익숙하다.
  • SQL DB엔 비관계형 기능(지리 공간 데이터 형 등)을 추가 가능
• DB 종류마다 경계선이 흐려져 선택이 복잡하긴 하다.
  • MySQL은 JSON 타입을 지원
  • 하지만 JSON 포맷 문서 지원은 MongoDB의 강점 중 하나

업데이트 작업 지원

• 뷰 데이터 모델은 이벤트 핸들러가 실행할 업데이트 작업 역시 효율적으로 구현되어야 한다.
  • 대개 뷰 DB의 레코드를 기본키로 찾아 변경을 반영한다.
  • 외래키를 이용해 레코드를 수정/삭제해야 하는 경우도 있다.
• 기본키 외의 칼럼으로 변경 작업이 필요한 경우 DB 자료형에 따라 효율성을 생각해 봐야 한다.
  • RDBMS나 MongoDB의 경우 필요한 칼럼 인덱스를 생성하여 변경 작업을 효율화시킬 수 있다.
  • 비기본키 기반 업데이트가 쉽지 않은 NoSQL DB도 존재한다.
  • 기본키 기반 수정/삭제만 지원하는 DynamoDB의 경우 보조 인덱스를 쿼리해 수정/삭제할 항목의 기본키를 결정해야 한다.

7.3.2 데이터 접근 모듈 설계

• 이벤트 핸들러와 쿼리 API 모듈은 DB에 직접 접근하지 않는다.
  • 데이터 접근 객체(DAO) 및 헬퍼 클래스로 구성된 데이터 접근 모듈을 사용

동시성 처리

• 동일한 레코드에 대해 동시 업데이트를 하는 경우가 있다.
  • 뷰가 한 종류 애그리거트의 이벤트만 구독하면 동시성 이슈는 없다.
  • 순차적으로 처리되기 때문
  • 여러 애그리거트의 이벤트를 구독하면 동일한 레코드에 업데이트를 할 가능성이 있다.
• 동시성 해결을 위해 낙관적 잠금 또는 비관적 잠금을 적용해야 한다.
  • 레코드를 읽지 않고 업데이트하는 방법도 존재

멱등한 이벤트 핸들러

• 이벤트 핸들러는 같은 이벤트를 한 번 이상 받을 수도 있다.
• 멱등하게 설계하면 중복 이벤트를 처리해도 문제되지 않는다.
• 비멱등적 이벤트 핸들러는 이벤트 ID를 기억하고 중복 이벤트가 발생하면 솎아 내야 한다.
• 이벤트 핸들러는 반드시 이벤트 ID를 기록하고 데이터 저장소를 원자적으로 업데이트해야 한다.
  • SQL DB라면 한 트랜잭션으로 PRCESSED_EVENTS라는 별도 테이블에 이벤트 ID를 삽입할 수 있다.
  • NoSQL에선 자신이 업데이트 하는 레코드에 이벤트를 저장해야 한다.

클라이언트 애플리케이션이 최종 일관된 뷰를 사용할 수 있다

• CQRS를 적용하면 커맨드를 업데이트한 직후 뷰의 업데이트가 지연될 가능성이 있다.
  • 메시징 인프라의 지연은 불가피하기에 뷰는 최종 일관된다.
• 커맨드와 쿼리 모듈 API로 비일관성을 감지하게 할 수는 있다.
  • 커맨드 클라이언트에 이벤트 ID를 반환하고 클라이언트가 쿼리 모듈에 이벤트 ID를 전달해 처리 여부를 확인 가능

7.3.3 CQRS 뷰 추가 및 업데이트

• CQRS 뷰는 계속 추가/수정될 것이다.
  • 새 쿼리를 지원하기 위해 새 뷰를 추가
  • 스키마 변경 반영을 위해 뷰를 재생성

아카이빙된 이벤트를 이용하여 CQRS 뷰 구축

• 메시지 브로커는 메시지를 무기한 보관하지 않으므로 메시지 브로커를 읽기만 해서는 새 뷰를 구축할 수 없다.
  • AWS S3 같은 곳에 아카이빙된 더 오랜 이벤트도 필요
  • 아파치 스파크처럼 빅데이터 기술이 필요

CQRS 뷰를 단계적으로 구축

• 전체 이벤트 처리 시간/리소스가 점점 증가하는 것도 뷰 생성의 또 다른 문제
• 2단계 증분 알고리즘 적용 (two-step in cremental algorithm)
  • 1단계: 주기적으로 각 애그리거트 인스턴스의 스냅샷을 그 이전의 스냅샷과과 스냅샷 이후의 이벤트를 바탕으로 계산
  • 2단계: 계산된 스냅샷과 이후 발생 이벤트를 이용해 뷰 생성

7.4 CQRS 뷰 구현: AWS DynamoDB 응용

• AWS DynamoDB
  • 아마존 클라우드에서 사용 가능한 확장성이 우수한 NoSQL DB
  • 완전 관리형 DB이기에 테이블 처리 능력을 동적으로 가감 가능
  • 데이터 모델은 JSON 객체처럼 key-value 쌍
• findOrderHistory와 findOrder가 구현된 CQRS 뷰에는 다음의 모듈이 존재한다.
  • OrderHistoryEventHandler: 여러 서비스가 발행한 이벤트를 구독하며 OrderHistoryDAO를 호출
  • OrderHistoryQuery API 모듈: REST API 엔드포인트 구현
  • OrderHistoryDataAccess: DynamoDB 테이블 관련 헬퍼 클래스를 조회/수정하는 메서드가 정의된 OrderHistoryDAO를 포함
  • ftgo-order-history: 주문이 저장된 DynamoDB 테이블

7.4.1 OrderHistoryEventHandlers 모듈

• 이벤트를 소비해서 DynamoDB 테이블을 업데이트하는 이벤트 핸들러로 구성된 모듈

public class OrderHistoryEventHandlers {
    private OrderHistoryDao orderHistoryDao;
    // ...
    public void handleOrderCreated(DomainEventEnvelop<OrderCreated> dee) {
        orderHistoryDao.addOrder(makeOrder(dee.getAggregateId(), dee.getEvent()),
            makeSourceEvent(dee));
    }
    // ...
    public void handleDeliveryPickedUp(DomainEventEnvelop<DeliveryPickedIp> dee) {
        orderHistoryDao.notePickedUp(dee.getEvent().getOrderId(), 
            makeSourceEvent(dee));
    }
    // ...
}

• makeSourceEvent()는 애그리거트 타입과 ID, 그리고 이벤트 ID가 포함된 SourceEvent를 생성한다.
  • SourceEvent를 이용하여 멱등성을 보장한다.

7.2.4 DynamoDB 데이터 모델링 및 쿼리 설계

• ftgo-order-history 테이블의 설계
  • DynamoDB 저장 모델은 아이템과 인덱스로 구성된다.
  • RDBMS보다 유연하기에 Order 애그리거트를 ftgo-order-history의 아이템 하나로 저장할 수 있다.

orderId	consumerId	orderCreatedTime	status	lineItems
…	xyz-abc	229392823232	CREATED	[{…}, {…}, …]

• findOrderHistory 쿼리 전용 인덱스 정의
  • DynamoDB의 query() 작업은 파티션 키와 정렬 키의 쌍을 기본키로 사용하여 알맞은 결과를 반환할 수 있다.
    • 파티션 키 - Z축 확장 시 이 키를 보고 저장소 파티션을 선택
  • (consumerId, orderCreationDate)는 유일한 값이 아니기에 기본키로는 적합하지 않다.
  • 해결 방법은 보조 인덱스를 만들어 (consumerId, orderCreationDate) 쿼리할 수 있다.
  • RDBMS의 인덱스와 비슷하지만 비식별 속성을 가질 수 있다는 점이 다르다.
    • 애플리케이션 테이블에서 가져올 필요 없이 쿼리로 반환되는 값이라 성능이 향상된다.
    • 지금의 경우 (orderId, status)를 가질 수 있다.
• findOrderHistory 쿼리 구현
  • DynamoDB query() 작업은 정렬 키에 범위 제약을 걸 수 있는 조건 표현식을 지원하기에 쉽게 구현 가능하다.
  • 비식별 속성으로 필터링하려면 불(Boolean) 표현식인 필터 표현식으로 구현 가능하다.
• 쿼리 결과 페이지네이션
  • DynamoDB 쿼리는 반환할 아이템 개수를 pageSize 매개변수로 지정한다.
  • DynamoDB는 위치(position) 기반 페이지네이션은 지원하지 않는다.
• 주문 업데이트
  • PutItem()
    • 기본키로 찾은 아이템을 생성 또는 대체하는 작업
    • 동시성 문제로 핸들러 A가 핸들러 B의 변경분을 덮어쓸 가능성이 있다.
    • 낙관적 잠금으로 동시성을 해결할 수는 있지만 UpdateItem()을 이용하는 것이 더 간단하다.
  • UpdateItem()
    • 개별 아이템 속성을 업데이트하고 필요 시 아이템을 생성하는 작업
    • 주문을 테이블에서 미리 가져올 필요가 없어 효율적
• 중복 이벤트 감지
  • 중복 이벤트를 접수한 핸들러가 Order 아이템 속성을 과거 값으로 세팅할 가능성이 존재한다.
  • OrderHistoryDaoDynamoDb는 아이템마다 이벤트를 일일이 기록해 중복 이벤트를 감지한다.
  • OrderHistoryDaoDynamoDb는 <애그리거트 타입=""><애그리거트 ID=""> 속성으로 애그리거트 별 이벤트를 추적 가능하다.
  • 각 애그리거트에서 전달 받은 이벤트 ID가 존재하지 않거나 더 큰 이벤트 ID인 경우에만 값을 업데이트하도록 한다.

attribute_not_exists(<애그리거트 타입><애그리거트 ID>
    또는 <애그리거트 타입><애그리거트 ID> < :이벤트 ID

7.4.3 OrderHistoryDaoDynamoDb 클래스

• ftgo-order-history 테이블의 아이템을 읽고 쓰는 메서드가 구현된 클래스
• 이 클래스의 업데이트 메서드는 OrderHistoryEventHandler가, 쿼리 메서드는 OrderHistoryQuery API가 각각 호출한다.