Apptainer/Singularityの10年：HPCコンテナの「ビッグバン」を振り返る

オリジナル記事「Ten Years of Apptainer/Singularity: A Look Back at the Big Bang of HPC Containers」

今年、Apptainerの前身となったプロジェクト「Singularity」が10周年を迎える。この10年間が実際にどのような意味を持っていたのか、立ち止まって振り返ってみる価値がある。

最近、私は「起源」についてよく考えている――ある問題があまりにも広範に蔓延し、その解決策が瞬く間にエコシステム全体を一変させる瞬間についてだ。顕著な例として、研究や学術界においてコンテナが急速かつ広範に採用された経緯が挙げられる。

2010年代半ば、科学者たちは研究にコンテナ（Docker）を取り入れ始めていたが、ハイパフォーマンスコンピューティング（HPC）システムは根本的に互換性のないアーキテクチャを採用していたため、研究者たちは切実に必要としていた移植性を手に入れられなかった。HPCの厳しい制約に特化したソリューションが不可欠であると認識し、私はその開発に着手した。

その結果生まれたソリューションは、即座に、そして普遍的に受け入れられた。これは段階的な普及ではなく、緊急に必要とされていたソリューションに対する驚異的な採用であり、数ヶ月のうちにゼロから、国立研究所やスーパーコンピューティングセンターのエコシステム全体へと広がっていった。こうしてコンテナはHPCの世界に導入され、その後のあらゆる進展が可能になったのである。

Apptainerについて語る前に、Singularityに立ち返る必要がある。

	Dockerは、HPC専用のコンテナ化技術の着想源となった

解決されずに残った問題

ハイパフォーマンスコンピューティングにポータビリティの問題があった。研究者たちは、HPCリソース上で再現できないソフトウェア環境をローカルで設定するのに数週間を費やしており、システム間の移植性や再現性はなおさらだった。実験を再現することはできなかった。コラボレーションは、科学的な境界ではなく、ソフトウェアの境界で止まってしまっていた。

Dockerは、広く理解されているインターフェースに加え、コンテナ向けのビルドおよび移動用APIや標準を提供することでコンテナを利用可能にしたが、DockerはHPC向けに構築されたものではなかった。それは特権デーモン、root所有のランタイム、エンタープライズワークロード向けに設計されたセキュリティモデルで構成されていた。これらはいずれも、たった一つの設定ミスが数千人のユーザに影響を及ぼす共有研究システムにはそぐわないものだった。HPC管理者は二者択一を迫られた。Dockerの扉を開き、誰もがroot権限を持ちリソースマネージャーを迂回するリスクを受け入れるか、それとも扉を閉ざしたままにし、研究者が同じ環境問題と際限なく格闘し続けるのを放置するか、という選択だった。

2015年、ローレンス・バークレー国立研究所に勤務していた頃、私はあるソリューションのプロトタイプを作成できるかどうか試してみることにした。Singularityは、次のような実際の問題を解決するために開発された。ソフトウェア環境を一度定義すれば、どこでも実行でき、権限昇格もデーモンも不要で、システム管理者にセキュリティと移植性のトレードオフを強いる必要がないというものだ。

このソリューションは、誰にとっても重要なものだった。

HPCコンテナのビッグバン

	ApptainerはHPCリソースの管理を簡素化する

その後起こったのは、段階的な導入ではなく、即座かつ世界的な普及だった。国立研究所、大学、スーパーコンピューティングセンターの研究者やシステム管理者はSingularityを見つけ、それが自分たちの抱える課題を解決してくれることを即座に理解した。数ヶ月も経たないうちに、Singularityは世界でも最も強力なシステム上で稼働するようになった。国立研究所、TOP500クラスタ、あらゆる主要な科学分野の何千人もの研究者にサービスを提供する学術HPCセンターなどだ。

その影響は明白だった。環境設定に費やしていた数週間が、数時間に短縮された。ソフトウェアの再現性を巡って停滞していた複数機関間の共同研究も、前進する道を見出した。バイオインフォマティクスのパイプライン、分子動力学シミュレーション、気候モデル、素粒子物理学のワークフロー、ゲノム解析――これらすべてが、移植性、再現性、安全性を確保しつつ、大規模に実行されるようになった。

Singularityは、HPC向けに改良されたコンテナツールではなかった。HPCのために構築された最初のコンテナツールだったのだ。だからこそ、あれほど広まったのである。

管理責任の履行

Singularityが成長するにつれ、私はこのプロジェクトをLinux Foundationに提供することを決断した。そうすることで、このプロジェクトが常に、その恩恵を受けるコミュニティによって運営される恒久的な拠点を確保するためだ。提案は受け入れられ、プロジェクト名はApptainerに変更された。

名称変更に戸惑う人もいた。だが、そうなるべきではなかった。プロジェクトの改名は、それが成し遂げたことへの愛の表れだったのだ。私はApptainerが、いかなる単一の企業、貢献者、あるいは経営判断よりも長く存続することを望んでいた（だからこそ、Rocky Linuxもまた、いかなる企業にも所有されていないのだ。私自身の企業でさえも！）。Linux Foundationは、プロジェクトが必要としていたものをまさに提供してくれた。Apptainer 1.0は2022年にリリースされた。成熟し、安定し、コミュニティによってガバナンスされ、長く続くように構築されたものだ。

さらに最近では、ApptainerはLinux FoundationのHigh Performance Software Foundation（HPSF）に加わった。これは、科学計算が依存するオープンソースソフトウェアスタックを維持するための、より広範な取り組みだ。その基盤となる財団は、ますます強固なものになっている。

10年が明らかにしたこと

Apptainerは、HPCコミュニティが認識していたものの、必ずしも明確に表現できなかった事実を証明した。科学計算には、従来のインフラでは満たすよう設計されていなかった要件が存在する。移植性、セキュリティ、再現性は、あくまで始まりに過ぎなかった。高性能計算の未来像と、その実現の緊急性を捉えるために必要だったのは、まさにこの視点であった。

Apptainerが問いかけることを可能にした問い

コンテナは移植性と再現性の問題を解決したが、それだけでは不十分だった。

HPCワークロードがより複雑化し、AIが登場するにつれ、新たな要件が浮上した。大規模な異種混在コンピューティング環境のための、新しいタイプのオーケストレーションとメタオーケストレーションだ。分散インフラ全体にわたるスケジューリングと管理、ユーザへの障壁の低減、そしてデータが最優先のリソース要件となる計算やMPIジョブと並行して、推論やJupyter Notebooksのようなリソースを大量に消費するサービスをスケジューリングすることである。

その問いこそが、今やHPCおよびAIインフラにおける決定的な課題となっている。科学計算とAI計算の次の進化は、単にハードウェアの高速化だけではない。それは、データや環境、セキュリティに対する制御権を放棄することなく、ユーザーがハードウェアを大規模かつインテリジェントにオーケストレーションできる、現代的なコンピューティングアーキテクチャである。Apptainerは、実際の問題解決に向けて構築されたものが、いかなる単一のツールや企業、時代をも凌駕する成果を生み出すことを証明した。この同じ原則が、今後の道筋を示している。

一つの長期的な視点

私は数十年にわたり、研究者が重要な科学を行うために依存するソフトウェアの開発に取り組んできた。Apptainerは世界最速のマシン上で動作する。それが可能にした科学は、あらゆる主要な科学分野に及んでいる。私が選んだガバナンスモデルにより、Apptainerは今後10年、そしてその次の10年も稼働し続けるだろう。

移植性の問題に対する解決策として始まったものが、再現可能な科学のためのアーキテクチャとなった。単一のツールとして始まったものが、コミュニティとなった。一つの答えとして始まったものが、今や次世代のイノベーションの基盤となっている。

これこそが、この10年間の成果だ。次の10年はすでに始まっている。

著者について： グレゴリー・カーツァーはCIQのCEO兼創設者であり、SingularityおよびApptainerのオリジナル開発者である。Apptainerコミュニティへの参加はこちら：https://github.com/apptainer/apptainer