왜 CQRS를 적용?? 🤷‍♂️

우리 팀은 “단일장애지점 극복”이라는 대명목하에 CQRS 패턴을 적용하기로 했다.

그렇다면 CQRS를 적용하면 어떤 부분에 있어 장단점이 있을까?

CQRS 장점

• 코드 레벨
  • Command, Query 역할과 책임을 분리함
    • 단일책임 원칙을 지킬 수 있음
    • 리팩토링 허들을 낮출 수 있음
• 아키텍처 레벨

  • 성능개선

    • 조회 요청과 명령 요청의 트래픽이 분산처리 되므로 더 많은 트래픽을 처리할 수 있다.
    • 이는 곧 성능을 끌어올릴 수 있다는 것을 의미!

  • 장애극복

    Command 와 Query에 대한 DB를 분리함으로서, 한 곳이 장애가 나도 극복이 가능하다.

    • 만약 Primary DB에 장애가 발생한다면
      • Secondary DB를 Primary DB로 승격시켜서 장애지점을 극복할 수 있다.
    • 만약 Secondary DB에 장애가 발생한다면
      • Primary DB를 Secondary DB로 복붙한다(이 표현이 적합한가,,ㅎㅎ)
    • 만약 둘 다 장애가 발생한다면
      • 만들어둔 백업 DB를 활용하여 롤백한다.

어떻게 하면 구현할 수 있을까?👇

Aurora 사용 제한사항

Aurora를 쓰면 한 큐에 해결된다.

(심지어 공식문서에서조차 Aurora 써줘잉하면서 현혹한다,,,역시 장사꾼들,,,)

Aurora는 Cluster 내부에 Primary DB와 여러 Secondary DB들이 내장되어있다.

• Primary DB
  • read, write 모두 가능
  • 클러스터당 하나씩만 존재
• Secondary DB
  • read만 가능
  • 최대 15개까지 지원하고, 하나의 엔드포인트만 애플리케이션에서 연결해도 여러 Secondary DB들로 로드밸런싱을 해준다.
  • Secondary DB들은 별도의 가용영역에 위치하므로, 고가용성을 유지한다.
  • Primary DB가 죽어도 자동으로 Secondary DB가 승격되는 failover 기능을 가지고 있다.

하지만 결국 가장 큰 문제점에 다달렀다. 문제는 Aurora의 Cost이다.