(57)【要約】アプリケーション側に手を加えることなく可用性を向上させることが可能な転送制御装置、転送制御方法、および転送制御プログラムを提供する。転送制御装置１は、イネーブラ２の切り替えを動的に実施する装置であって、類似した機能を持つイネーブラ２を同一ジャンルとして登録する登録部１１と、イネーブラ２の状態を監視する監視部１２と、イネーブラ２を呼び出す際、イネーブラ２が所定のｂｕｓｙ状態であるときは、イネーブラ２と同一ジャンルとして登録されている他のイネーブラ２にリクエストを転送し、自動的にリクエスト先を切り替える転送制御部１３とを備える。
2019230315.tif 000002
【特許請求の範囲】
【請求項１】
イネーブラの切り替えを動的に実施する転送制御装置であって、
類似した機能を持つ複数のイネーブラを同一ジャンルとして登録する登録部と、
前記イネーブラの状態を監視する監視部と、
前記イネーブラを呼び出す際、前記イネーブラが所定のｂｕｓｙ状態であるときは、前記イネーブラと同一ジャンルとして登録されている他のイネーブラにリクエストを転送し、リクエスト先を切り替える転送制御部と
を備えることを特徴とする転送制御装置。
【請求項２】
前記イネーブラの登録時に同一ジャンルの各ＡＰＩで共通している機能のメソッドを変換対象ＡＰＩとして設定し、前記他のイネーブラにリクエストを転送する際にメソッドの変換を行う変換部を備えることを特徴とする請求項１に記載の転送制御装置。
【請求項３】
前記イネーブラの登録時に同一ジャンルの各ＡＰＩで共通している機能のメソッドをジャンル呼び出し用ＡＰＩとして設定し、呼び出しの度にメソッドを変換するラッパーを備えることを特徴とする請求項１または２に記載の転送制御装置。
【請求項４】
負荷分散装置と、請求項１乃至３いずれか１項に記載の転送制御装置を複数備えるサービス提供システムであって、
前記負荷分散装置は、
前記リクエストに含まれるユーザＩＤのハッシュ値を算出する算出部と、
前記ハッシュ値を用いて前記リクエストの振り分け先を決定する負荷分散部と、を備え、
前記転送制御装置は、
ユーザＩＤ毎に、前記リクエストを転送した転送先イネーブラを記憶する記憶部を備え、
前記転送制御部は、前記リクエストに含まれるユーザＩＤに対応する転送先イネーブラを前記記憶部から読み出し、当該転送先イネーブラに基づいて前記リクエストを転送するイネーブラを決定すること
を特徴とするサービス提供システム。
【請求項５】
請求項４記載のサービス提供システムであって、
前記負荷分散部は、新たな転送制御装置を増設する際に、コンシステントハッシュ法を用いてハッシュテーブルを再割当てし、
前記転送制御装置は、前記再割当てされたハッシュテーブルに従って、自身のユーザ情報の一部を、前記新たな転送制御装置に配布すること
を特徴とするサービス提供システム。
【請求項６】
請求項４または５記載のサービス提供システムであって、
前記負荷分散部は、前記転送制御装置を減設する際に、コンシステントハッシュ法を用いてハッシュテーブルを再割当てし、
前記転送制御装置は、前記再割当てされたハッシュテーブルに従って、減設される転送制御装置１のユーザ情報の少なくとも一部を、自身のユーザ情報として前記記憶部に記憶すること
を特徴とするサービス提供システム。
【請求項７】
イネーブラの切り替えを動的に実施する転送制御方法であって、
コンピュータが、
類似した機能を持つ複数のイネーブラを同一ジャンルとして登録する登録ステップと、
前記イネーブラの状態を監視する監視ステップと、
前記イネーブラを呼び出す際、前記イネーブラが所定のｂｕｓｙ状態であるときは、前記イネーブラと同一ジャンルとして登録されている他のイネーブラにリクエストを転送し、リクエスト先を切り替える転送制御ステップと
を実行することを特徴とする転送制御方法。
【請求項８】
請求項１乃至３いずれか１項に記載した転送制御装置としてコンピュータを機能させることを特徴とする転送制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、転送制御装置、転送制御方法、サービス提供システムおよび転送制御プログラムに関する。
【背景技術】
【０００２】
近年のＢ２Ｂ２Ｘのビジネスモデルにおいては、左側のＢのサービス提供システムが、中央のＢのアプリケーション提供サーバに対して、アプリケーションで用いられる部品を提供する。サービス提供サーバは、ＡＰＩ−ＧＷ機能や、ロードバランサ機能を提供する（非特許文献１および非特許文献２参照）。【０００３】
ＡＰＩ−ＧＷ（Application Programming Interface - Gateway）機能では、ＡＰＩを通じて、複数のイネーブラ（部品提供サーバ）に接続して、複数のイネーブラからのレスポンスをまとめて、アプリケーション提供サーバに返信することが可能である。ロードバランサ機能では、複数のサーバの負荷状況、リクエスト数、レスポンスタイムなどを監視して、サーバの負荷分散を実現する。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】高橋  真由美、Ｂ２Ｂ２Ｘビジネスモデル活性化を目指したＡＰＩ活用の取り組み、ＮＴＴ技術ジャーナル、２０１５年１０月、５６−５８ページ
【非特許文献２】富士通、"負荷分散入門  第2回 負荷分散装置の基本機能"、［online］、２００４年８月３日、［平成２９年２月１３日検索］、インターネット〈URL：http://www.fujitsu.com/jp/products/network/security-bandwidth-control-load-balancer/ipcom/material/data/1/2.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、複数の外部サービスを連携したアプリケーションにおいては、イネーブラ毎に可用性（負荷やレスポンス等）が異なるため、負荷のかかっているイネーブラを含むアプリケーションはレスポンスが悪くなり、全体としての可用性が低くなってしまう。また、イネーブラのサービス停止や仕様変更があった際に、アプリケーション側が修正対応するまで正常に利用できない。【０００６】
本発明は、アプリケーション側に手を加えることなく可用性を向上させることが可能な転送制御装置、転送制御方法、サービス提供システムおよび転送制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、第１の態様に係る発明は、イネーブラの切り替えを動的に実施する転送制御装置であって、類似した機能を持つイネーブラを同一ジャンルとして登録する登録部と、前記イネーブラの状態を監視する監視部と、前記イネーブラを呼び出す際、前記イネーブラが所定のｂｕｓｙ状態であるときは、前記イネーブラと同一ジャンルとして登録されている他のイネーブラにリクエストを転送し、自動的にリクエスト先を切り替える転送制御部とを備えることを要旨とする。【０００８】
第２の態様に係る発明は、第１の態様に係る発明において、前記イネーブラの登録時に同一ジャンルの各ＡＰＩで共通しているメソッドを変換対象ＡＰＩとして設定し、前記他のイネーブラにリクエストを転送する際にメソッドの変換を行うことを要旨とする。【０００９】
第３の態様に係る発明は、第２の態様に係る発明において、前記イネーブラの登録時に同一ジャンルの各ＡＰＩで共通しているメソッドをジャンル呼び出し用ＡＰＩとして設定し、呼び出しの度にメソッドの変換をラッパーによって行うことを要旨とする。【００１０】
第４の態様に係る発明は、イネーブラの切り替えを動的に実施する転送制御方法であって、コンピュータが、類似した機能を持つイネーブラを同一ジャンルとして登録する登録ステップと、前記イネーブラの状態を監視する監視ステップと、前記イネーブラを呼び出す際、前記イネーブラが所定のｂｕｓｙ状態であるときは、前記イネーブラと同一ジャンルとして登録されている他のイネーブラにリクエストを転送し、自動的にリクエスト先を切り替える転送制御ステップとを実行することを要旨とする。【００１１】
第５の態様に係る発明は、転送制御プログラムであって、第１から第３のいずれか１つの態様に係る各機能部としてコンピュータを機能させることを要旨とする。
【発明の効果】
【００１２】
本発明によれば、アプリケーション側に手を加えることなく可用性を向上させることが可能な転送制御装置、転送制御方法、サービス提供システムおよび転送制御プログラムを提供することが可能である。
【図面の簡単な説明】
【００１３】
【図１】ＡＰＩマーケットを説明するための図である。
【図２】イネーブラにトラブルが発生した場合を説明するための図である。
【図３】イネーブラに仕様変更等が発生した場合を説明するための図である。
【図４】本発明の実施の形態に係る転送制御装置の適用例を示す構成図である。
【図５】本発明の実施の形態に係る転送制御装置の構成を示す機能ブロック図である。
【図６】本発明の実施の形態に係る転送制御装置の動作を示すフローチャートである。
【図７】本発明の実施の形態で想定する構成図である。
【図８】本発明の実施の形態で想定する構成図である。
【図９】同一ジャンルにおけるＡＰＩの比較を示す図である。
【図１０】実施例１に係る転送制御装置とイネーブラの構成を示す構成図である。
【図１１】実施例１に係る転送制御装置とイネーブラの構成を示す構成図である。
【図１２】実施例２に係る転送制御装置とイネーブラの構成を示す構成図である。
【図１３】実施例２に係る転送制御装置とイネーブラの構成を示す構成図である。
【図１４】複数の転送制御装置を用いた実施の形態のサービス提供システムの構成を示す図である。
【図１５】複数の転送制御装置を用いた実施の形態のフローチャートである。
【図１６】コンシステントハッシュ法の概要を示す図である。
【図１７】比較例の処理を示す図である。
【発明を実施するための形態】
【００１４】
以下、図面を用いて本発明の実施の形態を説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。
【００１５】
図１は、ＡＰＩマーケットを説明するための図である。ここでは、ＮＴＴグループ全体の公開ＡＰＩや、他社の人気ＡＰＩを用意するＡＰＩマーケット（ＡＰＩプラットフォーム）等を提供する場合を想定している。このような場合、「Ａ社翻訳」「Ｂ社翻訳」など、他社サービスのイネーブラ２を利用しているため、他社サービスが停止してしまったり、サービス終了してしまう点がリスクである。そのため、一つのイネーブラ２に依存せず、同一プラットフォーム上に同様の機能を持つ複数のイネーブラ２を登録することが想定される。
【００１６】
しかしながら、イネーブラ２毎に可用性（負荷やレスポンス等）が異なる。このため、負荷のかかっているイネーブラ２を含むアプリケーション５（イネーブラ連携アプリケーション）はレスポンスが悪くなり、全体としての可用性が低くなってしまう。また、他社サービスのイネーブラ２を利用してアプリケーション５を作成している場合、他社サービスが停止してしまったり、サービス終了してしまう点がリスクである。さらに、イネーブラ２のサービス停止や仕様変更があった際に、アプリケーション５側が修正対応するまで正常に利用できない。
【００１７】
図２は、イネーブラ２Ａがトラブル（負荷等）の影響でレスポンスが遅い場合を示している。イネーブラ２Ｂは正常に応答しているものとする。このような場合、イネ―ブラ２Ａの処理が終わらないため、アプリケーション５としての結果が返ってこない。
【００１８】
図３は、イネーブラ２Ａの仕様変更や、サービス終了・停止があった場合を想定している。イネーブラ２Ｂは正常に応答しているものとする。このような場合、アプリケーション５の変更をせずにイネーブラ２Ａへリクエストを実施すると、イネーブラ２Ａの仕様変更や、サービス終了・停止のため、エラーが発生する。
【００１９】
＜本発明の実施の形態の概要＞
そこで、本発明の実施の形態では、転送制御装置１が各イネーブラ２の状況を把握し、通常時よりもレスポンスが遅れていたり、エラーを頻出しているような場合、同一ジャンルの他のイネーブラ２へリクエストを転送し、代理でレスポンスを返答する。また、転送制御装置１は、イネーブラ２の登録時にイネーブラ２のジャンル登録を実施し、他のイネーブラ２へリクエストを転送する際に、同一ジャンルのイネーブラ２間でメソッドを変換する。
【００２０】
これにより、複数のイネーブラ２を連携したアプリケーション５の可用性を高めることが可能となる。また、複数のイネーブラ２を連携したアプリケーション５側では、イネーブラ２の負荷状況を考慮した処理を具備する必要がなく、イネーブラ２の停止や仕様変更に合わせたアプリケーション５の修正対応も不要である。このため、アプリケーション５の作成者は工数の削減や実装時間の短縮が見込める。
【００２１】
＜アプリケーション提供システム＞
図４は、本発明の実施の形態に係る転送制御装置１の適用例を示す構成図である。この図に示すように、アプリケーション提供システム８は、転送制御装置（サービス提供サーバ）１を備えるサービス提供システム９と、アプリケーション提供サーバ３ａ、３ｂ、３ｃと、エンドユーザ端末４ａ、４ｂ、４ｃを備える。アプリケーション提供サーバ３ａ、３ｂ、３ｃを区別しない場合、単にアプリケーション提供サーバ３と記載する場合がある。エンドユーザ端末４ａ、４ｂ、４ｃを区別しない場合、単にエンドユーザ端末４と記載する場合がある。
【００２２】
エンドユーザ端末４とアプリケーション提供サーバ３は、第１の通信ネットワークＮ１を介して相互に通信可能に接続される。アプリケーション提供サーバ３と転送制御装置１は、第２の通信ネットワークＮ２を介して相互に通信可能に接続される。第１の通信ネットワークＮ１と第２の通信ネットワークＮ２は、図４においては異なる通信ネットワークとして記載しているが、インターネット等の同じ通信ネットワークで合っても良い。
【００２３】
アプリケーション提供システム８は、Ｂ２Ｂ２Ｘのビジネスモデルを実現するシステムである。サービス提供システム９は、Ｂ２Ｂ２Ｘの左側のＢに対応し、アプリケーション提供サーバ３は、中央のＢに対応する。図４に示す例では、Ｂ２Ｂ２Ｘの右側のＸがエンドユーザ端末４で、Ｃ（Consumer）である場合を説明するが、企業等のシステムであっても良い。
【００２４】
アプリケーション提供サーバ３は、サービス提供システム９から提供されたデータに基づいて、エンドユーザ端末４に機能を提供する。
【００２５】
サービス提供システム９は、転送制御装置１と、アプリケーション提供サーバ３が備えるアプリケーション５で用いられる部品を提供するイネーブラ（部品提供サーバ）２Ａ、２Ｂ、２Ｃを備える。転送制御装置１と、イネーブラ２Ａ、２Ｂ、２Ｃは、第３の通信ネットワークＮ３を介して、相互に通信可能に接続される。第３の通信ネットワークＮ３は、典型的にはＬＡＮ（Local Area Network）である。イネーブラ２Ａ、２Ｂ、２Ｃを区別しない場合、単にイネーブラ２と記載する場合がある。
【００２６】
転送制御装置１は、アプリケーション提供サーバ３からＡＰＩを介してリクエストを受信すると、イネーブラ２にＡＰＩを介してリクエストを送信する。これにより、転送制御装置１は、イネーブラ２からレスポンスを受信すると、そのレスポンスに基づいて、アプリケーション提供サーバ３へのレスポンスを生成して、アプリケーション提供サーバ３に返信する。
【００２７】
＜転送制御装置＞
図５は、本発明の実施の形態に係る転送制御装置１の構成を示す機能ブロック図である。この転送制御装置１は、イネーブラ２の負荷状況や動作状況等を監視し、高負荷時やサービス停止時の可用性を高めるために、リクエスト先の切替機能を持つコンピュータである。転送制御装置１は、処理装置１０、記憶装置２０、通信制御装置３０を備える。もちろん、一般的な転送制御装置（サービス提供サーバ）１が備える各種の機能も備えるが、ここでは図示を省略している。
【００２８】
処理装置１０は、イネーブラ２を登録する登録部１１と、イネーブラ２の負荷状況や動作状況等を監視する監視部１２と、リクエストの転送を制御する転送制御部１３とを備える。記憶装置２０は、各種の情報を記憶する装置である。通信制御装置３０は、第２の通信ネットワークＮ２や第３の通信ネットワークＮ３等を介して他の装置と通信を行うための装置である。
【００２９】
このような転送制御装置１によれば、イネーブラ２の負荷状況や動作状況等に応じて元々のイネーブラ２から同一ジャンルの他のイネーブラ２に切り替えることができるため、アプリケーション５としてのサービスを停止させることなく運用が可能である。これにより、本実施形態では、各イネーブラ２やアプリケーション５に手を加えることなく、イネーブラ連携アプリケーション５における一部のイネーブラ２の高負荷、サービス停止時の可用性を高めることが可能となる。
【００３０】
＜転送制御方法＞
図６は、本発明の実施の形態に係る転送制御装置１の動作を示すフローチャートである。以下、図６を用いて、本発明の実施の形態に係る転送制御方法について説明する。
【００３１】
転送制御装置１は、まず、類似した機能を持つイネーブラ２を同一ジャンルとして登録し（ステップＳ１）、特定のイネーブラ２を呼び出す際、特定のイネーブラ２が所定のｂｕｓｙ状態であるかどうかを判定する（ステップＳ２→Ｓ３）。所定のｂｕｓｙ状態とは、高負荷であったり、エラーが頻繁に返ってきている場合をいう。エラーが頻繁に返ってきている場合としては、イネーブラ２の仕様変更があった場合や、サービスが終了または停止した場合が該当する。ここで、特定のイネーブラ２が所定のｂｕｓｙ状態でないときは、特定のイネーブラ２にリクエストを送信する（ステップＳ３→Ｓ４）。一方、特定のイネーブラ２が所定のｂｕｓｙ状態であるときは、特定のイネーブラ２と同一ジャンルとして登録されている他のイネーブラ２にリクエストを転送し、自動的にリクエスト先を切り替える（ステップＳ３→Ｓ５）。
【００３２】
＜ＡＰＩ−ＧＷとイネーブラの構成＞
図７および図８は、本発明の実施の形態で想定する構成図である。具体的には、図７は、ＡＰＩ−ＧＷとイネーブラ２Ａ，２Ｂ，２Ｃ，…の構成を示し、図８は、複数のイネーブラ２Ａ，２Ｂ，２Ｃ，…を連携したアプリケーション５の動作を示している。
【００３３】
既に説明したように、多数のイネーブラ２Ａ，２Ｂ，２Ｃ，…をＡＰＩ−ＧＷに接続し、アプリケーション５が多数のイネーブラ２Ａ，２Ｂ，２Ｃ，…を連携して利用することが想定される。ＮＴＴグループ全体の公開ＡＰＩや、他社の人気ＡＰＩを用意するＡＰＩマーケット、ＡＰＩプラットフォーム等が将来出てきた際、同一プラットフォーム上に複数の会社で同様の機能を持つＡＰＩが、複数登録されるということが想定される。本発明の実施の形態に係る転送制御装置１は、このようなＡＰＩ−ＧＷに機能追加をしたものである。
【００３４】
＜同一ジャンルにおけるＡＰＩの比較＞
図９は、同一ジャンルにおけるＡＰＩの比較を示す図である。ここでは、“GoogleTranslate”と、“YandexTranslate API”と、“IBMWatsonLanguageTranslator”の３つのＡＰＩを比較している。この図に示すように、翻訳の場合、“翻訳機能”、“言語検知機能”については多くのＡＰＩで共通している。例えば、「翻訳」メソッドの場合、入力がテキストで、出力が翻訳結果である。「言語検知」メソッドの場合、入力がテキストで、出力が検知した言語である。もちろん、図９は単なる例示であり、本発明の実施の形態を限定するものであると理解すべきではない。
【００３５】
＜実施例１＞
図１０および図１１は、実施例１に係る転送制御装置１とイネーブラ２の構成を示す構成図である。以下、図１０および図１１を用いて転送制御装置１を更に具体的に説明する。
【００３６】
実施例１では、各イネーブラ２がジャンルごとにまとめられて転送制御装置１の配下に登録されている。例えば、翻訳というジャンルＡには、類似の翻訳サービスを提供しているＡ社の翻訳イネーブラ２Ａ、Ｂ社の翻訳イネーブラ２Ｂ、…が登録されている。
【００３７】
アプリケーション５の例としては、イネーブラ２Ａ，２Ｄ，２Ｇが連携するアプリケーション５を想定している。このようなアプリケーション５を実行した場合、イネーブラ２Ａ，２Ｄ，２Ｇがそれぞれ転送制御装置１を経由して呼び出される。
【００３８】
転送制御装置１は、各ジャンルＡ，Ｂ，…の中でイネーブラ２の実行優先度を決めておく。ここでは、ジャンルＡについては、イネーブラ２Ａ，２Ｂ，２Ｃの順に実行優先度が高いものとする。そのため、転送制御装置１は、イネーブラ２Ａがｂｕｓｙ状態の時は、次に実行優先度の高いイネーブラ２Ｂを利用し、イネーブラ２Ｂもｂｕｓｙ状態の時は、次に実行優先度の高いイネーブラ２Ｃを利用する。転送制御装置１は、アプリケーション５がｂｕｓｙ状態でないイネーブラ２Ｂか２Ｃを利用（指定）する場合は、自動的にイネーブラ２Ｂか２Ｃへリクエストを転送する。変換機能部１０Ａは、他のイネーブラにリクエストを転送する際に、メソッドの変換を実施する。このように優先イネーブラ２の状態に問題がなければ当該イネーブラ２を呼び出し、続いて他のイネーブラ２を呼び出すようになっている。
【００３９】
以下、図１１を用いて変換機能部１０Ａについて更に詳しく説明する。既に説明したように、イネーブラ２を転送制御装置１に登録する際に、同一ジャンルの各ＡＰＩで共通している機能のメソッドを変換対象ＡＰＩとして設定し、転送制御装置１で他のイネーブラ２へ転送する際に、メソッドの変換を行う。図１１では、ジャンル「翻訳」の場合を例示している。変換機能部１０Ａは、転送制御装置１におけるイネーブラ２のジャンル「翻訳」の変換対象メソッドを図１１のように定義し、アプリケーション５からのリクエスト時にイネーブラ２Ａ，２Ｂ，２Ｃのメソッドに相互変換して転送する。共通していない機能のメソッドに対するリクエストに対しては、そのままイネーブラ２に対して転送する（スルーさせる）。
【００４０】
以上のように、実施例１に係る転送制御装置１によれば、アプリケーション５の変更を伴うことなく他のイネーブラ２への振り分けを実施できるため、可用性が高まる。なお、実施例１に係る転送制御装置１は、以下の機能を備えてもよい。
・ジャンルが設定されているイネーブラ２について、負荷状況やレスポンスタイム（ターンアラウンドタイム）、エラー発生等の状態監視をする。
・同一ジャンル内で空いているイネーブラ２があった場合、当該イネーブラ２へ処理の振り分けを実施する（アプリケーション５のプログラム上で指定可能とする）。
・他のイネーブラ２へ振り分けを実施したくない場合は、アプリケーション５上で指定すれば振り分け実施しないこともできる。・アプリケーション５に対して、他のイネーブラ２への振り分けを推薦し、その後振り分けを実行する。
【００４１】
＜実施例２＞
図１２および図１３は、実施例２に係る転送制御装置１とイネーブラ２の構成を示す構成図である。実施例２では、転送制御装置１が共通インタフェースを持つ。以下、実施例２に係る転送制御装置１を実施例１と異なる点を中心に説明する。
【００４２】
転送制御装置１が、ジャンルごとの共通インタフェースを持つようにしても振り分けを実施できる。具体的には、転送制御装置１は、イネーブラ２の登録時に同一ジャンルの各ＡＰＩとして共通している機能のメソッドをジャンル呼び出し用ＡＰＩとして設定する。転送制御装置１には、呼び出しの度にメソッドの変換を行うラッパー１０Ｂを作成して配置する。アプリケーション５は、ジャンル呼び出しをする際は、転送制御装置１が用意した共通インタフェースのメソッドを利用してリクエストを行う。
【００４３】
実施例２でも、ジャンル「翻訳」の場合を例示している。転送制御装置１は、イネーブラ２のジャンル「翻訳」のメソッドを図１３のように定義する。ラッパー１０Ｂは、アプリケーション５から共通インタフェースを用いたリクエストを受け付けると、当該リクエストを図１３に示すイネーブラ２Ａ，２Ｂ，２Ｃの各メソッドに変換して転送する。
【００４４】
API-GW_Translate.translate              翻訳機能
API-GW_Translate.detectLanguages        言語検知機能
アプリケーション５の例としては、イネーブラ２のジャンルＡ（イネーブラ２Ａを指定），イネーブラ２Ｄ，２Ｇが連携するアプリケーション５を想定している。このようなアプリケーション５を実行した場合、転送制御装置１は、ジャンルＡの中から選択するイネーブラ２に実行優先度を付けており、優先イネーブラ２（ここでは、イネーブラ２Ａ）の状態に問題がなければ当該イネーブラ２を呼び出し、続いて後続のイネーブラ２Ｄ、２Ｇを呼び出す。
【００４５】
図示する例では、ラッパー１０Ｂは、ジャンルＡの中でイネーブラ２Ａを優先的に利用する。イネーブラ２Ａがｂｕｓｙ状態の時は他のイネーブラ２Ｂ，２Ｃを利用する。ラッパー１０Ｂは、アプリケーション５から送信された共通インタフェースのリクエストを、利用するイネーブラ２の個別のメソッドに変換する。イネーブラ２Ａを優先イネーブラ２としているが、アプリケーション５側で個別にイネーブラ２を指定しても良い。個別にイネーブラ２が指定された場合は、転送制御装置１は、ラッパー１０Ｂを使用しない。
【００４６】
以上のように、実施例２に係る転送制御装置１によれば、アプリケーション５からイネーブラ２の個別呼び出しだけでなくジャンルでの呼び出しもできるようになる。また、実施例１と比較してメソッドの変換の組み合わせが減るため、転送制御装置１の提供元にとってはオペレーションコストが下がる効果もある。
【００４７】
＜まとめ＞
以上説明したように、本発明の実施の形態に係る転送制御装置１は、イネーブラ２の切り替えを動的に実施する装置であって、類似した機能を持つ複数のイネーブラ２を同一ジャンルとして登録する登録部１１と、イネーブラ２の状態を監視する監視部１２と、イネーブラ２を呼び出す際、イネーブラ２が所定のｂｕｓｙ状態であるときは、イネーブラ２と同一ジャンルとして登録されている他のイネーブラ２にリクエストを転送し、リクエスト先を切り替える転送制御部１３とを備える。これにより、イネーブラ２が正常に動作していない場合や、急なサービス停止、仕様変更があった場合でも、アプリケーション５の更新をすることなく動作可能となり、可用性を高めることが可能となる。
【００４８】
また、転送制御装置１は、イネーブラ２の登録時に同一ジャンルの各ＡＰＩで共通している機能のメソッドを変換対象ＡＰＩとして設定し、他のイネーブラ２にリクエストを転送する際にメソッドの変換を行ってもよい。すなわち、同一ジャンルの各イネーブラ２で共通している機能のパラメータ情報の変換処理を転送制御装置１側で行うため、イネーブラ２の仕様変更があってもアプリケーション５側の変更が不要である。
【００４９】
また、イネーブラ２の登録時に同一ジャンルの各ＡＰＩで共通している機能のメソッドをジャンル呼び出し用ＡＰＩとして設定し、呼び出しの度にメソッドの変換をラッパー１０Ｂによって行ってもよい。これにより、アプリケーション５からイネーブラ２の個別呼び出しだけでなくジャンルでの呼び出しもできるようになる。
【００５０】
なお、本発明は、このような転送制御装置１として実現することができるだけでなく、このような転送制御装置１が備える特徴的な機能部をステップとする転送制御方法として実現したり、それらのステップをコンピュータに実行させる転送制御プログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
【００５１】
＜その他の実施の形態＞
上記のように、本発明の実施の形態によって記載したが、この開示の一部をなす論述および図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例および運用技術が明らかとなる。
【００５２】
例えば、本発明の実施の形態に記載した転送制御装置１は、図５に示すように、一つのハードウエア上に構成されても良いし、その機能や処理数に応じて複数のハードウエア上に構成されても良い。また、既存のサービス提供システム９上に実現されても良い。
【００５３】
＜複数の転送制御装置を用いた実施の形態＞
以下に、複数の転送制御装置を用いた実施の形態について説明する。上述した実施例１では、転送制御装置１が、あるイネーブラ２がｂｕｓｙ状態の場合、当該イネーブラ２と類似する機能を持つ同じジャンルのイネーブラ２へ転送する。この場合、転送制御装置１は、アプリケーション５から送信された全てのリクエストについて、当該リクエストが呼び出すイネーブラ２を監視する。そのため、転送制御装置１は、リクエストが多いとスケールしない場合がある。すなわち、転送制御装置１は、リクエストの増加に伴い、所定の性能を満たすことができない場合がある。
【００５４】
転送制御装置１を複数用意して、負荷分散装置がアプリケーション５からのリクエストを複数の転送制御装置１に均等に振り分ける場合、負荷分散装置は、同一ユーザからのリクエストであっても、リクエストの度に異なる転送制御装置１に振り分けてしまう。この場合、転送制御装置１は、前回のリクエストの際にどのイネーブラ２へ転送していたかという情報を引き継げないため、ユーザの利便性が低下する。
【００５５】
本実施形態では、ユーザ利便性の低下を回避するために、複数の転送制御装置１で負荷分散を行う際に、各ユーザの振り分け先を一意に特定する。具体的には、ユーザＩＤのハッシュ値を用いて振り分け先の転送制御装置を一意に特定することで、同じユーザＩＤからのリクエストは毎回、同じ転送制御装置１に振り分ける。これにより、本実施形態では、転送制御装置１がイネーブラ２の転送状況（転送履歴）を引き継ぐことができ、複数の転送制御装置１で負荷分散を行う際のユーザ利便性の低下を回避することができる。
また、本実施形態では、複数の転送制御装置１に対して均等な負荷分散を実現するために、コンシステントハッシュ法を用いて負荷分散する。
【００５６】
図１４は、本実施形態のサービス提供システムの一例を示す図である。図示するサービス提供システムは、負荷分散装置６と、複数の転送制御装置１Ａ、１Ｂ、１Ｃと、アプリケーション５で用いられる部品を提供するイネーブラ２Ａ、２Ｂ、２Ｃとを備える。イネーブラ２Ａ、２Ｂ、２Ｃは、各転送制御装置１Ａ、１Ｂ、１Ｃに接続される。転送制御装置１Ａ、１Ｂ、１Ｃを区別しない場合、単に転送制御装置１と記載する場合がある。イネーブラ２Ａ、２Ｂ、２Ｃを区別しない場合、単にイネーブラ２と記載する場合がある。なお、本実施形態のイネーブラ２およびアプリケーション５は、上述の実施形態と同様である。
【００５７】
負荷分散装置６は、アプリケーション５から送信されるリクエストを、複数の転送制御装置１に振り分け、負荷分散する。図示する負荷分散装置６は、ハッシュ値算出部６１と、負荷分散部６２とを備える。ハッシュ値算出部６１は、アプリケーション５から送信されるリクエストに含まれるユーザＩＤのハッシュ値を算出する。負荷分散部６２は、  ハッシュ値を用いてリクエストの振り分け先の転送制御装置１を決定する。また、負荷分散部６２は、新たな転送制御装置１を増設する際、または、転送制御装置１を減設する際に、コンシステントハッシュ法を用いてハッシュテーブルの再割当てを行う。
【００５８】
本実施形態の転送制御装置１は、変換機能部１０Ａと、転送制御部１３と、管理部１４と、ユーザ情報記憶部２１とを備える。なお、転送制御装置１は、図示しないが、図５に示す登録部１１、監視部１２、記憶装置２０および通信制御装置３０も備える。変換機能部１０Ａは、上述の実施例１と同様である。なお、転送制御装置１は、実施例２のラッパー１０Ｂをさらに備えてもよく、あるいは、変換機能部１０Ａの代わりにラッパー１０Ｂを備えてもよい。
【００５９】
転送制御部１３は、イネーブラ２を呼び出す際、当該イネーブラ２が所定のｂｕｓｙ状態であるときは、当該イネーブラ２と同一ジャンルとして登録されている他のイネーブラにリクエストを転送し、リクエスト先を切り替える。また、転送制御部１３は、リクエストに含まれるユーザＩＤに対応する転送先イネーブラをユーザ情報記憶部２１から読み出し、当該転送先イネーブラに基づいてリクエストを転送するイネーブラを決定する。
【００６０】
管理部１４は、転送制御装置１の増設によりハッシュテーブルの再割当てが行われた場合、再割当てされたハッシュテーブルに従って、自身のユーザ情報の一部を増設された新たな転送制御装置１に配布する。管理部１４は、転送制御装置１の減設によりハッシュテーブルの再割当てが行われた場合、再割当てされたハッシュテーブルに従って、減設される転送制御装置１のユーザ情報の少なくとも一部を、自身のユーザ情報としてユーザ情報記憶部２１に記憶する。
【００６１】
ユーザ情報記憶部２１は、ユーザＩＤ毎に、リクエストを転送した転送先イネーブラ（転送先イネーブラの情報）を記憶する。具体的には、ユーザ情報記憶部２１には、ユーザＩＤ毎に、リクエストで指定されたイネーブラ２をどのイネーブラ２へ実際に転送したかの履歴情報が、ユーザ情報として記憶される。ユーザ情報には、例えば、ユーザＩＤ、リクエストで指定されたイネーブラ、転送先イネーブラなどが含まれる。ユーザ情報記憶部２１は、記憶装置２０に設けられる。
【００６２】
図１５は、負荷分散装置６および転送制御装置１が行う負荷分散処理を示すフローチャートである。負荷分散装置６のハッシュ値算出部６１は、アプリケーション５から送信されたリクエストを受信し（Ｓ２１）、当該リクエストに含まれるユーザＩＤのハッシュ値を算出する（Ｓ２２）。
【００６３】
負荷分散部６２は、ハッシュ値を用いて、リクエストの振り分け先の転送制御装置１を決定し（Ｓ２３）、決定した転送制御装置１にリクエストを送信する（Ｓ２４）。本実施形態では、負荷分散部６２は、コンシステントハッシュ（Consistent Hash）法を用いて、振り分け先の転送制御装置１を決定する。
【００６４】
図１６は、コンシステントハッシュ法の概要を簡単に示す図である。本実施形態のコンシステントハッシュ法では、負荷分散部６２は、ユーザＩＤのハッシュ値を、ハッシュ関数を用いてあらかじめ計算しておき、当該ハッシュ値を仮想的な円（リング状）のハッシュテーブル（ハッシュ空間）に配置する。そして、負荷分散部６２は、あるユーザＩＤのリクエストを受信して当該ユーザＩＤの転送制御装置１を選択する際に、当該ユーザＩＤのハッシュ値を前記ハッシュ関数を用いて同様に算出し、そのハッシュ値に対応するハッシュテーブルの位置に割り当てられた転送制御装置１を選択する。
【００６５】
図１６（ａ）は、負荷分散装置６に２つの転送制御装置１Ａ、１Ｂが接続されている場合のハッシュテーブルを示す。円（ハッシュテーブル）の実線部分１６Ａは、転送制御装置１Ａの割当範囲である。すなわち、負荷分散部６２は、実線部分１６Ａのハッシュ値に対応するユーザＩＤからのリクエストは、転送制御装置１Ａに振り分ける。また、円の点線部分１６Ｂは、転送制御装置１Ｂの割当範囲である。すなわち、負荷分散部６２は、点線部分１６Ａのハッシュ値に対応するユーザＩＤからのリクエストは、転送制御装置１Ｂに振り分ける。なお、転送制御装置１Ａのユーザ情報記憶部２１には、自身の割当範囲１６ＡのユーザＩＤのユーザ情報が記憶されている。転送制御装置１Ｂのユーザ情報記憶部２１には、自身の割当範囲１６ＢのユーザＩＤのユーザ情報が記憶されている。
【００６６】
転送制御装置１の転送制御部１３は、負荷分散装置６からリクエストを受信すると、前記リクエストに含まれるユーザＩＤに対応する転送先イネーブラをユーザ情報記憶部２１から読み出し、当該転送先イネーブラに基づいてリクエストを転送するイネーブラ２を決定する（Ｓ２５）。そして、転送制御部１３は、決定したイネーブラ２にリクエストを送信する（Ｓ２６）。例えば、転送制御部１３は、リクエストで指定されたイネーブラ２が過去（前回など）にどのイネーブラ２に転送されたかを示すユーザ情報を用いて、過去のリクエストで転送したイネーブラ２と同じになるように、Ｓ２５で転送するイネーブラ２を決定する。このとき、転送制御部１３は、リクエストで指定されたイネーブラと、実際に転送した転送先イネーブラとを、当該ユーザＩＤに対応付けてユーザ情報記憶部２１に記憶する。なお、転送制御装置１は、リクエストを転送する際に、必要に応じて実施例１、２で説明したメソッドの変換を行う。
【００６７】
次に、図１６を参照して、転送制御装置１を増設する場合について説明する。ここでは、図１６（ａ）に示すように２つの転送制御装置１Ａ、１Ｂから、図１６（ｂ）に示すように転送制御装置１Ｃを増設した場合を例に説明する。図１６（ｂ）は、負荷分散装置６に３つの転送制御装置１Ａ、１Ｂ、１Ｃが接続されている場合の円のハッシュテーブルを示す。円の実線部分１６Ａは、増設前の転送制御装置１Ａの割当範囲である。円の点線部分１６Ｂは、増設前の転送制御装置１Ｂの割当範囲である。
【００６８】
負荷分散装置６の負荷分散部６２は、新たな転送制御装置１Ｃを増設する際、コンシステントハッシュ法を用いてハッシュテーブルの再割当てを行う。これにより、円の一点鎖線部分１６Ｃが増設された転送制御装置１Ｃの割当範囲となる。すなわち、転送制御装置１Ａの割当範囲（実線部分１６Ａ）の一部１６Ａ’と、転送制御装置１Ｂの割当範囲（点線部分１６Ｂ）の一部１６Ｂ’とが、転送制御装置１Ｃの割当範囲となる。
【００６９】
このように転送制御装置１Ｃの増設によりハッシュテーブルの再割当てが行われた場合、転送制御装置１Ａ、１Ｂの管理部１４は、再割当てされたハッシュテーブルに従って、自身のユーザ情報の一部を増設された転送制御装置１Ｃに配布する。ここでは、転送制御装置１Ａは、１６Ａ’の部分のハッシュ値に対応するユーザＩＤのユーザ情報２１Ａを転送制御装置１Ｃに送信する。転送制御装置１Ｂは、１６Ｂ’の部分のハッシュ値に対応するユーザＩＤのユーザ情報２１Ｂを転送制御装置１Ｃに送信する。
【００７０】
なお、ユーザ情報の配布は、オペレータの指示により行われるものであってよく、あるいは、転送制御装置１間でクラスタを構成し、全ての転送制御装置１がハッシュテーブルを保持し、新たな転送制御装置１が追加された際に当該転送制御装置１に割り当てされるユーザ情報を各転送制御装置１が自律的に配布してもよい。
【００７１】
また、転送制御装置１を減設する場合については、以上説明した説明した転送制御装置１の増設と同様である。すなわち、図１６（ｂ）に示すように３つの転送制御装置１Ａ、１Ｂ、１Ｃから、図１６（ａ）に示すように転送制御装置１Ｃを減設した場合、負荷分散装置６は、コンシステントハッシュ法を用いてハッシュテーブルの再割当てを行う。これにより、転送制御装置１Ｃの割当範囲が無くなり、図１６（ａ）に示す状態となる。この場合、転送制御装置１Ａ、Ｂの管理部１４は、再割当てされたハッシュテーブルに従って、減設される転送制御装置１Ｃの割当範囲１６Ｃのユーザ情報の少なくとも一部を、自身のユーザ情報としてユーザ情報記憶部２１に記憶する。
【００７２】
図１７は、本実施形態の比較例の負荷分散を説明する図である。比較例では、負荷分散装置は、アプリケーションからのリクエストを複数の転送制御装置に均等に振り分ける。負荷分散装置は、アプリケーションから送信されたユーザＡの最初のリクエストを、転送制御装置Ａに振り分ける（Ｓ２１）。転送制御装置Ａは、ユーザＡのユーザ情報を取得する（Ｓ２２）。ここでは、ユーザＡの最初のリクエストであるため、転送制御装置Ａは、ユーザＡのリクエストをどのイネーブラに転送したかのユーザ情報を保持していない。転送制御装置Ａは、リクエストで指定されたイネーブラＡがｂｕｓｙ状態であるため他のイネーブラ２Ｂにリクエストを転送する（Ｓ２３）。この場合、転送制御装置１Ａは、ユーザ情報に実際に転送したイネーブラＢを転送先イネーブラ２として設定する。
【００７３】
負荷分散装置は、ユーザＡの次のリクエストを転送制御装置Ｂに振り分ける（Ｓ２４）。転送制御装置Ｂは、ユーザＡのユーザ情報を取得する（Ｓ２５）。ユーザＡの最初のリクエストは転送制御装置Ａで処理されたため、転送制御装置Ｂは、ユーザＡの最初のリクエストがどのイネーブラに転送されたかのユーザ情報を保持していない。転送制御装置Ｂは、アプリケーションで指定されたイネーブラＡがｂｕｓｙ状態であるため、他のイネーブラＣにリクエストを転送する（Ｓ２６）。
【００７４】
この比較例では、ユーザＡは、最初はイネーブラＢを利用したが、次のリクエストでは、イネーブラＣを利用することになる。例えば、ジャンルＡのイネーブラが地図表示の場合、最初のリクエストではイネーブラＢ仕様の地図で表示されたのに、次のリクエストではイネーブラＣ仕様の地図で表示されてしまう。イネーブラ毎に、地図のデザイン、地図に表示される店名などが異なるため、リクエストの度に利用するイネーブラが変更されると、リクエストの度に異なるデザインの地図がユーザＡの端末に表示され、ユーザの利便性が低下する。
【００７５】
これに対し、本実施形態では、利用者やリクエストの増加により、複数の転送制御装置１を用いて負荷分散する場合であっても、ユーザＩＤのハッシュ値を用いてリクエストの振り分け先の転送制御装置を決定する。これにより本実施形態では、同じユーザＩＤからのリクエストを、同じ転送制御装置１に振り分けことができる。したがって、本実施形態では、転送制御装置１がイネーブラ２の転送状況（転送履歴）を引き継ぐことができ、複数の転送制御装置１で負荷分散を行う際のユーザ利便性の低下を回避することができる。
【００７６】
また、本実施形態では、コンシステントハッシュ法を用いて負荷分散する。これにより、本実施形態では、複数の転送制御装置１に対して均等な負荷分散を実現することができる。
【００７７】
本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【符号の説明】
【００７８】
１…転送制御装置（サービス提供サーバ）
２…イネーブラ（部品提供サーバ）
５…アプリケーション
１０…処理装置
１０Ａ…変換機能部
１０Ｂ…ラッパー
１１…登録部
１２…監視部
１３…転送制御部
１４…管理部
２０…記憶装置
２１…ユーザ情報記憶部
３０…通信制御装置
【図１】
2019230315.tif 000003
【図２】
2019230315.tif 000004
【図３】
2019230315.tif 000005
【図４】
2019230315.tif 000006
【図５】
2019230315.tif 000007
【図６】
2019230315.tif 000008
【図７】
2019230315.tif 000009
【図８】
2019230315.tif 000010
【図９】
2019230315.tif 000011
【図１０】
2019230315.tif 000012
【図１１】
2019230315.tif 000013
【図１２】
2019230315.tif 000014
【図１３】
2019230315.tif 000015
【図１４】
2019230315.tif 000016
【図１５】
2019230315.tif 000017
【図１６】
2019230315.tif 000018
【図１７】
2019230315.tif 000019
【国際調査報告】
2019230315.tif 000020
2019230315.tif 000021