キャッシュ障害時もアプリを動作させる

はじめに

任意のキャッシュが応答しなくなっても商品検索を利用できるようにします。現在の失敗を観察し、制限付きタイムアウトとソースへのフォールバックを設定して、キャッシュを復旧させヒットの再開を確認します。

「商品検索にキャッシュを追加する」を先に完了してください。この新しい環境には独立したアプリ、DynamoDB ソース、接続済み Valkey ノードが用意されています。Terminal で操作し、AWS View で実際の状態と応答を観察します。故障コントロールはこのラボのキャッシュプロセスだけを停止します。故障注入ツールの開発は不要です。

認定試験との関連

実際のキャッシュタイムアウトを観察する

このステップでは、正常な動作を確認してからキャッシュが応答しない状態を観察します。タイムアウトは応答を待つ時間を制限します。一時停止したプロセスには接続エンドポイントがありますが、要求には応答できません。キャッシュミスとは異なります。

ID と設定を確認します。

cd /home/labex/project
aws sts \
  get-caller-identity
cat app.json

ARN の末尾は labex-ca03-operator です。アプリは timeout_seconds: 2、fallback_on_error: false に設定されています。正常なキャッシュで商品 101 を2回リクエストします。

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

初回はソースを読み、次はキャッシュを使います。用意された故障を有効にします。

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"pause"}' \
  http://127.0.0.1:8080/api/fault

HTTP ステータスを含めて商品を要求します。

curl -sS -w '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8080/api/products/101

これは意図した失敗です。約2秒後に HTTP 503 と failure: TimeoutError を返しますが、データベースには商品が存在し得ます。キャッシュ障害がそのまま商品カタログ障害になるべきではありません。

待ち時間を制限してソースにフォールバックする

このステップでは、任意のキャッシュが失敗した際にアプリが DynamoDB を読めるようにします。フォールバックはキャッシュエラー後の意図した代替経路です。通常のミスはキャッシュ値がない状態にすぎません。

この制御された学習シナリオでは、0.2秒のタイムアウトとフォールバックを有効にします。

jq '.timeout_seconds = 0.2 | .fallback_on_error = true' \
  app.json > app.next.json
mv app.next.json app.json

キャッシュは停止したままにします。同じ商品を再度要求して経過時間を表示します。

curl -sS -w '\nHTTP %{http_code}; elapsed %{time_total}s\n' \
  http://127.0.0.1:8080/api/products/101

応答は HTTP 200 で、現在のソース価格 20.00、served_from: source、cache_error: TimeoutError を返します。制御されたキャッシュ待ちは約0.2秒です。停止中の各リクエストはソース読み取りを増やすため、フォールバックは機能を保護する一方でデータベース負荷を増やします。

AWS View で新しいタイムアウト、一時停止状態、読み取り数を比較します。この単一環境の計時は本番タイムアウト、負荷容量、AWS 可用性の保証を示しません。

キャッシュを復旧してヒットを再確認する

このステップでは、制御された障害を解除し、アプリがキャッシュを再び利用できることを確認します。正常なキャッシュ動作と成功したフォールバックは別の結果です。

用意されたキャッシュプロセスを再開します。

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"resume"}' \
  http://127.0.0.1:8080/api/fault

商品 101 を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: cache と cache_error: null を観察します。調査中に元の TTL が切れた場合、初回はソースからキーを再作成し、次の要求がヒットします。連続したヒットではソース読み取り数が増えません。

確認のため、キャッシュを再開した状態で制限付きフォールバック設定を維持します。実際のサービスでは、キャッシュエラーと障害時の追加ソーストラフィックを監視します。フォールバックは利用不能なソースデータベースを動作させることはできません。

まとめ

実際に停止したキャッシュのタイムアウトを観察し、制限付きフォールバックを有効にして、復旧後にヒットを再開しました。ミスとエラーには別の扱いが必要です。フォールバックはソースに基づく応答を維持し、停止中のデータベース作業を増やします。

詳しくは、AWS 公式ドキュメントを参照してください：ワークロードに応じてクライアントのタイムアウトを選ぶ。