めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

OpenShiftの内部構造についての覚書 (4)

何の話かというと

OpenShiftのネットワーク構成について聞かれることが多くなってきたので、ポイントをまとめておきます。

管理アクセスの経路

まず、OpenShiftを構成するサーバ群について、こちらのp.12を参照してください。

この中にある「ブローカー」ノードは、REST APIで、ギアの作成などの管理操作のリクエストを受け付けます。rhcコマンドも裏ではこのREST APIを使用しています。(REST APIの仕様については、公式マニュアルの「REST API Guide」を参照してください。)リクエストを受けたブローカーは、実行ノードに対して、ギアの作成などの指示を出します。

アプリケーションアクセスの経路

一方、ギアの中で起動したWebアプリケーションに対して、Webブラウザからアクセスする際は、実行ノードに対して、直接に接続が行われます。ルーティング用のノードなどは介在しません。アプリケーション実行用のギアを立ち上げると、そのアプリケーション名を含む固有のURL(ドメイン名)が生成されて、そのドメイン名に対して、アプリケーションのギアが稼働する実行ノードのIPアドレスがDNS登録されます。(このためにDDNSのノードがあるわけですね。)

そして、各実行ノードでは、Apacheのmod_proxyがクライアントからのアクセスを受け付けて、URLに応じて、該当のアプリケーションにリクエストを振り分けます。(各アプリケーション自身は、local(127.0.x.x)の特定ポートをListenしています。)図にすると、このような感じになります。

また、オートスケール指定の場合は、上図の「Web Application」の部分は、そのアプリケーション用のロードバランサ(HA Proxy)になります。この場合、HA Proxyとその後ろのWeb Applicationサーバの通信が発生しますが、ギア同士の通信は、各実行ノードのHA Proxyがさばく様になっています。(ギアの中で動くロードバランサ用のHA Proxyとは別物です。ややこしいですね。。。)

各実行ノードのHA Proxyは、その中のギア内のアプリケーション機能にアクセスするためのポートを外部に公開します。他のギアは、このポートを指定して該当のギアと通信を行います。これは、WebアプリケーションとバックエンドDBの通信などでも利用されています。図にすると、このような感じです。


WebSocketsのサポートについて

詳細はすっとばしますが、WebSocketsに対応するには、クライアントからのリクエストをさばく実行ノード上のReverse Proxyの対応と、そこから転送されたリクエストを受け取るカートリッジ内のWebアプリケーションの対応が必要になります。

前者については、現行のApache(mod_proxy)では対応しきれないので、Node.jsで新たにProxyServerを書き起こして対応する方向で開発が進んでいます。OpenShift Orignでは、すでにコードはできており、OpenShift Onlineでは、Preview機能として利用可能になっています。(カートリッジ側については、個別に対応が進んでいるようです。)

現在は、後方互換のために、既存のmod_proxyとはポートを分けて、WebSocketsを使用する場合は、8000番ポートと8443番ポートを使用するようになっています。将来的には、mod_proxyは廃止して、WebSockets対応の独自Proxy Serverが標準になる予定とのことです。