[MSA] CQRS 패턴, B마트 전시 도메인 CQRS 적용하기를 보고...

ㅁ 들어가며

  마이크로서비스의 패턴 중 CQRS에 대해 공부하면서 B마트 전시 도메인 CQRS 적용하기 영상을 보았고, 관련 내용을 정리해 보았다.

 CQRS 패턴을 구성하게 된 이유를 설명하며, 아키텍처 구성까지 세부적으로 설명하고 있다. 

 

 

ㅁ 데이터 구조는 어떻게 될까?

ㅇ 고객의 의식 순서대로 데이터구조는 전개되지 않는다.

    ㄴ 다르게 말해 데이터의 일관성 구조을 유지할 수 없다.

ㅇ 실제 데이터는 지역과 영업적 이유로 복잡한 구조를 가니다.

    ㄴ 지점: 고객의 위치에 따른 지점

    ㄴ 지점에서 제공가능한 카탈로그

    ㄴ 카탈로그에 종속되는 상품과 아이템

    ㄴ 실물 배송 담당인 물류센터와 연계

    ㄴ 유통기한 및 업체 알고리즘에 따른 실물 선택

 

ㅁ 정규화 -> 비정규화

ㅇ 실질적인 물류를 관리하는 DB 스키마는 일관성이 유지된 관계형 데이터베이스 구조를 가진다.

ㅇ 고객에게 보여지게 되는 데이터는 비정규화된다.

   ㄴ 고객에게 보여주기 좋은 형태의 데이터 구조를 가지기 위해서이다.

 

ㅁ CQRS란?

Command and Query Responsibility Segregation 

명령과 조회의 책임을 분리한다.  

다시 말해, Writes(Insert,Update,Delete)와 단순 Read(Select)를 분리한다.

 

ㅁ 모노리틱 구조의 한계

ㅇ 서비스 초기 단순한 아키텍처

   ㄴ 명령(Create/Update/Delete)과 조회를 하나의 애플리케이션에서 처리함.

   ㄴ 초기 데이터 설계 및 메인 로직 개발에 이로움이 있다.

       ㄴ 데이터베이스의 일관성을 위해 모델을 하나로 관리하는 것이 바람직하다.

 

ㅇ 서비스가 성장하면서 다양한 서비스를 접목시키는 과정이 발생한다. 

   ㄴ 초기 비지니스 로직에서 고객의 니즈나 사업 전략에 의해 외주 주입 데이터(고객 맴핑) 데이터가 증가한다.

ㅇ 서비스의 성장은 모델을 복잡하게 하고 상황에 따라 불필요한 컬럼을 함께 조회한다.

   ㄴ 모델은 내부적인 관리를 위한 컬럼과 사용자를 위한 정보가 혼용됨.

   ㄴ 불필요한 데이터까지 모델로 관리하는 경향이 생김.

   ㄴ 불필요한 데이터로 인해 서비스 포퍼먼스에 문제가 발생함.

ㅇ 새로운 서비스를 출시 할 때에 복잡도와 연관성으로 인해 분리하기 어렵게 된다.

ㅇ 이를 해결하기 위해서 명령과 조회 도메인을 분리한다. 

ㅁ CQRS 패턴 적용

ㅇ 데이터의 일관성과 서비스 포퍼먼스를 위한 MSA의 격리성 사이에 딜레마를 극복한다.

ㅇ 데이터의 일관성을 책임 질 메인 모듈에 명령 도메인을 설정

    비정규화를 통해 조회 최적화된 다른 데이터베이스 혹은 NoSQL을 이용한 조회 도메인을 생성

 

ㅇ 도메인의 2가지 종류

 - 명령 도메인: 기존  비지니스로직을 처리하는 도메인 

   ㄴ Entity

 - 조회 도메인: 고객에게 제공되는 조회용 데이터에 최적화된 비정규화 도메인

   ㄴ Dto: 전체 Row가 아닌 일부데이터를 재정의 

 

ㅁ 성능의 한계

ㅇ 조회모델을 만드는 것은 최적화된 스키마를 비정규화를 의미.

ㅇ 비정규화된 데이터를 가지고 오기 위해 조회 서비스에 메인 직접 호출

ㅇ 비정규화된 데이터를 가져올 때의 한계

 ㄴ API 연동:

        ㄴ 메인 서비스에서 API를 직접 호하여 필요 비정규화 데이터 생성.

        ㄴ 서비스 장애 시 요청이 손실될 수 있음.

 ㄴ Cache: 서비스 포퍼먼스 향상을 위해 Cache를 사용

 

ㅁ 생성, 저장과 조회 시점 나누기, 비정규화 데이터 분리

 ㅇ 메인 데이터 변경 시 이벤트로 받아 조회 모델을 생성저장

 ㅇ CQRS에서는 Join이나 기타 연산작업을 극히 제한

    ㄴ 연산으로 인한 디비 병목을 예방함.

    ㄴ 연산없이 바로 조회하는 비정규 데이터 설계 필요.

    ㄴ 조회 포퍼먼스를 위해 NoSQL도 사용가능

ㅇ 이런 패턴은 명령 작업은 적고, 조회 작업이 많은 상황에 적합.

 

ㅁ 이벤트 소싱

ㅇ 조회 모델 데이터를 생성도 부하가 발생한다.

ㅇ 명령 모델은 변경 데이터의 이벤트를 소싱하여 조회가 필요한 서비스에서 처리하도록 하여 명령모델의 부하를 감소시킨다.

ㅇ 메인 서비스와 조회를 하는 여러 조회 서비스들의 결합도를 낮추어 서비스의 확장성을 높일 수 있다.

 

ㅁ 언제 CQRS?

ㅇ UX와 비지니스 요구 사항이 복잡할 때에

ㅇ 대량 조회 트래픽이 있을 때

ㅇ 데이터의 관리와 조회가 나뉘어져 있을 때

ㅇ 시스템 확장성이 높을 때

ㅇ (12:00)

 

ㅁ 스파게티 코드, 파스타 소스

ㅇ 처음에 단순했던 비지니스로직이 복잡해지고, 모델간의 의존성이 역전되면서 파스타 소스, 혹은 스파게티 코드가 되어갔다.

 

ㅇ 성능 향상을 위해 DB가 아닌 Redis를 적극 활용

ㅇ Redis도 부하가 가중되었고, 지연률이 높아지면서 로컬 캐시를 사용하기도함.

ㅇ 로컬 캐시

  ㄴ Redis 부하 감소 효과   

  ㄴ 서버 힙 메모리 사용량 증가

  ㄴ 오케스트레이션 환경에서 데이터 정합성 문제 발생. 인스턴스마다 값이 다를 수 있음.

 

ㅁ 조회 모델 설계

ㅇ 정리가 필요한 모델은 한 클레스로 모으기

  ㄴ Inner Class로 정리한 것일듯... 관련글: [Spring] DTO 깔끔하게 정리하는 법, Inner Class

ㅇ 핵심 도메인 모델 정의 

ㅇ 정규화처럼 API의 도메인도 정규화하여 중복되는 부분을 간소화함.

 

ㅁ 감지 대상과 이벤트

ㅇ 엔티티 변경에 따라 갱신 해야할 대상 ID

ㅇ 변경 감지할 Property 지정

ㅇ 실행Method 지정

 

 

ㅇ 이벤트를 생성하고 ID만 넘겨주어 정보 전달 시의 네트워트 IO를 아낄 수 있었다.

ㅇ 이후 코드로 설명하고 있다. 

 

 

ㅁ 마무리 

예전에도 보았던 동영상인데, 시간이 지나면서 새롭게 느껴지는 동영상이었다. CQRS 패턴은 서비스의 확장으로 부하가 발생하고, 이를 해결하는 과정에서 과 다양한 고객 서비스를 지향하여 서비스의 운영적 포퍼먼스를 위해 MSA 구조를 명령과 조회의 책임을 분리한다. 동영상은 이런 부분을 잘 설명해 주고 있고, 나중에 또 볼 때에 좋은 기억이 사라질 것 같아, 동영상 리뷰 겸 CQRS 패턴에 대해 이해하고 정리하는 시간을 가져 보았다.

 

ㅁ 함께 보면 좋은 사이트

ㅇ https://youtu.be/fg5xbs59Lro?si=H8FsdWnsl6vDpeMv