[クラウド分解辞典−Cloud Foundryの実像]

2015年8月25日(火)萱間 真人（CTC クラウドイノベーションセンター 主任）

　Cloud Foundryは、アプリケーションを効率的・継続的に動作させるためのPaaS（Platform as a Service）として、様々な“仕掛け”を提供します。それらの仕掛けが、プラットフォームの利用者には単純さを提供し、機能要件の策定・実現、すなわちアプリケーションソフトウェアへの集中を可能にします。一方でプラットフォームが非機能要件を一手に引き受けることになり、そこに複雑さが生まれます。

　本連載では、利用者のアプリケーション集中を実現するために複雑さを内包しているCloud Foundryについて、以下を解説します。なお、Cloud Foundryは常に進化しています。最新版は現在、開発が進行している「Cloud Foundry v3」ですが、本連載では2015年7月時点で安定して利用されている「Cloud Foundry v2」を対象にします。

●Cloud Foundryのアーキテクチャー
●Cloud Foundryを構成するコンポーネントの役割

　ただし、以下は解説しません。

●Cloud Foundryのクライアントコマンドツール（cfコマンド）の使用方法
●Cloud Foundryの環境構築方法
●Cloud Foundryのソースコードレベルでの動作仕様

　これらはCloud Foundryを使ってPaaS環境を構築・運用する技術者にとっては重要な情報です。しかし本連載の目的は、Cloud Foundryを使ってアプリケーションに集中したい利用者に対し、そのプラットフォームとしての特性を理解して頂くことです。そして、本連載がCloud Foundryを使ったアプリケーション開発／運用のあるべき姿を考えていただくことの契機になることを願っています。

　それでは、いよいよCloud Foundryの内部を知るための“見学ツアー”に出掛けましょう。ただCloud Foundryにたどり着くには、海外旅行同様に、飛行機に乗って空の高みに登らなければなりません。

オープンガバナンスで開発が進むCloud Foundry

　シートベルトは締めましたか？ 到着まで時間がありますので、Cloud Foundry について少しおさらいしておきましょう。

　Cloud Foundry はもともと、「Cloud Foundry」という企業が提供していたJava Applicationを動作させるためのPaaSでした。それが 2009年にSpringSourceに買収されたのですが、それとほぼ同時にSpringSourceが米VMWareに買収されます。そして2011年、VMWare はCloud Foundry をOSSとして公開し、コミュニティ主導の開発を推進しました。これによりCloud Foundryは爆発的な成長を遂げることになりました。

　オープンな PaaSとして、Cloud Foundryの位置付けが、ますます重要になることで、ガバナンスの透明性を求める声が高まりました。これを受けて、2014年に、米EMCや、米HP、米IBM、米Intel、米Pivotal、独SAP、米VMWare などの企業が参加してCloud Foundry Foundationを組織します。現在は、この組織によって、Cloud Foundryの仕様は、オープンなプロセスで検討されています。

　Cloud Foundryはオープンソースであり、オープンガバナンスであるということから、IBMやHP、日本ではNTTコミュニケーションズなどの大手企業がCloud Foundryをベースにした PaaSを展開しています。

　Cloud Foundryがこれほどまでに注目されているのはなぜでしょうか？ それは、Cloud FoundryがITを利用したビジネスのスピードを向上させる可能性があるからです。

　Webアプリケーションの作成は、「その機能群をソースコードとして表現すれば終わり」ではありません。可用性や拡張性などの非機能要件を検討し実装しなければなりません。サーバーやミドルウェアなどの実行環境を調達し、それらを適切に設定する必要もあります。加えて、それら実行環境にアプリケーションを配備する適切な方法を検討し、実現しなければなりません。

　Cloud Foundryの価値はまさにそこにあります。Cloud Foundryは、これまでアプリケーションの作成に含まれていた非機能要件、サーバーやミドルウェアの調達・設定、配備などをプラットフォームとして実現します。これにより、サービス提供までのリードタイムの短縮や、サービスイン後の継続的な改善が容易になります。そこに、ITを利用したビジネスのスピードを向上させる可能性がでてくるのです。

　少し長くなってしまいましたね。そろそろ上空1万メートルに到達するようです。

上空1万メートルから見れば
オンプレミスとCloud Foundryは同じ？

　ここは上空1万メートル、前方に国際線の航空機が見えます。眼下には2つのシステムが見えます。どちらも人気のあるWebアプリケーションが稼働しています。一方は従来型のオンプレミス環境を、他方はCloud Foundryをそれぞれ採用しています。

　試しに、それぞれのWebアプリケーションに対してHTTPリクエストを投げてみましょう。もちろん、両者は適切にHTTPレスポンスを返してきました。大量のリクエストを同時に投げてみるとどうでしょうか。やはり、両者は適切にHTTPレスポンスを返却してきます。

　どちらのシステムもWebアプリケーションのアップデートを1日に10回程度繰り返しているそうです。では、そのタイミングでHTTP リクエストを投げてみてはどうでしょうか。やはり、両者は適切にHTTPレスポンスを返却します。

　上空1万メートルからでは、両者の違いは分からないようです。どちらも、人気の高いWebアプリケーションが稼働できるだけの非機能要件を実現しています。それぞれで実現の仕方に違いがあるのでしょうか。

上空5000mから見たオンプレミス構成図

　少し高度を下げてみましょう。上空5000メートルです。前方に見えるのは国内線の航空機です。先ほどの2つのシステムをこの高度から見れば、全体図を描けそうです。スケッチしてみましょう。

　図1にあるCloud Foundryとオンプレミスの構成を見比べてみると、いくつかの点で両者は類似しています。

　人気のあるWebアプリケーションですから、たくさんのHTTPリクエストを受け付ける必要があります。そのため、どちらのシステムも充分な拡張性を備えています。アプリケーションの入口にはロードバランサーが設置され、アプリケーションサーバーへのリクエストを効率的に分散しています。

　また、人気のあるWebアプリケーションとして、可能な限り障害によるサービス停止を防がなければなりません。そのため、どちらのシステムも充分な可用性を備えています。アプリケーションサーバーはクラスタ構成を採り、それらを監視することで単一ノードの障害が全体へ波及することを防いでいます。システムログは一元的に管理され、システムを構成する各コンポーネントも監視されています。

　こうしてみれば、Cloud Foundryは従来型のシステムアーキテクチャーの延長にあると言えます。これら類似のコンポーネントについては、従来型システムで経験ある部分を置き換えれば、Cloud Foundryのアーキテクチャーも理解が容易なはずです。

　一方でCloud Foundryには、オンプレミス環境にはない、いくつかのコンポーネントが見られます。例えば、ロードバランサーとアプリケーション実行環境との間に何か仲介しているコンポーネントがあります。さらに、このコンポーネントは、2つの別のコンポーネントともつながっているようです。

　これら2つのコンポーネントも従来型システムにはありません。加えて、多くのコンポーネントを仲介しているようなコンポーネントがあります。これはいったいどんな役割を持っているのでしょうか。

　Cloud Foundryと従来型システムの間に、いくつかの相違点があることは、Cloud Foundryは従来型システムとは異なるアーキテクチャーを持つと言えます。これらの独自のコンポーネントがCloud FoundryをPaaSたらしめる鍵になっています。