エクサスケール計算の課題

エクサスケールの定義とスケールの断絶

エクサスケール計算とは、倍精度浮動小数点演算で毎秒10の18乗回（1 EFLOPS）以上を実行できるシステムを指します。2010年代後半、ペタスケール（10の15乗FLOPS）の1000倍という数字自体は単なる延長に見えますが、実際にはアーキテクチャの前提を作り替えるほどの断絶がありました。理由は、演算性能の指数関数的な伸びに対して、電力・データ移動・故障率という3つの制約が同じ比率では改善しなかったためです。

ペタスケール機は演算器を増やし周波数を上げることである程度延長できましたが、エクサスケール機を同じ延長線上で作ると、必要な電力が数ギガワット規模に達してしまい、施設として成立しません。したがって、エクサスケールの達成は「同じ設計をもっと大きくする」問題ではなく、演算1回あたりのエネルギーとデータ移動1回あたりのエネルギーを根本から作り直す問題として扱われました。

電力の壁がアーキテクチャに強制した制約

システム全体の電力予算は、実務上おおむね20〜30メガワット程度が上限とされてきました。これは半導体の/semiconductor/で扱われるパワーウォール（power wall、電力密度がダイの放熱限界に達する現象）とは似て非なる、施設規模の制約です。ダイ単体の発熱ではなく、システム全体の年間電力コストと冷却インフラが上限を決めます。

この予算制約から、消費エネルギーの内訳を見直す必要が生まれました。

1 FLOP あたりの消費エネルギー内訳（概念比較、ペタスケール世代の実測傾向）

  演算（浮動小数点乗算・加算）        : 数十 pJ/FLOP 程度
  オンチップのデータ移動（レジスタ〜キャッシュ）: 演算の数倍
  DRAM アクセス                        : 演算の数十〜百倍
  ノード間通信（ネットワーク越し）      : 演算の百〜千倍以上

  → 支配項は演算そのものではなく「データを動かすこと」

エクサFLOPS達成に必要な総電力を20〜30メガワット枠に収めるには、1FLOPあたりのエネルギーをペタスケール世代からおよそ1桁引き下げる必要がありました。演算器そのものの効率化には限界があるため、実際に効いたのはデータ移動を減らす設計判断です。具体的には、演算器あたりのメモリ帯域（バイト/FLOP比）を意図的に低く抑え、代わりにキャッシュ階層とオンチップネットワークを強化し、遠距離データ移動を最小化するアルゴリズム（後述の通信回避アルゴリズム）を前提にした点が挙げられます。

信頼性の壁 ── 故障が例外ではなく定常状態になる

2つ目の壁は、コンポーネント数の増大がもたらす信頼性の問題です。エクサスケール機は数百万個のコアと数万〜数十万個のノード、膨大な数のメモリモジュールと相互接続リンクで構成されます。個々の部品の平均故障間隔（MTBF、mean time between failures）がどれだけ長くても、部品数を掛け合わせるとシステム全体のMTBFは急激に短くなります。

システム全体の故障間隔の概算

  システムMTBF ≒ 個々の部品のMTBF / 部品総数

  例: 部品単体のMTBFが十分に長くても、部品数が数百万個規模になると
      システム全体では数時間〜1日程度の間隔で
      何らかのハードウェア故障が発生し得る

このため、エクサスケールでは「故障は例外的な事象」という前提そのものが成り立ちません。従来型の耐障害設計であるチェックポイント／リスタート（定期的に計算状態をディスクに保存し、故障時はその時点から再開する手法、/hpc-scientific-computing/checkpoint-restart-hpc-simulations/の主題）は依然として使われますが、システムMTBFがチェックポイント書き込み時間や再計算コストに対して相対的に短くなると、チェックポイントの間隔を狭めるほど有効な計算時間の割合（有効稼働率）が下がるというジレンマに陥ります。

有効稼働率の劣化構造

  チェックポイント間隔を短くする → 故障時の再計算ロスは減る
                                  → だがチェックポイント書き込みの
                                    オーバーヘッド頻度が増える

  チェックポイント間隔を長くする → 書き込みオーバーヘッドは減る
                                  → だが故障時に失われる計算量が増える

  → 最適な間隔はシステムMTBFとチェックポイント所要時間の
    積の平方根に比例する形で決まる（Youngの近似式に基づく考え方）

この構造的な限界から、エクサスケール世代ではチェックポイント／リスタートを補完・代替する技術として、演算中に冗長な検算を挟んで結果を検証するアルゴリズムベースの誤り耐性（algorithm-based fault tolerance）や、故障したノードの担当データを周辺ノードの情報から再構成する部分再計算、メモリのビット化けを検出訂正するECCの強化などが組み合わされるようになりました。単一の万能策ではなく、階層ごとに異なる耐障害機構を重ねる設計へ移行した点が特徴です。

並列度の壁と同期のコスト

3つ目の壁は、並列度そのものの引き上げが同期コストを増大させる問題です。エクサスケール機では数億スレッドのオーダーで同時実行を扱う必要があり、従来のBSP（bulk synchronous parallel、一括同期並列）モデル、すなわち「全プロセスが計算フェーズを終えてから一斉に通信・同期フェーズに入る」方式では、並列度の増加とともに次の問題が顕在化します。

• ロードインバランスの増幅: わずかなノード間の処理時間差でも、最も遅いプロセスに全体が引きずられる（ストラグラー問題）。プロセス数が増えるほど、最も遅い1つが現れる確率自体が上がる。
• 同期バリアの待ち時間: 全プロセスがバリア（barrier）に到達するまで待つ設計では、ハードウェアの微小なジッタ（実行時間のばらつき）が蓄積し、バリア到達を待つだけの時間が並列度に応じて増える。
• 通信の遅延隠蔽の欠如: 計算と通信を明確に分離するBSP型では、通信中は演算器が遊んでしまう。

これらに対応するため、ソフトウェアスタックは**非同期タスキング（asynchronous tasking）**モデルへの移行を進めました。これは、プログラムを「入力データが揃い次第実行できる細粒度タスク」の依存関係グラフとして表現し、ランタイムが利用可能なリソースにタスクを動的に割り当てる方式です。

非同期タスキングを支える実行モデルとしては、有向非巡回グラフ（DAG）でタスク依存を表現しランタイムがスケジューリングする方式（PaRSEC、Legion、Kokkosの一部機能など）や、MPIの上に非同期の片側通信（one-sided communication）やタスクベースAPIを重ねる方式が実用化されています。これにより、通信待ちで演算器が完全に停止する時間帯を減らし、電力の壁で抑えられた演算資源をより高い稼働率で使い切ることが狙いとなります。

ムーアの法則鈍化との関係

これら3つの壁が同時に効き始めた背景には、ムーアの法則の鈍化とDennardスケーリングの崩壊（/semiconductor/dennard-scaling/）があります。かつては同じ電力枠でトランジスタ数と周波数が世代ごとに伸び、演算性能はほぼ自動的に向上しました。しかし電圧スケーリングが下げ止まった後は、性能向上の手段がコア数増加、すなわち並列度の引き上げに限定されました。

これはエクサスケール計算にとって二重の負荷を意味します。1つは、コア数増加がそのまま前述の並列度の壁（同期コスト・ストラグラー問題）を増幅させること。もう1つは、演算器あたりのトランジスタ予算に対してメモリ帯域や相互接続の帯域を同じ比率で伸ばせず、演算とデータ移動のバランス（バイト/FLOP比）が悪化し続けることです。結果として、エクサスケール世代のソフトウェアは、ハードウェアが自動的に与えてくれる性能向上をあてにできず、通信回避アルゴリズム・非同期実行・混合精度演算といった明示的な最適化を積み重ねることで初めて性能目標に到達する構造になりました。

まとめ

• エクサスケール計算の実現を阻んだのは演算器の数ではなく、電力・信頼性・並列度という3つの壁であり、いずれも部品数の増大が非線形にコストを押し上げる構造を持つ。
• 電力の壁は、演算そのものよりデータ移動のエネルギーコストが支配的であるという事実から、バイト/FLOP比を抑えた設計と通信回避アルゴリズムを前提条件として要求した。
• 信頼性の壁は、システムMTBFが部品数に反比例して縮むためチェックポイント／リスタートだけでは有効稼働率を保てず、階層的な耐障害機構の併用を必要とした。
• 並列度の壁はBSP型の一括同期モデルの限界として現れ、ソフトウェアスタックを依存関係ベースの非同期タスキングへ移行させる圧力となった。
• ムーアの法則鈍化とDennardスケーリングの崩壊により性能向上の手段がコア数増加に限定されたことが、これら3つの壁を同時に深刻化させた根本要因である。