翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 設計上の考慮事項
<a name="design"></a>

考慮すべきその他の設計ポイント:
+ **エラー処理**: 何らかの理由でキャッシュが使用できなくなった場合、アプリケーションはすべての項目がキャッシュミスであるかのように処理する必要があります。キャッシュレイヤーが存在すると、アプリケーションに脆弱性が加わることはありません。
+ **TTL**: すべてのキャッシュエントリに対して単一の TTL 値を設定したり、エントリ (、`query`、`scan`キャッシュなど) に応じて異なる TTL `get_item`値を使用したりできます。また、負のキャッシュエントリ (項目を返さないリクエスト) に対して異なる TTL 値を持つこともできます。
+ **消費キャパシティ**: キャッシュされたレスポンスを返す場合は、レスポンスの`ConsumedCapacity`メトリクスを調整して読み取り消費量がゼロであることを示すことをお勧めします。
+ **レスポンスメタデータの削除**: レスポンスの `ResponseMetadata`セクションも削除する必要があります。これにより、誰かが を表示`RequestId`し、実際には数時間前から最新であると考えるリスクを回避できます。
+ **キャッシュメタデータの追加**: レスポンスに`CacheMetadata`セクションを追加すると便利です。このセクションでは、値が保存された時間 (古さの測定に有用) と、値を保存したクライアントライブラリとバージョン (形式が変更されるバージョンから別のバージョンへのシームレスなアップグレードを実行する場合に役立つ場合があります) をレポートできます。
+ **テーブルスキーマの決定**: キャッシュ無効化の書き込みオペレーションからプライマリキーを決定するには、テーブルのスキーマを知る必要があります。この情報を取得するには、各テーブルの初回使用時 (1 回のみ) に ElastiCache で`describe_table`呼び出しと長期キャッシュを使用します。
+ **クライアントを構築する代わりに受け入れる**: コンストラクタ内の DynamoDB および Redis クライアントインスタンスを (渡されたパラメータに基づいてシム内に構築する代わりに) 受け入れる利点は、コンストラクタの呼び出し元が設定`read_from_replicas=True`すべきかどうかなどの詳細を決定できることです。
+ **名前空間機能**: すべてのキャッシュの読み取りと書き込みをその名前空間に分離するコンストラクタでオプションの名前空間をサポートすると便利です。名前空間の使用はテストに最適です。名前空間が異なる各実行は空のキャッシュで始まり、以前の実行による副作用がないように見えるためです。名前空間を変更するだけで、本番稼働環境の完全なキャッシュを 空にすることをシミュレートすることもできます。これは、各ルックアップキーにプレフィックスを自動的に追加することで実装できます。
+ **スキャンキャッシュ**: `scan`呼び出しをキャッシュするかどうかを知るのは困難です。1 回限りのフルテーブルスキャンを実行する場合、キャッシュに 2 回目に読み取らないスキャンデータの大きなページを埋める必要はありません。一方、多くのワークロードは、複数のダウンストリームコンシューマーに最新のフルテーブルデータを提供するために、特に小さなテーブルに対して繰り返しスキャンを実行します。1 つの侵害は、2 つの呼び出しを行い、各呼び出しの署名 (TTL 期間内) が同じであるシステムを実装して、結果のスキャンレスポンスをキャッシュすることです。これにより、1 回限りのフルテーブルスキャン中にキャッシュを埋めることなく、厳密なスキャンループを有効にしてキャッシュの利点を得ることができます。最初のスキャンでは、小さなプレースホルダーがキャッシュに配置され、リクエストが 1 回行われたものとしてマークされます。2 番目のスキャンでは、トークン値を実際のペイロードに置き換えます。このペイロードは最大 1 MB です。