改めてコンテナのメリットを整理する
アプリケーション開発においては、テスト環境と本番環境を構築する場合が一般的である。どんなに準備されたアプリケーションであってもテスト環境と本番環境の差異が生じてしまい、その差を埋めるのはなかなか難しかった。アプリケーション構造の可視化が難しく、セキュリティや監視などの非機能要件が混在し複雑化しているからだ。
そこで登場したのがコンテナ技術だ。最小単位のユニットにソフトウェアをパッケージして、アプリケーションを素早く構築、テスト、デプロイできる。コンテナプラットフォームの「Docker」は、1つのLinux OSの上にインストールし、その上にコンテナが複数展開される構造になっている。コンテナ自体はLinux OSのカーネルを使って動作する。
コンテナ技術の特長としては、以下のようなものが挙げられる。
- オンプレミスやクラウドを問わずビジネス要件に合わせて最適なアプリケーションの稼働環境を選べるポータビリティ
- 軽量な実装による高速な立ち上がりが可能なスピード
- クラウドネイティブなテクノロジーの適用
ビジネス環境の変化が激しい時代に対応する、次世代アプリケーションの要件にマッチしていると言える。一見するとコンテナは、仮想マシン（VM）と類似しているが、VMがOSを所有しているのに対して、コンテナはOSを共有しているという点で大きく異なる。
コンテナはより開発者の視点に立った仕組みである
VMの場合、アプリケーション開発のためにインフラ担当が環境を用意していたが、コンテナの場合はアプリケーション開発者が環境を整備できる点も異なる。コンテナでは、新しいコードを頻繁に展開したり、新機能や改修をリリースするまでの期間が短くなったりするなど、迅速性の向上が見込まれる。
コンテナの弱点とそれを補うKubernetesの登場
優れた点の多いDockerコンテナだが、Docker単体ではエンタープライズレベルの要件を満たせないこともある。最大の課題はマルチホストに対応できないこと。例えば、アプリケーションをスケールするためにロードバランサーを用意したり、アプリケーションとデータベースを分離したり、ホストに障害が発生した時に自動復旧したりといった要件には、Dockerだけは対応できない。コンテナ自体が生まれては消えるため、ロードバランサーの負荷分散の設定が難しく、データベースの接続や、障害復旧時のデータの引き継ぎも困難なのだ。
Dockerは自分自身がインストールされているホストのコンテナしか管理できない
こうしたDockerの弱点を克服すべく登場したのが、コンテナオーケストレーションプラットフォームのKubernetesだ。オーケストラの指揮者のように、たくさんのコンテナを統合管理する仕組みで、マルチホストに対応し、ロードバランサーの自動配備、オートスケールにも対応し、障害発生時の自動復旧も可能と、Dockerの弱みを補う機能を備えている。同様の仕組みは他にも「Docker Swarm」「MESOS」などがあるが、その機能性からKubernetesが多く利用されている。
Kubernetesという名称はギリシャ語に由来しており、操舵手やパイロットを意味する。もともとは3人のグーグルのエンジニアによって生み出されたもので、現在はオープンソース化されており、開発者のうち2人は現在、ヴイエムウェアに在籍している。
Kubernetesは、コンテンツを管理するノードと、コンテナが実行されるノードによって構成され、マニフェストという定義ファイルの情報をもとにコンテナを制御する。これによって、ホストの負荷状況を見て、最適なアプリケーションの展開先を選定できるし、死活監視と自動復旧も可能となる。本番環境のミドルウェアアップデート時にアプリケーションが動作しなくなってしまうという問題にも対処可能だ。
Kubernetesクラスタの内部構造。マニフェストによって動作の指示を行う
開発環境でのミドルウェア アップデートでの動作を確認したら、そのコンテナをイメージ化し、本番のアップデート時に適用する。このようにKubernetesは、特にエンタープライズ向けで、ユーザー体験向上のために頻繁に更新する必要のあるアプリケーション開発に向いているといえる。更新頻度が少ないアプリケーションを無理にKubernetesに乗せる必要はないと考える。
