SHARE

目次

目次

SHARE

クラウド&インフラストラクチャ

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

infra study meetup #2 第1部 アイキャッチ画像
Forkwell が主催する技術イベント「Infra Study」。今回は「VM時代の開発とCloud Native時代の開発」というテーマで開催しました(開催日:2020年 5月20日)。Docker や Kubernetes の普及とともに近年バズワードのようにも語られ始めた Cloud Native について、サイバーエージェントの青山 真也さんをお招きして、その思想や未来像を紹介していただきました。それでは青山さんの基調講演内容を抜粋してお伝えします。

ここ数年でDockerやKubernetesが広く普及し、合わせてクラウドネイティブというワードがバズワードのように語られる一面も見かけるようになりました。正しくクラウドネイティブを実現するためにも思想を正しく理解したうえで Kubernetes などの技術スタックを選択していく必要があります。思想を正しく理解しないまま選択することは、こういった技術スタックをVMの代わりとして使ってしまいかねません。本セッションでは、クラウドネイティブが目指すものを紹介したうえで Docker/Kubernetesを用いた開発はどのように変わるのかを従来のVMを用いた開発と比べて紹介することで、Kubernetesにまだ明るくない方向けにわかりやすく紹介します。また最後にはKubernetesのコアともいえるReconciliation loopの仕組みと拡張性についても紹介し、期待する未来像についても紹介します。

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

私はサイバーエージェントでソフトウェアエンジニアとして働いている青山です。普段は 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 で載せたい気持ちはあるでしょうし、そもそもクラウドで色々な機能があれば、そっちを利用した方がいいと思います。


Forkwellキャリア相談

フォークウェルプレス編集部

Follow

記事一覧へ

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

青山 真也
さくらインターネット株式会社

客員研究員

#Kubernetes 完全ガイド 著者、#CNDT2019 #CNDT2021 Co-chair、#cloudnativejp #k8sjp #KubeConJP Organizer、さくらインターネット研究所 客員研究員、CREATIONLINE 技術アドバイザ、3-shake 技術顧問、PLAID