Devops Day 44 (5.8) 마이크로서비스_CQRS

CQRS
CQRS는 Command Query Responsibility Segregation(명령과 조회의 책임 분리)의 약자로 이름처럼 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS의 핵심입니다.

CQRS는 초기 CQS에서 시작되어 확장되었습니다.

CQS는 Command Query Separation의 약자로 시스템에서 처리되는 명령과 조회, 이 두 작업을 정의하는 핵심 개념이자, 이 둘을 분리시키는 디자인 패턴입니다.

기존에 하나의 데이터 저장소에 CRUD 작업을 모두 처리했다면, CQRS는 요청을 크게 명령(Create, Update, Delete)과 조회(Read)로 나누어 처리합니다.

명령과 조회를 각각 분리하면 명령(쓰기) 요청의 부하를 줄이고, 조회 대기 시간을 줄이는 등 다양한 이점을 누릴 수 있습니다.

데이터로 저장하는 것이 아니라 상태 변경 이벤트 자체를 저장하는 기법 사용할 경우 메시지 브로커와 데이터 저장소를 분리하지 않아도 될 뿐만 아니라, 데이터로 변경하는 복잡한 과정이 없어 쓰기 속도도 빠르고, 이벤트에 따른 CRUD를 전부 처리할 필요 없이, 이벤트 발생/조회만 처리하면 되어 서비스 확장을 조금 더 용이하게 할 수 있습니다.

두 번째 발표

[C817] 메시지 서비스로는 대표적으로 Apache Kafka와 Amazon SQS, Amazon Kinesis가 있습니다. 각각은 어떤 차이가 있나요?

Apache Kafka는 분산 실시간 스트리밍 플랫폼으로, Pub/Sub 메시지 패턴을 지원하며 대량의 데이터 처리와 확장성에 중점을 둡니다.

 

Amazon SQS는 완전 관리형 대기열 서비스로, 단일 프로듀서와 컨슈머 간의 비동기 메시지 통신을 지원하며 확장성과 내구성에 중점을 둡니다.

 

Amazon Kinesis는 실시간 스트리밍 데이터 처리를 위한 완전 관리형 서비스로, 대량의 스트리밍 데이터를 실시간으로 수집, 처리 및 분석할 수 있습니다. 스트림 단위로 데이터를 처리하며 여러 컨슈머가 동시에 읽을 수 있습니다.

Apache Kafka:

- Kafka는 분산 실시간 스트리밍 플랫폼으로 설계되었습니다. 높은 처리량과 지연 시간을 처리하는 데 중점을 둡니다.

- 다양한 소스에서 대량의 데이터를 수집하고, 실시간으로 처리하고, 여러 컨슈머에게 전달하는 데 사용됩니다.

- Kafka는 Pub/Sub(게시/구독) 메시지 패턴을 지원합니다. 메시지는 토픽(topic)에 발행(publish)되고, 이를 구독(subscribe)하는 컨슈머가 메시지를 소비(consume)합니다.

- 데이터의 내구성과 확장성에 중점을 두며, 따라서 대량의 데이터를 처리하고 여러 컨슈머에게 효과적으로 확장할 수 있습니다.

- 주키퍼(ZooKeeper)를 사용하여 메시지의 오프셋(offset)을 관리하고, 장애 감지 및 복구를 제공합니다.

Amazon SQS (Simple Queue Service):

- SQS는 완전 관리형 대기열 서비스로, 분산 메시지 전달을 처리하는 데 사용됩니다.

- 단일 프로듀서와 단일 컨슈머 간의 비동기 메시지 통신을 지원합니다.

- FIFO(First-In-First-Out) 및 표준 큐 두 가지 유형의 대기열을 제공합니다. FIFO 대기열은 메시지의 순서가 보장되며, 표준 대기열은 최소 한 번의 메시지 전달을 보장합니다.

- SQS는 메시지를 처리하기 위해 폴링(polling) 방식을 사용하며, 컨슈머가 대기열을 주기적으로 확인하여 메시지를 가져옵니다.

- Amazon SQS는 확장성과 내구성에 중점을 두고 있으며, 따라서 대량의 메시지 처리 및 장애 복구에 유용합니다.

Amazon Kinesis:

- Kinesis는 실시간 스트리밍 데이터 처리를 위한 완전 관리형 서비스입니다.

- 대량의 스트리밍 데이터를 실시간으로 수집, 처리 및 분석할 수 있습니다.

- Kinesis는 스트림(Stream) 단위로 데이터를 처리합니다. 스트림은 데이터를 보관하고, 여러 컨슈머가 동시에 읽을 수 있습니다.

- 높은 처리량과

[C818] 웹 서비스에서 메시지 브로커(메시지 큐)를 이용해 비동기적인 방법이 활용되는 사례를 하나 이상 찾아보고, 어떻게 활용되는지 설명하세요.

 

비동기적인 방법으로 메시지 브로커(메시지 큐)를 활용하는 웹 서비스의 사례 중 하나는 이벤트 기반 아키텍처입니다. 이벤트 기반 아키텍처는 여러 컴포넌트 간에 이벤트를 비동기적으로 전송하고 처리함으로써 시스템의 유연성과 확장성을 향상시킵니다. 전자 상거래 웹 사이트에서 주문 처리 시스템 운영할 경우 용자가 주문을 생성하면, 주문 정보를 처리하고 주문 상태를 업데이트하는 여러 단계의 작업이 필요합니다. 이때 메시지 브로커를 사용하여 비동기적으로 작업을 분리하고 처리할 수 있습니다.

 

주문 생성 이벤트 발행: 사용자가 주문을 생성하면, 웹 애플리케이션은 주문 생성 이벤트를 메시지 브로커에 발행합니다. 이 이벤트에는 주문에 대한 정보가 포함됩니다.

 

주문 처리 단계: 메시지 브로커에서 주문 생성 이벤트를 구독하는 주문 처리 서비스가 이벤트를 수신합니다. 주문 처리 서비스는 주문을 검증하고 재고 확인, 결제 처리 등의 작업을 수행합니다. 각 작업은 별도의 이벤트로 발행되어 메시지 브로커를 통해 다음 단계로 전달됩니다.

 

주문 상태 업데이트: 각 작업의 결과로 주문 상태가 변경되면, 상태 업데이트 이벤트가 메시지 브로커에 발행됩니다. 이벤트를 구독하는 웹 애플리케이션은 주문 상태를 업데이트하고 사용자에게 알림을 제공할 수 있습니다.

 

이러한 방식으로 메시지 브로커를 활용하면 주문 처리 시스템을 비동기적으로 구성할 수 있으며, 각 단계를 독립적으로 확장하고 결합도를 낮추는 장점을 가집니다