商品検索にキャッシュを追加する

AWSBeginner
オンラインで実践に進む

はじめに

商品アプリは毎回 DynamoDB からカタログを読み取ります。Valkey を実行する Amazon ElastiCache ノードを追加し、同じ商品の値を繰り返しのリクエストで再利用できるようにします。応答元と実際のソース読み取り数を比較して変化を確認します。

AWS Foundations for Beginners と AWS DynamoDB for Beginners の基本的な項目操作を先に学習してください。この独立した環境には商品アプリ、カタログ、ネットワーク設定が用意されています。Terminal でコマンドを実行し、AWS View で現在のノード、ソースレコード、アプリの応答を観察します。AWS CLI は設定済みで、個人の AWS アカウントや別のラボのリソースは不要です。

認定試験との関連

認定 試験タスク 実践
Cloud Practitioner (CLF-C02) Task 3.4 ElastiCache をメモリー内サービスとして認識し、キャッシュ値と DynamoDB の正本レコードを区別する。

このラボの概念図

商品のソースを観察する

このステップでは、キャッシュを使う前の商品アプリを観察します。キャッシュは再利用可能なデータをメモリーに保持します。データベースは引き続き正本です。キャッシュ値を失っても、カタログのレコードを失ってはいけません。まず、用意されたアプリの現在の動作を確認します。

プロジェクトディレクトリに移動し、設定済みの ID を確認します。

cd /home/labex/project
aws sts \
  get-caller-identity

ARN の末尾は labex-ca01-operator です。これから問い合わせるリソースの環境を識別します。

DynamoDB テーブルから商品 101 を直接読み取ります。DynamoDB は文字列を S、数値を N で表します。

aws dynamodb \
  get-item \
  --table-name product-catalog \
  --key '{"product_id":{"S":"101"}}' \
  --consistent-read

レコードは価格 20.00 の Travel mug を示します。別の商品 202 は独立した Notebook のレコードで、このラボでは変更しません。

用意された HTTP アプリは商品 JSON を返します。同じ商品を2回リクエストします。

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

どちらの応答にも "served_from":"source" があります。AWS View を開くとソース読み取り数が2増え、ElastiCache カードにはまだクラスターがありません。ソース読み取りは実際に DynamoDB に項目を要求したことを示し、AWS の請求額を測ったものではありません。

Send request コントロールも実際のアプリリクエストを送信するため、読み取り数を変えることがあります。例と異なる数になっても構いません。固定の最終数ではなく、数が増えるかどうかを比較します。 キャッシュ使用前の AWS View の例:リクエストはソースを読みます。読み取り数は異なる場合があります。

Valkey キャッシュノードを作成する

このステップでは、キャッシュノードを作成して接続します。Amazon ElastiCache はメモリー内キャッシュエンジンを管理します。Valkey はキーごとに値を保存し、ここでは商品 ID がキャッシュ商品を識別します。独立した単一ノードを使います。用意されたサブネットグループは準備済みのネットワーク配置を示し、セキュリティグループはそのネットワーク設定です。ネットワークルールの設計は VPC コースで扱います。

この新しい環境のネットワーク識別子を読みます。

cat resources.json

セキュリティグループ ID を保存して表示します。$(...) は次の操作に使うコマンド出力を保存します。

CACHE_GROUP_ID=$(jq -r .security_group_id resources.json)
echo "$CACHE_GROUP_ID"

小さな単一ノードキャッシュを作成します。product-cache はクラスターの識別子です。エンジンとノード数でこのコースの Valkey 構成を選びます。

aws elasticache \
  create-cache-cluster \
  --cache-cluster-id product-cache \
  --engine valkey \
  --engine-version 7.2 \
  --cache-node-type cache.t3.micro \
  --num-cache-nodes 1 \
  --cache-subnet-group-name product-cache-network \
  --security-group-ids "$CACHE_GROUP_ID"

CacheClusterStatus を観察します。ノードの詳細を問い合わせ、アプリが接続するアドレスとポートであるエンドポイントを取得します。

aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].{Status:CacheClusterStatus,Nodes:CacheNodes}'

クラスターが available でノード 0001 にエンドポイントがある状態で続けます。作成中なら少し待ち、同じ問い合わせを繰り返します。

実際のエンドポイントアドレスを保存して表示します。

CACHE_HOST=$(aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].CacheNodes[0].Endpoint.Address' \
  --output text)
echo "$CACHE_HOST"

用意された Valkey クライアントで実際の接続をテストします。

valkey-cli -h "$CACHE_HOST" -p 6379 PING

PONG はキャッシュエンジンの応答を証明しますが、商品アプリが使用していることまでは証明しません。AWS View に実際のノードとエンドポイントが表示されます。

アプリを接続してキャッシュヒットを観察する

このステップでは、アプリを設定して応答元を比較します。アプリは cache-aside を使い、最初にキャッシュで product:101 を探します。キーがない場合はミスで、DynamoDB を読み取って商品を保存します。後のヒットではソースを再読せず、そのキャッシュ値を返します。

app.json は通常のアプリ設定です。jq でモードとエンドポイントを変え、一時ファイルに書き込んで設定を置き換えます。

jq --arg host "$CACHE_HOST" \
  '.mode = "cache-aside" | .cache_host = $host' \
  app.json > app.next.json
mv app.next.json app.json

新しい設定を確認します。

cat app.json

アプリはリクエストごとに設定を読むため、再起動は不要です。ttl_seconds はキャッシュ値の存続時間です。次のラボで有効期限と鮮度を学びます。

商品 101 を1回リクエストします。

curl -sS http://127.0.0.1:8080/api/products/101

新しいキャッシュには値がないため、この初回リクエストは served_from: source を返します。AWS View でソース読み取り数を観察し、同じリクエストを繰り返します。

curl -sS http://127.0.0.1:8080/api/products/101

応答は同じ商品 ID、名前、価格で served_from: cache を返し、ソース読み取り数は増えません。先に AWS View でリクエストした場合、最初の Terminal リクエストからヒットすることがあります。キャッシュを埋めた後の連続した2つのリクエストを比較します。

Valkey クライアントで実際のキャッシュ値を読みます。

valkey-cli -h "$CACHE_HOST" -p 6379 GET product:101

JSON は Travel mug のソースレコードに対応します。この繰り返しの検索でソースアクセスが減ることを示しました。本番の遅延、容量、可用性を証明したものではありません。

最終確認のため、アプリとノードを稼働させたままにします。この独立した学習環境は使い捨てです。実際の AWS アカウントでは不要なキャッシュを削除して継続的なリソース料金を止めます。 接続後の AWS View の例:ソースを再読せず、同じ価格をキャッシュから返します。

まとめ

単一 Valkey ノードを作成し、用意された商品アプリを接続して cache-aside のミスとヒットを観察しました。キャッシュ JSON は DynamoDB の正本と一致し、繰り返しのヒットはソースの再読を避けました。次はソース変更と、TTL や明示的無効化による鮮度の維持を学びます。

詳しくは、AWS 公式ドキュメントを参照してください:キャッシュアサイドのデータフロー; キャッシュ接続エンドポイントを選択する。