(57)【要約】【課題】各アプリケーションに対してバランスのとれた流量配分を実施すること。【解決手段】流量配分装置１は、アプリ使用量のうちの保証される流量を示す各アプリケーションのアプリ保証値を、システム限界値の範囲内になるように計算するアプリ保証値計算部２２と、各アプリケーションのアプリ使用量を測定して取得したシステム使用量がシステム限界値を超過したときにシステム輻輳と判定する輻輳判定部３３と、システム輻輳と判定されたときに、アプリ使用量のうちのアプリ保証値からの超過分を対象としてアクセス制御を行う使用量調整部３４と、を有する。【選択図】図４
2015153314.tif 000002
【特許請求の範囲】
【請求項１】
各アプリケーションが使用する流量を示すアプリ使用量の総和であるシステム使用量と比較されるシステム限界値が格納されるパラメータ記憶部と、
前記アプリ使用量のうちの保証される流量を示す各アプリケーションのアプリ保証値を、前記システム限界値の範囲内になるように計算するアプリ保証値計算部と、
各アプリケーションの前記アプリ使用量を測定して取得した前記システム使用量が前記システム限界値を超過したときにシステム輻輳と判定する輻輳判定部と、
前記システム輻輳と判定されたときに、前記アプリ使用量のうちの前記アプリ保証値からの超過分を対象としてアクセス制御を行う使用量調整部と、を有することを特徴とする
流量配分装置。
【請求項２】
前記パラメータ記憶部には、さらに、各アプリケーションからの呼び出し命令を実行するイネーブラごとに、そのイネーブラごとに呼び出すアプリケーションの前記アプリ使用量の総和であるイネーブラ使用量と比較されるイネーブラ限界値が格納されており、
前記アプリ保証値計算部は、前記システム限界値の範囲内になり、かつ、前記イネーブラ限界値の範囲内になるように、各前記アプリ保証値を計算し、
前記輻輳判定部は、各アプリケーションの前記アプリ使用量を測定して取得した前記イネーブラ使用量が前記イネーブラ限界値を超過したときにイネーブラ輻輳と判定し、
前記使用量調整部は、前記イネーブラ輻輳と判定されたときにも、前記アプリ使用量のうちの前記アプリ保証値からの超過分を対象として前記アクセス制御を行うことを特徴とする
請求項１に記載の流量配分装置。
【請求項３】
前記輻輳判定部は、輻輳の判定に使用する各アプリケーションの前記アプリ使用量を測定する代わりに、測定した前記アプリ使用量と、その前記アプリ保証値とのうちの大きい方の値を、輻輳の判定に使用することを特徴とする
請求項１または請求項２に記載の流量配分装置。
【請求項４】
前記使用量調整部は、前記アプリ使用量のうちの前記アプリ保証値からの超過分に比例して、各前記アクセス制御を行う前記アプリ使用量の減少量を決定することを特徴とする
請求項１または請求項２に記載の流量配分装置。
【請求項５】
流量配分装置は、パラメータ記憶部と、アプリ保証値計算部と、輻輳判定部と、使用量調整部とを有しており、
前記パラメータ記憶部には、各アプリケーションが使用する流量を示すアプリ使用量の総和であるシステム使用量と比較されるシステム限界値が格納されており、
前記アプリ保証値計算部は、前記アプリ使用量のうちの保証される流量を示す各アプリケーションのアプリ保証値を、前記システム限界値の範囲内になるように計算し、
前記輻輳判定部は、各アプリケーションの前記アプリ使用量を測定して取得した前記システム使用量が前記システム限界値を超過したときにシステム輻輳と判定し、
前記使用量調整部は、前記システム輻輳と判定されたときに、前記アプリ使用量のうちの前記アプリ保証値からの超過分を対象としてアクセス制御を行うことを特徴とする
流量配分方法。
【請求項６】
請求項５に記載の流量配分方法を、コンピュータである前記流量配分装置に実行させるための流量配分プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、流量配分装置、流量配分方法、および、流量配分プログラムの技術に関する。
【背景技術】
【０００２】
非特許文献１には、送信側と受信側との通信経路の途中に位置するアクセスポイントが、通信経路に過剰に流れるトラヒックに対してパケット廃棄などの流量制御を実施することで、他の通信中のトラヒックに対する通信品質劣化を防止し、安定した通信を提供するシステムが提案されている。
ここで、流量制御の度合いを決定するために、あらかじめ通信量の上限値を定めておく。そして、その上限値からの超過分を過剰トラヒックとみなして廃棄対象とする。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ＮＴＴアクセスサービスシステム研究所、"6.トラヒック流量制御技術"、［online］、［平成26年2月10日検索］、インターネット〈URL：http://www.ansl.ntt.co.jp/j/times/051/01/06.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
アプリケーションを実行する装置が、外部に機能を提供するイネーブラ（Enabler）に対して、その機能を呼び出すためのＡＰＩ呼び出しを行う形態が普及している。これにより、アプリケーションの開発者は、自身でイネーブラが提供する機能を実装しなくて済むため、開発コストを削減することができる。
このようなＡＰＩ呼び出しを介するシステム連携を行う場合でも、ベストエフォートではなく通信帯域の保証などの品質保証を要求したサービスの提供が求められることもある。
【０００５】
アプリケーションに提供する通信品質を単に上げるだけならば、イネーブラの台数を増加させたり、使用させるアプリケーションの数を減らしたりするなどして、アプリケーション１つあたりに提供するリソースを増やせばいい。しかし、設備増強によるコストの増加や、アプリケーション減少による収入減少などを考えると、通信事業者にとっては、コストパフォーマンスが悪くなるだけである。
【０００６】
一方、非特許文献１のシステムのように、単に上限値からの超過分を廃棄対象とするだけでは、リソースの閑散期であっても過剰にパケット廃棄してしまい、設備の利用効率が低下してしまう。
よって、アプリケーションに提供する通信品質と、イネーブラなどの設備にかけるコストのバランスが取れるような流量制御が求められる。
【０００７】
そこで、本発明は、各アプリケーションに対してバランスのとれた流量配分を実施することを、主な課題とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するために、本発明は、各アプリケーションが使用する流量を示すアプリ使用量の総和であるシステム使用量と比較されるシステム限界値が格納されるパラメータ記憶部と、前記アプリ使用量のうちの保証される流量を示す各アプリケーションのアプリ保証値を、前記システム限界値の範囲内になるように計算するアプリ保証値計算部と、各アプリケーションの前記アプリ使用量を測定して取得した前記システム使用量が前記システム限界値を超過したときにシステム輻輳と判定する輻輳判定部と、前記システム輻輳と判定されたときに、前記アプリ使用量のうちの前記アプリ保証値からの超過分を対象としてアクセス制御を行う使用量調整部と、を有することを特徴とする。
【０００９】
これにより、システム輻輳が発生するまではアクセス制御が行われず、かつ、システム輻輳が発生したときはアプリ保証値の範囲内で適切なアクセス制御が行われるので、各アプリケーションに対してバランスのとれた流量配分を実施することができる。
【００１０】
本発明は、前記パラメータ記憶部には、さらに、各アプリケーションからの呼び出し命令を実行するイネーブラごとに、そのイネーブラごとに呼び出すアプリケーションの前記アプリ使用量の総和であるイネーブラ使用量と比較されるイネーブラ限界値が格納されており、前記アプリ保証値計算部が、前記システム限界値の範囲内になり、かつ、前記イネーブラ限界値の範囲内になるように、各前記アプリ保証値を計算し、前記輻輳判定部が、各アプリケーションの前記アプリ使用量を測定して取得した前記イネーブラ使用量が前記イネーブラ限界値を超過したときにイネーブラ輻輳と判定し、前記使用量調整部が、前記イネーブラ輻輳と判定されたときにも、前記アプリ使用量のうちの前記アプリ保証値からの超過分を対象として前記アクセス制御を行うことを特徴とする。
【００１１】
これにより、イネーブラの性能を保護しつつ、各アプリケーションに対してバランスのとれた流量配分を実施することができる。
【００１２】
本発明は、前記輻輳判定部が、輻輳の判定に使用する各アプリケーションの前記アプリ使用量を測定する代わりに、測定した前記アプリ使用量と、その前記アプリ保証値とのうちの大きい方の値を、輻輳の判定に使用することを特徴とする。
【００１３】
これにより、現在はアプリ使用量が少ないが、今後にアプリ使用量が増加する場合でも、アプリ保証値分のアプリ使用量を保証することができる。
【００１４】
本発明は、前記使用量調整部が、前記アプリ使用量のうちの前記アプリ保証値からの超過分に比例して、各前記アクセス制御を行う前記アプリ使用量の減少量を決定することを特徴とする。
【００１５】
これにより、アプリ使用量の超過分の偏りが平滑化されることで、各アプリケーションに対してバランスよく流量を配分できる。
【発明の効果】
【００１６】
本発明によれば、各アプリケーションに対してバランスのとれた流量配分を実施することができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に関する流量配分システムを示す構成図である。図１（ａ）は、流量配分システムのＡＰＩ処理の流れを示す。図１（ｂ）は、図１（ａ）に対して、流量制御パラメータを付加した図である。
【図２】本発明の一実施形態に関するシステム限界値に着目した流量制御処理を示す説明図である。図２（ａ）は、流量制御前の状態を示す。図２（ｂ）は、図２（ａ）から流量制御を行うことにより、システム使用量がシステム限界値の範囲内に収まった状態を示す。図２（ｃ）は、図２（ａ）から流量制御を行うことにより、今後の流量増加予定分も考慮しつつ、システム使用量がシステム限界値の範囲内に収まった状態を示す。
【図３】本発明の一実施形態に関するイネーブラ限界値に着目した流量制御処理を示す説明図である。図３（ａ）は、流量制御前の状態を示す。図３（ｂ）は、図３（ａ）から流量制御を行うことにより、イネーブラ使用量がイネーブラ限界値の範囲内に収まった状態を示す。
【図４】本発明の一実施形態に関する流量配分装置を示す構成図である。
【図５】本発明の一実施形態に関する時間経過にともなう流量変化と流量制御の内容を示す説明図である。図５（ａ）は、イネーブラ限界値に収める制御例を示す。図５（ｂ）は、システム限界値およびイネーブラ限界値に収める制御例を示す。図５（ｃ）は、今後の流量増加予定分も考慮しつつ、イネーブラ限界値に収める制御例を示す。
【発明を実施するための形態】
【００１８】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００１９】
図１（ａ）は、流量配分システムのＡＰＩ処理の流れを示す。流量配分システムは、アプリ実行装置８ａ〜８ｃと、流量配分装置１と、イネーブラ提供装置７ａ，７ｂとを含めて構成される。
これらの流量配分システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００２０】
アプリ実行装置８ａ〜８ｃは、アプリケーションを実行する装置であり、そのアプリケーションの実行中にイネーブラ提供装置７ａ，７ｂが提供する機能を呼び出すための各ＡＰＩを呼び出す。図１（ａ）では、ＡＰＩ呼出の流れを破線矢印で示し、矢印の元が呼出元を示し、矢印の先が呼出先を示す。
イネーブラ提供装置７ａ，７ｂは、機能を提供する実体であり、バックエンドシステムとも呼ばれる。例えば、イネーブラ提供装置７ａは、セキュリティ機能およびＳＭＳ（Short Message Service）機能を提供し、イネーブラ提供装置７ｂは、クラウド制御機能を提供する。
【００２１】
流量配分装置１は、各イネーブラ提供装置７ａ，７ｂの機能を束ねて、ＡＰＩとして各アプリ実行装置８ａ〜８ｃに提供する。つまり、流量配分装置１は、以下に示すように、アプリ実行装置８ａ〜８ｃからの各ＡＰＩの呼出を、イネーブラ提供装置７ａ，７ｂに割り振る。
１つめのＡＰＩ呼出は、アプリ実行装置８ａからイネーブラ提供装置７ａへと中継される。
２つめのＡＰＩ呼出は、アプリ実行装置８ｂからイネーブラ提供装置７ａ，７ｂへと中継される。つまり、１つのＡＰＩ呼出が、流量配分装置１内で２つに分岐する。
３つめのＡＰＩ呼出は、アプリ実行装置８ｃからイネーブラ提供装置７ｂへと中継される。
【００２２】
図１（ｂ）は、図１（ａ）に対して、流量制御パラメータを付加した図である。流量配分装置１は、流量配分システムのＡＰＩ処理に伴って発生する処理の流量を管理するための各流量制御パラメータ（AU[m]、AG[m]、EU[n]、EL[n]、SU、SL）を管理する。
【００２３】
AU(Application Use)[m]とは、アプリ使用量であり、[]内の添え字は、アプリ実行装置８ａ〜８ｃごとの（または、アプリ実行装置８ａ〜８ｃが実行する各アプリケーションごとの）ＩＤである。ここで、m=1〜Mであり、Mは流量配分システム内のアプリ実行装置８ａ〜８ｃの総数（例えば、M=3）である。なお、アプリ使用量とは、例えば、各アプリ実行装置８ａ〜８ｃから送信される信号流量として、ＴＰＳ（Transaction Per Second）や同時接続数、データの帯域幅などで規定される。
AG(Application Guarantee)[m]とは、アプリ保証値であり、[]内の添え字はAU[m]のmと同じである。アプリ保証値とは、各アプリ実行装置８ａ〜８ｃに対して、最低限保証する（データ破棄などのアクセス制御をしない）アプリ使用量を示す。AU[m]の値は、例えば、10[TPS]である。
【００２４】
EU(Enabler Use)[n]とは、イネーブラ使用量であり、[]内の添え字は、イネーブラ提供装置７ａ，７ｂごとの（または、イネーブラ提供装置７ａ，７ｂが実行する各イネーブラごとの）ＩＤである。ここで、n=1〜Nであり、Nは流量配分システム内のイネーブラ提供装置７ａ，７ｂの総数（例えば、N=2）である。なお、イネーブラ使用量とは、各イネーブラごとに呼び出される（収容される）ＡＰＩ呼出のアプリ使用量の総和である。
EL(Enabler Limit)[n]とは、イネーブラ限界値であり、[]内の添え字はEU[n]のnと同じである。イネーブラ限界値とは、各イネーブラ提供装置７ａ，７ｂが提供するイネーブラ使用量の限界値を示す。EL[n]は、大量のイネーブラ使用量から各イネーブラ提供装置７ａ，７ｂを保護するために用いられる。
【００２５】
SU(System Use)とは、システム使用量であり、流量配分装置１の装置単位（または、流量配分装置１が複数台存在するときには、それらの流量配分装置１をまとめたシステム単位）での、呼び出される（収容される）ＡＰＩ呼出のアプリ使用量の総和である。
SL(System Limit)とは、システム限界値であり、各流量配分装置１が提供するシステム使用量の限界値を示す。SLは、大量のシステム使用量から流量配分装置１を保護するために用いられる。
【００２６】
以下、各パラメータ間の関係式を列挙する。
システム使用量は、アプリ使用量の総和である。
「SU=ΣAU[m],m=1〜M」…（第１式）
または、システム使用量は、現在のアプリ使用量がアプリ保証値より小さい（余裕がある）ときには、アプリ使用量の代わりにアプリ保証値を用いて総和を計算してもよい。
「SU=Σmax(AU[m],AG[m]),m=1〜M」…（第２式）
なお、max(A,B)とは、AとBとのうちの最大の値を採用する関数である。
【００２７】
イネーブラ使用量は、そのイネーブラに収容されるアプリ使用量の総和である。
「EU[n]=ΣAU[i],n=1〜N,i=イネーブラnに収容されるアプリID」…（第３式）
または、第２式と同様に、アプリ使用量の代わりにアプリ保証値を用いて総和を計算してもよい。
「EU[n]=Σmax(AU[i],AG[i]),n=1〜N,i=イネーブラnに収容されるアプリID」…（第４式）
【００２８】
各アプリ保証値は、大量のAPIリクエスト信号から、流量配分装置１やイネーブラ提供装置７ａ，７ｂを保護するために、それらの限界値の範囲内で設定される。つまり、以下の（第５式）と（第６式）との両方を満たすように、各AG[m]が設定される。
「ΣAG[m]<SL,m=1〜M」…（第５式）
「ΣAG[i]<EL[n],n=1〜N,i=イネーブラnに収容されるアプリID」…（第６式）
または、（第５式）および（第６式）のいずれかを満たすように、各AG[m]が設定されてもよい。
【００２９】
輻輳判定式は、使用量が限界値を超えたときに、輻輳ありと判定する式である。
「if(SU>SL) then システムに輻輳あり」…（第７式）
「if(EU[n]>EL[n]) then イネーブラnに輻輳あり」…（第８式）
なお、「if(X) then Y else Z」とは、条件式Xを満たすときには処理Yを実行し、条件式Xを満たさないには処理Zを実行する条件分岐式である。
【００３０】
輻輳判定式において輻輳ありと判定されたときのアクセス制御量は、アプリ保証値を超えない程度に、決定される。
「S[m]=max(AU[m]-AG[m],0),if(S[m]==0) then D[m]=0 else D[m]=0〜S[m]」…（第９式）
ここで、S[m]は、アプリケーションmの使用量の超過分であり、D[m]=アプリケーションmのアクセス制御量（減少分）である。さらに、第９式の「D[m]=0〜S[m]」を決定する式として、超過分に比例してアクセス制御量を決定する式を挙げる。
「D[m]=S[m]*(S[m]/ΣS[i]),i=1〜M」…（第１０式）
または、第１０式の代わりに、最大の超過分に該当するアプリケーションmだけを対象として、輻輳の超過分を解消するだけアクセス制御してもよい。
【００３１】
図２は、システム限界値に着目した流量制御処理を示す説明図である。
図２（ａ）は、流量制御前の状態を示す。
アプリケーションm=1,3の２つは、AU[m]>AG[m]なので、超過分S[m]が発生している（S[m]>0）状態である。アプリケーションm=2は、AU[m]<AG[m]なので、超過分S[m]は発生していない。ここで、システム使用量SUがシステム限界値SLを超えてしまっているため、第７式で「システムに輻輳あり」と判定される。
【００３２】
図２（ｂ）は、図２（ａ）から流量制御を行うことにより、システム使用量がシステム限界値の範囲内に収まった状態を示す。
アプリケーションm=1,3は、アプリ保証値からの超過分があるので（S[1]>0, S[3]>0）、第９式により、アクセス制御の対象となる（D[1]>0,D[3]>0）。
アプリケーションm=2は、アプリ保証値からの超過分が無いため（S[2]=0）、第９式により、今回のアクセス制御の対象外である（D[2]=0）。
これにより、アクセス制御後は、第７式でも輻輳ありとは判定されなくなり、システムの輻輳は解消される。
【００３３】
図２（ｃ）は、図２（ａ）から流量制御を行うことにより、今後の流量増加予定分も考慮しつつ、システム使用量がシステム限界値の範囲内に収まった状態を示す。図２（ｂ）ではシステム使用量の計算に第１式を用いていたが、図２（ｃ）ではシステム使用量の計算に第２式を用いる点が異なる。
これにより、今後増加する予定のAU[2]の増加分を踏まえて、前もってシステム使用量を見積もるため、図２（ｂ）と比べて、アクセス制御の回数を抑制できる。
【００３４】
図３は、イネーブラ限界値EL[2]に着目した流量制御処理を示す説明図である。
図３（ａ）は、流量制御前の状態を示す。イネーブラn=2（図１のイネーブラ提供装置７ｂ）は、２つのＡＰＩ呼出（m=2,3）を収容している。図３（ａ）でも、図２（ａ）と同様に、第８式においてイネーブラn=2の輻輳が検出される（EU[2]>EL[2]）。
図３（ｂ）は、図３（ａ）から流量制御を行うことにより、第３式または第４式で求めたイネーブラ使用量EU[2]がイネーブラ限界値EL[2]の範囲内に収まった状態を示す。なお、図２（ｂ）と同様に、第９式において、超過分が無いアプリケーションm=2ではなく、超過分があるアプリケーションm=3に対してアクセス制御が行われている（AU[3]=AU[3]-D[3]）。
【００３５】
図４は、流量配分装置１を示す構成図である。
流量配分装置１は、太線矢印で示すように、アプリ実行装置８ａ〜８ｃから受けたＡＰＩ呼出を実行し、適宜イネーブラ提供装置７ａ，７ｂを呼び出すための構成（ＡＰＩ処理受付部１１と、ＡＰＩ処理依頼部１２と、ＡＰＩ処理実行部１３）を有する。
ＡＰＩ処理受付部１１が受け付けたアプリ実行装置８ａ〜８ｃからの各ＡＰＩ呼出は、ＡＰＩ処理依頼部１２によって、各イネーブラ提供装置７ａ，７ｂへと割り当てられる。
ＡＰＩ処理実行部１３は、各イネーブラ提供装置７ａ，７ｂのイネーブラを実行させることによって、割り当てられた各ＡＰＩ呼出を処理する。
【００３６】
流量配分装置１は、細線矢印で示すように、ＡＰＩ処理依頼部１２の制御パラメータを決定し、送信するための構成（パラメータ記憶部２１と、アプリ保証値計算部２２と、アプリ保証値記憶部２３と、使用量測定部３１と、アプリ使用量記憶部３２と、輻輳判定部３３と、使用量調整部３４）を有する。
パラメータ記憶部２１には、入力装置９が受け付けた各パラメータ（EL[n]、SL）が格納される。なお、入力装置９は、データ入力をするための装置であり、例えば、キーボード、マウス、タッチパネルなどの入力手段を有する。
アプリ保証値計算部２２は、パラメータ記憶部２１から各パラメータ（EL[n]、SL）を読み取り、第５式および第６式の両方を満たすようにして、各アプリ保証値AG[m]を計算する。計算されたAG[m]は、アプリ保証値記憶部２３に格納される。
【００３７】
使用量測定部３１は、ＡＰＩ処理依頼部１２が実行する各アプリケーションのアプリ使用量AU[m]を測定するとともに、そのAU[m]から他の使用量パラメータ（第１式または第２式によって求まるSU、第３式または第４式によって求まるEU[n]）も計算する。
アプリ使用量記憶部３２には、使用量測定部３１が計算した使用量に関する各パラメータ（AU[m]、EU[n]、SU）が格納される。
【００３８】
輻輳判定部３３は、アプリ使用量記憶部３２内の各使用量のパラメータ（EU[n]、SU）が、パラメータ記憶部２１内の各限界値のパラメータ（EL[n]、SL）の範囲内か否かを、第７式および第８式でそれぞれ判定する。ここで、第７式および第８式でそれぞれ輻輳ありとは判定されなかった（使用量に余裕がある）状況では、アプリ使用量AU[m]をアプリ保証値AG[m]を超過して増加させてもよい。これにより、各アプリケーションは、多くのリソースを使ってＡＰＩ処理を実行できるので、処理時間の短縮化を実現でき、システムリソースの利用効率を高めることができる。
【００３９】
使用量調整部３４は、輻輳判定部３３によって輻輳ありと判断されたときに、図２，図３で説明したように、第９式および第１０式を用いて、アクセス制御を行う対象のアプリケーションを決定するとともに、決定した対象ごとの制御度合い（D[m]）を決定する。
なお、使用量をD[m]分だけ減少させる具体的な方法として、新たなＡＰＩ呼出をキューに格納して実行時間を遅らせる指示、ＡＰＩ呼出に対して実行せずにエラー応答する指示、および、ＡＰＩ呼出を破棄する指示などを、使用量調整部３４からＡＰＩ処理依頼部１２に対して通知する方法が、挙げられる。
【００４０】
図５は、時間経過にともなう流量変化と流量制御の内容を示す説明図である。
図５の各表は、ＩＤで示される各時点での各パラメータのスナップショットとなっており、ＩＤの順に時刻が経過する。
システム「SU/SL」列は、システム使用量SUを分子とし、システム限界値SLを分母とする分数表記を示す。これにより、第７式を満たしているか否かが容易にわかる。
イネーブラ列は、イネーブラn=1の列(E[1]の列)と、イネーブラn=2の列(E[2]の列)とに分かれており、各イネーブラnの列について、イネーブラ使用量EU[n]を分子とし、イネーブラ限界値EL[n]を分母とする分数表記を示す。これにより、第８式を満たしているか否かが容易にわかる。
アプリ列は、各アプリケーションmの列(A[m])の列について、アプリ使用量AU[m]を分子とし、アプリ保証値AG[m]を分母とする分数表記を示す。
【００４１】
図５（ａ）は、イネーブラ限界値に収めるための使用量調整部３４が実行する制御例を示す。
ＩＤ「11」は、ＡＰＩ呼出の前準備の段階である。パラメータ記憶部２１内にパラメータ（SL=500,EL[1]=300,EL[2]=100）が入力される。アプリ保証値計算部２２がパラメータ（AG[1]=50,AG[2]=40,AG[3]=60）を計算する。
ＩＤ「12」は、ＡＰＩ呼出が開始され、まだリソースに余裕がある段階である。各AU[m]が増加しているものの、輻輳判定は、なされていない。システムに余裕があるとき（SU＜SLのとき）には、AU[m]>AG[m]であってもアクセス制御を行わないことにより、アプリケーションの処理を高速化することができる上に、ＡＰＩ使用量を増加できる。
ＩＤ「13」は、第８式のEU[2]>EL[2]により、イネーブラn=2に輻輳ありと判定された段階である。
ＩＤ「14」は、AU[2]を70から50まで減らすようにアクセス制御を行うことで（D[2]=20）、イネーブラn=2の輻輳を解消する段階である。図３で説明したように、使用量調整部３４は、輻輳があるイネーブラが収容しているアプリケーションのうち、超過分S[m]が大きいアプリケーション（今回はm=2）をアクセス制御の対象とし、AU[m]≧AG[m]の範囲内で減少分D[m]を決定する。
【００４２】
図５（ｂ）は、システム限界値およびイネーブラ限界値に収めるための使用量調整部３４が実行する制御例を示す。
ＩＤ「21」は、ＩＤ「11」と同様に、ＡＰＩ呼出の前準備の段階である。
ＩＤ「22」は、各AU[m]がバースト的に増加してしまったため、システム輻輳（600>500）と、イネーブラ輻輳（500>300,300>100）とが同時に発生してしまった例を示す。
ＩＤ「23」では、図２で説明したように、システム輻輳を解消するために、超過分が最大の（S[1]=250）アプリケーションm=1を対象として、システム輻輳の超過分（600-500=100）だけアクセス制御する（D[1]=100）。しかし、イネーブラ輻輳は依然として発生したままである。
ＩＤ「24」では、図３で説明したように、イネーブラn=1の輻輳を解消するために、そのイネーブラが収容する２つのアプリケーションm=1,2を対象として、イネーブラ輻輳の超過分（400-300=100）だけアクセス制御する（D[1]=50,D[2]=50）。しかし、イネーブラ輻輳n=2は依然として発生したままである。
ＩＤ「25」では、図３で説明したように、イネーブラn=2の輻輳を解消するために、そのイネーブラが収容する２つのアプリケーションm=2,3を対象として、イネーブラ輻輳の超過分（250-100=150）だけアクセス制御する（D[2]=110,D[3]=40）。
これにより、各輻輳は解消される。さらに、第９式により超過分S[m]を超えて減少分D[m]を設定しないので、各アプリ使用量AU[m]は、各アプリ保証値AG[m]を下回らず、アプリケーション使用者への過剰な不便を強いることはなくなる。
なお、図５（ｂ）では、使用量調整部３４は、システム輻輳の解消、イネーブラn=1の輻輳解消、イネーブラn=2の輻輳解消という３段階を順番に行った。一方、使用量調整部３４は、これら３つの輻輳を一度に解消するように、各アクセス制御量（D[1]=150,D[2]=160, D[3]=40）を求めてもよい。
【００４３】
図５（ｃ）は、今後の流量増加予定分も考慮しつつ、イネーブラ限界値に収める制御例を示す。
ＩＤ「31」は、ＩＤ「11」と同様に、ＡＰＩ呼出の前準備の段階である。
ＩＤ「32」は、第８式のEU[2]>EL[2]により、イネーブラn=2に輻輳ありと判定された段階である。なお、第３式ではEU[2]=70+30=100であり、EL[2]の100を超過しない（第８式で輻輳なし）。一方、図５（ｃ）では第４式で計算したEU[2]=70+60=130が、EL[2]の100を超過する。つまり、AU[3]=30よりも、AG[3]=60のほうが30だけ大きい。
ＩＤ「33」は、超過分の大きいアプリ使用量AU[2]をアクセス制御する（D[2]=30）ことで、イネーブラn=2の輻輳を解消する。
【００４４】
以上説明した本実施形態では、アプリ保証値計算部２２は、イネーブラ限界値EL[n]やシステム限界値SLの範囲内で、各アプリケーションに対するアプリ保証値AG[m]を計算する（第５式，第６式）。これにより、品質とコストのバランスが取れるようになるため、イネーブラ提供装置７ａ，７ｂや流量配分装置１に対する設備投資を効率化できる。
【００４５】
また、輻輳判定部３３は、イネーブラ限界値EL[n]やシステム限界値SLを超えるまでは、アプリ保証値AG[m]を超えてアプリ使用量AU[m]を使用させるように、アクセス制御を猶予する（第７式，第８式）。これにより、イネーブラ提供装置７ａ，７ｂや流量配分装置１に対する余剰資源が遊休資源とならずに有効に使用される。
【００４６】
さらに、使用量調整部３４は、イネーブラ限界値EL[n]やシステム限界値SLを超えた使用量が発生したときには、アクセス制御の範囲（D[m]）を、アプリ使用量AU[m]の全体ではなく、アプリ保証値AG[m]からの超過分（S[m]）だけに限定する（第９式，第１０式）。これにより、イネーブラ提供装置７ａ，７ｂが複数のユーザ（複数のアプリケーション）で共用される状況下においても、あるアプリケーションの過剰使用による迷惑を、他のアプリケーションが受けなくて済む。
【符号の説明】
【００４７】
１      流量配分装置
７ａ，７ｂ  イネーブラ提供装置
８ａ〜８ｃ  アプリ実行装置
９      入力装置
１１    ＡＰＩ処理受付部
１２    ＡＰＩ処理依頼部
１３    ＡＰＩ処理実行部
２１    パラメータ記憶部
２２    アプリ保証値計算部
２３    アプリ保証値記憶部
３１    使用量測定部
３２    アプリ使用量記憶部
３３    輻輳判定部
３４    使用量調整部
【図１】
2015153314.tif 000003
【図２】
2015153314.tif 000004
【図３】
2015153314.tif 000005
【図４】
2015153314.tif 000006
【図５】
2015153314.tif 000007