【ITニュース解説】The Working Set That Never Saturated

システムエンジニアを目指す皆さんにとって、コンピュータのメモリがどのように使われ、データがどのようにアクセスされるかは、システムの性能を理解し、設計する上で非常に重要な知識です。特に、大量のデータを扱う際には、「全てのデータが常にメインメモリに読み込まれている」という前提が崩れることがあります。今回紹介する記事は、まさにその前提に疑問を投げかけ、大規模なデータ構造（カウンタテーブル）をいかに効率的に扱うか、そしてその際に発生する様々な課題と発見について詳しく解説しています。

私たちのコンピュータは、プログラムが実行される際に必要なデータをメインメモリ（RAM）に読み込みます。しかし、データ量が非常に大きい場合、全てをRAMに載せることはできません。そこで、「ページング」という技術が使われます。これは、必要なデータの一部だけをRAMに読み込み、残りはより安価で大容量なストレージ（SSDやHDD）に置いておく仕組みです。データが必要になったら、その都度ストレージからRAMへ読み込むことで、限られたメモリを有効活用します。

この実験は、「カウンタテーブル」と呼ばれる、データ数を数えるためのランダムアクセス型のルックアップ構造を対象としています。従来の実験では、このテーブルのデータは全てRAMに常駐していると仮定されていました。しかし、Apple製のハードウェアで最新のAIモデル（Mixture-of-Experts、略してMoEモデル）を動かすサードパーティのランタイムが、モデルの中核部分だけをRAMに置き、専門家ごとのデータはSSDから必要な時に読み込むことで、高い効率とキャッシュヒット率を達成している事例を知り、この仮定が本当に正しいのか、疑問が持ち上がりました。もしカウンタテーブルも必要な部分だけをページングできるなら、もっと少ないRAMで動かせるのではないか、という発想です。

まず、この疑問を検証するため、カウンタテーブルをページング可能な形に再構築しました。具体的には、メモリマップ可能な固定サイズの配列としてデータが保存されるように変更しました。この際、最も重要なのは「正確性の保証」です。新しい仕組みが正しく動作し、計算結果が変わってしまわないよう、厳密なテストが行われました。何千回ものデータ検索と評価を行い、元の完全にメモリ上にあったテーブルと全く同じ結果が得られることを確認しました。これにより、新しいページング可能な構造が正しいことが保証され、性能評価の基盤が確立されました。

そして、最も重要な実験が始まりました。それは、実際にファイル内のデータを処理しながら、どのカウンタテーブルのページがメモリに読み込まれるかを観察することです。期待していたのは、しばらく処理を続けると、よく使うデータがメモリに残り、ワーキングセット（実際にメモリに滞在するデータの量）が安定する「飽和状態」が起こるだろう、というものでした。しかし、結果は驚くべきものでした。実験対象の8つのファイルのうち7つで、データ処理が進むにつれてワーキングセットが安定せず、むしろ増え続けることが判明したのです。セッションの最後の段階でも、さらに数メガバイトのデータがメモリに読み込まれていました。これは、「小さなメモリ量で全体の大規模なデータ構造を効率的に扱える」という当初の仮説が誤りであったことを示しています。キャッシュヒット率の測定でも、キャッシュサイズを増やしてもヒット率が特定の地点で頭打ちになることが確認され、ワーキングセットが飽和しないという結論を裏付けました。

なぜ、ワーキングセットは飽和しなかったのでしょうか。その原因は、「データの局所性（locality）」、つまり「よく使うデータが特定の狭い範囲に集中している」という概念に対する誤解にありました。確かに、プログラムコード自体には繰り返しが多いのですが、カウンタテーブルが使うのは「コンテキスト」と呼ばれる、文脈を示すデータです。この実験では、新しいコンテキストが予測以上に継続的に発生し続けるため、テーブル全体が幅広くアクセスされ続けることが分かりました。MoEモデルがSSDストリーミングで成功したのは、特定の「エキスパート」が多くのタスクで再利用されるような、明確な「再利用構造」があったためです。しかし、今回のカウンタテーブルにはそのような構造がなく、「コンテキストが繰り返されるか」が重要であり、「トークン（単語など）が繰り返されるか」ではない、という本質的な違いが明らかになりました。

ワーキングセットが飽和しないことが分かったとしても、ページング自体が無意味になるわけではありません。しかし、もしページングを採用するなら、ストレージからのデータ読み込み速度が性能に大きく影響します。そこで、当初仮定されていた「100マイクロ秒/リード」というSSDの読み込み速度が本当に正しいのか、実際に測定する実験が行われました。過去の実験ではこの数値が仮定だったため、今回のプロジェクトでは「誰も測っていない数値に結論を依存させない」という原則に基づき、厳密な測定が行われたのです。

測定の結果、実際のSSDからのランダムリード速度は、当初の仮定よりも遅いことが判明しました。例えば、4KBのデータ読み込みには178.7マイクロ秒かかります。これにより、1位置あたりの実際の処理コストは当初の計算よりも高くなりました。しかし、それでもコード補完機能が持つ全体的な処理時間予算（約10ミリ秒）と比較すると、ページングによる遅延は十分に許容範囲内であることが分かりました。つまり、この定性的な結論は変わらなかったのです。

この測定からは、さらにいくつかの重要な発見がありました。一つは、4KBページよりも16KBページの方が、1リードあたりのコストが低い（179マイクロ秒に対して139マイクロ秒）ということ。これは、ページングシステムを設計する際に、より大きなページサイズを利用する方が効率的であることを示唆しています。もう一つは、複数のスレッド（8スレッド）で並行してデータを読み込むと、実効的な読み込みレイテンシが約10倍も改善されること。これは、プリフェッチ（先読み）を行うページャーにとって、データ読み込み速度がボトルネックにならない可能性があることを示しています。

最終的な結論として、この実験は、大規模なカウンタテーブルのワーキングセットは容易には飽和せず、当初の期待ほど少ないメモリで効率的に動かすのは難しいことを示しました。しかし、ストレージからのデータ読み込み速度自体は、適切な設計（例えば、大きなページサイズやマルチスレッドによる並行読み込み）をすれば、システムのボトルネックにはならないことが分かりました。

この研究で得られた最も重要な教訓は、**「仮定を測定することの価値」**です。私たちはしばしば、過去の経験や一般的な知識に基づいてシステムを設計する上で多くの仮定を置きます。しかし、今回のケースのように、その仮定が実は楽観的であったり、問題の本質とは異なる要因に焦点を当てていたりすることがあります。実際に測定し、データを取ることで、何が本当に問題なのか、どこに最適化のポイントがあるのかが明確になります。システムエンジニアとして、設計段階での仮定が正しいかを常に検証し、問題の真の原因を探求する姿勢は、高品質なシステムを開発するために不可欠な能力だと言えるでしょう。

今回の実験には、データセットの規模、キャッシュポリシー、テーブルの配置方法など、いくつかの制限も存在します。例えば、今回は特定種類のデータセット（コードのみ）を対象としており、より大規模なデータや異なる種類のデータでは結果が変わる可能性もあります。また、キャッシュポリシー（LRU：最も長い間使われていないものを捨てる方式）や、データがメモリに配置される方法（挿入順）は、今回の結果にとって最悪のケースであった可能性も指摘されています。これらを改善することで、将来的に更なる効率向上が見込まれるかもしれません。しかし、データ構造をページング可能にすること自体にも、メモリ消費量の増加といったトレードオフが存在します。これらの知見は、複雑なシステム設計において常に考慮すべき要素であり、皆さんが将来、性能とリソースのバランスを最適化する際に役立つはずです。