> [!abstract] 概要(arXiv abstract の日本語訳) > 収束コンピューティング(converged computing)は、高性能計算(HPC)コミュニティとクラウドネイティブコミュニティの両方の利点を一つにまとめるものだ。実際、クラウドコンピューティングの経済的影響と、可搬性・柔軟性・管理容易性への要求は、それを重要であるだけでなく不可避なものにしている。この未開拓の領域を切り拓くには、技術面での革新だけでなく、協働とアイデア共有への取り組みも必要とされる。こうした目標を念頭に、本研究はまず、クラウドであれ HPC であれバッチワークフローを実行する上での中心的コンポーネント、すなわちワークロードマネージャに取り組む。クラウドにおいては、Kubernetes がこの種のバッチオーケストレーションのデファクトツールとなっている。HPC においては、次世代 HPC ワークロードマネージャである Flux Framework が類似の役割を担い、完全に階層的なリソース管理とグラフベースのスケジューリングを組み合わせて、インテリジェントなスケジューリングとジョブ管理を支えている。これらのマネージャの収束は、Flux を Kubernetes の内部に実装することを意味し、Kubernetes のスケジューラ自体に負荷をかけることなく印象的なスケールで動作する階層的なリソース管理とスケジューリングを可能にする。本論文は Flux Operator を紹介する——Kubernetes に容易にデプロイできる、オンデマンドの HPC ワークロードマネージャである。本稿では設計上の決定、両環境間のコンポーネントのマッピング、実験的な機能について詳述し、この領域における同等のオペレータである MPI Operator と性能を比較した実験結果を共有する。最後に、残された課題のレビューと、技術革新・協働のさらなる改善への期待を述べて議論を締めくくる。 ## 論文情報 - タイトル: The Flux Operator - 著者: Vanessa Sochat・Daniel Milroy([[Lawrence Livermore National Laboratory]])、Aldo Culquicondor・Antonio Ojea([[Google]]) - 媒体: arXiv プレプリント(compiled October 2, 2023) - 発表年: 2023 - arXiv ID: 2309.17420(cs.DC) - コード: [flux-framework/flux-operator](https://github.com/flux-framework/flux-operator)(Zenodo DOI: 10.5281/zenodo.8312253) - 謝辞に記載の資金提供: LLNL-LDRD Program(Project No. 22-ERD-041)、米国エネルギー省(DOE)契約 DE-AC52-07NA27344 のもと LLNL が実施 ## 概要 本論文は、HPC ワークロードマネージャ [[Flux Framework]] を Kubernetes 内部で稼働させる Kubernetes Operator「Flux Operator」を提案する。Kubernetes の Indexed Job を用いて 1 Pod = 1 ノードの Flux クラスタ(MiniCluster)をオンデマンドで構築し、状態保存・弾力性(elasticity)・オートスケーリング・マルチテナンシー・バースティング・ワークフロー統合という実験的機能を実装する。LAMMPS を用いた強スケーリング実験で [[MPI Operator]] と性能比較し、Flux Operator が総壁時間で優位であることを示す。(Source: [[.raw/papers/arxiv-2309.17420.txt]]) ## 問題設定 HPC コミュニティとクラウドコミュニティは、ワークフローの可搬性・柔軟性・自動化という共通のニーズを持つ一方、それぞれ異なるワークロードマネージャの慣習(HPC 側は Flux 等のグラフベース階層型リソースマネージャ、クラウド側は Kubernetes)で発展してきた。Kubernetes は「最も広く使われているコンテナオーケストレーションプラットフォーム」として 2023年6月時点で約74,000人のコントリビュータを抱え、Fortune 500 企業の70%以上で採用される一方、HPC の複雑な階層的リソース管理・グラフベーススケジューリングの要求を素の Kubernetes スケジューラは満たさない。本論文が扱う入力は「Kubernetes クラスタ上でカスタムリソース定義(MiniCluster CRD)としてユーザーが指定するクラスタサイズとアプリケーション」であり、出力は「Kubernetes 上で稼働する、完全な機能を持つ Flux HPC クラスタ」である。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §1 Introduction) ## 提案手法 ### アーキテクチャ: Kubernetes Operator としての設計 Flux Operator は、宣言的なカスタムリソース定義(CRD)「MiniCluster」を介してユーザーが望ましい状態(クラスタサイズ・実行するアプリケーション)を指定し、コントローラがその状態への調停(reconciliation)を繰り返し行う、標準的な Kubernetes Operator パターンに従う。ユーザーは Flux クラスタのセットアップやコンポーネント更新のオーケストレーションの詳細を意識する必要がない。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.1 Kubernetes Operators) [[Flux Framework]] は複数のプロジェクトから構成される「フレームワーク」であり、本論文は以下のコンポーネントを Table 1 として整理する。 **Table 1. Flux Framework Projects** | Project | Description | |---|---| | flux-core | core services(コアサービス) | | flux-pmix | OpenMPI v5+ をブートストラップする flux shell プラグイン | | flux-sched | Fluxion グラフベーススケジューラ | | flux-security | セキュリティコード | | flux-accounting | ユーザーの銀行勘定・アカウンティング | (Table 1. Flux Framework Projects. Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.2 Flux Framework) ### Flux MiniCluster: 1 Pod = 1 ノードのマッピング Flux は `hwloc`(portable hardware locality)ライブラリでホストのリソースを検出するため、1 つの物理ノードに複数 Pod が同居すると同一リソースを二重に検出してしまう。このため Flux Operator は「1 Pod = 1 物理ノード」というマッピングを厳守する設計を採る。当初はユーザーがクラウドインスタンスの上限ぎりぎりを指定するリソース仕様で実現していたが、後に Pod affinity/anti-affinity ルールによる自動化へ改善された。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.2.1 A Flux MiniCluster) クラスタ構築には Kubernetes の Indexed Job(2021年に batch working group が追加)を採用する。Indexed Job はバッチ方式でインデックス順に Pod を作成し、インデックス 0 が最後にクリーンアップされる特性を持つため、Flux Operator はインデックス 0 の Pod をリードブローカーとして扱い、クラスタのスケールアップ・ダウン([[#実験結果|§3.1]])でリードブローカーが誤って削除されるリスクを避ける設計にしている。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.2.1) ### ネットワーキング: ツリー型オーバーレイネットワーク(TBON) Flux Framework の基盤コンポーネントの一つが、スケーラブルなツリー型オーバーレイネットワーク「TBON」である。TBON はリーダー・フォロワー(broker)からなる有根木であり、各ブローカーは通常 1 ノードにマッピングされる。インデックス 0 がリードブローカー、1〜N がフォロワーブローカーとなる設計は、Indexed Job が最小インデックスから順に Pod を作成する挙動と自然に整合し、フォロワーがリードブローカーを見つけやすくする。初期のネットワーキングは ZeroMQ で行われ、フォロワーは共有システム設定ファイル内の自身のランクに基づきリードブローカーへ TCP 接続する。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.2.1 Networking) 初期実装では Pod 作成後に IP アドレスを取得し `/etc/hosts` へ書き込んでいたが、これは全 Pod の再起動を要するため設計として不適切だった。後の設計では MiniCluster 向けの headless service を作成し、各 Pod にラベルを付けることで headless service に発見させ、予測可能なホスト名を割り当てる方式へ改善した。MPI を使うワークフローでは、Flux は組み込みの MPI・通信モジュールを持ち、標準の MPI ライブラリが高速なインターコネクトに依存できるようにする。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.2.1 Networking) ### Volume Mounts と Flux コンテナ Flux は システム設定ファイル・通信暗号化用の ZeroMQ CURVE 証明書・ブローカー起動手段を必要とする。Kubernetes 環境ではこれらを ConfigMap 経由のボリュームマウントとして `/etc/flux` と `/flux_operator` に配置する。CURVE 証明書のブートストラップは当初「一回限りの証明書生成用コンテナを立ち上げてログから証明書を回収する」という迂遠な方法だったが、KubeCon Amsterdam '23 での共同作業後、ZeroMQ を Flux Operator 自体に直接コンパイルし `cgo` 経由で証明書内容を生成する方式へ改善された。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.2.1 Volume Mounts) Flux 用コンテナは、Flux 本体・必要モジュールに加えてユーザーが実行したいアプリケーションも事前に組み込んでビルドされる必要がある。著者らはこれを「設計上の欠陥」と認め、HPC 向けにビルドされた既存コンテナの多くが Flux 抜きで構築されているため再ビルドが必要になる課題を指摘する。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §2.2.1 A Flux Container) ### 実験的機能 - **状態保存(§3.1)**: 実行中のジョブキューを一時停止し、状態を共有ボリュームへアーカイブし、別サイズの新しい MiniCluster へロードして再開する試みである。ジョブ完了後の保存では成功したが、実行中のキューを止めて保存する場合は 1〜2 ジョブが転送中に失われることが観察された(全体の約9割は正常に移行)。原因分析は本論文のスコープ外とされる。 - **弾力性(elasticity, §3.2)**: Flux 自体はリソースの動的変更をネイティブサポートしないため、システム設定ファイルに実際より多い最大ノード数をあらかじめ定義しておき、CRD の変更に応じて Indexed Job のサイズを増減させる「ハック」を用いる。ノード削減時は大きいインデックスから終了し、リードブローカー(インデックス0)は size 0 への削減が許可されないため常に保護される。この機能には Kubernetes 1.27 以上が必要。 - **オートスケーリング(§3.3)**: 当初は標準の HorizontalPodAutoscaler(CPU 使用率ベース)を試したが、Flux のニーズに十分な粒度を提供できなかった。代わりにリードブローカー Pod から直接動くカスタムメトリクス API「flux-metrics-api」を実装し、キューの内容に基づくスケーリング判断を可能にした。 - **マルチテナンシー(§3.4)**: 単一ユーザー・PAM 認証による複数ユーザー・RESTful API アクセスによる複数ユーザーの3モードを提供する。RESTful API は OAuth2 ベースの認証(base64 エンコードのユーザー名/パスワードによる Basic 認証 → 期限付きトークン)を用い、`flux-accounting` によるフェアシェアアルゴリズムでジョブ優先度を決定できる。 - **バースティング(§3.5)**: ローカルクラスタの拡張にとどまらず外部リソースへワークを拡張する仕組み。ジョブに `burstable` 属性が付くと、バーストサービスがプラグイン(GKE・EKS・CE・ローカルの4種類を実装)経由でバースト可能性を判定し、満たせれば新しいクラスタを作成またはジョブを割り当てる。プライマリクラスタのリードブローカーを NodePort サービスとして外部公開し、外部クラスタのフォロワーブローカーが接続する設計を採る。 - **ワークフロー統合(§3.6)**: KubeCon Amsterdam '23 後、共同研究者が MiniCluster を Kubernetes ネイティブのジョブ投入オペレータ [[Kueue]] のジョブ種別として統合した。同様に Snakemake ワークフローツールへの Kueue executor プラグインとしての統合も進められている。 (Source: [[.raw/papers/arxiv-2309.17420.txt]] §3 Features) ## 新規性 既存の HPC ワークフロー統合は、ワークフローツールから Flux を実行ツール(executor)として呼び出す方式([101,102,103])にとどまり、複雑で異種構成のワークフローが要求する「異なるサイズ・構成の MiniCluster を組み合わせる」機能を提供しない。また比較対象の [[MPI Operator]] は SSH でワーカーを協調させ、ワーカー協調専用の追加ランチャーノードを常に必要とする設計であるのに対し、Flux Operator はリードブローカー自身がクラスタの一部として動作し、追加ノードのコストを要しない。さらに Flux はグラフベース・階層的リソース管理を用いる点で、実行可能性スコアに基づく Kubernetes デフォルトスケジューラとは根本的に異なるアプローチを取り、先行研究([[トポロジ考慮型スケジューリング|Fluence]], [22, 23])が示した「Kubernetes デフォルトスケジューラ比での性能改善」を Operator として実装レベルまで具体化したものである。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §1, §4.1 Methods) ## 実験設定 - **環境**: Amazon Web Services Elastic Kubernetes Engine(EKS)、`hpc6a.48xlarge` インスタンスタイプ、Elastic Fiber Adapter(EFA)による高速インターコネクト。 - **ベンチマーク**: LAMMPS(Large-scale Atomic/Molecular Massively Parallel Simulator)。CORAL-2(Collaboration of Oak Ridge, Argonne, and Livermore)のスケーラブルな科学ベンチマークとして採用。問題サイズ 64x16x16 の分子シミュレーションで強スケーリング構成をテスト。 - **比較対象**: [[MPI Operator]](Kubeflow プロジェクト発の「MPIJob」カスタムリソース。実験時点で MPI ワークロード実行の主要選択肢とされていた)。100 MPI ランク超へスケールできるよう改変版([22])を使用。 - **クラスタサイズ**: 64/6016、32/3008、16/1504、8/752(ノード数/MPI ランク数)。MPI Operator は追加のランチャーノードが必要なため、実験全体のベースクラスタは size 65 に設定。 - **評価指標**: (1) LAMMPS が報告する総壁時間(total wall time)、(2) ランチャー時間(Flux の `flux submit` vs MPI の `mpirun` のコマンド実行時間)、(3) クラスタの作成・削除時間(MiniCluster 総ランタイムから LAMMPS 総壁時間を引いた値)。 - **手順**: サイズ 65 の共通 Kubernetes クラスタを作成し、Flux Operator・MPI Operator それぞれについて、サイズ 64/32/16/8 の MiniCluster/Job を作成し LAMMPS を20回実行、タイミングと全設定・ログを記録。各実験の前に「使い捨て」実行を1回行いコンテナイメージをノードへキャッシュしてから計測することで、イメージプルのばらつきを計測対象から除外。オーケストレーションには実験ツール Flux Cloud を使用。 (Source: [[.raw/papers/arxiv-2309.17420.txt]] §4.1 Methods) ## 実験結果 ### クラスタ作成・削除時間 20 回ずつ×4サイズ(8/16/32/64)でクラスタの作成・削除を行った結果、ノード数に対する弱線形スケーリングが観察された(Figure 2)。いずれのサイズも 1 分未満・変動約 5 秒の範囲で完了しており、著者らはこれを「予想より良好」な結果としている。MPI Operator の設計上、比較可能な作成時間の指標は存在しなかったため、この指標は Flux Operator 単独の結果として報告される。 **Figure 1: Flux Operator と MPI Operator を比較する実験設計** ![[_attachments/arxiv-2309.17420/fig01-experiment-design.png]] (Figure 1. サイズ 65 の単一 Kubernetes クラスタ(青枠)を作成し、そこから 64 pod(6016 ランク)・32 pod(3008 ランク)・16 pod(1504 ランク)・8 pod(752 ランク)というより小さいクラスタサイズを段階的に切り出してテストする。MPI Operator のランチャー用に追加ノード(青)が、実作業を行うノード(緑)に加えて必要となる。Source: [[.raw/papers/arxiv-2309.17420.txt]] Figure 1) **Figure 2: MiniCluster 作成・削除時間の合計** ![[_attachments/arxiv-2309.17420/fig02-minicluster-creation-deletion-time.png]] (Figure 2. MPI ランク 752/1504/3008/6016(クラスタサイズ 8/16/32/64 ノードに対応)にわたる Flux MiniCluster の作成・削除時間の合計。AWS 上で hpc6a.48xlarge インスタンスタイプと Elastic Fiber Adapter を用いて実行。中央値は約47〜53秒の範囲に収まり、外れ値を除けば分布は比較的タイトである。Source: [[.raw/papers/arxiv-2309.17420.txt]] Figure 2) ### LAMMPS 総壁時間 Flux Operator は MPI Operator に対して一貫して優れた性能を示し、平均約5%高速だった(Figure 3)。差自体は小さいが、著者らはこの改善がより長時間の実験ではより顕著になり、総コストの削減につながりうると述べる。改善の根本原因の特定はパフォーマンスツールを用いた将来の調査課題とされる。 **Figure 3: LAMMPS 総壁時間の比較** ![[_attachments/arxiv-2309.17420/fig03-lammps-wall-time.png]] (Figure 3. LAMMPS ソフトウェア自身が報告する総壁時間の、Flux Operator(赤)と MPI Operator(黄)の比較。752 ランクでは Flux Operator の中央値が約73.5秒、MPI Operator が約76.5秒。6016 ランクでは Flux Operator が約18.5秒、MPI Operator が約20秒。全サイズで Flux Operator が一貫して高速。Source: [[.raw/papers/arxiv-2309.17420.txt]] Figure 3) ### ランチャー時間 `flux submit`(Flux Operator)と `mpirun`(MPI Operator)を比較すると、総壁時間よりもやや大きな差が見られた(Supplementary Figure 5)。両者とも強スケーリングの下で時間は減少するが、より大規模なスケールで MPI Operator に性能の頭打ち(inflection point)が生じるかは、実験時点でのリソース制約により未検証のまま将来課題として残された。 **Figure 5(Supplementary): エンドツーエンドの壁時間(flux submit vs mpirun)** ![[_attachments/arxiv-2309.17420/fig05-launcher-time-supplementary.png]] (Supplementary Figure 5. flux submit(Flux Operator)または mpirun(MPI Operator)を計測したランチャー起動時間。両者とも強スケーリングの下で単調に減少するが、Flux Operator が全サイズで一貫して高速(例: 752 ランクで Flux Operator 中央値約80秒 vs MPI Operator 約84秒、6016 ランクで約26.5秒 vs 約30秒)。Source: [[.raw/papers/arxiv-2309.17420.txt]] Figure 5) ### 実験設計上の考慮事項(Design Considerations) 著者らは、Kubernetes Operator を用いた実験を計画する際に考慮すべき時間の内訳を可視化する(Figure 4)。単一クラスタでオートスケーリングを使わない場合、クラスタ作成・コントロールプレーン準備・Operator インストール・コンテナプルの多くは一回限りのコスト(青)である。一方オートスケーリングを行うクラスタでは、新規ノードのプロビジョニングとコンテナプルが繰り返しのコスト(緑)へ転じる——ユーザーは新規ノード追加のたびに待機(かつ課金)を強いられることになる。さらにバースティングを伴うオートスケーリング構成では、新しいクラスタ自体の作成・削除にかかる追加時間も考慮が必要になる。 **Figure 4: Kubernetes Operator を用いた実験で考慮すべき時間内訳** ![[_attachments/arxiv-2309.17420/fig04-experiment-cost-timeline.png]] (Figure 4. 単一クラスタ実験(オートスケーリングなし、左)とオートスケーリング実験(右)における、クラスタ作成からクラスタ削除までの各ステップの時間コストの分類。青は一回限りのコスト、緑は繰り返しのコスト。オートスケーリングでは Control Plane / Nodes Ready と Operator Install 以降のステップが繰り返しコスト化する。Source: [[.raw/papers/arxiv-2309.17420.txt]] Figure 4) ## 考察 本論文は、収束コンピューティング(converged computing)——HPC とクラウドの技術的収束——を推進する具体例として Flux Operator を位置づける。Flux を Kubernetes 内部で稼働させる利点として、(1) Flux へのジョブ投入が Kubernetes API・etcd に負荷をかけず、数十万〜数百万ジョブへスケール可能であること、(2) Flux の階層的なリソース割り当てが、Kubernetes kubelet の(手動 vs 自動化の間で揺れる)バインディング判断に対し、より意図的な制御を Flux 側へ委譲できることを挙げる。一方、著者らはこれらの実験が単一のクラウド・単一のネットワークファブリック・インスタンスタイプ・最大64ノードという小規模スケールに限定されていることを明示し、大規模言語モデル学習のような近年のスケール要求がより大規模な実験を正当化しうると指摘する。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §5 Discussion, §6 Conclusion) 技術面に加え、著者らは HPC とクラウドコミュニティ間の「文化とコミュニケーション」を過小評価されがちな課題として強調する。「ノード」や「スケジューラ」のような基本用語が両コミュニティで異なる意味を持ちうること、学術グループが論文を書く一方で産業グループがそうしない傾向が研究成果の共有を非対称にすることを指摘し、双方が歩み寄る場(カンファレンス・ブログ等)の必要性を訴える。(Source: [[.raw/papers/arxiv-2309.17420.txt]] §5 Discussion) ## 強み / 弱点・課題 **強み** - LAMMPS を用いた実測ベンチマークで MPI Operator に対する定量的な優位性(総壁時間・ランチャー時間とも)を示した。 - Kubernetes ネイティブな Indexed Job・headless service・ConfigMap といった標準機構のみで HPC クラスタの起動・破棄を実現し、追加のカスタム CNI やホスト管理を必要としない設計。 - 状態保存・弾力性・オートスケーリング・マルチテナンシー・バースティング・ワークフロー統合という広範な実験的機能を、単一のコアアーキテクチャ(1 Pod = 1 ノード、Indexed Job、TBON)の上に段階的に積み上げている。 **弱点・課題(著者ら自身が明示)** - 実行コンテナに Flux とアプリケーション本体を両方組み込む必要があり、既存 HPC コンテナの再ビルドを要する設計上の欠陥がある。 - MiniCluster 全体を単一の Indexed Job で構築するため、リードブローカーとフォロワーブローカーで異なる Pod 仕様を持たせられない制約がある(著者らは JobSet への将来的な移行を志向)。 - ノードの動的な登録解除なしに拡縮する仕組みは Flux 自体には未実装の「ハック」であり、C/C++ で書かれたプラグインによるバースティングの本格実装が必要とされる。 - 実験規模は最大 64 ノードにとどまり、伝統的な HPC のスケールとしては小さい。 - 状態保存機能では、実行中ジョブの保存時に約1〜2件のジョブが転送中に失われる現象が観察されており、原因未解明のまま将来課題とされている。 (Source: [[.raw/papers/arxiv-2309.17420.txt]] §5 Discussion)