이 문서는 Google Cloud Translation API를 사용해 자동 번역되었습니다.
어떤 문서는 원문을 읽는게 나을 수도 있습니다.
최근 몇 년 동안 마이크로서비스의 인기로 인해 CQRS(Command Query Responsibility Segregation) 패턴에 대한 관심이 다시 부각되었습니다. CQRS는 각각 단일 작업을 담당하는 독립 서비스 세트로 애플리케이션을 설계하는 데 사용할 수 있는 패턴입니다.
CQRS 사용의 주요 이점은 응용 프로그램의 확장성을 높이고 유지 관리를 쉽게 할 수 있다는 것입니다. CQRS를 올바르게 구현하면 응용 프로그램을 보다 예측 가능하고 이해하기 쉽게 만들 수 있습니다.
이 문서에서는 CQRS 패턴과 확장 가능하고 유지 관리 가능한 애플리케이션을 빌드하는 데 사용할 수 있는 방법에 대해 자세히 살펴보겠습니다. 또한 CQRS를 구현할 때 고려해야 할 몇 가지 문제에 대해서도 살펴보겠습니다.
CQRS(Command Query Responsibility Segregation)는 각각 단일 작업을 담당하는 독립 서비스 세트로 애플리케이션을 설계하는 데 사용할 수 있는 패턴입니다.
"Command Query Responsibility Segregation"이라는 용어는 2010년 Greg Young이 블로그 게시물에서 처음 사용했습니다. 이 게시물에서 Greg는 CQRS를 "Eric Evans가 그의 저서 Domain-Driven Design에서 처음 설명하는 기술"이라고 설명했습니다.
CQRS 패턴은 DDD(Domain-Driven Design) 커뮤니티에 뿌리를 두고 있으며 종종 이벤트 소싱과 같은 다른 DDD 패턴과 함께 사용됩니다.
CQRS 패턴의 핵심은 간단합니다. 즉, 애플리케이션을 명령 처리(쓰기라고도 함)를 담당하는 부분과 쿼리 처리(읽기라고도 함)를 담당하는 다른 부분으로 애플리케이션을 나누는 것입니다.
명령은 시스템 상태를 변경하라는 요청입니다. 일반적으로 버튼 클릭이나 양식 제출과 같은 사용자 상호 작용에 의해 트리거됩니다.
명령은 일반적으로 명령의 유효성을 검사하고 변경 사항을 시스템에 적용하는 코드 조각인 명령 처리기에 의해 처리됩니다.
쿼리는 시스템의 정보에 대한 요청입니다. 일반적으로 페이지 로드 또는 검색 수행과 같은 사용자 상호 작용에 의해 트리거됩니다.
쿼리는 일반적으로 시스템에서 데이터를 가져와 사용자에게 반환하는 코드 조각인 쿼리 처리기에 의해 처리됩니다.
CQRS 패턴은 명령 처리 책임과 쿼리 처리 책임을 분리하기 때문에 종종 관심사의 분리로 설명됩니다.
CQRS 패턴은 기술적 성능과 개발자 생산성 측면에서 많은 이점을 제공할 수 있습니다.
CQRS의 주요 이점 중 하나는 향상된 성능입니다. 응용 프로그램을 별도의 두 부분으로 분할하면 응용 프로그램을 수평으로 확장하는 것이 더 쉬울 수 있습니다.
예를 들어 애플리케이션이 많은 트래픽을 수신하는 경우 더 많은 쿼리 서버를 추가하여 애플리케이션의 쿼리 부분을 확장할 수 있습니다. 응용 프로그램의 명령 부분은 더 많은 명령 서버를 추가하여 확장할 수 있습니다.
CQRS의 또 다른 이점은 향상된 예측 가능성입니다. 응용 프로그램을 두 부분으로 나누면 응용 프로그램의 작동 방식을 더 쉽게 이해할 수 있습니다. 각 부분의 책임이 명확하게 정의되어 있기 때문입니다.
CQRS는 또한 개발자 생산성 향상으로 이어질 수 있습니다. 응용 프로그램을 두 부분으로 분할하면 다른 부분에 영향을 주지 않고 응용 프로그램을 보다 쉽게 변경할 수 있습니다.
예를 들어 명령이 처리되는 방식이 변경되더라도 쿼리가 처리되는 방식에는 영향을 미치지 않습니다. 이렇게 하면 변경 사항을 응용 프로그램에 더 쉽고 빠르게 배포할 수 있습니다.
CQRS 패턴은 많은 이점을 제공할 수 있지만 CQRS를 구현할 때 고려해야 할 많은 문제도 있습니다.
CQRS의 주요 과제 중 하나는 복잡성 증가입니다. 응용 프로그램을 두 부분으로 나누면 응용 프로그램의 작동 방식을 이해하기가 더 어려울 수 있습니다. 각 부분의 책임이 항상 명확하지 않기 때문입니다.
CQRS의 또 다른 과제는 개발 시간 증가입니다. 애플리케이션을 두 부분으로 나누면 애플리케이션 개발 시간이 더 오래 걸릴 수 있습니다. 개발팀에서 애플리케이션의 명령 부분과 쿼리 부분을 모두 개발해야 하기 때문입니다.
CQRS의 또 다른 과제는 운영 오버헤드 증가입니다. 애플리케이션을 두 부분으로 나누면 애플리케이션을 운영하기가 더 어려울 수 있습니다. 운영팀에서 애플리케이션의 명령 부분과 쿼리 부분을 모두 관리해야 하기 때문입니다.
이 문서에서는 CQRS 패턴과 확장 가능하고 유지 관리 가능한 애플리케이션을 빌드하는 데 사용할 수 있는 방법을 살펴보았습니다. 또한 CQRS를 구현할 때 고려해야 할 몇 가지 과제도 살펴보았습니다.
CQRS 패턴은 많은 이점을 제공할 수 있지만 모든 애플리케이션에 적합하지는 않습니다. CQRS를 사용할지 여부는 사례별로 결정해야 합니다.