Pivotal Cloud Foundry 2.0、「Kubernetesに負けた」わけではない理由：Pivotalのスコット・ヤラ氏に聞いた

　Pivotalは2017年12月、Pivotal Cloud Foundry 2.0（以下、PCF 2.0）を発表、これを日本法人のPivotal Japanが2018年3月に国内発表した。最大の目玉は、新製品としてKubernetes環境を提供することにある。

　これについて、2018年1月に来日したPivotalの製品担当シニアバイスプレジデントであるスコット・ヤラ氏は、筆者に次のように話した。

Pivotalの製品担当シニアバイスプレジデント、スコット・ヤラ氏

　「これは、『Cloud Foundryが勝つか、Kubernetesが勝つか』という問題ではない。Cloud Foundryが適している用途では、Cloud Foundryが開発者および運用者の生産性を最も高められる存在だ。だが、Cloud Foundryで全ての用途をカバーできるわけではない。だから選択肢としてKubernetesを提供する。PCFには今後、サーバレスコンピューティング（Function as a Service：FaaS）の選択肢も加わる。これでPaaS、CaaS、FaaSの3大（クラウドネイティブプラットフォーム）技術が揃うことになる」

　つまり、PaaS、CaaS、FaaSのいずれも、全ての用途に適しているとはいえない。だから、クラウドネイティブアプリケーション開発・運用の世界で単一の「勝者」はない。

　「従って、統一的な管理の下で、これらのプラットフォームをアプリケーションに応じて使い分けられることが、今後顧客にとって重要になる」

　では、Cloud FoundryとKubernetesのそれぞれに適している用途とは何か。2018年3月の国内発表で、Pivotal Japanリードプラットフォームアーキテクトの市村友寛氏は、次のような図を示して説明した。

PaaSとCaaSは、それぞれどのような用途に適しているか

　図内の「PAS」は「Pivotal Application Service（PAS）」、つまり従来の「Pivotal Cloud Foundry」で、「PKS/k8s」とあるのは「Pivotal Container Service（PKS）」／Kubernetes（k8s）のことだ。

　市村氏によると、典型的なクラウドネイティブアプリケーションともいえる12ファクターアプリケーションなどでは、PASの方が開発者・運用者にとっての生産性が高い。一方、例えばメモリサイズが数十GBも求められるようなデータ処理アプリケーションなど、リソース利用で柔軟性／カスタマイズ性が求められるケース、そして既存のアプリケーションをそのままコンテナに移行する、いわゆる「リフト・アンド・シフト」を実施したい場合にはKubernetesが適しているという。

　PCF 2.0では、「Pivotal Cloud Foundry」という名称が、これまで「PCF」と呼ばれていたPASと、新たに加わったKubernetes環境であるPKSの双方を包括するものとなった。近い将来には、オープンソースプロジェクトriffをベースとした、サーバレスあるいはFaaSの製品がPCFの下に加わる。

PCFはPaaS、CaaS、FaaSを包含する。そして共通のサービス機能を提供する

　PCFは、包括的な製品名称にとどまるわけではない。PaaS、CaaS、FaaSの全てに共通のサービス機能を提供することになる。

　主な共通サービス機能をレイヤーの低い順から並べると、インフラ抽象化の「BOSH」、ネットワーク仮想化／セキュリティの「VMware NSX-T」、ログ／メトリクスの「Healthwatch」、サービスのカタログ化と容易な利用を実現する「Service Broker API」、CI/CDツールの「Concourse」がある。

BOSHという、特別な存在

　このうちBOSHは特別な存在だ。元々Cloud Foundryで使われてきたこのツールがKubernetesにも適用されることで、Cloud FoundryはKubernetesのプラットフォームとしての役割を果たすこともできるようになったという言い方ができる。

　BOSHについて、ヤラ氏は次のように話した。

　「Googleは、『Borg』という名称で同社が開発してきた技術を、Kubernetesとしてオープンソース化した。しかし、低レイヤーの技術はオープンソース化しなかった。だから同社は、Google Cloud Platform（GCP）がKubernetesを動かすための最良のサービスを提供できると言える。だが、私たちは、Cloud Foundryを支えてきたBOSHをKubernetesに適用することで、この低レイヤー技術の機能を果たせると考えた。多様なインフラ上での、Kubernetesクラスタの運用が楽になる」

　より具体的には、BOSHでKuberenetesクラスタのライフサイクル管理が容易になる。

　まず、低位のインフラは抽象化される。すなわち、各種のオンプレミス環境やクラウドサービスにおいて、共通の簡単な命令のみでKubernetesクラスタを立ち上げることができる。複数のクラスタを構成する際の、インフラ周りの作業も容易になるという。パッチ／アップデートについても自動化される。ロードバランサーへのIPアドレスの割り当ても不要で、自動修復も行えるようになる。

　BOSHによって、下の図のようなKubernetes運用における課題を解決できるという。

BOSHで、これらの問題が解決できるという

　ヤラ氏は、KubernetesをホストしているCloud Native Computing Foundation（CNCF）の活動を素晴らしいといい、同じくCNCFがホストするEnvoyを用いたサービスメッシュのIstioも、近く統合する予定だと話している。

VMware NSX-Tでマルチ環境のネットワーク／セキュリティ一括制御

　PKSにおけるもう1つの興味深いコンポーネントはVMware NSX-Tだ。NSXは、VXLANというトンネリングプロトコルを用い、仮想ネットワークを構築できる技術。VMware vSphere環境における導入が進んでおり、最大の導入理由は「マイクロセグメンテーション」、すなわち仮想ネットワークをアプリケーションあるいはアプリケーションの各階層といったきめ細かな単位で論理的に分割、仮想ファイアウォールによってアクセス制御を強化できることにある。

　「NSX-T」はNSXのマルチクラウド版とも表現できる。VMware ESXiだけでなく、多様なハイパーバイザーに対応している。複数の異なるインフラにまたがり、統一したポリシーの下で、きめ細かな仮想ネットワークセグメント分割ができる。

　「PKSでは、デフォルトで仮想ネットワーク技術Flannelが使える。だが、VMware NSX-Tを利用すれば、きめ細かなネットワーク分割ができることは大きなメリットだ」と、市村氏は話している。

　なお、NSX-TはPASにも適用できる。従って、Cloud FoundryとKubernetesの2つの環境にまたがり、統一されたポリシーの下でネットワーク／セキュリティ運用ができることになる。

Concourseで、Kubernetes環境へのデプロイも容易に

　開発者側の観点から、PivotalではConcourseという自社開発のCI/CDツールを通じてBOSHを活用、これによるKubernetes環境に対するデプロイプロセスの簡素化を実現している。

　市村氏は国内発表におけるデモで、Concourseから、そのユーザーインタフェースから離れることなくアプリケーションを投入するデモを見せた。

　Concourseから、自動的にPodが作成されて起動し、インフラ側からIPアドレスの割り当てがなされて、アプリケーションを投入できる。

　「これまでは、ロードバランサーへのIPアドレスをもらって、自分で割り当てなければならなかった。だが、BOSHでこうしたプロセスを自動化できる」（市村氏）という。