設計上の考慮事項

エラー処理: 何らかの理由でキャッシュが使用できなくなった場合、アプリケーションはすべての項目がキャッシュミスであるかのように処理する必要があります。キャッシュレイヤーが存在すると、アプリケーションに脆弱性が加わることはありません。

TTL: すべてのキャッシュエントリに対して単一の TTL 値を設定することも、エントリに応じて異なる TTL 値 (、query、scanキャッシュなど) get_itemを使用することもできます。負のキャッシュエントリ (項目を返さないリクエスト) に対して異なる TTL 値を持つこともできます。

消費キャパシティ: キャッシュされたレスポンスを返すときは、レスポンスのConsumedCapacityメトリクスを調整して読み取り消費量がゼロであることを示すことをお勧めします。

レスポンスメタデータの削除: レスポンスの ResponseMetadataセクションも削除する必要があります。これにより、誰かが を表示RequestIdし、実際には数時間前からそれが最新であると考えるリスクを回避できます。

キャッシュメタデータの追加: レスポンスにCacheMetadataセクションを追加すると便利です。このセクションでは、値が保存された時間 (古さの測定に有用) と、値を保存したクライアントライブラリとバージョン (形式が変更されたバージョンから別のバージョンへのシームレスなアップグレードを実行する場合に役立つ場合があります) をレポートできます。

テーブルスキーマの決定: キャッシュ無効化の書き込みオペレーションからプライマリキーを決定するには、テーブルのスキーマを知る必要があります。この情報を取得するには、各テーブルの初回使用時 (1 回のみ) に ElastiCache でdescribe_table呼び出しと長期キャッシュを使用します。

クライアントを構築する代わりに受け入れる: コンストラクタ内の DynamoDB および Redis クライアントインスタンスを (渡されたパラメータに基づいてシム内に構築する代わりに) 受け入れる利点は、コンストラクタの呼び出し元が設定read_from_replicas=Trueすべきかどうかなどの詳細を決定できることです。

名前空間機能: すべてのキャッシュの読み取りと書き込みをその名前空間に分離するコンストラクタでオプションの名前空間をサポートすると便利です。名前空間の使用はテストに最適です。名前空間が異なる各実行は空のキャッシュで始まり、以前の実行による副作用がないように見えるためです。名前空間を変更するだけで、本番稼働環境の完全なキャッシュを空にすることをシミュレートすることもできます。これは、各ルックアップキーにプレフィックスを自動的に追加することで実装できます。

スキャンキャッシュ: scan呼び出しをキャッシュするかどうかを知るのは困難です。1 回限りのフルテーブルスキャンを実行する場合、キャッシュに 2 回目に読み取られないスキャンデータの大きなページを埋める必要はありません。一方、多くのワークロードは、複数のダウンストリームコンシューマーに最新のフルテーブルデータを提供するために、特に小さなテーブルに対して繰り返しスキャンを実行します。1 つの侵害は、2 つの呼び出しを行い、各呼び出しの署名 (TTL 期間内) が同じであるシステムを実装して、結果のスキャンレスポンスをキャッシュすることです。これにより、1 回限りのフルテーブルスキャン中にキャッシュを埋めることなく、厳密なスキャンループを有効にしてキャッシュの利点を得ることができます。最初のスキャンでは、小さなプレースホルダーをキャッシュに配置して、リクエストが一度行われたものとしてマークします。2 番目のスキャンでは、トークン値を実際のペイロードに置き換えます。このペイロードは最大 1 MB です。