超高速Amazon MemoryDB for RedisでステートフルなK8sアプリケーションを構築する

Pulisher : Mass Migration & DR Center イ・ミンギュ
Description：Amazon Memory DBを活用したマイクロサービスのアーキテクチャ構成の紹介セッション

はじめに

Amazon Memory Diviを活用したマイクロサービスについて、他の人はどのようにアーキテクチャを構成しているのかが気になって聞いてみました。

セッションの概要紹介

マイクロサービス構成でメモリDBとしてRedisを使用してメッセージブローカーとして使うという説明をしました。RedisをメモリDBですが、永続的な目的で使ってるので、メッセージブローカーの部分は新鮮でした。 なぜなら、用途自体がブローカーの役割ではないからです。

マイクロサービスは通常、1つのことを行うが、そのことを非常によく、かつ迅速に行い、それらは緩やかに結合され、お互いについてさえ知らないかもしれません。明示的な依存関係がなく、主な利点の一つはスケーラビリティです。

発表者はReidsをネットワーク上の共有メモリのように考えていました。

Primaryが記録と読み込みをし、Replicaは読み込みだけします。

しかし、100個のReplicaが存在し、クライアントに記録されたことを知らせると応答し、Replica同士が複製する前に失敗すると、データ損失が発生します。 そのため、リクエストに対する応答が返ってくるまではクライアントに絶対に応答しません。

メモリ割り当ては応答が速く、構造がシンプルで、スケーリングにも有利です。有効なデータ型を使用して特定のケースにも適しており、実際に遅延が発生する場合、ネットワークとメモリディビで発生するのではなく、ほとんどのアプリケーションで遅延が発生します。

マイクロサービス間の通信パイプラインアーキテクチャを確認することができます。
ワークショップ url: https://catalog.workshops.aws/microservices-with-memorydb/en-US
ワークショップを実行すると、Kubernetesがインストールされており、注文、商品アプリケーションが既にインストールされています。
お互いにメモリデビットをインターフェースとして使っています。

パイソン( order_worker.py )で作った注文担当者ファイルをビルドすると、ドッカーコンテナにイメージとして生成されます。

その後、ECRに認証のためにCLIを実行させ、ECRにpushをすると、注文担当者がインスタンスに配布されます。

注文申し込み – http POST ${ORDER_API}/orders quantity=11 id=YOUR_ITEM_ID

該当APIを要求して注文が正常に確認されます。

注文の確認 – http GET ${ORDER_API}/orders/YOUR_ORDER_PK

このAPIで注文を確認します。

Redisにロードされた内容を照会することができます。

セッションを終えて

Redis Streamというデータ構造を活用して大量のリクエストもRedisでキューのようにロードして処理できるようにしました。発表者はすでにこの構造は多くの実験を通じて証明されたそうです。

最後に、Redisのインストールも難しくないし、使い方が簡単なので、勉強としてローカルサーバーでテストしながらメッセージキューに適応してみるのも悪くないと思います。