インフラストラクチャマイクロサービスでRedisを使用する方法

2019年に、Redisでイベントストアを作成する方法について書きました。 Redis Streamsは、トランザクションログのような不変の追加専用メカニズムにイベントを保存できるため、イベントストアに適していると説明しました。次に、そのブログで紹介されているサンプルのOrderShopアプリケーションの更新を使用して、Redisをメッセージキューとして使用する方法を示し、キャッシュ以外のRedisEnterpriseの多くのユースケースをさらに示します。

マイクロサービス、インフラストラクチャサービス、分散システムの概要

Redisは、メッセージキューやイベントストアなどのインフラストラクチャサービスを作成するための優れたソリューションですが、マイクロサービスアーキテクチャを使用して分散システムを作成する場合は、考慮しなければならないことがいくつかあります。リレーショナルデータベースはモノリシックアプリケーションに適していることがよくありますが、マイクロサービスアーキテクチャに必要なスケーラビリティと可用性の要件を提供できるのはRedisのようなNoSQLデータベースだけです。

分散システムは、分散状態を意味します。 CAPの定理によれば、ソフトウェア実装は、これら3つの属性のうち、整合性、可用性、およびパーティション許容度（CAP）のうち2つしか提供できません。したがって、実装のフォールトトレラントを実現するには、可用性と整合性のどちらかを選択する必要があります。可用性を選択すると、結果整合性が得られます。つまり、データは一定期間が経過した後にのみ一貫性が保たれます。分散システム全体で書き込み操作を同期および分離する必要があるため、整合性を選択するとパフォーマンスに影響します。

一連の状態変化イベントとして、注文や顧客などの事業体の状態を維持するイベントソーシングは、一貫性ではなく可用性を求めます。書き込み操作は簡単ですが、読み取り操作は、複数のサービスにまたがる場合、読み取りモデルなどの追加のメカニズムが必要になる可能性があるため、コストが高くなります。

分散システムでの通信は、ブローカーまたはブローカーレスにすることができます。ブローカーレススタイルはよく知られており、HTTPが最も有名な例です。仲介されたアプローチには、その名前が示すように、メッセージの送信者と受信者の間に仲介者がいます。送信者と受信者を切り離し、同期および非同期通信を可能にします。これにより、メッセージが送信された時点でメッセージコンシューマーが使用可能である必要がないため、より回復力のある動作が得られます。仲介された通信により、送信者と受信者の独立したスケーリングも可能になります。

（詳細については、同期および非同期通信のニーズに合わせて選択するもの（Redis Streams、Redis Pub / Sub、Kafkaなど）に関する投稿を参照してください）

OrderShop：サンプルのeコマース実装

マイクロサービスアーキテクチャの「HelloWorld」は、イベントベースのアプローチを使用したeコマースシステムのシンプルな実装であるOrderShopです。このサンプルアプリケーションは単純なドメインモデルを使用していますが、アプリケーションの目的を果たしています。

OrderShopは、DockerComposeを使用して調整されます。すべてのネットワーク通信はgRPCを介して行われます。中心的なコンポーネントは、イベントストアとメッセージキューです。すべてのサービスは、gRPCを介してそれらにのみ接続されます。 OrderShopは、Pythonのサンプル実装です。 OrderShopのソースコードはGitHubで確認できます。

（注： このコードはではありません 本番環境に対応しており、デモのみを目的としています！）

走って楽しい

• GitHubリポジトリのクローンを作成します：https：//github.com/redis-demos/ordershop-v2
• OrderShop v2を簡単な5ステップのプロセスで実行します：

1. docker-compose upでアプリケーションを起動します
2. ブラウザを開き、 http：// localhost：5000 /に移動します
   1. イベントを監視し、状態を閲覧する
3. python -m unittest tests / unit.pyを使用してクライアントを実行します
4. ブラウザで別のタブを開いてhttp：// localhost：8001 /
   1. redis：6379を使用する テストデータベースに接続するには
5. docker-compose downでアプリケーションを停止します

OrderShopv2アーキテクチャ

この場合、サーバーアーキテクチャは複数のサービスで構成されます。状態は複数のドメインサービスに分散されますが、単一のイベントストアに保存されます。 モデルの読み取り コンポーネントは、次に示すように、状態を読み取ってキャッシュするためのロジックを集中させます。

コマンドとクエリは、メッセージキューを介して伝達されます コンポーネントですが、イベントはイベントストアを介して伝達されます コンポーネント。イベントバスとしても機能します。

インフラストラクチャサービス

OrderShop v2では、すべてのユニキャスト通信はメッセージキューを介して行われます。 成分。このために、Redisリストを使用します。特に、2つのリストを組み合わせていわゆる「信頼できるキュー」にします。単純なコマンド（単一エンティティ操作など）を同期的に処理しますが、実行時間の長いコマンド（バッチ、メールなど）を非同期的に処理し、すぐに使用できる同期メッセージへの応答をサポートします。

イベントストアはRedisStreamsに基づいています。ドメインサービス（OrderShopの機能を示すための単なるダミー）は、イベントトピック（つまりエンティティ名）にちなんで名付けられたイベントストリームにサブスクライブされ、これらのストリームにイベントを公開します。各イベントは、イベントタイムスタンプがIDとして機能するストリームエントリです。ストリームで公開されたイベントの合計は、システム全体の状態になります。

アプリケーションサービス

モデルの読み取り イベントストアから推定エンティティをキャッシュします ドメインモデルを使用してRedisで。キャッシュを無視すると、ステートレスになります。

APIゲートウェイ もステートレスであり、ポート5000でREST-APIを提供します。HTTP接続を終了し、状態を読み取るための読み取りモデル（クエリ）または状態を書き込むための専用ドメインサービス（コマンド）にルーティングします。読み取り操作と書き込み操作のこの概念的な分離は、コマンドクエリ責任分離（CQRS）と呼ばれるパターンです。

ドメインサービス

ドメインサービスは、メッセージキューを介して書き込み操作を受け取ります APIゲートウェイから 。実行が成功すると、それぞれのイベントをイベントストアに公開します。 。対照的に、すべての読み取り操作は読み取りモデルによって処理されます イベントストアから状態を取得します 。

CRMサービス （顧客関係管理サービス）はステートレスです。イベントストアからドメインイベントにサブスクライブし、メールサービスを使用して顧客にメールを送信します。 。

中央ドメインエンティティは注文です。次の図に示すように、ステートマシンを使用して遷移が実行される「ステータス」と呼ばれるフィールドがあります。

これらの移行は、ドメインイベント（SAGAパターン）にサブスクライブされているいくつかのイベントハンドラーで実行されます。例：

クライアント

クライアントは、Pythonのユニットテストフレームワークを使用してシミュレートされます。現在、10個の単体テストが実装されています。 tests / unit.pyをご覧ください 詳細については。

シンプルなUIがポート5000で提供され、イベントを監視し、状態を参照します（WebSocketを使用）。

RedisInsightコンテナーは、Redisインスタンスを検査するためにも使用できます。 Webブラウザを開いてhttp：// localhost：8001 /にアクセスし、 redis：6379を使用します テストデータベースに接続します。

結論

Redisは、ドメイン層（カタログ検索など）およびアプリケーション層（HTTPセッションストアなど）だけでなく、インフラストラクチャ層（イベントストアやメッセージキューなど）でも強力なツールです。これらのレイヤー全体でRedisを使用すると、運用上のオーバーヘッドが削減され、開発者はすでに知っているテクノロジーを再利用できます。

コードをのぞいて、実装してみてください。これが、ドメインおよびインフラストラクチャサービスにおけるRedisの多様性と柔軟性を実証し、キャッシングを超えてどのように使用できるかを証明するのに役立つことを願っています。

Twitterでどうなるか教えてください：@martinez099。