Kubernetesが必要になるまで〜Dockerの登場〜
マイクロサービス化したからといって何もかも解決するわけではありません。アプリケーションを小さく分割すると、これまでに比べてたくさんのコンポーネントを運用する必要がでてきます。つまり、コンポーネント毎に運用環境へのインストール方法、起動方法などを用意して管理しなければなりません。これら全てを手順書などに起こして管理するのは大変ですよね。また、運用環境自身の問題もあります。これまで1つの仮想マシンに1つのでかいアプリケーションを乗せて運用すれば良かった世界から、1つあるいは複数の仮想マシンにまたがってたくさんのコンポーネントを乗せて運用する複雑な世界になるわけです。
ここで、運用を助けてくれるDocker（そしてコンテナ技術）の登場です。アプリケーションをコンテナ化し、Dockerの「Build、Share、Run」の仕組みにのせることでマイクロサービスと相性の良いインフラ環境を構築できます（コンテナ技術自体はDockerの登場よりもはるか昔からありますが、ここではなぜDockerが流行したかについて省略します）。
では「コンテナ」とはなんなのか？ アプリケーションの運用環境として比較されることの多い「仮想マシン」と「コンテナ」について見ていきましょう
こちらは左側が仮想マシン、右側がコンテナを利用した場合の簡略的な図です。
コンテナは仮想マシンを利用した場合に比べてハイパーバイザーを起動するレイヤが省略できます。またOS丸ごとではなく必要なプログラムを実行するだけなので、一般にコンテナは仮想マシンに比べて早く起動できます。また、アプリケーションがコンテナに隔離されているためお互い干渉しあったり、権限の分離がうまくできたりするため非常に便利です。
これらの特徴がマイクロサービスと相性が良いのは想像に難くないのではないでしょうか。
仮想マシンに比べて、コンテナ技術は小さいアプリケーションを開発するには非常に便利ですが、アプリケーションを本番運用しようとすると多くの課題があります。
- コンテナの仕様や設定を個々に管理するのが大変
- 冗長化のために複数台サーバーを利用してコンテナを起動したいとき、「どのサーバーに」「どのコンテナを起動するか」を決定することが難しい
- 障害発生時に、各コンテナの設定・障害復旧を実施／管理しなければいけない
などです。
ではこれらの課題はどうやって解決したら良いでしょうか？
