Cloud FoundryとKubernetes、クラウドネイティブに向けた2つのアプローチ：吉瀬淳一氏が解説（2/2 ページ）

CFARとKubernetes、どう使い分けるべきか

　以上のように、CFARとKubernetesはいずれもアプリケーションコンテナの実行管理という機能を有しているが、CFARでは「アプリケーション開発者がソースコードの開発に専念できるように必要な機能を提供する」という方向性で機能を充実させてきたのに対して、Kubernetesはよりインフラの視点で、ワークロードの実行を効率的に管理することを主眼としている。いずれも大規模にスケールさせることを前提としたアプリケーション実行環境である以上、組織としてどちらを採用するか、あるいは併用するかを検討しなければならない。1つのポイントとしては、アプリケーション開発の効率化に重きを置くか、まずはインフラ運用の効率化に取り組むか、ということが挙げられる。

　Webアプリケーション／マイクロサービスの開発の効率とアジリティを高める上で、CFARは強力な機能を提供している。アジャイル開発や頻繁なバージョンアップを行う開発部門にとって、CFARは現時点で最高のプラットフォームの1つであると言ってよいだろう。ただし先に述べたように、アプリケーションアーキテクチャや開発フレームワークは、プラットフォーム側で用意されたものに従う必要がある。そのため全社的な開発標準の整備など、一定のガバナンスがないと効果的に活用することは難しいだろう。また機能が充実している分、スモールスタートが行いにくいという問題もある。Cloud Foundryを採用し成功している企業は、トップダウンの意思決定で、組織の改革を含めて大規模な導入を行っている企業が多いように思う。

　一方、エンタープライズにおけるKubernetesの実用化事例の中には、アプリケーションのクラウドネイティブ化／マイクロサービス化に対する、Cloud Foundryとは異なるアプローチが見えてくる。アプリケーションをまずはコンテナ化（Dockerイメージ化）することによりポータビリティーを獲得し、それをKubernetesクラスタで実行することでスケーラビリティーを獲得するというアプローチだ。

　ここで、アプリケーションアーキテクチャや開発手法は必ずしも大きく変える必要がないため、いわゆるリフト・アンド・シフト（Lift and Shift：既存アプリケーションをそのまま移行する）が可能となる。もちろんそれだけでは開発側の生産性が大きく向上するわけではないが、アプリケーションのコンテナ化とコンテナオーケストレーションの活用により、テストとデプロイの柔軟性は得られるだろう。その後開発／運用の効率化、アーキテクチャのクラウドネイティブ化／マイクロサービス化を進めていく上で、必要な機能は順次追加していくというアプローチだ。その過程では、前述の「YAMLの壁」を乗り越えるための組織的な改革にも、徐々に取り組む必要があるだろう。

　冒頭にも述べたように、クラウドネイティブプラットフォームの行きつく先は”just run my code”である。そのために解決しなければならない課題は多く、Kubernetesとその周辺のエコシステムでは今まさに活発に議論と開発が行われているし、CFARにしてもまだまだ機能強化は続いている。

　ワークロードの観点でいうと、現時点ではCFARに適しているのはステートレスなWebアプリケーションやマイクロサービスであり、Kubernetesはよりインフラに近いレイヤーもアプリケーションから直接利用できるため、データサービスや機械学習といったユースケースも増えている。そのため、CFARを補う形でKubernetesを併用する、あるいはKubernetesのエコシステムを強化する形でCFARを併用する、という考え方も出てきている。

CFARとKubernetesの共存・併用、2つのアプローチ

　CFARもそれ自体が複雑な分散システムであるため、維持・管理するためには何らかのライフサイクルマネジメントが必要となる。Kubernetesと異なるのは、標準的なライフサイクルマネジメントレイヤーとしてのBOSHの存在である。BOSHはKubernetesよりも歴史が長く、分散システムのライフサイクルマネジメントとして優れた仕組みだが、AWS、OpenStack、VMwareといった対応するIaaSを必要とするという点と、現状はCloud Foundry以外のユースケースがないという点が導入上の制約となる。

　Cloud Foundry Container Runtime（CFCR）は、そのBOSHの上でCFARクラスタと横並びで、Kubernetesクラスタも管理しようというものである。これにより、KubernetesクラスタのライフサイクルマネジメントとCFAR のライフサイクルマネジメントを共通化できるため、特にCFARクラスタを運用しているユーザーがKubernetesを追加導入するといった場合にはメリットが大きいだろう。

　これに対して、SUSEやIBMが取り組んでいるのは、Kubernetesをデータセンターの共通インフラとして扱い、CFARはKubernetesの上で実行されるサービスの1つとしてデプロイする、というアプローチである。つまり、CFARにとってはBOSHに代わるライフサイクルマネジメントレイヤーとしてKubernetesが機能することになる。背景には、事実上Cloud Foundry専用であるBOSHに対して、Kubernetesがある意味IaaSとしても標準的なプラットフォームになりつつあるという期待がある。

　例えばクラスタ全体のリソース拡張に関して、Kubernetes用のリソースあるいはCFAR用のリソースを個別に考えるのではなく、単にKubernetesのノードを足していけばよいという、ハイパーコンバージド的な運用も可能となる。ただし、Kubernetes自体のライフサイクルマネジメントに関しては、別途考えなければならない。

　また、CFARはそれ自体がコンテナランタイムおよびオーケストレーションの機能（Garden）を持っているため、Kubernetes上でCFARを動作させた場合、その部分が完全にオーバーラップしてしまう。つまり、CFAR上でアプリケーションを実行した際、Kubernetesからはそのアプリケーションは見えない。CFARのアプリケーションコンテナをGardenの代わりにKubernetesで実行するという試みも一部では行われており、ゆくゆくは統合される可能性もあるが、現時点ではアプリケーションの実行は個別に管理する必要がある。

相互運用に向けた取り組みの進展と課題

　このように、CFARとKubernetesはプラットフォームとしての統合の仕組みは整いつつあるが、アプリケーションの実行管理は分離されている。2つの実行環境それぞれの利点を生かしてアプリケーションアーキテクチャを設計し、開発と運用を効率化するには、相互運用性が鍵となってくる。相互運用に向けた取り組みについてはCFF内で議論され、実際に実装が進みつつある。ここで幾つか紹介したい。

共通のサービスカタログ

　CFAR上のアプリケーションと、データベース（DB）などの外部サービスを接続するためのインタフェースとして、Service Brokerという仕組みが従来から実装されているが、これをCFAR以外からも使えるようにしたものがOpen Service Brokerである。既にKubernetesはOpen Service Broker APIをサポートしている。現在取り組まれているのは、1つのサービスをCFARおよびKubernetesの双方から利用できるようにするための、共通のサービスカタログの実装である。

バックエンドサービスのデプロイ

　Open Service Broker経由で利用するバックエンドサービスそのものを、Kubernetesの上でデプロイできるようにするという取り組みである。KubernetesではDBクラスタなどをデプロイする際にHelmが広く利用されているが、これを上記のサービスカタログと連動させることにより、サービスインスタンスの起動がオンデマンドで行えるようになる。

アクセスルーティング／サービスメッシュ

　Istioは、マイクロサービスのサービスメッシュを管理するソフトウェアである。Istioの機能範囲はマイクロサービスへのアクセスルーティングとロードバランシング、通信ポリシーの集中管理、テレメトリーなど。マイクロサービス化の進行に伴い、こうした機能の需要が高まっているため、Kubernetesエコシステムにおけるホットな領域の1つとなっている。

　CFARでは、外部からのアクセス（いわゆる「north-south」）のルーティングはgorouterというコンポーネントが担っており、マイクロサービス間（「east-west」）の通信についてはcf-container-networkingが実装された。これらに代わり、さらなるサービスメッシュ機能を提供するものとしてIstioを統合しようという取り組みが始まっている。

　さらには、KubernetesとCFAR双方の通信を共通にIstioのサービスで管理できれば、ポリシー管理の一元化など、さまざまなメリットが想定できる。だが、実装面での課題は多く、まだ議論が始まったばかりである。

エンタープライズユーザーが今、やるべきこと

　エンタープライズユーザーにとって、レガシーなアプリケーション開発と運用からクラウドネイティブな世界へと移行していくためには幾つかのアプローチがあり、いずれにせよ克服しなければならない課題は多い。CFARから始めるのであればアプリケーション開発手法の改革と標準化に取り組むべきだし、Kubernetesから始めるのであればインフラチームのSRE化といったことも考えなければならないだろう。さらにはサーバーレスといった新たなアーキテクチャモデルも生まれてきている。

　結局のところ、CNCFにしてもCFFにしても、目指すところは「アプリケーション開発を効率化し、多種多様なワークロードを迅速にスケールさせ、安定して稼働させるプラットフォームとエコシステム」である。そこに至るアプローチは異なるものの、これまで実現してきた成果は互いに生かされており、今後さらに相互運用性は向上していくだろう。

　変化の激しい分野ではあるが、向かっている方向が一致している以上、ユーザーは「落ち着くまで様子見」をする必要はない。今優先して取り組みたいことに近いアプローチを採用して、進むべきだと思う。