Amazon ElastiCacheとキャッシュのシナリオ判断
商品情報や注文画面のキャッシュを例に、性能と正確さを同時に判断します。ヒット率の計算、更新漏れ、個人情報の分離、障害時のDB負荷を具体的な条件で確認します。
この単元で学ぶこと
- キャッシュの利用経路と更新漏れを調べる
- ヒット率と原本への負荷を条件付きで計算する
- 個別データ・障害・方式の制約を判断する
本文解説
1. 同じ検索を繰り返す 商品紹介ページが同じDB検索を大量に繰り返している場合、再利用可能な結果をElastiCacheへ置く方法を検討します。アプリが先にキャッシュを照会し、ミスなら原本を読む経路を作ります。作成後もDBへ直接全要求を送るままなら、期待した負荷軽減にはなりません。
2. 単純化した負荷計算 1000回の読取りのうち900回がヒットなら90%です。ここでミス一回につきDB読取り一回、他のDBアクセスはないという単純な条件なら、DB読取りは100回です。実際には更新や再試行、取得の集約等もあり得るため、この前提を外して常に同じ件数になるとは説明しません。
3. 価格変更の反映 DBで商品の価格を変更した後、キャッシュを更新せず長いTTLの値を返すと旧価格が出ます。更新時の削除・更新を見直し、キャッシュ反映が失敗した場合の再試行も考えます。単価表示と決済確定で許容する鮮度が違うなら、決済時は権威ある原本で確認するなど業務の条件を分けます。
4. 個人別のキー 利用者AとBの注文一覧をordersという共通キーへ入れると、別人の情報が返るおそれがあります。認可に加え利用者等を適切にキーへ含め、必要ならキャッシュ対象自体を見直します。転送時暗号化は盗聴対策であり、他人の内容を選ぶアプリの誤りを直すものではありません。
5. 期限の長短 変更の少ない公開説明文と在庫数を同じ長いTTLで扱うと、必要な鮮度を満たさない場合があります。短いTTLは再取得が増え、長いTTLは古い内容を再利用しやすくなります。更新通知や削除との組合せを含め、対象データの変化と利用者への影響から方針を選びます。
6. キャッシュ消失時 原本DBの前段として使うキャッシュを再起動・交換した後などにミスが増えると、DBへ多くの読取りが戻る可能性があります。原本の処理能力、再取得の集中、再試行回数を確認します。平常時にキャッシュが助けていた分を、障害時にもDBが受けられるか検証します。
7. 方式の機能を確認 現在のエンジンはValkey・Redis OSS・Memcachedで、Serverlessとノード型があります。複製、バックアップ、データ型、耐久性等は同じではありません。新しい耐久性機能を利用する案なら対応するエンジン・版・方式を確認し、単にElastiCacheという名称から利用可能と結論しません。
8. 改善の判定 ヒット率だけでなく応答時間、DB負荷、誤った値の有無、メモリや削除の状況、費用を比較します。高いヒット率でも旧価格や別人のデータを返していれば成功ではありません。必要な期限と更新のテストを実施し、採用した方式の障害と復旧も確認します。
図解
重要ポイント
- DB要求の算数は一ミス一読取り等の前提を付ける。
- 個人別情報を共通キーへ混ぜない。
- 消失時の再取得負荷を見積もる。
間違えやすい点
- ヒット率の改善だけで業務の正確さまで達成と考える。
- 一つの方式の耐久性機能を全方式へ当てはめる。
用語解説
- 再取得
- 使えるキャッシュがないとき原本から内容を読み直すこと。
- 鮮度
- 内容が現在の原本の状態をどの程度反映するか。
- 原本
- この構成で正しい状態の基準として扱うDBデータ。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。