<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" />

해당 글은 CQRS 패턴과 데이터 플로우에 위주로 다루고, DynamoDB 나 ES/OS 와 같이 조회에 최적화된 데이터베이스에 대해서는 깊게 다루지 않겠습다! (자료를 완성하고 보니, 차라리 그냥 PPT로 만들걸 이라는 생각이….)

</aside>

서론

최근 v1.1 기획 회의를 통해서 통합 검색 기능과 해시태그 기능을 추가하기로 결정.

기능 추가시 추가 인프라를 사용하지 않고 기존에 사용중인 인프라만 사용하여 운영할 수 있는지 POC 진행

MySQL 검색 인덱스 POC:

• FTS + FTI(Full-Text Index)
  • 추가 필터링 조건이 생길 경우 인덱스를 타지 않음
• 반정규화 + MVI(Multi-Value Index)
  • 인덱스 생성 비용 증가
  • JOIN 쿼리보다 조회 속도가 느림
• 정규화 JOIN + Index
  • 필터링 조건이 추가될수록 성능 하락

POC 에서 MySQL 만으로는 라이브로 전문 검색 기능을 운영하기 어렵다고 판단 → OpenSearch 도입 결정

전문 검색이 필요한 기능에 한정적으로 OpenSearch를 사용하도록 제한하여 리소스 비용 최소화하기 위해 노력

Command Query Responsibility Segregation

CQRS란?

<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" />

• CQS(Command Query Separation) 과의 차이점은?

https://www.martinfowler.com/bliki/CommandQuerySeparation.html

</aside>

CQRS 그림 - 출처 https://engineering-skcc.github.io/microservice outer achitecture/inner-architecture-cqrs/

• 시스템의 상태를 변경하는 명령과, 시스템의 상태를 조회하는 조회의 역할을 분리한 아키텍처 패턴
  • Command(명령) : 시스템의 상태를 변경시키는 작업
  • Query(조회) : 시스템의 상태를 조회하는 작업
  • CQRS는 Bertrand Meyer의 CQS 원칙을 확장한 개념임
• 명령과 조회의 책임을 분리함으로 써, 명령과 조회의 패러다임 불일치 문제를 해소할 수 있음
  • Command-Side → 비즈니스 로직, Validation 로직 등등..
  • Query-Side → 캐싱처리, 반정규화, 높은 처리량 등등..
  • 패러다임의 불일치가 잘 와닿지 않는다면?
• 명령과 조회의 책임이 시스템적으로 분리가 되어있다면 독립적인 최적화 전략을 사용할 수 있음
  • Command-Side → PGSQL, MySQL 등등
  • Query-Side → DynamoDB, OpenSearch 등등
  • 만약, 조회에 트래픽이 너무 몰린다? → Query-Side 만 독립적으로 스케일링