Foundryが提供するソフトウェアスタックを表したものです。Foundryサイトは1台のサーバで構築することもできますが、実体は複数のサーバコンポーネントで構成され、複数台のオペレーティングシステムの上で仮想的な1つのシステムを提供します。Serviceを構成するシステムのカーネル」といえるでしょう。Foundryサイト(cloudfoundry.comなどのようなサービス提供サイトやStackatoのようなパッケージ製品)が位置付けられます。Foundryと呼びます)が提供するのは、大きく分けて次の4つです。Foundryの担当範囲を知ることで、何が不足しているかを認識しましょう。Foundryのそれぞれの内部コンポーネントの関連を表したものです(注6)。枠で囲われた箱がサーバコンポーネント、つまり何らかのポートで待ち受けを行うプロセスを表しています。Foundryで複数インスタンスの起動によるスケールアウトが可能なコンポーネントを表しています。コンポーネント間を結ぶ線は、ネットワーク上で実際にパケットのやりとりが必要なことを表しています。Foundryのアーキテクチャは視点によりさまざまな議論が可能です。Broker」などもコンポーネントとして存在します。Foundryサイト環境の構築および動作に必須ではないため割愛しています。Foundryのアプリケーションコンテナを構成するコンポーネントは以下の通りです。Foundryサイトに流れるすべてのHTTP(S)トラフィックの負荷分散機能を提供します。HTTP(S)トラフィックを負荷分散できるものであれば、任意のものを使用可能です。従って、このコンポーネントの実装はソースコードに含まれておらず、サードパーティのプロダクトを自分自身で構築します。オールインワン構成の場合は、nginxが利用されるように構成されます。Foundryに特化したL7ロードバランサのような動作をするコンポーネントです。ロードバランサから受け取ったHTTPトラフィックを受け取り(注7)、適切なサーバ(後述するDEA上のユーザーアプリケーションインスタンスやクラウドコントローラのインスタンス)にトラフィックをルーティングする機能を提供します。実装はhttps://github.com/cloudfoundry/routerにあります。FoundryサイトでHTTPSに対応するにはロードバランサでHTTPSをHTTPに変換する必要があります。Railsを使って実装されています。vmcコマンドで行われる操作はすべて、HTTPリクエストとしてこのコンポーネントで処理されます。実装はhttps://github.com/cloudfoundry/cloud_controller/tree/master/cloud_controllerにあります。Database)アプリケーションのメタデータが格納されるリレーショナルデータベースです。開発用にはSQLite3が利用され、本番システム用にはPostgreSQLが利用できるように、クラウドコントローラの設定が記述されています。このコンポーネントの実装は、ソースコードに含まれていません。Foundryが使用しているRubyのMySQLクライアントではいくつかの問題があるため、PostgreSQLの利用をお勧めします。System)クラウドコントローラにアップロードされたアプリケーションのソースコードを、クラウドコントローラのインスタンス間で保管しておく共有ファイルシステムです。オールインワン構成では必要ありません。マルチノード構成で、クラウドコントローラを複数サーバにまたがって並べるときは、NFSなどによる共有ファイルシステムの実装が必要になります。このコンポーネントの実装は、ソースコードに含まれていません。クラウドコントローラから指令を受け取り、各サーバ上のユーザーのアプリケーション(Droplet)の起動/停止を制御するエージェント機能を提供します。実装はhttps://github.com/cloudfoundry/deaにあります。Manager)クラウドコントローラデータベースを参照し、DEAに対してハートビートを行いながら、デプロイされたアプリケーションの死活確認を行い、必要に応じてリカバリを要求する機能を提供します。実装はhttps://github.com/cloudfoundry/cloud_controller/tree/master/health_managerにあります。Foundry内部のコンポーネント間のメッセージのやりとりを仲介するメッセージングサーバの機能を提供します。NATSと呼ばれる独自のメッセージングミドルウェアを使う必要があります。このコンポーネントの実装は、ソースコードに含まれていません。これらのコンポーネントで構成されるアプリケーションコンテナに対し、必要に応じてサービスブロックを追加していくことができます(追加しない、という選択も可能です)。サービスブロックの構成に必要なコンポーネントは以下の通りで、サービスの実装(例えばMongoDBやRedisなど)の分だけ追加します。オールインワン構成ではMySQL、MongoDB、Redis、Neo4Jなどのサービスが追加されるようになっています。Gateway)クラウドコントローラに対して、サービスブロックが提供するデータサービスの情報を登録し、プロビジョニング、デプロビジョニングなどの指令をクラウドコントローラから受け取るためのゲートウェイ機能を提供します。実装例はhttps://github.com/cloudfoundry/vcap-services/blob/master/mongodb/lib/mongodb_service/mongodb_provisioner.rbなどです。Node)サービスゲートウェイから指令を受け取り、実際のサービスインスタンスを起動/停止する機能を提供します。実装例はhttps://github.com/cloudfoundry/vcap-services/blob/master/mongodb/lib/mongodb_service/mongodb_node.rbなどです。Foundry内部のコンポーネント間のメッセージのやりとりを仲介するバスの機能を提供します。NATSと呼ばれる独自のメッセージングミドルウェアを使う必要があります。オールインワン構成では、クラウドコントローラやルータなどが利用するメッセージバスと共有されます。このコンポーネントの実装は、ソースコードに含まれていません。Foundryサイトを使うことでスケーラビリティやフォルトトレランスの管理から逃れられることを期待するでしょう。Foundryサイトの管理者にとっては、内部的にスケーラビリティとフォルトトレランスを確保する手段を講じておく必要があるでしょう。Foundryサイト上で動作するアプリケーションインスタンスとサービスインスタンスのスケーラビリティとフォルトトレランスについて言及します。instanceコマンドによって提供されます。Foundry内部では、DEAで管理されるアプリケーションプロセス数を変更します。Foundryサイトの管理者は、DEAが起動可能なアプリケーション数に随時注意を払っておき、必要に応じてDEAを追加・削除できるように準備しておく必要があります。トラフィック量の多いアプリケーションを想定して、ロードバランサおよびルータも必要に応じて追加・削除できるように準備しておく必要があります。Foundryサイト上で動くアプリケーションのフォルトトレランスは、ヘルスマネージャによって保障されます。具体的には、アプリケーションインスタンスが動いているノードの障害をヘルスマネージャが検知し、別のDEA上で起動するようにクラウドコントローラにメッセージを投げることで、わずかな時間で回復するように設計されています。Foundryサイトの管理者は、ヘルスマネージャノード自体がダウンした場合は速やかに別のサーバ上で起動できるようにしておくなどの事前準備が必要です。ヘルスマネージャ自体が停止しても、DEA上で稼働するアプリケーションには影響がありません。ヘルスマネージャの現在の実装は、プロセス管理のみを責任範囲としており、アプリケーションのパフォーマンス管理までは責任を持っていません。アプリケーションの応答が低下したときに、自動的にアプリケーションのインスタンス数を増やすなどの機能は提供されません。Foundryには含まれていません。Foundryには含まれていません。いくつかのサービスの実装にはデータのバックアップ機能が含まれているので、その機能を使って定期的にバックアップを取得し、障害時には手動でリストアしてあげる必要があります。Foundryサイト自体のフォルトトレランスについて言及します。Foundryのソースに含まれないものについては、利用するプロダクトに完全に依存します。Foundryが強く依存するメッセージングミドルウェアのNATSに言及します。ルータ、クラウドコントローラ、DEAおよびサービスノードは基本的に、ノード数を追加することでスケールアウトできます。クラウドコントローラやDEAを追加・削除したとき(またはサービスノードを追加・削除したとき)は、それらがルータ(またはサービスゲートウェイ)に通知され、自動的にトラフィックが制御されるように設計・実装されています。ここでいう「削除」は、障害による停止の場合も同様で、フォルトトレランスが保障されます。ルータの追加・削除はロードバランサと協調するように制御する必要があり、フォルトトレランスもロードバランサとして利用する製品に依存します。ヘルスマネージャおよびサービスゲートウェイは1つのプロセスで機能を提供するコンポーネントです。これらにスケールアウトさせるための設計や実装は、現在のところありません。スケールアップさせることで対応する必要があります。ヘルスマネージャはアプリケーション数の増加に伴って徐々にパフォーマンスが低下していき、障害の検知まで時間がかかるようになるので、注意してください。これらのコンポーネントで障害が発生した場合は、アプリケーションの監視やサービスのプロビジョニング機能が動作しなくなりますが、アプリケーションそのものが停止するような重要な障害には至りません。速やかに再起動を試みてください。コンポーネント自体はデータを持たないため、コールドスタンバイの状態にしておけば問題ありません。NATSも、1つのプロセスで機能を提供するコンポーネントです。Foundryの各コンポーネントはこれらに未対応です。従って、スケールアップさせることで対応する必要があります。NATSで障害が発生した場合には、ルータやDEAなどをはじめとしてアプリケーションを正常に動作させるための多くのコンポーネントのプロセスが停止し、サイト全体がダウンします。Foundryとは別のレイヤでソリューションを検討する必要があります(注8)。注8:筆者らがこの問題についてMLで議論をしたところ、LinuxのkeepalivedやheartbeatなどのHAソフトウェアを使って、IPアドレスを移動させる方式で実現するのが最も現実的な解のようです。Foundryが提供するのはHTTPのトラフィックのルーティングとデータサービスのプロビジョニングです。Foundryとうまく連携するように自動化されたシステムを構築する必要があるでしょう。Foundryを使ったビジネスモデルも見えてくるでしょう。Foundryサイトをセットアップし、アプリケーションをデプロイするとともに、内部のアーキテクチャ概要について解説しました。Foundry自体のソースコードを修正するか、補完するソリューションによる実装を検討する必要があります。Foundry自体のソースコードを修正して、機能を追加する方法を、例を挙げて紹介します。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。