並列I/OとHDF5

I/Oが律速になる構造 ── なぜ計算より書き出しが遅いのか

大規模シミュレーションでは、計算ノードの演算性能が伸び続ける一方、状態やチェックポイントを永続化するストレージ帯域はそれに追いつきません。数万プロセスが一斉に配列を書き出すと、律速は演算ではなくI/Oに移ります。並列I/Oの設計とは、この帯域とメタデータ処理という有限資源を、どうすれば連続した大きなアクセスに変換して使い切れるかという問題です。

横にスクロール

素朴な実装は2通りあります。1つは各プロセスが自分専用ファイルを持つN-to-N（file-per-process）。もう1つは全プロセスが1つの共有ファイルの別々の領域を書くN-to-1（shared-file）です。N-to-Nはファイル数がプロセス数まで膨れ、メタデータサーバーへの create/open が殺到してリスタート時のファイル列挙も遅くなります。N-to-1はファイル1個で済みますが、各プロセスの担当領域が論理的に飛び飛び（strided）で、素朴に書くと小さなアクセスが分散して帯域が出ません。ここを橋渡しするのがMPI-IOの集団I/Oです。

集団I/Oの核心 ── two-phase I/O

集団I/Oの代表実装がtwo-phase I/O（ROMIO実装の中核）です。各プロセスの書きたい領域がファイル上で飛び飛びでも、集団全体で見ればファイルのある区間を密に覆っていることに着目します。処理は名前の通り2フェーズです。

two-phase I/O（書き込みの場合）

フェーズ1: 通信フェーズ（redistribution）
  少数の「集約プロセス（aggregator）」を選ぶ
  ファイルを連続した領域（file domain）に分割し各集約プロセスへ割り当てる
  全プロセスは自分のデータを、担当する集約プロセスへMPIで送る
  → 集約プロセスのメモリ上に、ファイルオフセット順の連続バッファが組み上がる

フェーズ2: I/Oフェーズ
  各集約プロセスが、連続バッファをストライプ幅の大きな1回の書き込みで出す
  → ファイルシステムには「大きく連続したアクセス」だけが届く

要は、飛び飛びで小さいアクセスの集合を、ネットワーク上の再配置(redistribution)によって少数の連続した大アクセスへ組み替えます。ネットワーク帯域はストレージ帯域より広いことが多いため、この付け替えは割に合います。この再配置はMPIの集団通信と同じ発想で、全プロセス参加を前提に通信パターンを最適化している点が独立I/Oとの決定的な差です。

HDF5とNetCDF ── フォーマット層とMPI-IOの関係

MPI-IOはバイト列の並列アクセスを提供しますが、「配列の形・型・単位」といった意味は持ちません。ここを埋めるのがHDF5やNetCDFなどの自己記述フォーマットです。これらはファイル内にデータ本体と、それを解釈するメタデータ（次元・データ型・属性）を一緒に格納します。重要なのは、並列HDF5（PHDF5）やPnetCDFがMPI-IOの上に載る層であり、実際のバイト書き込みは下位のMPI-IOへ委譲する点です。

並列書き込みで最も事故が多いのがメタデータの扱いです。HDF5でデータセットを作成・拡張する操作（H5Dcreate、サイズ変更など）はファイル構造そのものを書き換えるため、全プロセスが同一の呼び出しに集団参加しなければなりません。一部プロセスだけが異なるデータセットを作る、あるいは片方だけがサイズ変更すると、各プロセスが持つファイル構造の認識がずれ、破損やデッドロックに直結します。データ本体の書き込みは各プロセスが別領域を担えますが、メタデータは全員で足並みを揃える、という非対称性が並列フォーマット層の鉄則です。

ストライピングとLustre/GPFS

並列I/Oの帯域は、最終的にファイルがどうストレージへ分散されるかで決まります。Lustreでは、1つのファイルは複数のOST（Object Storage Target、実体はディスク群）に分割配置されます。これを制御する主パラメータが2つあります。

• ストライプカウント（stripe count）: そのファイルを何台のOSTに分散させるか。カウントが大きいほど並列にアクセスできるディスクが増え、集約帯域が上がる。
• ストライプサイズ（stripe size）: 1つのOSTへ連続して書くブロックの大きさ。このサイズ単位でOSTをラウンドロビンに巡回する。

ストライピングの巡回（stripe count = 4 の例）

  ファイルの論理オフセット →
  [ stripe0 ][ stripe1 ][ stripe2 ][ stripe3 ][ stripe0 ][ stripe1 ]...
      OST0       OST1       OST2       OST3       OST0       OST1

  1本のOSTだけに全部載せる（count=1）と、そのOSTの帯域が上限になる
  count=4なら理想的には4台分の帯域を合算できる

ここでMPI-IOの集団I/Oとストライピングが噛み合います。two-phase I/Oの集約プロセス数をストライプカウントに合わせ、各集約プロセスの書き込み単位をストライプサイズの整数倍にそろえると、1回の書き込みが1台のOSTに連続して落ち、OST間の競合（同じOSTを複数プロセスが奪い合うロック競合）を避けられます。ROMIOのLustre向けドライバは、ヒント striping_factor（=stripe count）や cb_nodes（集約ノード数）を通じてこの整合を取ります。GPFS（IBM Storage Scale）も同様にブロックサイズ単位でのアクセス整合が帯域を左右し、思想は共通です。

I/Oボトルネックとチェックポイント設計

I/Oが律速かどうかは、Rooflineモデルと同じ発想で、供給可能なストレージ帯域と要求データ量の比から見積もれます。1ステップで書き出すデータ量をD、達成可能な集約帯域をBとすれば、書き込み時間はおよそ D/B で下限が決まり、これが計算時間より長ければ純然たるI/O律速です。ここを改善する主軸は「アクセスを連続化して実効帯域Bを上げる（集団I/O＋ストライピング整合）」と「書き出すDを減らす（圧縮・間引き）」の2方向になります。

チェックポイントはこの並列I/Oが最も重くのしかかる場面です。チェックポイント・リスタートの実効オーバーヘッドは、まさにここで論じた集団I/Oとストライピングの整合で決まります。書き込み中も計算を止めない非同期化や、ノードローカルNVMeを一次受けにする多階層化と組み合わせると、実効的な書き込み時間をさらに隠蔽できます。エクサスケール規模ではノード数に反比例して障害間隔が縮むため、チェックポイント頻度が上がり、並列I/Oの効率がシステム全体の稼働率を直接左右する一級の設計課題になります。

まとめ

• I/O律速の本質は、多数プロセスの小さく飛び飛びなアクセスを、いかに連続した大アクセスへ変換してストレージ帯域を使い切るかにある。
• MPI-IOの集団I/O（two-phase I/O）は、通信フェーズで少数の集約プロセスへデータを再配置し、I/Oフェーズでストライプ単位の連続書き込みに変えることで独立I/Oを大きく上回ることがある。
• HDF5/PnetCDFはMPI-IOの上の自己記述フォーマット層で、データ転送は独立/集団を選べるが、データセット生成や次元拡張といったメタデータ更新は必ず全プロセス集団で行う必要がある。
• Lustre/GPFSではストライプカウント・ストライプサイズがOSTへの分散を決め、集約プロセス数とストライプ数、書き込み単位とストライプサイズをそろえると帯域を最大化できる。この整合がチェックポイントの実効オーバーヘッドと大規模系の稼働率を左右する。