(57)【要約】【課題】本発明の課題は、設定した予算の範囲内でサービスの駆動を可能とすることを目的とする。【解決手段】上記課題は、マイクロサービス基盤において、複数のロジックの連鎖構造に基づいてリソースを割り当てる優先度を決定する優先度決定部と、記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整する適応的調整部と、前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる分配部と、を有する情報処理装置により達成される。【選択図】図３
2019106037.tif 000002
【特許請求の範囲】
【請求項１】
マイクロサービス基盤において、複数のロジックの連鎖構造に基づいてリソースを割り当てる優先度を決定する優先度決定部と、
記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整する適応的調整部と、
前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる分配部と、
を有する情報処理装置。
【請求項２】
前記優先度決定部は、前記複数のロジックのうち、予め優先度が決定されたロジックから前記連鎖構造に従ってイベントの伝播方向と逆方向にあるロジックに対して、同じ優先度を設定する
ことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記分配部は、
予め定められた課金額を前記リソースに置き換えて、各ロジックに対して決定した前記優先度に基づいて分配し、
前記適応的調整部からの前記比較結果に応じて、前記余剰リソースを合計し、前記リソースが不足しているロジックへ割り当てる
ことを特徴とする請求項１又は２のいずれか一項記載の情報処理装置。
【請求項４】
前記適応的調整部は、
前記ロジックを起動する制御閾値と該ロジックへ入力されるイベントの値との差に反比例して、該ロジックの起動頻度を増減させる
ことを特徴とする請求項１乃至３のいずれか一項記載の情報処理装置。
【請求項５】
マイクロサービス基盤において、複数のロジックの連鎖構造に基づいてリソースを割り当てる優先度を決定し、
記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整し、
前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる
処理をコンピュータが行う情報処理方法。
【請求項６】
マイクロサービス基盤において、複数のロジックの連鎖構造に基づいてリソースを割り当てる優先度を決定し、
記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整し、
前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる
処理をコンピュータに実行させる情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、及び情報処理プログラムに関する。
【背景技術】
【０００２】
近年、小さなサービスをＷｅｂ  ＡＰＩ（Application  Programming  Interface）を介して各サービスを呼び出して連携することで一つのサービスとしたマイクロサービスが提供されている。このようなマイクロサービスを利用する場合には、利用状況に応じた課金がユーザになされる。
【０００３】
ユーザは予め予算を立ててサービスを利用することが多く、そのため、サービスの提供者によるサービス内における予算の配分が適切であることが望まれる。例えば、エージェントによる計算リソースの使用状況及びプロセスの実行を監視して性能データを収集し、収集した性能データの評価結果に基づいて、エージェントによるプロセス実行のためのリソースを再割り当てする技術等が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−７４０５６号公報
【特許文献２】特表２００９−５３６４８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述したようなマイクロサービスでセンサを用いた場合、センサからの信号の受信（センサイベント）に応じてパイプライン的に様々な処理が連鎖して実行される場合がある。課金額は主には処理の実行に応じて定まるため、様々な処理が連鎖的に実行されるサービスでは、課金額を容易に予測できないといった問題がある。
【０００６】
したがって、１つの側面では、設定した予算の範囲内でサービスの駆動を可能とすることを目的とする。
【課題を解決するための手段】
【０００７】
一態様によれば、マイクロサービス基盤において、複数のロジックの連鎖構造に基づいてリソースを割り当てる優先度を決定する優先度決定部と、記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整する適応的調整部と、前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる分配部と、を有する情報処理装置が提供される。
【０００８】
また、上記課題を解決するための手段として、情報処理方法、及び情報処理プログラムとすることもできる。
【発明の効果】
【０００９】
設定した予算の範囲内でサービスの駆動を可能とすることができる。
【図面の簡単な説明】
【００１０】
【図１】一般的なマイクロサービスの一例を示す図である。
【図２】情報処理装置のハードウェア構成を示す図である。
【図３】本実施例における情報処理装置の機能構成例を示す図である。
【図４】本実施例における情報処理装置による処理全体の概要を説明するためのフローチャート図である。
【図５】処理の流れを説明するための図である。
【図６】分配部による処理を説明するためのフローチャート図である。
【図７】調整部によるロジック実行制御処理を説明するためのフローチャート図である。
【図８】監視・予測部による処理を説明するためのフローチャート図である。
【図９】データ構成例を示す図である。
【図１０】重量度に基づく基本的な優先度の決定方法を説明するための図である。
【図１１】２以上のロジックの重要度に基づく優先度の決定方法を説明するための図である。
【図１２】分配部によって行われる優先度の決定処理の具体例を説明するための図である。
【図１３】リソース分配処理を説明するための図である。
【図１４】実行抑止回数の調整方法について説明するための図である。
【図１５】余剰リソースの取得方法について説明するための図である。
【図１６】余剰リソース分配処理の例を説明するための図である。
【図１７】イベント発火頻度の制御例を説明するための図である。
【図１８】本実施例におけるマイクロサービスの具体的な例を説明するための図である。
【図１９】ＳＬＡの度合別のコース例を示す図である。
【図２０】イベント発生とロジック頻度を説明するための図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態を図面に基づいて説明する。まず、センサを用いたマイクロサービスについて説明する。図１は、一般的なマイクロサービスの一例を示す図である。図１に例示するマイクロサービス９１は、センサ７と、制御部９０と、複数のロジック３とを有する。
【００１２】
センサ７は、所定の現象を感知するデバイスであり、速度センサ、ドアセンサ、人感センサ、温度センサ、湿度センサ、気圧センサ、電磁波センサ、生体情報センサ等のいずれであってもよい。制御部９０は、センサ７からのセンサ７が検知した値の受信に応じて、マイクロサービス９１を構成する複数のロジック３の実行を制御する。また、制御部９０は、センサ７からの値の受信（イベント）を監視し、統計情報を取得してもよい。複数のロジック３は、制御部９０によって実行が制御され、入力信号（入力された値）に対して所定の処理を行うソフトウェアであり、プラグインに相当する。
【００１３】
センサ７と複数のロジック３とは、制御部９０と通信可能であり、通信手段は無線又は有線のいずれであってもよい。制御部９０は、複数のロジック３の各々を制御してもよいし、実行制限等の対象のロジック３へのイベントの入力を制御するようにしてもよい。
【００１４】
上述したマイクロサービス１００は、垂直統合型ではなく、データに対する軽量な処理を部品化し、それらを組み合わせてシステムを駆動するマクロサービス基盤により実現する。
【００１５】
一般に、マイクロサービス基盤では、制御部９０の制御処理と、複数のロジック３による特定の処理とをクラウドコンピューティングによるプラットフォームの上で実行する。複数のロジック３のそれぞれは、「マイクロロジック」と呼ばれる処理単位であるが、単に「ロジック」という。そして、プラットフォームのサービサと呼ばれる利用者が、プラットフォーム提供者（「プラットフォーマ」という）にマイクロロジックの利用料に応じた料金を支払う。
【００１６】
マイクロロジックは、例えば、センサ７の値が変化した等の特定の契機（イベント）の度に起動し、入力として受け付けたセンサ７に対して所定の処理を行った上で出力値を生成する。出力値はプラットフォームがアクセス可能なデータベース（ＤＢ）に蓄積されたり、或いは、別のマイクロロジックの入力イベントとなる。
【００１７】
マイクロサービス９１では、複数のロジック３が多段及び複雑に連鎖している。このようなロジックの連鎖構造を示したグラフを「ロジック連鎖グラフ」と呼ぶ。図１のロジック連鎖グラフを用いて、イベントが連鎖的に波及した結果、課金が高額となる場合について説明する。
【００１８】
制御部９０がセンサ７から値を受信するごとに、まず、２つのロジック３にデータを示すイベントが通知される。その後、２つのロジック３のそれぞれが出力するデータは、多段及び複雑に連鎖して複数のロジック３を伝播する。ここの例では、合計５個のロジック３であるのに対してロジック３の起動回数は８回である。１秒毎に、ロジック３が８回起動した場合の１日の起動回数は、
８（起動回数）×６０秒（分当たり）×６０分（時間当たり）×２４時間（１日当たり）＝６０４８００回
となる。
【００１９】
ロジック３の駆動単価を０．０１円／起動毎とした場合、２４時間で６，０４８円となる。しかしながら、センサ７の発火頻度（センサ７がイベントを発生する頻度）が未知の場合は課金額は予測し難くいため不明となる。また、図１では、センサ７が１つの場合を示したが、複数のセンサ７を含んでもよい。この場合、課金額の予想は更に困難となる。
【００２０】
上述したような既存のマイクロサービス基盤において、利用者が利用料金の上限を設定した場合、利用料金の上限に到達すると、運用期間の途中であってもサービスが停止されるリミッタの状態となる。利用料金の上限とは、例えば、１ヶ月等の予算であり、運用期間とは、例えば、１ヶ月である。
【００２１】
マイクロサービス基盤では、処理が連鎖するという特性から、イベントの頻度等により課金額が大きく変動し易く、利用者にとって課金額を予測し難い。また、予定した運用期間の半ばでリミッタの状態となるのでは、既存のマイクロサービスは利用者にとって利用し難いサービスであると考えられる。
【００２２】
利用者のためには、利用者の予算計画に応じて、その予算の範囲内で継続的にサービスを享受できるように、省コストで駆動することが好ましい。本実施例では、駆動した結果の課金ではなく、利用者の予算の範囲内で継続的にマイクロサービスを駆動する制御を行う情報処理装置、情報処理方法、及び情報処理プログラムを提供する。
【００２３】
本実施例では、発明者による以下の着目点に基づき、マイクロサービスを駆動制御する。
・マイクロサービス基板の「駆動品質に関するＳＬＡ（Service  Level  Agreement）」を利用者の予算に応じて可変制御する。
・ＳＬＡがイベントに対してロジック３がどの程度過敏に反応するかを捉える（リアルタイム性）。
・１又は２以上の主要なロジック３に重要度を定め、ロジック連鎖グラフ上で重要度を定めた各ロジック３を起点として逆伝播することより、予算を複数のロジック３のそれぞれに分配する。
・複数のロジック３のそれぞれに対するイベント到達頻度をモデル化し、予算と予測値とを照らし合わせたうえでロジック３の起動頻度を調整する。
・各ロジック３の余剰予算を回収（取得）し、予測値に基づいて、回収（取得）した余剰予算を起動頻度が調整されているロジック３に再分配する。
【００２４】
上述した発明者による着目点を情報処理により実現することで、利用者の計画した予算内で継続したマイクロサービスの利用を可能とする。利用者に対しては、利用料の超過によるサービス停止を懸念した余剰課金を不要とし、低コスト化を行えるマイクロサービスを実現する。また、プラットフォーム提供者に対しては、予算の大きさに応じたロジック３の内容を変える等のサービス設計の変更を不要とする柔軟なスケール性を実現し、開発負担を低減する。
【００２５】
以下に、本実施例について説明する。本実施例における情報処理装置は、図２に示すようなハードウェア構成を有する。図２は、情報処理装置のハードウェア構成を示す図である。図２において、情報処理装置１００は、ＣＰＵ（Central  Processing  Unit）１１と、主記憶装置１２と、補助記憶装置１３と、入力装置１４と、表示装置１５と、通信Ｉ／Ｆ（インターフェース）１７と、ドライブ装置１８とを有し、バスＢに接続される。
【００２６】
ＣＰＵ１１は、主記憶装置１２に格納されたプログラムに従って情報処理装置１００を制御するプロセッサに相当する。主記憶装置１２には、ＲＡＭ（Random  Access  Memory）、ＲＯＭ（Read  Only  Memory）等が用いられ、ＣＰＵ１１にて実行されるプログラム、ＣＰＵ１１での処理に必要なデータ、ＣＰＵ１１での処理にて得られたデータ等を記憶又は一時保存する。
【００２７】
補助記憶装置１３には、ＨＤＤ（Hard  Disk  Drive）等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置１３に格納されているプログラムの一部が主記憶装置１２にロードされ、ＣＰＵ１１に実行されることによって、各種処理が実現される。主記憶装置１２と、補助記憶装置１３とを、記憶部１３０という。記憶部１３０に、アクセス可能な外部記憶装置等を含めてもよい。
【００２８】
入力装置１４は、マウス、キーボード等を有し、プラットフォーム提供者等が情報処理装置１００による処理に必要な各種情報を入力するために用いられる。表示装置１５は、ＣＰＵ１１の制御のもとに必要な各種情報を表示する。入力装置１４と表示装置１５とは、一体化したタッチパネル等によるユーザインタフェースであってもよい。通信Ｉ／Ｆ１７は、有線又は無線などのネットワークを通じてセンサ７との通信を行う。通信Ｉ／Ｆ１７による通信は無線又は有線に限定されるものではない。
【００２９】
情報処理装置１００によって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact  Disc  Read-Only  Memory）等の記憶媒体１９によって情報処理装置１００に提供される。
【００３０】
ドライブ装置１８は、ドライブ装置１８にセットされた記憶媒体１９（例えば、ＣＤ−ＲＯＭ等）と情報処理装置１００とのインターフェースを行う。この記憶媒体１９に格納されたプログラムは、ドライブ装置１８を介して情報処理装置１００にインストールされ、情報処理装置１００により実行可能となる。
【００３１】
尚、プログラムを格納する記憶媒体１９はＣＤ−ＲＯＭに限定されず、コンピュータが読み取り可能な、構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤ（Digital  Versatile  Disk）ディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。
【００３２】
図３は、本実施例における情報処理装置の機能構成例を示す図である。図３において、情報処理装置１００は、主に、本実施例に係る全体最適化処理部４０を有し、全体最適化処理部４０は、複数の処理部を有し、一例として、分配部４１と、監視・予測部４３と、調整部４５と、実行部４７とを有する。監視・予測部４３、調整部４５、及び実行部４７は、適用的調整部４９に相当する。
【００３３】
処理部４１、４３、４５、４７、及び４１は、情報処理装置１００にインストールされたプログラムが、情報処理装置１００のＣＰＵ１１に実行させる処理により実現される。
【００３４】
記憶部１３０には、優先度情報５１、ロジック配備情報５３、イベント到達実績ＤＢ５５、イベント到達予測ＤＢ５７、リソース割当情報５９等が記憶される。
【００３５】
全体最適化処理部４０は、本実施例におけるマイクロサービス１００１（図６）を、運用期間において、利用者の予算の範囲内でロジック３の起動を制御し、全体として継続して運用可能に制御する。全体最適化処理部４０の各処理部４１、４３、４５、４７、及び４１の概要について説明する。
【００３６】
分配部４１は、利用者が重要と考えるロジック３に基づいて、複数のロジック３のロジック全てに優先度を設定する。分配部４１は、利用者が重要と考えるロジック３のロジックＩＤと重要度とを取得する。ロジックＩＤは、ロジック３を特定する。分配部４１は、重要度とロジックＩＤとから、全てのロジック３に優先度を設定する。ロジックＩＤと優先度とが示された優先度情報５１が記憶部１３０に記憶される。
【００３７】
また、分配部４１は、ロジック配備情報５３と優先度情報５１とを参照して、ロジック３毎にリソースの割当比を決定する。分配部４１による優先度決定処理は、運用期間の初回の計算時に行われ、優先度決定部の一例に相当する。リソース割当情報５９が記憶部１３０に記憶される。
【００３８】
監視・予測部４３は、各ロジック３からイベント５の到達通知を受信してロジック３毎にイベント５の到達を監視し、運用期間におけるイベント５の到達回数の累積予測を行う。イベント５は、センサ７からの値の通知又はロジック３から次のロジック３への出力に相当する。監視・予測部４３は、各ロジック３から受信したイベント５の到達通知に応じてイベント到達実績ＤＢ５５を更新する。
【００３９】
運用期間は、利用者の予算が適用される日単位、月単位、年単位等の期間である。イベント５の到達の累積予測は、運用期間の開始日から終了日（所定単位の期間の最初の日から終了日）までイベント５の回数を累積して到達回数の推移を表す直線等であり、「到達予測モデル」ともいう。
【００４０】
また、監視・予測部４３は、イベント到達実績ＤＢ５５を参照して、運用期間のイベント５の到達回数の累積予測を行い、リソース割当情報５９に基づいて、リソースが超過する可能性を判定し、イベント５の通知を無視する実行抑止回数を決定する。監視・予測部４３は、リソースが超過する予測となったロジック３毎に実行抑止回数を示したリソース超過の判定結果を生成して、調整部４５に通知する。
【００４１】
調整部４５は、監視・予測部４３から通知されるリソース超過の判定結果に基づいて、イベント到着時に、ロジック３の実行又は抑止の実行制御を行う。また、調整部４５は、イベント到着の通知を監視・予測部４３に行う。実行部４７は、調整部４５がロジック３を起動すると判断した場合に、ロジック３を起動する。
【００４２】
分配部４１は、運用期間中に、各ロジック３から予算の余剰分（以下、「余剰リソース」という）を回収し、リソースが不足しているロジック３に分配する余剰リソース分配処理を行う。
【００４３】
図４は、本実施例における情報処理装置による処理全体の概要を説明するためのフローチャート図である。情報処理装置１００では、分配部４１が、利用者が重要と考えるロジックに基づいて、複数のロジックの全てに優先度を決定する優先度決定処理を行う（ステップＳ７１）。利用者によって、複数のロジックに対して１以上のロジックに重要度が設定されていればよく、全てのロジックに対して重要度が設定される必要はない。分配部４１によって、ロジックＩＤと優先度とが示された優先度情報５１が記憶部１３０に記憶される。
【００４４】
分配部４１は、ロジック配備情報５３を参照して、リソースを分配するリソース分配処理を行う（ステップＳ７２）。リソース分配処理は初回の場合に行われ、分配部４１は、ロジック配備情報５３と優先度情報５１とを参照し、リソース割当情報５９を作成して記憶部１３０に記憶する。
【００４５】
監視・予測部４３、調整部４５、及び実行部４７とにより、ロジックの起動頻度の適応的調整処理を行う（ステップＳ７３）。監視・予測部４３によって、ロジック毎にイベント到達の増加傾向を予測し、調整部４５によって、予測結果に応じたロジックを起動させる頻度で、実行部４７を呼び出してロジックを起動させる。
【００４６】
分配部４１は、定めた時間間隔で、各ロジックの余剰リソースを集計し、起動頻度を調整したロジックに余剰リソースを分配する余剰リソース分配処理を行う（ステップＳ７４）。これは、初回以降の計算の場合に相当し、分配部４１はリソース割当情報５９を更新する。
【００４７】
以降、ステップＳ７３及びＳ７４が予算が割り当てられた運用期間の終了日まで繰り返され、運用期間毎に、リソース割当情報５９が新たに作成される。運用期間毎に、利用者による重要度の見直しがなければ、最初に設定した優先度情報５１を優先度の規定値として利用者の識別情報等に関連付けて別途管理しておき、運用期間の始まりごとに、別途管理されている優先度情報５１を読み込んでもよい。この場合、ステップＳ７１の優先度決定処理は省略される。
【００４８】
上述したフローチャートにおける、監視・予測部４３、調整部４５、実行部４７、及び分配部４１の役割について説明する。
【００４９】
図５は、処理の流れを説明するための図である。図５において、分配部４１は、利用者が選択したロジックと、利用者が指定した重要度とに基づいて、全てのロジックの優先度を決定する。優先度情報５１が作成される。
【００５０】
利用者により実際に運用が開始されると、センサ７からの値の通知により、ロジックで発生し、後段のロジックへ通知されるイベント５が、調整部４５によって検出される。
【００５１】
調整部４５は、監視・予測部４３からリソース超過の判定結果を受信する。調整部４５は、リソース超過の判定結果で特定されるリソースが不足するロジックに対しては、実行の抑止をカウントする実行抑止カウンタが実行抑止回数に達するまで、そのロジックを実行しない制御を行う。ロジックを実行する場合には、調整部４５は、ロジックの実行を指示する実行指示を実行部４７に対して行う。実行指示は、イベント５の内容を含む。
【００５２】
また、調整部４５は、イベント５を検出すると、監視・予測部４３へイベント到達通知を送信し、イベント到達実績ＤＢ５５内の、イベント５の通知先となるロジックに対して到達回数を１インクリメントする。到達回数のインクリメントは、通知先のロジックの実行後に行ってもよい。
【００５３】
実行部４７は、調整部４５からの実行指示に応じて、イベント５の内容に基づいてイベント５の通知先のロジックを実行する。実行部４７は、ロジックの実行により得られたデータの通知先として、ロジック配備情報５３を参照して接続先のロジックを特定し、イベント５を発生する。イベント５の発生後の処理は、上述した通りである。
【００５４】
監視・予測部４３は、調整部４５からのイベント到達通知に応じて、イベント到達実績ＤＢ５６を更新する。また、監視・予測部４３は、イベント到達実績ＤＢ５６を用いて、ロジック毎の到達予測モデルを生成し、イベント到達予測ＤＢ５７に格納する。
【００５５】
そして、監視・予測部４３は、監視時間間隔で、イベント到達予測ＤＢ５７を参照し、ロジック毎に、リソースが超過するか、又は、余剰リソースがあるかを判定する。監視・予測部４３は、リソースが超過する予測となったロジック毎に、実行抑止回数を決定し、リソース超過の判定結果を生成して調整部４５に通知する。一方、余剰リソースを持つロジックが存在する場合、監視・予測部４３は、分配部４１に対して、余剰リソースを持つロジックのロジックＩＤ毎に余剰リソースの大きさを示した余剰リソース分配依頼を行う。
【００５６】
図６は、分配部による処理を説明するためのフローチャート図である。図６において、ステップ４１１３及びＳ４１１４が図４のステップＳ７１の優先度決定処理に相当し、Ｓ４１１８が図４のステップＳ７２のリソース分配処理に相当する。また、ステップＳ４１１６、Ｓ４１１７、及びＳ４１１８が図４のステップＳ７４の余剰リソース分配処理に相当する。
【００５７】
分配部４１は、計算時間間隔が経過したか否かを判断する（ステップＳ４１１１）。計算時間間隔が経過していない場合（ステップＳ４１１１のＮＯ）、分配部４１は、計算時間間隔が経過するまでステップＳ４１１１を繰り返す。計算時間間隔が経過した場合（ステップＳ４１１１のＹＥＳ）、分配部４１は、初回の計算か否かを判断する（ステップＳ４１１２）。
【００５８】
初回の計算であると判断した場合（ステップＳ４１１２のＹＥＳ）、分配部４１は、利用者が指定したロジックと重要度とに基づいて、ロジック配備情報５３を参照して、全てのロジックの優先度を決定する（ステップＳ４１１３）。優先度の決定方法については、後述する。優先度情報５１が作成され記憶部１３０に記憶される。
【００５９】
次に、分配部４１は、リソースを分配する対象ロジックとして全ロジックを設定し、利用者の予算を全リソースとする（ステップＳ４１１４）。そして、分配部４１は、対象ロジックへ分配するリソースの割当比を計算し、リソース割当情報５９を更新し（ステップＳ４１１８）、ステップＳ４１１１へと戻り、上述した同様の処理を繰り返す。
【００６０】
初回の計算ではないと判断した場合（ステップＳ４１１２のＮＯ）、分配部４１は、監視・予測部４３から余剰リソース分配依頼を受信しているか否かを判断する（ステップＳ４１１５）。余剰リソース分配依頼を受信していない場合（ステップＳ４１１５のＮＯ）、分配部４１は、ステップＳ４１１１へと戻り上述同様の処理を繰り返す。
【００６１】
余剰リソース分配依頼を受信している場合（ステップＳ４１１５のＹＥＳ）、分配部４１は、余剰リソース分配依頼を参照して、各ロジックの余剰リソースを合計して、全リソースとする（ステップＳ４１１６）。分配部４１は、余剰リソースのあるロジック以外のロジックを対象ロジックとして設定する（ステップＳ４１１７）。そして、分配部４１は、対象ロジックへ分配するリソースの割当比を計算し、リソース割当情報５９を更新して（ステップＳ４１１８）、この処理を終了する。
【００６２】
図７は、調整部によるロジック実行制御処理について説明する。図７において、調整部４５は、イベントが到達したか否かを判定する（ステップＳ４５１１）。イベントが到達していない場合（ステップＳ４５１１のＮＯ）、調整部４５は、所定間隔でステップＳ４５１１を繰り返す。
【００６３】
イベントが到達している場合（ステップＳ４５１１のＹＥＳ）、調整部４５は、監視・予測部４３にイベント到達通知を行って、イベント到達実績ＤＢ５５を更新させる（ステップＳ４５１２）。
【００６４】
次に、調整部４５は、イベントが到達したロジックはリソース超過の予測となっているか否かを判断する（ステップＳ４５１３）。調整部４５は、監視・予測部４３から送信された最新のリソース超過の判定結果にイベントが到達したロジックが含まれているか否かを判断する。
【００６５】
イベントが到達したロジックはリソース超過の予測となっていない場合（ステップＳ４５１４のＮＯ）、調整部４５は、実行部４７にイベントが到達したロジックを実行させる（ステップＳ４５１４）。実行部４７によるロジックの実行後、調整部４５は、ステップＳ４５１１へと戻り、上述同様の処理を繰り返す。
【００６６】
イベントが到達したロジックはリソース超過の予測となっている場合（ステップＳ４５１４のＹＥＳ）、調整部４５は、更に、スキップカウンタが、監視・予測部４３から通知された実行抑止回数に達しているか否かを判定する（ステップＳ４５１５）。
【００６７】
スキップカウンタが実行抑止回数に達していない場合（ステップＳ４５１５のＮＯ）、調整部４５は、スキップカウンタをインクリメントして（ステップＳ４５１６）、ステップＳ４５１１へと戻り、上述同様の処理を繰り返す。スキップカウンタが実行抑止回数に達している場合（ステップＳ４５１５のＹＥＳ）、調整部４５は、スキップカウンタをリセットして（ステップＳ４５１７）、調整部４５は、実行部４７にイベントが到達したロジックを実行させる（ステップＳ４５１４）。実行部４７によるロジックの実行後、調整部４５は、ステップＳ４５１１へと戻り、上述同様の処理を繰り返す。
【００６８】
図８は、監視・予測部による処理を説明するためのフローチャート図である。図８において、監視・予測部４３は、イベント到達通知を受けるごとに、イベント到達実績ＤＢを更新する（ステップＳ４３１１）。また、監視・予測部４３は、所定間隔ごとに、イベント到達実績ＤＢ５５を更新する（ステップＳ４３３１）。
【００６９】
一方で、監視・予測部４３は、監視時間間隔が経過したか否かを判断する（ステップＳ４３５１）。監視時間間隔が経過していない場合（ステップＳ４３５１のＮＯ）、監視・予測部４３は、ステップＳ４３５１を繰り返す。
【００７０】
監視時間間隔が経過している場合（ステップＳ４３５１のＹＥＳ）、監視・予測部４３は、ロジック毎に、リソースが超過するか、又は、余剰リソースが存在するかを判定する（ステップＳ４３５２）。監視・予測部４３は、リソース割当情報５９を用いて、ロジック毎のリソースの上限（図１４の予算閾値８７に相当）を決定し、イベント到達予測ＤＢ５７の各ロジックの到達予測モデルと、決定した上限とから、リソースの超過又は余剰リソースの存在を判定する。
【００７１】
次に、監視・予測部４３は、リソースが超過するロジック毎に、実行抑止回数を決定し（ステップＳ４３５４）、実行抑止回数を指定したリソース超過の判定結果を生成する（ステップＳ４３５４）。監視・予測部４３は、生成したリソース超過の判定結果を調整部４５に通知する。
【００７２】
また、監視・予測部４３は、余剰リソースを有するロジック毎に余剰リソースの大きさを示した余剰リソース分配依頼を分配部４１に対して行う（ステップＳ４３５６）。そして、監視・予測部４３は、ステップＳ４３１１へと戻り、上記同様の処理を繰り返す。
【００７３】
図９は、データ構成例を示す図である。図９では、５つのロジックでマイクロサービスが構成される場合の一例を示し、ロジックの個数、値等は、この例に限定されない。
【００７４】
優先度情報５１には、ロジック３毎の優先度を記録したテーブルに相当し、ロジックＩＤ、優先度等の項目を有する。ロジックＩＤは、ロジックを一意に特定する識別情報である。優先度は、分配部４１が決定した優先度を示す。
【００７５】
ロジック配備情報５３は、各ロジック３の入力側のロジック３と、出力側のロジック３とを示したテーブルに相当し、ロジックＩＤ、入力ロジックＩＤ、出力ロジックＩＤリスト等の項目を有する。ロジックＩＤは上述した通りである。入力ロジックＩＤは、ロジックの接続元のロジックのＩＤを示し、出力ロジックＩＤリストは、ロジックの接続先のロジックのＩＤを示す。複数のロジックが接続先となる場合、全てのロジックＩＤが示される。
【００７６】
イベント到達実績ＤＢ５５は、ロジック３毎にイベントの到達回数を記録したテーブルであり、ロジックＩＤ、到達回数（回）等の項目を有する。ロジックＩＤは上述した通りである。到達回数（回）は、調整部４５からのイベント到達通知に応じて、１インクリメントされる。到達回数（回）は、運用期間における現時点までのイベント到達の累積回数を示す。
【００７７】
イベント到達頻度予測ＤＢ５７は、ロジック３毎に予測到達回数を示すテーブルであり、ロジックＩＤ、予測到達回数（分毎）等の項目を有する。ロジックＩＤは上述した通りである。予測到達回数（分毎）は、運用期間の終了時のイベント到達回数の予測値を示し、１分毎に更新される。
【００７８】
リソース割当情報５９は、ロジック３毎に運用期間中に利用できるリソース全体と優先度情報５１とに基づいて、分配部４１によって決定された割当比を示すテーブルであり、ロジックＩＤ、割当比等の項目を有する。ロジックＩＤは上述した通りである。割当比は、ロジックに割り当てるリソースの割合を示す。
【００７９】
次に、処理部４１、４３、４５、及び４７による処理例について説明する。先ず、優先度の決定方法について図１０〜図１１で説明する。
【００８０】
図１０は、重要度に基づく基本的な優先度の決定方法を説明するための図である。ロジック３の重要度は、利用者によって異なり、利用者の予算の範囲において、ロジックごとに求められるＳＬＡは細かく異なっている。一方で、利用者に複数のロジックの１つ１つに重要度を設定させるのは、利用者に負担が掛かる。
【００８１】
本実施例では、利用者は、１以上の重要と考えるロジックを選択し、選択したロジックに重要度を設定するのみとする。分配部４１は、利用者が選択したロジックと、設定した重要度とに基づいて、全てのロジックに優先度を決定する。優先度の決定の際には、ロジック配備情報５３を参照してロジックの繋がりを考慮する。
【００８２】
つまり、基本的には、あるロジックの要求品質が高いのであれば、そのロジックへの入力となるロジックの品質も高くなる。利用者が選択したロジックから逆伝播により、利用者が設定した重要度に対応する優先度をロジックに設定する。
【００８３】
図１０の例では、利用者がロジック３ｘに重要度「５」を設定した場合、ロジック３ｘに優先度「５」が設定されると共に、ロジック３ｘの入力側に繋がるロジック３ｙの優先を「５」に決定する。次に、利用者が２以上のロジック３に重要度を設定した場合の優先度の決定方法について説明する。
【００８４】
図１１は、２以上のロジックの重要度に基づく優先度の決定方法を説明するための図である。以下の説明において、ロジック３としてロジックＡ、Ｂ、Ｃ、Ｄ、及びＥを示す。図１１のマイクロサービス１００１では、ロジック配備情報５３に基づくロジック連鎖グラフより、センサ７からのイベント５は、全体最適化処理部４０による起動制御の下、ロジックＡとロジックＢとに伝播される。
【００８５】
センサ７からのイベント５が通知されるロジックＡの接続先は、ロジックＤとロジックＥであり、ロジックＤの接続先はロジックＥである。即ち、ロジックＥの接続元は、ロジックＡとロジックＤである。また、センサ７からのイベント５が通知されるロジックＢの接続先は、ロジックＤとロジックＣである。よって、ロジックＤの接続元は、ロジックＡとロジックＢである。
【００８６】
利用者は、ロジックＥに重要度「５」を指定し、ロジックＣに重要度「３」を指定したとする。この場合、利用者が重要度を定めたロジックＥ及びロジックＣをそれぞれ起点として逆伝播しながら、他のロジックＡ、Ｂ、及びＤのそれぞれの優先度を決定する。重要度を１〜５とし、重要度の値に対応させて、それぞれの優先度を１〜５とした場合で説明する。値「１」が重要度及び優先度が最も低いことを示し、値「５」が重要度及び優先度が最も高いことを示す。ただし、重要度及び優先度の値、及び、重要度と優先度の対応付けはこの例に限定されない。
【００８７】
利用者が選択したロジックＥに対して、重要度「５」に対応する優先度「５」を設定し、ロジックＥを起点として逆伝播する。ロジックＥの接続元のロジックＡの優先度を「５」とし、ロジックＡの接続元は全体最適化処理部４０であるため、ロジックＡからの逆伝播を終了する。一方、ロジックＥの接続元のロジックＤに対しても、優先度を「５」とする。更に、ロジックＤの接続元のロジックＢの優先度を「３」とする。ロジックＢの接続元は全体最適化処理部４０であるため、ロジックＡからの逆伝播を終了する。
【００８８】
利用者が選択したロジックＣに対して、重要度「３」に対応する優先度「３」を設定し、ロジックＣを起点として逆伝播する。ロジックＣの接続元のロジックＢの優先度を「３」とし、ロジックＢの接続元は全体最適化処理部４０であるため、ロジックＢからの逆伝播を終了する。
【００８９】
しかしながら、ロジックＢでは、接続先のロジックＤの優先度に基づけば、「５」が設定され、もう一方の接続先のロジックＣの優先度に基づけば、「３」が設定されることになり、優先度に矛盾が生じる。このような優先度の矛盾に対しては、優先度の高い方を優先して設定する。即ち、ロジックＢには優先度「５」が設定される。
【００９０】
更に、図１１の逆伝播による優先度の決定方法による、分配部４１の優先度の決定処理を具体例で説明する。図１２は、分配部によって行われる優先度の決定処理の具体例を説明するための図である。図１２において、接続行列８１は、ロジック配備情報５３に基づくロジック３間の接続関係を表した行列である。
【００９１】
＜状態１＞では、接続行列８１には、ロジックＡ〜Ｅのそれぞれを接続元とした場合の接続先となるロジックに対して「１」が設定されている。
【００９２】
＜状態２＞では、利用者により指定されたロジックＤ及びＥに対して、分配部４１は、利用者が設定した重要度を優先度として設定する。この例では、重要度と優先度とは同一であるが、必ずしも同一である必要はない。例えば、重要度より優先度の粒度を細かくしてもよい。重要度に対応する優先度が設定されればよい。
【００９３】
そして、分配部４１は、ロジックＥを起点として１ロジック逆伝播して、接続行列８１の接続先「Ｅ」と接続元「Ａ」の要素と、接続行列８１の接続先「Ｅ」と接続元「Ｄ」の要素とに優先度「５」を設定する。接続行列８１において、優先度は（  ）内に示され、以下同様である。また、分配部４１は、ロジックＥを起点として１ロジック逆伝播して、接続行列８１の接続先「Ｅ」と接続元「Ａ」の要素に優先度「５」を設定する。
【００９４】
更に、分配部４１は、ロジックＣを起点として１ロジック逆伝播して、接続行列８１の接続先「Ｃ」と接続元「Ｂ」の要素に優先度「３」を設定する。
【００９５】
＜状態３＞では、分配部４１が、更に、１ロジック逆伝播することで設定した優先度が、接続行列８１に示されている。ロジックＥを起点とした場合では、接続行列８１の接続先「Ｄ」と接続元「Ｂ」の要素に優先度「５」が設定される。ロジックＣを起点とした場合では、接続行列８１の接続先「Ｃ」と接続元「Ｂ」の要素に優先度「３」が設定される。
【００９６】
＜状態４＞では、分配部４１は、＜状態３＞で得られた接続行列８１の各行内の最高値をロジックＢの優先度に決定する。この例では、ロジックＢの優先度は「５」と決定される。従って、全てのロジックＡ〜Ｅに対して、それぞれの優先度は、「５」、「５」、「３」、「５」、及び「５」に決定される。
【００９７】
次に、図１２の＜状態４＞に示す優先度を例として、リソース分配処理を説明する。図１３は、リソース分配処理を説明するための図である。図１３は、図１１に示す優先度に基づくリソース分配の例を示している。
【００９８】
分割部４１は、優先度の合計を全リソース６０とすることで、優先度の合計「２３」に対するロジックＡ〜Ｅの優先度の割合を求めることで割当比を算出する。ロジックＡ、Ｂ、Ｄ、及びＥの優先度は「５」であるため、分割部４１は、全リソースに対する割当比を「０．２２」に決定する。また、ロジックＣの優先度は「３」であるため、分割部４１は、全リソースに対する割当比を「０．１２」に決定する。割当比の桁数及び端数のまるめ方は任意であり、この例に限定されない。
【００９９】
全リソース６０は、利用者の予算に相当し、割当リソース６１は、優先度で定めた割当比によって全リソース６０から分配されたロジックＡ〜Ｅそれぞれのリソースに相当する。
【０１００】
次に、図４のステップＳ７３における適応的調整処理のうち、監視・予測部４３による実行抑止回数の調整方法について説明する。図１４は、実行抑止回数の調整方法について説明するための図である。図１４（Ａ）及び図１４（Ｂ）に示すグラフは、横軸に時間を示し、縦軸にイベント到達回数を示している。この例では、運用期間を２４時間とし、あるロジック３を例として説明するが、運用期間は２４時間に限定されない。
【０１０１】
図１４（Ａ）において、実績８３は、イベント到達実績ＤＢ５５の到達回数に基づいて、定めた時間間隔で発生したイベント到達回数の累積値を示している。監視・予測部４３は、累積値の推移から到達予測モデル８４を生成し、運用開始から２４時間後の累積値を予測する。到達予測モデル８４は、回帰分析（線形又は非線形のいずれでもよい）、ニューラルネットワーク（機械学習）等を用いればよい。累積値と総時間とから、１分間のイベント到達回数を得ることができる。１分当たりのイベント到達回数は、イベント発火頻度に相当する。
【０１０２】
また、監視・予測部４３は、利用者の予算を運用期間内のイベントの総到達回数に換算し、リソース割当情報５９の割当比を乗算して、ロジック３毎の予算閾値８７を設定する。２４時間後の累積値が予算閾値８７より大きい場合、監視・予測部４３は、予算を超過すると予測する。
【０１０３】
図１４（Ｂ）では、２４時間後の累積値から予算閾値８７を減算した差分回数８８が予算の超過分を表している。監視・予測部４３は、イベント到達回数の累積値に対して、ロジックの実行回数を予算閾値８７以下にするために、到達予測モデル８４の積分値が予算内になるように実行抑止回数を算出する。
【０１０４】
次に、図４のステップＳ７３における適応的調整処理のうち、監視・予測部４３による余剰リソースの取得方法について説明する。図１５は、余剰リソースの取得方法について説明するための図である。図１５（Ａ）及び図１５（Ｂ）に示すグラフは、図１４（Ａ）及び図１４（Ｂ）と同様である。
【０１０５】
図１５（Ａ）において、実績８３は、図１４（Ａ）と同様に、定めた時間間隔で発生したイベント到達回数の累積値を示している。監視・予測部４３は、図１４（Ａ）で説明した同様の方法により、到達予測モデル８４を生成して２４時間後の累積値を予測し、また、リソース割当情報５９の割当比を用いて予算閾値８７を設定する。２４時間後の累積値が予算閾値８７より小さい場合、監視・予測部４３は、余剰リソースがあると予測する。
【０１０６】
図１５（Ｂ）では、予算閾値８７から２４時間後の累積値を減算することで得られる余剰リース８９を示している。余剰リース８９は、余ると予測されるリソースの大きさを示す。監視・予測部４３は、余剰リース８９を検出したロジック３から余剰リース８９のないロジック３へとリソースの再分配を依頼する余剰リソース分配依頼を分配部４１に対して行う。
【０１０７】
余剰リソース分配依頼には、余剰リース８９を検出したロジック３のロジックＩＤと、余剰リソース８９とが示される。また、余剰リソース分配依頼に、リソースの不足分の大きい順にロジックＩＤを指定する情報を含めてもよい。
【０１０８】
次に、図４のステップＳ７４における余剰リソース分配処理の例について説明する。図１６は、余剰リソース分配処理の例を説明するための図である。ロジックＡ〜ＥのロジックＩＤを「001」、「002」、「003」、「004」、及び「005」として、優先度は、図９の優先度情報５１を適用する。
【０１０９】
図１６（Ａ）では、余剰リソース８９の回収例を示している。分配部４１は、余剰リソース分配依頼に基づいて、余剰リソース８９の合計を求める。この例では、ロジックＡ、Ｃ、及びＤの余剰リソース８９を合計して、全余剰リソース６９を得る。
【０１１０】
図１６（Ｂ）では、全余剰リソース６９の分配例を示している。分配部４１は、余剰リソース８９の無いロジックＢとＥとに全余剰リソース６９を分配する。分配量は、優先度に基づいて行う。優先度が同じであっても、イベント到達回数の差が大きい場合がある。余剰リソース分配依頼に、リソースの不足分の大きい順にロジックＩＤが指定されている場合には、このような状況に対して、分配部４１は、優先度とリソースの不足分とに基づいて、分配量を定めてもよい。
【０１１１】
上述した適応的調整処理に加えて、更に、イベント発火頻度を制御することで余剰リソースを得られるようにしてもよい。図１７は、イベント発火頻度の制御例を説明するための図である。図１７（Ａ）では、ロジック３ｐはロジック３ｑに接続され、接続元のロジック３ｐが照度センサ４ｐからの照度値を受信してイベントを発生させて、電灯４ｑをオンオフする接続先のロジック３ｑを起動する例を示している。
【０１１２】
図１７（Ａ）では、ロジック３ｐが出力を行う契機となる制御閾値３７を事前に登録した場合の例を示している。一例として、制御閾値３７を１００Ｌｘとする。ロジック３ｐは、照度センサ４ｐから得られる照度値が、制御閾値「１００Ｌｘ」に対して予め定めた検出範囲内である場合に、ロジック３ｑへ照度値を示すイベントを通知することで、ロジック３ｑへの入力イベントの到達回数を削減する。
【０１１３】
ロジック３ｑに対しては、制御閾値「１００Ｌｘ」の間は常時電源をオンにするが、入力イベントで示される照度値が定めた検出範囲内において制御閾値３７に近くなる程、起動頻度を高くなるように実行抑止回数が決定される。制御閾値３７から離れる程、起動頻度が低くなるように実行抑止回数が決定される。即ち、検出範囲において、入力イベントの照度値と制御閾値３７との差に反比例してロジック３ｑの起動頻度を増減し制御する。
【０１１４】
図１７（Ｂ）のグラフは、横軸に時間を示し、左縦軸には照度（Ｌｘ）を示し、右縦軸には単位時間当たりのロジック起動頻度を示している。線３８が照度の変化を示し、棒グラフ３９がロジック起動頻度を示している。図１７（Ｂ）のグラフより、照度値が制御閾値３７より高い程、ロジック起動頻度が低くなり、照度値が制御閾値３７より低い程、ロジック起動頻度が高くなっている。このような制御により、余剰リソースをより適応的に回収することができる。
【０１１５】
図１８は、本実施例におけるマイクロサービスの具体的な例を説明するための図である。図１８に示すマイクロサービス１００２は、温度センサ７１、湿度センサ７２、照度センサ７３、及び音センサ７４と、ロジック３１〜３１０とを有する。ロジック３１〜３１０それぞれは、全体最適化処理部４０によって起動頻度が制御される。
【０１１６】
ロジック３１は、温度センサ７１から通知される温度の値が、設定された制御閾値「１０°Ｃ」以上の場合にイベントを発生する。ロジック３２は、湿度センサ７２から通知される湿度の値が設定された制御閾値「５４％」以上の場合にイベントを発生するロジックである。ロジック３１及びロジック３２から発生したイベントは、ロジック３３に到達する。
【０１１７】
ロジック３３は、ロジック３１及びロジック３２からの入力イベントで示される値に基づいて熱中症危険指数を計算し、得られた熱中症危険指数が、設定された制御閾値「１０」を超えている場合、イベントを発生する。ロジック３３で発生したイベントは、ロジック３４とロジック３７とに到達する。ロジック３４は、ロジック３３からイベントが到達すると、熱中症警報をオンにする。
【０１１８】
ロジック３５は、照度センサ７３から通知される照度の値が、設定された制御閾値「１０Ｌｘ」以上の場合にイベントを発生する。ロジック３５から発生したイベントは、ロジック３６に到達する。ロジック３６は、ロジック３５からの入力イベントによって現場作業中であると判断し、イベントを発生する。イベントを発生する制御閾値は「現場作業中：YES」である。ロジック３６で発生したイベントは、ロジック３７に到達する。ロジック３７は、ロジック３３、ロジック３５、及びロジック３９から到達したイベントの値を用いて現場を可視化する処理を行う。一例として、騒音履歴、熱中症危険指数履歴、現場作業状況等の情報が表示される。
【０１１９】
ロジック３８は、音センサ７４から通知される騒音の値が、設定された制御閾値「９８ｄＢ」以上の場合にイベントを発生する。ロジック３８から発生したイベントは、ロジック３９に到達する。ロジック３９は、ロジック３８からの入力イベントによって騒音レベルが「大」になったと判断し、イベントを発生する。ロジック３９で発生したイベントは、ロジック３７とロジック３１０とに到達する。ロジック３１０は、ロジック３９から到達したイベントに応じて騒音抑制警報をオンにする。
【０１２０】
本実施例では、利用者により重要度の設定が可能である。利用者は、異常検知はリアルタイム制を必要とするが、可視化はそう重要ではないと考えている場合がある。このような場合には、利用者の予算内において、利用者が主なロジックごとに求めるＳＬＡを重要度として与えることができる。
【０１２１】
図１８の例では、利用者が、熱中症警報のロジック３４には重要度「５」を指定し、現場可視化のロジック３７には重要度「１」を指定し、騒音抑制警報のロジック３１０には重要度「３」を指定した場合を示している。この場合、上述した分配部４１による優先度決定処理により、ロジック３４、ロジック３３、ロジック３２、及びロジック３１に対して、優先度は「５」に決定される。ロジック３７、ロジック３６、及びロジック３５に対して、優先度は「１」に決定される。ロジック３１０、ロジック３９、及びロジック３８に対して、優先度は「３」に決定される。
【０１２２】
このように、利用者が指定したロジックと重要度とによって、全てのロジックに対して優先度が自動的に決定される。利用者は、主要なロジックに対して重要度を決定するのみで、ロジックごとのＳＬＡを指定可能である。
【０１２３】
利用者の予算は、利用者が任意の額を設定してもよいが、予めプラットフォーム提供者が、サービスの内容ごとに金額を設定し利用者に提案してもよい。サービスの内容の区分は、ＳＬＡの分類と度合とによる分類を示し、分類に応じた料金が予め設定されていてもよい。
【０１２４】
図１９は、ＳＬＡの度合別のコース例を示す図である。図１９に示す分類毎に料金を示したテーブル例では、縦に分類を示し、横にＳＬＡの項目を示している。分類には、コースＸ、コースＹ、及びコースＺが示されている。ＳＬＡ項目には、「現場モニタリング／可視化アプリケーション」（以下、「ＳＬＡ第１項目」という）、「異常通知アプリケーション」（以下、「ＳＬＡ第２項目」という）、及び「料金（／月）」が示されている。
【０１２５】
コースＸでは、ＳＬＡ第１項目において提供可能な内容は「数分毎に画面更新」であり、ＳＬＡ第２項目において提供可能な内容は「数分後に通知が届く」であり、料金は「XX,XXX」である。コースＹでは、ＳＬＡ第１項目において提供可能な内容は「毎秒画面更新」であり、ＳＬＡ第２項目において提供可能な内容は「約１分内に通知が届く」であり、料金は「YY,YYY」である。コースＸでは、ＳＬＡ第１項目において提供可能な内容は「リアルタイムに画面更新」であり、ＳＬＡ第２項目において提供可能な内容は「数秒内に通知が届く」であり、料金は「ZZ,ZZZ」である。
【０１２６】
このようなコース例の提示があることで、利用者は、どの程度のサービスを希望の予算内で受けられるのかを把握することができる。コース例の提示は、この例に限定されない。分類の数と、ＳＬＡ項目の数及びそれぞれの内容とは、プラットフォーム提供者が決定すればよい。
【０１２７】
次に、イベント発生とロジック頻度について図２０で説明する。図２０は、イベント発生とロジック頻度を説明するための図である。図２０（Ａ）では、一般的なロジック間のイベントに対するロジック起動の例を示している。前段のロジック３ａでイベントが発生すると、イベントは、メッセージブロッカ２が受け付けて、制御部９０によって、ロジック３ａの接続先のロジック３ｂが起動され、イベントが通知される。制御部９０は、単に、接続先のロジック３ｂへのイベントを監視し、イベントが発生する度にロジック３ｂを起動する制御のみを行う。
【０１２８】
一方、図２０（Ｂ）は、本実施例の場合を例示している。本実施例では、監視・予測部４３が全てのイベント発生を監視し、発生回数の推移に基づいて到達予測モデル８４を生成する。また、監視・予測部４３は、ロジック３ｂの割当リソース６１を監視し、生成した到達予測モデル８４を参照して、リソース超過・余剰判定を行い、リソースが超過している場合に、ロジック３ｂに対する実行抑止回数を示す判定結果を通知する。
【０１２９】
調整部４５は、監視・予測部４３からのリソース超過の判定結果に基づいて、実行部４７を制御する。調整部４５は、ロジック３ｂへのイベント到達回数をカウントするカウンタの値が実行抑止回数に達したら、実行部４７にロジック３ｂの実行を指示し、カウンタをリセットし、イベントが到達する毎にカウンタをインクリメントする。
【０１３０】
カウンタの値が実行抑止回数未満の間は、イベントを無視（破棄）し、実行部４７によるロジック３ｂの起動を行わない。ロジック３ｂを起動しなかったイベントの到達回数に相当するリソースを節約でき、利用者の予算の消費を抑えることができる。
【０１３１】
上述したように、本実施例では、利用者は、予算の決定と、少なくとも１つ以上のロジックを選択して重要度を指定するのみ、予算が適用される運用期間内において継続的にマイクロサービスを利用することが可能となる。プラットフォーム提供者は、予算の大きさに応じたロジック３の内容を変える等のサービス設計の変更を不要とする柔軟なスケール性により、開発負担を低減できる。
【０１３２】
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、主々の変形や変更が可能である。
【０１３３】
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
マイクロサービス基盤において、複数のロジックの連鎖構造に基づいて優先度を決定する優先度決定部と、
記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整する適応的調整部と、
前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる分配部と、
を有する情報処理装置。
（付記２）
前記優先度決定部は、前記複数のロジックのうち、予め優先度が決定されたロジックから前記連鎖構造に従ってイベントの伝播方向と逆方向にあるロジックに対して、同じ優先度を設定する
ことを特徴とする付記１記載の情報処理装置。
（付記３）
前記優先度決定部は、異なる優先度が２以上設定されたロジックに対しては、設定された優先度のうち高い優先度を選択する
ことを特徴とする付記２記載の情報処理装置。
（付記４）
前記分配部は、
予め定められた予算を前記リソースに置き換えて、各ロジックに対して決定した前記優先度に基づいて分配し、
前記適応的調整部からの前記比較結果に応じて、前記余剰リソースを合計し、前記リソースが不足しているロジックへ割り当てる
ことを特徴とする付記１乃至３のいずれか一項記載の情報処理装置。
（付記５）
前記適応的調整部は、
前記ロジックを起動する制御閾値と該ロジックへ入力されるイベントの値との差に反比例して、該ロジックの起動頻度を増減させる
ことを特徴とする付記１乃至３のいずれか一項記載の情報処理装置。
（付記６）
マイクロサービス基盤において、複数のロジックの連鎖構造に基づいて優先度を決定し、
記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整し、
前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる
処理をコンピュータが行う情報処理方法。
（付記７）
マイクロサービス基盤において、複数のロジックの連鎖構造に基づいて優先度を決定し、
記憶部に記憶した前記複数のロジックの起動実績から予測した各ロジックの将来におけるイベントの発生頻度と、前記優先度に基づいて各ロジックに割り当てた割当リソースとを比較して、比較結果に基づいて各ロジックの起動頻度を調整し、
前記比較結果に基づいて、余剰リソースの合計を算出し、リソースが不足しているロジックへ割り当てる
処理をコンピュータに実行させる情報処理プログラム。
【符号の説明】
【０１３４】
３        ロジック（マイクロロジック）
７        センサ
１１      ＣＰＵ
１２      主記憶装置
１３      補助記憶装置
１４      入力装置
１５      表示装置
１７      通信Ｉ／Ｆ
１８      ドライブ装置
１９      記憶媒体
４０      全体最適化処理部
４１      分配部
４３      監視・予測部
４５      調整部
４７      実行部
５１      優先度情報
５３      ロジック配備情報
５５      イベント到達実績ＤＢ
５７      イベント到達予測ＤＢ
５９      リソース割当情報
１００    情報処理装置
１３０    記憶部
【図１】
2019106037.tif 000003
【図２】
2019106037.tif 000004
【図３】
2019106037.tif 000005
【図４】
2019106037.tif 000006
【図５】
2019106037.tif 000007
【図６】
2019106037.tif 000008
【図７】
2019106037.tif 000009
【図８】
2019106037.tif 000010
【図９】
2019106037.tif 000011
【図１０】
2019106037.tif 000012
【図１１】
2019106037.tif 000013
【図１２】
2019106037.tif 000014
【図１３】
2019106037.tif 000015
【図１４】
2019106037.tif 000016
【図１５】
2019106037.tif 000017
【図１６】
2019106037.tif 000018
【図１７】
2019106037.tif 000019
【図１８】
2019106037.tif 000020
【図１９】
2019106037.tif 000021
【図２０】
2019106037.tif 000022