Diviを活用したマイクロサービスについて、他の人はどのようにアーキテクチャを構成しているのかが気になって聞いてみました。セッションの概要紹介マイクロサービス構成でメモリDBとしてRedisを使用してメッセージブローカーとして使うという説明をしました。RedisをメモリDBですが、永続的な目的で使ってるので、メッセージブローカーの部分は新鮮でした。用途自体がブローカーの役割ではないからです。マイクロサービスは通常、1つのことを行うが、そのことを非常によく、かつ迅速に行い、それらは緩やかに結合され、お互いについてさえ知らないかもしれません。明示的な依存関係がなく、主な利点の一つはスケーラビリティです。発表者はReidsをネットワーク上の共有メモリのように考えていました。Primaryが記録と読み込みをし、Replicaは読み込みだけします。100個のReplicaが存在し、クライアントに記録されたことを知らせると応答し、Replica同士が複製する前に失敗すると、データ損失が発生します。そのため、リクエストに対する応答が返ってくるまではクライアントに絶対に応答しません。メモリ割り当ては応答が速く、構造がシンプルで、スケーリングにも有利です。有効なデータ型を使用して特定のケースにも適しており、実際に遅延が発生する場合、ネットワークとメモリディビで発生するのではなく、ほとんどのアプリケーションで遅延が発生します。マイクロサービス間の通信パイプラインアーキテクチャを確認することができます。https://catalog.workshops.aws/microservices-with-memorydb/en-USワークショップを実行すると、Kubernetesがインストールされており、注文、商品アプリケーションが既にインストールされています。お互いにメモリデビットをインターフェースとして使っています。)で作った注文担当者ファイルをビルドすると、ドッカーコンテナにイメージとして生成されます。その後、ECRに認証のためにCLIを実行させ、ECRにpushをすると、注文担当者がインスタンスに配布されます。id=YOUR_ITEM_ID該当APIを要求して注文が正常に確認されます。${ORDER_API}/orders/YOUR_ORDER_PKこのAPIで注文を確認します。Redisにロードされた内容を照会することができます。Streamというデータ構造を活用して大量のリクエストもRedisでキューのようにロードして処理できるようにしました。発表者はすでにこの構造は多くの実験を通じて証明されたそうです。最後に、Redisのインストールも難しくないし、使い方が簡単なので、勉強としてローカルサーバーでテストしながらメッセージキューに適応してみるのも悪くないと思います。