2019년에 Redis에서 이벤트 저장소를 만드는 방법에 대해 썼습니다. Redis Streams는 트랜잭션 로그와 같은 변경할 수 없는 추가 전용 메커니즘에 이벤트를 저장할 수 있기 때문에 이벤트 저장소에 적합하다고 설명했습니다. 이제 해당 블로그에 소개된 샘플 OrderShop 애플리케이션의 업데이트와 함께 Redis를 메시지 대기열로 사용하는 방법을 보여주고 캐싱을 넘어 Redis Enterprise의 다양한 사용 사례를 추가로 보여드리겠습니다.
마이크로서비스, 인프라 서비스 및 분산 시스템에 대한 간략한 살펴보기
Redis는 메시지 대기열 및 이벤트 저장소와 같은 인프라 서비스를 생성하기 위한 훌륭한 솔루션이지만 마이크로서비스 아키텍처를 사용하여 분산 시스템을 생성할 때 고려해야 할 몇 가지 사항이 있습니다. 관계형 데이터베이스는 종종 모놀리식 애플리케이션에 적합했지만 Redis와 같은 NoSQL 데이터베이스만이 마이크로서비스 아키텍처에 필요한 확장성 및 가용성 요구 사항을 제공할 수 있습니다.
분산 시스템은 분산 상태를 의미합니다. CAP 정리에 따르면 소프트웨어 구현은 일관성, 가용성 및 파티션 허용 오차(따라서 CAP)라는 세 가지 속성 중 두 가지만 제공할 수 있습니다. 따라서 구현을 내결함성으로 만들려면 가용성과 일관성 중에서 선택해야 합니다. 가용성을 선택하면 최종 일관성을 갖게 됩니다. 즉, 일정 기간이 지난 후에만 데이터가 일관성을 유지하게 됩니다. 일관성을 선택하면 분산 시스템 전체에서 쓰기 작업을 동기화하고 격리해야 하기 때문에 성능에 영향을 미칩니다.
주문 또는 고객과 같은 비즈니스 엔터티의 상태를 일련의 상태 변경 이벤트로 유지하는 이벤트 소싱은 일관성 대신 가용성을 추구합니다. 쓰기 작업은 간단하지만 읽기 작업은 여러 서비스에 걸쳐 있는 경우 읽기 모델과 같은 추가 메커니즘이 필요할 수 있기 때문에 더 많은 비용이 듭니다.
분산 시스템의 통신은 중개되거나 중개되지 않을 수 있습니다. 브로커리스 스타일은 가장 유명한 인스턴스로 HTTP와 함께 잘 알려져 있습니다. 중개된 접근 방식은 이름에서 알 수 있듯이 메시지의 발신자와 수신자 사이에 중개자가 있습니다. 송신자와 수신자를 분리하여 동기 및 비동기 통신을 가능하게 합니다. 그 결과 메시지 소비자가 메시지가 전송되는 순간에 사용 가능하지 않아도 되므로 보다 탄력적인 동작이 발생합니다. 또한 중개된 통신을 통해 발신자와 수신자를 독립적으로 확장할 수 있습니다.
(자세한 내용은 동기 및 비동기 통신 요구 사항에 대한 선택 사항 - Redis Streams, Redis Pub/Sub, Kafka 등)에 대한 게시물을 참조하십시오.
OrderShop:전자 상거래 구현 샘플
마이크로 서비스 아키텍처의 "Hello World"는 이벤트 기반 접근 방식을 사용하는 전자 상거래 시스템의 간단한 구현인 OrderShop입니다. 이 샘플 애플리케이션은 간단한 도메인 모델을 사용하지만 애플리케이션의 목적을 충족합니다.
OrderShop은 Docker Compose를 사용하여 오케스트레이션됩니다. 모든 네트워크 통신은 gRPC를 통해 이루어집니다. 중앙 구성 요소는 이벤트 저장소와 메시지 대기열입니다. 각각의 모든 서비스는 gRPC를 통해서만 연결됩니다. OrderShop은 Python의 샘플 구현입니다. GitHub에서 OrderShop 소스 코드를 볼 수 있습니다.
(참고: 이 코드는 아닙니다. 프로덕션 준비가 되어 있으며 데모용입니다!)
달리기와 재미
- GitHub 저장소 복제:https://github.com/redis-demos/ordershop-v2
- 간단한 5단계 프로세스로 OrderShop v2 실행:
- docker-compose up으로 애플리케이션 시작
- 브라우저를 열고 https://localhost:5000/으로 이동합니다.
- 이벤트 보기 및 상태 탐색
- python -m unittest tests/unit.py로 클라이언트 실행
- 브라우저에서 다른 탭을 열어 https://localhost:8001/
- redis:6379 사용 테스트 데이터베이스에 연결
- docker-compose down으로 애플리케이션 중지
OrderShop v2 아키텍처
이 경우 서버 아키텍처는 여러 서비스로 구성됩니다. 상태는 여러 도메인 서비스에 분산되지만 단일 이벤트 저장소에 저장됩니다. 모델 읽기 구성 요소는 다음과 같이 상태를 읽고 캐싱하기 위한 논리를 집중합니다.
명령과 쿼리는 메시지 대기열을 통해 전달됩니다. 구성요소인 반면 이벤트는 이벤트 저장소를 통해 전달됩니다. 이벤트 버스 역할도 하는 구성 요소입니다.
인프라 서비스
OrderShop v2에서 모든 유니캐스트 통신은 메시지 대기열을 통해 발생합니다. 요소. 이를 위해 Redis 목록, 특히 두 개의 목록을 결합하여 소위 "신뢰할 수 있는 대기열"을 사용할 것입니다. 간단한 명령(예:단일 엔터티 작업)은 동기식으로 처리하지만 장기 실행 명령(예:일괄 처리, 메일)은 비동기식으로 처리하고 즉시 사용 가능한 동기식 메시지에 대한 응답을 지원합니다.
이벤트 저장소는 Redis Streams를 기반으로 합니다. 도메인 서비스(OrderShop의 기능을 보여주기 위한 더미)는 이벤트 주제(즉, 엔터티 이름)의 이름을 따서 명명된 이벤트 스트림을 구독하고 이러한 스트림에 이벤트를 게시합니다. 각 이벤트는 이벤트 타임스탬프가 ID 역할을 하는 스트림 항목입니다. 스트림에 게시된 이벤트의 합계는 전체 시스템의 상태를 나타냅니다.
응용 서비스
모델 읽기 이벤트 저장소에서 추론된 항목을 캐시합니다. Redis에서 도메인 모델을 사용합니다. 캐시를 무시하면 상태 비저장입니다.
API 게이트웨이 또한 상태 비저장이며 포트 5000에서 REST-API를 제공합니다. HTTP 연결을 종료하고 상태 읽기(쿼리)를 위한 읽기 모델 또는 쓰기 상태(명령)를 위한 전용 도메인 서비스로 라우팅합니다. 읽기 작업과 쓰기 작업 간의 이러한 개념적 분리는 CQRS(명령 쿼리 책임 분리)라는 패턴입니다.
도메인 서비스
도메인 서비스는 메시지 대기열을 통해 쓰기 작업을 수신합니다. API 게이트웨이에서 . 성공적으로 실행되면 각 이벤트에 대한 이벤트를 이벤트 저장소에 게시합니다. . 대조적으로 모든 읽기 작업은 읽기 모델에 의해 처리됩니다. 이벤트 저장소에서 상태를 가져옵니다. .
CRM 서비스 (고객 관계 관리 서비스)는 상태 비저장입니다. 이벤트 저장소에서 도메인 이벤트를 구독하고 메일 서비스를 사용하여 고객에게 이메일을 보냅니다. .
중앙 도메인 엔티티는 주문입니다. 아래 다이어그램과 같이 상태 머신을 사용하여 전환이 수행되는 '상태'라는 필드가 있습니다.
이러한 전환은 도메인 이벤트(SAGA 패턴)에 등록된 여러 이벤트 핸들러에서 수행됩니다. 예:
고객
클라이언트는 Python의 단위 테스트 프레임워크를 사용하여 시뮬레이션됩니다. 현재 10개의 단위 테스트가 구현되어 있습니다. tests/unit.py를 살펴보세요. 자세한 내용은.
이벤트를 보고 상태를 탐색하기 위해 포트 5000에서 간단한 UI가 제공됩니다(WebSockets 사용).
Redis 인스턴스를 검사하는 데 RedisInsight 컨테이너도 사용할 수 있습니다. https://localhost:8001/로 웹 브라우저를 열고 redis:6379를 사용합니다. 테스트 데이터베이스에 연결합니다.
결론
Redis는 도메인 계층(예:카탈로그 검색) 및 애플리케이션 계층(예:HTTP 세션 저장소)뿐만 아니라 인프라 계층(예:이벤트 저장소 또는 메시지 대기열)에서도 강력한 도구입니다. 이러한 계층 전체에서 Redis를 사용하면 운영 오버헤드가 줄어들고 개발자가 이미 알고 있는 기술을 재사용할 수 있습니다.
코드를 살펴보고 직접 구현해 보십시오. 이것이 도메인 및 인프라 서비스에서 Redis의 다용성과 유연성을 입증하고 캐싱을 넘어 어떻게 사용될 수 있는지 입증하는 데 도움이 되기를 바랍니다.
Twitter에서 진행 상황을 알려주세요. @martinez099.