Cluster Networking (HPC RDMA)

解決する課題

HPC シミュレーションや大規模な AI モデル学習では、計算そのものよりもノード間の通信がボトルネックになりがちです。多数のサーバーが頻繁にデータを交換するため、ネットワークの遅延と帯域が全体の速度を左右します。通常の TCP/IP ネットワークでは、OS のネットワークスタックや CPU を経由するオーバーヘッドが大きく、こうしたワークロードの性能を引き出しきれません。Cluster Networking はこの課題を、RDMA を使った専用の高速ファブリックで解決します。

• 数百〜数千ノードで動く MPI ジョブや分散学習の通信遅延を最小化したい
• ノード間の All-Reduce / All-to-All 通信が重く、GPU やコアを遊ばせたくない
• TCP/IP のスタックや CPU コピーによるオーバーヘッドを回避したい
• 関係するインスタンスを物理的に近くに配置して、ノード間のホップを減らしたい
• スパコン級の密結合ワークロードを、クラウド上でオンデマンドに動かしたい

主要概念と用語

• Cluster Network（クラスタネットワーク）: RDMA 対応のインスタンス群を、低遅延・高帯域の専用ネットワークでまとめて起動・管理する単位。同一クラスタ内のノードは互いに近接配置される
• RDMA（Remote Direct Memory Access）: 相手ノードのメモリへ、OS や CPU を介さず直接読み書きする通信方式。カーネルのネットワークスタックを通らないため、遅延が小さく CPU 負荷も低い
• RoCE（RDMA over Converged Ethernet）: イーサネット上で RDMA を実現する技術。OCI のクラスタネットワークはこの方式の高速ファブリックを用いる
• クラスタネットワーク用シェイプ: RDMA をサポートする特定のベアメタルシェイプ（HPC 向けや GPU 向けの一部シェイプ）。これらのシェイプでのみクラスタネットワークを構成できる
• インスタンスプール / インスタンス構成: クラスタネットワーク内のノード群は、内部的にインスタンス構成をテンプレートとし、プールとして一括管理される
• MPI（Message Passing Interface）: 複数ノードにまたがる並列計算で標準的に使われる通信ライブラリ。RDMA ファブリック上で動かすことで真価を発揮する
• プレイスメント（近接配置）: 同一クラスタのノードを物理的に近いネットワーク位置へまとめて配置し、ホップ数と遅延を抑える仕組み

仕様・制限・クォータ

• クラスタネットワークは、RDMA 対応の特定シェイプ（HPC 向けや一部の GPU ベアメタルシェイプ）でのみ構成できる。汎用シェイプでは利用できない
• RDMA ファブリックは専用のネットワークインターフェースを使い、通常の VCN を介した TCP/IP 通信とは別系統で提供される。管理用の一般ネットワークと高速ファブリックは役割が分かれる
• 1つのクラスタネットワークは同一の可用性ドメイン内にノードを近接配置する。複数 AD にまたがった単一クラスタは想定しない
• ノードは同一シェイプ・同一構成でそろえるのが基本（密結合ジョブでは性能と挙動を均一にするため）
• クラスタネットワーク自体や RDMA ファブリックの利用に追加料金はかからず、課金対象は起動したベアメタルインスタンスやストレージなどのリソース
• 起動できるノード数や対象シェイプの在庫は、テナンシ/リージョン単位のサービス制限・クォータで管理され、大規模構成では引き上げ申請やキャパシティ確保が必要になることがある
• RDMA を活かすには、OS イメージや MPI ライブラリがファブリックに対応している必要がある（HPC/GPU 向けの対応イメージを使う）

内部の仕組み

クラスタネットワークは、指定したノード数ぶんの RDMA 対応ベアメタルインスタンスを、同一可用性ドメイン内の近接した位置へまとめて起動します。これにより、ノード間のネットワークホップが少なくなり、遅延が安定して小さくなります。各ノードは通常の VCN 経由の管理用ネットワークに加えて、RDMA 用の高速ファブリックへ接続されます。

RDMA では、アプリケーション（MPI など）が相手ノードのメモリへ直接アクセスでき、データ転送のたびに OS のネットワークスタックや CPU によるコピーを経由しません。これがカーネルバイパスと呼ばれる仕組みで、遅延の削減と CPU オーバーヘッドの低減につながります。結果として、All-Reduce のような集団通信が頻発する分散学習や HPC ジョブで、計算リソースを通信待ちで遊ばせにくくなります。

• ノード群は内部的にインスタンス構成＋プールとして扱われ、同一テンプレートから均一に起動される
• 高速ファブリックは TCP/IP とは独立した経路で、帯域と遅延の予測可能性が高い
• 近接配置により、ノードを増やしても通信特性のばらつきを抑えやすい

設計パターン / ベストプラクティス

• ノードは同一シェイプ・同一イメージでそろえ、密結合ジョブの性能と挙動を均一にする
• アプリケーションは RDMA／MPI 対応の通信ライブラリを使い、TCP/IP 経路に通信を逃がさない構成にする
• 大規模ジョブのデータ入出力には、高スループットの共有ストレージ（File Storage や並列ファイルシステム、Object Storage など）を組み合わせ、I/O が新たなボトルネックにならないようにする
• 起動・破棄を自動化し、ジョブのある間だけクラスタを立てて使い終えたら落とす運用でコストを抑える
• 大規模構成は事前にキャパシティとクォータを確認し、必要なら確保しておく
• ベンチマークで遅延と帯域、集団通信の性能を実測し、ノード数やシェイプ選定にフィードバックする

運用・監視

• クラスタネットワークやノードの状態は OCI コンソール/CLI で確認でき、各ノードのライフサイクル状態を追える
• メトリクスは OCI Monitoring で確認する。CPU/GPU 使用率に加え、ジョブが通信待ちになっていないか（計算リソースの遊び）を併せて見ると挙動を把握しやすい
• 性能が出ないときは、RDMA 経路が正しく使われているか（TCP/IP にフォールバックしていないか）、MPI/ドライバの対応状況、ノードの近接配置を順に確認する
• ノード単位の障害に備え、ジョブはチェックポイントを取り、途中から再開できるようにしておく(長時間の HPC/学習ジョブでは特に重要)
• ジョブ終了後はクラスタを破棄して不要なベアメタル課金を止める運用を徹底する

コスト

クラスタネットワークや RDMA ファブリックの機能自体に追加料金はかからず、課金対象は起動したベアメタルインスタンス（HPC/GPU シェイプ）・ストレージ・ネットワークなどのリソースです。HPC/GPU シェイプは単価が高くなりやすいため、コスト最適化の本質は「必要な期間だけクラスタを立てて、使い終えたら確実に落とす」ことにあります。

セキュリティ

• ノードへのアクセスはプライベートサブネットを基本とし、NSG / セキュリティリストで管理用ネットワークの境界を制御する
• ノードから OCI サービスへアクセスする際は、鍵のハードコードを避けインスタンスプリンシパルを利用する
• クラスタネットワークの作成・操作は IAM ポリシーで必要な範囲に限定する
• 計算データの入出力に使う共有ストレージのアクセス権を最小権限で設計し、ジョブ間でのデータ漏えいを防ぐ
• 利用イメージはパッチ適用済みの対応イメージを使い、ドライバや MPI ライブラリも含めてライフサイクルを管理する

関連サービス・比較

OCI の Cluster Networking は、AWS では EFA（Elastic Fabric Adapter） とクラスタープレイスメントグループの組み合わせに対応します。高速ファブリックによる低遅延通信と、ノードの近接配置という2つの要素をまとめて提供する点が特徴です。

ハンズオン / CLI例

典型的な流れは、まずインスタンス構成を作り、それを使ってクラスタネットワークを起動し、最後に状態を確認することです。以下は OCI CLI での骨子です（OCID やシェイプは環境に合わせて置き換えてください）。

# 1. RDMA 対応シェイプでインスタンス構成を作成（ノードの設計図）
#    詳細はJSONで指定（シェイプ・対応イメージ・サブネット等）
oci compute-management instance-configuration create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --display-name hpc-node-config \
  --instance-details file://instance-details.json

# 2. インスタンス構成からクラスタネットワークを起動（ノード数を指定）
oci compute-management cluster-network create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --display-name hpc-cluster \
  --instance-pools file://cluster-instance-pools.json \
  --placement-configuration file://placement.json

# 3. クラスタネットワークの状態とノード数を確認
oci compute-management cluster-network get \
  --cluster-network-id ocid1.clusternetwork.oc1..xxxxx \
  --query "data.{name:\"display-name\", state:\"lifecycle-state\"}" \
  --output table

# 4. ジョブが終わったらクラスタを破棄してベアメタル課金を止める
oci compute-management cluster-network terminate \
  --cluster-network-id ocid1.clusternetwork.oc1..xxxxx