1/3「VM時代の開発とKubernetesによるCloud Nativeな開発のこれから」サイバーエージェント 青山 真也

本日はこのテーマでこれまでとこれからのお話をベースにお話させていただきたいと思います。

私はサイバーエージェントでソフトウェアエンジニアとして働いている青山です。普段は Kubernetes as a Service を自社で開発してるので、そのプロダクトオーナーとして活動しています。また前の上記の図のようにコミュニティの活動もしております。

Forkwell さんとは昔からの知り合いでして、Cloud Native Meetup Tokyo で何回かスポンサーをしていただいています。

ここでいうVM時代とは？

まずはタイトルにある「VM時代」が何を示してるのかを紹介していきます。

物理マシン時代

今回は歴史を4つに分けました。

あくまでも私個人の考えなので、年代は立場や会社によって異なると思います。物理マシンの時代は、数台だけ大きめのサーバーを用意して、そこでアプリケーションを動作させているので台数も少なく、1台1台を大切に扱っていました。

仮想マシン時代（1）

次に仮想マシンが登場し、サーバーがメニーコア化して、仮想化技術も広く普及してきて、集約率を上げるために、物理マシンの代替として仮想マシンを使う時代が訪れました。このときはまだ VM はペットとして、1台1台大切に管理するような方式が多かったです。

この頃からコンテナ技術はあり、VM の代替としてのコンテナ技術は、すでに存在していました。いわゆる System Container と呼ばれるものですね。

仮想マシン時代（2）≒ Cloud 時代

その後、業界的に Webサービスが広く普及すると、よりスケーラブルなシステムを設計したくなります。世の中的にもニーズに応えるためにクラウドが普及し、無尽蔵なリソースがクラウド上にあるようになります。さらにマネージドサービスもたくさん普及してきました。

そういった環境で、効率的に大規模になったインフラを安定的かつ効率的に管理するために、Immutable Infrastructure や Infrastructure as Code、DevOps などの考え方が広く普及してきたのが、この時代かなと思います。

Cloud Native 時代

このクラウドの時代からもう一歩進化したのが、いわゆる Cloud Native な時代だと思います。1個前の仮想マシンの第2世代は、自分が見てると、あくまでもインフラ側から寄っていったと思ってるんですね。インフラ側から寄っていき、アプリケーションをどういうふうに実行するのがいいのかを考えて作った方法かなと。

Cloud Native は、個人的にはもうちょっとアプリ側から寄っていった、もしくはアプリ側とちゃんと歩幅を合わせてアプリケーションを動かすために最適なインフラをどう作ったらいいのか、それを考えて作り出されたインフラであり、そういったものが Cloud Native の発端、もしくは最初の思想なんじゃないかなと思います。

アプリケーションを開発したものを即座に安定的に提供するには、どのようなインフラがいいのかを考えられてきたのが、Cloud Native な時代かなと思います。

アプリケーションを主体としてアプリケーションを実行するために、最適なインフラの形を模索しているのがこの時代の特徴なので、サーバーやPaaS、場合によっては VM をうまく扱うような方法も、Cloud Native な時代にあったアプリケーションの開発手法といえると思います。

今回紹介する Docker と Kubernetes も、今こそなんとなく Cloud Native の代名詞として名前が一緒に出てくるプロダクトですが、そもそも各社パブリッククラウドもアプリケーションを主体としてうまく動かすにはどうしたらいいのかという思想で、クラウド時代後期ぐらいから徐々に取り組んでいたと思います。

こういった思想から生まれたものの一つがDocker とか Kubernetes なので、一概にクラウドを使うことが Cloud Native ではないと思います。

Docker の良かった点は、正しくアプリケーションを動かすための動作環境とアプリケーションをパッケージングして、気軽に使えるところ。あとは開発者にとって、ビルドの容易性が非常に良かった。また VM みたいに重いものではなくて、開発者がアプリケーションを起動させるのと同じような使用感で、どこでも動かせるのがすごい良かったんじゃないかなと。まとめると、デベロッパーエクスペリエンスの良さが挙げられます。

Kubernetes に関しては、あとで Reconciliation モデルの話はしますが、一言で例えるならアプリケーションの実行を第1に考えたときにどういうインフラを作るかを主軸に設計された基盤、だと思うんですね。Dev からも Ops からも支持されてみんなが使うような基盤になったんじゃないかと思います。

CNCFが言うCloud Nativeとは？

CNCF が「Cloud Nativeとは」の話をしているんですね。一応定義があるんですけれど、

定義をテクニカルにまとめると、こういうシステム特性を持ってるシステムを、オープンなテクノロジーを使ってスケーラブルに実現する、またはしている状態。これを Cloud Native といいます。

歴史的背景を取り読んだうえで意訳すると、昔とは異なって Dev や Ops が一緒に考えて、アプリケーションの実行基盤を最適に再定義したものが、Cloud Native だと思います。

インフラから寄っていくだけでなく、一緒に考えたものが、Cloud Native なので、クラウドの延長線上の進化系なのかなと思います。これにより開発したものを即座に安定的に実行できるのが特徴です。

CNCF はオープンソースを推奨しますと書かれてるんですけど、個人的には必須でないとも思っています。Cloud Native という汎用的なワードを使ってるので、これを強制するのは良くないかなと。

Kubernetes Concept 101

今回は Kubernetes による Cloud Native な開発がメインのテーマなので、Kubernetes の話をします。

Kubernetesと「リソース」

Kubernetes は Google の Borg （クラスタマネージャ）から着想を得た基盤です。さまざまな自動化とか、自動連携機能がたくさん盛り込まれてます。Kubernetes はさまざまなものをリソースという単位で扱えます。リソースは、YAML 形式のマニフェストで記述して、Kubernetes に登録することで、Kubernetes を操作する形です。

今回の例だと、Nginx のコンテナアプリケーションを3つ。 Kubernetes 上に起動することを意味しています。

『X as a Service 基盤』としてのKubernetes

Kubernetes では、自由にリソースを拡張できます。たとえば MySQL のクラスタを作ってくださいとマニフェストを書いて、Kubernetes に登録すると、実際に Kubernetes 上で、MySQL のコンテナが複数立ち上がってデータベースクラスタを組んでくれたり、あとはその運用を自動的にやってくれる機能も持たせることができます。

Kubernetes はちょっと小さなクラウドっぽくも見えたりするんですね。今回ステートフルなものを中心に紹介しましたけど、他にも、ML の基盤やサーバーレス、バッチジョブみたいな色々なものを独自に定義して、Kubernetes に登録すると、その機能を開発者が使えたりします。

クラウド環境とCloud Native

このあたりの話を聞くと、現実とのギャップを感じる方もいると思います。

横並びにしてみると、Kubernetes やクラウドにも同じ機能がある状態になるんですね。Cloud Native を目指しましょうといったときに、Kubernetes をやる必要はなく、さっきいったことを目指せば、それは Cloud Native だと思います。

なので、コンテナを使わなくても、極論 Cloud Native なアーキテクチャとか、状態は作れると思います。逆に Kubernetes は使うけど、従来の VM っぽい使い方しかできないんだったら、やめた方がいいです。

Managed Kubernetes on Public Cloud

 

特に最近の環境は、クラウド上に Kubernetes がいるので、かなりややこしいです。

Kubernetes 導入の進め方

基本的に最初は VM に乗っかっているWorkload を、Kubernetes 上で実行するところだけ Kubernetes 化していき、あとは適宜クラウドと共存していくのがいいと思います。

この共存レベルは、クラウドによって異なります。オンプレ勢からすると、色々なものを Kubernetes で載せたい気持ちはあるでしょうし、そもそもクラウドで色々な機能があれば、そっちを利用した方がいいと思います。

---