(57)【要約】【課題】  複数の仮想サーバーで提供されているＷｅｂサービスが、ＡＰＩスロットリング機能を実装している場合に、各仮想サーバーのＡＰＩ実行回数制限値を自動で決定する仕組みがなかった。【解決手段】  Ｗｅｂサービスを実現している仮想サーバーの台数とＡＰＩ実行回数制限値とに基づき、仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定手段と、ＡＰＩが呼び出された場合、決定手段によって決定されたＡＰＩ実行回数制限値に基づき、Ｗｅｂサービスを提供する、またはＡＰＩの呼び出しをエラーとして処理する制御手段と、を有するサービスシステム。【選択図】  図４
2018097837.tif 000002
【特許請求の範囲】
【請求項１】
夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供するサービスシステムであって、
前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、
仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定手段と、
前記ＡＰＩが呼び出された場合、前記決定手段によって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御手段と、
を有するサービスシステム。
【請求項２】
前記サービスシステムは、
前記サービスシステムの負荷に応じて前記Ｗｅｂサービスを実現している仮想サーバーの台数を変更するオートスケーリング機能と、
前記オートスケーリング機能により変更される前記仮想サーバーの台数を確認する確認手段と、
をさらに有し、
前記決定手段は、前記確認手段により確認された前記仮想サーバーの台数と前記ＡＰＩ実行回数制限値とに基づき、仮想サーバー１台の新たなＡＰＩ実行回数制限値を決定することを特徴とする請求項１に記載のサービスシステム。
【請求項３】
前記確認手段は、
前記決定手段により決定された仮想サーバー１台のＡＰＩ実行回数制限値を更新するタイミングで、前記オートスケーリング機能により変更される前記仮想サーバーの台数を確認することを特徴とする請求項２に記載のサービスシステム。
【請求項４】
前記確認手段は、
前記サービスシステムの負荷に応じて前記Ｗｅｂサービスを実現する新たな仮想サーバーを起動する他、前記サービスシステムのオートスケーリング機能により変更される前記仮想サーバーの台数を管理する管理手段に対し、
前記仮想サーバーの台数を問い合わせることで前記仮想サーバーの台数を確認することを特徴とする請求項２乃至３のいずれか１項に記載のサービスシステム。
【請求項５】
前記オートスケーリング機能は、
前記サービスシステムの負荷が一定以上に増加したことに応じて、前記仮想サーバーの台数を増加させ、前記サービスシステムの負荷が一定以下に減少したことに応じて、前記仮想サーバーの台数を減少させることを特徴とする請求項２乃至４のいずれか１項に記載のサービスシステム。
【請求項６】
前記オートスケーリング機能は、
前記仮想サーバーの使用するリソース及びキューに格納されたジョブの少なくとも一つに基づいて、前記サービスシステムの負荷を判定し、前記仮想サーバーの台数を変更することを特徴とする請求項２乃至５のいずれか１項に記載のサービスシステム。
【請求項７】
前記Ｗｅｂサービスは前記ＡＰＩを複数公開しており、
前記決定手段は、前記Ｗｅｂサービスを実現している仮想サーバーの台数と夫々のＡＰＩ毎に定められた前記ＡＰＩ実行回数制限値とに基づき、仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至６のいずれか１つに記載のサービスシステム。
【請求項８】
前記制御手段は、
特定のＡＰＩが呼び出された場合、前記決定手段により決定された前記特定のＡＰＩに対応するＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの実行をエラーとして処理することを特徴とする請求項７に記載のサービスシステム。
【請求項９】
前記Ｗｅｂサービスは、
認証および認可に関するデータ処理を実行する認証・認可サービス、帳票データを作成するデータ処理を実行する帳票サービス、印刷データを作成するデータ処理を実行する印刷サービス、およびプリンターの情報を管理しレポートデータを作成するデータ処理を実行するプリンター管理サービスのうちいずれか１つであることを特徴とする請求項１乃至８のいずれか１つに記載のサービスシステム。
【請求項１０】
前記決定手段は、
前記ＡＰＩ実行回数制限値を前記仮想サーバーの台数で割ることで仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至９のいずれか一つに記載のサービスシステム。
【請求項１１】
前記決定手段は、
前記ＡＰＩ実行回数制限値に達するまで夫々の前記仮想サーバーに対し任意の数を割り当てていくことで前記仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至９のいずれか一つに記載のサービスシステム。
【請求項１２】
前記サービスシステムは、前記サービスシステムとは異なる外部サービスシステムと連携する機能をさらに有し、
前記決定手段は、
前記Ｗｅｂサービスが、外部サービスシステムにおいて提供されている外部Ｗｅｂサービスによって公開された外部ＡＰＩを実行する回数を制限するために利用される外部ＡＰＩ実行回数制限値と、前記ＡＰＩ実行回数制限値と、前記仮想サーバーの台数とに基づいて、
前記仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至１１のいずれか一つに記載のサービスシステム。
【請求項１３】
前記決定手段は、
前記外部ＡＰＩ実行回数制限値をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割ることにより、新たな外部ＡＰＩ実行回数制限値を算出し、
前記新たな外部ＡＰＩ実行回数制限値と、前記ＡＰＩ実行回数制限値と、前記仮想サーバーの台数とに基づいて、
前記仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１２に記載のサービスシステム。
【請求項１４】
前記ＡＰＩ実行回数は、
前記ＡＰＩが前記クライアントサービスによって実行される回数であり、
前記外部ＡＰＩ実行回数は、前記外部ＡＰＩが前記Ｗｅｂサービスによって実行される回数であることを特徴とする請求項１３に記載のサービスシステム。
【請求項１５】
夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供する制御方法であって、
前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、
仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定ステップと、
前記ＡＰＩが呼び出された場合、前記決定ステップによって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御ステップと、
を有する制御方法。
【請求項１６】
夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供する制御方法を実現するためのプログラムであって、
前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、
仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定ステップと、
前記ＡＰＩが呼び出された場合、前記決定ステップによって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御ステップと、
を有する制御方法を実現するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、公開されたＡＰＩが実行されたことに応じてＷｅｂサービスを提供するサービスシステム、その制御方法、およびそのプログラムに関するものである。
【背景技術】
【０００２】
近年、複数のＷｅｂサービスを連携させる形態が増えている。例えば、公開されたＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を利用し、Ｗｅｂサービス同士を連携させるマッシュアップと呼ばれる方法がある。この方法は、連携先のＷｅｂサービスが公開しているＡＰＩを連携元のＷｅｂサービスが実行し連携先Ｗｅｂサービスを利用することでＷｅｂサービス同士の連携を行う方法である。
【０００３】
そのＷｅｂサービスにおける従来技術として、ＡＰＩスロットリングと呼ばれる機能がある。Ｗｅｂサービスにおいて、単位時間当たりに実行できるＡＰＩ実行回数に制限値を設け、ユーザー端末またはその他のＷｅｂサービスを始めとしたクライアントサービスから大量にＡＰＩが実行されることを抑制する。クライアントが実行したＡＰＩの実行回数が制限値を超えた場合に一定時間Ｗｅｂサービスの利用を禁止するといったペナルティを課すＷｅｂサービスなども存在する。特許文献１には、ＡＰＩスロットリング機能を用いて、大容量データの処理を行う電子システムについて開示されている。
【０００４】
さらに、Ｗｅｂサービスにおける従来技術として、Ｗｅｂサービスを複数の仮想サーバーによって提供することがある。仮想サーバーとは、物理的なサーバーコンピューター群を仮想化技術によって論理的なコンピューターに分割し、分割された論理コンピューター中に独立したＯＳを具備させた論理的なコンピューターのことである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１６−１２６８０１
【発明の概要】
【発明が解決しようとする課題】
【０００６】
複数の仮想サーバーで提供されているＷｅｂサービスが、ＡＰＩスロットリング機能を実装した場合に、各仮想サーバーが実行可能なＡＰＩの実行回数の制限値（以下、ＡＰＩ実行回数制限値）を各仮想サーバーに自動で決定する仕組みがない。
【０００７】
本願発明は、各仮想サーバーの新たなＡＰＩ実行回数制限値を自動で決定することで、ユーザーが手動でＡＰＩ実行回数制限値を決定する煩わしさを解消することを目的とする。
【課題を解決するための手段】
【０００８】
夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供するサービスシステムであって、
前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定手段と、前記ＡＰＩが呼び出された場合、前記決定手段によって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御手段と、を有するサービスシステム。
【発明の効果】
【０００９】
各仮想サーバーのＡＰＩ実行回数制限値を自動で決定することで、ユーザーが手動でＡＰＩ実行回数制限値を決定する煩わしさを解消することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】サービスシステム全体図である。
【図２】情報処理装置２００の内部構成図である。
【図３】各装置の機能のブロック図である。
【図４】本発明の実施例１の処理の流れを示すフローチャートである。
【図５】本発明の実施例１の処理の流れを示すフローチャートである。
【図６】本発明の実施例２の処理の流れを示すフローチャートである。
【図７】本発明の実施例３の処理（パターン２）の流れを示すフローチャートである。
【図８】本発明の実施例３〜５の処理（パターン１）の流れを示すフローチャートである。
【図９】本発明の実施例４、５の処理（パターン２）の流れを示すフローチャートである。
【図１０】（ａ）、（ｂ）、（ｃ）、（ｄ）本発明の実施例２、３、４（パターン１）を示すイメージ図である。
【図１１】（ａ）、（ｂ）、（ｃ）、（ｄ）本発明の実施例２、３、４（パターン２）を示すイメージ図である。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための最良の形態について実施例を用いて説明する。Ｗｅｂサービスとは、サービスシステムを構成するサーバーコンピューター上で実行されたＷｅｂアプリケーションが提供する機能または機能群のことである。本願発明におけるＷｅｂサービスは仮想サーバーにおいて実現される。仮想サーバーとは、物理的なサーバーコンピューター群を仮想化技術によって論理的なコンピューターに分割し、分割された論理コンピューター中に独立したＯＳを具備させた論理的なコンピューターである。
【００１２】
図１を用いて、本実施形態に係るサービスシステム１４０とそのネットワークを構成している各種装置について説明する。図１では、インターネット１００を経由してクライアントシステム１１０、外部サービスシステム１２０または端末１３０が、サービスシステム１４０を構築するサーバーコンピューターまたはサーバーコンピューター群と接続している状態が示されている。クライアントシステム１１０は、サービスシステム１４０が公開するＡＰＩを実行するサービスシステムである。外部サービスシステム１２０は、各ＡＰＩによって実行されたＷｅｂサービスが利用するサービスシステムであり、マッシュアップする際に連携先となるＷｅｂサービスである。端末１３０は、ＷｅｂブラウザーがインストールされているＰＣやスマートフォン、タブレットなどの携帯端末や画像形成装置を想定している。以下、単にＡＰＩと称した場合はサービスシステム１４０が公開するＡＰＩを指し示しており、外部ＡＰＩと称した場合は外部サービスシステム１２０が公開するＡＰＩを指し示していることに留意されたい。
【００１３】
次に図２を用いて、図１に示したサービスシステム１４０を構成するサーバーコンピューターである情報処理装置２００の内部構成について説明する。図２は、情報処理装置２００の内部構成について示したブロック図である。ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウスなどによる情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピューターは、リモートデスクトップなどにより他のコンピューターから接続・操作することも可能である。
【００１４】
ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行うハードウェアである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などからプログラムを取り出してプログラムの命令を実行し、情報処理装置２００の制御を行うユニットである。
【００１５】
ＲＯＭ２０４は、アプリケーションプログラムおよびＯＳを含む組込済みプログラム、およびデータ等が記録されている記憶装置である。ＲＡＭ２０５は、ＣＰＵ２０３が命令を実行する際に使用するワークメモリである。ＲＯＭ２０４に保存されていたプログラムがＲＡＭ２０５へとロードされ、そのプログラムの命令をＣＰＵ２０３が順次読みだし命令を実行する。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。
【００１６】
以上、サービスシステム１４０の情報処理装置２００について述べたが、外部サービスシステム１２０を構成するサーバーコンピューターおよび端末１３０も情報処理装置２００と同様の構造である。
【００１７】
特筆する点として１点ここで説明をしておくと、端末１３０は二次記憶装置２０６に保存されているアプリケーションプログラムがＲＡＭ２０５にロードされることで、端末１３０はＷｅｂブラウザーの機能を実現する。ユーザーがそのＷｅｂブラウザーからＷｅｂサービスにアクセスしＷｅｂサービスの画面を操作することで、ＷｅｂブラウザーによってＡＰＩが実行される。その結果、サービスシステム１４０のＷｅｂサービスをユーザーが端末１３０を用いて利用できる。即ち、Ｗｅｂサービスはマッシュアップ以外の方法でも利用されるということである。
【００１８】
次に図３を用いてＷｅｂサービスを実現するための機能を説明する。以降の説明では、仮想サーバーにオートスケーリング機能が実装されているものとして説明するが、オートスケーリング機能が実装されていない場合でも本願発明は成り立つ。オートスケーリング機能とは、サービスシステム１４０の負荷に応じて自動で仮想サーバーの台数を増減させる機能のことである。オートスケーリング機能により、サービスシステムの負荷が一定以上に高まると仮想サーバー台数を増やして性能劣化を防ぎ、負荷が一定以下に低いときには仮想サーバーの台数を減らして仮想サーバー運用コストを削減することが可能となる。実施例では、後述するオートスケーリンググループ３０３によってオートスケーリング機能が実現する。
【００１９】
図３は、オートスケーリンググループ３０３が管理する仮想サーバー３０２、ＤＢサーバー３０５および負荷分散装置３５０の各装置に構成されるモジュール群を示したブロック図である。仮想サーバー３０２は、ＲＯＭ２０４に組み込まれた仮想サーバー３０２を実現するためのプログラムをＲＡＭ２０５にロードすることで実現され、ＲＡＭ２０５の一部または全体は仮想サーバー３０２を実現するために使用される。仮想サーバー３０２上には、仮想的な二次記憶装置とＲＡＭとＲＯＭとが存在し、仮想的な二次記憶装置に保存されていたプログラムを仮想的なＲＡＭへロードさせることで、仮想サーバー３０２はアプリケーションモジュール３００やＡＰＩ実行制御モジュール３０１を実現する。アプリケーションモジュール３００やＡＰＩ実行制御モジュール３０１によりＷｅｂサービスが実現される。
【００２０】
なお、仮想サーバー３０２は、１台のサーバーコンピューター上に複数台の仮想サーバーを構築する場合もあれば、複数のサーバーコンピューターにより一つの仮想サーバーを構築する場合も考えられる。図３では、オートスケーリンググループ３０３に２つの仮想サーバー３０２が含まれているが、一つの仮想サーバー３０２を含む場合、あるいは３つ以上の仮想サーバー３０２を含む場合等も考えられる。
【００２１】
アプリケーションモジュール３００はＷｅｂサービスを実現する機能を有しており、そのＷｅｂサービスを実行させるためのＡＰＩを外部に公開し、クライアントシステム１１０や端末１３０からの実行要求に応じてＷｅｂサービスを提供する。実施例１におけるＷｅｂサービスは、クラウドシステム上に実装された他のＷｅｂサービスを利用する際の認証および認可処理を行う認証・認可サービスを想定しているが、Ｗｅｂサービスの内容はこれに限るものではない。帳票データを作成するデータ処理を実行する帳票サービス、印刷データを作成するデータ処理を実行する印刷サービス、およびプリンターの情報を管理しレポートデータを作成するデータ処理を実行するプリンター管理サービス等も考えられる。アプリケーションモジュール３００により実現されるＷｅｂサービスは、ＤＢサーバー３０５または外部サービスシステム１２０が公開する外部ＡＰＩを実行することも可能であり、外部ＡＰＩを実行した結果を利用し自身のＷｅｂサービスを実行することによりマッシュアップが可能となる。
【００２２】
オートスケーリンググループ３０３は、仮想サーバー３０２の台数を監視する機能であり、必要に応じて仮想サーバー３０２の台数の増減を行い、その増減結果を管理する。オートスケーリンググループ３０３は、ＲＯＭ２０４に保存されていたプログラムをＲＡＭ２０５へロードし、ＲＡＭ２０５に保存されたプログラムから命令を順次読みだし、読みだした命令を実行することで実現される。
【００２３】
オートスケーリンググループ３０３は、管理している仮想サーバー３０２の負荷を監視し、負荷が大きくなった場合に仮想サーバー３０２の台数を増やし、負荷が小さくなった場合に仮想サーバー３０２の台数を減らす。このように仮想サーバー３０２の台数を負荷の監視結果に基づき増減させることをオートスケーリングと称する。本願発明における負荷の確認とは、仮想サーバー３０２におけるＣＰＵ使用量とメモリ使用量などのリソースの消費量、および仮想サーバー３０２が受け付けるアクセス数などを監視し、負荷の状況を把握することである。オートスケーリンググループ３０３が仮想サーバー３０２の台数を変更する際の判定方法は仮想サーバー３０２の負荷を監視する方法に限らない。例えば、後述の負荷分散モジュール３０４へのアクセス数の監視の他、仮想サーバー３０２が処理するリクエストをキューに保存する場合はそのキューに格納されたジョブ数を監視する方法が考えられる。
【００２４】
負荷分散モジュール３０４は、インターネット１００を介して送信されてきたリクエストを分散して仮想サーバー３０２へ配信する機能を提供し、具体的にはＳＬＢ（Ｓｅｒｖｅｒ  Ｌｏａｄ  Ｂａｌａｎｃｅｒ）がある。ただし、負荷分散モジュール３０４はサービスシステム１４０とは別のサービスシステムで実現してもよく、サービスシステム１４０が負荷分散装置３５０と同等の機能を有するようにしてもよい。負荷分散モジュール３０４は、二次記憶装置２０６に保存されていたプログラムをＲＡＭ２０５へロードさせることで実現される。ＤＢ（ＤａｔａＢａｓｅ）サーバー３０５は、仮想サーバー３０２が利用するデータを管理するサーバーである。なお、ＤＢサーバー３０５は仮想サーバー３０２上に構成されていても良く、不図示のイントラネットで接続された別のサービスシステムとして構成されても良い。
【００２５】
ＤＢサーバー３０５はデータ管理モジュール３１０を持つ。ＤＢサーバー３０５は、二次記憶装置２０６に保存されていたプログラムをＲＡＭ２０５へロードさせることでデータ管理モジュール３１０を実現する。データ管理モジュール３１０の実現により、Ｗｅｂサービスが利用するデータの管理、およびアクセス要求したＷｅｂサービスが各データにアクセスできるか否かのアクセス可否を判断する。ＤＢサーバー３０５は必ずしも必要というわけではなく、ＡＰＩの機能を実現する上で必要なデータをＤＢサーバー３０５ではなく外部サービスシステム１２０などから取得することも可能である。
【００２６】
ＡＰＩ実行制御モジュール３０１は、Ｗｅｂサービスが公開しているＡＰＩの実行要求に対し実行可能か否かを判定し、その結果に基づいてＡＰＩの実行を制御するＡＰＩスロットリング機能を提供している。ＡＰＩスロットリング機能を提供するため、ＡＰＩ実行制御モジュール３０１は二次記憶装置２０６に保存されていたプログラムをＲＡＭ２０５へロードさせることでその機能を実現する。ＡＰＩ実行制御モジュール３０１は各ＡＰＩの単位時間あたりのＡＰＩ実行回数制限値を管理している。本願発明におけるＡＰＩ実行回数とは、ＡＰＩが実行された結果カウントされる回数であり、例えば、ＡＰＩが１回実行されると「１」が記憶される。ＡＰＩ実行制御モジュール３０１が、ＡＰＩ実行回数制限値とＡＰＩ実行回数とを比較して、ＡＰＩ実行回数がＡＰＩ実行回数制限値以下であれば、ＡＰＩを実行するための処理を行い、ＡＰＩ実行回数がＡＰＩ実行回数制限値を上回れば、呼び出されたＡＰＩをエラーとして処理する。これについては、後述の図５で説明する。また、ＡＰＩ実行回数とＡＰＩ実行回数制限値との比較は、Ｗｅｂサービスが公開する全てのＡＰＩに対して行うとは限らず、特定のＡＰＩが呼び出された場合でも、その特定のＡＰＩのＡＰＩ実行回数とＡＰＩ実行回数制限値とを比較することもある。後述の実施例では、Ｗｅｂサービスが公開する全てのＡＰＩに対して、比較を行う場合を例に説明する。
【００２７】
ＷｅｂサービスがＤＢサーバー３０５や外部ＡＰＩを実行する場合、ＤＢサーバー３０５や外部サービスシステム１２０がそのリクエストの処理に耐えられない可能性がある。そうした場合に備え、Ｗｅｂサービス自身のＡＰＩの実行回数に制限をかけるが、必ずしも外部と連携することだけを想定してＡＰＩの実行に制限をかけるものではない。本願発明は仮想サーバー３０２がオートスケーリングし仮想サーバー３０２の台数が変動したとしても、ＡＰＩ実行回数制限値を超えることのないよう、もしくはＡＰＩ実行回数に大幅な余剰が発生しないようにＡＰＩスロットリングを行うことを目的としていることを改めて記載しておく。
【００２８】
なお、ＡＰＩ実行回数制限値はＤＢサーバー３０５や外部サービスシステム１２０の許容できる上限値を考慮した値である必要もなく、またその上限値そのままの値を利用する必要もない。例えば、外部サービスシステム１２０の仕様を考慮し単位時間当たりに実行可能なＡＰＩの実行回数が１００回である場合、ＡＰＩ実行回数制限値は「１００」ではなく「７５」としてもよい。ＡＰＩ実行回数制限値「１００」をそのままＡＰＩ実行回数制限値として利用してしまうと、ＡＰＩの実行回数が１回でもＡＰＩ実行回数制限値「１００」を超えた場合に外部サービスシステム１２０がＷｅｂサービスにペナルティを課すことも考えられるので制限値に余裕を持たせている。しかし、値「１００」をＡＰＩ実行回数制限値としてそのまま利用しても本願発明は実施可能である。
【００２９】
［実施例１］
実施例１では、本願発明の目的を達成するための基本的な形態を説明する。まずは、図４を用いてＡＰＩ実行時におけるフローを説明する。なお、ＡＰＩの実行処理は各仮想サーバー３０２で独立して実行されている。Ｗｅｂサービスが機能群である場合は複数のＡＰＩを公開することもあり、実施例１ではアプリケーションモジュール３００におけるＷｅｂサービスが「ＡＰＩ１」、「ＡＰＩ２」、「ＡＰＩ３」の３つのＡＰＩを公開する場合を考える。表１にＡＰＩ実行制御モジュール３０１が管理しているＡＰＩ実行回数制限値を示す。表１で示したＡＰＩ実行回数制限値は、ＤＢサーバー３０５の実行制限値を考慮してサービスシステム１４０を構築時にユーザーが設定しＡＰＩ実行制御モジュール３０１がその設定値を保存しているものとする。
【００３０】
【表１】
2018097837.tif 000003
【００３１】
図４のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図４のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。
【００３２】
ステップＳ４０１において、現在の仮想サーバーの台数を取得する。今回は、ＡＰＩ実行制御モジュール３０１はオートスケーリンググループ３０３で管理している現在起動中の仮想サーバー３０２の台数を取得しその台数を確認する。なお、現在の仮想サーバー３０２の台数取得方法はこの方法に限らず、例えば負荷分散モジュール３０４が分散先として管理している仮想サーバー３０２の台数を負荷分散モジュール３０４から取得し確認しても良い。また、仮想サーバー３０２の台数を確認するタイミングは、仮想サーバー３０２のＡＰＩ実行回数制限値を決定（または更新）するタイミングでもよく、または定期的に台数を確認する形態等でも問題はない。
【００３３】
実施例１では、現在の仮想サーバー３０２は「仮想サーバーＡ３０２」と「仮想サーバーＢ３０２」の２台が存在しているものとする。表２にＡＰＩ実行制御モジュール３０１が管理している仮想サーバー３０２の台数を示す。
【００３４】
【表２】
2018097837.tif 000004
【００３５】
ステップＳ４０２において、仮想サーバーの台数とＡＰＩ実行回数制限値から、各仮想サーバーに割り振られる新たなＡＰＩ実行回数制限値を決定する。今回は、ＡＰＩ実行制御モジュール３０１が仮想サーバー３０２の台数とＡＰＩ実行回数制限値とに基づき各仮想サーバー３０２に割り振られる新たなＡＰＩ実行回数制限値を計算し決定するものとする。具体的には、表１で示したＡＰＩ実行回数制限値を表２で示した仮想サーバー３０２の台数で割り、その値を新たなＡＰＩ実行回数制限値として決定する。実施例１では、ＡＰＩ実行制御モジュール３０１が仮想サーバー３０２の台数をオートスケーリンググループ３０３から取得して台数を確認し、仮想サーバー３０２の台数を算出する方法を挙げた。
【００３６】
しかし、オートスケーリンググループ３０３が仮想サーバー３０２の台数を管理して新たなＡＰＩ実行回数制限値を計算し、ＡＰＩ実行制御モジュール３０１がその計算結果を利用する方法であってもよい。
【００３７】
今回は、仮想サーバー３０２の台数が２台であるため、表３のように仮想サーバー１台あたりのＡＰＩ実行回数制限値としてＡＰＩ１は５０回、ＡＰＩ２は２５回、ＡＰＩ３は５０回がＡＰＩ実行制御モジュール３０１に設定される。
【００３８】
実施例１では、表１で示した各ＡＰＩ実行回数制限値を表２に示した仮想サーバー３０２の台数で割り、仮想サーバー１台あたりのＡＰＩ実行回数制限値を算出して決定した。ただし、ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には仮想サーバー３０２の台数を把握して割り振り、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。
【００３９】
【表３】
2018097837.tif 000005
【００４０】
ステップＳ４０３において、ＡＰＩの実行判定を行う。今回は、ＡＰＩ実行制御モジュール３０１がステップＳ４０２の結果に基づいてＡＰＩの実行判定を行う。本処理の詳細については図５で後述する。
【００４１】
ステップＳ４０４において、ＡＰＩが実行可能か否かの判定を行う。ステップＳ４０３の結果より実行可能と判定された場合はステップＳ４０５に進み、アプリケーションモジュール３００は要求されたＡＰＩの処理を実行する。ステップＳ４０３の結果より実行不可能と判定された場合はステップＳ４０７に進む。
【００４２】
ステップＳ４０７において、ＡＰＩの実行エラーを応答する。具体的には、Ｓ４０４においてアプリケーションモジュール３００が、ＡＰＩの実行回数がＡＰＩ実行回数制限値を上回ったと判断すると、エラーとなったことをＡＰＩの実行元であるクライアントシステム１１０または端末１３０に応答する。
【００４３】
ステップＳ４０５において要求されたＡＰＩの処理を実行後、ステップＳ４０６において処理が実行できたか否かを判定する。ステップＳ４０６において処理が失敗したと判定された場合は、ステップＳ４０９でアプリケーションモジュール３００が処理の失敗をクライアントシステム１１０または端末１３０に応答する。処理が実行された場合はステップＳ４０８に進み、処理結果をクライアントシステム１１０または端末１３０に応答する。なお、実施例１における図４はＡＰＩ実行要求受信時に毎回実行するフローとして説明したが、ＡＰＩ実行要求を受信せずとも定期的にフローを実行する形態であってもよい。
【００４４】
図５を用いてステップＳ４０３のＡＰＩの実行判定の詳細を説明する。なおＡＰＩの実行判定は、各ＡＰＩ実行回数制限値を利用して判定を行う。実施例１では単位時間を１分として説明を行うが、この値に限らず３０秒や１時間などとしてもよい。また本判定フローについては幾つかの方法があり、実施例１ではそのうちの代表的な方法を示す。
【００４５】
図５は現在時刻をＡＰＩの実行回数をカウントする基準日時とした場合のＡＰＩ実行判定のフローである。ステップＳ５０１において、ＡＰＩ実行制御モジュール３０１はＡＰＩの実行履歴から単位時間あたりの各ＡＰＩの実行回数を取得する。今回は、現在時刻から過去１分間のＡＰＩの実行回数を取得する。表４にＡＰＩの実行履歴を示す。ＡＰＩの実行履歴は、アプリケーションモジュール３００でＡＰＩが実行された際に記録され、実行されたＡＰＩとその実行時間を含む。
【００４６】
実施例１では、「２０１６年１０月１日  １０：００：１０」にＡＰＩの実行要求がされたものとする。ＡＰＩ実行制御モジュール３０１は、ＡＰＩ実行を要求された時間から過去１分間で実行されたＡＰＩ１の実行回数を算出する。表４から、ＡＰＩの実行要求された時刻の１分前である「２０１６年１０月１日  ０９：５９：１０」から「２０１６年１０月１日  １０：００：１０」の間にＡＰＩ１は３回実行されているので、ＡＰＩ１の実行回数は「３」と判断される。
【００４７】
【表４】
2018097837.tif 000006
【００４８】
ステップＳ５０２において、ＡＰＩｎの実行回数がＡＰＩｎのＡＰＩ実行回数制限値未満かどうかを判定する。今回、ＡＰＩ実行制御モジュール３０１はステップＳ５０１の結果とＳ４０２で算出したＡＰＩｎのＡＰＩ実行回数制限値との比較を行い、ＡＰＩｎのＡＰＩ実行回数がＡＰＩｎのＡＰＩ実行回数制限値未満であるか否かを判定する。ステップＳ５０２の結果、ＡＰＩ１のＡＰＩ実行回数がＡＰＩ１のＡＰＩ実行回数制限値未満だった場合はステップＳ５０３に進み、ＡＰＩ１のＡＰＩ実行回数制限値以上だった場合はステップＳ５０４に進む。ＡＰＩ１の場合は、ステップＳ５０１の結果よりＡＰＩ１のＡＰＩ実行回数「３」がＡＰＩ１のＡＰＩ実行回数制限値「５０」（表３）を下回るので、ステップＳ５０３に進む。
【００４９】
ステップＳ５０３において実行可能判定を行い、ステップＳ５０４では実行不可能判定を行う。Ｓ５０３、Ｓ５０４はそれぞれＡＰＩ実行制御モジュール３０１によって行われる。ステップＳ５０５において、全てのＡＰＩの実行判定が行われたと判断されるまで、ステップＳ５０２〜ステップＳ５０５の過程は繰り返される。
【００５０】
続いて、単位時間を一定間隔で区切り区切られた間隔でＡＰＩ実行回数をカウントし、ＡＰＩ実行判定を行うフローを説明する。図５中のステップＳ５０１の代わりに、後述のステップＳ５２０を実施することで本フローを実施する。ステップＳ５２０において、ＡＰＩのＡＰＩ実行回数履歴から過去１分間のＡＰＩ実行回数を一定間隔で取得する。Ｓ５２０はＡＰＩ実行制御モジュール３０１によって取得される。表５にこの方式におけるＡＰＩ１のＡＰＩ実行回数履歴の例を示す。今回は、ＡＰＩ実行回数制限値の単位時間を１分としているため、１５秒間隔でＡＰＩ１のＡＰＩ実行回数をカウントしている方式で説明する。なお本方式でのＡＰＩ実行回数のカウント間隔は１５秒とは限らず、単位時間を複数に分割した時間であればどのような間隔でもよい。
【００５１】
実施例１では、「２０１６年１０月１日  １０：００：１０」にＡＰＩ１の実行要求を受信されたものとする。ＡＰＩ実行制御モジュール３０１は、ＡＰＩ１の実行要求された時間を元に過去１分間のＡＰＩ１のＡＰＩ実行回数をカウントする。具体的には、「２０１６／１０／１  ０９：５９：１５−２９」、「２０１６／１０／１  ０９：５９：３０−４４」、「２０１６／１０／１  ０９：５９：４５−５９」、「２０１６／１０／１  １０：００：００−１４」の実行回数を加算する。表５から、ＡＰＩ１のＡＰＩ実行回数は「４５」と判断される。
【００５２】
【表５】
2018097837.tif 000007
【００５３】
ステップＳ５０２からステップＳ５０５までは、図５で説明したフローと同じなので、詳細な説明は省略する。今回は、ＡＰＩ１のＡＰＩ実行回数がＡＰＩ１のＡＰＩ実行回数制限値以下なので、ＡＰＩ１は実行可能と判定される。
【００５４】
続いて、図４、図５を用いて、オートスケーリング機能が実行されて仮想サーバー３０２の台数が増減した場合について具体的に説明する。まず、Ｗｅｂサービスが仮想サーバーＡ３０２と仮想サーバーＢ３０２の２台の仮想サーバー３０２によって提供されている状態で、オートスケーリング機能により仮想サーバーＣ３０２が追加されたものとする。
【００５５】
ステップＳ４００でＡＰＩ実行制御モジュール３０１がＡＰＩの実行要求を受信した後、ステップＳ４０１において、ＡＰＩ実行制御モジュール３０１によって仮想サーバー３０２の台数が取得される。今回は、仮想サーバー３０２の台数が３台となるため、仮想サーバー３０２の台数「３」が取得される。ステップＳ４０２において、表１のＡＰＩ実行回数制限値をそれぞれ「３」で割って、ＡＰＩ１は３３回、ＡＰＩ２は１６回、ＡＰＩ３は３３回が仮想サーバー１台当たりのＡＰＩ実行回数制限値であると判定される。起動中の仮想サーバーの台数を基に任意の割合でＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分け新たなＡＰＩ実行回数制限値としてもよい。また、今回は表１のＡＰＩ実行回数制限値が仮想サーバー３０２の台数である「３」では割りきれなかったため、表６ではその余りを切り捨てた状態で表示しているが、任意の仮想サーバー３０２にその余りを割り振っても良い。表６に仮想サーバー１台当たりのＡＰＩ実行回数制限値を示す。
【００５６】
【表６】
2018097837.tif 000008
【００５７】
続いて、ステップＳ５０１において、ＡＰＩ実行制御モジュール３０１はＡＰＩ実行回数の履歴からＡＰＩ実行回数を取得する。今回はＡＰＩ１のＡＰＩ実行回数を例に説明する。表７Ａと表７Ｂと表７Ｃに、仮想サーバーＡ３０２と仮想サーバーＢ３０２と仮想サーバーＣ３０２のＡＰＩ１の実行履歴を示す。実施例１では各仮想サーバー３０２に対し「２０１６年１０月１日  １０：００：１０」にＡＰＩ１の実行要求がされたものとする。実行要求されてから過去１分間のＡＰＩ１のＡＰＩ実行回数は、仮想サーバーＡ３０２では表７Ａより２７回、仮想サーバーＢ３０２では表７Ｂより４０回、仮想サーバーＣ３０２では表７ＣよりＡＰＩ１が実行されなかったことが確認できる。
【００５８】
【表７Ａ】
2018097837.tif 000009
【００５９】
【表７Ｂ】
2018097837.tif 000010
【００６０】
【表７Ｃ】
2018097837.tif 000011
【００６１】
ステップＳ５０２からステップＳ５０５において、ＡＰＩ実行制御モジュール３０１は表６のＡＰＩ実行回数制限値と表７のＡＰＩ実行回数とを比較して、仮想サーバーＡ３０２はＡＰＩ実行可能、仮想サーバーＢ３０２はＡＰＩ実行不可能、仮想サーバーＣ３０２は実行可能と判定される。
【００６２】
次に、Ｗｅｂサービスへのアクセス数の減少によりオートスケーリング機能が実行されて、仮想サーバー３０２の台数が減少した場合について説明する。Ｗｅｂサービスが仮想サーバーＡ３０２と仮想サーバーＢ３０２と仮想サーバーＣ３０２の３台の仮想サーバー３０２によって提供されていた状態からオートスケーリング機能により仮想サーバーが２台（仮想サーバーＡ３０２と仮想サーバーＢ３０２）になったものとする。
【００６３】
Ｓ４００においてＡＰＩ実行制御モジュール３０１がＡＰＩの実行要求を受信した後、ステップＳ４０１において、仮想サーバー３０２の台数がＡＰＩ実行制御モジュール３０１によって取得される。仮想サーバー３０２の台数が２台になったため、仮想サーバー３０２の台数「２」が取得される。
【００６４】
ステップＳ４０２において、ＡＰＩ実行制御モジュール３０１は仮想サーバー３０２の台数とＡＰＩ実行回数制限値とに基づき各仮想サーバー３０２に割り振られる新たなＡＰＩ実行回数制限値を算出する。表１のＡＰＩ実行回数制限値を仮想サーバーの台数「２」で割り、ＡＰＩ１は５０回、ＡＰＩ２は２５回、ＡＰＩ３は５０回が新たなＡＰＩ実行回数制限値であると判断される。
【００６５】
続いて、ステップＳ５０１において、ＡＰＩ実行制御モジュール３０１がＡＰＩ実行回数履歴からＡＰＩ実行回数を取得する。表８Ａは仮想サーバーＡ３０２のＡＰＩ１のＡＰＩ実行回数履歴を示し、表８Ｂは仮想サーバーＢ３０２のＡＰＩ１のＡＰＩ実行回数履歴を示す。仮想サーバーＡ３０２と仮想サーバーＢ３０２に対し、「２０１６年１０月１日  １０：０１：４０」にＡＰＩ１の実行要求がされたものとする。実行要求されてから過去１分間のＡＰＩ１のＡＰＩ実行回数は表８Ａより仮想サーバーＡ３０２では３５回であると判定される。ＡＰＩ１のＡＰＩ実行回数制限値「５０」を表８ＡのＡＰＩ実行回数「３５」と、を比較して仮想サーバーＡ３０２はＡＰＩ実行可能と判定される。
【００６６】
一方、仮想サーバーＢ３０２の場合は、実行要求されてから過去１分間のＡＰＩ１のＡＰＩ実行回数は表８Ｂより３０回と判定される。ＡＰＩ１のＡＰＩ実行回数制限値「５０」と比較して、仮想サーバーＢ３０２はＡＰＩ実行可能と判定される。
【００６７】
【表８Ａ】
2018097837.tif 000012
【００６８】
【表８Ｂ】
2018097837.tif 000013
【００６９】
実施例１により、オートスケーリング機能を実行する際に各仮想サーバー３０２での新たなＡＰＩ実行回数制限値を計算しＡＰＩ実行回数制限値を更新できる。これにより、公開しているＡＰＩが大量に実行されてサービスシステム１４０の負荷が高まった際でも、オートスケーリング機能によりＷｅｂサービスを停止せずにリクエスト処理しつつ、スロットリング機能によるＡＰＩの実行制限を起動中の仮想サーバー３０２にかけることができる。一方で、公開しているＡＰＩ実行回数が減少した場合には、各仮想サーバー３０２のＡＰＩの実行能力を十分に生かしたＷｅｂサービスを実現できる。
【００７０】
また、オートスケーリング機能が実装されていない場合でも本願発明を用いることで、仮想サーバーの台数（表２）と、予め設定されているＡＰＩ実行回数制限値（表１）とに基づき、各仮想サーバー３０２の新たなＡＰＩ実行回数制限値（表３）を決定することができる。
【００７１】
［実施例２］
実施例２では、ＡＰＩによって実行されたＷｅｂサービスが外部ＡＰＩを実行する場合に、ＡＰＩ実行制御モジュール３０１において新たなＡＰＩ実行回数制限値を設定する形態を説明する。
【００７２】
外部サービスシステム１２０において外部ＡＰＩ実行回数制限値が設定されている場合、その回数を超えて外部ＡＰＩを実行すると外部サービスシステム１２０の機能を利用できなくなる。ここで、外部ＡＰＩ実行回数制限値とは、外部ＡＰＩが実行された結果カウントされる回数（以下、外部ＡＰＩ実行回数）に制限を設けるための値のことである。外部ＡＰＩ実行回数が外部ＡＰＩ実行回数制限値を上回り、外部サービスシステム１２０の機能が利用できなくなると、ペナルティにより外部ＡＰＩを利用しているＡＰＩも使えなくなってしまい、サービスシステム１４０が停止してしまう。そのため、外部ＡＰＩを利用する場合は、外部ＡＰＩ実行回数制限値に応じてＡＰＩ実行回数制限値を設定する必要がある。
【００７３】
本形態では、図６のフローチャートを用いてＡＰＩ実行回数制限値を設定する方法について説明する。
【００７４】
また、クライアントサービス４００によって実行されたＡＰＩ１、ＡＰＩ２、ＡＰＩ３がＷｅｂサービスを実行し、そのＷｅｂサービスが外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３を実行しているものとする。そのイメージ図を図１０（ａ）に示す。また、以下、区別するために、クライアントシステム１１０が実現するＷｅｂサービスをクライアントサービス４００と呼称し、サービスシステム１４０が実現するＷｅｂサービスをリソースサービス４０１と呼称し、外部サービスシステム１２０が実現するＷｅｂサービスを外部Ｗｅｂサービス４０２と呼称する（図１０、図１１を参照）。今回は一例として、クライアントサービス４００がＡＰＩを実行する場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。
【００７５】
図６のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図６のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。
【００７６】
ステップＳ６０１において、各ＡＰＩによって実行されたＷｅｂサービスが実行する外部ＡＰＩの情報を取得し、管理する。今回は、各ＡＰＩによって実行されたリソースサービス４０１が実行する外部ＡＰＩの情報を取得する。具体的には、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を実行し、ＡＰＩ２によって実行されたリソースサービス４０１が外部ＡＰＩ２を実行し、ＡＰＩ３によって実行されたリソースサービス４０１が外部ＡＰＩ３を実行することを、ＡＰＩ実行制御モジュール３０１が情報として取得し、管理する。
【００７７】
ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、外部ＡＰＩ実行回数制限値「６００」がＡＰＩ実行制御モジュール３０１によって取得され、表９のようにＡＰＩ実行制御モジュール３０１で管理されるものとする。
【００７８】
【表９】
2018097837.tif 000014
【００７９】
ステップＳ６０３において、外部ＡＰＩ実行回数制限値をＡＰＩ数で割り、各ＡＰＩ実行回数制限値を算出する。今回は、ＡＰＩ実行制御モジュール３０１が外部ＡＰＩ実行回数制限値とＡＰＩ数から、各ＡＰＩのＡＰＩ実行回数制限値を決定する。各ＡＰＩのＡＰＩ実行回数制限値を算出する際、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値をそのまま外部ＡＰＩ実行回数制限値として利用する方法のみならず、外部ＡＰＩ実行回数制限値を超えて外部ＡＰＩが実行されても、外部ＡＰＩを実行できる値を設定する方法でもよい。今回は後者の方法を採用し、外部ＡＰＩ実行回数制限値の７５％である「４５０」を外部ＡＰＩ実行回数制限値とする。なお、外部ＡＰＩ実行回数制限値を設定する際の割合は７５％以外の割合でもよい。後述の実施例でも同様である。また、今回は３つのＡＰＩをリソースサービス４０１が公開しているため、ＡＰＩ数は「３」となる。外部ＡＰＩ実行回数制限値「４５０」をＡＰＩ数「３」で割り、算出した値「１５０」を各ＡＰＩのＡＰＩ実行回数制限値とする。
【００８０】
Ｓ６０４において、サービスシステムが予め保有しているＡＰＩ実行回数制限値と、算出したＡＰＩ実行回数制限値と、を比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。今回は、サービスシステム１４０のＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ実行回数制限値（表１）とＳ６０３で算出した各ＡＰＩのＡＰＩ実行回数制限値「１５０」とを比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。Ｓ６０４で比較した結果を表１０に示す。
【００８１】
【表１０】
2018097837.tif 000015
【００８２】
表１で示したＡＰＩ実行回数制限値とステップＳ６０３の計算結果とを比較したのは、ＤＢサーバー３０５の制限値を考慮した上での比較である。ＤＢサーバー３０５を使用しない場合であれば、ステップＳ６０３で得られたＡＰＩ実行回数制限値「１５０」を新たなＡＰＩ実行回数制限値として設定してもよい。また、ＡＰＩ実行回数制限値が、表１のＡＰＩ実行回数制限値を上回っても外部ＡＰＩ実行回数制限値を考慮したＡＰＩ実行回数制限値（Ｓ６０３）を上回らなければ、少なくともペナルティにより外部Ｗｅｂサービス４０２が使用できなくなるようなことは起こらないので、Ｓ６０３で算出したＡＰＩ実行回数制限値を表１の値と比較するステップは必須ではない。さらに、ＤＢサーバー３０５を使用している一部ＡＰＩのＡＰＩ実行回数制限値を設定する場合は、そのＡＰＩ実行回数制限値を設定するときのみ表１の値と比較すればよい。後述の実施例でも同様である。
【００８３】
表９のように、外部サービスシステム１２０が公開する外部ＡＰＩ実行回数制限値が複数の外部ＡＰＩの合計値で示されている場合（以下、パターン１）のみならず、複数の外部ＡＰＩのそれぞれで外部ＡＰＩ実行回数制限値が設定されている場合（以下、パターン２）も考えられる。パターン２において新たなＡＰＩ実行回数制限値を設定する方法を、図６のフローチャートと図１１（ａ）のイメージ図を用いて説明する。今回は一例として、クライアントサービス４００がＡＰＩを実行している場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。今回のパターン２は、図６中のステップＳ６０３を後述のステップＳ１０００に置き換えることで実現する。
【００８４】
ステップＳ４００とステップＳ６０１は実施例２のパターン１と同様の処理で同様の結果が得られるので、詳細の説明は省略する。
【００８５】
ステップＳ６０２において、各ＡＰＩによって実行されたリソースサービス４０１が実行する外部ＡＰＩの情報を取得し、管理する。今回、Ｓ６０２はＡＰＩ実行制御モジュール３０１によって実施されるものとする。具体的には、外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３の外部ＡＰＩ実行回数制限値を取得し、其々「２００」であるものとし、表１１のようにＡＰＩ実行制御モジュール３０１で管理されるものとする。
【００８６】
【表１１】
2018097837.tif 000016
【００８７】
ステップＳ１０００において、各外部の外部ＡＰＩ実行回数制限値を各ＡＰＩ実行回数制限値として設定する。ＡＰＩ実行回数制限値を設定する際、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値（表１１）の７５％である「１５０」をＡＰＩ実行回数制限値とする。なお、制限値を設定する際の割合は７５％以外の割合でもよい。パターン２の場合は、各外部ＡＰＩで外部ＡＰＩ実行回数制限値があらかじめ決められているため、ステップＳ６０３のように外部ＡＰＩ実行回数制限値をＡＰＩ数で割って各ＡＰＩのＡＰＩ実行回数制限値を算出する必要はない。Ｓ６０４は、実施例２のパターン１と同様の処理で同様の結果（表１０）が得られる。
【００８８】
実施例２で設定したＡＰＩ実行回数制限値（表１０）を仮想サーバー３０２の台数で割ることで、各仮想サーバー３０２のＡＰＩ実行回数制限値が得られる。仮想サーバー３０２が２台あるものとすると、実施例２の場合、ステップＳ６０４で得られた各ＡＰＩ実行回数制限値（表１０）を仮想サーバー３０２の台数である「２」で割り、得られた値「５０」が仮想サーバー１台当たりのＡＰＩ１とＡＰＩ３のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。
【００８９】
ただし、ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。
【００９０】
実施例２より、仮想サーバー３０２にオートスケーリング機能が実装されているかどうかに関わらず、外部ＡＰＩ実行回数制限値に応じて、各仮想サーバーにおけるＡＰＩ実行回数制限値を設定できる。この方法により、外部ＡＰＩがＡＰＩの機能によって実行され、外部ＡＰＩ実行回数制限値によって外部Ｗｅｂサービス４０２が停止したり、そのペナルティによりリソースサービス４０１が停止しないように制御することができる。また、外部ＡＰＩ実行回数制限値が変更になった場合にも、自動でＡＰＩ実行回数制限値を変更して、適切な値を維持することができる。
【００９１】
［実施例３］
実施例３以降では、クライアントサービス４００または端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを１回実行すると、そのＡＰＩによって実行されたリソースサービス４０１が外部ＡＰＩを複数回実行する場合を考える。その際の実行回数を、「ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数」と呼称する。（クライアントサービス４００または端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する回数を「ＡＰＩ実行回数」、ＡＰＩによって実行されたリソースサービス４０１が外部ＡＰＩを実行する回数を「外部ＡＰＩ実行回数」とした。）
【００９２】
上記の実施例２では、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が１回の場合で説明している。実施例２で設定した外部ＡＰＩ実行回数制限値「２００」を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が「２」以上の場合にも適応すると、たとえＡＰＩ実行回数が「２００」でも外部ＡＰＩ実行回数が「４００」以上になってしまい、外部ＡＰＩ実行回数制限値「２００」を越えてしまう。その結果、外部サービスシステム１２０が利用できなくなり、そのペナルティによりその外部ＡＰＩを利用しているＡＰＩも使えなくなり、サービスシステム１４０が停止してしまう。そのため、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を考慮してＡＰＩ実行回数制限値を設定する必要がある。
【００９３】
パターン１については、図８のフローチャートを用いてＡＰＩ実行回数制限値を設定する方法について説明する。また、クライアントサービス４００によって実行されたＡＰＩ１、ＡＰＩ２、ＡＰＩ３がリソースサービス４０１を実行し、そのリソースサービス４０１によって外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３を実行されているものとする。そのイメージ図を図１０（ｂ）に示す。
【００９４】
図８のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図８のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。
【００９５】
ステップＳ６０１は実施例２のパターン１と同様の処理で得られるので、詳細の説明は省略する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を２回、ＡＰＩ２の場合は外部ＡＰＩ２を１回、ＡＰＩ３の場合は外部ＡＰＩ３を２回実行しているものとする。それに関する情報を、ＡＰＩ実行制御モジュール３０１が取得し、管理する。
【００９６】
ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、ＡＰＩ実行制御モジュール３０１によって外部ＡＰＩ実行回数制限値「６００」が取得され、実施例２のパターン１のときと同様の情報（表９）がＡＰＩ実行制御モジュール３０１で管理されるものとする。
【００９７】
ステップＳ８０１において、ＡＰＩ実行回数１回あたりの外部ＡＰＩ実行回数の合計値を取得し、管理する。今回、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が、ＡＰＩ１とＡＰＩ２とＡＰＩ３で合計５回なので、ＡＰＩ実行制御モジュール３０１は表１２のように、このＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値を管理するものとする。
【００９８】
【表１２】
2018097837.tif 000017
【００９９】
ステップＳ８０２において、外部ＡＰＩ実行回数制限値を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割り、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値を算出する。具体的には、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値（表１０）を、ステップＳ８０１で取得したＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値（表１２）で割ることで、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値を算出する。その際、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値をそのまま外部ＡＰＩ実行回数制限値として利用する方法のみならず、外部ＡＰＩ実行回数制限値を超えて外部ＡＰＩが実行されても外部ＡＰＩが実行できる値を設定する方法でもよい。今回は後者の方法を採用し、外部ＡＰＩ実行回数制限値の７５％である「４５０」を外部ＡＰＩ実行回数制限値とする。「４５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「５」で割り、得られた値「９０」がＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値となる。その結果、ＡＰＩ実行制御モジュール３０１において、表１３のように外部ＡＰＩ実行回数制限値が設定されたものとする。
【０１００】
【表１３】
2018097837.tif 000018
【０１０１】
Ｓ７０３において、サービスシステムが予め保有しているＡＰＩ実行回数制限値と外部ＡＰＩ実行回数制限値と、を比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。今回は、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ実行回数制限値（表１）とＳ８０２において算出した外部ＡＰＩ実行回数制限値（表１３）とを比較し、その結果を表１４に示す。
【０１０２】
【表１４】
2018097837.tif 000019
【０１０３】
表１で示したＡＰＩ実行回数制限値とステップＳ８０２の計算結果とを比較したのは、ＤＢサーバー３０５の制限値を考慮した上での比較である。ＤＢサーバー３０５を使用しない場合であれば、ステップＳ８０２で得られたＡＰＩ実行回数制限値「９０」を各ＡＰＩのＡＰＩ実行回数制限値として設定してもよい。後述の実施例でも同様である。
【０１０４】
次にパターン２の場合に、ＡＰＩ実行回数制限値を設定する方法を、図７のフローチャートと図１１（ｂ）のイメージ図を用いて説明する。今回は一例として、クライアントサービス４００がＡＰＩを実行する場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。
【０１０５】
図７のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図７のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。
【０１０６】
ステップＳ６０１は実施例３のパターン１と同様の処理で同様の結果が得られるので、説明は省略する。
【０１０７】
ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回はＡＰＩ実行制御モジュール３０１が、外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３の外部ＡＰＩ実行回数制限値を取得し、其々が「２００」であるものとする。実施例２のパターン２のときと同様の情報（表１１）がＡＰＩ実行制御モジュール３０１で管理されるものとする。
【０１０８】
ステップＳ７０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を取得し、管理する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を２回、ＡＰＩ２の場合は外部ＡＰＩ２を１回、ＡＰＩ３の場合は外部ＡＰＩ３を２回実行しているので、表１５のようにＡＰＩ実行制御モジュール３０１がＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を管理する。
【０１０９】
【表１５】
2018097837.tif 000020
【０１１０】
ステップＳ７０２において、外部ＡＰＩｎの外部ＡＰＩ実行回数制限値を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割り、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩｎの外部ＡＰＩ実行回数制限値を算出する。その際、これまでの実施例と同様に、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値（表１０）の７５％である「１５０」をＡＰＩ実行回数制限値とする。ＡＰＩ１（ｎ＝１）の場合は、ステップＳ６０２で得られた外部ＡＰＩ１の外部ＡＰＩ実行回数制限値「１５０」を、ステップＳ７０１で得られたＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数「２」で割り、得られた値「７５」が、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩを実行する回数１回に対するＡＰＩ１のＡＰＩ実行回数制限値となる。
【０１１１】
ステップＳ７０３は、実施例３のパターン１と同様の処理なので、説明は省略する。ＡＰＩ１の場合、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ１のＡＰＩ実行回数制限値「１００」と、ステップＳ７０２で設定したＡＰＩ１のＡＰＩ実行回数制限値「７５」とを比較し、より小さい値である「７５」をＡＰＩ１の新たなＡＰＩ実行回数制限値として設定する。
【０１１２】
ステップＳ７０４において、全ＡＰＩのＡＰＩ実行回数制限値を設定したかどうかを判定する。全てのＡＰＩ実行回数制限値が設定されたと判断されるまで、ステップＳ７０２〜ステップＳ７０４の工程は繰り返される。表１６に、実施例３のパターン２で設定したＡＰＩ実行回数制限値を示す。
【０１１３】
【表１６】
2018097837.tif 000021
【０１１４】
実施例３で設定したＡＰＩ実行回数制限値（表１４、表１６）を仮想サーバー３０２の台数で割ることで、各仮想サーバー３０２の新たなＡＰＩ実行回数制限値が得られる。仮想サーバー３０２が２台あるものとすると、実施例３のパターン１の場合、表１４のＡＰＩ実行回数制限値を仮想サーバー３０２の台数である「２」で割り、得られた値「４５」が仮想サーバー１台当たりのＡＰＩ１とＡＰＩ３のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。
【０１１５】
実施例２のパターン２の場合、表１６のＡＰＩ実行回数制限値を仮想サーバー３０２の台数「２」で割り、得られた値「３７」が仮想サーバー１台当たりのＡＰＩ１とＡＰＩ３のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。ただし、ＡＰＩ１とＡＰＩ３の各仮想サーバーにおけるＡＰＩ実行回数制限値を算出した際の余りは、任意の仮想サーバー３０２に割り振っても良い。
【０１１６】
また、ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。
【０１１７】
実施例３より、仮想サーバー３０２にオートスケーリング機能が実装されているかどうかに関わらず、ＡＰＩによって実行されたリソースサービス４０１が外部ＡＰＩを実行する回数に応じて、各仮想サーバーにおけるＡＰＩ実行回数制限値を設定できる。この方法により、外部ＡＰＩがＡＰＩの機能によって実行され、外部ＡＰＩ実行回数制限値によってリソースサービス４０１や外部Ｗｅｂサービス４０２が停止しないように制御することができる。また、外部ＡＰＩ実行回数制限値が変更になった場合にも、自動でＡＰＩ実行回数制限値を変更し、適切な値を維持することができる。
【０１１８】
［実施例４］
実施例４では、ＡＰＩによって実行されたリソースサービス４０１が複数の外部ＡＰＩを実行する場合にＡＰＩ実行回数制限値を設定する過程を説明する。
【０１１９】
パターン１について、図８のフローチャートを用いてＡＰＩ実行回数制限値を設定する方法について説明する。また、クライアントサービス４００によって実行されたＡＰＩ１とＡＰＩ２がリソースサービス４０１を実行し、そのリソースサービス４０１が外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３を実行しているものとする。そのイメージ図を図１０（ｃ）に示す。今回は一例として、クライアントサービス４００がＡＰＩを実行する場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。
【０１２０】
図８のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図８のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。
【０１２１】
ステップＳ６０１において、各ＡＰＩによって実行されたＷｅｂサービスが呼び出し実行する外部ＡＰＩの情報を取得する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を１回、外部ＡＰＩ２を２回、ＡＰＩ２の場合は外部ＡＰＩ３を２回実行している。それに関する情報をＡＰＩ実行制御モジュール３０１が取得し、管理しているものとする。
【０１２２】
ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、外部ＡＰＩ実行回数制限値「６００」がＡＰＩ実行制御モジュール３０１によって取得され、実施例２のパターン１のときと同様の情報（表９）がＡＰＩ実行制御モジュール３０１で管理されるものとする。
【０１２３】
ステップＳ８０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値を取得し、管理する。今回、ＡＰＩ１とＡＰＩ２によって実行されたリソースサービス４０１が合計で５回外部ＡＰＩを実行するので、ＡＰＩ実行制御モジュール３０１は表１７のように管理するものとする。
【０１２４】
【表１７】
2018097837.tif 000022
【０１２５】
ステップＳ８０２は、実施例３のパターン１と同様の処理で同様の結果（表１３）が得られる。次に、Ｓ７０３において、サービスシステムが予め保有しているＡＰＩ実行回数制限値と外部ＡＰＩ実行回数制限値と、を比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。今回は、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ実行回数制限値（表１）とＳ８０２で算出した外部ＡＰＩの実行回数制限値とを比較して、より小さい値をＡＰＩの新たな実行回数制限値として設定する。比較した結果を表１８に示す。
【０１２６】
【表１８】
2018097837.tif 000023
【０１２７】
表１で示したＡＰＩ実行回数制限値とステップＳ８０２の計算結果を比較したのは、ＤＢサーバー３０５の制限値を考慮した上での比較である。ＤＢサーバー３０５を使用しない場合であれば、ステップＳ８０２で得られた外部ＡＰＩ実行回数制限値をＡＰＩ実行回数制限値として設定してもよい。
【０１２８】
次にパターン２の場合にＡＰＩ実行回数制限値を設定する方法を、図９のフローチャートと図１１（ｃ）のイメージ図を用いて説明する。今回は一例として、クライアントサービス４００がＡＰＩを実行している場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。
【０１２９】
図９のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図９のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。
【０１３０】
ステップＳ６０１は実施例４のパターン１と同様の処理で同様の結果が得られるので、説明は省略する。
【０１３１】
ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、ＡＰＩ実行制御モジュール３０１が外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３の外部ＡＰＩ実行回数制限値を取得し、其々の値が「２００」であるものとする。実施例２のパターン２のときと同様の情報（表１１）がＡＰＩ実行制御モジュール３０１で管理される。
【０１３２】
ステップＳ７０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を取得し、管理する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を１回、外部ＡＰＩ２を２回、ＡＰＩ２の場合は外部ＡＰＩ３を２回実行しているので、表１９のようにＡＰＩ実行制御モジュール３０１がＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を管理しているものとする。
【０１３３】
【表１９】
2018097837.tif 000024
【０１３４】
ステップＳ９０１において、各外部ＡＰＩの外部ＡＰＩ実行回数制限値を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割り、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を算出する。今回は、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値とステップＳ７０１で取得したＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数とを用いて、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部の外部ＡＰＩ実行回数制限値を算出する。算出する際は、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値の７５％である「１５０」をＡＰＩ実行回数制限値とする。具体的に外部ＡＰＩ１の場合、ＡＰＩ１が実行したリソースサービス４０１によって１回実行されているので、ステップＳ６０２で設定した外部ＡＰＩ実行回数制限値「１５０」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ１実行回数制限値となる。また、外部ＡＰＩ２の場合は、ＡＰＩ１が実行したリソースサービス４０１によって２回実行されるので、ステップＳ６０２で設定した外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数「２」で割って得られた値「７５」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ２の外部ＡＰＩ実行回数制限値となる。表２０には、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値を示し、ＡＰＩ実行制御モジュール３０１に設定されたものとする。
【０１３５】
【表２０】
2018097837.tif 000025
【０１３６】
ステップＳ９０２において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値の中で、最小値をＡＰＩｎのＡＰＩ実行回数制限値として設定する。具体的にＡＰＩ１の場合（ｎ＝１）、ＡＰＩ１が実行したリソースサービス４０１が外部ＡＰＩ１と外部ＡＰＩ２とを実行しているので、ステップＳ９０１で算出した結果（表２０）である「１５０」と「７５」とを比較して、より小さい値である「７５」がＡＰＩ１のＡＰＩ実行回数制限値として設定される。
【０１３７】
ステップＳ６０４は、実施例４のパターン１と同様の処理なので、説明は省略する。ＡＰＩ１の場合、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ１のＡＰＩ実行回数制限値「１００」と、ステップＳ９０２で設定したＡＰＩ１のＡＰＩ実行回数制限値「７５」とを比較し、より小さい値である「７５」をＡＰＩ１のＡＰＩ実行回数制限値として設定する。
【０１３８】
ステップＳ９０３において、全ＡＰＩのＡＰＩ実行回数制限値を設定したかどうかを判定する。全てのＡＰＩ実行回数制限値が設定されたと判断されるまで、ステップＳ９０２〜ステップＳ９０３の工程は繰り返される。表２１に、実施例４のパターン２で設定したＡＰＩ実行回数制限値を示す。
【０１３９】
【表２１】
2018097837.tif 000026
【０１４０】
実施例４は、各ＡＰＩが実行したリソースサービス４０１が重複せずに外部ＡＰＩを実行する形態に関するものである。次に、各ＡＰＩが実行したリソースサービス４０１が重複して外部ＡＰＩを実行する形態でＡＰＩ実行回数制限値を設定する形態を説明する。具体的には、図１０（ｄ）や図１１（ｄ）のように、複数のＡＰＩが実行したリソースサービス４０１が一つの外部ＡＰＩを実行する形態を考える。
【０１４１】
パターン１（図１０（ｄ））については、図１０（ｂ）や図１０（ｃ）のときと同様に、図８のフローチャートを用いてＡＰＩ実行回数制限値は設定される。また、実施例３のパターン１（図１０（ｂ））と本形態では、外部ＡＰＩ実行回数制限値とＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値とＡＰＩ数が同じである。そのため、外部ＡＰＩを重複して実行しているかどうかに関わらず、実施例３のパターン１と同様の結果（表１４）が得られる。したがって、図１０（ｄ）の場合においてＡＰＩ実行回数制限値を設定することに関する説明は省略する。
【０１４２】
パターン２（図１１（ｄ））についても、実施例４のパターン２（図１１（ｃ））のときと同様に、図９のフローチャートを用いてＡＰＩ実行回数制限値は設定される。したがって、図１１（ｃ）のときと同様のステップに関する詳細な説明は省略し、異なる結果が得られるステップ（ステップＳ７０１、ステップＳ９０１）のみを以下で説明する。
【０１４３】
ステップＳ７０１で、ＡＰＩ実行回数１回あたりの外部ＡＰＩ実行回数を取得し、管理する。今回は図１１（ｄ）より、ＡＰＩ実行制御モジュール３０１において表２２のようにＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が管理される。
【０１４４】
【表２２】
2018097837.tif 000027
【０１４５】
ステップＳ９０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を算出する。今回は、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値（表１１）と、ステップＳ７０１で取得したＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数とを用いて、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を算出する。ここで、これまでの実施例と同様に、外部ＡＰＩ実行回数制限値「２００」の７５％である「１５０」を外部ＡＰＩ実行回数制限値とする。
【０１４６】
図１１（ｄ）では、外部ＡＰＩ１はＡＰＩ１とＡＰＩ３によって実行されたリソースサービス４０１によって１回ずつ実行されているので、外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「２」で割って得られた「７５」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ１の外部ＡＰＩ実行回数制限値となる。また、外部ＡＰＩ３は、ＡＰＩ１とＡＰＩ３によって実行されたリソースサービス４０１によって１回ずつ実行されているので、外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「２」で割って得られた値「７５」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ３の外部ＡＰＩ実行回数制限値となる。外部ＡＰＩ２は、ＡＰＩ２によって実行されたリソースサービス４０１によって１回実行されているので、ステップＳ６０２で設定した外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「１」で割って得られた値「１５０」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ２の外部ＡＰＩ実行回数制限値となる。表２３には、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を示し、ＡＰＩ実行制御モジュール３０１に設定されたものとする。
【０１４７】
【表２３】
2018097837.tif 000028
【０１４８】
ステップＳ９０３において、全てのＡＰＩ実行回数制限値が設定されたと判断されるまで、ステップＳ９０２〜ステップＳ９０３の工程は繰り返され、その結果、図１１（ｄ）の形態において設定したＡＰＩ実行回数制限値は、実施例３のパターン２（表１６）と同様の結果となる。
【０１４９】
実施例４で設定したＡＰＩ実行回数制限値（表１６）を仮想サーバー３０２の台数で割ることで、各仮想サーバー３０２のＡＰＩ実行回数制限値が得られる。
【０１５０】
仮想サーバー３０２が２台あるものとし、実施例４で算出した結果を仮想サーバー３０２の台数である「２」で割り、得られた値が各仮想サーバー３０２でのＡＰＩ実行回数制限値となる。実施例４のパターン１（図１０（ｃ））の場合、表１８のＡＰＩ実行回数制限値を仮想サーバー３０２の台数である「２」で割り、得られた値「４５」が仮想サーバー１台当たりのＡＰＩ１のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。ＡＰＩ実行回数制限値が仮想サーバー３０２の台数で割りきれない場合は、その余りを任意の仮想サーバー３０２に割り振っても良い。それ以外のパターンの場合も同様である。
【０１５１】
ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。
【０１５２】
実施例４より、仮想サーバー３０２にオートスケーリング機能が実装されているかどうかに関わらず、ＡＰＩによって実行されたリソースサービス４０１が複数の外部ＡＰＩを実行する場合や、複数のＡＰＩによって実行されたリソースサービス４０１が一つの外部ＡＰＩを実行する場合でも、各仮想サーバーにおけるＡＰＩ実行回数制限値を設定することができる。この方法により、外部ＡＰＩがＡＰＩの機能によって実行され、外部ＡＰＩ実行回数制限値によって外部Ｗｅｂサービス４０２が停止したり、そのペナルティによってリソースサービス４０１が停止することがないように制御できる。また、外部ＡＰＩ実行回数制限値が変更になった場合にも、自動でＡＰＩ実行回数制限値を変更し、適切な値を維持することができる。
【０１５３】
［その他の実施例］
上記の実施例では、ＡＰＩが２〜３つ、外部ＡＰＩが３つである場合を示したが、任意のＡＰＩ数や外部ＡＰＩ数、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数等の場合でも本フローは成り立つ。また、実施例２〜４に記載されていない部分は、実施例１に記載されていることと同じである。
【０１５４】
さらに実施例３〜実施例４のパターン１では、図８のフローチャートを用いてＡＰＩ実行回数制限値を算出する方法を説明した。しかし、その方法に限らず、外部ＡＰＩ実行回数制限値をＡＰＩ数で割って、各外部ＡＰＩ実行回数制限値を最初に設定することで、パターン２で示した図７や図９の方法でＡＰＩ実行回数制限値を算出することもできる。
【０１５５】
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１５６】
１１０  クライアントシステム
１２０  外部サービスシステム
３５０  負荷分散装置
３００  アプリケーションモジュール
３０１  ＡＰＩ実行制御モジュール
３０２  仮想サーバー
３０３  オートスケーリンググループ
３０４  負荷分散モジュール
３０５  ＤＢサーバー
３１０  データ管理モジュール
４００  クライアントサービス
４０１  Ｗｅｂサービス
４０２  外部Ｗｅｂサービス
【図１】
2018097837.tif 000029
【図２】
2018097837.tif 000030
【図３】
2018097837.tif 000031
【図４】
2018097837.tif 000032
【図５】
2018097837.tif 000033
【図６】
2018097837.tif 000034
【図７】
2018097837.tif 000035
【図８】
2018097837.tif 000036
【図９】
2018097837.tif 000037
【図１０】
2018097837.tif 000038
【図１１】
2018097837.tif 000039