Caching Strategy

答え：A

要件は、

同一HTTPレスポンス
+
多数の利用者
+
許容できる古さ
+
オリジンリクエスト削減

CloudFrontでHTTPレスポンス自体をキャッシュすることで、キャッシュヒット時はALBやアプリケーションまでリクエストを送らず応答できます。

答え：C

CloudFrontでは、

レスポンスを変える値
→ キャッシュキーへ含める

レスポンスを変えない値
→ 不要ならキャッシュキーから除外

とします。不要な値でキャッシュキーを細分化すると、同じレスポンスが別々にキャッシュされ、ヒット率が低下します。

答え：B

これは、

遅延読み取り

が適するシナリオです。AとCはキャッシュを利用できますが、実際に参照されない商品までキャッシュするため、

人気商品だけを
必要になった時点でキャッシュしたい

という条件を外します。Dも低レイテンシーな読み取りは可能ですが、複数のアプリケーションインスタンスで共有するキャッシュではなく、それぞれが独立したコピーを保持する構成になります。

キャッシュヒット
→ ElastiCache

キャッシュミス
→ RDS
→ ElastiCacheへ保存

とする遅延読み取りが最も適切です。

答え：D

Aもインメモリキャッシュによる低レイテンシー化は可能ですが、別のキャッシュAPIとDynamoDBとの同期処理をアプリケーション側で実装する必要があります。Bはアクセスパターンを追加できますが、反復読み取りをマイクロ秒級のキャッシュから返す仕組みではありません。Cは整合性を強める選択であり、マイクロ秒級のキャッシュヒットを実現する方法ではありません。決定条件は、

DynamoDB
+
反復読み取り
+
結果整合性
+
マイクロ秒級レイテンシー
+
DynamoDB API互換性
+
アプリケーション変更の最小化

です。DynamoDB専用でDynamoDB互換APIを提供するDAXが最も適切です。

答え：B

DAXは強い整合性のある読み取りをDynamoDBへ渡し、その結果をキャッシュしません。したがって、

強い整合性のある読み取り

が必須なら、DAXのキャッシュヒットによる高速化を前提にできません。

答え：C

TTLは、

キャッシュヒット率
と
データ鮮度

のトレードオフです。許容できる古さを超えるTTLを設定してはいけません。また、更新直後から新しい値が必要ならキャッシュ無効化も組み合わせます。

答え：A

現在のCloudFrontでは、

Minimum TTL > 0

の場合、

no-cache
no-store
private

が存在してもMinimum TTLの期間はキャッシュされます。キャッシュしてはいけないレスポンスではCloudFront側のMinimum TTLも確認します。

答え：D

現在のCloudFrontでは、キャッシュタグによる無効化を使用できます。URLパスが異なる関連コンテンツへ共通タグを付けることで、

必要な関連オブジェクトだけ

をまとめて無効化できます。

答え：C

頻繁な静的ファイル更新では、

app-v41.js
↓
app-v42.js

のようなバージョン付きファイル名を利用できます。新しいURLになるため、CloudFrontや利用者側に古いURLのキャッシュが残っていても、新しいファイルを参照できます。

答え：B

DAXでは、

項目キャッシュ
と
クエリキャッシュ

は別です。項目更新によって既存のQuery結果が自動的に更新されるわけではありません。したがって、クエリ結果の許容鮮度に合わせてクエリキャッシュTTLを設計します。

答え：B / E

キャッシュヒットでは、有効なコピーを再利用することで元データソースへのアクセスを削減できます。キャッシュミス時にソースから取得し、次回の読み取りのためキャッシュする方式が遅延読み取りです。