JP2018097837A - サービスシステム、その制御方法、およびそのプログラム - Google Patents

Abstract

【課題】 複数の仮想サーバーで提供されているＷｅｂサービスが、ＡＰＩスロットリング機能を実装している場合に、各仮想サーバーのＡＰＩ実行回数制限値を自動で決定する仕組みがなかった。
【解決手段】 Ｗｅｂサービスを実現している仮想サーバーの台数とＡＰＩ実行回数制限値とに基づき、仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定手段と、ＡＰＩが呼び出された場合、決定手段によって決定されたＡＰＩ実行回数制限値に基づき、Ｗｅｂサービスを提供する、またはＡＰＩの呼び出しをエラーとして処理する制御手段と、を有するサービスシステム。
【選択図】 図４

Description

本発明は、公開されたＡＰＩが実行されたことに応じてＷｅｂサービスを提供するサービスシステム、その制御方法、およびそのプログラムに関するものである。

近年、複数のＷｅｂサービスを連携させる形態が増えている。例えば、公開されたＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用し、Ｗｅｂサービス同士を連携させるマッシュアップと呼ばれる方法がある。この方法は、連携先のＷｅｂサービスが公開しているＡＰＩを連携元のＷｅｂサービスが実行し連携先Ｗｅｂサービスを利用することでＷｅｂサービス同士の連携を行う方法である。

そのＷｅｂサービスにおける従来技術として、ＡＰＩスロットリングと呼ばれる機能がある。Ｗｅｂサービスにおいて、単位時間当たりに実行できるＡＰＩ実行回数に制限値を設け、ユーザー端末またはその他のＷｅｂサービスを始めとしたクライアントサービスから大量にＡＰＩが実行されることを抑制する。クライアントが実行したＡＰＩの実行回数が制限値を超えた場合に一定時間Ｗｅｂサービスの利用を禁止するといったペナルティを課すＷｅｂサービスなども存在する。特許文献１には、ＡＰＩスロットリング機能を用いて、大容量データの処理を行う電子システムについて開示されている。

さらに、Ｗｅｂサービスにおける従来技術として、Ｗｅｂサービスを複数の仮想サーバーによって提供することがある。仮想サーバーとは、物理的なサーバーコンピューター群を仮想化技術によって論理的なコンピューターに分割し、分割された論理コンピューター中に独立したＯＳを具備させた論理的なコンピューターのことである。

特開２０１６−１２６８０１

複数の仮想サーバーで提供されているＷｅｂサービスが、ＡＰＩスロットリング機能を実装した場合に、各仮想サーバーが実行可能なＡＰＩの実行回数の制限値（以下、ＡＰＩ実行回数制限値）を各仮想サーバーに自動で決定する仕組みがない。

本願発明は、各仮想サーバーの新たなＡＰＩ実行回数制限値を自動で決定することで、ユーザーが手動でＡＰＩ実行回数制限値を決定する煩わしさを解消することを目的とする。

夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供するサービスシステムであって、
前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定手段と、前記ＡＰＩが呼び出された場合、前記決定手段によって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御手段と、を有するサービスシステム。

各仮想サーバーのＡＰＩ実行回数制限値を自動で決定することで、ユーザーが手動でＡＰＩ実行回数制限値を決定する煩わしさを解消することが可能となる。

サービスシステム全体図である。 情報処理装置２００の内部構成図である。 各装置の機能のブロック図である。 本発明の実施例１の処理の流れを示すフローチャートである。 本発明の実施例１の処理の流れを示すフローチャートである。 本発明の実施例２の処理の流れを示すフローチャートである。 本発明の実施例３の処理（パターン２）の流れを示すフローチャートである。 本発明の実施例３〜５の処理（パターン１）の流れを示すフローチャートである。 本発明の実施例４、５の処理（パターン２）の流れを示すフローチャートである。 （ａ）、（ｂ）、（ｃ）、（ｄ）本発明の実施例２、３、４（パターン１）を示すイメージ図である。 （ａ）、（ｂ）、（ｃ）、（ｄ）本発明の実施例２、３、４（パターン２）を示すイメージ図である。

以下、本発明を実施するための最良の形態について実施例を用いて説明する。Ｗｅｂサービスとは、サービスシステムを構成するサーバーコンピューター上で実行されたＷｅｂアプリケーションが提供する機能または機能群のことである。本願発明におけるＷｅｂサービスは仮想サーバーにおいて実現される。仮想サーバーとは、物理的なサーバーコンピューター群を仮想化技術によって論理的なコンピューターに分割し、分割された論理コンピューター中に独立したＯＳを具備させた論理的なコンピューターである。

図１を用いて、本実施形態に係るサービスシステム１４０とそのネットワークを構成している各種装置について説明する。図１では、インターネット１００を経由してクライアントシステム１１０、外部サービスシステム１２０または端末１３０が、サービスシステム１４０を構築するサーバーコンピューターまたはサーバーコンピューター群と接続している状態が示されている。クライアントシステム１１０は、サービスシステム１４０が公開するＡＰＩを実行するサービスシステムである。外部サービスシステム１２０は、各ＡＰＩによって実行されたＷｅｂサービスが利用するサービスシステムであり、マッシュアップする際に連携先となるＷｅｂサービスである。端末１３０は、ＷｅｂブラウザーがインストールされているＰＣやスマートフォン、タブレットなどの携帯端末や画像形成装置を想定している。以下、単にＡＰＩと称した場合はサービスシステム１４０が公開するＡＰＩを指し示しており、外部ＡＰＩと称した場合は外部サービスシステム１２０が公開するＡＰＩを指し示していることに留意されたい。

次に図２を用いて、図１に示したサービスシステム１４０を構成するサーバーコンピューターである情報処理装置２００の内部構成について説明する。図２は、情報処理装置２００の内部構成について示したブロック図である。ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウスなどによる情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピューターは、リモートデスクトップなどにより他のコンピューターから接続・操作することも可能である。

ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行うハードウェアである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などからプログラムを取り出してプログラムの命令を実行し、情報処理装置２００の制御を行うユニットである。

ＲＯＭ２０４は、アプリケーションプログラムおよびＯＳを含む組込済みプログラム、およびデータ等が記録されている記憶装置である。ＲＡＭ２０５は、ＣＰＵ２０３が命令を実行する際に使用するワークメモリである。ＲＯＭ２０４に保存されていたプログラムがＲＡＭ２０５へとロードされ、そのプログラムの命令をＣＰＵ２０３が順次読みだし命令を実行する。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。

以上、サービスシステム１４０の情報処理装置２００について述べたが、外部サービスシステム１２０を構成するサーバーコンピューターおよび端末１３０も情報処理装置２００と同様の構造である。

特筆する点として１点ここで説明をしておくと、端末１３０は二次記憶装置２０６に保存されているアプリケーションプログラムがＲＡＭ２０５にロードされることで、端末１３０はＷｅｂブラウザーの機能を実現する。ユーザーがそのＷｅｂブラウザーからＷｅｂサービスにアクセスしＷｅｂサービスの画面を操作することで、ＷｅｂブラウザーによってＡＰＩが実行される。その結果、サービスシステム１４０のＷｅｂサービスをユーザーが端末１３０を用いて利用できる。即ち、Ｗｅｂサービスはマッシュアップ以外の方法でも利用されるということである。

次に図３を用いてＷｅｂサービスを実現するための機能を説明する。以降の説明では、仮想サーバーにオートスケーリング機能が実装されているものとして説明するが、オートスケーリング機能が実装されていない場合でも本願発明は成り立つ。オートスケーリング機能とは、サービスシステム１４０の負荷に応じて自動で仮想サーバーの台数を増減させる機能のことである。オートスケーリング機能により、サービスシステムの負荷が一定以上に高まると仮想サーバー台数を増やして性能劣化を防ぎ、負荷が一定以下に低いときには仮想サーバーの台数を減らして仮想サーバー運用コストを削減することが可能となる。実施例では、後述するオートスケーリンググループ３０３によってオートスケーリング機能が実現する。

図３は、オートスケーリンググループ３０３が管理する仮想サーバー３０２、ＤＢサーバー３０５および負荷分散装置３５０の各装置に構成されるモジュール群を示したブロック図である。仮想サーバー３０２は、ＲＯＭ２０４に組み込まれた仮想サーバー３０２を実現するためのプログラムをＲＡＭ２０５にロードすることで実現され、ＲＡＭ２０５の一部または全体は仮想サーバー３０２を実現するために使用される。仮想サーバー３０２上には、仮想的な二次記憶装置とＲＡＭとＲＯＭとが存在し、仮想的な二次記憶装置に保存されていたプログラムを仮想的なＲＡＭへロードさせることで、仮想サーバー３０２はアプリケーションモジュール３００やＡＰＩ実行制御モジュール３０１を実現する。アプリケーションモジュール３００やＡＰＩ実行制御モジュール３０１によりＷｅｂサービスが実現される。

なお、仮想サーバー３０２は、１台のサーバーコンピューター上に複数台の仮想サーバーを構築する場合もあれば、複数のサーバーコンピューターにより一つの仮想サーバーを構築する場合も考えられる。図３では、オートスケーリンググループ３０３に２つの仮想サーバー３０２が含まれているが、一つの仮想サーバー３０２を含む場合、あるいは３つ以上の仮想サーバー３０２を含む場合等も考えられる。

アプリケーションモジュール３００はＷｅｂサービスを実現する機能を有しており、そのＷｅｂサービスを実行させるためのＡＰＩを外部に公開し、クライアントシステム１１０や端末１３０からの実行要求に応じてＷｅｂサービスを提供する。実施例１におけるＷｅｂサービスは、クラウドシステム上に実装された他のＷｅｂサービスを利用する際の認証および認可処理を行う認証・認可サービスを想定しているが、Ｗｅｂサービスの内容はこれに限るものではない。帳票データを作成するデータ処理を実行する帳票サービス、印刷データを作成するデータ処理を実行する印刷サービス、およびプリンターの情報を管理しレポートデータを作成するデータ処理を実行するプリンター管理サービス等も考えられる。アプリケーションモジュール３００により実現されるＷｅｂサービスは、ＤＢサーバー３０５または外部サービスシステム１２０が公開する外部ＡＰＩを実行することも可能であり、外部ＡＰＩを実行した結果を利用し自身のＷｅｂサービスを実行することによりマッシュアップが可能となる。

オートスケーリンググループ３０３は、仮想サーバー３０２の台数を監視する機能であり、必要に応じて仮想サーバー３０２の台数の増減を行い、その増減結果を管理する。オートスケーリンググループ３０３は、ＲＯＭ２０４に保存されていたプログラムをＲＡＭ２０５へロードし、ＲＡＭ２０５に保存されたプログラムから命令を順次読みだし、読みだした命令を実行することで実現される。

オートスケーリンググループ３０３は、管理している仮想サーバー３０２の負荷を監視し、負荷が大きくなった場合に仮想サーバー３０２の台数を増やし、負荷が小さくなった場合に仮想サーバー３０２の台数を減らす。このように仮想サーバー３０２の台数を負荷の監視結果に基づき増減させることをオートスケーリングと称する。本願発明における負荷の確認とは、仮想サーバー３０２におけるＣＰＵ使用量とメモリ使用量などのリソースの消費量、および仮想サーバー３０２が受け付けるアクセス数などを監視し、負荷の状況を把握することである。オートスケーリンググループ３０３が仮想サーバー３０２の台数を変更する際の判定方法は仮想サーバー３０２の負荷を監視する方法に限らない。例えば、後述の負荷分散モジュール３０４へのアクセス数の監視の他、仮想サーバー３０２が処理するリクエストをキューに保存する場合はそのキューに格納されたジョブ数を監視する方法が考えられる。

負荷分散モジュール３０４は、インターネット１００を介して送信されてきたリクエストを分散して仮想サーバー３０２へ配信する機能を提供し、具体的にはＳＬＢ（Ｓｅｒｖｅｒ Ｌｏａｄ Ｂａｌａｎｃｅｒ）がある。ただし、負荷分散モジュール３０４はサービスシステム１４０とは別のサービスシステムで実現してもよく、サービスシステム１４０が負荷分散装置３５０と同等の機能を有するようにしてもよい。負荷分散モジュール３０４は、二次記憶装置２０６に保存されていたプログラムをＲＡＭ２０５へロードさせることで実現される。ＤＢ（ＤａｔａＢａｓｅ）サーバー３０５は、仮想サーバー３０２が利用するデータを管理するサーバーである。なお、ＤＢサーバー３０５は仮想サーバー３０２上に構成されていても良く、不図示のイントラネットで接続された別のサービスシステムとして構成されても良い。

ＤＢサーバー３０５はデータ管理モジュール３１０を持つ。ＤＢサーバー３０５は、二次記憶装置２０６に保存されていたプログラムをＲＡＭ２０５へロードさせることでデータ管理モジュール３１０を実現する。データ管理モジュール３１０の実現により、Ｗｅｂサービスが利用するデータの管理、およびアクセス要求したＷｅｂサービスが各データにアクセスできるか否かのアクセス可否を判断する。ＤＢサーバー３０５は必ずしも必要というわけではなく、ＡＰＩの機能を実現する上で必要なデータをＤＢサーバー３０５ではなく外部サービスシステム１２０などから取得することも可能である。

ＡＰＩ実行制御モジュール３０１は、Ｗｅｂサービスが公開しているＡＰＩの実行要求に対し実行可能か否かを判定し、その結果に基づいてＡＰＩの実行を制御するＡＰＩスロットリング機能を提供している。ＡＰＩスロットリング機能を提供するため、ＡＰＩ実行制御モジュール３０１は二次記憶装置２０６に保存されていたプログラムをＲＡＭ２０５へロードさせることでその機能を実現する。ＡＰＩ実行制御モジュール３０１は各ＡＰＩの単位時間あたりのＡＰＩ実行回数制限値を管理している。本願発明におけるＡＰＩ実行回数とは、ＡＰＩが実行された結果カウントされる回数であり、例えば、ＡＰＩが１回実行されると「１」が記憶される。ＡＰＩ実行制御モジュール３０１が、ＡＰＩ実行回数制限値とＡＰＩ実行回数とを比較して、ＡＰＩ実行回数がＡＰＩ実行回数制限値以下であれば、ＡＰＩを実行するための処理を行い、ＡＰＩ実行回数がＡＰＩ実行回数制限値を上回れば、呼び出されたＡＰＩをエラーとして処理する。これについては、後述の図５で説明する。また、ＡＰＩ実行回数とＡＰＩ実行回数制限値との比較は、Ｗｅｂサービスが公開する全てのＡＰＩに対して行うとは限らず、特定のＡＰＩが呼び出された場合でも、その特定のＡＰＩのＡＰＩ実行回数とＡＰＩ実行回数制限値とを比較することもある。後述の実施例では、Ｗｅｂサービスが公開する全てのＡＰＩに対して、比較を行う場合を例に説明する。

ＷｅｂサービスがＤＢサーバー３０５や外部ＡＰＩを実行する場合、ＤＢサーバー３０５や外部サービスシステム１２０がそのリクエストの処理に耐えられない可能性がある。そうした場合に備え、Ｗｅｂサービス自身のＡＰＩの実行回数に制限をかけるが、必ずしも外部と連携することだけを想定してＡＰＩの実行に制限をかけるものではない。本願発明は仮想サーバー３０２がオートスケーリングし仮想サーバー３０２の台数が変動したとしても、ＡＰＩ実行回数制限値を超えることのないよう、もしくはＡＰＩ実行回数に大幅な余剰が発生しないようにＡＰＩスロットリングを行うことを目的としていることを改めて記載しておく。

なお、ＡＰＩ実行回数制限値はＤＢサーバー３０５や外部サービスシステム１２０の許容できる上限値を考慮した値である必要もなく、またその上限値そのままの値を利用する必要もない。例えば、外部サービスシステム１２０の仕様を考慮し単位時間当たりに実行可能なＡＰＩの実行回数が１００回である場合、ＡＰＩ実行回数制限値は「１００」ではなく「７５」としてもよい。ＡＰＩ実行回数制限値「１００」をそのままＡＰＩ実行回数制限値として利用してしまうと、ＡＰＩの実行回数が１回でもＡＰＩ実行回数制限値「１００」を超えた場合に外部サービスシステム１２０がＷｅｂサービスにペナルティを課すことも考えられるので制限値に余裕を持たせている。しかし、値「１００」をＡＰＩ実行回数制限値としてそのまま利用しても本願発明は実施可能である。

［実施例１］
実施例１では、本願発明の目的を達成するための基本的な形態を説明する。まずは、図４を用いてＡＰＩ実行時におけるフローを説明する。なお、ＡＰＩの実行処理は各仮想サーバー３０２で独立して実行されている。Ｗｅｂサービスが機能群である場合は複数のＡＰＩを公開することもあり、実施例１ではアプリケーションモジュール３００におけるＷｅｂサービスが「ＡＰＩ１」、「ＡＰＩ２」、「ＡＰＩ３」の３つのＡＰＩを公開する場合を考える。表１にＡＰＩ実行制御モジュール３０１が管理しているＡＰＩ実行回数制限値を示す。表１で示したＡＰＩ実行回数制限値は、ＤＢサーバー３０５の実行制限値を考慮してサービスシステム１４０を構築時にユーザーが設定しＡＰＩ実行制御モジュール３０１がその設定値を保存しているものとする。

図４のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図４のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。

ステップＳ４０１において、現在の仮想サーバーの台数を取得する。今回は、ＡＰＩ実行制御モジュール３０１はオートスケーリンググループ３０３で管理している現在起動中の仮想サーバー３０２の台数を取得しその台数を確認する。なお、現在の仮想サーバー３０２の台数取得方法はこの方法に限らず、例えば負荷分散モジュール３０４が分散先として管理している仮想サーバー３０２の台数を負荷分散モジュール３０４から取得し確認しても良い。また、仮想サーバー３０２の台数を確認するタイミングは、仮想サーバー３０２のＡＰＩ実行回数制限値を決定（または更新）するタイミングでもよく、または定期的に台数を確認する形態等でも問題はない。

実施例１では、現在の仮想サーバー３０２は「仮想サーバーＡ３０２」と「仮想サーバーＢ３０２」の２台が存在しているものとする。表２にＡＰＩ実行制御モジュール３０１が管理している仮想サーバー３０２の台数を示す。

ステップＳ４０２において、仮想サーバーの台数とＡＰＩ実行回数制限値から、各仮想サーバーに割り振られる新たなＡＰＩ実行回数制限値を決定する。今回は、ＡＰＩ実行制御モジュール３０１が仮想サーバー３０２の台数とＡＰＩ実行回数制限値とに基づき各仮想サーバー３０２に割り振られる新たなＡＰＩ実行回数制限値を計算し決定するものとする。具体的には、表１で示したＡＰＩ実行回数制限値を表２で示した仮想サーバー３０２の台数で割り、その値を新たなＡＰＩ実行回数制限値として決定する。実施例１では、ＡＰＩ実行制御モジュール３０１が仮想サーバー３０２の台数をオートスケーリンググループ３０３から取得して台数を確認し、仮想サーバー３０２の台数を算出する方法を挙げた。

しかし、オートスケーリンググループ３０３が仮想サーバー３０２の台数を管理して新たなＡＰＩ実行回数制限値を計算し、ＡＰＩ実行制御モジュール３０１がその計算結果を利用する方法であってもよい。

今回は、仮想サーバー３０２の台数が２台であるため、表３のように仮想サーバー１台あたりのＡＰＩ実行回数制限値としてＡＰＩ１は５０回、ＡＰＩ２は２５回、ＡＰＩ３は５０回がＡＰＩ実行制御モジュール３０１に設定される。

実施例１では、表１で示した各ＡＰＩ実行回数制限値を表２に示した仮想サーバー３０２の台数で割り、仮想サーバー１台あたりのＡＰＩ実行回数制限値を算出して決定した。ただし、ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には仮想サーバー３０２の台数を把握して割り振り、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。

ステップＳ４０３において、ＡＰＩの実行判定を行う。今回は、ＡＰＩ実行制御モジュール３０１がステップＳ４０２の結果に基づいてＡＰＩの実行判定を行う。本処理の詳細については図５で後述する。

ステップＳ４０４において、ＡＰＩが実行可能か否かの判定を行う。ステップＳ４０３の結果より実行可能と判定された場合はステップＳ４０５に進み、アプリケーションモジュール３００は要求されたＡＰＩの処理を実行する。ステップＳ４０３の結果より実行不可能と判定された場合はステップＳ４０７に進む。

ステップＳ４０７において、ＡＰＩの実行エラーを応答する。具体的には、Ｓ４０４においてアプリケーションモジュール３００が、ＡＰＩの実行回数がＡＰＩ実行回数制限値を上回ったと判断すると、エラーとなったことをＡＰＩの実行元であるクライアントシステム１１０または端末１３０に応答する。

ステップＳ４０５において要求されたＡＰＩの処理を実行後、ステップＳ４０６において処理が実行できたか否かを判定する。ステップＳ４０６において処理が失敗したと判定された場合は、ステップＳ４０９でアプリケーションモジュール３００が処理の失敗をクライアントシステム１１０または端末１３０に応答する。処理が実行された場合はステップＳ４０８に進み、処理結果をクライアントシステム１１０または端末１３０に応答する。なお、実施例１における図４はＡＰＩ実行要求受信時に毎回実行するフローとして説明したが、ＡＰＩ実行要求を受信せずとも定期的にフローを実行する形態であってもよい。

図５を用いてステップＳ４０３のＡＰＩの実行判定の詳細を説明する。なおＡＰＩの実行判定は、各ＡＰＩ実行回数制限値を利用して判定を行う。実施例１では単位時間を１分として説明を行うが、この値に限らず３０秒や１時間などとしてもよい。また本判定フローについては幾つかの方法があり、実施例１ではそのうちの代表的な方法を示す。

図５は現在時刻をＡＰＩの実行回数をカウントする基準日時とした場合のＡＰＩ実行判定のフローである。ステップＳ５０１において、ＡＰＩ実行制御モジュール３０１はＡＰＩの実行履歴から単位時間あたりの各ＡＰＩの実行回数を取得する。今回は、現在時刻から過去１分間のＡＰＩの実行回数を取得する。表４にＡＰＩの実行履歴を示す。ＡＰＩの実行履歴は、アプリケーションモジュール３００でＡＰＩが実行された際に記録され、実行されたＡＰＩとその実行時間を含む。

実施例１では、「２０１６年１０月１日 １０：００：１０」にＡＰＩの実行要求がされたものとする。ＡＰＩ実行制御モジュール３０１は、ＡＰＩ実行を要求された時間から過去１分間で実行されたＡＰＩ１の実行回数を算出する。表４から、ＡＰＩの実行要求された時刻の１分前である「２０１６年１０月１日 ０９：５９：１０」から「２０１６年１０月１日 １０：００：１０」の間にＡＰＩ１は３回実行されているので、ＡＰＩ１の実行回数は「３」と判断される。

ステップＳ５０２において、ＡＰＩｎの実行回数がＡＰＩｎのＡＰＩ実行回数制限値未満かどうかを判定する。今回、ＡＰＩ実行制御モジュール３０１はステップＳ５０１の結果とＳ４０２で算出したＡＰＩｎのＡＰＩ実行回数制限値との比較を行い、ＡＰＩｎのＡＰＩ実行回数がＡＰＩｎのＡＰＩ実行回数制限値未満であるか否かを判定する。ステップＳ５０２の結果、ＡＰＩ１のＡＰＩ実行回数がＡＰＩ１のＡＰＩ実行回数制限値未満だった場合はステップＳ５０３に進み、ＡＰＩ１のＡＰＩ実行回数制限値以上だった場合はステップＳ５０４に進む。ＡＰＩ１の場合は、ステップＳ５０１の結果よりＡＰＩ１のＡＰＩ実行回数「３」がＡＰＩ１のＡＰＩ実行回数制限値「５０」（表３）を下回るので、ステップＳ５０３に進む。

ステップＳ５０３において実行可能判定を行い、ステップＳ５０４では実行不可能判定を行う。Ｓ５０３、Ｓ５０４はそれぞれＡＰＩ実行制御モジュール３０１によって行われる。ステップＳ５０５において、全てのＡＰＩの実行判定が行われたと判断されるまで、ステップＳ５０２〜ステップＳ５０５の過程は繰り返される。

続いて、単位時間を一定間隔で区切り区切られた間隔でＡＰＩ実行回数をカウントし、ＡＰＩ実行判定を行うフローを説明する。図５中のステップＳ５０１の代わりに、後述のステップＳ５２０を実施することで本フローを実施する。ステップＳ５２０において、ＡＰＩのＡＰＩ実行回数履歴から過去１分間のＡＰＩ実行回数を一定間隔で取得する。Ｓ５２０はＡＰＩ実行制御モジュール３０１によって取得される。表５にこの方式におけるＡＰＩ１のＡＰＩ実行回数履歴の例を示す。今回は、ＡＰＩ実行回数制限値の単位時間を１分としているため、１５秒間隔でＡＰＩ１のＡＰＩ実行回数をカウントしている方式で説明する。なお本方式でのＡＰＩ実行回数のカウント間隔は１５秒とは限らず、単位時間を複数に分割した時間であればどのような間隔でもよい。

実施例１では、「２０１６年１０月１日 １０：００：１０」にＡＰＩ１の実行要求を受信されたものとする。ＡＰＩ実行制御モジュール３０１は、ＡＰＩ１の実行要求された時間を元に過去１分間のＡＰＩ１のＡＰＩ実行回数をカウントする。具体的には、「２０１６／１０／１ ０９：５９：１５−２９」、「２０１６／１０／１ ０９：５９：３０−４４」、「２０１６／１０／１ ０９：５９：４５−５９」、「２０１６／１０／１ １０：００：００−１４」の実行回数を加算する。表５から、ＡＰＩ１のＡＰＩ実行回数は「４５」と判断される。

ステップＳ５０２からステップＳ５０５までは、図５で説明したフローと同じなので、詳細な説明は省略する。今回は、ＡＰＩ１のＡＰＩ実行回数がＡＰＩ１のＡＰＩ実行回数制限値以下なので、ＡＰＩ１は実行可能と判定される。

続いて、図４、図５を用いて、オートスケーリング機能が実行されて仮想サーバー３０２の台数が増減した場合について具体的に説明する。まず、Ｗｅｂサービスが仮想サーバーＡ３０２と仮想サーバーＢ３０２の２台の仮想サーバー３０２によって提供されている状態で、オートスケーリング機能により仮想サーバーＣ３０２が追加されたものとする。

ステップＳ４００でＡＰＩ実行制御モジュール３０１がＡＰＩの実行要求を受信した後、ステップＳ４０１において、ＡＰＩ実行制御モジュール３０１によって仮想サーバー３０２の台数が取得される。今回は、仮想サーバー３０２の台数が３台となるため、仮想サーバー３０２の台数「３」が取得される。ステップＳ４０２において、表１のＡＰＩ実行回数制限値をそれぞれ「３」で割って、ＡＰＩ１は３３回、ＡＰＩ２は１６回、ＡＰＩ３は３３回が仮想サーバー１台当たりのＡＰＩ実行回数制限値であると判定される。起動中の仮想サーバーの台数を基に任意の割合でＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分け新たなＡＰＩ実行回数制限値としてもよい。また、今回は表１のＡＰＩ実行回数制限値が仮想サーバー３０２の台数である「３」では割りきれなかったため、表６ではその余りを切り捨てた状態で表示しているが、任意の仮想サーバー３０２にその余りを割り振っても良い。表６に仮想サーバー１台当たりのＡＰＩ実行回数制限値を示す。

続いて、ステップＳ５０１において、ＡＰＩ実行制御モジュール３０１はＡＰＩ実行回数の履歴からＡＰＩ実行回数を取得する。今回はＡＰＩ１のＡＰＩ実行回数を例に説明する。表７Ａと表７Ｂと表７Ｃに、仮想サーバーＡ３０２と仮想サーバーＢ３０２と仮想サーバーＣ３０２のＡＰＩ１の実行履歴を示す。実施例１では各仮想サーバー３０２に対し「２０１６年１０月１日 １０：００：１０」にＡＰＩ１の実行要求がされたものとする。実行要求されてから過去１分間のＡＰＩ１のＡＰＩ実行回数は、仮想サーバーＡ３０２では表７Ａより２７回、仮想サーバーＢ３０２では表７Ｂより４０回、仮想サーバーＣ３０２では表７ＣよりＡＰＩ１が実行されなかったことが確認できる。

ステップＳ５０２からステップＳ５０５において、ＡＰＩ実行制御モジュール３０１は表６のＡＰＩ実行回数制限値と表７のＡＰＩ実行回数とを比較して、仮想サーバーＡ３０２はＡＰＩ実行可能、仮想サーバーＢ３０２はＡＰＩ実行不可能、仮想サーバーＣ３０２は実行可能と判定される。

次に、Ｗｅｂサービスへのアクセス数の減少によりオートスケーリング機能が実行されて、仮想サーバー３０２の台数が減少した場合について説明する。Ｗｅｂサービスが仮想サーバーＡ３０２と仮想サーバーＢ３０２と仮想サーバーＣ３０２の３台の仮想サーバー３０２によって提供されていた状態からオートスケーリング機能により仮想サーバーが２台（仮想サーバーＡ３０２と仮想サーバーＢ３０２）になったものとする。

Ｓ４００においてＡＰＩ実行制御モジュール３０１がＡＰＩの実行要求を受信した後、ステップＳ４０１において、仮想サーバー３０２の台数がＡＰＩ実行制御モジュール３０１によって取得される。仮想サーバー３０２の台数が２台になったため、仮想サーバー３０２の台数「２」が取得される。

ステップＳ４０２において、ＡＰＩ実行制御モジュール３０１は仮想サーバー３０２の台数とＡＰＩ実行回数制限値とに基づき各仮想サーバー３０２に割り振られる新たなＡＰＩ実行回数制限値を算出する。表１のＡＰＩ実行回数制限値を仮想サーバーの台数「２」で割り、ＡＰＩ１は５０回、ＡＰＩ２は２５回、ＡＰＩ３は５０回が新たなＡＰＩ実行回数制限値であると判断される。

続いて、ステップＳ５０１において、ＡＰＩ実行制御モジュール３０１がＡＰＩ実行回数履歴からＡＰＩ実行回数を取得する。表８Ａは仮想サーバーＡ３０２のＡＰＩ１のＡＰＩ実行回数履歴を示し、表８Ｂは仮想サーバーＢ３０２のＡＰＩ１のＡＰＩ実行回数履歴を示す。仮想サーバーＡ３０２と仮想サーバーＢ３０２に対し、「２０１６年１０月１日 １０：０１：４０」にＡＰＩ１の実行要求がされたものとする。実行要求されてから過去１分間のＡＰＩ１のＡＰＩ実行回数は表８Ａより仮想サーバーＡ３０２では３５回であると判定される。ＡＰＩ１のＡＰＩ実行回数制限値「５０」を表８ＡのＡＰＩ実行回数「３５」と、を比較して仮想サーバーＡ３０２はＡＰＩ実行可能と判定される。

一方、仮想サーバーＢ３０２の場合は、実行要求されてから過去１分間のＡＰＩ１のＡＰＩ実行回数は表８Ｂより３０回と判定される。ＡＰＩ１のＡＰＩ実行回数制限値「５０」と比較して、仮想サーバーＢ３０２はＡＰＩ実行可能と判定される。

実施例１により、オートスケーリング機能を実行する際に各仮想サーバー３０２での新たなＡＰＩ実行回数制限値を計算しＡＰＩ実行回数制限値を更新できる。これにより、公開しているＡＰＩが大量に実行されてサービスシステム１４０の負荷が高まった際でも、オートスケーリング機能によりＷｅｂサービスを停止せずにリクエスト処理しつつ、スロットリング機能によるＡＰＩの実行制限を起動中の仮想サーバー３０２にかけることができる。一方で、公開しているＡＰＩ実行回数が減少した場合には、各仮想サーバー３０２のＡＰＩの実行能力を十分に生かしたＷｅｂサービスを実現できる。

また、オートスケーリング機能が実装されていない場合でも本願発明を用いることで、仮想サーバーの台数（表２）と、予め設定されているＡＰＩ実行回数制限値（表１）とに基づき、各仮想サーバー３０２の新たなＡＰＩ実行回数制限値（表３）を決定することができる。

［実施例２］
実施例２では、ＡＰＩによって実行されたＷｅｂサービスが外部ＡＰＩを実行する場合に、ＡＰＩ実行制御モジュール３０１において新たなＡＰＩ実行回数制限値を設定する形態を説明する。

外部サービスシステム１２０において外部ＡＰＩ実行回数制限値が設定されている場合、その回数を超えて外部ＡＰＩを実行すると外部サービスシステム１２０の機能を利用できなくなる。ここで、外部ＡＰＩ実行回数制限値とは、外部ＡＰＩが実行された結果カウントされる回数（以下、外部ＡＰＩ実行回数）に制限を設けるための値のことである。外部ＡＰＩ実行回数が外部ＡＰＩ実行回数制限値を上回り、外部サービスシステム１２０の機能が利用できなくなると、ペナルティにより外部ＡＰＩを利用しているＡＰＩも使えなくなってしまい、サービスシステム１４０が停止してしまう。そのため、外部ＡＰＩを利用する場合は、外部ＡＰＩ実行回数制限値に応じてＡＰＩ実行回数制限値を設定する必要がある。

本形態では、図６のフローチャートを用いてＡＰＩ実行回数制限値を設定する方法について説明する。

また、クライアントサービス４００によって実行されたＡＰＩ１、ＡＰＩ２、ＡＰＩ３がＷｅｂサービスを実行し、そのＷｅｂサービスが外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３を実行しているものとする。そのイメージ図を図１０（ａ）に示す。また、以下、区別するために、クライアントシステム１１０が実現するＷｅｂサービスをクライアントサービス４００と呼称し、サービスシステム１４０が実現するＷｅｂサービスをリソースサービス４０１と呼称し、外部サービスシステム１２０が実現するＷｅｂサービスを外部Ｗｅｂサービス４０２と呼称する（図１０、図１１を参照）。今回は一例として、クライアントサービス４００がＡＰＩを実行する場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。

図６のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図６のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。

ステップＳ６０１において、各ＡＰＩによって実行されたＷｅｂサービスが実行する外部ＡＰＩの情報を取得し、管理する。今回は、各ＡＰＩによって実行されたリソースサービス４０１が実行する外部ＡＰＩの情報を取得する。具体的には、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を実行し、ＡＰＩ２によって実行されたリソースサービス４０１が外部ＡＰＩ２を実行し、ＡＰＩ３によって実行されたリソースサービス４０１が外部ＡＰＩ３を実行することを、ＡＰＩ実行制御モジュール３０１が情報として取得し、管理する。

ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、外部ＡＰＩ実行回数制限値「６００」がＡＰＩ実行制御モジュール３０１によって取得され、表９のようにＡＰＩ実行制御モジュール３０１で管理されるものとする。

ステップＳ６０３において、外部ＡＰＩ実行回数制限値をＡＰＩ数で割り、各ＡＰＩ実行回数制限値を算出する。今回は、ＡＰＩ実行制御モジュール３０１が外部ＡＰＩ実行回数制限値とＡＰＩ数から、各ＡＰＩのＡＰＩ実行回数制限値を決定する。各ＡＰＩのＡＰＩ実行回数制限値を算出する際、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値をそのまま外部ＡＰＩ実行回数制限値として利用する方法のみならず、外部ＡＰＩ実行回数制限値を超えて外部ＡＰＩが実行されても、外部ＡＰＩを実行できる値を設定する方法でもよい。今回は後者の方法を採用し、外部ＡＰＩ実行回数制限値の７５％である「４５０」を外部ＡＰＩ実行回数制限値とする。なお、外部ＡＰＩ実行回数制限値を設定する際の割合は７５％以外の割合でもよい。後述の実施例でも同様である。また、今回は３つのＡＰＩをリソースサービス４０１が公開しているため、ＡＰＩ数は「３」となる。外部ＡＰＩ実行回数制限値「４５０」をＡＰＩ数「３」で割り、算出した値「１５０」を各ＡＰＩのＡＰＩ実行回数制限値とする。

Ｓ６０４において、サービスシステムが予め保有しているＡＰＩ実行回数制限値と、算出したＡＰＩ実行回数制限値と、を比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。今回は、サービスシステム１４０のＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ実行回数制限値（表１）とＳ６０３で算出した各ＡＰＩのＡＰＩ実行回数制限値「１５０」とを比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。Ｓ６０４で比較した結果を表１０に示す。

表１で示したＡＰＩ実行回数制限値とステップＳ６０３の計算結果とを比較したのは、ＤＢサーバー３０５の制限値を考慮した上での比較である。ＤＢサーバー３０５を使用しない場合であれば、ステップＳ６０３で得られたＡＰＩ実行回数制限値「１５０」を新たなＡＰＩ実行回数制限値として設定してもよい。また、ＡＰＩ実行回数制限値が、表１のＡＰＩ実行回数制限値を上回っても外部ＡＰＩ実行回数制限値を考慮したＡＰＩ実行回数制限値（Ｓ６０３）を上回らなければ、少なくともペナルティにより外部Ｗｅｂサービス４０２が使用できなくなるようなことは起こらないので、Ｓ６０３で算出したＡＰＩ実行回数制限値を表１の値と比較するステップは必須ではない。さらに、ＤＢサーバー３０５を使用している一部ＡＰＩのＡＰＩ実行回数制限値を設定する場合は、そのＡＰＩ実行回数制限値を設定するときのみ表１の値と比較すればよい。後述の実施例でも同様である。

表９のように、外部サービスシステム１２０が公開する外部ＡＰＩ実行回数制限値が複数の外部ＡＰＩの合計値で示されている場合（以下、パターン１）のみならず、複数の外部ＡＰＩのそれぞれで外部ＡＰＩ実行回数制限値が設定されている場合（以下、パターン２）も考えられる。パターン２において新たなＡＰＩ実行回数制限値を設定する方法を、図６のフローチャートと図１１（ａ）のイメージ図を用いて説明する。今回は一例として、クライアントサービス４００がＡＰＩを実行している場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。今回のパターン２は、図６中のステップＳ６０３を後述のステップＳ１０００に置き換えることで実現する。

ステップＳ４００とステップＳ６０１は実施例２のパターン１と同様の処理で同様の結果が得られるので、詳細の説明は省略する。

ステップＳ６０２において、各ＡＰＩによって実行されたリソースサービス４０１が実行する外部ＡＰＩの情報を取得し、管理する。今回、Ｓ６０２はＡＰＩ実行制御モジュール３０１によって実施されるものとする。具体的には、外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３の外部ＡＰＩ実行回数制限値を取得し、其々「２００」であるものとし、表１１のようにＡＰＩ実行制御モジュール３０１で管理されるものとする。

ステップＳ１０００において、各外部の外部ＡＰＩ実行回数制限値を各ＡＰＩ実行回数制限値として設定する。ＡＰＩ実行回数制限値を設定する際、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値（表１１）の７５％である「１５０」をＡＰＩ実行回数制限値とする。なお、制限値を設定する際の割合は７５％以外の割合でもよい。パターン２の場合は、各外部ＡＰＩで外部ＡＰＩ実行回数制限値があらかじめ決められているため、ステップＳ６０３のように外部ＡＰＩ実行回数制限値をＡＰＩ数で割って各ＡＰＩのＡＰＩ実行回数制限値を算出する必要はない。Ｓ６０４は、実施例２のパターン１と同様の処理で同様の結果（表１０）が得られる。

実施例２で設定したＡＰＩ実行回数制限値（表１０）を仮想サーバー３０２の台数で割ることで、各仮想サーバー３０２のＡＰＩ実行回数制限値が得られる。仮想サーバー３０２が２台あるものとすると、実施例２の場合、ステップＳ６０４で得られた各ＡＰＩ実行回数制限値（表１０）を仮想サーバー３０２の台数である「２」で割り、得られた値「５０」が仮想サーバー１台当たりのＡＰＩ１とＡＰＩ３のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。

ただし、ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。

実施例２より、仮想サーバー３０２にオートスケーリング機能が実装されているかどうかに関わらず、外部ＡＰＩ実行回数制限値に応じて、各仮想サーバーにおけるＡＰＩ実行回数制限値を設定できる。この方法により、外部ＡＰＩがＡＰＩの機能によって実行され、外部ＡＰＩ実行回数制限値によって外部Ｗｅｂサービス４０２が停止したり、そのペナルティによりリソースサービス４０１が停止しないように制御することができる。また、外部ＡＰＩ実行回数制限値が変更になった場合にも、自動でＡＰＩ実行回数制限値を変更して、適切な値を維持することができる。

［実施例３］
実施例３以降では、クライアントサービス４００または端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを１回実行すると、そのＡＰＩによって実行されたリソースサービス４０１が外部ＡＰＩを複数回実行する場合を考える。その際の実行回数を、「ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数」と呼称する。（クライアントサービス４００または端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する回数を「ＡＰＩ実行回数」、ＡＰＩによって実行されたリソースサービス４０１が外部ＡＰＩを実行する回数を「外部ＡＰＩ実行回数」とした。）

上記の実施例２では、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が１回の場合で説明している。実施例２で設定した外部ＡＰＩ実行回数制限値「２００」を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が「２」以上の場合にも適応すると、たとえＡＰＩ実行回数が「２００」でも外部ＡＰＩ実行回数が「４００」以上になってしまい、外部ＡＰＩ実行回数制限値「２００」を越えてしまう。その結果、外部サービスシステム１２０が利用できなくなり、そのペナルティによりその外部ＡＰＩを利用しているＡＰＩも使えなくなり、サービスシステム１４０が停止してしまう。そのため、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を考慮してＡＰＩ実行回数制限値を設定する必要がある。

パターン１については、図８のフローチャートを用いてＡＰＩ実行回数制限値を設定する方法について説明する。また、クライアントサービス４００によって実行されたＡＰＩ１、ＡＰＩ２、ＡＰＩ３がリソースサービス４０１を実行し、そのリソースサービス４０１によって外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３を実行されているものとする。そのイメージ図を図１０（ｂ）に示す。

図８のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図８のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。

ステップＳ６０１は実施例２のパターン１と同様の処理で得られるので、詳細の説明は省略する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を２回、ＡＰＩ２の場合は外部ＡＰＩ２を１回、ＡＰＩ３の場合は外部ＡＰＩ３を２回実行しているものとする。それに関する情報を、ＡＰＩ実行制御モジュール３０１が取得し、管理する。

ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、ＡＰＩ実行制御モジュール３０１によって外部ＡＰＩ実行回数制限値「６００」が取得され、実施例２のパターン１のときと同様の情報（表９）がＡＰＩ実行制御モジュール３０１で管理されるものとする。

ステップＳ８０１において、ＡＰＩ実行回数１回あたりの外部ＡＰＩ実行回数の合計値を取得し、管理する。今回、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が、ＡＰＩ１とＡＰＩ２とＡＰＩ３で合計５回なので、ＡＰＩ実行制御モジュール３０１は表１２のように、このＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値を管理するものとする。

ステップＳ８０２において、外部ＡＰＩ実行回数制限値を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割り、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値を算出する。具体的には、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値（表１０）を、ステップＳ８０１で取得したＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値（表１２）で割ることで、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値を算出する。その際、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値をそのまま外部ＡＰＩ実行回数制限値として利用する方法のみならず、外部ＡＰＩ実行回数制限値を超えて外部ＡＰＩが実行されても外部ＡＰＩが実行できる値を設定する方法でもよい。今回は後者の方法を採用し、外部ＡＰＩ実行回数制限値の７５％である「４５０」を外部ＡＰＩ実行回数制限値とする。「４５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「５」で割り、得られた値「９０」がＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値となる。その結果、ＡＰＩ実行制御モジュール３０１において、表１３のように外部ＡＰＩ実行回数制限値が設定されたものとする。

Ｓ７０３において、サービスシステムが予め保有しているＡＰＩ実行回数制限値と外部ＡＰＩ実行回数制限値と、を比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。今回は、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ実行回数制限値（表１）とＳ８０２において算出した外部ＡＰＩ実行回数制限値（表１３）とを比較し、その結果を表１４に示す。

表１で示したＡＰＩ実行回数制限値とステップＳ８０２の計算結果とを比較したのは、ＤＢサーバー３０５の制限値を考慮した上での比較である。ＤＢサーバー３０５を使用しない場合であれば、ステップＳ８０２で得られたＡＰＩ実行回数制限値「９０」を各ＡＰＩのＡＰＩ実行回数制限値として設定してもよい。後述の実施例でも同様である。

次にパターン２の場合に、ＡＰＩ実行回数制限値を設定する方法を、図７のフローチャートと図１１（ｂ）のイメージ図を用いて説明する。今回は一例として、クライアントサービス４００がＡＰＩを実行する場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。

図７のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図７のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。

ステップＳ６０１は実施例３のパターン１と同様の処理で同様の結果が得られるので、説明は省略する。

ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回はＡＰＩ実行制御モジュール３０１が、外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３の外部ＡＰＩ実行回数制限値を取得し、其々が「２００」であるものとする。実施例２のパターン２のときと同様の情報（表１１）がＡＰＩ実行制御モジュール３０１で管理されるものとする。

ステップＳ７０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を取得し、管理する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を２回、ＡＰＩ２の場合は外部ＡＰＩ２を１回、ＡＰＩ３の場合は外部ＡＰＩ３を２回実行しているので、表１５のようにＡＰＩ実行制御モジュール３０１がＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を管理する。

ステップＳ７０２において、外部ＡＰＩｎの外部ＡＰＩ実行回数制限値を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割り、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩｎの外部ＡＰＩ実行回数制限値を算出する。その際、これまでの実施例と同様に、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値（表１０）の７５％である「１５０」をＡＰＩ実行回数制限値とする。ＡＰＩ１（ｎ＝１）の場合は、ステップＳ６０２で得られた外部ＡＰＩ１の外部ＡＰＩ実行回数制限値「１５０」を、ステップＳ７０１で得られたＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数「２」で割り、得られた値「７５」が、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩを実行する回数１回に対するＡＰＩ１のＡＰＩ実行回数制限値となる。

ステップＳ７０３は、実施例３のパターン１と同様の処理なので、説明は省略する。ＡＰＩ１の場合、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ１のＡＰＩ実行回数制限値「１００」と、ステップＳ７０２で設定したＡＰＩ１のＡＰＩ実行回数制限値「７５」とを比較し、より小さい値である「７５」をＡＰＩ１の新たなＡＰＩ実行回数制限値として設定する。

ステップＳ７０４において、全ＡＰＩのＡＰＩ実行回数制限値を設定したかどうかを判定する。全てのＡＰＩ実行回数制限値が設定されたと判断されるまで、ステップＳ７０２〜ステップＳ７０４の工程は繰り返される。表１６に、実施例３のパターン２で設定したＡＰＩ実行回数制限値を示す。

実施例３で設定したＡＰＩ実行回数制限値（表１４、表１６）を仮想サーバー３０２の台数で割ることで、各仮想サーバー３０２の新たなＡＰＩ実行回数制限値が得られる。仮想サーバー３０２が２台あるものとすると、実施例３のパターン１の場合、表１４のＡＰＩ実行回数制限値を仮想サーバー３０２の台数である「２」で割り、得られた値「４５」が仮想サーバー１台当たりのＡＰＩ１とＡＰＩ３のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。

実施例２のパターン２の場合、表１６のＡＰＩ実行回数制限値を仮想サーバー３０２の台数「２」で割り、得られた値「３７」が仮想サーバー１台当たりのＡＰＩ１とＡＰＩ３のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。ただし、ＡＰＩ１とＡＰＩ３の各仮想サーバーにおけるＡＰＩ実行回数制限値を算出した際の余りは、任意の仮想サーバー３０２に割り振っても良い。

また、ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。

実施例３より、仮想サーバー３０２にオートスケーリング機能が実装されているかどうかに関わらず、ＡＰＩによって実行されたリソースサービス４０１が外部ＡＰＩを実行する回数に応じて、各仮想サーバーにおけるＡＰＩ実行回数制限値を設定できる。この方法により、外部ＡＰＩがＡＰＩの機能によって実行され、外部ＡＰＩ実行回数制限値によってリソースサービス４０１や外部Ｗｅｂサービス４０２が停止しないように制御することができる。また、外部ＡＰＩ実行回数制限値が変更になった場合にも、自動でＡＰＩ実行回数制限値を変更し、適切な値を維持することができる。

［実施例４］
実施例４では、ＡＰＩによって実行されたリソースサービス４０１が複数の外部ＡＰＩを実行する場合にＡＰＩ実行回数制限値を設定する過程を説明する。

パターン１について、図８のフローチャートを用いてＡＰＩ実行回数制限値を設定する方法について説明する。また、クライアントサービス４００によって実行されたＡＰＩ１とＡＰＩ２がリソースサービス４０１を実行し、そのリソースサービス４０１が外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３を実行しているものとする。そのイメージ図を図１０（ｃ）に示す。今回は一例として、クライアントサービス４００がＡＰＩを実行する場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。

図８のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図８のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。

ステップＳ６０１において、各ＡＰＩによって実行されたＷｅｂサービスが呼び出し実行する外部ＡＰＩの情報を取得する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を１回、外部ＡＰＩ２を２回、ＡＰＩ２の場合は外部ＡＰＩ３を２回実行している。それに関する情報をＡＰＩ実行制御モジュール３０１が取得し、管理しているものとする。

ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、外部ＡＰＩ実行回数制限値「６００」がＡＰＩ実行制御モジュール３０１によって取得され、実施例２のパターン１のときと同様の情報（表９）がＡＰＩ実行制御モジュール３０１で管理されるものとする。

ステップＳ８０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値を取得し、管理する。今回、ＡＰＩ１とＡＰＩ２によって実行されたリソースサービス４０１が合計で５回外部ＡＰＩを実行するので、ＡＰＩ実行制御モジュール３０１は表１７のように管理するものとする。

ステップＳ８０２は、実施例３のパターン１と同様の処理で同様の結果（表１３）が得られる。次に、Ｓ７０３において、サービスシステムが予め保有しているＡＰＩ実行回数制限値と外部ＡＰＩ実行回数制限値と、を比較して、より小さい値を新たなＡＰＩ実行回数制限値として設定する。今回は、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ実行回数制限値（表１）とＳ８０２で算出した外部ＡＰＩの実行回数制限値とを比較して、より小さい値をＡＰＩの新たな実行回数制限値として設定する。比較した結果を表１８に示す。

表１で示したＡＰＩ実行回数制限値とステップＳ８０２の計算結果を比較したのは、ＤＢサーバー３０５の制限値を考慮した上での比較である。ＤＢサーバー３０５を使用しない場合であれば、ステップＳ８０２で得られた外部ＡＰＩ実行回数制限値をＡＰＩ実行回数制限値として設定してもよい。

次にパターン２の場合にＡＰＩ実行回数制限値を設定する方法を、図９のフローチャートと図１１（ｃ）のイメージ図を用いて説明する。今回は一例として、クライアントサービス４００がＡＰＩを実行している場合を示しているが、端末１３０が実現するＷｅｂブラウザーの機能がＡＰＩを実行する場合も考えられる。

図９のフローは、仮想サーバー３０２が起動した場合や、仮想サーバー３０２がＡＰＩの実行要求をクライアントシステム１１０または端末１３０から受信した場合、または仮想サーバー３０２が定期的に実行することで開始される。図９のフローは例として、Ｓ４００においてＡＰＩの実行要求が受信されたことにより開始される場合を示している。

ステップＳ６０１は実施例４のパターン１と同様の処理で同様の結果が得られるので、説明は省略する。

ステップＳ６０２において、外部ＡＰＩ実行回数制限値を取得し、管理する。今回は、ＡＰＩ実行制御モジュール３０１が外部ＡＰＩ１、外部ＡＰＩ２、外部ＡＰＩ３の外部ＡＰＩ実行回数制限値を取得し、其々の値が「２００」であるものとする。実施例２のパターン２のときと同様の情報（表１１）がＡＰＩ実行制御モジュール３０１で管理される。

ステップＳ７０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を取得し、管理する。今回は、ＡＰＩ１によって実行されたリソースサービス４０１が外部ＡＰＩ１を１回、外部ＡＰＩ２を２回、ＡＰＩ２の場合は外部ＡＰＩ３を２回実行しているので、表１９のようにＡＰＩ実行制御モジュール３０１がＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数を管理しているものとする。

ステップＳ９０１において、各外部ＡＰＩの外部ＡＰＩ実行回数制限値を、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割り、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を算出する。今回は、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値とステップＳ７０１で取得したＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数とを用いて、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部の外部ＡＰＩ実行回数制限値を算出する。算出する際は、ステップＳ６０２において取得した外部ＡＰＩ実行回数制限値の７５％である「１５０」をＡＰＩ実行回数制限値とする。具体的に外部ＡＰＩ１の場合、ＡＰＩ１が実行したリソースサービス４０１によって１回実行されているので、ステップＳ６０２で設定した外部ＡＰＩ実行回数制限値「１５０」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ１実行回数制限値となる。また、外部ＡＰＩ２の場合は、ＡＰＩ１が実行したリソースサービス４０１によって２回実行されるので、ステップＳ６０２で設定した外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数「２」で割って得られた値「７５」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ２の外部ＡＰＩ実行回数制限値となる。表２０には、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ実行回数制限値を示し、ＡＰＩ実行制御モジュール３０１に設定されたものとする。

ステップＳ９０２において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値の中で、最小値をＡＰＩｎのＡＰＩ実行回数制限値として設定する。具体的にＡＰＩ１の場合（ｎ＝１）、ＡＰＩ１が実行したリソースサービス４０１が外部ＡＰＩ１と外部ＡＰＩ２とを実行しているので、ステップＳ９０１で算出した結果（表２０）である「１５０」と「７５」とを比較して、より小さい値である「７５」がＡＰＩ１のＡＰＩ実行回数制限値として設定される。

ステップＳ６０４は、実施例４のパターン１と同様の処理なので、説明は省略する。ＡＰＩ１の場合、ＡＰＩ実行制御モジュール３０１が保有しているＡＰＩ１のＡＰＩ実行回数制限値「１００」と、ステップＳ９０２で設定したＡＰＩ１のＡＰＩ実行回数制限値「７５」とを比較し、より小さい値である「７５」をＡＰＩ１のＡＰＩ実行回数制限値として設定する。

ステップＳ９０３において、全ＡＰＩのＡＰＩ実行回数制限値を設定したかどうかを判定する。全てのＡＰＩ実行回数制限値が設定されたと判断されるまで、ステップＳ９０２〜ステップＳ９０３の工程は繰り返される。表２１に、実施例４のパターン２で設定したＡＰＩ実行回数制限値を示す。

実施例４は、各ＡＰＩが実行したリソースサービス４０１が重複せずに外部ＡＰＩを実行する形態に関するものである。次に、各ＡＰＩが実行したリソースサービス４０１が重複して外部ＡＰＩを実行する形態でＡＰＩ実行回数制限値を設定する形態を説明する。具体的には、図１０（ｄ）や図１１（ｄ）のように、複数のＡＰＩが実行したリソースサービス４０１が一つの外部ＡＰＩを実行する形態を考える。

パターン１（図１０（ｄ））については、図１０（ｂ）や図１０（ｃ）のときと同様に、図８のフローチャートを用いてＡＰＩ実行回数制限値は設定される。また、実施例３のパターン１（図１０（ｂ））と本形態では、外部ＡＰＩ実行回数制限値とＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値とＡＰＩ数が同じである。そのため、外部ＡＰＩを重複して実行しているかどうかに関わらず、実施例３のパターン１と同様の結果（表１４）が得られる。したがって、図１０（ｄ）の場合においてＡＰＩ実行回数制限値を設定することに関する説明は省略する。

パターン２（図１１（ｄ））についても、実施例４のパターン２（図１１（ｃ））のときと同様に、図９のフローチャートを用いてＡＰＩ実行回数制限値は設定される。したがって、図１１（ｃ）のときと同様のステップに関する詳細な説明は省略し、異なる結果が得られるステップ（ステップＳ７０１、ステップＳ９０１）のみを以下で説明する。

ステップＳ７０１で、ＡＰＩ実行回数１回あたりの外部ＡＰＩ実行回数を取得し、管理する。今回は図１１（ｄ）より、ＡＰＩ実行制御モジュール３０１において表２２のようにＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数が管理される。

ステップＳ９０１において、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を算出する。今回は、ステップＳ６０２で取得した外部ＡＰＩ実行回数制限値（表１１）と、ステップＳ７０１で取得したＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数とを用いて、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を算出する。ここで、これまでの実施例と同様に、外部ＡＰＩ実行回数制限値「２００」の７５％である「１５０」を外部ＡＰＩ実行回数制限値とする。

図１１（ｄ）では、外部ＡＰＩ１はＡＰＩ１とＡＰＩ３によって実行されたリソースサービス４０１によって１回ずつ実行されているので、外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「２」で割って得られた「７５」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ１の外部ＡＰＩ実行回数制限値となる。また、外部ＡＰＩ３は、ＡＰＩ１とＡＰＩ３によって実行されたリソースサービス４０１によって１回ずつ実行されているので、外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「２」で割って得られた値「７５」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ３の外部ＡＰＩ実行回数制限値となる。外部ＡＰＩ２は、ＡＰＩ２によって実行されたリソースサービス４０１によって１回実行されているので、ステップＳ６０２で設定した外部ＡＰＩ実行回数制限値「１５０」をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数の合計値「１」で割って得られた値「１５０」が、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する外部ＡＰＩ２の外部ＡＰＩ実行回数制限値となる。表２３には、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数に対する各外部ＡＰＩの外部ＡＰＩ実行回数制限値を示し、ＡＰＩ実行制御モジュール３０１に設定されたものとする。

ステップＳ９０３において、全てのＡＰＩ実行回数制限値が設定されたと判断されるまで、ステップＳ９０２〜ステップＳ９０３の工程は繰り返され、その結果、図１１（ｄ）の形態において設定したＡＰＩ実行回数制限値は、実施例３のパターン２（表１６）と同様の結果となる。

実施例４で設定したＡＰＩ実行回数制限値（表１６）を仮想サーバー３０２の台数で割ることで、各仮想サーバー３０２のＡＰＩ実行回数制限値が得られる。

仮想サーバー３０２が２台あるものとし、実施例４で算出した結果を仮想サーバー３０２の台数である「２」で割り、得られた値が各仮想サーバー３０２でのＡＰＩ実行回数制限値となる。実施例４のパターン１（図１０（ｃ））の場合、表１８のＡＰＩ実行回数制限値を仮想サーバー３０２の台数である「２」で割り、得られた値「４５」が仮想サーバー１台当たりのＡＰＩ１のＡＰＩ実行回数制限値となり、「２５」が仮想サーバー１台当たりのＡＰＩ２のＡＰＩ実行回数制限値となる。ＡＰＩ実行回数制限値が仮想サーバー３０２の台数で割りきれない場合は、その余りを任意の仮想サーバー３０２に割り振っても良い。それ以外のパターンの場合も同様である。

ＡＰＩ実行回数制限値の決定方法はこの算出方法に限らず、不均等にＡＰＩ実行回数制限値を各仮想サーバー３０２に振り分けて、新たなＡＰＩ実行回数制限値としてもよい。不均等に割り振る際には、ＡＰＩ実行回数制限値を１回も割り振られない仮想サーバー３０２はないものとする。

実施例４より、仮想サーバー３０２にオートスケーリング機能が実装されているかどうかに関わらず、ＡＰＩによって実行されたリソースサービス４０１が複数の外部ＡＰＩを実行する場合や、複数のＡＰＩによって実行されたリソースサービス４０１が一つの外部ＡＰＩを実行する場合でも、各仮想サーバーにおけるＡＰＩ実行回数制限値を設定することができる。この方法により、外部ＡＰＩがＡＰＩの機能によって実行され、外部ＡＰＩ実行回数制限値によって外部Ｗｅｂサービス４０２が停止したり、そのペナルティによってリソースサービス４０１が停止することがないように制御できる。また、外部ＡＰＩ実行回数制限値が変更になった場合にも、自動でＡＰＩ実行回数制限値を変更し、適切な値を維持することができる。

［その他の実施例］
上記の実施例では、ＡＰＩが２〜３つ、外部ＡＰＩが３つである場合を示したが、任意のＡＰＩ数や外部ＡＰＩ数、ＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数等の場合でも本フローは成り立つ。また、実施例２〜４に記載されていない部分は、実施例１に記載されていることと同じである。

さらに実施例３〜実施例４のパターン１では、図８のフローチャートを用いてＡＰＩ実行回数制限値を算出する方法を説明した。しかし、その方法に限らず、外部ＡＰＩ実行回数制限値をＡＰＩ数で割って、各外部ＡＰＩ実行回数制限値を最初に設定することで、パターン２で示した図７や図９の方法でＡＰＩ実行回数制限値を算出することもできる。

本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１１０ クライアントシステム
１２０ 外部サービスシステム
３５０ 負荷分散装置
３００ アプリケーションモジュール
３０１ ＡＰＩ実行制御モジュール
３０２ 仮想サーバー
３０３ オートスケーリンググループ
３０４ 負荷分散モジュール
３０５ ＤＢサーバー
３１０ データ管理モジュール
４００ クライアントサービス
４０１ Ｗｅｂサービス
４０２ 外部Ｗｅｂサービス

Claims (16)

1. 夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供するサービスシステムであって、
   前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、
   仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定手段と、
   前記ＡＰＩが呼び出された場合、前記決定手段によって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御手段と、
   を有するサービスシステム。
2. 前記サービスシステムは、
   前記サービスシステムの負荷に応じて前記Ｗｅｂサービスを実現している仮想サーバーの台数を変更するオートスケーリング機能と、
   前記オートスケーリング機能により変更される前記仮想サーバーの台数を確認する確認手段と、
   をさらに有し、
   前記決定手段は、前記確認手段により確認された前記仮想サーバーの台数と前記ＡＰＩ実行回数制限値とに基づき、仮想サーバー１台の新たなＡＰＩ実行回数制限値を決定することを特徴とする請求項１に記載のサービスシステム。
3. 前記確認手段は、
   前記決定手段により決定された仮想サーバー１台のＡＰＩ実行回数制限値を更新するタイミングで、前記オートスケーリング機能により変更される前記仮想サーバーの台数を確認することを特徴とする請求項２に記載のサービスシステム。
4. 前記確認手段は、
   前記サービスシステムの負荷に応じて前記Ｗｅｂサービスを実現する新たな仮想サーバーを起動する他、前記サービスシステムのオートスケーリング機能により変更される前記仮想サーバーの台数を管理する管理手段に対し、
   前記仮想サーバーの台数を問い合わせることで前記仮想サーバーの台数を確認することを特徴とする請求項２乃至３のいずれか１項に記載のサービスシステム。
5. 前記オートスケーリング機能は、
   前記サービスシステムの負荷が一定以上に増加したことに応じて、前記仮想サーバーの台数を増加させ、前記サービスシステムの負荷が一定以下に減少したことに応じて、前記仮想サーバーの台数を減少させることを特徴とする請求項２乃至４のいずれか１項に記載のサービスシステム。
6. 前記オートスケーリング機能は、
   前記仮想サーバーの使用するリソース及びキューに格納されたジョブの少なくとも一つに基づいて、前記サービスシステムの負荷を判定し、前記仮想サーバーの台数を変更することを特徴とする請求項２乃至５のいずれか１項に記載のサービスシステム。
7. 前記Ｗｅｂサービスは前記ＡＰＩを複数公開しており、
   前記決定手段は、前記Ｗｅｂサービスを実現している仮想サーバーの台数と夫々のＡＰＩ毎に定められた前記ＡＰＩ実行回数制限値とに基づき、仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至６のいずれか１つに記載のサービスシステム。
8. 前記制御手段は、
   特定のＡＰＩが呼び出された場合、前記決定手段により決定された前記特定のＡＰＩに対応するＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの実行をエラーとして処理することを特徴とする請求項７に記載のサービスシステム。
9. 前記Ｗｅｂサービスは、
   認証および認可に関するデータ処理を実行する認証・認可サービス、帳票データを作成するデータ処理を実行する帳票サービス、印刷データを作成するデータ処理を実行する印刷サービス、およびプリンターの情報を管理しレポートデータを作成するデータ処理を実行するプリンター管理サービスのうちいずれか１つであることを特徴とする請求項１乃至８のいずれか１つに記載のサービスシステム。
10. 前記決定手段は、
    前記ＡＰＩ実行回数制限値を前記仮想サーバーの台数で割ることで仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至９のいずれか一つに記載のサービスシステム。
11. 前記決定手段は、
    前記ＡＰＩ実行回数制限値に達するまで夫々の前記仮想サーバーに対し任意の数を割り当てていくことで前記仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至９のいずれか一つに記載のサービスシステム。
12. 前記サービスシステムは、前記サービスシステムとは異なる外部サービスシステムと連携する機能をさらに有し、
    前記決定手段は、
    前記Ｗｅｂサービスが、外部サービスシステムにおいて提供されている外部Ｗｅｂサービスによって公開された外部ＡＰＩを実行する回数を制限するために利用される外部ＡＰＩ実行回数制限値と、前記ＡＰＩ実行回数制限値と、前記仮想サーバーの台数とに基づいて、
    前記仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１乃至１１のいずれか一つに記載のサービスシステム。
13. 前記決定手段は、
    前記外部ＡＰＩ実行回数制限値をＡＰＩ実行回数１回当たりの外部ＡＰＩ実行回数で割ることにより、新たな外部ＡＰＩ実行回数制限値を算出し、
    前記新たな外部ＡＰＩ実行回数制限値と、前記ＡＰＩ実行回数制限値と、前記仮想サーバーの台数とに基づいて、
    前記仮想サーバー１台のＡＰＩ実行回数制限値を決定することを特徴とする請求項１２に記載のサービスシステム。
14. 前記ＡＰＩ実行回数は、
    前記ＡＰＩが前記クライアントサービスによって実行される回数であり、
    前記外部ＡＰＩ実行回数は、前記外部ＡＰＩが前記Ｗｅｂサービスによって実行される回数であることを特徴とする請求項１３に記載のサービスシステム。
15. 夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供する制御方法であって、
    前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、
    仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定ステップと、
    前記ＡＰＩが呼び出された場合、前記決定ステップによって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御ステップと、
    を有する制御方法。
16. 夫々の仮想サーバー上にＷｅｂサービスを実現し、公開されたＡＰＩがクライアントサービスに呼び出されたことに応じて前記Ｗｅｂサービスを提供する制御方法を実現するためのプログラムであって、
    前記Ｗｅｂサービスを実現している仮想サーバーの台数と前記ＡＰＩが実行される回数を制限するために利用されるＡＰＩ実行回数制限値とに基づき、
    仮想サーバー１台のＡＰＩ実行回数制限値を決定する決定ステップと、
    前記ＡＰＩが呼び出された場合、前記決定ステップによって決定されたＡＰＩ実行回数制限値に基づき、前記Ｗｅｂサービスを提供する、または前記ＡＰＩの呼び出しをエラーとして処理する制御ステップと、
    を有する制御方法を実現するためのプログラム。

Images