🚀 읽기 전용 서버를 따로 둔다고?! CQRS 패턴 쉽게 이해하기

🤔 CQRS 패턴이 뭐길래?

개발을 하다 보면 이런 고민이 들 때가 있습니다.

"조회 요청이 너무 많아서 DB가 버벅거리는 걸 해결할 방법이 없을까?"
"명령과 조회가 같은 데이터베이스를 공유하다 보니 성능이 저하되네…"

이런 문제를 해결하기 위해 등장한 패턴이 CQRS(Command Query Responsibility Segregation)입니다.
말 그대로, 명령(Command)과 조회(Query)의 책임을 분리하는 아키텍처 패턴입니다.

즉, 데이터를 변경하는 요청(명령)과 데이터를 조회하는 요청(조회)을 분리해서 처리하는 방식이죠.

---

📌 CQRS 패턴을 왜 사용할까?

기존의 일반적인 애플리케이션 아키텍처에서는 하나의 데이터베이스에 명령과 조회가 함께 처리됩니다.

하지만 이렇게 되면 몇 가지 문제점이 생깁니다.

• 🚨 조회 요청이 많으면 DB가 버벅거린다 → 트래픽이 증가할수록 성능 저하
• 🔄 명령과 조회가 같은 모델을 공유 → 유지보수가 어렵고, 변경이 힘듦
• 🔗 DB 락(Lock) 이슈 → 트랜잭션을 유지해야 해서 성능 저하 발생

이런 문제를 해결하기 위해 CQRS를 사용하면 읽기와 쓰기를 분리하여 최적화할 수 있습니다! 🚀

---

🏗 CQRS 패턴의 기본 구조

CQRS 패턴은 크게 Command(명령)과 Query(조회)로 나뉩니다.

1️⃣ Command(명령)

• 데이터를 변경(생성, 수정, 삭제)하는 역할
• 예: 주문 생성, 상품 등록, 회원가입

2️⃣ Query(조회)

• 데이터를 읽기 전용으로 조회하는 역할
• 예: 주문 내역 조회, 상품 목록 조회

🖼 쉽게 표현하면?

사용자 → Command → DB (데이터 변경)
사용자 → Query → 별도 DB 또는 캐시 (데이터 조회)

이렇게 읽기와 쓰기를 분리하면, 조회 요청이 많더라도 데이터 변경에는 영향을 주지 않으며, 성능이 향상됩니다.

---

✍️ 예제 코드 (Spring Boot)

1️⃣ Command(명령) - 주문 생성

@RestController
@RequestMapping("/orders")
public class OrderCommandController {
    private final OrderService orderService;

    public OrderCommandController(OrderService orderService) {
        this.orderService = orderService;
    }

    @PostMapping
    public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
        Order order = orderService.createOrder(request);
        return ResponseEntity.ok(order);
    }
}

2️⃣ Query(조회) - 주문 내역 조회

@RestController
@RequestMapping("/orders")
public class OrderQueryController {
    private final OrderQueryService orderQueryService;

    public OrderQueryController(OrderQueryService orderQueryService) {
        this.orderQueryService = orderQueryService;
    }

    @GetMapping("/{id}")
    public ResponseEntity<OrderResponse> getOrder(@PathVariable Long id) {
        OrderResponse order = orderQueryService.getOrderById(id);
        return ResponseEntity.ok(order);
    }
}

🚀 차이점

• OrderCommandController → 주문을 생성하는 명령용 API
• OrderQueryController → 주문을 조회하는 조회용 API

즉, 읽기와 쓰기를 완전히 분리하여 각각의 역할을 나눈 것입니다.

---

✅ CQRS 패턴의 장점

✅ 읽기/쓰기 성능 최적화 → 조회 DB를 분리하여 읽기 성능을 극대화할 수 있음
✅ 확장성(Scalability) 향상 → 읽기와 쓰기를 별도로 확장 가능
✅ 데이터 모델 최적화 가능 → 조회용 DB는 NoSQL, ElasticSearch 등을 활용할 수 있음
✅ 비즈니스 로직 단순화 → 명령과 조회의 역할을 분리하여 유지보수 용이

---

❌ CQRS 패턴의 단점

❌ 설계 복잡성 증가 → 기존보다 데이터 구조가 복잡해짐
❌ 데이터 동기화 문제 → 명령과 조회 데이터가 일치하지 않을 가능성
❌ 추가적인 인프라 필요 → 읽기/쓰기 DB를 따로 운영해야 함
❌ Replica DB 동기화 지연 문제 → 특히 리전별로 Replica DB를 구성할 경우(제 경험담 입니다), 예를 들어 런던에서 일본까지 데이터 동기화에 1.3초 이상이 걸릴 수도 있습니다. 이 경우, Insert 후 바로 Select를 하면 Read DB에는 해당 데이터가 아직 존재하지 않아 문제가 발생할 수 있습니다. 이러한 문제를 해결하려면 즉시 호출을 제한하거나, Kafka를 활용한 이벤트 기반 동기화, 또는 프론트엔드에서 적절한 캐싱 처리를 고려해야 합니다.

하지만 고성능이 필요한 시스템(예: 전자상거래, 금융, SNS 등)에서는 CQRS 패턴이 매우 유용할 수 있습니다! 🏆

---

📌 CQRS 패턴을 언제 사용해야 할까?

다음과 같은 상황에서 CQRS 패턴을 고려하면 좋습니다.

✔ 읽기/쓰기 트래픽이 비대칭적인 경우 → 읽기 요청이 훨씬 많은 서비스 (ex: 뉴스 사이트, 검색 엔진)
✔ 고성능 조회가 필요한 경우 → ElasticSearch, Redis 등을 활용한 검색 서비스
✔ 복잡한 도메인 로직이 있는 경우 → 이벤트 소싱(Event Sourcing)과 결합하여 사용
✔ 확장성이 필요한 경우 → 읽기 서버와 쓰기 서버를 개별적으로 확장 가능

---

🎯 정리

📌 CQRS는 명령과 조회를 분리하여 성능을 최적화하는 패턴입니다.
📌 읽기와 쓰기를 따로 설계하면 확장성과 유지보수성이 향상됩니다.
📌 설계가 복잡해질 수 있으므로, 시스템의 특성을 고려하여 도입해야 합니다.

🚀 CQRS 패턴을 적용하면 더 빠르고 안정적인 서비스를 만들 수 있습니다. 하지만 모든 프로젝트에 적합한 것은 아니므로, 시스템의 요구사항에 따라 신중하게 도입하는 것이 중요합니다! 😊