- 会員限定
- 2014/05/21 掲載
注目高まるPaaS基盤「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はアプリの実行
今すぐビジネス+IT会員に
ご登録ください。
すべて無料!今日から使える、
仕事に役立つ情報満載!
-
ここでしか見られない
2万本超のオリジナル記事・動画・資料が見放題!
-
完全無料
登録料・月額料なし、完全無料で使い放題!
-
トレンドを聞いて学ぶ
年間1000本超の厳選セミナーに参加し放題!
-
興味関心のみ厳選
トピック(タグ)をフォローして自動収集!
関連コンテンツ
PR
PR
PR