JP2017016408A - Ａｐｉ提供システムおよびａｐｉ提供方法 - Google Patents

Abstract

【課題】APIリクエストの輻輳制御において、APIリクエスト要求元の優先順位を反映させる。【解決手段】API提供システム１は、APIリクエストの要求者または／および要求元システムを判別して当該APIリクエストを認証するAPIメッセージ受付部１１と、各APIリクエストの要求者または／および要求元システムを示す固有の識別子と優先度との組合せを保持する要求元別優先度登録テーブル１５１と、このAPIリクエストの要求者または／および要求元システムに基づき、前記要求元別優先度登録テーブル１５１を参照してAPIリクエストの優先度を判定する優先度判定部１５と、判定した優先度に応じてAPIリクエストを優先的に処理するか否かを決定する制御対象決定部１６とを備える。【選択図】図１

Description

本発明は、API（Application Program Interface）リクエストの輻輳に対して利用制限を行うAPI提供システムおよびAPI提供方法に関する。

近年のネットワークの高速化とウェブブラウザの普及により、インターネットを経由して所定の処理を提供するAPIが広く普及している。このAPIは、インターネット経由で或るサーバ上にあるプログラムや管理データなどを、他のサーバや端末などから呼び出して利用するための手順やデータ形式などを定めた規約であり、コンピュータプログラムの機能を呼び出して利用するための規約であるAPI（Application Program Interface）に擬えて呼ばれている。

開発者は、APIを活用することによって、容易にエンドユーザ向けアプリケーションを開発することができる。またAPIの提供者は、このAPIを活用したアプリケーションにより、自社のサービスやコンテンツをエンドユーザ等に訴求することができる。例えば通信キャリアは、ネットワーク機能やオペレーション機能をAPIとしてエンドユーザ向けアプリケーションの開発を促し、自社の通信サービスをエンドユーザ等に訴求することができる。

このAPIの呼び出しにより、ネットワーク機能やオペレーション機能に輻輳が発生するおそれがある。例えば、ネットワークの障害情報を通知するようなサービスをAPIで利用可能としたとき、大規模災害の発生時に障害情報を問い合わせるAPIリクエストが一時的に大量に発生し、このAPIに係るネットワーク機能やオペレーション機能に輻輳が発生する場合である。このような輻輳に対処するには、例えば非特許文献１に記載の技術がある。非特許文献１には、無線ＬＡＮ（Local Area Network）アドミッション制御技術と併用して、受付を許可したトラヒック等の監視を行い、規定値を超えたトラヒックに対して流量制御を実施する技術が記載されている。これにより、通信中のVoIP（Voice over Internet Protocol）やVideo等のトラヒックに対する通信品質劣化を防止し、安定した通信を提供することが可能となる。

NTTアクセスサービスシステム研究所、「トラヒック流量制御技術」、[online]、[平成２７年６月１９日検索]、インターネット<URL:http://www.ansl.ntt.co.jp/j/times/051/01/06.html>

非特許文献１の方式は、WebRTC（Web Real-Time Communication）などの一般的なサービス機能の公開を前提としており、一時的な要求の急増に伴う輻輳時においては、予めAPIのゲートウェイに設定された閾値または外部から随時設定された閾値にて、当該処理を行う機能に割り当てるリソース制御や新規要求に対する一律なトラヒック制御が行われる。
しかし、B2B2C（Business to Business to Consumer）モデルなどビジネスモデルの多様化に伴い、新たな提供形態、例えば自社利用する機能の空きリソースを利用した他社への機能提供などが想定される。このような場合、輻輳時における個々の要求に対する優先制御は行われていないため、内部利用と外部利用が一律で先着順に規制されてしまうケースが発生する。また、通常は公平に利用していた各アプリからのAPIリクエストに対し、輻輳時はサービスグレードに従って優先度を変更したいなどの要求が発生した際に、柔軟に対応することが出来ず、先着順に規制されてしまう。
本発明は、前記した問題を解決し、APIリクエストの輻輳制御において、APIリクエストの要求元の優先順位を反映させることを課題とする。

前記課題を解決するため、請求項１に記載の発明では、APIリクエストの要求元を判別して当該APIリクエストを認証するメッセージ受付部と、各APIリクエストの要求元を示す固有の識別子と優先度との組合せを保持する要求元別優先度登録テーブルと、前記メッセージ受付部が判別した当該APIリクエストの要求元に基づき、前記要求元別優先度登録テーブルを参照して当該APIリクエストの優先度を判定する優先度判定部と、前記優先度判定部が判定した優先度に応じて当該APIリクエストを優先的に処理するか否かを決定する制御対象決定部と、を備えることを特徴とするAPI提供システムとした。

このようにすることで、APIリクエストの輻輳制御において、APIリクエストの要求元の優先順位を反映させることができる。

請求項２に記載の発明では、アプリケーション毎の使用量を記憶して輻輳を判定する輻輳判定部を備えており、前記制御対象決定部は、前記輻輳判定部が輻輳発生を判定した際に、前記優先度判定部が判定した優先度に応じて前記APIリクエストを破棄するか否かを決定する、ことを特徴とする請求項１に記載のAPI提供システムとした。

このようにすることで、APIリクエストの要求元であるアプリケーション毎に輻輳を判定し、輻輳発生時にAPIリクエストの要求元の優先順位を反映させることができる。

請求項３に記載の発明では、前記優先度判定部は、前記輻輳判定部より輻輳発生の通知を受け取ることによって、その機能を活性化させる、ことを特徴とする請求項２に記載のAPI提供システムとした。

このようにすることで、非輻輳時のオーバヘッドなしに輻輳時の優先制御を実現できる。

請求項４に記載の発明では、前記制御対象決定部は、輻輳発生時に各前記APIリクエストをバッファリングし、前記APIリクエストの優先度に応じて、当該APIリクエストを優先キューと非優先キューのいずれかに格納して処理順序を動的に変更する、ことを特徴とする請求項２または請求項３に記載のAPI提供システムとした。

このようにすることで、所定期間ごとのAPIリクエストの処理順序に、このAPIリクエストの要求元の優先順位を反映させることができる。

請求項５に記載の発明では、前記制御対象決定部は、輻輳発生時に、所定時間に亘って当該APIリクエストをバッファリングして前記優先キューと前記非優先キューのいずれかに格納した後、前記優先キューのリクエストを処理し、更に前記非優先キューのリクエストを処理する、ことを特徴とする請求項４に記載のAPI提供システムとした。

このようにすることで、優先されるAPIリクエストを規制なしに実行したのちに、非優先のAPIリクエストをソート順に実行することができる。

請求項６に記載の発明では、前記要求元別優先度登録テーブルは、各APIリクエストの要求元のパラメータと優先度との組み合わせを保持する、ことを特徴とする請求項１ないし請求項５のいずれか１項に記載のAPI提供システムとした。

このようにすることで、各APIリクエストの優先度を判定することができる。

請求項７に記載の発明では、前記要求元のパラメータは、要求元システムの事業者、当該事業者の住所、アプリケーション、エンドユーザ、当該エンドユーザの住所、リクエスト内容のうちいずれかを含む、ことを特徴とする請求項６に記載のAPI提供システムとした。

このようにすることで、列挙したパラメータによる要求元の優先度付けをすることができる。

請求項８に記載の発明では、メッセージ受付部により、APIリクエストの要求元を判別すると共に前記APIリクエストを認証し、優先度判定部により、前記APIリクエストの要求元に基づいて当該APIリクエストの優先度を判定し、制御対象決定部により、前記APIリクエストの優先度に応じて当該APIリクエストを優先的に処理するか否かを決定する、ことを特徴とするAPI提供方法とした。

このようにすることで、APIリクエストの輻輳制御において、APIリクエストの要求元の優先順位を反映させることができる。

本発明によれば、APIリクエストの輻輳制御において、APIリクエストの要求元の優先順位を反映させることが可能となる。

本実施形態におけるAPI提供システムの構成図である。 本実施形態における要求元別優先度登録テーブルを示す図である。 本実施形態における輻輳時の制御を示すシーケンス図である。 本実施形態における輻輳時の制御を示す概念図である。 本実施形態の第１動作例を示す概念図である。 本実施形態の第２動作例を示す概念図である。 変形例の動作例を示す概念図である。 比較例のAPI提供システムの構成図である。 比較例の輻輳時の制御を示すシーケンス図である。 比較例の優先制御処理を示すフローチャートである。 比較例の第１動作例を示す概念図である。 比較例の第２動作例を示す概念図である。

次に、比較例と本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。

《比較例のAPI提供システム》
図８は、比較例のAPI提供システム１Ａの構成図である。
API提供システム１Ａは、APIメッセージ受付部１１、処理依頼部１２、API使用量測定部１３とアプリケーション毎使用量記憶部１３１、輻輳判定部１４とアプリケーション毎保証値記憶部１４１、使用量調整部１７、処理実行部１８を含んで構成される。API提供システム１Ａは、API要求部２−１，２−２で動作するアプリケーションからのAPIリクエストを受け付けて処理すると共に、アプリケーション毎に使用量を記憶することで輻輳を検知し、制御を行うものである。以下、API要求部２−１，２−２などを特に区別しない場合、単にAPI要求部２と記載する場合がある。
APIメッセージ受付部１１は、APIリクエストの要求元を判別して、このAPIリクエストの認証を認可する。この認証の認可は、セキュリティやユーザ管理の観点から行われるものである。

処理依頼部１２は、APIリクエストについて、いずれのアプリケーションが発行したものであるかを判別し、アプリケーション毎使用量記憶部１３１を参照して輻輳を判断する。更に処理依頼部１２は、APIリクエストを処理実行部１８に送信して、処理を実行させる。
API使用量測定部１３は、このAPIリクエストの使用量を測定して、このAPIリクエストの使用量をアプリケーション毎使用量記憶部１３１に格納する。

輻輳判定部１４は、アプリケーション毎使用量記憶部１３１を介してAPIリクエストが引き渡されると、このAPIリクエストの輻輳を判定する。輻輳判定部１４は、輻輳の判定にあたり、このAPIリクエストに係るアプリケーションの保証値をアプリケーション毎保証値記憶部１４１から取得し、この保証値に基づいて輻輳を判定するための閾値を算出する。

使用量調整部１７は、APIリクエストの輻輳時に、これらAPIリクエストの一部を破棄して使用量を調整する。これにより、API提供システム１は、APIリクエストの処理動作を継続することができる。
処理実行部１８は、APIリクエストを受信すると、このAPIリクエストに含まれる引数に従って処理を実行し、処理結果を応答する。これにより、API要求部２−１，２−２は、APIリクエストの処理結果を得ることができる。

図９は、比較例の輻輳時の制御を示すシーケンス図である。
最初、API要求部２は、APIリクエストを発行し、このAPIリクエストをAPIメッセージ受付部１１に送信する（シーケンスＱ４０）。APIメッセージ受付部１１は、このAPIリクエストの認証を認可すると、処理依頼部１２に引き渡す（シーケンスＱ４１）。

処理依頼部１２は、引き渡されたAPIリクエストを発行したアプリケーションを判別し、このAPIリクエストをAPI使用量測定部１３に引き渡す（シーケンスＱ４２）と共にアプリケーション毎使用量記憶部１３１に格納する（シーケンスＱ４３）。
API使用量測定部１３は、処理依頼部１２からAPIリクエストが引き渡されると、各アプリケーションがAPIリクエストを使用した量を測定し、測定した使用量をアプリケーション毎使用量記憶部１３１に格納する（シーケンスＱ４４）。これにより、API提供システム１は、このAPIリクエストを発行したアプリケーションの使用量を測定して、所定の閾値を超過したか否かを判断することができる。

輻輳判定部１４は、アプリケーション毎使用量記憶部１３１を介してAPIリクエストが引き渡されると（シーケンスＱ４５）、このAPIリクエストを発行したアプリケーションの使用量が閾値を超えているか否かにより、このAPIリクエストの輻輳を判定する（シーケンスＱ４６）。
使用量調整部１７は、輻輳判定部１４からAPIリクエストが引き渡されると（シーケンスＱ４７）、アプリケーション毎使用量記憶部１３１を参照して（シーケンスＱ４７）、このAPIリクエストを破棄するか否かを判断する。ここで使用量調整部１７は、このAPIリクエストを破棄せずに処理依頼部１２に戻している（シーケンスＱ４９）。処理依頼部１２は、このAPIリクエストを処理実行部１８に送信する（シーケンスＱ５０）。処理実行部１８は、APIリクエストを受信すると、このAPIリクエストに含まれる引数に従って処理を実行する。

図１０は、比較例の優先制御処理を示すフローチャートである。
優先制御処理が開始すると、輻輳判定部１４は、APIリクエストの使用量が閾値（保証値）に達したか否かを判定する（ステップＳ６０）。使用量調整部１７は、このAPIリクエストが輻輳していないならば（ステップＳ６１→Ｎｏ）、このAPIリクエストを処理し（ステップＳ６２）、ステップＳ６０の閾値判定に戻る。これにより、複数のAPIリクエストを次々に受け付けて処理することができる。

使用量調整部１７は、このAPIリクエストが輻輳したならば（ステップＳ６１→Ｙｅｓ）、APIリクエストの使用量を取得し（ステップＳ６３）、所定値を超過しているか否かを判断する（ステップＳ６４）。使用量調整部１７は、このAPIリクエストの使用量が所定値を超過していないと判定したならば（ステップＳ６４→Ｎｏ）、このAPIリクエストを処理して（ステップＳ６６）、ステップＳ６０の処理に戻る。使用量調整部１７は、このAPIリクエストの使用量が所定値を超過していると判定したならば（ステップＳ６４→Ｙｅｓ）、このAPIリクエストを破棄して（ステップＳ６５）、ステップＳ６０の処理に戻る。

図１１は、比較例の第１動作例を示す概念図である。
比較例のAPI提供システム１Ａは、API要求部２−１〜２−６からのAPIリクエストをイネーブラに引き渡して処理する。ここでイネーブラとは、例えば図８の処理実行部１８に対応するものである。API要求部２−５，２−６は、このイネーブラの稼働者と同一の者が稼働しているため、「内部」と記載している。API要求部２−１〜２−４は、このイネーブラの稼働者とは異なる者が稼働させているため、「外部」と記載している。API要求部２−１〜２−６には、それぞれアプリケーション＃１〜＃６が動作しており、APIリクエストを発行する。なお図面ではアプリケーションのことを単に「アプリ」と記載している。

比較例では、輻輳時における個々の要求に対する優先制御は行われていない。そのため内部であるAPI要求部２−５，２−６のAPIリクエストと外部であるAPI要求部２−１〜２−４のAPIリクエストが一律で先着順に規制される。よって内部であるAPI要求部２−５，２−６のAPIリクエストが外部に先立って破棄されるおそれがある。図１１では、内部であるAPI要求部２−６のAPIリクエストが外部に先立って破棄されている。

図１２は、比較例の第２動作例を示す概念図である。
比較例のAPI提供システム１Ａは、API要求部２−１〜２−４からのAPIリクエストをイネーブラに引き渡してベストエフォートで処理する。API要求部２−１〜２−４は、図１１と同様に、いずれも「外部」の利用者である。API要求部２−１〜２−３は、非プレミアム（通常）のサービスグレード（優先度）が付与され、API要求部２−４は、通常より高いプレミアムのサービスグレードが付与されている。API要求部２−１〜２−４には、それぞれアプリケーション＃１〜＃４が動作しており、APIリクエストを発行する。

各アプリケーション＃１〜＃４からのAPIリクエストは、通常時（非輻輳時）には公平に利用され、輻輳時には各アプリケーション＃１〜＃４のサービスグレードに従ってAPIリクエストの優先度が設定されることが望ましい。しかし、図１２で示したように、比較例のAPIリクエストは先着順に規制されるので、プレミアムのサービスグレードを有するAPI要求部２−４のAPIリクエストが規制される場合がある。

《本実施形態のAPI提供システム》
本発明ではAPIを利用する際に、セキュリティやユーザ管理の観点から行われる認証認可の仕組みを利用し、要求者または要求元システムを示す固有の識別子と優先度との組合せをテーブルとして保持することで、輻輳時における要求単位の優先制御を実現している。

本実施形態では、比較例のAPI提供システム１Ａに本発明を組み込む場合を説明している。本実施形態では、輻輳発生の判定に従って、以降発生したAPIリクエストに対する要求元の優先度を識別し、このAPIリクエストを破棄するか否かと規制順序とを任意に指定可能とすることを達成している。

図１は、API提供システム１の構成図である。
API提供システム１は、比較例のAPI提供システム１Ａと同様な構成に加えて、APIリクエスト毎の優先度を判定する優先度判定部１５、優先度判定部１５が優先度を判定する為に必要な要求元別優先度を参照・登録可能とする要求元別優先度登録テーブル１５１（図２参照）、優先度の判定結果に基づく制御対象或いは制御順序を決定する制御対象決定部１６、APIリクエストをバッファリングする要求格納部１６１、優先キュー１６２および非優先キュー１６３、これらの各部の判定結果に従った処理を実現する処理実行部１８を備えている。

優先度判定部１５は、APIリクエストの認証・認可で用いられた固有の識別子を参照し、要求元の事業者やアプリケーションやエンドユーザの各識別子と優先度の組み合わせが格納された要求元別優先度登録テーブル１５１を参照して、APIリクエストの優先度を決定している。オペレータは、要求元別優先度登録テーブル１５１を動的に変更することで、APIリクエストの優先度の動的な変更が可能である。
制御対象決定部１６は、APIリクエストを時間ｔに亘ってバッファリングし、バッファリングされたAPIリクエストを優先度順かつ先着順にて優先キュー１６２または非優先キュー１６３に格納することで優先制御を実現する。更に制御対象決定部１６は、輻輳発生時に、優先度に応じてAPIリクエストを破棄するか否かを決定する。
これにより、API提供システム１の内部利用と外部利用が混合するケースにおいて、物理的或いは論理的に分割して実現することを必須とせず、分割損のないリソースの最大活用を可能とし、かつ、輻輳制御によるAPI提供システム１の安定的な稼働を実現した。

図２は、本実施形態における要求元別優先度登録テーブル１５１を示す図である。
要求元別優先度登録テーブル１５１は、要求元別優先度を参照および登録可能とするテーブルである。事業者テーブル１５１１および、アプリケーションテーブル１５１２、エンドユーザテーブル１５１３は、要求元別優先度登録テーブル１５１と相互に組み合わせて使用されるテーブルである。
要求元別優先度登録テーブル１５１は、項目としてｐｔ欄１５１ａ、事業者欄１５１ｂ、アプリケーション欄１５１ｃ、エンドユーザ欄１５１ｄ、優先度欄１５１ｅを含んで構成される。

ｐｔ欄１５１ａは、事業者欄１５１ｂからエンドユーザ欄１５１ｄまでの組み合わせパターンを示す欄である。
事業者欄１５１ｂは、このAPIリクエストを発行したAPI要求部２を稼働している事業者の名称や住所などの属性を示す欄である。この事業者欄１５１ｂをキーとして事業者テーブル１５１１を参照することで、この事業者に係る優先度を特定可能である。
なお、事業者テーブル１５１１は、項目として事業者欄１５１ｆと優先度欄１５１ｇとを含み、事業者と優先度との対応関係を示している。ここで事業者“Ｍ”は、例えば内部利用であり優先される。事業者“Ｎ”は、例えば外部利用であり優先されない。

アプリケーション欄１５１ｃは、このAPIリクエストを発行したAPI要求部２を稼働しているエンドユーザ向けアプリケーションの名称や属性を示す欄である。アプリケーション欄１５１ｃをキーとしてアプリケーションテーブル１５１２を参照することでこのエンドユーザ向けアプリケーションに係る優先度を特定可能である。
なおアプリケーションテーブル１５１２は、項目としてアプリケーション欄１５１ｈと優先度欄１５１ｉとを含み、アプリケーションと優先度との対応関係を示している。ここでアプリケーション“α”は優先され、アプリケーション“β”は非優先である。

エンドユーザ欄１５１ｄは、このAPIリクエストを発行したAPI要求部２を操作しているエンドユーザの名称や住所などの属性を示す欄である。優先度判定部１５は、エンドユーザ欄１５１ｄをキーとしてエンドユーザテーブル１５１３を参照することで、このエンドユーザに係る優先度を特定可能である。

なお、エンドユーザテーブル１５１３は、項目としてエンドユーザ欄１５１ｊと優先度欄１５１ｋとを含み、エンドユーザと優先度との対応関係を示している。ここでエンドユーザ“Ａ”は、例えばプレミアムユーザであり優先される。エンドユーザ“Ｂ”は、例えば非プレミアムユーザであり優先されない。
優先度欄１５１ｅは、事業者欄１５１ｂからエンドユーザ欄１５１ｄまでの組み合わせパターンに対応するAPIリクエストの優先度を示している。

図３は、本実施形態における輻輳時の制御を示すシーケンス図である。
シーケンスＱ１０〜Ｑ１６までの処理は、比較例のシーケンスＱ４１〜Ｑ４６（図９参照）までの処理と同様である。
シーケンスＱ１６の後、輻輳判定部１４は、優先度判定部１５に対して輻輳発生を通知し、APIリクエストの優先度の判定を依頼する（シーケンスＱ１７）。優先度判定部１５は、輻輳判定部１４から輻輳発生の通知を受け取ることによって、その機能を活性化させ、これを契機に通常時は公平に先着順で行っていた処理順序（優先度）を動的に変更する。

優先度判定部１５は、APIメッセージ受付部１１に依頼して（シーケンスＱ１８）、APIリクエストに係る認証情報を取得する（シーケンスＱ１９）。優先度判定部１５は、この認証情報に基づき要求元別優先度登録テーブル１５１の優先度を確認して（シーケンスＱ２０）、APIリクエストに係る優先度の応答を受けて（シーケンスＱ２１）、このAPIリクエストの優先度を決定している。優先度判定部１５は更に、制御対象決定部１６にAPIリクエストを引き渡して制御対象の決定を依頼する（シーケンスＱ２２）。

制御対象決定部１６は、時間ｔに亘ってAPIリクエストを要求格納部１６１にバッファリングする（シーケンスＱ２３）。その後制御対象決定部１６は、要求格納部１６１にバッファリングされた各APIリクエストを取り出し（シーケンスＱ２４）、判定された優先度に従って、優先キュー１６２または非優先キュー１６３（図１参照）に格納する。所定期間内に発生したAPIリクエストを横並びで比較して優先制御を行う為に、輻輳発生以降のAPIリクエストは、要求格納部１６１にバッファリングされて処理を保留される。この保留動作は、バッファリング可能な容量設計にも依存するが、API提供システム１にて計測される時間tを基準として繰返し行われる。時間tの間のAPIリクエスト全体を対象に優先度が判定され、優先キュー１６２または非優先キュー１６３へ格納される。要求格納部１６１に格納されたAPIリクエストのうち、優先度が低い一部のAPIリクエストは破棄される。

制御対象決定部１６は、優先キュー１６２（図１参照）から取り出したAPIリクエストを規制なしに処理実行部１８に処理依頼する（シーケンスＱ２５）。これにより、API提供システム１は、APIリクエストの輻輳制御において、各APIリクエストの要求元の優先順位を反映させることができる。
制御対象決定部１６は、非優先キュー１６３（図１参照）から取り出したAPIリクエストの処理依頼を、使用量調整部１７に行う（シーケンスＱ２６）。以降、シーケンスＱ２７〜Ｑ２９の処理は、比較例のシーケンスＱ４８〜Ｑ５０（図９参照）の処理と同様である。これにより、非優先キュー１６３のAPIリクエストは規制される。

図４は、本実施形態における輻輳時の制御を示す概念図である。
この概念図は、輻輳発生時のAPI提供システム１の動作を示している。なお、この図ではAPI提供システム１の内部構成の一部のみを示し、その他を省略している。
要求元であるAPI要求部２は、APIリクエストをAPI提供システム１に送信して、処理結果であるAPIリプライを受信する。API提供システム１は、APIメッセージ受付部１１により、このAPIリクエストを受け付ける。
API提供システム１は、APIリクエストの輻輳を判断すると、制御対象決定部１６によりAPIリクエストのバッファリングを開始する（ステップＳ１０）。これ以降、時間ｔに亘り、APIリクエストは要求格納部１６１にバッファリングされる。

時間ｔが終了する頃に、制御対象決定部１６は、バッファリングしたAPIリクエストを優先順位付けソートし（ステップＳ１１）、優先キュー１６２と非優先キュー１６３とに格納する。これによりAPIリクエストは、処理実行部１８に引き渡されて処理され、処理結果を含んだAPIリプライがAPI要求部２に送信される。制御対象決定部１６は、これ以外のAPIリクエストを破棄し（ステップＳ１２）、次の周期の制御を開始する。
次の周期におけるステップＳ１３〜Ｓ１５の処理は、ステップＳ１０〜Ｓ１２の処理と同様である。API提供システム１は、輻輳が終了するまで、これらの処理を繰り返す。

図５は、本実施形態の第１動作例を示す概念図である。
API提供システム１は、API要求部２−１〜２−６からのAPIリクエストをイネーブラに引き渡して処理する。API要求部２−５，２−６は、このイネーブラの稼働者と同一の者が稼働させているため、「内部」と記載している。API要求部２−１〜２−４は、このイネーブラの稼働者とは異なる者が稼働させているため、「外部」と記載している。API要求部２−１〜２−６には、それぞれアプリケーション＃１〜＃６が動作しており、APIリクエストを発行する。

輻輳時における個々の要求に対する優先制御により、内部のAPI要求部２−５，２−６が発行したAPIリクエストは、外部のAPI要求部２−１〜２−４が発行したAPIリクエストよりも優先して処理される。この図５では、制御対象決定部１６が、外部のAPI要求部２−４が発行したAPIリクエストを破棄し，内部のAPI要求部２−５，２−６が発行したAPIリクエストを優先してイネーブラに引き渡すことを示している。

図６は、本実施形態の第２動作例を示す概念図である。
API提供システム１は、API要求部２−１〜２−６からのAPIリクエストをイネーブラに引き渡して処理する。API要求部２−１〜２−４は、図５と同様に、いずれも「外部」の要求元であり、API要求部２−５，２−６は「内部」の要求元である。API要求部２−１〜２−３は、非プレミアム（通常）のサービスグレード（優先度）が付与され、API要求部２−４は、通常より高いプレミアムのサービスグレードが付与されている。API要求部２−１〜２−６には、それぞれアプリケーション＃１〜＃６が動作しており、APIリクエストを発行する。

各アプリケーション＃１〜＃６からのAPIリクエストは、通常（非輻輳時）には公平に利用される。アプリケーション＃１〜＃６のサービスグレードに従ってAPIリクエストの優先度が設定される。プレミアムのサービスグレードを有するAPI要求部２−４が発行したAPIリクエストは、API要求部２−１〜２−３が発行したAPIリクエストよりも優先して処理される。この図６では、制御対象決定部１６がプレミアムのサービスグレードを有するAPI要求部２−４が発行したAPIリクエストを優先してイネーブラに引き渡し、代わりにAPI要求部２−３が発行したAPIリクエストを破棄することを示している。

本実施形態によれば、APIリクエスト毎の帯域利用状況を見て、輻輳要因と思われる利用帯域が大きいAPIリクエストや、短時間での利用頻度が高いAPIリクエストなどを任意に指定して規制を実行し、エンドユーザのランク、例えばプレミアムや非プレミアムなどに連動して規制対象を変更することが可能となる。よってAPI提供システム１は、自身のリソースを最大に活用して、安定的な運用を行うことができる。

《変形例のAPI提供システム》
図７は、変形例の動作例を示す概念図である。
API提供システム１Ｂは、API要求部２−１〜２−３からのAPIリクエストをイネーブラに引き渡して処理する。API要求部２−１〜２−３には、それぞれアプリケーション＃１〜＃３が動作しており、APIリクエストを発行する。API提供システム１Ｂは、これらAPIリクエストの要求頻度を測定するリクエストカウンタ１９を備えている。

図７に示すように、API要求部２−１の最低保証帯域はＹ₁、要求帯域はＲ₁、利用帯域はＸ₁である。API要求部２−２の最低保証帯域はＹ₂、要求帯域はＲ₂、利用帯域はＸ₂であり、API要求部２−３の最低保証帯域はＹ₃、要求帯域はＲ₃、利用帯域はＸ₃である。このうちAPI要求部２−２の要求帯域Ｒ₂が、著しく最低保証帯域Ｙ₂を超えて輻輳しているので、API提供システム１Ｂは、API要求部２−２のAPIリクエストの輻輳が解消されるまで利用帯域Ｘ₂を規制する。つまり、API提供システム１Ｂは、要求帯域を最低保証帯域で除算した値が最も高いアプリケーションから規制を実行する。API要求部２−１〜２−３の要求帯域は、リクエストカウンタ１９が測定したAPIリクエストの要求頻度に基づいて算出される。

規制量については、イネーブラ許容帯域をＺとしたとき、このリソースを最大活用する方法と、輻輳を早期に沈静化させる方法とがある。
リソースを最大活用するには、イネーブラ許容帯域Ｚから他のAPI要求部２−１，２−３の利用帯域Ｒ₁とＲ₃とを減算し、その残りを全てAPI要求部２−２の利用帯域に割り当てるとよい。これによりAPI提供システム１Ｂは、イネーブラ許容帯域Ｚを全て提供することができる。
また一方で輻輳を早期に沈静化させるには、API要求部２−２の利用帯域Ｘ₂を、最低保証帯域Ｙ₂と一致させるとよい。これによりAPI提供システム１Ｂは、充分な余裕を持ってAPIリクエストを処理することができる。

API提供システム１においてテナントを設定し、テナント毎に輻輳制御を行うことで、内部利用と外部利用を分けた運用を行うことは可能である。しかしながら、テナント分割を行うと、リソースの分割損や輻輳などの準正常系状態の発生に応じてリソースの割当を柔軟に変えるには、調整や設定に所定の作業を要する。
本発明では、こうしたテナント分割による煩雑な運用を省き、輻輳時においても安定的かつリソースの最大活用が可能となる仕組みを、トラヒック制御機能と連動した要求元別の優先度を判定することで効率的に実現した。

（変形例）
本実施の形態に係るAPI提供システム１は、前記したような処理を実行させるプログラムによって実現することができ、そのプログラムをコンピュータによる読み取り可能な記録媒体（ＣＤ−ＲＯＭ等）に記憶して提供することが可能である。また、そのプログラムを、インターネット等のネットワークを通して提供することも可能である。
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｄ）のようなものがある。
（ａ） 要求元のパラメータは、要求元システムの事業者、アプリケーション、エンドユーザに限られず、事業者の住所、エンドユーザの住所、リクエスト内容などを含んでもよい。
（ｂ） 例えば、ネットワーク回線の申込を受け付ける機能をAPIにて提供し、かつリクエスト内容として新規申込と申込変更が可能な時、ネットワーク回線提供日時が確定している申込の変更を優先して受け付けるように構成してもよい。
（ｃ） 輻輳判定部１４は、輻輳を検知しなかったならば、優先度判定部１５を活性化せずに、APIリクエストを使用量調整部１７に直接に送信してもよい。これにより非輻輳時には、優先度判定によるオーバヘッドを防ぐことができる。
（ｄ） APIリクエストの種類は、SOAP（Simple Object Access Protocol）、REST（REpresentational State Transfer）のいずれでもよく、またはそれ以外であってもよく、限定されない。

１，１Ａ，１Ｂ API提供システム
１１ APIメッセージ受付部 （メッセージ受付部の一例）
１２ 処理依頼部
１３ API使用量測定部
１３１ アプリケーション毎使用量記憶部
１４ 輻輳判定部
１４１ アプリケーション毎保証値記憶部
１５ 優先度判定部
１５１ 要求元別優先度登録テーブル
１６ 制御対象決定部
１６１ 要求格納部
１６２ 優先キュー
１６３ 非優先キュー
１７ 使用量調整部
１８ 処理実行部
１９ リクエストカウンタ
２，２−１〜２−６ API要求部

Claims (8)

1. APIリクエストの要求元を判別して当該APIリクエストを認証するメッセージ受付部と、
   各APIリクエストの要求元を示す固有の識別子と優先度との組合せを保持する要求元別優先度登録テーブルと、
   前記メッセージ受付部が判別した当該APIリクエストの要求元に基づき、前記要求元別優先度登録テーブルを参照して当該APIリクエストの優先度を判定する優先度判定部と、
   前記優先度判定部が判定した優先度に応じて当該APIリクエストを優先的に処理するか否かを決定する制御対象決定部と、
   を備えることを特徴とするAPI提供システム。
2. アプリケーション毎の使用量を記憶して輻輳を判定する輻輳判定部を備えており、
   前記制御対象決定部は、前記輻輳判定部が輻輳発生を判定した際に、前記優先度判定部が判定した優先度に応じて前記APIリクエストを破棄するか否かを決定する、
   ことを特徴とする請求項１に記載のAPI提供システム。
3. 前記優先度判定部は、前記輻輳判定部より輻輳発生の通知を受け取ることによって、その機能を活性化させる、
   ことを特徴とする請求項２に記載のAPI提供システム。
4. 前記制御対象決定部は、輻輳発生時に各前記APIリクエストをバッファリングし、前記APIリクエストの優先度に応じて、当該APIリクエストを優先キューと非優先キューのいずれかに格納して処理順序を動的に変更する、
   ことを特徴とする請求項２または請求項３に記載のAPI提供システム。
5. 前記制御対象決定部は、輻輳発生時に、所定時間に亘って当該APIリクエストをバッファリングして前記優先キューと前記非優先キューのいずれかに格納した後、前記優先キューのリクエストを処理し、更に前記非優先キューのリクエストを処理する、
   ことを特徴とする請求項４に記載のAPI提供システム。
6. 前記要求元別優先度登録テーブルは、各APIリクエストの要求元のパラメータと優先度との組み合わせを保持する、
   ことを特徴とする請求項１ないし請求項５のいずれか１項に記載のAPI提供システム。
7. 前記要求元のパラメータは、要求元システムの事業者、当該事業者の住所、アプリケーション、エンドユーザ、当該エンドユーザの住所、リクエスト内容のうちいずれかを含む、
   ことを特徴とする請求項６に記載のAPI提供システム。
8. メッセージ受付部により、APIリクエストの要求元を判別すると共に前記APIリクエストを認証し、
   優先度判定部により、前記APIリクエストの要求元に基づいて当該APIリクエストの優先度を判定し、
   制御対象決定部により、前記APIリクエストの優先度に応じて当該APIリクエストを優先的に処理するか否かを決定する、
   ことを特徴とするAPI提供方法。

Images