Publickeyでは2011年10月に開催された「第1回 CloudFoundry輪読会」を基に「PaaS基盤「Cloud Foundry」のアーキテクチャは、どうなっている？」という記事を公開しました。あれから3年半経過した現在、Cloud FoundryはV2へバージョンアップしました。

　そして「第18回 Cloud Foundry 輪読会」では、このCloud Foundry V2のアーキテクチャ概要について、NTTコミュニケーションズの草間一人氏が「Cloud Foundryはなぜ動くのか」というタイトルで解説しています。本記事は、その内容をまとめたものです。

本記事は『注目高まるPaaS基盤「Cloud Foundry V2」のアーキテクチャはどうなっている？(後編)』の続きです。

Cloud Foundry内部のRouterはリクエストを振り分ける

　Cloud Foundryにおけるコンポーネントの役割を説明していきましょう。

　コンポーネントとは何か。これはつまりアプリケーションで、1つのプロセスです。例えばRouterはGo言語で書かれたアプリケーションで、Health ManagerもGo言語になっています。DEAやCloud ControllerはRubyで書かれています。

　これらはただのアプリケーションなので、やろうと思えば1つのVM（仮想マシン）上で動かせますが、一般に実運用を考えると、1コンポーネントずつ1VMで動かすことが多いでしょう。


　まずRouterですが、URLによってアクセスを振り分けるコンポーネントです。


　api.xxxだったり、dora.xxxだったり、URLを見て振り分けるわけです。ネットワーク機器のルータとは別のものですので注意してください。Cloud FoundryではGoRouterと呼ぶことが多いですね。


　なぜRouterはリクエストの振り先を知っているのでしょうか。それはrouter.registerというメッセージの仕組みがあって、DEAやCloud Controllerが「このURLの振り先は実体がここだから転送して」とか「DEAはここだから、こっちに転送して」など、各コンポーネントがRouterに対してあらかじめ情報を送っておくんです。


　Routerはオンメモリデータベースを持っていて情報を格納しておき、実際のアクセスと突き合わせて振り先を判断しています。


　仮に同じアプリケーションが複数インスタンス合った場合でも、それぞれがデータベースに入っているので、ラウンドロビンで振り分けられるようになっています。ですから同一のURLに複数の振り先があっても大丈夫なようにできています。

Cloud ControllerはAPIの提供、DEAはアプリの実行