青山氏が語った、「クラウドネイティブ」がやがて「Kubernetesネイティブ」へ進む理由：仮想マシン時代とクラウドネイティブ時代の違い（1/2 ページ）

青山真也氏は2020年5月20日、Forkwell主催のオンラインミートアップで、仮想マシン時代の開発とKubernetesによるクラウドネイティブな開発のこれからについて話した。この講演を要約してお届けする。

　「5年後、オンプレ環境でデータベース以外はKubernetesで稼働している状態が実現し、パブリッククラウドではKubernetes上で全てが管理されている状態になる」――。サイバーエージェントのソフトウェアエンジニアで、プライベートクラウドKubernetes基盤のプロダクトオーナーである青山真也氏は2020年5月20日、Forkwell主催の「Infra Study Meetup #2」で、「VM 時代の開発とKubernetes による Cloud Native な開発のこれから」について話した。

　本記事ではこの講演を要約してお届けする。掲載に当たっては、青山氏のチェックを受けている。

「クラウド利用＝クラウドネイティブ」ではない

　以前、アプリケーションは物理マシン上で構築・運用されていたが、その後集約率を向上するために、仮想マシン時代に移行した。この環境では、アプリケーションはペット的な存在で、可用性などはインフラ側で担保するようになっていた。

　やがてWebサービスの普及によりスケーラブルなシステム設計と運用のニーズが拡大したことを受けて、無尽蔵なリソースを使える環境や、データベースなどのマネージドサービスを提供するパブリッククラウドが登場し、その利用が拡大した。同時に大規模なインフラを管理する考え方として、「Immutable Infrastructure」や「Infrastructure as Code」が広まっていった。一方、DevOpsの普及も進んだ。

　それでもパブリッククラウドが登場した当初は、まだ第2の仮想マシン時代だった。これが2016年ごろからもう一段進化し、クラウドネイティブな時代に移行してきたと考える。

　クラウドネイティブな時代とそれまでには、根本的な違いがある。クラウドネイティブ以前は、インフラ側からアプリケーション開発・運用ニーズに対応するアプローチがなされてきた。クラウドを使えば無条件にクラウドネイティブかというと、そうではない。一方、クラウドネイティブは、「アプリケーションを動かすために最適なインフラをどう作ればいいか」を考えて生み出されてきた。その主眼は、「開発したものを即座に、安定的に提供する」ことにある。

　こうした思想から生まれたものの例として、DockerやKubernetesがある。本講演ではこれらをもとに紹介するが、クラウドネイティブを実現する方法は他にもあるだろう。

　Dockerのようなアプリケーションコンテナは、アプリケーションと動作環境をパッケージングできるところに、これまでとの大きな違いがある。さらに開発者でもイメージのビルドは容易で、アプリケーション起動に要する時間も、物理マシン上で直接起動する場合とほぼ変わらない。

　一方Kubernetesは、「アプリケーションの実行を第一に考えた時にどういうインフラを作るかを主軸に設計されたインフラ基盤」だと考えられる。このために開発者からも運用担当者からも支持されている。

　Kubernetesでは、さまざまなリソースをYAML形式のマニフェストで登録し、Kubernetesで操作できる。コンテナアプリケーションだけでなく、データベース、サーバレス、バッチジョブなどを定義して登録し、自動的に実行したり、運用を自動化したりできる。「X as a Service」を実現できるKubernetesは、小さなクラウドだとも表現できる。

仮想マシン時代とクラウドネイティブ時代の、インフラと開発面での具体的な違い

　仮想マシン時代とDocker／Kubernetesによるクラウドネイティブ時代では、インフラ担当者、開発者にとって具体的にどのような違いがあるのだろうか。

イメージ化による、「即座に安定した」ビルドからデプロイのプロセスの実現

　インフラ面から見ると、従来の仮想マシンの世界では、例えばTerraformで仮想マシンを起動し、ChefやAnsibleなどのツールで設定して、Jenkinsなどによってアプリをデプロイする。あるいはPackerなどで仮想マシンのベースイメージを作成してTerraformで起動し、アプリをデプロイするだけにする。いずれにしても、デプロイの完了までに時間が掛かる。また、複数のツールの習得が必要になる。

　一方、Docker／Kubernetesの世界では、Dockerfileを用いてイメージのビルドを開発者が実行する。コンテナイメージにアプリケーションやミドルウェアが環境ごとパッケージングされるため、同じ状態での起動が保証されるようになっている。あとはKubernetesのマニフェストを記述することで起動すればいい。

　では、開発者から見た場合はどのような違いがあるか。

　従来はコードのリポジトリに対してプッシュすると、CI（Continuous Integration：継続的インテグレーション）ツールが動作し、テスト後にコンパイルされたバイナリをどこかに置いて、これをCD（Continuous Delivery：継続的デリバリ）ツールで仮想マシンにデプロイする流れになる。

　Docker／Kubernetesの世界になると、コードのリポジトリに対してプッシュすると、環境込みのコンテナイメージが作られる。すると、そのコンテナイメージを使うように、マニフェスト用の別のリポジトリに保存されているインフラの構成情報であるKubernetesのマニフェストが更新される。CDツールではこのマニフェストに基づき、デプロイを行えばいい。アプリケーションの実行を主体としたマニフェストが保存されているため、アプリケーションの状態がコード化して見られるようになる。

　この場合、アーティファクトはコンテナイメージとマニフェストだけなので、外部に依存する部分さえ用意すれば手元でも再現が可能になる。