Kubernetesはいかに大規模コンピューティングの主役となったのか（前編）
Kubernetesが注目される理由 ― クラウド時代の新しい標準
現在、多くのベンダーが、規模を問わずさまざまな組織にクラウドサービスの導入を勧めています。その中でも、開発者やシステム管理者に対して専門家たちが特に強く推奨しているのが Kubernetes（クバネティス） です。
Kubernetesを習得すれば、あらゆるクラウドサービス上でプログラムを実行できるようになります。そして、世界中の企業における仕事のチャンスも大きく広がります。
本シリーズでは、Kubernetesが2015年の初回リリース以降、なぜこれほど短期間で中心的な存在になったのかを解説します。
そのために、コンテナの仕組みを、コンピューター資源を共有する他の代表的な2つの形態と比較していきます。
- 仮想マシン（Virtual Machines）
（Infrastructure as a Service：IaaS） - Functions as a Service（FaaS）
さらに、Kubernetesが、特にDockerを中心とする豊かなコンテナ技術の環境の中でどのように登場し、それまで存在していた仕組みを活かしながら発展していったのかも紹介します。
なお、このシリーズでは「サーバーレスコンピューティング」という言葉は使いません。その理由は、この言葉が曖昧で、PaaSにもFaaSにも使われることがあるためです。そして何より、少し誤解を招く表現でもあります。というのも、実際には必ずどこかにサーバーが存在するからです。
Kubernetesは、LPI DevOps Tools Engineer認定資格でも扱われています。
コンピューター資源共有の代表的な3つの形態
このシリーズの読者の多くは、IaaS、Platform as a Service（PaaS：コンテナ化が含まれる領域）、そしてFaaSの違いをすでに理解しているかもしれません。
ここでは、それぞれの歴史を簡単に紹介しながら、どのような用途に向いているのか、そしてどのように普及していったのかを見ていきます。
まずは基本から整理してみましょう。
IaaS（仮想マシン）
IaaSでは、OSやドライバを含む「ひとつの完全なコンピューターシステム」をエミュレートした環境が、別のシステムの上で動作します。
複数の仮想マシン（VM）は同じハードウェアとホストソフトウェア（ハイパーバイザー）を共有しますが、それぞれは互いを認識できず、他のVMの存在も見えません。
PaaS（コンテナ化）
PaaSでは、アプリケーションとその実行環境（ライブラリ、場合によってはログ機能などの補助サービスを含む）が、共有OSの上で独立して動作します。
DockerやKubernetesは、このPaaS全体を構成する要素の一部です。
FaaS
FaaSでは、独立したステートレスな関数が、ホストシステムが提供するプラットフォーム上で実行されます。そのプラットフォームには、関数を動かすために必要な環境があらかじめ用意されています。
この3つを比べると、段階が進むにつれて、ホストシステムとそのベンダーがより多くのソフトウェアと責任を担うようになります。
その結果、利用者側の開発者やシステム管理者は、自分たちが管理すべきソフトウェアの範囲を絞ることができます。
IaaSもFaaSも重要な技術ですが、Kubernetesはそれらを大きく上回る勢いで普及し、PaaSの分野でも圧倒的な存在となっています。
まずは仮想マシンとFaaSの歴史を見て、そのあとでコンテナ化について掘り下げていきます。
仮想マシン
完全なコンピューターシステムをエミュレートするという考え方、そしてそれを低コストで顧客に提供するという発想は、かなり古くから存在していました。
IBMは1967年の時点で、System/360 上で仮想マシンをサポートしていました。System/360は、1960〜70年代に「コンピューター」といえば真っ先に思い浮かぶほど有名な存在でした。
その後、
と、仮想化技術は広がっていきます。
また、1台のデスクトップPC上で複数のコンピューター環境を個別に動かせるエミュレーターも多数存在しました。
代表例のひとつが QEMU です。QEMUは2003年に登場し、GNU/Linux上で広く利用されています。
仮想マシンの大きな利点
仮想マシンの大きなメリットは、ホストOSとゲストOSを別々にできることです。
多くのクラウドベンダーはホスト側にLinuxを採用していますが、顧客の中にはWindowsを動かしたい企業も多くあります。
たとえば Microsoft Azure は、その名の通りWindowsホスト上で動いています。
このように、利用者は自分の用途に合ったOSを自由に選べることが、仮想マシンの強みでした。
2013年にDockerが登場するまでは、仮想マシンは最先端技術と考えられていました。
しかし、仮想化には標準化が不足しており、それを補うためにさまざまな取り組みが行われました。
代表的なオープンソース実装として、
があります。
XENは2003年にオープンソースとして公開され、「Linuxが仮想マシンのホストになれる」ことを示しました。Amazon EC2やGoogleも、かつてクラウド基盤にXENを利用していました。
KVMは2006年に登場しました。
（QEMUとXenは、LPIC-3 Virtualization and Containerization認定でも扱われています。）
OpenStackという標準
仮想マシンの分野で最も大きな標準といえるのが OpenStack です。
OpenStackは、大手ホスティング企業Rackspaceの技術をもとに構築され、2010年に発表されました。
非常に野心的なプロジェクトであり、
など、30以上のソフトウェアコンポーネントで構成されています。
OpenStackは、膨大なデータ管理が必要な企業に適していると言えるでしょう。
たとえば、何百万もの顧客向けクラウドサービスを運用し、会計、監視、可観測性など、企業に必要な機能を包括的に提供できます。
ただし、それ自体がひとつの巨大な世界でもあります。
著者はOpenStackを、過去の巨大な標準化の試みに重ねています。
ひとつは CORBA（Common Object Request Broker Architecture）。
これは独立したプログラム同士を連携させるための仕組みでしたが、あまりにも多くを実現しようとした結果、複雑化しすぎて広く定着しませんでした。
最終的には、WebベースのRESTモデルが、多くの課題を解決することになります。
もうひとつは DCE（Digital Computing Environment）。
複数企業の製品を組み合わせ、ローカルネットワーク全体をひとつのコンピューターのように見せようとした仕組みです。
しかしこちらも、実装の複雑さや互換性の問題により広く成功することはありませんでした。
現在、OpenStackを利用している企業は5,000社以上あるとされています。
これは十分大きな規模ですが、Kubernetesと比べると差があります。
Kubernetesは、企業の約60％で利用されていると推定されています。
なぜ仮想マシンよりコンテナなのか
仮想マシンの重要性が低下した理由は明確です。
コンテナの方が圧倒的に軽量だからです。
そのため、
- 起動が速い
- ユーザー負荷の急増に対応しやすい
- 運用コストが低い
というメリットがあります。
さらに、多くの開発者がLinuxをアプリケーション実行環境として選ぶようになったため、「ホストOSと別のOSを使える」という仮想マシンの強みも以前ほど重要ではなくなりました。
仮想マシンでは、必要な環境を作る作業そのものが大きな負担になります。
サイズやコストを抑えるためには、
- 不要なデーモン
- 不要なユーティリティ
- 不要なライブラリ
を細かく取り除く必要があります。
コンテナでも同じ考え方は重要ですが、OSそのものを含めないぶん、はるかにシンプルです。
セキュリティ面については、コンテナのほうが侵害されやすいという指摘もあります。
たしかに、VMハイパーバイザーにも、コンテナを支えるOSにも脆弱性は見つかっています。
ただ著者は、「コンテナのほうが安全性が低い」と単純に決めつけることには疑問を持っています。
Googleも、「重要なのはVMかコンテナかではなく、安全な開発手法を採用しているかどうかだ」とする見解を公開しています。
FaaS
IaaSとPaaSは、自社運用も可能ですが、サードパーティベンダーのサービスを利用すると大きなメリットがあります。
一方で、FaaSは基本的にベンダー利用を前提とした仕組みです。
もし自分のハードウェア上で関数を動かしているなら、それは単に通常のプログラム実行にすぎません。
FaaSの魅力は、管理作業のほとんどをベンダーに任せられることです。
その反面、別のベンダーへ移行する際には多くの作業が発生する可能性があります。
FaaSは、特定の用途では非常に優れています。
たとえばWebサーバーです。
多くのWebサーバーはすでに高いモジュール化が進んでおり、ユーザーごとのリクエストを個別に処理します。
そのため、
- 一時的に関数を起動する
- 状態は外部データベースに保存する
というFaaSの仕組みと非常に相性が良いのです。
FaaSの関数は イベント駆動型 です。
外部で何かが起きたとき、それをトリガーとして関数が実行されます。
必要に応じて複数インスタンスにスケールし、処理が終われば停止します。
そのため、
「入力を受け取って結果を返し、その後は待機状態になる短時間の処理」
に向いています。
しかし、多くのアプリケーションはもっと複雑です。
実際には、
- 複数レイヤーの機能
- 補助サービス
- データベース以外の状態管理
などが必要になります。
FaaSでは、その多くを開発者自身が別途実装しなければなりません。
つまり、
- 仮想マシンは「多すぎた」
- FaaSは「少なすぎた」
ということです。
その中間にあった理想的な答えが コンテナ化 でした。
ただ、分散プログラミングが広がり始めた当初、コンテナ向けに使いやすく高機能なソフトウェアはまだ存在していませんでした。
PaaSサービスはありましたが、
- ベンダーロックインが強く
- 開発者が求める機能を十分に備えていませんでした
それが変わったのが 2013年。
「コンテナの年」とも言える年です。
コンテナの物語は、本シリーズ第2回へと続きます。
