目次


知らないかもしれない Cloud Foundry に関する 5 つの事実

このサービスとしてのオープンソース・プラットフォームにまつわる誤解を解き明らかす

Comments

クラウド・テクノロジーの有効な利用法が確立されてきたことから、企業はクラウドに移行し、クラウドから価値を得る必要があると考えるようになってきました。特に、PaaS (Platform-as-a-Service) では、クラウド向けにワンストップの完全なオペレーティング・システムが手に入ります。

企業が Cloud Foundry のような PaaS ソリューションを利用すれば、アプリを実行するためのクラウド・リソースの管理について細々としたことを懸念する必要がなくなります。こうした詳細は、すべてプラットフォームが対処するため、アプリケーション・コードと、サービス・カタログのアクセスにだけ集中できます。スケーリング、修復、高可用性、災害復旧といった残りの側面は、すべてプラットフォームが引き受けてくれます。

早い時期に PaaS として登場した Cloud Foundry をはじめとする初期のプラットフォームは、絶え間ない革新によって、これからも PaaS 分野でのリーダーシップを維持していくはずです。その一方で、コンテナーのオーケストレーションという課題を解決する、Docker Swarm や Kubernetes などの新しい手法がもたらす革新と話題にも遅れずについていくことが重要です。

この数年間、Cloud Foundry のようなプラットフォームはかなりの成功を収めているものの、反論者もいます。具体的には、クラウド (アプリ、サービス、組織、ユーザーなど) の世界観を押し付けるプラットフォームには、デプロイできるアプリケーションの種類に一定の制限が課せられるという反論です。

例えば、データベースなどのサービスをデプロイするプラットフォームとしては、Cloud Foundry はそれほど適していません。Cloud Foundry にデータベースをデプロイする場合、BOSH (マルチクラウド対応のスケーラブルなリリース・エンジニアリング・ツール) を直接扱い、VM または VM 上で稼働するコンテナー・クラスターを使用してデータベースを IaaS (INfrastructure-as-a-service) にデプロイすることになります。このような制約があったことから、Kubernetes や Docker Swarm などの代わりのプラットフォームが登場する結果になりました。これらの代替プラットフォームでは、開発者がコンテナーのクラスターを直接管理して、そのクラスター上でアプリケーションを実行できるため、開発者に完全な自由が与えられます。

Cloud Foundry の代わりとなるプラットフォームが新たに登場することは、あらゆる側面で革新を促すことから歓迎すべきです。けれども、Cloud Foundry クラウド・オペレーティング・システムにまつわるいくつもの伝説や誤解も一掃するだけの価値があります。この記事では、Cloud Foundry について知らないかもしれない 5 つの事実を探ります。

これらの事実を取り上げる目的は、Cloud Foundry を他のプラットフォームと比較対照することではなく、誤解を解き、真相を明らかにすることです。現在の Cloud Foundry のアーキテクチャーと設計点に光を当てることで、PaaS を利用しようとしている企業ユーザーが可能な限り最善の決定を下せるよう支援したいと思います

1

事実その 1: Cloud Foundry は常にコンテナーを使用してきました

Docker と Kubernetes の登場により、コンテナーへの関心は最高潮に達しています。そこで重要となるのが、Cloud Foundry がコンテナー・テクノロジーにどのように関連しているのかを理解することです。まず、Cloud Foundry は他の多くの PaaS 環境と同じく、コンテナーを使用します。実際、Cloud Foundry は当初からコンテナー手法を使用してきました。つまり、現在のあらゆるコンテナー・オーケストレーション・プラットフォームの先駆けです。コンテナーの役割を考えれば、コンテナーが常に Cloud Foundry の中心となってきたのはなぜなのかを理解できるでしょう。

コンテナーは UNIX/Linux システム内での分離手段です。Linux 内では、さまざまなカーネル機能を使用して複数のアプリケーションをいわゆるコンテナーの中で実行することで、各アプリケーションがそれぞれに固有の分離されたシステム・リソースを把握できるとともに、リソースの使用量も制限することができます。

Cloud Foundry では、当初からコンテナーを使用しています。最近のリリースでは Cloud Foundry 内のコンテナー層 (Garden runC) がアップグレードされ、CNCF 主導の runC 標準が採用されたことで、新しい業界標準に貢献および適合するようになっています。つまり、Cloud Foundry アプリケーションを実行するときは、常に runC コンテナー内でアプリケーションを実行していることになります。

Cloud Foundry で固有に追加されている機能は、runC コンテナーの管理機能です。さらに、その複雑さはエンド・ユーザーにはわからないようになっています。Cloud Foundry 内の Diego ランタイムは、効率的なコンテナー・スケジューラーです。このスケジューラーの目標は (一部に)、Cloud Foundry をインスタンス化する際の基礎となる仮想マシンの使用効率を最大限に高めることにあります。

コンテナーにスケジューラーが必要となるわけは、IaaS 内で提供されるリソースの量は控えめであるからです。例えば、VM を作成するのに、10 GB のメモリー、64 基の CPU、10 GB のイーサネット・ネットワークを使用できるとします。複数の VM に Cloud Foundry をインストールして、最終的に 4 台の VM がエンド・ユーザー向けアプリケーションそれぞれの専用 VM としてアプリケーションを実行することになったとします。Cloud Foundry Diego スケジューラーはその役割の一環として、アプリケーションを配置すべき方法と場所、そして利用可能なリソースのうち、アプリケーションに割り当てるべき割合を決定する必要があります。スケジューラーの目標は、アプリケーションを最大限利用できる配置場所を決定し、環境が課す制約の中で、できるだけ多くのアプリケーションを効率的に実行できるようにすることです。

具体的には、Diego スケジューラーはユーザー・アプリケーション・インスタンスを、その可用性を維持できるように配置します。また、障害発生時にはアップグレードを正常な状態に戻し、アップグレード時にはアプリケーションを再びプロビジョニングします。Diego は、すべての Cloud Foundry アプリはステートレスであるという事実を利用します (ステートレスであれば、1 つのインスタンスが実行中の状態を維持する限り、アプリケーションをいつでも安全に別のホストに移動することができます)。ステートレスなアプリであることから、Diego は根本的なシンプルさを維持しつつ、ユーザー・アプリケーションの回復力、正常性管理、効率的な配置に対応できるというわけです。この機能が、Diego を他の一般的なスケジューラーと差別化しています。

2

事実その 2: Cloud Foundry は 10 種類を超える IaaS 上で稼働します (同じコード、異なるクラウド)

最初にリリースされた Cloud Foundry が稼働できたクラウドはわずか (VMware と AWS など) でしたが、当時のマルチクラウド・ユーザーにとっては、それでも十分満足でした。やがて BOSH の最初のバージョンが登場し、成熟するにつれ、VSphere、VCloud、OpenStack をはじめとする他のクラウドも追加されていきました。BOSH でサポートしていたのは明瞭なクラウド・プロバイダー・インターフェース (CPI) でしたが、新しい CPI を追加していくうちに BOSH ディレクター・コード内に埋め込まれる CPI が多様化し、さらに新しい CPI を追加するのが難しくなってきました。

図 1. クラウドにとらわれない CPI
クラウドにとらわれない CPI
クラウドにとらわれない CPI

2015 年、BOSH チームはその状況を打開すべく、BOSH ディレクター・コード・ベース内の CPI をクリーンアップし、CPI を外部化する作業を開始しました。現在、CPI は BOSH リリースとしてパッケージ化され、ディレクターとは独立してデプロイ、アップグレードできるようになっています。また、CPI は任意の言語で作成することができるだけでなく、対象とするクラウドに必要なテクノロジーであれば、どのテクノロジーでも使用できます。

既存のすべての CPI がそれぞれ固有のリポジトリーに変換されて、別の CPI チームが結成された後、Cloud Foundry コミュニティーはあることに注目しました。それは、この新しい拡張可能なメカニズムの結果として、さらに多くのクラウドや、コンテナー・プラットフォームまでも、Cloud Foundry をデプロイするために使用可能になったという点です。新しく使用できるようになったプラットフォームのほんの数例を挙げると、SoftLayer、Azure、GCP、そして Docker および Kubernetes があります。

図 2. 利用可能な CPI
利用可能な CPI
利用可能な CPI

利用可能な CPI は、ベアメタル SSH CPI、マルチ CPI を含め、15 種類以上あります。これだけ多様な CPI を使用できることから、Cloud Foundry は最も使いやすいクロスプラットフォーム PaaS であると言えます。

3

事実その 3: Cloud Foundry は数十万ものアプリケーションにスケーリングします。

Cloud Foundry が成熟していく過程で直面した最も大きな課題は、スケーラビリティーです。IBM、SAP、Pivotal、GE などの企業では、Cloud Foundry コード・ベースは、アプリケーション・サービスを対象とした自社のパブリック・クラウド戦略でのコア要素となると見込んでいました。そこで、プラットフォームの多数の部分が Golang で作成し直され、新しい分散システム・テクノロジーが Diego に追加された結果、Cloud Foundry のランタイム環境はより最新式の安定したものになりました。けれどもこうした変更は、環境のスケーラビリティーを向上させるのに役立ったのでしょうか?

Diego チームは線形スケーリング特性を実現するために、2016 年のほとんどをランタイム環境の微調整に費やしました。チームは各種コンポーネントの選択を見直して改善し、スケーリングの実験を実施しました。その結果に応じて、アプリケーションを実行するベース VM に対応する 1,250 個の Diego セルをプロビジョニングしました。次のグラフに示すように、このプラットフォームは最終的に 250,000 個のコンテナーを実行できるほどスケーリングするようになりました。

図 3. 250,000 個のコンテナー
250,000 個のコンテナー
250,000 個のコンテナー

アプリケーション・インスタンスとコンテナーは 1 対 1 でマッピングすることを前提とすれば、Diego のスケーラビリティー・テストで明らかになったのは、Cloud Foundry では 250,000 個のアプリケーションを管理できることです。しかも、スケーラビリティー・テスト全体を通して、Cloud Foundry では管理対象のアプリケーションをルーティング可能かつレスポンシブな状態に維持することができました。しかも、このテスト結果は、現在何十万ものアプリが存在する本番環境で Cloud Foundry が実行されている主な理由ではありません。

実際のところ、Cloud Foundry のスケーリングの限界はわかりません。大規模なスケーリングの実験を実施するにはあまりにもコストがかかるため、Diego チームは限界点に達するまでテストの規模を大きくすることは敢えてしなかったのです。理論上は、Cloud Foundry は 500,000 個のアプリケーション、あるいは数百万個のアプリケーションにまでもスケーリングします。このスケーラビリティー・テストの詳細については、このリンク先のブログ記事「250k Containers In Production: A Real Test For The Real World」を参照してください。

4

事実その 4: Cloud Foundry は任意の言語と任意のフレームワークを使用して稼働します

当初から、Cloud Foundry は任意の言語と任意のフレームワークを使用して稼働するように設計されています。この設計点は常に維持されてきたため、広く利用されている新しい言語とフレームワークは Cloud Foundry 内でサポートされているだけでなく、カスタマイズすることもできます。その好例は Java のサポートです。Java アプリケーションを実行する手法はいくつもあります。また、OpenJDK または IBM Liberty Java VM を使用するかどうかを問わず、サポート対象の Java ビルドパックがあります。

図 4. Cloud Foundry の設計上の主要なポイント (クラウド、フレームワーク/言語、サービスにとらわれません)
Cloud Foundry の設計上の主要なポイント
Cloud Foundry の設計上の主要なポイント

Cloud Foundry エコシステム内で活躍しているのは、十分に確立された言語とフレームワークだけではありません。このエコシステムには、新しいまだよく知られていない言語も取り込まれます。例えば、2015 年 12 月に Apple が Swift 言語の OSS をリリースすると同時に、Swift 対応の Cloud Foundry ビルドパックが登場しました。現在は、少なくも 2 つのバージョンをコミュティーから入手できます。

その上、これらのビルドパックでは Heroku との互換性が維持されており、Heroku コミュニティーがリリースしているビルドパックを Cloud Foundry インストール済み環境で使用できるようになっています。さらに Cloud Foundry コミュニティーは複数のランタイムを必要とするアプリケーション用のマルチビルドパックのサポートについて調査し、ビルドパックを革新しています。また、既存の手段では解決できない、アプリケーションでの未知の問題を解決するために言語のランタイム環境またはフレームワークをフォークする必要が出てきた場合に備え、Cloud Foundry コミュニティーはプライベート・ビルドパックについても調査しています。

5

事実その 5: Cloud Foundry は拡張できます

以前、Cloud Foundry は拡張性と拡張ポイントがないと非難されていました。このプラットフォームは完全にオープンであり、理論上は誰でも Github プル・リクエストを送信すればプラットフォームに変更を加えることができますが、体系的な方法でプラットフォームを拡張する手段がないというのが非難の理由です。つまり、プラットフォームのすべての構成部分について全員で調査し、全員で作成するための方法がありませんでした。別の言い方をすると、「百家争鳴」戦略の精神で革新を生むのは不可能だったのです。

この問題を解決するために、2016 年にプロジェクトの管理委員会 (プラットフォームの方向性を管理する委員会) は、Cloud Foundry を構成するすべてのプロジェクトを、Runtime、BOSH、Extensions という 3 つのサブ PMC に分割することを決定しました。新しく発足された Extensions プロジェクト管理委員会の任務は、プラットフォームの拡張を奨励すること、それらの拡張の進化に何らかの構造を取り込むこと、コミュニティーがあらゆる種類の選択肢を (有益か、それほど有益でないかについて) 調査できるようにすることです。

委員会は 6 か月にわたり、拡張としてふさわしく、新しいプロジェクトと見なせる既存のプロジェクトを体系化して改良しました。現在、Cloud Foundry では拡張プロセスが確立され、コミュニティー内の誰もがプラットフォームを拡張するために使用できる手段が用意されています。プラットフォームの拡張には、API、ツール、CPI、他のプラットフォームへのコネクター、ビルドパック、サービスなどが含まれます。

コミュニティーがさらに拡張を追加するにつれ、消えていく拡張もあれば、コアに昇格する拡張もあるでしょう。いずれにしても、第一の目標は、このプラットフォームがオープンで活発に成長し続けるようにすること、そしてコミュニティー内の誰もが新しい見事なアイデアでプラットフォームを拡張できるようにすることです。

まとめ

PaaS は進化を続けています。早い時期から PaaS として登場した Cloud Foundry をはじめとする初期のプラットフォームは、絶え間ない革新によって、これからも PaaS 分野でのリーダーシップを維持していくはずです。その一方で、コンテナーのオーケストレーションという課題を解決する、Docker Swarm や Kubernetes などの新しい手法がもたらす革新と話題にも遅れずについていくことが重要です。

さまざまな意味で、コンテナー・オーケストレーションはゼロ・サム・ゲームではないため、多くのプラットフォームが成功することが見込まれます。こうしたプラットフォームが解決しようとしている問題空間には、IT アプリケーションおよびサービス管理のすべてが含まれます。

この記事では、企業の IT チームとその管理者が、Cloud Foundry と他の PaaS 環境のどちらを採用するか決定する際に正しい答えを出せるよう、(よく知られているものも、そうでないものも含め) 重要な 5 つの事実を明らかにしました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1064635
ArticleTitle=知らないかもしれない Cloud Foundry に関する 5 つの事実
publish-date=02142019