キャッシュコヒーレンシーとは｜MSI/MESI・スヌーピング／ディレクトリ方式とフォールスシェアリング対策で学ぶ性能改善

キャッシュコヒーレンシーとは

キャッシュコヒーレンシー（cache coherence）とは、複数のプロセッサあるいはキャッシュ階層が同じメモリ位置（同じアドレス）をローカルに保持している場合に、それらのコピー間の整合性（整合した最新の値を保証すること）を保つ仕組みを指します。特にマルチコアCPUやマルチプロセッサシステム、分散キャッシュを用いるシステムで重要な課題です。

なぜ必要か

単一プロセッサ環境では主記憶（RAM）に対する読み書きの整合は比較的単純ですが、複数のコアが各自のキャッシュに同じデータを持ち、かついずれかが値を書き換えると、他のキャッシュにあるコピーは古いままになります。これを放置するとプログラムの正しさが失われます。キャッシュコヒーレンシーはこうした「同じアドレスに対する複数コピー」の不整合をリアルタイムで防ぎ、プログラムが期待する動作を保証するために必要です。

問題の具体例

例えば2つのコアが同一のフラグ変数flagをキャッシュしているとします。コアAがflagを1にセットしてコミットしても、コアBのキャッシュにあるflagが0のままであれば、コアBは古い状態を参照し続け、誤った判定をする可能性があります。共有データの更新が他のコピーに速やかに反映されないと、競合状態やデータ破壊が発生します。

コヒーレンシーとメモリコンシステンシーの違い

• コヒーレンシー：同一アドレスへの書き込みの見え方（同一アドレス間の一貫性）に関する性質。あるメモリアドレスに対するすべてのプロセッサから見た更新が、ある順序で一貫して見えること等を保証する。
• メモリコンシステンシー（メモリモデル）：複数アドレスにまたがる読み書きの順序性を含めた、全体としての可視性・順序性を定義する。例えば強い順序（sequential consistency）や弱い順序（relaxed consistency）など。

簡単に言うと、コヒーレンシーは「同じ場所」に関する保証、コンシステンシーは「複数の操作の順序」に関する保証です。両者は関連しますが別の概念です。

代表的なコヒーレンシープロトコル

キャッシュコヒーレンシーはハードウェア（あるいはソフトウェア）でプロトコルとして実装されます。代表的な方式を挙げます。

• スヌーピング（snooping）プロトコル：バス上のトランザクションを全てのプロセッサが監視（スヌープ）し、他キャッシュの状態を更新・無効化する方式。バスがブロードキャストできる小規模なマルチプロセッサに適している。
• ディレクトリ（directory）ベースのプロトコル：各メモリブロックに「どのキャッシュがコピーを持っているか」を管理するディレクトリを置き、必要なコマンド（無効化・転送）をディレクトリが仲介して行う方式。プロセッサ数やメモリ容量が大きくなるときにスケーラブル。
• 書き込み無効化（write-invalidate）方式：あるキャッシュがブロックを更新する際、他のキャッシュに対してそのブロックを無効化（invalidate）する。これにより更新を行ったキャッシュだけが有効な最新コピーを持つ。
• 書き込み更新（write-update / write-broadcast）方式：更新された値を他のキャッシュに直接送って全コピーを更新する方式。無効化に比べ即時整合を保てるが帯域を多く使う。

状態ベースのプロトコル（MSI / MESI / MOESI 等）

多くの実装は「キャッシュラインごとの状態」を管理します。代表的なのがMSIやMESIです。

• MSI：Modified（変更済み）、Shared（共有）、Invalid（無効）。変更があるとModifiedになり、それ以外のキャッシュはInvalidになる等の振る舞いをする。
• MESI：MSIにExclusive（排他）状態を追加したもの。Exclusiveはそのラインが唯一のコピーであり主記憶と同一であることを示す。多くの商用CPUはMESIやその派生を採用している。
• MOESI / MESIF等：さらにOwned（所有）やForwardなどの状態を追加し、書き戻しやキャッシュ間転送の効率を改善する派生プロトコルもある。

スケーラビリティとディレクトリ方式

スヌーピングはバスによるブロードキャストが前提のため、コア数が増えると帯域とレスポンスがボトルネックになります。大規模なマルチプロセッサや多ノード環境ではディレクトリ方式が用いられ、どのノードがブロックを保持しているかを追跡することで不要なブロードキャストを減らします。ただしディレクトリの管理・アクセスのための追加コストや複雑さがあります。

フォールスシェアリング（False Sharing）

フォールスシェアリングは、論理的には別々の変数を各スレッドが独立に更新しているにもかかわらず、それらが同じキャッシュライン上に配置されているためにコヒーレンシートラフィックが発生し性能が低下する現象です。対策としてはデータ構造の配置（パディングやアラインメント調整）、スレッド間アクセスの分離、アトミック操作やロックの適切な利用などがあります。

実装上の注意点とパフォーマンス影響

• コヒーレンシートラフィックは帯域とレイテンシを消費し、特に書き込み頻度が高い共有データに対して顕著に性能低下を招く。
• キャッシュライン粒度（通常64バイトなど）は設計上の鍵で、細粒度化すればフォールスシェアリングは減るが管理コストが増える。
• 省電力設計では不要なコヒーレンシー通知を抑える工夫が求められる。

プログラマ視点での対策

ソフトウェア側でできる対策も重要です。

• 共有データのアクセス頻度を下げる（スレッドローカル変数の活用）。
• データレイアウトを見直してフォールスシェアリングを避ける（パディング、構造体の分割）。
• 適切な同期（ロック、アトミック操作、メモリバリア）の使用。メモリモデルの理解が不可欠。
• アロケータやランタイムのチューニング。スレッド毎のヒープやアロケーション境界を工夫することも有効。

分散キャッシュにおける一貫性との違い

ここまで主にプロセッサ内／近傍のキャッシュについて述べましたが、分散システムやCDN、ウェブキャッシュでも「キャッシュの整合性（consistency）」問題があり、プロトコルや要件が異なります。分散キャッシュではスケールやネットワーク遅延を考慮し、厳密整合（強整合）ではなく最終的整合性（eventual consistency）を採るケースが多いです。更新通知（push/invalidate）、TTLベース、コールバック、リーシング（lease）など方式があります。

デバッグと計測

コヒーレンシー問題の検出は難しく、再現性が低いバグ（データレース等）を招きます。動的解析ツール、統計的プロファイラ、ハードウェアの性能カウンタ（キャッシュミス、コヒーレンス事件数）を利用してトラフィックホットスポットやフォールスシェアリングを特定します。またスレッド間の相互作用を可視化することで設計改善につなげます。

まとめ

キャッシュコヒーレンシーはマルチプロセッサ時代における基本的かつ重要な課題で、ハードウェアプロトコル（スヌーピング／ディレクトリ、MSI/MESIなど）とソフトウェア側の設計の両面で考慮する必要があります。性能上のボトルネックやデバッグ困難さを避けるため、データ配置・同期設計・アルゴリズムの見直しが重要です。さらに、分散システムではスケーラビリティのために異なる一貫性トレードオフが採られることを理解しておく必要があります。

参考文献

• Cache coherence — Wikipedia
• MESI protocol — Wikipedia
• A Primer on Memory Consistency and Cache Coherence — Daniel Sorin 等（講義資料/概要）
• “Cache Consistency” に関する古典的論文や教科書（Hennessy & Patterson の教科書も参照）
• False sharing — Wikipedia