スパコン生まれのコンテナ実装 Singularity -1-

はじめに

HPCに限らず、多くのアプリケーションは自らが動く実行環境が整備されていなければ、正しく動作することはできません。動作環境の内容は OSや、その中にインストールされているライブラリの種類やバージョン、そして設定など、多岐に渡ります。

ある環境において「動作が確認できている」場合、その環境は動作確認済みと言い、その環境において「動作が保証されていて、問題が発生したら対応する責任がある」場合、その環境はサポートされていると言います。

たまたま互換性があって、サポートされていなかったり、動作確認済みでない環境で動いてしまう場合もありますが、その結果が信頼できるかは自ら確認する必要があります。動作環境の準備にあたって、依存関係などを解消するのに、多い時は数十のツールやライブラリの整備が必要になることもあります。この「動作環境を整備し、動作の結果が正しいことを保証する」というのは、アプリケーションのみならず環境構築にも精通している必要があり、想像以上に経験やスキルを必要とします。

さて、HPCの適用範囲が多彩になったことで、HPC環境に求められる動作環境も同時に多彩になりました。また多くのアプリケーションで、定期的に新しいバージョンをリリースするローリングリリースが採用されることが増え、常に要求仕様は変化しています。特に進歩が著しい AI 分野では毎週のように新しいものが出てきたり、逆に統廃合が進んだりしていて、そうした変化に追従するのは専用の環境においてすらハードな作業となっています。まして複数のバージョンを混在・共存させるとなると、さらに大きな困難が伴います。

旧来、 HPC 環境の構築とは、これらの要求をすり合わせて包含した最小公倍数的な実行環境を構築することでしたが、もはや非現実的と言えます。対する解決策として、環境を切り替える様々な手段が用意されてきました。

• 個別ディレクトリにランタイムやアプリケーションをインストールし、環境変数等で切り替える module。
• ハードウエアのエミュレーションを行い、新たに個別のOSをインストールして使う、完全仮想化。
• カーネルは共通で用いて、アプリケーションごとにランタイムを分離して切り替えるコンテナ。

仮想化とコンテナは、システム管理者が用意したものとは無関係にユーザー自身が環境を用意できますが、これはある意味、実行環境を用意する仕事がシステム管理者からユーザーに移動しているとも言えます。ただし、これらにより再現性が確保でき、作成した実行環境の共有も容易になります。結果として、ユーザーは常に自身のアプリケーションを最新に追従させることも、旧バージョンを使うことも、環境に一切手を加えることなく随時できるため、環境の構築・維持・検証のためのコストは大幅な低減が可能になります。

これから米国Lawrence Berkeley National Laboratory=LBNLのスパコンで生まれたコンテナ実装、Singularityについて解説していきます。

コンテナ

Linuxにはもともとchrootという機能があり、例えば他のLinux OSがインストールされているディスクパーティションをマウントしたら、そのディレクトリをルートディレクトリとして扱い、その外のファイルへはアクセスできない分離した環境の中でアプリケーションを起動できます。サービスの起動に必要最小限のものだけを分離してchroot起動するという手法は、DNSサーバー等のセキュリティ対策としてよく用いられてきました。

コンテナはこの機能（だけではありませんが）を用いてアプリケーションの実行環境を分離します。OSを構成する要素のうちカーネルは本体のものを使い、ルートディレクトリだけを切り替えているわけです。完全仮想化ではエミュレータを起動してから新たにOSを起動する必要があり、長期間サービスを起動している必要があったり、カーネルごと別のOS（Windows等）が必要になったりしない限り、無駄が多くなります。コンテナはイメージを用意できたらすぐ環境を切り替えてアプリケーションが起動できるため、普通にアプリケーションを起動するのと変わらない使い勝手を実現できます。

ただし、コンテナの実装にはいろいろなものがあります。最も広く用いられているDockerはコンテナの外と分断された環境を実現します。ユーザーはコンテナ内でrootのように作業できますが、必要なファイルやネットワーク設定を起動時に設定して取り込む必要があります。筆者は鍵のかかる窓もない個室に必要な荷物を持ち込んで作業をするのをイメージしています。そしてその部屋の構築管理はシステムで起動しているデーモンにより実行されます。これはパブリッククラウドのように、不特定多数の人がインフラをシェアしながら互いが見えないようサービスを運用する場合には必要なことですが、逆に外（ホームディレクトリやデバイス、ネットワーク等）との連携が取れないと不便な用途には向きません。

スパコンユーザーが使いやすいよう作られたSingularityは逆で、Singularityがインストールされてさえいれば、システム側にデーモン等を起動しておく必要はなくユーザー側で全てハンドリングできます。コンテナを起動したユーザーは自分のIDとホームディレクトリへのアクセスを維持したままなので、あらかじめファイルを取り込む必要もありません。ネットワークやデバイスもそのまま使えます。コンテナの中から外のプロセスは見えますし、外から中で何をやっているかもわかります。これは、自分の部屋の1面だけ作業用に模様替えできる機能とイメージしています。

コンテナの採用により、特定のアプリケーションを使うのに、システム側でOSを入れ替えることも、新たにライブラリをインストールすることも、設定を切り替えることも、ほぼ不要になります。分離された動作環境を独立に構築して持つことで、アプリケーションからは必要なものが見える環境が起動され、ユーザーはそれを起動するだけです。また、その環境を配布することでアプリケーションの開発者は環境要因のサポートコストを大幅に下げられるはずです。

まとめ

これからSingularityについての解説を始めるにあたり、概要を書かせていただきました。次回以降、製品群の解説、そして具体的な使い方に入っていきます。

ご質問やご指摘についてはsupport@pacificteck.comまでお寄せください。