ウェブやデータサイエンス方面のソフトウェア構築では、気づくとコンテナ化ソフトウェアのDockerが必須技術のように言われており、コンテナオーケストレーションツールのKubernetesがデータセンターの新たな基盤になったような話を見かけるようになった。コンテナ化技術の時代。
コンテナ化技術は、データセンターのクラウド化（IaaS）を可能にした仮想マシン技術とよく対比される。技術的には随分と異なる。仮想マシンはオペレーティング・システム（OS）にまるでハードウェアがあるかのように見せる技術だが、コンテナ化はOSの名前空間とプロセス管理をつかったアプリケーションの隔離である。しかし、コンテナ向きの仕事を、仮想マシンがしばらく担ってきた。
1. 仮想マシンの時代（1998年～）
2000年代は仮想マシンが流行っていた。Intelのi80286以降のCPUがハードウェアで仮想化を支援する機能を持っており、1987年にリリースされたIBM OS/2が、それを使って仮想マシンでMS-DOSやWindows 3.xを動かす機能を提供していたのだが、VMwareが1999年にMS-Windows向けの製品を出してから一般化した。2003年ぐらいから、プロプライエタリ/オープンソースの競合製品が増え、2006年からCPUの仮想化支援機能が拡充される。
仮想マシン技術は便利で、古いOSを新しいハードウェアで動かしたり、ひとつのハードウェアで複数のOSを動かしたり、OSを新しいハードウェアに移動させたり、OSの領域を破壊しかねない危ないソフトウェアの挙動を隔離された領域で確認したりできる。標準インストールのOSをそのままに、Linuxをインストールして使うのに使っている人も多いはずだ。
2000年代は、あまり上手くない使い方もされていた。サーバーソフトウェアを含む、アプリケーションの隔離とポータブル化だ。OSではなくて、アプリケーション。ウェブ・アプリケーション全盛の時代だが、アプリケーション・サーバーなどのミドルウェアに強く依存した構造を持つ。また、ライブラリ等のバージョン整合性の問題も依然としてある。実行環境をまとめて管理したくなったわけだが、OS全体に依存しているわけではないので、仮想マシンを用いるのは無駄が多い*1。
2. コンテナ化の時代（2013年～）
2002年から2013年にかけてLinuxに名前空間（namespace）と新たなプロセス管理技術（cgroup）が導入され、2010年に複数のマウントポイントをひとつのディレクトリに統合する機能（OverlayFS）が開発された*2後、2013年にそれらを使ったコンテナ化技術のDockerがリリースされると、驚くぐらいの勢いで普及した*3。ウェブ・アプリケーションの開発や運用ではもちろん、エンドユーザー・コンピューティングになるデータサイエンス分野でも、無くてはならない道具のように言われている。
コンテナは仮想マシンと比較してリソース負荷がかなり軽い。アプリケーションの隔離なので異なるOSを動かすことはできないが、サーバーOSはLinuxに統一されつつあり、異なるOSを動かす必要は小さくなっている。また、Linux Kernelは、アプリケーションに対して、後方互換性を重視している。
さらにコンテナオーケストレーションツールによって、コンテナ化技術の特性を活かしたサーバー管理が行えるようになった。2014年に公開され、事実上のスタンダードとなったKubernetesでは、複数の計算機をクラスターとして運用し、統合的にコンテナを管理するだけではなく、どの計算機でどのコンテナーを動かすのかを自動的にスケジュールできるようになっており*4、大規模で複雑な運用にも適応できるようになっている。管理単位がOSになる仮想マシンではできない。
クラウド事業者も、IaaSから、PaaSとなるコンテナのホスティングや、それを土台にした機能単位のホスティング（FaaS）に流行が移っている。コンテナを動かすサーバーが必要なのに、サーバーレスと謎用語で呼んでいるのが気になるが。
3. 時代にあわせるべきか
コンテナオーケストレーションツールを導入して、オンプレミスのクラウド化を進めるのが世の潮流のようだ。アプリケーションの利用具合から、クラウド事業者とオンプレミスを適時スイッチできるようにすべきと言う話とも整合的になる。コンテナホスティングサービスとオンプレミスの間の移行がスムーズになる。
あわててコンテナオーケストレーションツールを導入する必要はない。動くアプリケーションが同じであれば、物理マシンで動いていても、仮想マシンで動いていても、コンテナ化されていても、エンドユーザーから見て大差ない。アプリケーションをコンテナ化しても、データベースやディスク装置の管理は別に要る。
Kubernetes職人や分散ストレージ職人*5がいれば良いのではあるが、クラスターを構成しないと試せないので、参入障壁は高い*6。生成AIがアドバイスしてくれそうな気もするが、ハルシネーションに騙されて業務システムをいじると、悲惨なことになりかねない。自宅の何台もの計算機でKubernetesクラスターを構成して練習している人もいるが*7。
2000年代のインフラ屋の皆さんは自宅にCISCOのルーターを並べて自慢（or 自虐）していたが、2020年代もライフスタイルは大差ないかも知れない。
*1JavaのApplication Serverであれば、アプリケーションに必要なファイルや設定はWAR型式でまとめて稼働中にアップロードと更新できるが、Application ServerとJVMの更新はできない。後方互換性があるので、JVMのバージョンを無理に固定する必要は乏しいが。
*2union mount filesystem．Linuxのメインストリームにマージされるのは2014年。
*3似たようなコンセプトのchrootがあったのだが、Dockerの方が隔離レベルが高く、imageとcontainerを分けるなど、概念的に深化している。
*4ひとたび設定すれば、後は完全に自動とは行かないようだ。
*5不特定多数のコンテナを扱う場合、共有ディスクやオブジェクトストレージを使わないと、データの永続化やコンテナ間のデータ共有ができない。スケーラビリティを考えると、共有ディスクも分散ファイルシステムでクラスタ化することになる。
*6仮想マシンを同時に複数立ち上げる方法もあるはずだが、試している人を見たことがない。
0 コメント:
コメントを投稿