CQRS 패턴은 아키텍처 레벨에서 Command 모델과 Query 모델을 명확히 분리하는 것입니다.
이 패턴은 Application을 벗어나 DB Layer까지 고려한 방법입니다.
보통 일반적인 CRUD 패턴에서는 그림과 같이 서버와 DB가 네트워크를 두고 존재할겁니다. 서버로 요청된 api는 Command든 Query든 상관 없이 모두 하나의 DB에 접근하게 됩니다. 하지만, 서버에서 정해둔 DB의 CP(Connection Pool)은 한정되어 있습니다. 실제로 사용자가 처리하는 대부분의 작업은 Read 작업이고, 보통 Read 작업은 Indexing, Caching 등을 활용해 효율을 극대화하는 방법을 사용합니다. 하지만 CP가 한정되어 있고 cahce miss가 발생한다면 스레드가 Connection를 얻기 위해 대기하며 네트워크 병목 과 Command로 인한 DB 서버 cpu 및 memory 경합 이 발생할 수 있습니다.
우리는 이를 대비하기 위해 적당한 CP를 선정할 필요가 있습니다. 하지만, 이론 상 적당한 CP의 개수는 core_count * 2 + spindle count 입니다. green winit은 ssd 기반 ebs volume을 사용하는 ec2 환경에서 배포하므로 spindle count를 알 수 없습니다. 그래서 보통 안정적으로 작게 시작하는데, t2.micro 기준 1 core * 2 ~ 1 core * 4 = 2 ~ 4 개 정도의 CP가 적당할 것으로 보입니다.
선정 기준을 바탕으로 Boot에서 최대 4개의 CP를 할당했다고 했을 때, CRUD 패턴에서는 Command와 Query가 같은 CP를 공유하게 될겁니다. 그럼 위에서 언급된 문제들이 발생하게 될 것이고 우리는 이를 개선하기 위해 DB는 Master/Slave 전략으로, 서버에서는CQRS 패턴을 도입하며 앞서 언급한 문제점을 해결 할 수 있습니다.
여기서 중요한 포인트는 CQRS 패턴은 아키텍처 레벨에서 분리하는 것으로 DB와는 연관이 없음을 인지할 수 있습니다!
챌린지 인증 Command 중 이미지 업로드는 I/O bound 작업으로 상당한 시간이 소요됩니다. 특히, 외부 서비스와 연동된 만큼 AWS 트래픽에 따라 처리 속도는 더욱 느려질 수 있습니다. T type 인스턴스의 경우 버스터블 성능으로 동시간대 여러 사용자가 이미지 업로드를 한다면 CPU 크레딧이 빨리 소진되어 처리 속도는 매우 떨어집니다.
이런 상황을 고려해서 이미지 업로드 작업은 2s가 소요된다고 가정하겠습니다.