(57)【要約】【課題】クライアントのユーザにサービスを提供する上で、人手による通信先の設定作業を削減しつつその時々で最適なサービスをユーザに提供できるようにする。【解決手段】ゲートウェイ装置は、環境パラメータ取得部、仕様情報記憶部、評価条件記憶部、ステージ判定部、サーバパラメータ取得部、通信先選定部、通信処理部を備える。環境パラメータ取得部はシステムの環境パラメータを取得する。評価条件記憶部にはステージ評価式とサーバ評価式が記憶されている。ステージ判定部は環境パラメータをステージ評価式に代入して現在のステージを判定する。通信先選定部はサーバパラメータをサーバ評価式に代入して通信先のサーバの候補を選定し通信処理部がサーバの候補へ通信を順次試みる。【選択図】図１
2019174969.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと複数のサーバにネットワークを介して接続され、前記クライアントからのリクエストを要求先のサーバへ中継するゲートウェイ装置において、
前記ゲートウェイ装置の側で検出可能なシステムの環境パラメータを取得する環境パラメータ取得部と、
各サーバと前記各サーバで動作するアプリケーションプログラムとで実現されるマイクロサービスの情報と、前記ネットワーク上における前記各サーバの所在情報とを含む仕様情報が記憶された仕様情報記憶部と、
各サーバでアプリケーションプログラムが動作しているステージを評価するための第１評価条件と、前記ステージ毎に前記サーバの機能が前記リクエストを処理可能か否かを評価するための第２評価条件とが記憶された評価条件記憶部と、
取得された前記システムの環境パラメータを基に前記第１評価条件を満たす現在のステージを判定するステージ判定部と、
各サーバに存在する機能を実数化したサーバパラメータを取得するサーバパラメータ取得部と、
取得された前記サーバパラメータと前記仕様情報を基に、前記ステージ判定部により判定されたステージに対応する前記第２評価条件を満たす通信先のサーバの候補を選定する通信先選定部と、
前記通信先選定部により選定されたサーバの候補へ通信を順次試みる通信処理部と
を具備するゲートウェイ装置。
【請求項２】
前記環境パラメータが、サービスの運用段階か本番段階か、時刻、時間帯、カレンダ、中継するデータ量、有料サーバの課金額のいずれかの値を含む請求項１記載のゲートウェイ装置。
【請求項３】
前記サーバパラメータが、サーバ毎に設定される課金額、性能のいずれかの値を含む請求項１記載のゲートウェイ装置。
【請求項４】
前記第１評価条件が、条件式または関数式に前記環境パラメータを代入して計算した結果として得られる値が予め設定された閾値を満たすか否かである請求項１記載のゲートウェイ装置。
【請求項５】
前記第２評価条件が、決定したステージに対応して設定されたサーバ評価用の計算式である請求項１記載のゲートウェイ装置。
【請求項６】
前記通信先選定部は、
前記第２評価条件を満たす通信先候補のサーバのリストを生成し、前記リストにおいて評価結果のよい通信先候補の順に前記サーバに優先度を付与して通信処理部に渡し、
前記通信処理部は、
渡されたサーバリストの優先度の高い候補の順に通信を試みる請求項１記載のゲートウェイ装置。
【請求項７】
前記ステージ判定部は、
前記環境パラメータを評価条件として設定されている複数のステージ評価式に代入し、ステージ毎に評価し、評価結果のよいステージを現在のステージとして特定する請求項１記載のゲートウェイ装置。
【請求項８】
クライアントと複数のサーバとネットワークを介して接続されたゲートウェイ装置とを有し、前記クライアントからのリクエストをゲートウェイ装置が要求先のサーバへ中継する通信システムにおいて、
前記ゲートウェイ装置が、
前記ゲートウェイ装置の側で検出可能なシステムの環境パラメータを取得する環境パラメータ取得部と、
各サーバと前記各サーバで動作するアプリケーションプログラムとで実現されるマイクロサービスの情報と、前記ネットワーク上における前記各サーバの所在情報とを含む仕様情報が記憶された仕様情報記憶部と、
各サーバでアプリケーションプログラムが動作しているステージを評価するための第１評価条件と、前記ステージ毎に前記サーバの機能が前記リクエストを処理可能か否かを評価するための第２評価条件とが記憶された評価条件記憶部と、
取得された前記システムの環境パラメータを基に前記第１評価条件を満たす現在のステージを判定するステージ判定部と、
各サーバに存在する機能を実数化したサーバパラメータを取得するサーバパラメータ取得部と、
取得された前記サーバパラメータと前記仕様情報を基に、前記ステージ判定部により判定されたステージに対応する前記第２評価条件を満たす通信先のサーバの候補を選定する通信先選定部と、
前記通信先選定部により選定されたサーバの候補へ通信を順次試みる通信処理部と
を具備する通信システム。
【請求項９】
クライアントと複数のサーバにネットワークを介して接続され、前記クライアントからのリクエストを要求先のサーバへ中継するゲートウェイ装置における通信方法であって、
前記ゲートウェイ装置が、
前記ゲートウェイ装置の側で検出可能なシステムの環境パラメータを取得し、
各サーバと前記各サーバで動作するアプリケーションプログラムとで実現されるマイクロサービスの情報と、前記ネットワーク上における前記各サーバの所在情報とを含む仕様情報を記憶し、
各サーバでアプリケーションプログラムが動作しているステージを評価するための第１評価条件と、前記ステージ毎に前記サーバの機能が前記リクエストを処理可能か否かを評価するための第２評価条件とを記憶し、
取得した前記システムの環境パラメータを基に前記第１評価条件を満たす現在のステージを判定し、
各サーバに存在する機能を実数化したサーバパラメータを取得し、
前記ゲートウェイ装置が、取得した前記サーバパラメータと前記仕様情報を基に、判定したステージに対応する前記第２評価条件を満たす通信先のサーバの候補を選定し、
選定したサーバの候補へ通信を順次試みる通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信システム、ゲートウェイ装置および通信方法に関する。
【背景技術】
【０００２】
近年のソフトウェア開発では、マイクロサービスと呼ばれる小規模のサービスを複数用意し、それらをＡＰＩゲートウェイで束ねる形でシステムを構築する手法が取り入れられている。
【０００３】
このような手法において、各サービスは、個別に開発されそれぞれ異なる環境で稼働する。また各サービスは、目的が異なることからサービス毎に複数のサーバが利用されている場合があり、サービス利用者（ソフトウェア開発者など）は、サービス接続時に所望のサービスを選択（指定）して利用する必要がある。例として、高性能かつ高価なサーバと低性能かつ安価なサーバの中から所望のサーバのサービスを選択する場合や、テスト用と本番用に用途を分けたサーバの中から所望のサーバのサービスを選択する場合などが考えられる。
【０００４】
従来、クラウド上でアプリケーションを利用するためのプラットフォームを提供する例えばアマゾンウェブサービス（「ＡＷＳ」と称す）などは、クライアントとサーバ（サービス）との中継装置であるアプリケーションプログラミングインターフェースゲートウェイ（以下「ＡＰＩゲートウェイ」と称す）に、テスト時または本番時といったステージに合わせて各ＡＰＩの通信先を切り替える通信先切替機能を備える（例えば非特許文献１参照）。
【０００５】
また、他には、例えば複数の通信パターンの設定の中からいくつかを組み合わせることで通信先を自動切替する技術があり（例えば特許文献１参照）、特定のサーバに通信できないときに代替サーバに通信するような設定が容易にできる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Amazon API Gateway：https://aws.amazon.com/jp/api-gateway/
【特許文献】
【０００７】
【特許文献１】特開２０１３−１９６４６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記した従来技術では、以下のような問題がある。
特許文献１に示される従来の技術の場合、通信先の通信パターンをソフトウェア開発者が手動操作で組み合わせて通信先を設定する必要があり、都度、設定作業が必要であり設定コストがかかる。
【０００９】
近年のソフトウェア開発のように、ＡＰＩゲートウェイを用いて複数のサーバのＡＰＩにより提供されるサービスを束ねる場合、多数のＡＰＩに対して通信パターンを手動操作で組み合わせて設定する必要があるため、人手による設定コストがより増大することになる。
【００１０】
また、非特許文献１で示される従来の技術では、ステージの設定に際して各ＡＰＩに対して通信先を手動操作で個別に指定する必要がある。必要なステージ数はサービス数に応じて掛け算式で増えていく可能性があり、この技術においてもステージを増やすたびに各ＡＰＩに対する設定作業が必要となるため、設定作業のためのコストが膨れ上がる可能性がある。
【００１１】
本発明が解決しようとする課題は、クライアントからのリクエストをＡＰＩゲートウェイが中継してサーバに渡して処理を実行させ、クライアントのユーザにサービスを提供する上で、人手による通信先の設定作業を削減しつつその時々で最適なサービスをユーザに提供できる通信システム、ゲートウェイ装置および通信方法を提供することにある。
【課題を解決するための手段】
【００１２】
実施形態のゲートウェイ装置は、環境パラメータ取得部、仕様情報記憶部、評価条件記憶部、ステージ判定部、サーバパラメータ取得部、通信先選定部、通信処理部を備える。環境パラメータ取得部はゲートウェイ装置の側で検出可能なシステムの環境パラメータを取得する。仕様情報記憶部には各サーバと各サーバで動作するアプリケーションプログラム（ＡＰＩ）とで実現されるマイクロサービスの情報と、ネットワーク上における各サーバの所在情報とを含む仕様情報が記憶されている。評価条件記憶部には各サーバでアプリケーションプログラムが動作しているステージを評価するための第１評価条件（ステージ評価式）と、ステージ毎に前記サーバの機能がリクエストを処理可能か否かを評価するための第２評価条件（サーバ評価式）とが記憶されている。ステージ判定部は取得されたシステムの環境パラメータを基に第１評価条件を満たす現在のステージを判定する。サーバパラメータ取得部は各サーバに存在する機能を実数化したサーバパラメータを取得する。通信先選定部は取得されたサーバパラメータと仕様情報を基に、ステージ判定部により判定されたステージに対応する第２評価条件を満たす通信先のサーバの候補を選定する。通信処理部は通信先選定部により選定されたサーバの候補へ通信を順次試みる。
【図面の簡単な説明】
【００１３】
【図１】実施形態のアプリケーションシステムの構成を示す図である。
【図２】ステージ情報テーブルの一例を示す図である。
【図３】ＡＰＩ情報テーブルの一例を示す図である。
【図４】サーバ情報テーブルの一例を示す図である。
【図５】環境パラメータテーブルの一例を示す図である。
【図６】サーバパラメータテーブルの一例を示す図である。
【図７】このアプリケーションシステムの全体的な動作を示すフローチャートである。
【図８】このアプリケーションシステムにおいて現在のステージを判定する動作を示すフローチャートである。
【図９】このアプリケーションシステムにおいて通信先のサーバを判定する動作を示すフローチャートである。
【図１０】このアプリケーションシステムにおいて通信動作を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、図面を参照して、実施形態を詳細に説明する。
（実施形態）
図１は通信システムの一つの実施の形態のアプリケーションシステムの構成を示す図である。
【００１５】
図１に示すように、実施形態のアプリケーションシステムは、サーバコンピュータとしての複数のアプリケーションサーバ４１〜４４（以下「サーバ４１〜４４」と称す）により提供されるマイクロサービスＭＳ_１、ＭＳ_２（以下「サービスＭＳ_１、ＭＳ_２」と称す）とクライアントコンピュータとしてのクライアントＣ１とをネットワーク１を介して接続し、互いの間にゲートウェイ装置としてＡＰＩゲートウェイ２を介在させ、サーバ４１〜４４とクライアントＣ１間の通信をＡＰＩゲートウェイ２が中継するネットワークシステムである。
【００１６】
複数のサーバ４１〜４４のうち、サーバ４１、４２はサービスＭＳ_１を提供する。サーバ４１のサーバ名を「1_1」とし、サーバ４２のサーバ名を「1_2」とする。
【００１７】
複数のサーバ４１〜４４のうち、サーバ４３、４４はサービスＭＳ_２を提供する。サーバ４３のサーバ名を「2_1」とし、アプリケーションサーバ４４のサーバ名を「2_2」とする。
【００１８】
サービスＭＳ_１、ＭＳ_２を提供する各サーバ４１〜４４は、ウェブ上で処理を行うソフトウェアまたは処理コンポーネントとしてのアプリケーションプログラミングインタフェース（以下「ＡＰＩ」と称す）を有する。
【００１９】
ＡＰＩはクライアントＣ１よりＡＰＩゲートウェイ２を通じて受信された処理依頼のリクエストによりデータ処理を実行するＷｅｂ利用可能なプログラムモジュールである。
【００２０】
ＡＰＩは、サーバ、クライアントなどのコンピュータが有するソフトウェアコンポーネントが互いにやりとりするのに使用するインタフェースプログラムである。ネットワーク１は、インターネットを含む通信回線である。
【００２１】
サーバ４１〜４４、クライアントＣ１、ＡＰＩゲートウェイ２は、ハードウェアとして、ＣＰＵ、メモリ、通信インタフェースなどを有するコンピュータである。
【００２２】
クライアントＣ１には、ＪａｖａＳｃｒｉｐｔ（登録商標）が実行可能なウェブブラウザなどのソフトウェアコンポーネントがインストールされている。ウェブブラウザは、サーバ４１〜４４へのアクセスによりサーバ４１〜４４のＡＰＩより各種機能の入力画面を表示可能である。
【００２３】
入力画面には、例えばアンケート調査などのようにクライアントＣ１の操作者がテキストデータ（文字など）を直接キー入力するための入力ボックスが表示される。入力ボックスに入力されたデータは、ネットワーク１およびＡＰＩゲートウェイ２を経由してサーバ４１〜４４のうちの対象のＡＰＩに送られて処理される。
【００２４】
ＡＰＩゲートウェイ２は、上記ハードウェアにより実現される機能構成として、記憶部２０、環境パラメータ取得部２７、サーバパラメータ取得部２８、通信先選択部２９、制御部３０、通信管理部３１、編集部３４などを有する。
【００２５】
記憶部２０には、評価条件としての評価条件テーブル２１、ＡＰＩ情報テーブル２２およびサーバ情報テーブル２３などの仕様情報テーブル２４、環境パラメータテーブル２５、サーバパラメータテーブル２６などが記憶されている。ＡＰＩ情報テーブル２２には、サーバ４１〜４４で動作するＡＰＩの仕様情報（図３参照）が記憶されている。サーバ情報テーブル２３には、サーバ４１〜４４の仕様情報（図４参照）が記憶されている。通信管理部３１は、通信処理部３２と通信エラー通知部３３を有する。
【００２６】
図２に示すように、評価条件テーブル２１には、システム全体の環境や状況を示すステージを評価するためのステージ評価式（第１評価条件）、サーバ評価式（第２評価条件）などがステージの識別情報（ステージＩＤ）およびステージ名毎に記憶されている。ステージ評価式は、ステージに該当するかどうかを評価するための論理式である。この論理式に、取得した環境パラメータを代入することで計算結果として得られる値が予め設定された閾値を満たすか否かが評価条件である。
【００２７】
例えばサービスの実施段階がテスト段階であることを表すステージの判別式を、Process=testとし、本番段階（運用段階）であることを表すステージの判別式を、Process=prodとする。また、現在時刻が昼であることを表すステージの判別式は、1000 < Time < 2000とする。このようにステージの判別結果を実数（数値）で得たり、または「正」、「否」の２値で得たり、コマンドで得てもよい。
【００２８】
サーバ評価式は、当該ステージにおいてサーバ評価の基準となる計算式であり、ステージに毎に設定されている。ステージを特定した後、特定したステージに対応する計算式に、取得したサーバパラメータを代入することで計算結果として得られる数値の大きさによって、通信先候補としてのサーバの順位が決定する。
【００２９】
すなわち、評価条件テーブル２１は、各サーバ４１〜４４でＡＰＩが動作しているステージを評価するためのステージ評価式と、ステージ毎にサーバ４１〜４４の機能がクライアントＣ１からのリクエストを処理可能か否かを評価するためのサーバ評価式とが記憶された評価条件記憶部として機能する。
【００３０】
仕様情報テーブル２４は、各サーバ４１〜４４と各サーバ４１〜４４で動作するＡＰＩとで実現されるマイクロサービスの情報（マイクロサービスＩＤ）と、ネットワーク１上における各サーバ４１〜４４の所在情報（ロケーション）とを含む仕様情報が記憶された仕様情報記憶部として機能する。
【００３１】
例えば図３に示すように、ＡＰＩ情報テーブル２２には、ＡＰＩのＩＤ毎に、ＡＰＩの名称であるＡＰＩ名と通信先のマイクロサービスＩＤとが対応して記憶される。
【００３２】
図４に示すように、サーバ情報テーブル２３には、サーバのＩＤ毎に、各サーバ４１〜４４のネットワーク１上のロケーション（所在情報）とマイクロサービスＩＤとサーバ名が記憶されている。
【００３３】
環境パラメータ取得部２７は、ＡＰＩゲートウェイ２の側で検出可能なシステムの環境パラメータを取得する。この環境パラメータは、例えば現在時刻(Time)、時間帯（Time zone）、カレンダ（week,day）、サービスの実施段階(Process：テスト段階(test)か本番段階(prod)か）、このゲートウェイ２を中継するデータの通信量の総計、有料サーバの利用金額の合計（課金総額：Billing）といった、システム全体に対して一意に定まる変数であり、それぞれについて取得モジュール２７ａ〜２７ｎが設けられている。各取得モジュール２７ａ〜２７ｎは、通信先選択部２９からの要求に応じてこれらの値を一意に取得できるように実装されている。
【００３４】
また、環境パラメータ取得部２７が返す値がステージ評価式に代入された結果が現在の状況に該当するか否かを表すものである必要があるため、評価式は、論理式で表し、評価結果は真理値（数値）であることが望ましい。
【００３５】
図５に示すように、環境パラメータテーブル２５は、環境パラメータＩＤ毎に変数名とその変数名の値（パラメータ値）が対応して記憶される。変数名の値（パラメータ値）は、環境パラメータ取得部２７により取得された値が入る。この例では、変数名として、課金額Billing、段階Processを例に挙げているが、この他、例えば時刻、サーバの課金総額、サーバの動作状況またはサーバで稼働しているＡＰＩの動作状況などが考えられる。
【００３６】
サーバパラメータ取得部２８は、各サーバ４１〜４４に存在する機能や性能を実数化したサーバパラメータを取得する。このサーバパラメータは、一例として、例えばサーバの性能、利用料（課金額）、バージョン（テスト版、本番用など）、バグの有無といった、サーバ毎に一意に定まるサーバ固有の性質を表す値（属性情報）である。
【００３７】
サーバパラメータ取得部２８は、複数の取得モジュール２８ａ〜２８ｎを有する。各取得モジュール２８ａ〜２８ｎは、それぞれ性能を取得するプログラム、利用料（課金額）を取得するプログラムといったようにパラメータ毎に設けられおり、パラメータは、利用しているサーバの数の分だけ取得される。
【００３８】
図６に示すように、サーバパラメータテーブル２６は、サーバパラメータＩＤ毎に変数名とそのサーバＩＤと変数名の値（パラメータ値）が対応して記憶される。変数名の値（パラメータ値）は、サーバパラメータ取得部２８により取得された値が入る。この例では、変数名として、課金額Billing、運用段階Version_newestを例に挙げている。
【００３９】
通信先選択部２９は、取得されたシステムの環境パラメータを基にステージ評価式を満たす現在のステージ（テストか本番か）を判定するステージ判定部として機能する。具体的には、通信先選択部２９は、環境パラメータを、評価条件として設定されている異なる複数のステージ評価式（stage_1,stage_2,…）に代入し、ステージ毎に評価し、評価結果の中から、評価のよいステージを現在のステージとして特定する。
【００４０】
また、通信先選択部２９は、サーバパラメータ取得部２８により取得されたサーバパラメータを基に、判定したステージに対応するサーバ評価式を満たす通信先のサーバの候補を選定する。より具体的には、通信先選択部２９は、サーバ評価式を満たす通信先候補のサーバのリストを生成し、生成したリストにおいて評価結果のよい通信先候補の順にサーバに優先度を付与して制御部３０を通じて通信処理部３２に渡す。
【００４１】
制御部３０は、クライアントＣ１からのＡＰＩリクエストをリクエスト先のサーバ（サーバ４１〜４４のいずれか）へ中継する制御を行う。また、制御部３０は、下記各部を制御する。
【００４２】
通信管理部３１は、通信先選定部２９から制御部３０を通じてサーバリストを受け取り、サーバリストに従ってサーバと通信を行う。通信処理部３２は、通信先選定部２９により選定されたサーバ（サーバ４１〜４４のいずれか）の候補へ通信を順次試みる。この際、通信処理部３２は、渡されたサーバリストに記載されているサーバＩＤのうち優先度の高い候補の順にサーバへ通信を試みる。
【００４３】
通信処理部３２は、候補の全てのサーバへ通信を試みた結果、通信が失敗、つまり通信エラーが生じた際に通信エラー通知部３３に対して通信エラーを返すよう指示する。通信エラー通知部３３は、この指示に従い制御部３０に通信エラーを返す。そして、制御部３０は、通信エラーをクライアントＣ１へ返す。
【００４４】
編集部３４は、管理者のＰＣからのアクセスにより、評価条件テーブル２１の内容を編集するための編集画面を管理者のＰＣに表示し、編集画面にて評価条件テーブル２１の内容を編集可能である。
【００４５】
以下、図７乃至図１０のフローチャートを参照してこの実施形態のアプリケーションシステムの動作を説明する。図７はこのアプリケーションシステムの全体的な動作を示すフローチャートである。
【００４６】
まず、図７のフローチャートを参照してＡＰＩゲートウェイ２においてクライアントＣ１よりＡＰＩリクエストを受け取ってから通信対象のサーバに対して通信を中継するまでの処理動作を説明する。
【００４７】
ＡＰＩゲートウェイ２では、制御部３０が、クライアントＣ１からＡＰＩリクエストが受信されるのを待機しており（図７のステップＳ１０１のＮｏ、ステップＳ１０２）、クライアントＣ１からのＡＰＩリクエストを受け取ると（図７のステップＳ１０１のＹｅｓ）、制御部３０は、通信先選択部２９に対して通信先のサーバの候補のリスト（サーバリスト）の生成を指示する（ステップＳ１０３）。
【００４８】
このとき、制御部３０は、クライアントＣ１から受け取ったＡＰＩリクエストがどのＡＰＩに対するものであるかを示す要求先情報を通信先選択部２９に伝達する。要求先情報はＡＰＩリクエストに含まれている。
【００４９】
制御部３０からの指示を受けた通信先選択部２９は、環境パラメータ取得部２７が取得した環境パラメータ（時刻、サーバの課金総額、サーバの動作状況またはサーバで稼働しているＡＰＩの動作状況など）を用いて、通信先の現在のステージを特定（判定）する（ステップＳ１０４）。なお、このステージ特定の動作については、後述の図８のフローチャートを参照した説明で詳細に説明する。
【００５０】
通信先選択部２９は、ステージの特定と共に、取得したサーバパラメータをサーバ評価式に代入して、サーバの性能や状態などを評価する。
【００５１】
通信先選択部２９は、特定したステージの条件を満たすサーバのサーバＩＤを、そのステージで動作しているサーバの所在情報とマイクロサービスで利用するＡＰＩの情報を仕様情報テーブル２４（サーバ情報テーブル２３およびＡＰＩ情報テーブル２２）から抽出し、読み出したサーバの情報およびＡＰＩの情報を用いて通信先となり得るサーバの候補を選定し、通信先候補のサーバリストを生成し、制御部３０に渡す（ステップＳ１０５）。なお、通信先のサーバを選定する動作については、後述の図９のフローチャートを参照した説明で詳細に説明する。
【００５２】
制御部３０は、クライアントＣ１から受信したＡＰＩリクエストと、通信先選択部２９により生成された通信先候補のサーバリストとを通信管理部３１に渡す（ステップＳ１０６）。
【００５３】
通信管理部３１は、制御部３０から渡されたサーバリストに記載されている優先度が上位のサーバＩＤから順にサーバと通信を実行し（ステップＳ１０７）、通信により得られた通信結果を制御部３０へ返す。
【００５４】
制御部３０は、通信管理部３１から受け取った通信結果をクライアントＣ１に返す（ステップＳ１０８）。
【００５５】
図８のフローチャートを参照して上記Ｓ１０４のステージ特定動作を詳細に説明する。
この処理では、通信先選択部２９は、評価条件テーブル２１から読み出したステージ情報に含まれるステージ評価式を用いて現在のステージを特定（判定）する。
【００５６】
この場合、通信先選択部２９は、まず、ステージの評価条件、つまり図２の評価条件テーブル２１のステージ評価式を読み出し（ステップＳ２０１）、環境パラメータ取得部２７に対してシステム内外を含めた全ての環境パラメータを要求する（ステップＳ２０２）。
【００５７】
環境パラメータ取得部２７は、各取得モジュール２７ａ〜２７ｎを用いて環境パラメータを取得し（ステップＳ２０３）、それを通信先選択部２９に返す。
【００５８】
通信先選択部２９は、環境パラメータ取得部２７が取得した環境パラメータを受け取ると、受け取った環境パラメータを、全てのステージ評価式（ステージＩＤ"stage_1","stage_2"…ステージＩＤ"stage_4"）に代入し、ステージ毎にサーバの現在のステージを評価する（ステップＳ２０４）。
【００５９】
そして、各ステージ評価式で評価した中から、評価のよいもの（具体的には条件式ならば評価結果が正しいか条件を満たすもの、また関数式ならば高い数値のもの）を、そのサーバの現在のステージとして判定、つまりステージを特定する（ステップＳ２０５）。
【００６０】
ここで、図２の評価条件テーブル２１のステージ評価式内の変数Billingや変数Processは、各環境パラメータに該当しており、取得した環境パラメータの値を評価式に代入する。例えば変数Bllingと変数Processについて、取得した環境パラメータが"1500","test"であれば、ステージＩＤ"stage_1"の評価式は「否」、ステージＩＤ"stage_2"の評価式は「正」、ステージＩＤ"stage_3"の評価式は「否」、ステージＩＤ"stage_4"の評価式は「否」となり、この中から、評価として正しい値、つまり評価結果が「正」のステージＩＤ"stage_2"を現在のステージとして判定する。
【００６１】
なお、ここで示した評価式は、一例であり、上記条件式（選択式）の他に、例えば変数を用いた多項式（F1(X1,X2,…Xn)など）で表現してもよく、取得した環境パラメータを各変数X1,X2,…Xnに代入することで、各ステージの評価結果が真理値で表現される。この中から、評価結果の実数が最大となるステージを現在のステージとして特定（判定）する。
【００６２】
図９のフローチャートを参照して上記Ｓ１０５の通信先のサーバの選定動作を詳細に動作を説明する。
この処理では、通信先選択部２９は、評価条件テーブル２１よりサーバの評価条件、つまり図２の評価条件テーブル２１のサーバ評価式を読み出す（ステップＳ３０１）。
【００６３】
続いて、通信先選択部２９は、サーバパラメータ取得部２８に対して全サーバパラメータを要求する（ステップＳ３０２）。
【００６４】
この要求を受けたサーバパラメータ取得部２８は、各取得モジュール２８ａ〜２８ｎを用いてそれぞれ対応するサーバパラメータを取得する（ステップＳ３０３）。
【００６５】
サーバパラメータ取得部２８の各取得モジュール２８ａ〜２８ｎが通信先選択部２９に返す値は、環境パラメータと同様に、通信先選択部２９が読み出したサーバ評価式（図２参照）に代入して評価（閾値と比較）するため、実数であることが望ましい。但し、通信不可となるサーバを表す場合は、例外値（exception）を利用する。
【００６６】
通信先選択部２９は、サーバパラメータ取得部２８が取得したサーバパラメータをサーバパラメータ取得部２８から受け取り、受け取ったサーバパラメータを、上記Ｓ１０４の処理で判定したステージＩＤのステージに含まれるサーバ評価式に代入し、評価値を算出し記憶する（ステップＳ３０４）。
【００６７】
ここで利用するサーバ評価式は、図８の処理で判定したステージＩＤの"stage2"に対応するサーバ評価式、つまり「-billing+version_newest」である。
【００６８】
サーバパラメータの取得結果が、図６に示すように、サーバパラメータテーブル２６の値であった場合、各値をサーバ評価式に代入すると、サーバ４１(1_1)の計算結果（評価値）は、-1000+1="-999"、サーバ４２(1_2)の計算結果（評価値）は、-10+1="-9"、サーバ４３(2_1)の計算結果（評価値）は、0+1="1"、サーバ４４(2_2)の計算結果（評価値）は、0+exception="例外"となる。
【００６９】
このように取得したサーバパラメータをサーバ評価式の各変数に代入することで、そのステージでの評価計算を行い、各サーバの評価結果として実数を算出する。但し、サーバ４４(2_2)の計算結果（評価値）のように例外値が評価結果となった場合は、そのサーバは、通信不可と判定する。
【００７０】
通信先選択部２９は、仕様情報テーブル２４より、リクエストされたＡＰＩを有する接続先とすべき候補のサーバＩＤとそのロケーションを取得し、サーバＩＤとそのロケーションとが対応した接続先候補のサーバリストを生成する（ステップＳ３０５）。
【００７１】
ここでは、まず、リクエストに含まれるＡＰＩＩＤにて通信するマイクロサービスＩＤをＡＰＩ情報テーブル２２から取得する。続いて、通信先選択部２９は、取得したマイクロサービスＩＤのマイクロサービスに含まれるサーバＩＤとそのロケーション（ネットワーク１上のサーバの所在情報）をサーバ情報テーブル２３から取得し、これらに基づいて接続先候補のサーバリストを生成する。
【００７２】
通信先選択部２９は、生成した接続先候補のサーバリストの各サーバＩＤに優先度を付与（評価値の高いサーバＩＤの順に１から番号を振って順位付け）し（ステップＳ３０６）、優先度を付与した接続先候補のサーバリストを制御部３０に返す（ステップＳ３０７）。なお、評価結果で例外値となっているサーバは、通信不可と判定し、リストから除外する。上記評価結果では、計算結果（評価値）から、サーバ４４(2_2)を除いたサーバ４１(1_1)、サーバ４２(1_2)、サーバ４３(2_1)がサーバリストに載せられる。
【００７３】
図１０のフローチャートを参照して上記Ｓ１０７の通信動作を詳細に説明する。
通信監理部３１では、通信処理部３２が、制御部３０から受け取った情報（通信先候補のサーバリストとＡＰＩリクエスト等）に含まれる通信先候補のサーバリストから、最も優先度の高いサーバＩＤを選択して当該サーバと通信を実行する（図１０のステップＳ４０１）。
【００７４】
ここで、通信に成功した場合（ステップＳ４０２のＮｏ）、通信処理部３２は、当該サーバの通信を終了して、サーバから受け取った通信結果を制御部３０に返す（ステップＳ４０３）。
【００７５】
一方、通信に失敗した場合（ステップＳ４０２のＹｅｓ）、通信処理部３２は、通信に失敗したサーバのサーバＩＤを通信先候補のサーバリストから除外する（ステップＳ４０４）。
【００７６】
除外後、通信処理部３２は、通信先候補のサーバリストに通信先サーバのサーバＩＤが残っているかどうかを確認する（ステップＳ４０５）。
【００７７】
通信先候補のサーバリストを確認した結果、通信先候補のサーバリスト内に通信先サーバのサーバＩＤが残っていない場合（ステップＳ４０５のＮｏ）、通信処理部３２は通信エラー通知部３３に通信エラーを返すよう指示し、この指示に従い通信エラー通知部３３は、制御部３０に通信エラーを返す（ステップＳ４０６）。
【００７８】
サーバリスト内に通信先のサーバのサーバＩＤが残っている場合（ステップＳ４０５のＹｅｓ）、通信処理部３２は、リストに残っているサーバＩＤの中から通信を試みたサーバの次に評価の高かったサーバのサーバＩＤを選択し（ステップＳ４０７）、選択したサーバＩＤを持つサーバに対して通信を再実行する（ステップＳ４０８）。
【００７９】
このようにこの実施形態のアプリケーションシステムによれば、クライアントＣ１からＡＰＩリクエストがＡＰＩゲートウェイ２に受信されると、ＡＰＩゲートウェイ２は、ＡＰＩリクエストに従い通信をサーバのＡＰＩに中継する際に、環境パラメータおよびサーバパラメータを取得し、初めに、取得した環境パラメータをステージ評価式に代入して現在のステージを判定し、次に、取得したサーバパラメータを、判定した現在のステージに対応するサーバ評価式に代入して通信先とすべきサーバを選定する。つまり現在の状況に応じて通信の中継先となるサーバが自動的に選定されるので、ソフトウェア開発者は、状況に応じて手動操作で中継先のサーバを指定する必要が無くなり、その分の作業コストを削減することができる。
【００８０】
また、ＡＰＩゲートウェイ２は、多数のＡＰＩの情報を管理している場合が多く、接続先をＡＰＩ毎に通信パターンなどを設定する必要があり、この通信パターンの設定には人手を要するが、この実施形態では、ＡＰＩ毎の通信パターンの設定は不要であり、想定される状況に対応する評価式をステージ評価用とサーバ評価用の２つの評価式を用意すればよいので、設定コストを低減することができる。
【００８１】
このアプリケーションシステムでは、現在のステージや通信先となるサーバを、利用者が指定することなく自動的に選定し、サーバの利用環境や利用状況に応じて全ＡＰＩの通信先の切り替えを適宜行うので、そのための通信パターンの設定作業が不要になり、ＡＰＩゲートウェイ２を用いて複数のサーバ４１〜４４のＡＰＩを利用してサービスを束ねるようなソフトウェアを開発するにあたり、人手による設定作業を削減し、トータルコストを低減することができる。
【００８２】
本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。ここに示した実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【００８３】
上記実施形態では、ＡＰＩゲートウェイ２において、クライアントＣ１からのリクエストを制御部３０が受け付けて、各サーバ４１〜４４に振り分けたが、この他、ＡＰＩゲートウェイ２にサービス毎にいくつかのＡＰＩを設けておき、クライアントＣ１からのリクエストを、一旦、ＡＰＩゲートウェイ２のＡＰＩで受け付けて、そのＡＰＩが、該当サービスを提供するサーバ４１〜４４にリクエストを振り分けるようにしてもよい。
【００８４】
また、ステージの評価結果に応じてサーバを選定する具体例としては、サーバ４１〜４４の設置場所が、例えば「大阪」や「東京」などのように異なる地域に点在しているケースにおいて、「東京」、「千葉」、「神奈川」などの関東圏で災害が発生したという災害発生情報を、環境パラメータ取得部２７が、例えば防災サイトのサーバより取得してその災害発生情報を通信先選択部２９に渡し、通信先選択部２９は、災害発生情報に含まれる位置情報（環境パラメータ）から、予め設定されている関数式で災害発生地域としての点数を計算し、その点数から災害発生でサービス提供に影響が生じる度合いを評価し、関東圏の度合いが高い場合は、クライアントＣ１からのリクエストを、同種のサービスを提供する「大阪」のサーバへ振り分けるようにしてもよい。
【００８５】
また上記実施形態では、ＡＰＩゲートウェイ２の各構成要素を、コンピュータのハードディスク装置などのストレージにインストールしたプログラムで実現したが、この他、上記プログラムを、コンピュータ読取可能な電子媒体：electronic mediaに記憶しておき、プログラムを電子媒体からコンピュータに読み取らせることで本発明の機能をコンピュータが実現するようにしてもよい。電子媒体としては、例えばＣＤ−ＲＯＭ等の記録媒体やフラッシュメモリ、リムーバブルメディア：Removable media等が含まれる。さらに、ネットワークを介して接続した異なるコンピュータに構成要素を分散して記憶し、各構成要素を機能させたコンピュータ間で通信することで実現してもよい。
【符号の説明】
【００８６】
４１〜４４…アプリケーションサーバ（サーバ）、Ｃ１…クライアント、２…ＡＰＩゲートウェイ、２０…記憶部、２１…評価条件テーブル、２２…ＡＰＩ情報テーブル、２３…サーバ情報テーブル、２４…仕様情報テーブル、２５…環境パラメータテーブル、２６…サーバパラメータテーブル、２７…環境パラメータ取得部、２８…サーバパラメータ取得部、２９…通信先選択部、３０…制御部、３１…通信管理部、３２…通信処理部、３３…通信エラー通知部。
【図１】
2019174969.tif 000003
【図２】
2019174969.tif 000004
【図３】
2019174969.tif 000005
【図４】
2019174969.tif 000006
【図５】
2019174969.tif 000007
【図６】
2019174969.tif 000008
【図７】
2019174969.tif 000009
【図８】
2019174969.tif 000010
【図９】
2019174969.tif 000011
【図１０】
2019174969.tif 000012