**分散キャッシュは、複数のアプリケーションインスタンスがネットワーク越しにデータを再利用する仕組みです。**目的は高コスト処理の反復を避けることであり、鮮度と障害時のルールを明確にする必要があります。
3つのバックエンドが同じ商品カタログを読むとします。プロセス内キャッシュなら各インスタンスが自分のコピーを管理します。共有キャッシュサービスなら、1つが保存した値を他も使えます。キャッシュサービス自体が複数ノードで構成されることもあります。
データ生成コストと、どれだけ古い値を許容できるかから考えます。商品説明は短い遅延を許せても、購入時の最終在庫確認は正本が必要かもしれません。
テナント、言語、その他の関連入力を含め、結果全体を識別するキーを定めます。不十分だと、高速でも別の顧客のデータを返してしまいます。キャッシュ値は消えるため、永続的な業務記録の正本はデータベースに置きます。
一般的なcache-asideでは、アプリがキャッシュを調べ、なければDBを読み、TTLという有効期間を付けて結果を保存します。
Request -> Cache -> hit -> Return value
-> miss -> Database -> Fill cache -> Return value
多数の要求が同じ値を必要とするとき、DBの反復読み取りを減らせます。ただしネットワーク呼び出しと依存先が増えるため、省ける仕事がそのコストを上回る場合に有効です。Redisのcache-asideを参照してください。
カタログなら、DB更新をコミットしてからキャッシュの商品を無効化する方法が実用的な出発点です。次の読み手が再取得します。ただし競合は残ります。読み手がコミット前の古い値を取得し、無効化の後にキャッシュへ入れることがあるからです。
TTLはその新しく保存されたコピーの寿命を制限しますが、すべての読み取りが直ちに最新の書き込みを見る保証ではありません。古い権限、価格、残高が操作のルールを破るなら、正本で確認するか、明確な保証を持つバージョン対応の更新を設計します。Redisを使えば解決すると考えず、業務操作に合わせて整合性を選びます。
人気の値が期限切れになると、多数の呼び出しが同時にDBへ向かうことがあります。これがcache stampedeです。キャッシュ停止では、多数のキーで同じ問題が起きます。
これらの経路を意図的に試します。通常時の高いヒット率だけでは、キャッシュ喪失時の動作は分かりません。
シャーディングはキーを複数ノードに分け、レプリケーションは可用性や読み取り用のコピーを保持します。解決する問題は異なります。Redis Clusterはハッシュスロットで配置するため、ノード追加で1つのホットキーの仕事が自動分割されるわけではありません。Redis Cluster仕様を参照してください。
ヒット率、遅延、タイムアウト、メモリ、追い出し、DBへ流れる負荷を監視します。追い出しはメモリ管理のために値を削除する動作で、TTL前にも起きます。キャッシュを業務データやキュー内の仕事の永続保存保証として扱ってはいけません。
カタログでは、明確なキーのcache-aside、鮮度方針、保護された代替経路から始めます。分散で解ける容量問題が実測された場合にだけノードを増やします。良いキャッシュ設計は、値がある場合だけでなく、ない場合や誤っている場合も説明できます。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する