PUNCH4NFDIのための連合型異種計算・ストレージインフラストラクチャ

1. はじめに

PUNCH4NFDI（国立研究データインフラストラクチャのための素粒子、宇宙、原子核、ハドロン）コンソーシアムは、ドイツ研究振興協会（DFG）の資金提供を受け、素粒子物理学、天文学、宇宙線物理学、ハドロン物理学、原子核物理学のコミュニティから約9,000人の科学者を代表しています。より広範なNFDIイニシアチブに組み込まれたその主な目標は、連合型かつFAIR（検索可能、アクセス可能、相互運用可能、再利用可能）な科学データプラットフォームを確立することです。このプラットフォームは、参加機関の多様な計算・ストレージリソースへのシームレスなアクセスを提供し、指数関数的に増大するデータ量と計算集約的な解析アルゴリズムによってもたらされる共通の課題に対処することを目指しています。本ドキュメントは、ドイツの異種研究インフラストラクチャを連合化するために設計されたアーキテクチャコンセプト——Compute4PUNCHとStorage4PUNCH——に焦点を当てています。

2. 連合型異種計算インフラストラクチャ – Compute4PUNCH

Compute4PUNCHは、ドイツ全土に分散する、ハイスループットコンピューティング（HTC）、ハイパフォーマンスコンピューティング（HPC）、クラウドシステムなど、多様な現物拠出リソースを効果的に活用するという課題に対処します。これらのリソースは、アーキテクチャ、オペレーティングシステム、ソフトウェアスタック、アクセスポリシーにおいて多様です。コア設計原則は、既存の運用中のリソースプロバイダーへの干渉を最小限に抑えた統一的なオーバーレイシステムを構築することです。

2.1. コアアーキテクチャと統合

連合は、中央バッチシステムオーバーレイとしてHTCondorを中心に構築されています。異種リソースは、COBalD/TARDISリソースメタスケジューラを使用して動的に統合されます。COBalD/TARDISは、リソースの可用性、ジョブ要件、ポリシーに基づいて、適切なバックエンド（例：Slurm、Kubernetesクラスター）にジョブをパイロットするインテリジェントなブローカーとして機能します。これにより、物理的に分散したシステムから単一の論理的なリソースプールが形成されます。

2.2. ユーザーアクセスとソフトウェア環境

ユーザーエントリーポイントは、従来のログインノードとJupyterHubサービスを通じて提供されます。トークンベースの認証・認可インフラストラクチャ（AAI）がアクセスを標準化します。ソフトウェア環境の複雑さは、コンテナ技術（例：Docker、Singularity/Apptainer）と、計算ノードにスケーラブルな読み取り専用ソフトウェア配布をグローバルに提供するCERN Virtual Machine File System (CVMFS)によって管理されます。

3. 連合型ストレージインフラストラクチャ – Storage4PUNCH

Storage4PUNCHは、コミュニティが提供するストレージシステム（主に高エネルギー物理学（HEP）で確立されているdCacheおよびXRootD技術に基づく）を連合化することを目指しています。この連合は、共通の名前空間とプロトコル（xrootd、WebDAVなど）を使用して、統一されたデータアクセス層を提示します。このコンセプトは、キャッシュソリューションとメタデータ処理サービスの統合を評価し、連合全体でのデータ局所性と発見可能性を向上させることも検討しています。

4. 技術的実装とコンポーネント

4.1. 認証・認可 (AAI)

トークンベースのAAI（おそらくOAuth 2.0/OpenID Connect標準、WLCG IAMやINDIGO IAMと類似）がシングルサインオン体験を提供します。これは、コミュニティのアイデンティティをローカルリソースの権限にマッピングし、異種のローカル認証システム（例：Kerberos、SSHキー）を抽象化します。

4.2. リソースメタスケジューリング: COBalD/TARDIS

COBalD（コーディネーター）とTARDIS（Transparent Adaptive Resource Dynamic Integration System）は連携して動作します。COBalDは高レベルのスケジューリング決定を行い、TARDISはターゲットリソース上の「パイロット」または「プレースホルダージョブ」のライフサイクルを管理します。この分離により、柔軟なポリシー適用（例：コスト、公平性、優先度）と、変動するリソース状態への動的適応が可能になります。スケジューリングは、コスト関数 $C_{total} = \sum_{i}(w_i \cdot T_i) + \lambda \cdot R$ を最小化する最適化問題としてモデル化できます。ここで、$T_i$ はジョブ $i$ のターンアラウンドタイム、$w_i$ はその優先度重み、$R$ はリソース使用コスト、$\lambda$ はバランスパラメータを表します。

4.3. データ・ソフトウェア層

CVMFSはソフトウェア配布に不可欠です。これは、コンテンツアドレッサブルストレージモデルと積極的なキャッシング（Stratum 0/1サーバーとローカルSquidキャッシュを使用）を利用して、ソフトウェアリポジトリを効率的に配信します。連合では、中央のPUNCHリポジトリStratum 0と機関ごとのStratum 1ミラーを持つ、CVMFSストラタの階層が採用されている可能性があります。データアクセスも同様の連合モデルに従い、ストレージエレメント（SE）がそのエンドポイントをグローバルディレクトリ（RucioやシンプルなRESTサービスのようなもの）に公開し、クライアントがデータの場所を透過的に解決できるようにします。

5. プロトタイプの現状と初期経験

本ドキュメントは、Compute4PUNCHとStorage4PUNCHの両方のプロトタイプが運用中であることを示しています。初期の科学的アプリケーションが実行され、パフォーマンス、使いやすさ、統合上の問題点に関する貴重なフィードバックが得られています。抜粋では具体的なベンチマーク数値は提供されていませんが、実行の成功は、オーバーレイバッチシステム、AAI統合、CVMFSを介したソフトウェア配信の基本的な機能が検証されたことを意味します。これらの経験は、ポリシー設定、エラー処理、ユーザードキュメンテーションの改良を導いています。

6. 主要な洞察と戦略的分析

核心的洞察： PUNCH4NFDIは新しいスーパーコンピューターを構築しているのではなく、既存の断片化されたリソースを実用的に縫い合わせる「連合ファブリック」をエンジニアリングしています。これは、一枚岩のインフラストラクチャから、アジャイルでソフトウェア定義されたリソース集約への戦略的転換であり、商用クラウドのトレンドを反映しながら、公的資金による学術界の制約と文化に合わせて調整されています。

論理的流れ： アーキテクチャは、明確な依存関係駆動の論理に従っています：1) 「誰が」の問題を解決するためのアイデンティティの統一（AAI）、2) 「どこで」の問題を解決するためのリソースの抽象化（COBalD/TARDIS + HTCondor）、3) 「何で」の問題を解決するための環境の分離（コンテナ + CVMFS）。この階層化された抽象化は、システムエンジニアリングの教科書的なアプローチであり、Worldwide LHC Computing Grid（WLCG）の成功を彷彿とさせますが、より多様なリソースセットに適用されています。

強みと弱点： 主な強みは、その非破壊的な採用モデルです。オーバーレイ技術を使用し、サイトの自律性を尊重することで、リソースプロバイダーへの参入障壁を下げます——これはコンソーシアムにとって重要な成功要因です。しかし、これがまたそのアキレス腱でもあります。メタスケジューリングのパフォーマンスオーバーヘッドと、異種で独立管理されたシステム間でのデバッグに伴う本質的な複雑さは、無視できないものになる可能性があります。「最小限の干渉」という要件は、深いストレージ-計算結合や動的ネットワークプロビジョニングなどの高度な機能を実装する能力を制限し、効率向上の可能性に上限を設けるかもしれません。GoogleのBorgやKubernetesクラスターのような目的構築の集中型システムと比較して、連合は常に高いレイテンシと低い利用予測可能性を持つことになります。

実践的洞察： この道を検討している他のコンソーシアムへの提言：1) 初日から監視と可観測性に多大な投資を行う。インフラストラクチャのためのGrafana/Prometheusや、ユーザージョブのためのAPM（アプリケーションパフォーマンス監視）などのツールは、複雑さを管理するために不可欠です。2) 限られたセットのコンテナベースイメージに標準化することで、CVMFSのメンテナンス負担を軽減します。3) 連合レベルの問題とローカルサイトの問題を区別する明確な階層化されたサポートモデルを開発する。真の試練は技術的実現可能性（HEPコミュニティはそれを証明済み）ではなく、運用上の持続可能性と大規模でのユーザー満足度です。

7. 技術的詳細

リソーススケジューリングの数学的モデル： COBalD/TARDISシステムは、制約付き最適化問題を解くものとして概念化できます。$J$をジョブの集合、$R$をリソースの集合、$S$をリソース状態（例：アイドル、ビジー、ドレイン）の集合とします。スケジューラは、ジョブ優先度$p_j$、リソース効率$e_{j,r}$、コスト$c_r$を考慮した効用関数$U$を最大化することを目指します： $$\max \sum_{j \in J} \sum_{r \in R} x_{j,r} \cdot U(p_j, e_{j,r}, c_r)$$ 制約条件： $$\sum_{j} x_{j,r} \leq C_r \quad \forall r \in R \quad \text{(リソース容量)}$$ $$\sum_{r} x_{j,r} \leq 1 \quad \forall j \in J \quad \text{(ジョブ割り当て)}$$ $$x_{j,r} \in \{0,1\} \quad \text{(二値決定変数)}$$ ここで、$x_{j,r}=1$はジョブ$j$がリソース$r$に割り当てられた場合を表します。TARDISは、リアルタイム状態$S$に基づいて割り当ての実現可能性を動的に管理します。

実験結果と図の説明： 提供されたPDF抜粋には具体的なパフォーマンスグラフは含まれていませんが、典型的な評価には以下の比較図が含まれるでしょう：
1. 時間経過に伴うジョブスループット： 連合プール全体と個々のリソースクラスターでの1時間あたりの完了ジョブ数を示す折れ線グラフ。集約の利点を実証します。
2. リソース使用率ヒートマップ： 1週間にわたる異なるリソースプロバイダー（KIT、DESY、ビーレフェルト大学など）間でのCPU/GPU使用率のパーセンテージを示すグリッド可視化。負荷分散の効果を強調します。
3. ジョブ起動レイテンシCDF： 連合システムとローカルバッチシステムへの直接投入における、ジョブ投入から実行開始までの時間を比較する累積分布関数プロット。メタスケジューリングのオーバーヘッドを明らかにします。
4. データアクセスパフォーマンス： ローカルアクセス、同じ地域内の連合ストレージエレメントからのアクセス、リモートの連合ストレージエレメントからのアクセスにおける読み書き速度を比較する棒グラフ。キャッシングとネットワークの影響を示します。

8. 分析フレームワークと概念モデル

ケーススタディ：天文サーベイデータの連合解析
シナリオ： テューリンゲン州立天文台タウテンブルクの研究グループが、銀河団を特定するために、スローン・デジタル・スカイ・サーベイ（SDSS）からの1 PBの画像データを処理する必要があります。これは約100,000 CPU時間を必要とする計算集約的なタスクです。
Compute4PUNCH/Storage4PUNCHを介したプロセス：
1. 認証： 研究者は、機関の認証情報（トークンベースのAAI経由）を使用してPUNCH JupyterHubにログインします。
2. ソフトウェア環境： 彼らのJupyterノートブックカーネルは、CVMFS上でホストされ、必要なすべての天文学パッケージ（Astropy、SExtractorなど）を含むコンテナイメージから実行されます。
3. ジョブ定義と投入： 彼らはノートブック内でパラメータスイープジョブを定義します。ノートブックはPUNCHクライアントライブラリを使用して、これらをHTCondor DAG（Directed Acyclic Graph）として連合プールに投入します。
4. リソースマッチングと実行： COBalD/TARDISはジョブ要件（CPU、メモリ、場合によってはGPU）を評価し、例えば、KITのHTCプール、ビーレフェルト大学のHPCキュー、DESYのクラウドノードなど、利用可能なスロットにそれらをパイロットします。ジョブは、キャッシュを活用して、最寄りのストレージロケーションから連合XRootD名前空間を介して入力データを読み取ります。
5. 結果集約： 出力ファイルは連合ストレージに書き戻されます。研究者は統一されたWebダッシュボードを介して進捗を監視し、最終的にノートブックで結果を集約して分析します。
このケースは、アイデンティティ、計算、ストレージ、ソフトウェア管理のシームレスな統合を示しています。

9. 将来の応用と開発ロードマップ

PUNCH4NFDIインフラストラクチャは、いくつかの高度な応用の基盤を築きます：
1. 連合機械学習トレーニング： GPUクラスターを含む異種リソースプールは、機関の境界を越えてPyTorchやTensorFlowなどの分散MLトレーニングフレームワークをサポートし、データを集中化できないプライバシー保護トレーニングのニーズに対処できます。
2. インタラクティブ解析と可視化： JupyterHubサービスを、大規模データセット探索のためのスケーラブルなバックエンド駆動のインタラクティブ可視化ツール（例：連合上のDaskクラスターに接続されたJupyterウィジェット）で強化します。
3. 外部クラウド・HPCセンターとの統合： 連合モデルを拡張し、共通の課金/アカウンティング層を介して商用クラウドクレジット（例：AWS、GCP）や国立スーパーコンピューティングセンター（例：JSCのJUWELS）を組み込み、科学のための真のハイブリッドクラウドを創出します。
4. メタデータとデータレイク統合： 単純なファイル連合を超えて、ストレージ層が統一されたメタデータカタログ（例：RucioやiRODSベース）と結合された統合データレイクアーキテクチャに移行し、コミュニティ間でのデータ発見とプロベナンス追跡を可能にします。
5. ワークフロー・アズ・ア・サービス： 連合インフラストラクチャの上に、REANA（Reproducible Analysis Platform）やApache Airflowのようなより高レベルのプラットフォームサービスを提供し、科学者が基盤となるインフラストラクチャを管理することなく、複雑で再現可能な解析パイプラインを定義・実行できるようにします。

開発ロードマップは、本番サービスの強化、リソースプールの拡大、より洗練されたデータ管理ツールの統合、非専門家ユーザーの採用障壁を下げるためのユーザーフレンドリーなAPIとSDKの開発に焦点を当てる可能性が高いです。

10. 参考文献

PUNCH4NFDI Consortium. (2024). PUNCH4NFDI White Paper. [Internal Consortium Document].
Thain, D., Tannenbaum, T., & Livny, M. (2005). Distributed computing in practice: the Condor experience. Concurrency - Practice and Experience, 17(2-4), 323-356. https://doi.org/10.1002/cpe.938
Blomer, J., et al. (2011). Distribution of software in the CernVM file system with Parrot. Journal of Physics: Conference Series, 331(4), 042009. https://doi.org/10.1088/1742-6596/331/4/042009
Giffels, M., et al. (2022). COBalD and TARDIS – Dynamic resource overlay for opportunistic computing. EPJ Web of Conferences, 251, 02009. https://doi.org/10.1051/epjconf/202225102009
dCache Collaboration. (2023). dCache: A distributed storage data caching system. Retrieved from https://www.dcache.org/
XRootD Collaboration. (2023). XRootD: High performance, scalable fault tolerant access to data. Retrieved from http://xrootd.org/
Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, 160018. https://doi.org/10.1038/sdata.2016.18
Verma, A., et al. (2015). Large-scale cluster management at Google with Borg. Proceedings of the Tenth European Conference on Computer Systems (EuroSys '15). https://doi.org/10.1145/2741948.2741964