- 会員限定
- 2014/05/21 掲載
注目高まるPaaS基盤「Cloud Foundry V2」のアーキテクチャはどうなっている?(後編)
ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。
そして「第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会員にご登録ください。
すべて無料!ビジネスやITに役立つメリット満載!
-
ここでしか見られない
1万本超のオリジナル記事が無料で閲覧可能
-
多角的にニュース理解
各界の専門家がコメンテーターとして活躍中!
-
スグ役立つ会員特典
資料、デモ動画などを無料で閲覧可能!セミナーにご招待
-
レコメンド機能
あなたに合わせた記事表示!メールマガジンで新着通知
関連タグ
PR
PR
PR