JPWO2016017021A1 - 経路解決システム及び経路解決方法 - Google Patents

Abstract

システム構成要素が複数のリージョンにまたがって分散配置される分散システムにおいて、応答性やスループットなどのサービス性能を向上させる。システムを構成する複数の構成要素が複数のリージョンにまたがって配置される分散システムに接続された経路解決システムは、構成要素間の処理性能の計測値をネットワークの性能情報に依存しない標準値に変換し、クライアント端末からのリクエストが転送された構成要素より経路問い合わせ要求を受けると、リクエストを処理するための構成要素を結ぶ複数の経路を導出し、同一のリクエストの標準値に基づき、各経路においてリクエストの処理に要する性能情報の推測値を算出し、算出した推測値に基づき、最適経路を決定する。

Description

本発明は複数の拠点にまたがる分散システムにおいてシステム構成要素間の接続経路を最適化する手段に関する。

情報技術をサービスとして提供するクラウドコンピューティングが普及している。クラウドコンピューティングサービスを提供するクラウドコンピューティングサービスプロバイダ（以降、クラウドプロバイダ）は、世界中のエンドユーザに高い応答性や高いスループット、さらには高いターンアラウンドタイム（TAT）を提供することを目的の一つとして、世界規模にデータセンタを建設している。

クラウドコンピューティングサービスを利用するアプリケーションサービスプロバイダ（以降、アプリケーションプロバイダ）は、このような環境においても、高い応答性やスループット、TATを持つアプリケーションサービスをエンドユーザに提供することが求められている。

特許文献1には、エンドユーザに対して高い応答性やスループット、TATを持つアプリケーションサービスを提供するため、エンドユーザの接続先を近傍のデータセンタに配置されるアプリケーションとする技術が開示されている。

特表2010-503901

しかしながら、特許文献1記載の技術は、アプリケーションシステムが複数のリージョンに分散していない場合に有効であり、アプリケーションシステムを構成するアプリケーションやアプリケーションデータといった構成要素が複数のリージョンに分散しているシステム（以降、分散システム）では応答性やスループット、TATが低くなる場合がある。なお、リージョンとは単一のデータセンタ、もしくは近傍に位置する複数のデータセンタを意味している。また、以降では応答性やスループット、TATなどのアプリケーションサービスの性能を評価する指標をまとめてサービス性能と呼ぶ。

現実に、アプリケーションプロバイダの運用コストや各国法制度などを制約として、必ずしもエンドユーザの近傍にシステム構成要素が配置されているとは限らない。クラウドシステムとして一般的な3階層システムでは、プレゼンテーション層やアプリケーション層の構成要素はエンドユーザの近傍のリージョンに配置され、データ層の構成要素はエンドユーザから遠方の異なる国のリージョンに格納される場合、アプリケーション層とデータ層の間のデータ転送はリージョン間で行われる。一般に、長距離であるほどデータ転送性能は下がる傾向があり、上記のように多量のデータ転送を長距離で行うことで、システム全体のサービス性能が低下してしまう。

また、クラウドシステムのプレゼンテーション層やアプリケーション層などの構成要素は、負荷分散のため重複して配置されることが多い。この場合、どの構成要素を結ぶ経路を選択してエンドユーザ要求を処理したかによって、エンドユーザに対するサービス性能は大きく異なる。例えば、データ層がエンドユーザの遠方に位置する場合、データ層にアクセスしないエンドユーザ要求を処理する際には、エンドユーザの接続先をエンドユーザの近傍にあるプレゼンテーション層やアプリケーション層にした方がよい。一方、遠方にあるデータ層に頻繁にアクセスし、その結果をアプリケーション層で処理することが多いエンドユーザ要求に関しては、エンドユーザ要求を処理するアプリケーション層は遠方のアプリケーション層を選択した方がよい。

上記課題を解決するため、本発明における経路解決システム及び経路解決方法では、システム構成要素が複数のリージョンにまたがって分散配置される分散システムにおいて、エンドユーザ処理にかかる全処理を考慮して高いサービス性能の提供を可能とするシステム構成要素間の経路を決定する。

具体的には、本発明における分散システムの経路解決システムは、分散システムを構成する複数の構成要素のアドレスと種類とを含む構成情報を管理する構成管理部と、複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理するインフラ性能管理部と、複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理するエンドユーザトレース管理部と、構成情報とネットワーク性能情報と処理性能情報とに基づき、処理性能情報の計測値をネットワークの性能情報に依存しない標準値に変換し、リクエストが転送された構成要素より経路問い合わせ要求を受けると、構成情報に基づき、リクエストを処理するための複数の構成要素を結ぶ複数の経路を導出し、複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせのリクエストの標準値を特定し、特定した標準値とネットワーク性能情報とに基づき、複数の経路の各々においてリクエストの処理に要する性能情報の推測値を算出し、算出した推測値に基づき、最適経路を決定する評価部を備える。

また、本発明における分散システムの経路解決方法では、分散システムを構成する複数の構成要素のアドレスと種類とを含む構成情報を管理し、複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理し、複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理し、構成情報とネットワーク性能情報と処理性能情報とに基づき、処理性能情報の計測値をネットワークの性能情報に依存しない標準値に変換し、リクエストが転送された構成要素より経路問い合わせ要求を受けると、構成情報に基づき、リクエストを処理するための複数の構成要素を結ぶ複数の経路を導出し、複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせのリクエストの標準値を特定し、特定した標準値とネットワーク性能情報とに基づき、複数の経路の各々においてリクエストの処理に要する性能情報の推測値を算出し、算出した推測値に基づき最適経路を決定する。

本発明によれば、分散システムのサービス性能を向上できる。

本発明の第一の実施形態を例示するブロック図である。 本発明におけるリージョンを例示する図である。 本発明の第一の実施形態におけるシステム構成要素間のコミュニケーションを例示する図である。 経路解決システムのフローを例示する図である。 エンドユーザトレース管理部の管理するテーブルを例示する図である。 エンドユーザトレース管理部の管理するテーブル、インフラ性能管理部、構成管理部の管理するテーブルを例示する図である。 評価部により導出されるエンドユーザ要求を処理できる複数パスのサービス性能のリストと経路解決システムの応答を例示する図である。 経路解決システムの設定画面を例示する図である。 本発明の第二の実施形態を例示するブロック図である。 本発明の第二の実施形態におけるシステム構成要素間のコミュニケーションを例示する図である。 本発明の第三の実施形態を例示するブロック図である。 経路伝達のフローを例示する図である。 解決履歴管理部の管理するテーブルを例示する図である。

以下、本発明の実施形態について説明する。

以下、図面を用いて本発明の第一の実施形態を詳細に説明する。なお、全図に示す同一の番号は同一の機能を持つため説明を省略する。

図1は本発明の一実施形態に係る経路解決手段を示す構成図である。クライアント1はクラウドコンピューティング上で提供されるサービスの提供を受ける。ここでは、クライアント１も分散システムを構成する一つの構成要素であると定義する。DNS 2はクライアントやアプリケーションシステムからの要求を受けて名前解決を行うドメインネームシステム（Domain Name System）である。具体的に、クライアントなどから送られるFQDN（Fully Qualified Domain Name）をIPアドレスへと変換する。リージョンA〜C 3はクラウドコンピューティングのデータセンタもしくは近傍に位置する複数のデータセンタを指す。なお、リージョンA〜C 3はクラウドコンピューティングに限定されず、コンピューティング環境全般を指す。また、リージョンAはリージョンBと、もしくはリージョンCと同じでリージョンでも構わない。アプリケーションA, B 4はアプリケーションシステムにおけるプレゼンテーション層やアプリケーション層に相当する。

経路解決システム 5はアプリケーションA, B 4からの問合せを受け、エンドユーザ要求を処理するシステム構成要素の最適な組合せ、換言して最適経路を解決する。データベース 6はアプリケーションシステムにおけるデータ層に相当する。経路問合せ部 10は最適経路を経路解決システム 5に問い合わせる。経路切換え部 11は経路解決システム 5から返され、経路問合せ部10が受信する経路情報を元に、経路を切り替える。評価部12は、エンドユーザトレース管理部13、インフラ性能管理部14、構成管理部15の情報を用いて、経路問合せ部10から送信されるエンドユーザ要求内容とエンドユーザの位置に対して、アプリケーションプロバイダの指定する要件に関して最良の経路を評価する。

エンドユーザトレース管理部13は、エンドユーザトレース収集部16にて収集される、エンドユーザによるアプリケーションやデータベースの利用履歴等であるエンドユーザトレースを管理する。インフラ性能管理部14は、インフラ性能収集部17にて収集される、システム構成要素が配置される各リージョンのシステム性能、具体的にコンピューティングリソースの性能やストレージI/O性能、ネットワーク性能などを管理する。構成管理部15は、システム構成要素の位置や種別、システム構成要素が配置されるコンピューティングリソースの性能仕様などのシステム構成を管理する。

これらの要素1〜17はネットワークを介して接続されており、A1はクライアント1が名前解決を行う際のDNS 2への問合せを示し、A2は名前解決されたアプリケーションへの接続を示し、A3は経路問合せ部10による経路問合せ要求を示す。また、A10はエンドユーザトレース収集部16によるエンドユーザトレース管理部13へのエンドユーザトレースの送信を示し、A11はインフラ性能収集部17によるインフラ性能管理部14へのインフラ性能情報の送信を示す。

図2は、リージョンの一例を示すブロック図である。なお、図示では、図2では一つのデータセンタで構成されるリージョンを示しているが、複数のデータセンタからなるリージョンも図示するリージョン3-1が複数接続されるだけである。

リージョン3-1は、複数のコンピューティングノード（#1〜#n）200-1〜200-nと、ストレージ装置250と、ゲートウェイ装置270とを相互に接続するネットワーク260と、を有する。ノード200-1〜200-nの総称を、ノード200で表す。各ノード200は、内部のネットワーク260とゲートウェイ装置270を介して外部のネットワーク50からクライアント1と管理計算機100に接続されている。

ノード（#1）200-1は、物理計算機201-1と、物理計算機201-1の計算機資源を1以上の仮想計算機210-1〜210-nに割り当てる仮想化部202-1と、各仮想計算機202-1〜202-nのOS 211-1〜211-n上で稼動するアプリケーション4-1〜4-nと、を含む。OS 211-1〜211-nの総称をOS 211とし、同様にアプリケーション4-1〜4-nの総称をアプリケーション4とする。なお、物理計算機201-1は、プロセッサ2011とメモリ2012とを含んで構成される。

ストレージ装置250は、OS 211やアプリケーション4またはアプリケーション4が利用するデータベース6などが格納される。リージョン3-1では、管理計算機100からの指令に応じて、1以上の仮想計算機210を生成して、OS 211、アプリケーション4を実行させ、アプリケーション4のサービスをクライアントに提供する。

図3はクライアント1が要求する処理内容にとってのシステム構成要素の最適経路を解決し、システム構成要素間の接続を制御するコミュニケーション図を示す。なお、図3は本実施例で提示する経路解決手段の全体概要を示す図であり、個々の詳細は図4〜図7を用いて後述する。

クライアント1はアプリケーションサービスに接続するために、アプリケーションサービスのドメインをDNSに問い合わせてIPアドレスを獲得しなければならない。そこで、クライアント1はDNS 2に対して名前解決を要求する（C1）。DNS 2は要求されるドメインのIPアドレスを解決し（C2）、接続元であるクライアント1に解決結果を応答する（C3）。なお、この時に応答で得られるIPアドレスはアプリケーションA 4のIPアドレスとする。これは、DNS 2がエンドユーザとアプリケーションシステムの応答時間を監視し、応答時間の短いアプリケーションのIPアドレスを返すためである。このレイテンシベースの名前解決は分散システムにおいて最も使われる方法である。DNSでは、レイテンシベースの名前解決以外に、静的に対応するIPアドレスを返す静的名前解決方法や、複数のアプリケーションのIPアドレスをラウンドロビン方式などによりクライアントに応答する動的名前解決方法などがある。ここで、アプリケーションサービスを分散システムとする第一の理由は、サービス性能の向上であり、その他の理由としてサービス継続性などが挙げられる。この2つの理由に対して、静的名前解決方法は有益ではなく、動的名前解決方法はサービス継続性にのみ有効である。それゆえ、分散システムにおいてはレイテンシベースの名前解決方法が用いられている。

続けて、クライアント1は解決されたIPアドレスを用いてアプリケーションA 4にリクエストを発行する（C4）。アプリケーションA 4の経路問合せ部10は経路解決システム5（図3ではRoute Name System: RNSと呼称する）に対して経路解決を要求する（C5）。経路解決システム5はリクエストに含まれるエンドユーザ要求内容に従い経路を導出し（C6）、経路情報を要求元であるアプリケーションA 4の経路問合せ部10に応答する（C7）。

アプリケーションA 4の経路切替え部11はC7で獲得した経路情報を参照し、アプリケーションA 4が経路に含まれているかを確認し（C8）、含まれていれば、もしくは経路情報が空であれば、アプリケーションA 4に制御を渡しアプリケーションA 4の処理を実施する（C9）。なお、この時、データベース6での処理が必要であれば処理要求を行い、データベース6は処理を実施する（C16）。クライアント1はアプリケーションA 4の応答を受信し（C10）、処理を完了する。

C8にてアプリケーションA 4が経路に含まれていなければ、経路切換え部11は経路情報に含まれる切り替え手段に従い、一旦クライアント1にリダイレクト要求を行い（C12）、クライアント1から直接アプリケーションB 4へ再リクエストをしてもらうか（C13）、アプリケーションB 4へ処理を転送（フォワード）する。

経路問合せ部10は経路解決システム5への問合せを実施するだけであり、その処理を関数やメソッド、クラスやオブジェクトなどの形式でライブラリとして提供することで、アプリケーションプロバイダの開発者は容易に実装できる。また、経路切替え部11は経路問合せ部10が受信した経路情報を参照し、経路切替え部11が埋め込まれるアプリケーションで処理するか、別のアプリケーションで処理するかを決定し、別のアプリケーションで処理する場合にはリダイレクトするか、フォワードするかを決定するだけである。それゆえ、前述の経路問合せ部10と同様に、ライブラリとして提供することで、アプリケーションプロバイダの開発者は容易に実装できる。経路問合せ部10と経路切換え部11は、ライブラリの読み込み等の処理を除くアプリケーションの先頭に数行挿入するだけで、本実施例で示す機能を活用することができる。

また、本機能の実装に関して、アプリケーションA, B 4やデータベース6などのシステム構成要素はソースコードなど改変可能ではなく、バイナリなど改変不可能であるかもしれない。その際は、経路解決用のリバースプロキシを、アプリケーションA, B 4やデータベース6などのシステム構成要素の前段の要素として、同じリージョンに用意することで本機能を実装できる。具体的に、アプリケーションA 4がバイナリである場合、アプリケーションA 4に設定されるIPアドレスとポートを持つリバースプロキシを、リージョンB 3に設置し、アプリケーションA 4のIPアドレスとポートを任意に変更し、クライアント1はリバースプロキシに接続し、必要に応じて、リバースプロキシはアプリケーションA 4に接続すれば良い。たとえアプリケーションA 4がバイナリであっても、IPアドレスやポートの変更は可能であることが多い。

続けて、アプリケーションB 4の経路問合せ部10は、クライアント1から再送信、もしくはアプリケーションA 4から転送される要求を受け、C5〜C7と同様の処理を行い、経路情報を取得する（C14）。この時、C5での問合せと、C14の問合せは、C5からC14の間に障害等が発生しない限り、同じ内容の経路情報が応答される。これは、リージョンの状態を除き、経路解決システム5の返す経路情報はクライアント1から発行されるエンドユーザ要求内容と、クライアント1の位置のみに依存するためである。

続けて、アプリケーションB 4の経路切換え部11は自身が埋め込まれるアプリケーションB 4のアドレスが経路情報に含まれているため、制御をアプリケーションB 4に渡し、アプリケーションB 4はリクエストを処理する（C15）。その際、必要に応じてデータベース6は処理を行い（C16）、その後、処理結果をクライアント1に返し、クライアント1は応答を受信する（C17）。

次に、図4〜図7を用いて、経路解決システム5の処理内容を説明する。図4は経路解決システム5の処理フローを示す。経路解決システム5の評価部12は経路問合せ部10から送信されるエンドユーザ要求であるリクエストを受信し、リクエストに含まれるエンドユーザ要求内容をもって、テーブルT1を照合する（F1）。

ここで、テーブルT1はエンドユーザトレース管理部13により管理されるテーブルである。エンドユーザトレースとは、クライアント1や全てのシステム構成要素（アプリケーションA, B 4やデータベース6）の間でやり取りされる要求や、応答に係る通信や処理をエンドユーザトレース収集部16が監視し得られる情報である。エンドユーザトレース情報の取得は、公知または周知の手法を採用することができる。例えば「Dapper, a large-scale distributed systems tracing infrastructure.」（Sigelman, Benjamin H., et al. 2010, Google research）に開示される手法を適用すればよい。

テーブルT1の各行はエンドユーザトレース収集部16が収集する1エンドユーザトレースに相当する。テーブルT1の各行の情報であるエンドユーザトレース情報で取得する情報は、本実施例を実現する上で好ましい例であり、これに限定するものではない。

本実施例で示す経路解決手段は、実際のエンドユーザ要求処理の履歴を元に、アプリケーションプロバイダの指定する要件に従った最良な経路の解決と、経路の切換えを実施する。それゆえ、実際のエンドユーザ要求処理の履歴が十分に確保されていなければ、経路解決をしない。経路解決をしない際は、アプリケーションシステムは従来と同じ経路を通って接続されるだけである。そこで、エンドユーザトレースの収集及び管理に関する説明にあたり、従来の接続経路である、クライアント1からのリクエストに対して、データベース6のデータにアクセスし、アプリケーションA 4が必要な処理を施す例を用いる。この例において、クライアント1のエンドユーザトレース収集部16はクライアントとアプリケーションA 4間の通信や処理に関する情報を一つのエンドユーザトレースとしてまとめて、エンドユーザトレース管理部13に送信し、エンドユーザトレース管理部13はテーブルT1に格納する。

同様に、リージョンA 3のエンドユーザトレース収集部13はアプリケーションA 4とデータベース6の間の通信や処理を一つのエンドユーザトレースとしてまとめて、エンドユーザトレース管理部13に送信し、エンドユーザトレース管理部13はテーブルT1に格納する。そして、エンドユーザトレース管理部13は、一つのエンドユーザ要求から派生したエンドユーザトレース全てをセットとして、管理する。また、エンドユーザトレース管理部13はエンドユーザトレースセットを管理するためにテーブルT3を用いても良い。テーブルT3の各行は1つのエンドユーザトレースセットに相当する。

テーブルT1において、トレースIDは個々のエンドユーザトレースを識別するための識別子であり、親IDはエンドユーザトレース間で親関係のある識別子であり、兄弟IDはエンドユーザトレース間で兄弟関係のある識別子であり、セットIDは一つのエンドユーザ要求から派生した全てのエンドユーザトレースをまとめたセットに対して与えられる識別子である。送信元アドレスはエンドユーザトレースの処理要求の発信元を識別するアドレスであり、送信先アドレスはエンドユーザトレースの処理要求の発信先を識別するアドレスである。応答時間とスループット、TATはそれぞれエンドユーザトレース処理に要した性能情報である。

ここで、一つのエンドユーザトレースの処理には1つもしくは複数の要求が含まれる場合がある。例えば、エンドユーザがhttp://example.com/にアクセスするために、クライアントのブラウザソフトウェアのアドレスバーに当該アドレスを入力する場合、エンドユーザが発行する要求（以降、主要求とする）はhttp://example.com/の一つであるが、ブラウザソフトウェアは、エンドユーザの指定する要求を満足するために、http://example.com/sample_imageなどを自動的に要求する（以降、従属要求とする）。そこで、本実施例では、同一の送信元アドレスと同一の送信先アドレスを含む要求と応答の通信と処理を一つのエンドユーザトレースとして管理することを想定している。なお、この管理方法は限定ではない。

また、応答時間とはエンドユーザトレースに含まれる最初の要求が完了する時間であり、TATはエンドユーザトレースに含まれる全ての要求が完了する時間である。テーブルT1のトレースID1, 2のデータは上記に例示したクライアント（送信元アドレスがxxx.xxx.xxx.xxx）−アプリケーションA 4（送信元アドレスがyyy.yyy.yyy.yyy）−データベース6（送信元アドレスがzzz.zzz.zzz.zzz）の接続に要したデータを例示している。ここで、トレースID 1のTATがトレースID 2のTATより大きいのは、トレースID 1のTATがトレースID 2のTATを含んでいるためである。

なお、テーブルT1に格納されるエンドユーザトレースは、送信元アドレスと、送信先アドレス、要求クエリ、付加情報に関して同じ値を持つものをまとめて一つのエンドユーザトレースとしても良い。経路解決システム5は、エンドユーザ要求内容により、テーブルT1を検索し、その検索結果のサービス性能情報を用いて、最適な経路を導出する。それゆえ、エンドユーザトレース収集部16が収集する生のエンドユーザトレースをそのまま管理する必要はない。よって、テーブルT1に含まれる応答時間、スループット、TATはまとめられるエンドユーザトレースの統計値となっている。ここで、統計値はどのような値でも良く、平均値、最大・最小値、中央値などが用いられる。また、統計値を用いる場合は、直近の状況を反映するために、移動平均などを用いると良い。また、テーブルT1において、要求クエリは主要求である。付加情報とは要求クエリに付加される情報を示す。例えば、エンドユーザトレースがHTTPである場合のCookieがこの付加情報に該当する。

続けて、F1の結果が空であれば（F2）、空の経路情報を要求者に返答する（F9）。一方、F2の結果が空でなければ、F1の結果をテーブルT3に照合し、エンドユーザ要求リクエストを含むエンドユーザトレースセットを獲得する（F3）。続けて、F3で得られたエンドユーザトレースセットに含まれるエンドユーザトレースに関わるシステム構成要素のアドレスを送信先アドレスもしくは送信元アドレスから取得し（F4）、構成管理部15が管理するテーブルT6を読み込み、F4で取得した情報を用いてシステム構成要素の仕様情報を獲得する（F5）。

ここで、テーブルT6は構成管理部15の管理するテーブルであり、アプリケーションシステムの静的な情報が含まれる。テーブルT6に含まれる情報は一例であり、好ましい最低限必要な情報である。テーブルT6において、システム構成要素アドレスはシステム構成要素を一意に識別するためのアドレスであり、本実施例では各システム構成要素のIPアドレスとしている。位置はリージョンA〜C 3の位置情報を示し、これは緯度と経度による表記などでも良く、ＩＰアドレスなどのネットワーク位置情報を保持しておき、GeoIPデータベースサービスなどで変換しても良い（例えば、Quova IP Geo-Location Database. <http://www.quova.com>）。

また、構成種別はアプリケーションやデータベースなどの種別を示し、インスタンスセットは当該システム構成要素が配置されるコンピューティングリソースの性能仕様を示す情報である。ここで、インスタンスセットはコンピューティングリソース性能を表現する情報であれば特に限定しない。本実施例では、1つのコンピューティングリソースあたりの性能を表現する情報と、その数で表現している。例えば、CPUやメモリなどの性能指標を用いても良い。また、性能指数は現在のコンピューティング環境での最小のインスタンスセットを1とする時の指数である。この情報は必須ではないが、後述する経路計算の際にこの情報があると好ましい。

続けて、評価部12はエンドユーザ要求処理を実現できる複数の経路を導出する（F6）。本実施例の場合、説明を簡単にするためにシステム構成要素が少なく、経路を導出することは容易である。具体的に、クライアント1からアプリケーションA 4、データベース6と接続する経路と、リダイレクトによりクライアント1からアプリケーションB 4、データベース6と接続する経路と、クライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路である。しかし、一般には一つのエンドユーザ要求を処理するために、多数のシステム構成要素が関連する場合がある。その場合は、既存の探索アルゴリズム、例えばダイクストラ法などのグラフ探索法やA*探索アルゴリズムなどを用いれば良い。続けて、評価部12はF6で導出した複数のパスのサービス性能の推定値を導出する（F7）。まず、評価部12はインフラ性能管理部13の管理するテーブルT4〜T6を用いて、テーブルT1からテーブルT2を作成する。

テーブルT4はインフラ性能管理部13により管理されるテーブルで、エンドユーザとリージョン間、複数のリージョン間のネットワーク性能を評価する際の評価単位を管理するテーブルである。テーブルT4のネットワークGIDは、前記評価単位の識別子であり、アドレス範囲は前記評価単位に含まれるアドレスの範囲を示す。グループの分割は特に限定するものではないが、システム構成要素種別（テーブルT6の構成種別）と距離（本実施例ではリージョン）を軸に分割することが好ましい。例えば、テーブルT4では、4つのグループを管理しており、GID 1〜4のそれぞれは、近傍に位置する複数のエンドユーザのアドレスを含むグループ、リージョンA 3に含まれシステム構成種別がアプリケーションであるシステム構成要素のアドレスを含むグループ、リージョンB 3に含まれシステム構成種別がアプリケーションであるシステム構成要素のアドレスを含むグループ、リージョンB 3に含まれシステム構成種別がデータベースであるシステム構成要素のアドレスを含むグループを示す。

テーブルT5はインフラ性能管理部13により管理されるテーブルで、テーブルT4のネットワークグループ間のネットワーク性能の実際の評価結果を格納するテーブルである。テーブルT5の各行ははインフラ性能収集部17が収集し、インフラ性能管理部14に送信し、インフラ性能管理部14がテーブルT5に格納した情報である。

テーブルT5において、IDは各評価の識別子であり、ネットワークは性能計測対象のネットワークを示す。例えば、テーブルT5のID 1のネットワークはネットワークグループ1とネットワークグループ2の間のネットワーク性能である。つまりは、クライアント1とアプリケーションA 4間のネットワーク性能である。また、応答時間、スループット、TATはそれぞれのネットワークの性能測定値を指す。

なお、テーブルT5に格納される性能情報は、インフラ性能収集部17が収集する一つ一つの性能情報ではなく、各ネットワークにてまとめて管理しても良い。経路解決システム5は、テーブルT5の情報を用いて、最適な経路を導出する。それゆえ、インフラ性能収集部17が収集する生の性能情報をそのまま管理する必要はない。よって、テーブルT5に含まれる応答時間、スループット、TATはまとめられた統計値となっている。ここで、統計値はどのような値でも良く、平均値、最大・最小値、中央値などが用いられる。また、統計値を用いる場合は、直近の状況を反映するために、移動平均などを用いると良い。

テーブルT2において、要求クエリ、トレースID、親ID、兄弟ID、セットID、送信元アドレス、送信先アドレスはテーブルT1と同じである。正規化応答時間、正規化スループット、正規化TATはそれぞれ、テーブルT1の応答時間、スループット、TATをテーブルT4〜T6を用いて変換したものである。

この正規化する目的は、ネットワーク距離とネットワーク性能、コンピューティングリソース性能に依存するテーブルT1のサービス性能を、それらに対して非依存にすることである。これは、他の経路におけるサービス性能を導出するために必要となる。ここで、どのような方法で正規化しても良いが、本実施例では、テーブルT1のサービス性能をそれぞれのネットワーク性能で除算している。

具体的に、テーブルT1のトレースID 1の応答時間を正規化では、テーブルT5のID 1の応答時間で除算している（15ms/10ms=1.5）。ここで、本実施例にてコンピューティングリソースを考慮していないのは、テーブルT6に示すように、アプリケーションA 4とアプリケーションB 4のコンピューティングリソース性能が同じであり、また、データベース6は一つのみであり、コンピューティングリソースを考慮する必要がないためである。一般には、
（数式1）に示すように正規化すれば良い。ここで、p_iはテーブルT1のi行のサービス性能値であり、pn_jはテーブルT5のj行の対応するサービス性能であり、pc_kはテーブルT6のk行の対応する性能指数である。また、α_nはpnにかかる係数、α_cはpcにかかる係数であり、これらは任意である。
（数式1）
p_i/(α_n * pn_j + α_c * pc_k), i=1,2,..., n, j=1,2,..., m, k=1,2,..., s
なお、テーブルT2はF7の段階で導出しても、図4に至る前に事前に、具体的にエンドユーザトレース管理部13が定期的に生成しても良い。

続けて、評価部12は、テーブルT2を用いて、F6で導出した複数の経路のサービス性能の推定値を算出する。これは、各経路に含まれるネットワークやコンピューティングリソースの基礎性能（テーブルT5とテーブルT6記載の性能）を用いて、前述した正規化手順の逆の手順で変換すれば良い。推定値の算出方法の詳細については後述する。

評価部12による、F6で導出した複数の経路のサービス性能の推定値導出結果の例をテーブルVT1に示す。テーブルVT1の各行は、前述した考慮できる複数の各経路を示す。テーブルVT1の列は、大きくクライアント1−アプリケーション層間のサービス性能、アプリケーション層−データベース層間のサービス性能、全体合計のサービス性能を示す。

まず、クライアントとアプリケーション層間のサービス性能の推定値の算出方法についてVT1を例に説明する。評価部12は、T3を参照し、要求クエリ、T2の送信元アドレスと送信先アドレスが一致する行の正規化された性能情報（標準値）を取得する。例えば、クライアント（xxx.xxx.xxx.xxx）＞アプリケーションA（yyy.yyy.yyy.yyy）＞データベース（zzz.zzz.zzz.zzz）の経路においては、評価部12はT3より正規化応答時間の1.5を取得する。
但し、T2の送信元アドレスと送信先アドレスが一致するものがない場合、評価部12はT6を参照し、送信元アドレスと送信先アドレスの構成要素の種類が一致するものを選択する。例えば、クライアント（xxx.xxx.xxx.xxx）＞アプリケーションB（sss.sss.sss.sss）＞データベース（zzz.zzz.zzz.zzz）の経路においては、評価部12はT3より正規化応答時間の1.5を取得する。

次に、評価部12は、T5を参照し、ネットワーク性能を加味した性能情報の推定値を算出する。例えば、クライアント＞アプリケーションA＞データベースの経路においては、T5よりクライアントとアプリケーションA間のネットワークの応答時間は10ｍｓと特定できるので、正規化応答時間の1.5×10ms = 15msがクライアントとアプリケーション間の応答時間の推定値である。クライアント＞アプリケーションB＞データベースの経路においては、T5よりクライアントとアプリケーションB間のネットワークの応答時間は100ｍｓと特定できるので、正規化応答時間の1.5×100ms = 150msがクライアントとアプリケーションB間の応答時間の推定値である。但し、この場合、クライアントからリクエストを受信したアプリケーションAからクライアントにリクエストが戻されるので（図3のREDIRECT処理に相当）、クライアントとアプリケーションA間の応答時間の推定値である15msが加算される。すなわち、150ms+15ms=165msがクライアントアプリケーション間の応答時間の推定値となる。

スループットやTATなどの他の性能情報も同様に算出される。また、アプリケーションとデータベース間の性能情報の推定値も同様に算出される。

テーブルVT1によると、応答時間に関しては、クライアント1からアプリケーションA 4、データベース6と接続する経路が良く、スループットに関しては、リダイレクトによりクライアント1からアプリケーションB 4、データベース6と接続する経路が良く、TATに関してはクライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路が良いという結果である。

続けて、評価部12は、アプリケーションプロバイダの指定する要件に照らして、最良の経路を選択する（F8）。 アプリケーションプロバイダは、経路解決システムの有効化の設定や、要件の設定を行うことができる。図8は経路解決システムの設定画面を例示する図である。図8では、TATが要件として設定されているので、F8において評価部12は、全体合計のTATが最少となる経路、すなわち、クライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路を選択する。

続いて、経路解決システム5は評価部12がF8にて導出した経路情報を要求者に返答する（F9）。図7のR1に、その応答の書式を例示する。R1はJSONフォーマットとして例示しており、アプリケーションA 4に含まれる経路問合せ部10からの問合せの場合の、F8にて選択した、クライアント1からアプリケーションA 4を経由してアプリケーションB 4、データベース6と接続する経路を示している。R1では、経路情報として、経路に含まれる全アドレス、経路における問合せ時点の位置、経路切換え方法が記載される。ここで、経路に含まれるのはドメインではなくアドレスが望ましい。ドメインで通知すると、当該通知ドメインを再びDNSを用いて名前解決するため、導出した経路情報が無意味になるためである。また、R1のように、経路に含まれる全アドレスと、経路における問合せ時点の位置を含むのでなく、経路における問合せ時点以降の経路のみを記載してもよい。経路解決システム5の応答する経路情報のフォーマットは限定しない。

本実施例に用いられる技術により、分散システムにおいて、アプリケーションサービスは、アプリケーションプロバイダの指定する要件に従った最良なサービス性能をエンドユーザに提供することが可能になる。

図面を用いて本発明の第二の実施形態を詳細に説明する。なお、全図に示す同一の番号は同一の機能を持つため説明を省略する。

第一の実施例は、要求元のリクエストを受ける要求先が経路の切換えを実施する例であった。本実施例は、要求元が、最良の経路情報に従い、経路を切り替える例である。

図9は本発明の一実施形態に係る経路解決手段を示す構成図である。宛先書換え部20は経路解決システム 5から返され、経路問合せ部10が受信する経路情報を元に、経路を切り替える。

図10はクライアント1が要求する処理内容にとってのシステム構成要素の最適経路を解決し、システム構成要素間の接続を制御するコミュニケーション図を示す。

クライアント1はC1〜C3の処理を実施し名前を解決する。続けて、C5〜C7を実施し、経路を解決する。続けて、C7で得られた経路情報を元に、接続先を変更する。先のR1によると、DNSにより得られたyyy.yyy.yyy.yyyのアドレスを持つアプリケーションA 4に接続するのではなく、sss.sss.sss.sssを持つアプリケーション B 4に接続する。

ここで、宛先書換え部20は経路問合せ部10が受信した経路情報を参照し、接続先を書き換えるだけである。宛先書換え部20の容易な実装方法として1つの手法を例示する。アプリケーションの接続先が記載されるコード箇所を全て修正するのは手間であるため、宛先書換え部20をライブラリとして用意し、クライアント1及び全てのシステム構成要素のネットワークライブラリに含まれるAPIの呼び出しをフックし、元々の宛先部分を経路情報で得られた接続先のアドレスへと書き換える。

本実施例に用いられる技術により、分散システムにおいて、アプリケーションサービスは、アプリケーションプロバイダの指定する要件に従った最良なサービス性能をエンドユーザに提供できる。

図面を用いて本発明の第三の実施形態を詳細に説明する。なお、全図に示す同一の番号は同一の機能を持つため説明を省略する。

第一の実施例は、システム構成要素に要求が届くたびに、経路解決のために経路解決システムに問合せを行った。また、経路解決システムは要求が届くたびに最適な経路の導出を行った。本実施例ではこれらの効率化を図ることを目的とする。

図11は本発明の一実施形態に係る経路解決手段を示す構成図である。経路伝達部30は、経路問合せ部10が受信した経路情報を、経路切替え部11がリダイレクトもしくはフォワードにより経路を切替える際に、クライアント1もしくは他のシステム構成要素に送信する通信に経路情報を埋め込む。また、システム構成要素が要求を受信した際に、経路情報を通信内容から確認する。解決履歴管理部31は解決した経路情報を一定期間保持しておき、評価部12に対して過去の経路情報を提供する。

図12は経路伝達部30と、経路問合せ部10、経路切替え部11の動作フローを示した図である。経路伝達部30は受信した要求に経路情報が含まれているかを確認し（F11）、含まれていれば経路問合せ部10に問合せを依頼せずに、送付された経路情報を利用する（F13）。一方、経路情報が含まれていなければ、経路問合せ部10に問合せを依頼する（F12）。経路問合せ部10の問合せ方法は、実施例1で説明したとおりである。また、経路情報を獲得した後の処理も実施例1と同様に、経路切換えを実施すれば良い（F14）。

なお、本実施例の実装に関して、経路切替え部11にてリダイレクトが選択される場合、リダイレクトされた接続元は新たにリクエストを生成し直す。それゆえ、HTTPの場合、経路情報はCookieに書込み、その後リダイレクトすることが好ましい。

図13は解決履歴管理部31の管理するテーブルと、解決履歴管理部31を含む経路解決システム5の経路解決の際の処理フローを示す。

評価部12は図4のF8処理後、要求内容と経路情報、その有効期限に関する情報を解決履歴管理部31に渡す。解決履歴管理部31は図13のテーブルT10のように、その情報を格納する。解決履歴管理部31は定期的に、もしくはイベントドリブンに有効期限を確認し、有効期限が切れた履歴は消去する。

また、評価部12は、図4の処理フローを実施する前に、解決履歴管理部31に要求内容をもって問合せ（F21）、解決履歴管理部31はテーブルT10の要求クエリ列に対して要求内容に合致する項目を抽出し、その結果を評価部12に返答する。評価部12は、その結果が空であれば（F22）、図4のF1〜F8を実施し、空でなければ、その情報によりF9を実施する。

なお、本実施例では、実施例1を拡張して記載したが、実施例2記載の方法と併用しても良い。本実施例に用いられる技術により、分散システムにおいて、高速に経路解決を実施することが可能になる。

5 経路解決システム
10 経路問合せ部
11 経路切換え部
12 評価部
13 エンドユーザトレース管理部
14 インフラ性能管理部
15 構成管理部
20 宛先書換え部
30 経路伝達部
31 解決履歴管理部

Claims (8)

1. システムを構成する複数の構成要素が複数のリージョンにまたがって配置される分散システムに接続された経路解決システムであって、
   前記複数の構成要素のアドレスと種類とを含む構成情報を管理する構成管理部と、
   前記複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理するインフラ性能管理部と、
   前記複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した前記複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理するエンドユーザトレース管理部と、
   前記構成情報と前記ネットワーク性能情報と前記処理性能情報とに基づき、前記処理性能情報の計測値を前記ネットワークの性能情報に依存しない標準値に変換し、
   前記リクエストが転送された前記構成要素より経路問い合わせ要求を受けると、前記構成情報に基づき、前記リクエストを処理するための複数の前記構成要素を結ぶ複数の経路を導出し、前記複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせの前記リクエストの前記標準値を特定し、特定した前記標準値と前記ネットワーク性能情報とに基づき、前記複数の経路の各々において前記リクエストの処理に要する性能情報の推測値を算出し、算出した前記推測値に基づき、最適経路を決定する評価部、とを備える経路解決システム。
2. 請求項１に記載された経路解決システムに接続された前記分散システムであって、
   前記分散システムを構成する前記各構成要素は、
   前記経路解決システムへ前記リクエストを処理するための経路を問い合わせる経路問い合わせ部と、
   前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に前記構成要素自身が含まれているかを判定し、含まれている場合は前記リクエストを処理し、含まれていない場合は、前記最適経路に含まれる他の構成要素または前記クライアント端末へ前記リクエストを転送する経路切り替え部、とを備える分散システム。
3. 請求項２に記載された分散システムであって、
   前記分散システムを構成する前記各構成要素は、
   更に、前記リクエストに前記最適経路を付加して転送する経路伝達部を備える分散システム。
4. 請求項１に記載された経路解決システムに接続された前記分散システムであって、
   前記クライアント端末は、
   前記経路解決システムへ前記リクエストを処理するための経路を問い合わせる経路問い合わせ部と、
   前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に基づき前記リクエストの転送先を決定する経路書換え部、とを備える分散システム。
5. システムを構成する複数の構成要素が複数のリージョンにまたがって配置される分散システムに接続された経路解決システムの経路解決方法であって、
   前記複数の構成要素のアドレスと種類とを含む構成情報を管理し、
   前記複数の構成要素間のネットワークの性能情報の計測値を含むネットワーク性能情報を管理し、
   前記複数の構成要素の一つであるクライアント端末からのリクエスト毎の処理に要した前記複数の構成要素間の性能情報の計測値の集計値を含む処理性能情報を管理し、
   前記構成情報と前記ネットワーク性能情報と前記処理性能情報とに基づき、前記処理性能情報の計測値を前記ネットワークの性能情報に依存しない標準値に変換し、
   前記リクエストが転送された前記構成要素より経路問い合わせ要求を受けると、前記構成情報に基づき、前記リクエストを処理するための複数の前記構成要素を結ぶ複数の経路を導出し、前記複数の経路に含まれる隣接する構成要素の種類が同じ組み合わせの前記リクエストの前記標準値を特定し、特定した前記標準値と前記ネットワーク性能情報とに基づき、前記複数の経路の各々において前記リクエストの処理に要する性能情報の推測値を算出し、算出した前記推測値に基づき最適経路を決定する、経路解決方法。
6. 請求項５に記載された経路解決方法であって、
   前記分散システムを構成する前記各構成要素は、
   前記経路解決システムへ前記リクエストを処理するための経路を問い合わせ、
   前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に前記構成要素自身が含まれているかを判定し、含まれている場合は前記リクエストを処理し、含まれていない場合は、前記最適経路に含まれる他の構成要素または前記クライアント端末へ前記リクエストを転送する、経路解決方法。
7. 請求項６に記載された経路解決方法であって、
   前記分散システムを構成する前記各構成要素は、
   更に、前記リクエストに前記最適経路を付加して転送する、経路解決方法。
8. 請求項１に記載された経路解決方法であって、
   前記クライアント端末は、
   前記経路解決システムへ前記リクエストを処理するための経路を問い合わせ、
   前記経路システムより、決定された前記最適経路を受信すると、前記最適経路に基づき前記リクエストの転送先を決定する、経路解決方法。

Images