Amazon ElastiCacheとキャッシュを理解する
ElastiCacheはインメモリのデータストアやキャッシュを管理するサービスです。DBの前段で繰り返す読取りを軽くする基本例から、更新時の整合性、期限、障害時の扱いを学びます。
この単元で学ぶこと
- キャッシュの役割と読取り手順を説明する
- 更新と期限の設計を比較する
- エンジン・運用方式・保護を区別する
本文解説
1. よく読む結果を再利用 商品一覧を表示するたびにDBへ同じ問合せを行う代わりに、結果をメモリ上のキャッシュから返す方法があります。ElastiCacheはその環境の構築・管理を軽減します。ここではDBを原本として前段にキャッシュを置く構成を中心に学び、キャッシュ導入でDBが自動的に不要になるとは考えません。
2. ヒットとミス 必要なキーの内容が使えればヒット、なければミスです。Lazy loadingではミス時にDBを読み、結果をキャッシュへ入れます。初回や期限切れ後はDBの処理が残ります。アプリがどこへ読みに行くかを実装・設定し、ElastiCache作成だけで全SQLが自動転送されるわけではありません。
3. 更新で古くなる DBの価格が変わっても、以前に保存したキャッシュの価格がそのままなら古い表示になります。DB変更時に対応キーを削除する、値を更新する、期限を設ける等の方針を選びます。どの程度の古さを業務が許容できるかを先に決め、DB更新とキャッシュの反映に失敗した場合も考えます。
4. 二つの入れ方 Lazy loadingは読まれたとき必要な内容を入れるので、未使用のデータを全て先に入れずに済みます。Write-throughは書込み時にDBとキャッシュを更新する考え方で、次の読取りに備えます。後者でも書込み負担や失敗処理があり、どの方法も全ての業務へ無条件に最良ではありません。
5. TTLとキー キャッシュのTTLは内容を期限付きで再利用するために使います。長ければヒットしやすい一方、更新が見えるまでの古さを考えます。キーには商品IDや言語等、応答を区別する必要な情報を含めます。利用者別の情報を一つの共通キーへ置くと他人の内容を返す危険があり、暗号化だけで識別の誤りは直りません。
6. エンジンを選ぶ 現行ElastiCacheはValkey、Redis OSS、Memcachedに対応します。キーと値を扱う共通点はありますが、データ構造、複製、障害切替え、バックアップ等の機能はエンジンと版・運用方式によって異なります。例えば並び付き集合のような機能を使いたい場合、対応するエンジンを確認します。
7. Serverlessとノード型 Serverlessは基盤ノードの詳細な構成管理を軽減し、需要に応じて調整します。ノード型では種類・台数・配置等を選びます。必要な互換性、性能、クォータ、料金を確認して方式を決めます。自動調整があっても、何をキャッシュしどう更新するかというアプリの判断は残ります。
8. 障害と耐久性 原本DBの前段キャッシュでは、消失やミス時に再取得する経路を用意します。現行には対応するValkeyノード型で耐久性を有効にする方式等もあり、全ElastiCacheに保存機能がないと一般化しません。採用方式の複製・復元・保持を確認します。耐久性があっても、古い値や誤った共有キーの問題を自動解消するものではありません。
図解
重要ポイント
- 作成だけでSQLの読取り先は変わらない。
- 更新とTTLは許容する鮮度から選ぶ。
- エンジンと運用方式で機能を確認する。
間違えやすい点
- 高ヒット率なら値も最新と考える。
- 全ElastiCacheが耐久性やバックアップに非対応と考える。
用語解説
- Lazy loading
- キャッシュミスのとき原本から取得してキャッシュへ入れる方法。
- Write-through
- 書込み時に原本とキャッシュを更新する考え方。
- キャッシュヒット率
- 対象要求のうちキャッシュを利用できた要求の割合。
- TTL
- キャッシュ内容を再利用する期限に関係する値。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。