マルチユーザーNASの読み取りにおけるSSDリードキャッシュとディスク直接読み取りの比較：共有再利用によって優位性が変わるのはどんな場合か？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

SSD Read Cache vs Direct Disk for Multi-User NAS Reads: When Does Shared Reuse Change the Winner? - Zima Store Online

複数ユーザーが利用するNASでは、異なるクライアントが同じ頻繁にアクセスされるブロックを繰り返し要求し、それらのブロックがRAMに収まらなくなった場合、SSD読み取りキャッシュの価値が高まります。一方、ユーザーが主に異なるデータを読む場合、ワークロードがシーケンシャルな場合、またはHDDプールがクライアントネットワークの処理速度を上回ってリクエストを処理できる場合は、直接ディスクアクセスの方が適しています。

新たな判断材料となるのは、共有された再利用です。ユーザーが10人いるからといって、必ずしもキャッシュが有効になるわけではありません。10人がそれぞれ無関係なアーカイブを読めば、再利用可能なワーキングセットはほとんど生まれないでしょう。一方、3人の編集者が同じプロジェクト素材を繰り返し開けば、1つのキャッシュ済みコピーによって複数回のディスク読み取りを回避できます。人数ではなく、重複利用を測定してください。

SSDが評価されるには、共有された再利用がまずRAMキャッシュを超える必要がある

繰り返し読み取られるデータは、通常SSDキャッシュより先にRAMへアクセスされます。ZFSでは、ARCが主要な読み取りキャッシュで、L2ARCが2次的なSSD/NVMe層です。同じファイルを2人目のユーザーが開いたとき、データがメモリから出ていないにもかかわらず「SSD並みに高速」と見えることがあります。そのため、ウォーム状態での複数ユーザーテストでは、どの層がリクエストを処理したのかを特定する必要があります。

Klara Systemsの説明によると、L2ARCはARCから追い出されるブロックを格納し、アクティブなワーキングセットがRAMより大きく、なおかつRAMとL2ARCを合わせた容量には収まる場合に最も有効です。2026年のL2ARCのワーキングセット適合性に関する分析が示す、最初に確認すべき条件は明確です。SSDキャッシュが重要になるのは、メモリミスによって実際のバックエンド読み取りが発生してからです。

共有データに対してARCやOSのページキャッシュがすでに高いヒット率を実現しているなら、SSDキャッシュを追加しても、キャッシュメタデータのためにメモリを消費しながら、コピーをより低速な層へ移すだけかもしれません。その状態では、直接ディスクアクセスさえ真の競合相手ではありません。すでにRAMが勝っているからです。

複数ユーザーが有利になるのは、頻繁に使うデータが重複するときだけ

複数ユーザーによるアクセスがキャッシュの費用対効果を変えるのは、共有プロジェクトフォルダー、ソフトウェアパッケージ、VMテンプレート、サムネイル、インデックス、参照メディア、頻繁に閲覧されるチームディレクトリなど、共通データにリクエストが集中するときです。1つのSSDコピーで複数クライアントからの繰り返しアクセスを処理できれば、機械式ディスクのシークを減らし、混雑時のHDDキューを短縮できます。

Klaraのより広範なパフォーマンスチューニング指針では、ARCは再利用性と新しさのバランスを取るものと説明され、頻繁に再利用されるブロックは一度しかスキャンされないブロックとは異なる動作をするとされています。ここで重要なのは頻度を考慮したキャッシュ動作です。共有された再利用があれば、あるユーザーによって昇格されたブロックが、別のユーザーにとっても有用なまま残る可能性が高まります。

重複利用がなければ、ユーザー数は逆効果になることもあります。各家庭メンバーやワークステーションが別々のデータセットを読むと、合計ワーキングセットがより速く増大し、RAMとSSDキャッシュの両方で入れ替えが発生します。その結果、ユーザーが増えるほどヒット率が低下する可能性があります。問うべきなのは「接続されているクライアント数」ではなく、「共通して頻繁に使われるデータがどれだけあるか」です。

シーケンシャルスループットやネットワークが上限を決める場合は、直接ディスクが有利

大容量メディアの再生、バックアップの検証、一度きりのアーカイブスキャンは、シーケンシャル処理になることが多く、各ブロックに一度しかアクセスしない場合があります。正常な複数ディスクHDDプールなら、このようなトラフィックを効率的にストリーミングできますが、キャッシュにとっては将来の再利用がほとんどありません。2.5GbEや1GbEがすでに飽和している場合、同じ読み取りをSSDから提供しても、クライアントから見た完了時間は短縮されない可能性があります。

L2ARCのチューニング記事では、シーケンシャルプリフェッチによるトラフィックが常にL2ARCへ昇格されるとは限らず、書き込み中心のワークロードやキャッシュ階層よりはるかに大きいデータセットでは読み取りキャッシュが効果を発揮しにくいことも説明されています。そのため、キャッシュのベンチマークで小さなフォルダーを2回コピーするだけでは不十分です。その結果を数テラバイト規模のストリーミングに一般化してはいけません。

複数ユーザーのパターン	SSD読み取りキャッシュ	直接ディスク	有利になりやすい選択肢
複数ユーザーがRAMから追い出された同じ頻繁に使うファイルを再度開く	バックエンドのシークを削減できる	HDDの処理を繰り返す	ヒット率が安定するならSSDキャッシュ
ユーザーが無関係な大容量ファイルを一度だけ読む	再利用価値が低い	効率的なシーケンシャル処理	直接ディスク
共有データセットがRAMに収まる	追加効果がほとんどない	RAMによってほぼ回避される	どちらも増設せず、RAM経路を維持
クライアントネットワークが飽和している	体感速度が変わらない可能性がある	すでにリンク速度に追いついている	真の制約がネットワークなら、まずネットワークを改善
頻繁に使うデータを毎回予測可能な速度で読みたい	ウォームアップと追い出しの影響が残る	HDDが制約になると遅すぎる	専用SSD層を検討

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

キャッシュの入れ替えが激しいと、ユーザーを高速化せずにSSD層だけが忙しく見える

SSD読み取りキャッシュには、データの投入、インデックス作成、管理が必要です。合計ワーキングセットが継続的に変化すると、別のユーザーが再利用する前に有用なブロックが追い出される可能性があります。キャッシュデバイスが高いアクティビティを示していても、HDDプールが多くのミスを処理し続ける場合があります。そのため、SSDの使用率だけでは効果の証拠になりません。

2025年のTrueNASコミュニティスレッドでは、NASとProxmoxが混在するワークロードにおいて、ARCのヒット率は通常高かったものの、多数のVMが再起動するイベントなどで急激に低下し、その間にL2ARCがミスのかなりの割合を吸収した事例が紹介されています。この混合ワークロードにおけるキャッシュ事例は、普遍的な目標ヒット率ではなく、実際に起こり得る運用パターンの一例として参考になります。

キャッシュの入れ替えが継続的に発生し、メタデータのために貴重なRAMを消費する場合や、既知の頻繁に使うデータセットを専用SSDボリュームに置くのとほぼ同じコストがかかる場合、キャッシュの価値は失われます。キャッシュは適応型の配置であり、専用SSD層は明示的な配置です。自動昇格よりも予測可能なレイテンシーが重要な場合は、後者を使用してください。

1クライアントが1フォルダーを繰り返すのではなく、共有ワーキングセットをテストする

3つのデータセットを用意します。全クライアントが使用する共通の頻繁に使うデータセット、クライアントごとのプライベートデータセット、そしてシーケンシャルなアーカイブデータセットです。同じアクセススケジュールを、まずSSDキャッシュなしで、次にSSDキャッシュありで実行します。ARC/ページキャッシュのヒット、SSDキャッシュのヒット、HDDのIOPSとレイテンシー、ネットワーク使用率、クライアント応答時間のp95を記録してください。キャッシュは単に2回目の実行を高速化するのではなく、共通データセットに対するバックエンドディスクの処理を減らす必要があります。

ベンチマークのためだけに、本番環境のキャッシュを破壊的にフラッシュしないでください。使用可能なRAMより大きいテストデータセット、適切に管理された再起動、または通常の階層を通じて共通データセットを十分に移動させられる長時間の実行を利用します。ウォームアップ後の安定した挙動とコールド状態の挙動の両方を比較してください。ワークロードが終わるまでにウォームアップが完了しないキャッシュは、実用上の価値がほとんどありません。

既存のZimaSpace記事繰り返し読み取りにおけるキャッシュの一般的な判断では、単一ユーザーにおけるワーキングセットの境界を説明しています。今回のテストで加わる別の問いは、異なるユーザーが互いのキャッシュ済みブロックを、結果を変えるほど頻繁に実際に再利用するかどうかです。

キャッシュの有無を無理に二択にせず、3つの結果から選ぶ

共有ワーキングセットがRAMに収まらず、ユーザー間で繰り返し利用され、キャッシュ層に十分収まって安定したヒットを生み、キャッシュが有効なときにHDDのレイテンシーが低下するなら、SSD読み取りキャッシュを選びます。読み取りが主にシーケンシャルまたはプライベートで、プールがすでに目標レイテンシーを満たしている場合や、ネットワークが依然として体感上の上限になっている場合は、直接ディスクアクセスを維持してください。

頻繁に使うファイルをすぐに高速化する必要がある場合、頻繁に書き込まれる場合、または昇格と追い出しのポリシーに依存することが重要なデータにとってリスクとなる場合は、専用のSSDデータセットまたはボリュームを選びます。この第3の選択肢は、アクティブなVMディスク、データベース、コンテナの状態データ、または頻繁に使う範囲が明確なプロジェクトファイルに特に適しています。

有利な選択肢が変わるのは、共有された再利用、メモリミス、バックエンドディスクのレイテンシー、キャッシュヒットの安定性、ネットワークの余裕のいずれか、測定可能な条件が変わった場合だけです。これらのどれも変わらないなら、SSDキャッシュは管理対象となる別のデバイスにすぎません。複数ユーザー環境で規模を拡大することがキャッシュの機会を生むのは、再現性のある共有読み取りが生まれる場合だけです。