45일차 마이크로서비스

CQRS(Command and Query Responsibility Segregation)

 

CQRS는 명령과 쿼리의 역할을 구분한다는 것을 뜻하며 커맨드 (Create, Insert, Update, Delete)와 쿼리(Select - Read)의 책임을 분리하는 의미를 가진다.

 

커맨드 - 명령 - 상태를 변경하는 작업(Create, Insert, Update, Delete)

쿼리 - 조회 - 상태를 반환하는 작업(Select - Read)

 

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

 

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

 

CQRS 패턴을 마이크로서비스에 적용해보자.

 

마이크로서비스의 핵심은 서비스별 데이터 저장소를 각기 다르게 채택하는 것이며 이때 서비스 성능 향상을 위해서 인스턴스를 스케일 아웃하여 여러 개로 실행할 경우 빈번한 명령과 조회 작업으로 리소스 교착상태가 발생할 수 있다. 뿐만 아니라, 통상적으로 명령보다 조회 요청이 훨씬 많이 사용되기 때문에, 하나의 서비스 내에 이러한 모든 기능을 넣어두면, 조회 요청 빈도가 증가함에 따라 명령기능도 함께 확장해야 하기 때문에 도메인의 복잡도가 높아진다.

 

이러한 문제점을 해결하기 위한 방법 중 하나로, CQRS 패턴을 사용하는 것이다. 기존에 하나의 데이터 저장소에 CRUD 작업을 모두 처리 했다면, CQRS는 요청을 크게 명령(Create, Update, Delete)과 조회(Read)로 나누어 처리한다.

 

보통 CQRS를 호텔 방에 비유하여 일반, 프리미엄, 디럭스로 비유하여 부른다.

 

일반

 

일반은 단순히 모델을 나누는 형태로 명령과 조회를 분리할 수 있다. 하지만 하나의 데이터 저장소를 사용한다는 면에서 완벽하게 마이크로서비스 설계 철학과 부합하는 것은 아니다.

 

프리미엄

 

프리미엄은 아예 물리적으로 명령 작업과 조회 작업을 위한 데이터베이스를 따로 준비하는 것이다. 이처럼 명령과 조회를 각각 분리 하면 명령(쓰기) 요청의 부하를 줄이고, 조회 대기 시간을 줄이는 등 다양한 이점을 누릴 수 있다.

 

디럭스

디럭스는 CQRS 패턴은 이벤트 소싱 패턴과 함께 사용한다.

이벤트 소싱 : Application내의 모든 Activity를 이벤트로 전환해서 이벤트 스트림(Event Stream)을 별도의 Database에 저장하는 방식

 

기본적으로 앞서 살펴본 메세지 브로커를 이용한 이벤트 주도의 아키텍처의 경우, 이벤트로 인해 상태가 변경된 경우, 이를 데이터 모델로 처리 하고 최종값을 반영하는 형태를 의미한다. 하지만 이벤트 소싱 패턴의 경우, 이를 데이터로 저장하는 것이 아니라 상태 변경 이벤트 자체를 저장하는 기법을 의미한다.

 

이렇게 하면 메세지 브로커와 데이터 저장소를 분리 하지 않아도 될 뿐만 아니라, 데이터로 변경하는 복잡한 과정이 없어 쓰기 속도도 빠르고, 이벤트에 따른 CRUD를 전부 처리할 필요 없이, 이벤트 발생/조회만 처리하면 되어 서비스 확장을 조금 더 용이하게 할 수 있다. 다시 말해, 이벤트는 한 번 발생한 후에 수정되지 않고 업데이트나 삭제 없이 입력만 되는 개념이기 때문에 저장소에 이러한 이벤트를 저장(쓰기)해두고, 필요한 데이터가 생기는 시점에 축적된 이벤트를 조회(읽기) 하기만 하면 되는 형태로, CQRS와 같은 맥락의 패턴을 가진다.

따라서 이벤트 소싱과 CQRS는 함께 사용하기 좋은 패턴이다.

 

! CQRS패턴에 이벤트 소싱은 필수가 아니지만 이벤트 소싱에 CQRS는 필수임 !

 

 

 

+추가 공부

 

SQS

Message Visibility Timeout

 

Visibility Timeout이란 중복 처리를 막기위해 컨슈밍서버 한대가 컨슘했을 때 다른 서버들은 컨슘할 수 없게하는 대기시간을 말합니다. 다른 서버에서 컨슘하기 위해서는 Visibility Timeout을 기다릴 수 밖에 없습니다.

 

SQS 설명  : https://sabarada.tistory.com/119

 

 

Dead Letter Queue

실패한 레코드를 보관하는 별도의 큐(토픽)이다

1. 존재하지 않는 큐로 전송되는 메시지입니다. [1] [2]
2. 대기열 길이 제한을 초과했습니다.
3. 메시지 길이 제한을 초과했습니다.
4. 다른 큐 교환에서 메시지를 거부했습니다. [삼]
5. 메시지가 소비되지 않았기 때문에 임계값 읽기 카운터 수에 도달했습니다. 때때로 이것을 "백아웃 큐"라고 합니다.
6. 메시지당 TTL(수명) 로 인해 메시지가 만료됨 [4]
7. 메시지가 성공적으로 처리되지 않았습니다.

저런 이유로 DLQ로 들어갈 수 있다.

 

DLQ 설정 하는 방법 : https://lannstark.tistory.com/87 

 

 

SNS(Simple Notification service)

 

Amazon SNS 는 발행자에게서 구독자 (혹은 생산자에게서 소비자 라고도 함) 에게 메시지 전달 기능을 제공하는 관리 서비스다. 발행자는 비동기적으로 '토픽' 에 메시지를 전송하는 방법으로 구독자와 통신한다. 이 토픽은 논리적인 액세스 포인트와 소통 채널을 의미한다.

고객은 특정 SNS 토픽에 구독하고 발행된 메시지를 지원되는 프로토콜을 통해 받을 수 있다. 이 프로토콜은 Amazon Kinesis Data Firehose, Amazon SQS, AWS Lambda, HTTP, email, 모바일푸시알람, 모바일 메시지 (SMS) 등이 있다.

 

기능과 특징

• A2A messaging (application to application)
• a2a 메시징서비스는 Kinesis, Lambda, SQS, HTTP/S endpoint 등을 지원함
• A2P notifications
• 모바일 애플리케이션, 휴대전화, 이메일 등으로 개인 구독자에게 사용자 알림을 줄 수 있다
• 표준적인 FIFO 토픽
• strict한 메시지 순서를 보장하기 위해, 메시지 그룹을 정의하기 위해, 메시지 중복을 방지하기 위해 FIFO 토픽을 사용한다. 모든 지원되는 딜리버리 프로토콜은 표준 토픽에 구독가능하다.
• 메시지 지속성
• Amazon SNS 는 여러 전략을 이용해 지속성을 보장한다. 대표적으로 DLQ(Dead Letter Queue)
• 메시지 아카이브화와 분석
• Kinesis Data Firehose 로 SNS topic 을 구독해 추가적인 아카이빙과 분석을 제공한다
• 메시지 속성 제공
• 메시지 속성을 통해 메시지에 대한 임의의 메타데이터들을 제공받을 수 있다
• 메시지 필터링
• 토픽을 구독한 구독자는 해당토픽의 모든 메시지를 받게 되는데, 메시지의 하위집합만을 받고자 하려면 구독자는 해당 토픽의 구독의 필터 정책에 동의해야한다. 필터정책에 부합하는 속성을 가진 메시지만이 전달될 수 있게 된다. 그렇지 않은 경우의 메시지는 걸러진다.
• 메시지 보안
• AWS KMS 에 의해 보호되는 암호화 키를 사용해 메시지의 내용을 보호한 상태로 SNS 토픽에 저장된다.