「Kubernetes-native」へと舵を切るCloud Foundry、その理由と展望は？：草間一人氏が解説（1/2 ページ）

Cloud Foundryは、「Kubernetes-native」への移行という大きな変革の途上にある。具体的にはどのような取り組みが進行しているのか。背景と展望を含めて、PaaS研究会を主宰する草間一人氏が解説する。

[草間一人，著]

　Cloud Foundryは、Cloud Foundry Foundation（CFF）が中心となって開発しているオープンソースのプラットフォームである。2011年の登場以降進化を続け、今ではフォーチュン500企業のうち半分で利用されるまでに成長した。

　そのCloud Foundryが今、大きな変革の時を迎えている。

　2020年4月、CFFのExecutive Directorに就任したチップ・チルダーズ（Chip Childers）氏は、自身のブログポストで、同コミュニティーの現在におけるフォーカスはCloud FoundryプラットフォームをKubernetesベースに進化させることにある旨を明らかにした。

Cloud Foundryが実現してきた価値と、その仕組み

　デジタルトランスフォーメーションという言葉をよく聞く昨今。企業の規模に関わらず、アイディアをいかに素早く実現し、世の中に提供できるかが重要になりつつある。また、市場からのフィードバックを生かして素早くサービスに反映していくことも大切だ。

　そのためには、サービスに関連するアプリケーションを、いかに素早くデリバリーしていくかを考えなければならない。初回構築だけでなく繰り返し行うアップデートも同様だ。また、近年ではマイクロサービスのように複数のアプリケーションを同時に運用するのが当たり前になりつつある。このような環境では、デリバリーに関するほんのわずかなタイムロスですら、全体を通すと大きな損失につながりかねない。

　Cloud Foundry――正確にいうと「Cloud Foundry Application Runtime（以下、CFAR）」は、そのようなアプリケーションの開発と運用を支援するプラットフォームだ。

　CFARを利用するアプリケーション開発者は、手元で“cf push”という非常に簡単なコマンドを打つだけで、アプリケーションを世の中に公開できる。それだけでなく、監視やログの収集なども自動化されており、運用コスト削減につながる。

　従来の方法であれば、デプロイの前にはサーバやネットワークなどのインフラの調達と設定、安定した運用のためにログの収集や監視の設定も必要だった。CFARはこのあたりが全て自動化されており、ものの数分でアプリケーションの公開が出来てしまう。

　昨今では、DockerやKubernetesのコンテナ技術がDevOpsというキーワードと共に注目されており、冒頭にも記した素早い運用のために活用されつつある。それとCFARは何が異なるのだろうか。PaaSは触ったことがないが、DockerやKubernetesであれば経験があるという人もいるだろう。これらの方法を比較したのが以下の図である。

　Kubernetesとの比較においても、より簡単にアプリをデプロイできることが分かるだろう。

　この仕組みを実現するため、CFARは多くのコンポーネントを独自に実装し、組み合わせる形を取ってきた。詳細は割愛するが、ざっくりまとめると「コントロールプレーン」「コンテナオーケストレーター」の２グループに分けられる。

　コントロールプレーンにはCFAR自体の操作を行うAPIや、認証・認可の仕組みが含まれている。アプリケーション開発者はCLIやCI/CD（継続的インテグレーション／継続的デプロイ）ツールを経由して、このコントロールプレーンにアプリケーションをアップロードする。

　アップロードされたアプリケーションは内部でコンテナイメージへの変換が行われた後に、コンテナオーケストレーターの上で稼働する。

　これらのコントロールプレーンやコンテナオーケストレーターは、「BOSH」と呼ばれる仕組みによって管理される仮想マシンの上で稼働している。

　BOSHはCFARに限らず、運用の難しい分散型アプリケーションをIaaS上で管理できる汎用的な仕組みとして作られている。そこでCFFは、BOSHの上でKubernetesを構築・運用できる「Cloud Foundry Container Runtime（以下、CFCR）」を2017年にリリースした。こうして、Cloud FoundryはPaaS（Platform as a Service）であるCFARと、CaaS（Container as a Service）であるCFCRの2プロジェクトを包括する存在になった。

Kubernetes化の動き

　複数ユーザーのアプリケーションがマルチテナントで動くPaaSは、コンテナ技術と親和性が高い。リソースのオーバーヘッドを抑えつつ、適切な隔離ができるからだ。例えば「コンテナ」と言われて真っ先に名前が挙がるDockerは、元々はdotCloudというPaaSから派生して生まれたものだ。

　今、コンテナオーケーストレーターとして最も有名なのがKubernetesである。コミュニティーは大変な盛り上がりを見せており、各企業での利用も広がりつつある。一方、CFARはKubernetesが生まれたばかりの頃から、「Diego」という独自のコンテナオーケーストレーターを利用している。これはcf pushでデプロイされるアプリケーションだけでなく、Dockerイメージの実行も可能など、PaaSとして利用するには必要十分な機能を備えている。しかしKubernetesの盛り上がりを受けて、Diegoを置き換えようという動きが生まれ始めた。

　そうしてIBMやSUSE、SAPによって始められたのが「Eirini」である。Eiriniを利用すると、CFAR利用者はKubernetesとDiegoを選択できる。Kubernetesを選択すると、開発者がデプロイしたアプリケーションはPodとして動作するようになる。

　さらにこういう考え方もできる。Kubernetesを利用するのであれば、CFARのコントロールプレーンもコンテナ化して、その上で動かしてしまえばいいのではないか？　そうして登場したのが、「Project Quarks」だ。このプロジェクトは、BOSHの仕組みをエミュレートすることで、従来仮想マシンとして立ち上げていたものをKubernetesでコンテナとして動かせる。

　このEiriniとQuarksによって、Kubernetes上にCFARの全てを載せることが可能となった。2020年3月、CFFは「KubeCF」というインキュベーションプロジェクトを受け入れた。これはSUSEが中心となって開発を進めているCFARのディストリビューションであり、同社の「SUSE Cloud Application Platform」のベースとなっている。

Kubernetes化による利点

　そもそも、CFARをKubernetesに載せることによるメリットは何だろうか。

　アプリケーション開発者の観点で言うと、CFARの開発体験をKubernetes上でも享受できる。Kubernetesの利用は広がりつつあるが、開発者からは「Kubernetesは難しい」「YAMLで定義していくのは面倒」という声も聞かれる。

　一般的に、柔軟性と簡易さはトレードオフの関係にある。Kubernetesが注目されたのはその柔軟性にあったが、一方でKubernetes独特の概念の習得やYAMLでの定義、コンテナイメージ作成のためのDockerfile作成などの一手間が必要だ。「とにかくアプリが良い感じに動いてくれれば良い」と考える開発者には、この一手間が負担に感じてしまう。