キャッシュの一貫性を維持する3つの方法

```html

ラルフ・ウォルドー・エマーソンの言葉を信じるなら、「愚かな一貫性は小さな心の妖怪」ということになります。しかし、スケーラブルで成功するエンタープライズレベルのキャッシング戦略を実装するとなると、一貫性について「愚か」な部分は何ひとつありません。むしろ、エンタープライズデータベースの運用管理における最大の課題のひとつこそが、キャッシュの一貫性の維持なのです。

そもそも、なぜキャッシュを使うのか？

エンタープライズキャッシュの最大の利点は、データへのアクセスが高速かつ効率的であることです。プライマリデータベースへの呼び出しは、時間と処理能力の両面でコストがかかる一方、キャッシュへの呼び出しは瞬時に完了し、プライマリデータベースに一切の負荷をかけません。

キャッシュの一貫性を脅かす3つの障害

もちろん、こうした利点は「キャッシュ内のデータが常にソースデータと同じ値を保つ」という根本的な前提の上に成り立っています。単純な目標に思えますが、理論どおりにはいきません。実際には、以下の3つの落とし穴が存在します。

1. プライマリデータベースの変更がキャッシュに反映されないケース

キャッシュ経由のデータアクセスは、定義上、プライマリデータベース経由よりも高速です。そのため、特定のデータが要求されると、まずキャッシュが参照されます。この戦略は「キャッシュアサイドパターン」と呼ばれます。デフォルトでキャッシュが先にチェックされ、データが存在しなければ、アプリケーションがプライマリデータベースに問い合わせ、結果をユーザーへ返す過程でキャッシュにも格納します。

問題が生じるのは、プライマリデータベースのデータが変更されてから、キャッシュがその変更を反映するまでの「ギャップ」の間です。このギャップは、アプリケーションがキャッシュをチェックする頻度に左右されます。しかし、チェックのたびにプロセッサリソースを消費します。同じプロセッサは同時に多数の他の処理やトランザクションも担っており、中にはキャッシュ更新と同等以上に重要なものもあるのです。

課題は、更新チェックを頻繁すぎず、かつ疎かになりすぎない「ちょうど良い」バランスポイントを見つけることにあります。もちろん、このギャップの間にユーザーが古いデータへアクセスしてしまえば、その賭けは失敗に終わります。

2. キャッシュ済みデータの更新に遅延が発生するケース

この問題は前述のケースと一部重なります。プライマリデータベースで値が更新されるたびに、キャッシュに対して「変更値の更新または完全な削除」を指示するメッセージが送信されます（削除の場合、次回その値が要求されるとプライマリデータベースから取得され、以降はキャッシュから参照されます）。通常、この通信は比較的迅速に行われ、キャッシュの一貫性が維持されます。

しかしここでも、変更には処理能力と時間が必要です。遅延は、利用可能な処理速度とネットワークスループットの両方の影響を受けます。サーバーがキャッシュ更新メッセージを送信してから、キャッシュがそれを受信・処理するまでの間に、ユーザーが不幸にも古いデータへアクセスすると、結果として古いデータ、誤ったデータ、あるいはその両方が返される恐れがあります。

3. キャッシュノード間で不整合が生じるケース

当然ながら、Webサイトやアプリケーションの規模が大きくなるほど、キャッシュは単一ではなく複数のノードに分散保存される傾向があります。プライマリノードに加えて、理想的には同一データを保持する任意の数のレプリカノードが存在します。ロードバランシングとパフォーマンスの観点からは理にかなっています。

しかし、データ整合性の観点から見ると、これがキャッシュ不整合のもうひとつの要因となります。プライマリデータベースでデータが更新されるたびに、その変更をすべてのレプリカにも反映する必要があります。ノードの地理的な配置や数によっては、更新プロセスに相当な時間がかかることがあります。更新が進行中であっても、ユーザーがまだ変更未反映のノードへアクセスする可能性は十分にあり、その結果、再びキャッシュ不整合が発生しうるのです。

キャッシュ不整合がもたらすコスト

キャッシュデータベースには多くのメリットがある一方、キャッシュ不整合のリスクは最も顕著な欠点といえるでしょう。では、この問題はどれほど深刻なのでしょうか？結論から言えば、そのコストは状況次第です。

中には、大きな影響なしに発生する不整合もあります。たとえば、キャッシュ内の「いいね」の合計数がプライマリデータベースの実際の数と一時的にズレていても、短時間の不一致は問題を引き起こすことも、気づかれることすらほとんどないでしょう。

一方、キャッシュが特定商品の「残り1点」を在庫ありと表示しているのに、プライマリデータベース上の実際の在庫はゼロ——这样的な矛盾が起これば、顧客を混乱させ離反させ、ブランドの信頼性を損ない、会社の取引や会計に大混乱をもたらし、極端な場合には法的リスクにまで発展しかねません。

不整合に対抗する3つの方法

幸いなことに、上述したキャッシュ不整合の各要因には、それぞれ対応する解決策が存在します。

1. キャッシュ無効化（Cache Invalidation）

キャッシュ無効化では、プライマリデータベースで値が更新されるたびに、対応するキーを持つキャッシュアイテムが自動的に削除されます。「力技のアプローチ」と見られるかもしれませんが、利点は、コストと時間のかかる書き込みがプライマリデータベースへの1回だけで済み、2回以上発生しない点にあります。

2. ライトスルーキャッシング（Write-Through Caching）

この方式では、プライマリデータベースを更新してキャッシュを削除する代わりに、アプリケーションがまずキャッシュを更新し、その後キャッシュがプライマリデータベースを同期的に更新します。つまり、プライマリデータベース側に更新を委ねるのではなく、キャッシュ自身が一貫性の維持に責任を持ち、変更内容をプライマリデータベースへ伝達します。

3. ライトビハインドキャッシング（Write-Behind Caching）

残念ながら、「2回の書き込みがかえって問題を生む」こともあります。ライトスルー戦略の欠点は、キャッシュとプライマリデータベースの両方を更新するために、時間とプロセッサ負荷のかかる2回の書き込み（まずキャッシュへ、次にプライマリデータベースへ）が必要になることです。

ライトビハインドと呼ばれる別の戦略は、最初にキャッシュのみを更新し、プライマリデータベースの更新を後回しにすることでこの問題を回避します。もちろん、プライマリデータベースも更新する必要があり、早いに越したことはありませんが、ユーザーは2回の書き込みの「コスト」を負担せずに済みます。プライマリデータベースへの2回目の書き込みは非同期で舞台裏で（ゆえに「ライトビハインド」と呼ばれます）、パフォーマンスへの影響が少ないタイミングで実行されます。

Redis Enterpriseによる解決

キャッシュ無効化に加えて、ライトスルーおよびライトビハインドキャッシングは、キャッシュの一貫性実現に役立つ多くのシナリオに対応できます。しかし、答えを見つけることと、それを実際に実装することは別物です。

Redis Enterpriseのアクティブアクティブ型Geoレプリケーションは複数のプライマリを可能にし、増大し続ける負荷にも柔軟に対応できます。「アクティブアクティブ」とは、データベースの各インスタンスが任意のキーに対して読み取り・書き込みの両操作を受け入れられることを意味します。各データベースインスタンスは、どれほど地理的に離れていても、ネットワーク上の対等なピアです。任意のインスタンスに書き込みが発生すると、そのノードは自動的にネットワーク上の他のすべてのインスタンスへメッセージを送信し、変更内容を通知することで、全インスタンスが一貫したキャッシュデータを保持することを保証します。

さらに、Redis Enterprise独自のアクティブアクティブ型Geoレプリケーションは、キャッシュ不整合につながり得る書き込み競合に対処するために設計された高度なアルゴリズムを採用しています。これらのアルゴリズムは、競合のないレプリケートデータ型（CRDT：Conflict-free Replicated Data Types）に基づいており、複数のレプリカからの書き込みを、一貫性を効果的に維持する形でマージできることを保証します。

一貫性こそが成功の鍵

キャッシュの一貫性を維持する課題は、アーキテクチャの拡大とともに複雑さを増し、その重要性も高まっていきます。ビジネスに求められ、顧客が期待する一貫性を確実に提供するためには、エンタープライズレベルのキャッシングソリューションが不可欠です。

エマーソンにとって一貫性は「妖怪」だったかもしれませんが、エンタープライズレベルのデータベースキャッシングにおいては絶対に不可欠な要素です。だからこそ、Redis Enterpriseを選ぶのが賢明なのです。選ばないほうがよほど「愚か」といえるでしょう。

キャッシングの全体像については、Lee Atchison著『Caching at Scale with Redis』をご一読ください。