Compute4PUNCH & Storage4PUNCH：素粒子・宇宙・原子核物理学のための連合インフラストラクチャ

1. はじめに

PUNCH4NFDI（National Research Data Infrastructureのための素粒子、宇宙、原子核、ハドロン）コンソーシアムは、ドイツ研究振興協会（DFG）の資金提供を受け、ドイツの素粒子物理学、宇宙物理学、宇宙線物理学、ハドロン物理学、原子核物理学コミュニティから約9,000人の科学者を代表しています。国家的なNFDIイニシアチブに組み込まれたその主な目標は、連合されたFAIR（検索可能、アクセス可能、相互運用可能、再利用可能）な科学データプラットフォームを確立することです。このプラットフォームは、加盟機関が提供する多様で異種のコンピュートおよびストレージリソースへのシームレスなアクセスを提供し、複雑なアルゴリズムによる指数関数的に増大するデータ量の分析という共通の課題に対処することを目指しています。本ドキュメントは、この連合インフラストラクチャの基盤を形成するCompute4PUNCHとStorage4PUNCHの技術的概念に焦点を当てます。

2. 連合異種コンピュートインフラストラクチャ – Compute4PUNCH

Compute4PUNCHは、ドイツ全土に分散する多様な現物提供型の高スループットコンピューティング（HTC）、高性能コンピューティング（HPC）、クラウドリソースを効果的に活用するという課題に対処します。これらのリソースは、アーキテクチャ、オペレーティングシステム、ソフトウェアスタック、認証メカニズムが異なります。

2.1. コアアーキテクチャとオーバーレイシステム

Compute4PUNCHの基盤は、HTCondorに基づく連合オーバーレイバッチシステムの構築です。重要な革新は、COBalD/TARDISリソースメタスケジューラの使用です。TARDIS（TARDIS Acts as a Resource Dispatcher for In-place Scheduling）は、外部の異種リソースをHTCondorプールに動的かつ透過的に統合します。これは「パイロット」システムとして機能し、外部クラスタ（SlurmベースのHPCシステムなど）にプレースホルダージョブを投入し、その後、中央のHTCondorキューから実際のユーザージョブを引き出して実行します。このアプローチは、リソース提供者の既存の運用環境への侵入を最小限に抑え、採用のための重要な要件を満たします。

リソースマッチングとスケジューリングのロジックは、最適化関数によって抽象的に表現できます。$R = \{r_1, r_2, ..., r_n\}$を利用可能な異種リソースの集合とし、各リソースはアーキテクチャ$arch(r_i)$、利用可能コア数$c(r_i)$、メモリ$m(r_i)$、キュー待機時間$w(r_i)$などの属性を持ちます。$J = \{j_1, j_2, ..., j_m\}$を要件$req(j_k)$を持つユーザージョブの集合とします。メタスケジューラの目標は、効率性と公平性の加重和であることが多い目的関数$F$を最大化するマッピング$M: J \rightarrow R$を見つけることです：

$F(M) = \alpha \cdot \sum_{j_k} U(j_k, M(j_k)) - \beta \cdot \sum_{r_i} L(r_i, M^{-1}(r_i))$

ここで、$U$はリソースがジョブの要件（CVMFSを介したソフトウェア環境の互換性を考慮）をどれだけ満たすかを測定する効用関数、$L$は単一リソースの過剰購読にペナルティを与える負荷関数です。COBalD/TARDISは、この動的でオンラインのスケジューリング問題をヒューリスティックに解決します。

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

ユーザーアクセスは、トークンベースの認証・認可インフラストラクチャ（AAI）を通じて標準化されます。主なエントリーポイントは、従来のログインノードとJupyterHubサービスであり、インタラクティブな分析とプロトタイピングのための使い慣れたWebベースのインターフェースを提供します。

多様なソフトウェア依存関係を処理するために、インフラストラクチャはコンテナ技術（例：Docker、Singularity/Apptainer）とCERN Virtual Machine File System (CVMFS)を活用します。CVMFSは、ソフトウェアインストールのためのスケーラブルで読み取り専用、かつグローバルに分散された名前空間を提供します。コミュニティ固有のソフトウェアスタックはCVMFSリポジトリに公開され、物理的な場所に関係なく、どのコンピュートノードも必要なソフトウェア環境に即座に一貫してアクセスできるようになり、ローカルインストールのオーバーヘッドを排除します。

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

Storage4PUNCHは、主にdCacheまたはXRootD技術に基づくコミュニティ提供のストレージシステムの連合化に焦点を当てています。これらはいずれも高エネルギー物理学（HEP）で確立された技術です。

3.1. 連合化とキャッシング戦略

連合化により統一された名前空間が作成され、ユーザーは複数の機関のストレージ要素にまたがるデータに、あたかも単一のシステムであるかのようにアクセスできます。これを実現するために、XRootDの連合プロトコルやdCacheのフロントエンドプーリングなどの技術が採用されています。システムはインテリジェントなデータ位置特定とルーティングを実行します。

評価中の重要なコンポーネントはキャッシングです。グローバルまたは地域的なキャッシュ層は、頻繁にアクセスされるデータセットのレイテンシと広域ネットワーク負荷を大幅に削減できます。サイズ$S$のキャッシュのデータアクセスパターンに対するヒット率$H$をモデル化できます。データアイテム$d_i$にアクセスする確率がZipf様分布$P(i) \sim 1 / i^{\alpha}$に従う場合、LRUキャッシュの期待ヒット率はおよそ次のようになります：

$H(S) \approx \sum_{i=1}^{S} P(i)$

ここで、$\alpha$は歪度パラメータです。データ再利用率の高い科学ワークフロー（分析チェーンで一般的）では、中程度のサイズのキャッシュでも高い$H$が得られ、その導入が正当化されます。このプロジェクトは、より深い統合のためのメタデータ処理ソリューションも評価しており、ファイルアクセスだけでなく、連合全体でのデータ発見機能の提供を目指しています。

4. 技術詳細と数学的枠組み

連合システムの性能は、効率的なリソース発見とスケジューリングにかかっています。システム状態はグラフ$G=(V,E)$としてモデル化できます。ここで、頂点$V$はリソース（コンピュートノード、ストレージエンドポイント）を表し、辺$E$は帯域幅$bw(e)$とレイテンシ$lat(e)$を持つネットワークリンクを表します。ワークフロー$W$は、データ依存関係$D$を持つタスク$T$の有向非巡回グラフ（DAG）です。

スケジューリング問題は次のようになります：各タスク$t \in T$をコンピュートリソース$r_c \in V_c$に配置し、その必要な入力データをストレージリソース$r_s \in V_s$からルーティングして、総所要時間（ワークフロー完了時間）を最小化する。制約条件は以下の通り：

$\text{minimize } \max_{t \in T} (ft(t))$
制約条件：
$\forall r \in V_c, \sum_{t placed\ on\ r} c(t) \leq C(r)$ (CPU容量)
$\forall d \in D, \text{transfer\_time}(d) = \frac{size(d)}{\min\_bw(path)} + \sum_{e \in path} lat(e)$

ここで、$ft(t)$はタスク$t$の終了時間、$c(t)$はそのCPU要求、$C(r)$はリソース$r$の容量です。連合システムは、HTCondorおよびCOBalD/TARDIS内のヒューリスティックアルゴリズムを使用して、このNP困難問題に対する近似解をリアルタイムで求めます。

5. 実験結果とプロトタイプ性能

本論文は、運用プロトタイプでの初期経験について報告しています。提供された抜粋では具体的な定量的ベンチマークは詳細に述べられていませんが、連合インフラストラクチャ上での科学アプリケーションの実行が成功したことが示唆されています。

チャート説明（推測される性能指標）： 仮想的な性能チャートは、時間の経過に伴う2つの主要な指標を示す可能性が高いです：1) 連合プール全体の総合リソース使用率。これは、オーバーレイシステムが異なる提供センター間の容量ギャップを効果的に埋める方法を示します。2) 連合シナリオと孤立したリソース使用を比較したジョブターンアラウンドタイム。連合システムは、特に柔軟なリソース要件を持つジョブに対して、ターンアラウンドタイムの平均と分散が低くなることが示されるでしょう。なぜなら、それらは最短のキューを持つリソースにルーティングできるからです。TARDISを介したHPCリソースの統合は、パイロットジョブメカニズムによる初期のレイテンシ追加を示すが、適切なワークロードに対しては、そうでなければ利用できない高コア数ノードへのアクセスを提供します。

CVMFSの使用は、均一なソフトウェア環境を提供することに成功したと報告されており、これはユーザー採用のための重要な成功要因です。トークンベースのAAIは実装されており、安全な複数機関アクセスのための必要な基盤を提供しています。

6. 分析フレームワーク：概念的なケーススタディ

ケース：マルチメッセンジャー天体物理学分析。 宇宙線物理学者は、Fermi-LATとIceCubeによって検出されたガンマ線バースト（GRB）のデータを分析し、ASAS-SNからの光学追観測と相関させる必要があります。ワークフローには以下が含まれます：A) 高I/Oに最適化されたHTCファームでのテラバイト規模の生光子データ（Fermi）の処理。B) 多数のコアを持つHPCクラスタでのニュートリノ事象再構成（IceCube）のためのモンテカルロシミュレーションの実行。C) GPUノードを使用した光学データの画像分析の実行。

Compute4PUNCH/Storage4PUNCHを介した連合実行：
1. ユーザーは、JupyterHubを介して単一の高レベルワークフロー記述（例：Common Workflow Language - CWLを使用）を送信します。
2. AAIトークンが、すべてのシステムでユーザーを認証します。
3. HTCondorオーバーレイは、COBalD/TARDISの指示に従ってワークフローDAGを分析します：
- タスクAは、DESYのdCacheバックエンドのストレージに近いHTCワーカーにマッチングされ、ディスパッチされます。
- タスクBの10,000 CPU時間の要件により、TARDISがKITのSlurmベースのHPCクラスタ上でスロットをプロビジョニングします。
- タスクCは、ボン大学のGPUパーティションに送信されます。
4. すべてのタスクは、PUNCH CVMFSリポジトリから同一の分析ソフトウェアスタック（Python、特定の科学ライブラリ）を引き出します。
5. 中間データは、連合Storage4PUNCH名前空間（例：XRootDを使用）を介して交換され、頻繁にアクセスされる較正ファイルは地域キャッシュから提供されます。
6. 最終結果が集約され、ユーザーに返されます。

このケースは、価値提案を示しています：物理学者は、3つの異なるシステムにまたがる個別のログイン、ソフトウェアインストール、データ転送を管理するのではなく、単一の論理インフラストラクチャと対話します。

7. 核心的洞察とアナリストの視点

核心的洞察： PUNCH4NFDIは、もう一つのモノリシックなスーパーコンピュータを構築しているのではありません。国家的規模の異種研究コンピューティングのための連合層—「メタオペレーティングシステム」—を設計しています。その真の革新は、既存の政治的サイロ化されたリソースを実用的に調整し、一貫したユーティリティに変えることであり、技術的純粋さよりも最小限の侵入を優先しています。これはGoogleのBorgというよりは、コンピュートジョブのための洗練されたEU全域の航空交通管制システムに似ています。

論理的流れ： その論理は優雅に再帰的です。交渉の余地のない制約から始めます：既存のコミュニティ運用を混乱させない。これにより、プッシュベースの集中スケジューラではなく、プルベースのオーバーレイアーキテクチャ（HTCondor + TARDIS）が強制されます。そのオーバーレイは、次に、普遍的なソフトウェア配信メカニズム（CVMFS/コンテナ）と統一されたアイデンティティ層（トークンAAI）を必然的に必要とします。ストレージ連合は、実戦で鍛えられたHEPツール（dCache/XRootD）を活用するという並行した道筋をたどります。全体の流れは、制約駆動設計の模範であり、各技術的選択は、複数機関協力の社会政治的現実の直接的な結果です。

強みと欠点：
強み： このアーキテクチャは見事に連合可能です。設計上、ガバナンスを水平方向に拡張し、新しいリソース提供者の参入障壁を下げます。HTCondorとCVMFSの使用は、LHC共同研究から得られた数十年にわたるコミュニティの信頼と運用ノウハウを活用し、技術的リスクを低減します。「現物提供」リソースへの焦点は財政的に持続可能であり、断片化問題を多様性の利点に変えます。
欠点： 明白な問題は性能オーバーヘッドです。二重スケジューリング（メタスケジューラ + ローカルバッチシステム）とパイロットジョブモデルは必然的にレイテンシを追加し、きめ細かく緊密結合したMPIジョブには適していません—これは純粋なHPCワークロードにとって重要な制限です。CVMFSへの依存は堅牢ですが、ソフトウェア配信の単一障害点を作り出し、高度に独自またはライセンスされたコードでは苦労する可能性があります。さらに、FAIRデータ原則で指摘されているように、真の相互運用性には豊富なメタデータが必要です。現在のStorage4PUNCHの説明は、バイトレベルのアクセスに重点を置いており、意味論的発見にはあまり焦点を当てていないようです。

実用的な洞察：
1. PUNCHチーム向け： 性能特性評価に注力してください。代表的なワークフローに対する連合環境とネイティブ環境のジョブスループットおよびレイテンシを比較した透明性のあるベンチマークを公開してください。このデータは、懐疑的なHPCセンター管理者やユーザーを説得するために重要です。連合層自体の「Tier-1」サポートモデルを積極的に開発してください。その複雑さが重要な依存関係になります。
2. 他のコンソーシアム（例：バイオインフォマティクスや気候科学）向け： 単に技術スタックをコピーするのではなく、それを可能にしたガバナンスモデルをコピーしてください。重要な教訓は、機関のインセンティブを一致させる「現物提供」合意です。PUNCHが行ったように、認証とソフトウェア配布の連合化から始めてください。これらは基礎となります。
3. 資金提供機関（DFG、EU）向け： このモデルは、将来の国家的研究インフラストラクチャ公募の青図となるべきです。「接着剤」（連合層のコアDevOps、調整）に資金を提供し、機関に「レンガ」（実際のコンピュート/ストレージ）の資金提供を任せてください。これは、新しい集中型施設を構築するよりも、既存の資本投資をより効果的に活用します。この原則は、欧州オープンサイエンスクラウド（EOSC）の戦略的ビジョンでも共鳴しています。

結論として、Compute4PUNCHとStorage4PUNCHは、21世紀の大規模科学インフラストラクチャのための成熟した、実用的で、非常に複製可能なモデルを代表しています。それは、理論的な性能の一部を、アクセシビリティ、回復力、政治的実現可能性の大きな向上と交換しています。その成功は、FLOPSではなく、5つの異なるクラスタの専門的なシステム管理者になることなく分析を完了できる博士課程の学生の数によって測定されるでしょう。

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

PUNCH4NFDIインフラストラクチャは、いくつかの将来の発展の基盤を築きます：

機械学習ワークフローとの統合： 連合は、専門的なAI/MLアクセラレータ（例：NVIDIA DGXポッド、Google TPU）をリソースタイプとしてサポートするように拡張できます。KubeflowのようなフレームワークをHTCondorと並行して統合し、TARDISが従来のHTCとMLに焦点を当てたリソースにまたがるハイブリッドジョブ配置を管理できます。
積極的なデータ配置とワークフロー対応スケジューリング： キャッシングを超えて、システムは予測的データステージングを実装できます。ユーザーが送信したワークフローDAGを分析することで、ジョブ実行開始前に、必要なデータセットをリモートのStorage4PUNCHエンドポイントから、スケジュールされたコンピュートリソース近くのローカルキャッシュに事前にフェッチし、データ転送レイテンシを効果的に隠すことができます。これには、コンピュートメタスケジューラとストレージ連合の名前空間および監視データとのより緊密な統合が必要です。
エッジコンピューティングへの拡張： 電波天文学やニュートリノ物理学などの分野では、センサーが膨大なデータストリームを生成するため、連合モデルにエッジコンピューティングサイトを組み込むことができます。軽量のTARDISエージェントを観測所で実行し、中央キューから前処理タスクを引き出して、関連するイベントのみを中央ストレージに送信する前に、現場でデータをフィルタリングおよび削減できます。
グリーンコンピューティングと炭素意識スケジューリング： メタスケジューラは、ドイツ全土の電力網からの炭素強度データで強化できます。その後、大規模計算の炭素フットプリントを最小限に抑えるために、再生可能エネルギー普及率の高い地域（例：北部の風力発電）のデータセンターに、生産ピーク時にジョブを優先的にルーティングできます。これは、Linux FoundationのCarbon Callイニシアチブで強調されているように、研究インフラストラクチャにとって新たに重要になっている優先事項です。
国際パートナーとの連合間接続： 論理的な次のステップは、ドイツのPUNCH連合を、Worldwide LHC Computing Grid（WLCG）、Open Science Grid（OSG）、European Open Science Cloud（EOSC）などの海外の類似インフラストラクチャと接続することです。これにより、グローバルで学際的な研究インフラストラクチャが生まれますが、政策調整、セキュリティ、アカウンティングにおいて重大な課題が生じます。

9. 参考文献

PUNCH4NFDIコンソーシアム. "PUNCH4NFDI - Particles, Universe, NuClei and Hadrons for the NFDI." ホワイトペーパー, 2021.
Thain, D., Tannenbaum, T., & Livny, M. "Distributed computing in practice: the Condor experience." Concurrency - Practice and Experience, 17(2-4), 323-356, 2005. https://doi.org/10.1002/cpe.938
Blomer, J., et al. "CernVM-FS: delivering scientific software to globally distributed computing resources." International Journal of High Performance Computing Applications, 28(2), 158-174, 2014. https://doi.org/10.1177/1094342013509700
Giffels, M., et al. "COBalD/TARDIS – Dynamic, Pilot-based Resource Provisioning for a Federated HTCondor Pool." In Proceedings of CHEP 2018, 2018.
Wilkinson, M. D., et al. "The FAIR Guiding Principles for scientific data management and stewardship." Scientific Data, 3:160018, 2016. https://doi.org/10.1038/sdata.2016.18
European Commission. "European Open Science Cloud (EOSC) Strategic Implementation Roadmap." 2018.
Linux Foundation. "Carbon Call: A Global Initiative for Reliable Carbon Accounting." 2022. https://www.linuxfoundation.org/research/carbon-call
Zhu, J.-Y., Park, T., Isola, P., & Efros, A. A. "Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks." In Proceedings of the IEEE International Conference on Computer Vision (ICCV), 2017. (連合的で異種リソースアクセスの恩恵を受ける可能性のある複雑な計算ワークロードの例として引用).