JP2023000232A - データ処理プログラム、データ処理方法およびデータ処理システム - Google Patents

データ処理プログラム、データ処理方法およびデータ処理システム Download PDF

Info

Publication number
JP2023000232A
JP2023000232A JP2021100932A JP2021100932A JP2023000232A JP 2023000232 A JP2023000232 A JP 2023000232A JP 2021100932 A JP2021100932 A JP 2021100932A JP 2021100932 A JP2021100932 A JP 2021100932A JP 2023000232 A JP2023000232 A JP 2023000232A
Authority
JP
Japan
Prior art keywords
node
resource
processing
amount
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021100932A
Other languages
English (en)
Inventor
政秀 野田
Masahide Noda
智大 今井
Tomohiro Imai
兆功 郭
Yoshiisa Kaku
耕一 横田
Koichi Yokota
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2021100932A priority Critical patent/JP2023000232A/ja
Priority to US17/712,388 priority patent/US20220407821A1/en
Publication of JP2023000232A publication Critical patent/JP2023000232A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/726—Reserving resources in multiple paths to be used simultaneously
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction

Abstract

【課題】処理装置のリソース増強を行う適切なタイミングを判断するデータ処理プログラム、データ処理方法及びデータ処理システムを提供する。【解決手段】データ処理方法は、受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置のうちのいずれかの処理装置に、前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する。【選択図】図１

Description

本発明は、データ処理プログラム、データ処理方法およびデータ処理システムに関する。
近年、現実世界をデータ化して仮想世界に写像することで、仮想世界をデータとして俯瞰して把握・分析するデジタルツインシステムがある。デジタルツインシステムでは、例えば、センサデータを時系列データとして取り込むことで、時間の経過に伴って変化するデータの分析が可能となる。一方、データ量の増加などでリソースが不足した場合に、リソースを増強することで、サービス全体の処理量を増やすことが行われる。
先行技術としては、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、第１の処理の負荷が第１の条件を超えるときに、第１の処理に関係する第２の処理を実行する処理プログラムを第２の処理を実行するために増加される処理ノードに転送することを実行させるものがある。また、オブジェクトのサーバ上の容量を、予測される必要な容量に合わせるために、過去の需要、入力される地域、コスト要件等に基づいて動的に需要を予測し、それに応じて容量調整を行う技術がある。
特開２０１７－２１９９７２号公報 特開２００１－０６７３７７号公報
しかしながら、従来技術では、複数のサービスを組み合わせてストリームデータ処理などを行うシステムにおいて、システム内の処理装置（ノード）のリソース増強を行う適切なタイミングを判断することが難しい。
一つの側面では、本発明は、処理装置のリソース増強を行う適切なタイミングを判断することを目的とする。
１つの実施態様では、受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置のうちのいずれかの処理装置に、前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、データ処理プログラムが提供される。
本発明の一側面によれば、処理装置のリソース増強を行う適切なタイミングを判断することができるという効果を奏する。
図１は、実施の形態にかかるデータ処理方法の一実施例を示す説明図である。 図２は、データ処理システム２００のシステム構成例を示す説明図である。 図３は、ノードＮｉのハードウェア構成例を示すブロック図である。 図４は、増強条件テーブル２２０の記憶内容の一例を示す説明図である。 図５は、データ処理システム２００内のノード間の接続例を示す説明図である。 図６は、ノードＮｉの機能的構成例を示すブロック図である。 図７は、受信量収集テーブル７００の記憶内容の一例を示す説明図である。 図８は、通信状況テーブル８００の記憶内容の一例を示す説明図である。 図９は、リソース増強の判断例を示す説明図（その１）である。 図１０は、リソース増強の判断例を示す説明図（その２）である。 図１１は、リソース増強の判断例を示す説明図（その３）である。 図１２は、データ処理システム２００の動作例を示す説明図である。 図１３は、機械学習を利用したリソース増強の判断処理例を示す説明図である。 図１４は、ノードＮｉの増強制御処理手順の一例を示すフローチャートである。
以下に図面を参照して、本発明にかかるデータ処理プログラム、データ処理方法およびデータ処理システムの実施の形態を詳細に説明する。
（実施の形態）
図１は、実施の形態にかかるデータ処理方法の一実施例を示す説明図である。図１において、処理装置１０１は、受信したデータに対して所定の処理を実行して結果を出力するコンピュータである。所定の処理は、例えば、ストリームデータ処理である。ストリームデータ処理とは、時々刻々と発生するデータを逐次的に処理することである。データは、例えば、車両（コネクテッドカー）や生産設備などのセンサデータである。
例えば、デジタルツインシステムでは、現実世界に配備したセンサなどから情報を取り込み、関係するデータを組み合わせて処理、分析することが行われる。デジタルツインシステムでは、センサデータを時系列データとして取り込むことで、時間の経過に伴って変化するデータの分析が可能となる。
また、大量のデータを高速に処理するために、並列分散かつ複数段でデータをストリームデータ処理する場合がある。例えば、メッセージキューサービスやストリームデータ処理サービスを組み合わせて、ストリームデータ処理を行うデジタルツインシステムがある。このデジタルツインシステムでは、センサデータをストリームデータとして扱い、メッセージキューを介してストリームデータ処理を行う。
このようなシステムでは、データ量の増加などでリソースが不足した場合に、例えば、スケールアウトやスケールアップなどにより、リソースを増強することが行われる。
複数のサービスの組み合わせにより実現されるサービスの増強手法として、例えば、組み合わせている各サービスが、個々にリソースの増強を制御する技術がある（従来技術１）。従来技術１では、例えば、各サービスが、自サービスの使用済みリソースが、予め決められた閾値を超えたら、リソースの増強を行う。
しかしながら、従来技術１では、あるサービスが増強された場合に、そのサービスからのストリームデータが流れ込む後段のサービスがすぐにリソース不足になり、リソース不足状態が長く続くことになるという問題がある。
また、組み合わせているサービス全体について、一括でリソースの増強を制御する技術がある（従来技術２）。従来技術２は、例えば、組み合わせているサービス全体の使用済みリソースが、予め決められた閾値を超えたら、全サービスのリソースの増強を一括して行う。
しかしながら、従来技術２では、本来増強しなくてよいサービスについても補強することになる場合があり、過剰なリソース提供につながるという問題がある。
また、前段のサービスが、既定の時間、既定の負荷量を超え続けたら、後段のサービスを増強する技術がある（従来技術３）。従来技術３では、時間と負荷量に関する閾値の範囲、各サービスの前段のサービスとのつながりは、事前に設定される。従来技術３については、例えば、特許文献１を参照することができる。
しかしながら、現実世界の状況は刻々と変化するため、センサからメッセージキューへの流量も状況によって変化する。その結果、前段のサービスからの流入量が状況によって変化する。このため、従来技術３のように、閾値の範囲などのパラメータを事前に設定することは困難である。また、複数のメッセージキューを利用してストリームデータ処理を複数段つなげるといったシステム構成になると、サービスの接続関係の複雑さが増し、事前のパラメータ設定が困難になる。
そこで、本実施の形態では、ある処理装置のリソース増強が行われたときに、その後段の処理装置のリソース増強を行う適切なタイミングを判断するデータ処理方法について説明する。以下、処理装置１０１の処理例について説明する。ここでは、処理装置１０１は、複数の処理装置のいずれかの処理装置であり、前段の処理装置から受信したデータに対して所定の処理を実行して結果を出力する。また、処理装置１０１の前段の処理装置を「処理装置１０２，１０３」とする。
（１）処理装置１０１は、自装置の前段の処理装置群の第１の処理装置から増強通知を受け付ける。ここで、増強通知は、リソースを増強したことを示す通知である。処理装置のリソースを増強すると、その処理装置の処理能力が向上し、その処理装置から後段の処理装置へのデータの流入量が増加する傾向にある。
図１の例では、処理装置１０１が、前段の処理装置１０２から増強通知を受け付けた場合を想定する。
（２）処理装置１０１は、第１の処理装置から増強通知を受け付けた場合、前段の処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前段の処理装置群のそれぞれの受信量の合計に対する第１の処理装置の受信量の割合を算出する。所定期間は、任意に設定可能であり、例えば、増強通知を受け付けた時点を含む一定時間（３０分など）の期間である。
ここで、処理装置１０１の処理負荷は、受信するデータ量が増加すると、それに応じて増加するという関係にある。したがって、前段の処理装置群のうち、処理装置１０１が受信するデータの受信量が多い処理装置ほど、処理装置１０１との関係が強く依存度合いが高いといえる。
ここでは、処理装置１０１の第１の処理装置への依存度合いを、前段の処理装置群のそれぞれの受信量の合計に対する第１の処理装置の受信量の割合によって表す。処理装置１０１は、第１の処理装置への依存度合いをもとに、第１の処理装置の増強が自装置にどのような影響を及ぼすかを推測することができる。
図１の例では、処理装置１０１は、前段の処理装置１０２から増強通知を受け付けたことに応じて、前段の処理装置群１０２，１０３のそれぞれから直近３０分間に受信したデータの受信量を特定する。ここでは、処理装置１０２から直近３０分間に受信したデータの受信量を「受信量ａ」とし、処理装置１０３から直近３０分間に受信したデータの受信量を「受信量ｂ」とする（ａ＞ｂ）。この場合、処理装置１０１は、前段の処理装置群１０２，１０３のそれぞれの受信量の合計「ａ＋ｂ」に対する前段の処理装置１０２の受信量「ａ」の割合「ａ／（ａ＋ｂ）」を算出する。この割合「ａ／（ａ＋ｂ）」は、処理装置１０１の前段の処理装置１０２への依存度合いを表す。
（３）処理装置１０１は、算出した割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する。リソースの使用状況は、例えば、使用リソース量と未使用リソース量とによって表される。処理装置１０１の第１の処理装置への依存度合いが高いほど、第１の処理装置の増強が自装置に及ぼす影響が大きいといえ、第１の処理装置の増強によりデータの受信量が増加してリソース消費量が増えると推測することができる。
このため、処理装置１０１は、第１の処理装置が増強されたときに、第１の処理装置への依存度合いに応じて、自装置の未使用リソースが使用されると判断する。具体的には、例えば、処理装置１０１は、算出した割合と、自装置の現在のリソースの使用状況とに基づいて、自装置の将来のリソースの使用状況を推測する。例えば、算出した割合が高いほど、処理装置１０１の使用リソース量が多くなるように、将来のリソースの使用状況が推測される。
そして、処理装置１０１は、推測した将来のリソースの使用状況が予め決められた増強条件を満たすか否かを判断する。ここで、増強条件を満たす場合に、処理装置１０１は、自装置のリソースを増強すると判断する。一方、増強条件を満たさない場合には、処理装置１０１は、自装置のリソースを増強しないと判断する。
図１の例では、処理装置１０１は、算出した割合「ａ／（ａ＋ｂ）」と、自装置の現在のリソースの使用状況とに基づいて、将来のリソースの使用状況を推測する。そして、処理装置１０１は、推測した将来のリソースの使用状況が、予め決められた増強条件を満たすか否かを判断する。ここでは、将来のリソースの使用状況が増強条件を満たす場合を想定する。この場合、処理装置１０１は、自装置のリソースを増強すると判断する。
このように、処理装置１０１によれば、ネットワーク通信量（前段の処理装置群それぞれの受信量）をもとに、増強された第１の処理装置への依存度合いを算出することができる。そして、処理装置１０１によれば、第１の処理装置への依存度合いをもとに、第１の処理装置の増強が自装置にどのような影響を及ぼすかを推測して、リソース不足になるかどうかを判断することができる。
これにより、処理装置１０１は、前段の処理装置１０２の増強によるネットワーク通信量の変化やリソース消費量の変化を直接予測することが困難な場合であっても、自装置のリソース増強を行う適切なタイミングを判断することができる。図１の例では、処理装置１０１は、前段の処理装置１０２への依存度合いをもとに、前段の処理装置１０２の増強が自装置にどのような影響を及ぼすかを推測して、前段の処理装置１０２の増強に連動して、自装置のリソースを増強するか否かを判断することができる。
（データ処理システム２００のシステム構成例）
つぎに、実施の形態にかかるデータ処理システム２００のシステム構成例について説明する。データ処理システム２００は、例えば、クラウド上に実世界（ヒト・モノ）のデータを収集し、データの分析、予測の結果をサービスやアプリケーションに対して提供するデジタルツインシステムに適用される。例えば、コネクテッドカーを例に挙げると、速度や位置などの車両から収集される大量のデータを分析し、危険情報などをドライバーにフィードバックすることができる。
以下の説明では、データ処理システム２００に含まれる複数の処理装置を「ノードＮ１～Ｎｎ」と表記する場合がある（ｎ：２以上の自然数）。また、ノードＮ１～Ｎｎのうちの任意のノードを「ノードＮｉ」と表記する場合がある（ｉ＝１，２，…，ｎ）。図１に示した処理装置１０１は、例えば、ノードＮｉに対応する。
図２は、データ処理システム２００のシステム構成例を示す説明図である。図２において、データ処理システム２００は、ノードＮ１～Ｎｎと、管理端末２０１と、を含む。データ処理システム２００において、ノードＮ１～Ｎｎおよび管理端末２０１は、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などである。
ここで、ノードＮｉは、増強条件テーブル２２０を有し、受信したデータに対して所定の処理を実行して結果を出力する。ノードＮｉは、例えば、メッセージキューサービスやストリームデータ処理サービスなどのサービスに対応するデータ処理基盤である。所定の処理は、例えば、センサデータのキューイング処理やストリームデータ処理などである。
ノードＮｉは、例えば、クラウドコンピューティングのサーバであってもよく、エッジコンピューティングのサーバであってもよい。また、ノードＮｉは、サーバ（物理サーバ）上の仮想マシンやコンテナによって実現されることにしてもよい。なお、増強条件テーブル２２０の記憶内容については、図４を用いて後述する。
管理端末２０１は、データ処理システム２００の管理者が使用するコンピュータである。管理端末２０１は、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレットＰＣなどである。
データ処理システム２００において、ノードＮｉは、例えば、前段のノードから受信したデータに対して所定の処理（例えば、キューイング処理、ストリームデータ処理）を実行して結果を後段のノードに出力する。なお、ノードＮｉは、自ノードの前段のノードおよび後段のノードを特定可能である。例えば、ノードＮｉの前段のノードおよび後段のノードは、管理者によって設定されてもよい。また、前段のノードについては、ノードＮｉは、自ノードにデータを送信してきたノードを、前段のノードとして特定してもよい。
（ノードＮｉのハードウェア構成例）
図３は、ノードＮｉのハードウェア構成例を示すブロック図である。図３において、ノードＮｉは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ディスクドライブ３０３と、ディスク３０４と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０５と、可搬型記録媒体Ｉ／Ｆ３０６と、可搬型記録媒体３０７と、を有する。また、各構成部は、バス３００によってそれぞれ接続される。
ここで、ＣＰＵ３０１は、ノードＮｉの全体の制御を司る。ＣＰＵ３０１は、複数のコアを有していてもよい。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭがＯＳのプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。
ディスクドライブ３０３は、ＣＰＵ３０１の制御に従ってディスク３０４に対するデータのリード／ライトを制御する。ディスク３０４は、ディスクドライブ３０３の制御で書き込まれたデータを記憶する。ディスク３０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。
通信Ｉ／Ｆ３０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータに接続される。そして、通信Ｉ／Ｆ３０５は、ネットワーク２１０と装置内部とのインターフェースを司り、他のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ３０５には、例えば、モデムやＬＡＮアダプタなどを採用することができる。
可搬型記録媒体Ｉ／Ｆ３０６は、ＣＰＵ３０１の制御に従って可搬型記録媒体３０７に対するデータのリード／ライトを制御する。可搬型記録媒体３０７は、可搬型記録媒体Ｉ／Ｆ３０６の制御で書き込まれたデータを記憶する。可搬型記録媒体３０７としては、例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどが挙げられる。
なお、ノードＮｉは、上述した構成部のほかに、例えば、入力装置、ディスプレイなどを有することにしてもよい。また、図２に示した管理端末２０１についても、ノードＮｉと同様のハードウェア構成により実現することができる。ただし、管理端末２０１は、上述した構成部のほかに、例えば、入力装置、ディスプレイなどを有する。
（増強条件テーブル２２０の記憶内容）
つぎに、図４を用いて、ノードＮｉが有する増強条件テーブル２２０の記憶内容について説明する。増強条件テーブル２２０は、例えば、図３に示したメモリ３０２、ディスク３０４などの記憶装置により実現される。
図４は、増強条件テーブル２２０の記憶内容の一例を示す説明図である。図４において、増強条件テーブル２２０は、増強条件情報４００－１，４００－２を記憶する。増強条件情報４００－１は、前段のノード数が２以上の場合の増強条件「想定リソース使用量が８０［％］超え」を示す。増強条件情報４００－２は、前段のノード数が１の場合の増強条件「現在のリソース使用量が７０［％］超え」を示す。各増強条件は、例えば、ノードＮｉごとに任意に設定可能である。
（データ処理システム２００内のノード間の接続例）
つぎに、図５を用いて、データ処理システム２００内のノード間の接続例について説明する。
図５は、データ処理システム２００内のノード間の接続例を示す説明図である。図５において、データ処理システム２００内のノードＮ１～Ｎ４が示されている。ノードＮ１，Ｎ２は、ノードＮ３の前段のノードである。各ノードＮ１，Ｎ２は、例えば、不図示の前段のノードやセンサ（例えば、コネクテッドカー）などから受信したデータに対してキューイング処理などを実行して結果を後段のノードＮ３に出力する。
ノードＮ３は、ノードＮ１，Ｎ２の後段のノードであり、ノードＮ４の前段のノードである。ノードＮ３は、例えば、前段のノードＮ１，Ｎ２から受信したデータに対してストリームデータ処理などを実行して結果を後段のノードＮ４に出力する。
ノードＮ４は、ノードＮ３の後段のノードである。ノードＮ４は、例えば、前段のノードＮ３から受信したデータに対してストリームデータ処理などを実行して結果を、不図示の後段のノードやユーザ端末（例えば、アプリケーション、サービスなど）に出力する。
（ノードＮｉの機能的構成例）
図６は、ノードＮｉの機能的構成例を示すブロック図である。図６において、ノードＮｉは、受付部６０１と、特定部６０２と、算出部６０３と、判断部６０４と、増強制御部６０５と、を含む。受付部６０１～増強制御部６０５は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０４などの記憶装置に記憶される。
受付部６０１は、ノードＮ１～Ｎｎのうちの自ノードの前段のノードＮｊ（ｊ≠ｉ、ｊ＝１，２，…，ｎ）から増強通知を受け付ける。増強通知は、リソースを増強したことを示す通知である。増強通知には、前段のノードＮｊを識別する識別子、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスが含まれる。
増強通知は、例えば、スケールアウトやスケールアップなどにより、前段のノードＮｊのリソースが増強されたことに応じて、前段のノードＮｊからノードＮｉに通知される。増強通知は、例えば、前段のノードＮｊにおいて、増強が完了したタイミングで通知されてもよく、また、増強が開始されたタイミングで通知されてもよい。前段のノードＮｊにおけるリソースの増強は、例えば、前段のノードＮｊの判断部６０４によりリソースを増強すると判断された場合に行われてもよく、また、管理者の指示や既存のリソース制御により行われてもよい。
特定部６０２は、前段のノードＮｊから増強通知を受け付けた場合、自ノードの前段のノード群のそれぞれから所定期間Ｔ内に受信したデータの受信量を特定する。所定期間Ｔは、直近の通信状況を判断するために設けられる期間であり、例えば、増強通知を受け付けた時点以前の直近３０分程度の期間に設定される。前段のノード群は、前段のノードＮｊを含む１以上のノードである。
具体的には、例えば、特定部６０２は、自ノードのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）から、サービスがメトリクスとして収集している単位時間あたりのデータの受信量を取得する。データの受信量は、例えば、バイトサイズによって表されてもよく、また、メッセージ数によって表されてもよい。
取得された単位時間あたりのデータの受信量は、例えば、図７に示すような受信量収集テーブル７００に記憶される。受信量収集テーブル７００は、例えば、図３に示したメモリ３０２、ディスク３０４などの記憶装置により実現される。ここで、受信量収集テーブル７００の記憶内容について説明する。
図７は、受信量収集テーブル７００の記憶内容の一例を示す説明図である。図７において、受信量収集テーブル７００は、Ｔｉｍｅ、送信元ＩＰおよび受信量のフィールドを有し、各フィールドに情報を設定することで、受信量データ（例えば、受信量データ７００－１，７００－２）をレコードとして記憶する。
ここで、Ｔｉｍｅは、時間帯を示す。例えば、Ｔｉｍｅ「２０２１／３／１５ １０：５４：００」は、２０２１年３月１５日の１０時５４分台の時間帯（１分間）を示す。送信元ＩＰは、前段のノードＮｊのＩＰアドレスを示す。受信量は、Ｔｉｍｅにおいて前段のノードＮｊから受信した１分あたりのデータの受信量を示す（単位：ＭＢ）。
特定部６０２は、取得した単位時間あたりのデータの受信量に基づいて、前段のノード群のそれぞれから所定期間Ｔ内に受信したデータの受信量を特定する。ここで、所定時間Ｔを直近３０分間の期間とする。この場合、特定部６０２は、受信量収集テーブル７００を参照して、前段のノード群のそれぞれについて、Ｔｉｍｅが直近３０分間に含まれる受信量データを抽出する。そして、特定部６０２は、前段のノード群のそれぞれについて、抽出した受信量データが示す受信量を集計することにより、直近３０分間に受信したデータの受信量を特定する。
特定された所定期間Ｔ内（例えば、直近３０分間）に受信したデータの受信量は、例えば、前段のノードＮｊと対応付けて、図８に示すような通信状況テーブル８００に記憶される。通信状況テーブル８００は、例えば、図３に示したメモリ３０２、ディスク３０４などの記憶装置により実現される。ここで、通信状況テーブル８００の記憶内容について説明する。
図８は、通信状況テーブル８００の記憶内容の一例を示す説明図である。図８において、通信状況テーブル８００は、送信元ＩＰおよび受信量のフィールドを有し、各フィールドに情報を設定することで、通信状況情報（例えば、通信状況情報８００－１，８００－２）をレコードとして記憶する。
ここで、送信元ＩＰは、前段のノードＮｊのＩＰアドレスを示す。受信量は、直近３０分間に前段のノードＮｊから受信したデータの受信量を示す（単位：ＭＢ）。
図６の説明に戻り、算出部６０３は、特定された前段のノード群のそれぞれから所定期間Ｔ内に受信したデータの受信量に基づいて、前段のノード群のそれぞれの受信量の合計に対する前段のノードＮｊの受信量の割合を算出する。具体的には、例えば、算出部６０３は、図８に示した通信状況テーブル８００を参照して、前段のノード群のそれぞれの受信量の比率を算出する。
そして、算出部６０３は、算出した前段のノード群のそれぞれの受信量の比率から、前段のノードＮｊの依存比率を算出する。ここで、前段のノードＮｊの依存比率は、ノードＮｉの前段のノードＮｊへの依存度合いを示す指標値であり、ノードＮｉと前段のノードＮｊとの関係の強さを示す。前段のノードＮｊの依存比率は、例えば、前段のノード群のそれぞれの受信量の合計に対する前段のノードＮｊの受信量の割合によって表すことができる。
図８の例では、送信元ＩＰ「１０．２４４．１．１２」のノードの受信量と送信元ＩＰ「１０．２４４．１．１３」のノードの受信量との比率は、「１：２」である。例えば、送信元ＩＰ「１０．２４４．１．１２」のノード（前段のノードＮｊ）から増強通知を受け付けたとする。この場合、前段のノードＮｊの依存比率は、「１／３」となる。
判断部６０４は、算出された割合と自ノードのリソースの使用状況とに基づいて、自ノードのリソースを増強するか否かを判断する。ここで、リソースの使用状況は、例えば、現在の使用リソース量および未使用リソース量を含む。リソースは、例えば、ＣＰＵ、メモリ、ストレージ、通信Ｉ／Ｆなどである。
現在の使用リソース量は、ノードＮｉの使用可能なリソースのうち、現在使用されているリソース量である（単位：［％］）。また、現在の未使用リソース量は、ノードＮｉの使用可能なリソースのうち、現在使用されていないリソース量である（単位：［％］）。リソースの使用状況は、例えば、ノードＮｉのＯＳから取得することができる。なお、ノードＮｉの使用可能なリソースは、例えば、ノードＮｉの全リソースであってもよく、また、ノードＮｉの一部のリソースであってもよい。
具体的には、例えば、判断部６０４は、自ノードのＯＳから、現在の使用リソース量および未使用リソース量を取得する。つぎに、判断部６０４は、算出された前段のノードＮｊの依存比率と現在の使用リソース量および未使用リソース量に基づいて、想定リソース消費量を算出する。
ここで、想定リソース消費量は、ノードＮｉの将来の使用リソース量を示す。より詳細に説明すると、例えば、判断部６０４は、下記式（１）を用いて、ノードＮｉの想定リソース消費量を算出することができる。ただし、Ｒ（済）は、ノードＮｉの現在の使用リソース量を示す。Ｒ（未）は、ノードＮｉの現在の未使用リソース量を示す。ｄＲは、前段のノードＮｊの依存比率を示す。
想定リソース消費量＝Ｒ（済）＋Ｒ（未）＊ｄＲ ・・・（１）
つぎに、判断部６０４は、算出した想定リソース消費量が増強条件を満たすか否かを判断する。より詳細に説明すると、例えば、判断部６０４は、図４に示した増強条件テーブル２２０を参照して、前段のノード数が２以上の場合の増強条件「想定リソース使用量が８０［％］超え」を特定する。
そして、判断部６０４は、算出した想定リソース消費量が８０［％］より大きいか否かを判断する。８０［％］は、増強条件を満たすか否かを判断するための閾値に相当する。ここで、想定リソース消費量が８０［％］より大きい場合、判断部６０４は、自ノードのリソースを増強すると判断する。一方、想定リソース消費量が８０［％］以下の場合には、判断部６０４は、自ノードのリソースを増強しないと判断する。
なお、前段のノードが１つの場合がある。この場合、判断部６０４は、例えば、増強条件テーブル２２０を参照して、前段のノード数が１の場合の増強条件「現在のリソース使用量が７０［％］超え」を特定する。そして、判断部６０４は、取得した自ノードの現在のリソース使用量が７０［％］より大きいか否かを判断する。ここで、現在のリソース使用量が７０［％］より大きい場合、判断部６０４は、自ノードのリソースを増強すると判断する。一方、現在のリソース使用量が７０［％］以下の場合には、判断部６０４は、自ノードのリソースを増強しないと判断する。
ノードＮｉのリソースを増強するか否かの判断例については、図９～図１１を用いて後述する。
また、判断部６０４は、例えば、回帰分析やニューラルネットワークなどを用いた機械学習を利用して、自ノードのリソースを増強するか否かを判断することにしてもよい。なお、機械学習を利用して、自ノードのリソースを増強するか否かを判断する場合の処理例については、図１３を用いて後述する。
増強制御部６０５は、自ノードのリソースを増強すると判断された場合、自ノードのリソースの増強を行う。具体的には、例えば、増強制御部６０５は、自ノードのリソースを増強すると判断された場合に、所定の処理（キューイング処理、ストリームデータ処理など）を実行するために割り当てられるリソース量を増加させることにしてもよい。
リソース量の増加分は、例えば、予め決められていてもよい。また、リソース量の増加分は、想定リソース消費量と閾値（例えば、８０［％］）との差分に応じて決定することにしてもよい。また、前段のノードが１つの場合、リソース量の増加分は、現在のリソース量と閾値（例えば、７０［％］）との差分に応じて決定することにしてもよい。
より詳細に説明すると、例えば、ノードＮｉが仮想マシンやコンテナによって実現されるとする。また、増強するリソースを「ＣＰＵリソース」とする。この場合、増強制御部６０５は、例えば、ノードＮｉに割り当てる仮想ＣＰＵ（ＣＰＵリソース）の数を、予め決められた数分増加させることにしてもよい。
また、増強制御部６０５は、例えば、自ノードのリソースを増強すると判断された場合に、自ノードのリソースの増強指示を、図２に示した管理端末２０１や不図示のリソース制御装置に出力することにしてもよい。リソースの増強指示には、例えば、ノードＮｉのＩＰアドレスや増強対象のリソース情報（リソースの種別、リソース量の増加分など）が含まれる。
例えば、データ処理システム２００の管理者やリソース制御装置（不図示）は、ノードＮｉからの増強指示に応じて、ノードＮｉのリソースの増強を行うことができる。これにより、前段のノードＮｊが増強されたときに、その後段のノードＮｉがリソース不足となる前に、ノードＮｉのリソース増強を行うことができる。
なお、判断部６０４および増強制御部６０５の処理は、例えば、ノードＮｉのリソースの種別（ＣＰＵ、メモリ、ストレージ、通信Ｉ／Ｆなど）ごとに実行されることにしてもよい。また、判断部６０４および増強制御部６０５の処理は、例えば、ノードＮｉの特定の種別のリソース（例えば、ＣＰＵ）についてのみ実行されることにしてもよい。
また、増強制御部６０５は、自ノードのリソースを増強後に、例えば、前段のノード群からのデータの流入量の低下などにより、自ノードの使用リソース量が所定量以下まで低下した場合、自ノードのリソースの一部を解放することにしてもよい。
（リソース増強の判断例）
つぎに、図９～図１１を用いて、ノードＮｉのリソースを増強するか否かの判断例について説明する。ここでは、図５に示したデータ処理システム２００を例に挙げて説明する。また、ノードＮｉを「ノードＮ３」とし、前段のノード群を「ノードＮ１，Ｎ２」とする。
図９は、リソース増強の判断例を示す説明図（その１）である。図９において、ノードＮ３と、ノードＮ３の前段のノード群Ｎ１，Ｎ２が示されている。ノードＮ１は、メッセージキュー１のサービスを実行する。ノードＮ２は、メッセージキュー２のサービスを実行する。ノードＮ３は、データ処理１のサービスを実行する。
メッセージキュー１，２のサービスは、例えば、受信したセンサデータをバッファリングして、後段のノードＮ３に順次出力する。データ処理１のサービスは、前段のノード群Ｎ１，Ｎ２のそれぞれから受信したデータに対してストリームデータ処理を実行して結果を後段のノード（例えば、図５に示したノードＮ４）に出力する。
また、通信状況テーブル９００には、前段のノード群Ｎ１，Ｎ２のそれぞれから受信した直近３０分間のデータの受信量が示されている。なお、図９～図１１では、ノードＮ１，Ｎ２の識別子として、ノードＮ１，Ｎ２の「送信元ＩＰ」のかわりに、「Ｎ１，Ｎ２」を表記している。
ここで、ノードＮ３のノードＮ１からの受信量は、「１０［ＭＢ］」である。また、ノードＮ３のノードＮ２からの受信量は、「２０［ＭＢ］」である。この場合、ノードＮ３は、例えば、前段のノード群Ｎ１，Ｎ２のそれぞれの受信量の比率から、前段のノードＮ１，Ｎ２のそれぞれの依存比率を算出する。
ここでは、前段のノードＮ１の依存比率は、「１／３」となる。また、前段のノードＮ２の依存比率は、「２／３」となる。また、ノードＮ３の現在の使用リソース量を「３０［％］」とし、ノードＮ３の現在の未使用リソース量を「７０［％］」とする。また、ノードＮ３について、前段のノード数が２以上の場合の増強条件を「想定リソース使用量が８０［％］超え」とする。
まず、前段のノード群Ｎ１，Ｎ２のうちノードＮ１が増強された場合を想定する。この場合、ノードＮ３は、上記式（１）を用いて、前段のノードＮ１の依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。想定リソース消費量は、以下のようになる。
想定リソース消費量＝３０＋７０＊（１／３）＝５３．３［％］
ノードＮ３は、算出した想定リソース消費量が８０［％］以下のため、前段のノードＮ１と連動して、自ノードのリソースを増強しないと判断する。
つぎに、前段のノード群Ｎ１，Ｎ２のうちノードＮ２が増強された場合を想定する。この場合、ノードＮ３は、上記式（１）を用いて、前段のノードＮ２の依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。想定リソース消費量は、以下のようになる。
想定リソース消費量＝３０＋７０＊（２／３）＝７６．６［％］
ノードＮ３は、算出した想定リソース消費量が８０［％］以下のため、前段のノードＮ２と連動して、自ノードのリソースを増強しないと判断する。
図１０は、リソース増強の判断例を示す説明図（その２）である。図１０において、ノードＮ３と、ノードＮ３の前段のノード群Ｎ１，Ｎ２が示されている。また、通信状況テーブル１０００には、前段のノード群Ｎ１，Ｎ２のそれぞれから受信した直近３０分間のデータの受信量が示されている。
ここで、ノードＮ３のノードＮ１からの受信量は、「１０［ＭＢ］」である。また、ノードＮ３のノードＮ２からの受信量は、「２０［ＭＢ］」である。この場合、ノードＮ３は、例えば、前段のノード群Ｎ１，Ｎ２のそれぞれの受信量の比率から、前段のノードＮ１，Ｎ２のそれぞれの依存比率を算出する。
ここでは、前段のノードＮ１の依存比率は、「１／３」となる。また、前段のノードＮ２の依存比率は、「２／３」となる。また、ノードＮ３の現在の使用リソース量を「５０［％］」とし、ノードＮ３の現在の未使用リソース量を「５０［％］」とする。また、ノードＮ３について、前段のノード数が２以上の場合の増強条件を「想定リソース使用量が８０［％］超え」とする。
まず、前段のノード群Ｎ１，Ｎ２のうちノードＮ１が増強された場合を想定する。この場合、ノードＮ３は、上記式（１）を用いて、前段のノードＮ１の依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。想定リソース消費量は、以下のようになる。
想定リソース消費量＝５０＋５０＊（１／３）＝６６．６［％］
ノードＮ３は、算出した想定リソース消費量が８０［％］以下のため、前段のノードＮ１と連動して、自ノードのリソースを増強しないと判断する。
つぎに、前段のノード群Ｎ１，Ｎ２のうちノードＮ２が増強された場合を想定する。この場合、ノードＮ３は、上記式（１）を用いて、前段のノードＮ２の依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。想定リソース消費量は、以下のようになる。
想定リソース消費量＝５０＋５０＊（２／３）＝８３．３［％］
ノードＮ３は、算出した想定リソース消費量が８０［％］を超えるため、前段のノードＮ２と連動して、自ノードのリソースを増強すると判断する。
図１１は、リソース増強の判断例を示す説明図（その３）である。図１１において、ノードＮ３と、ノードＮ３の前段のノード群Ｎ１，Ｎ２が示されている。また、通信状況テーブル１１００には、前段のノード群Ｎ１，Ｎ２のそれぞれから受信した直近３０分間のデータの受信量が示されている。
ここで、ノードＮ３のノードＮ１からの受信量は、「２０［ＭＢ］」である。また、ノードＮ３のノードＮ２からの受信量は、「１０［ＭＢ］」である。この場合、ノードＮ３は、例えば、前段のノード群Ｎ１，Ｎ２のそれぞれの受信量の比率から、前段のノードＮ１，Ｎ２のそれぞれの依存比率を算出する。
ここでは、前段のノードＮ１の依存比率は、「２／３」となる。また、前段のノードＮ２の依存比率は、「１／３」となる。また、ノードＮ３の現在の使用リソース量を「５０［％］」とし、ノードＮ３の現在の未使用リソース量を「５０［％］」とする。また、ノードＮ３について、前段のノード数が２以上の場合の増強条件を「想定リソース使用量が８０［％］超え」とする。
まず、前段のノード群Ｎ１，Ｎ２のうちノードＮ１が増強された場合を想定する。この場合、ノードＮ３は、上記式（１）を用いて、前段のノードＮ１の依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。想定リソース消費量は、以下のようになる。
想定リソース消費量＝５０＋５０＊（２／３）＝８３．３［％］
ノードＮ３は、算出した想定リソース消費量が８０［％］を超えるため、前段のノードＮ１と連動して、自ノードのリソースを増強すると判断する。
つぎに、前段のノード群Ｎ１，Ｎ２のうちノードＮ２が増強された場合を想定する。この場合、ノードＮ３は、上記式（１）を用いて、前段のノードＮ２の依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。想定リソース消費量は、以下のようになる。
想定リソース消費量＝５０＋５０＊（１／３）＝６６．６［％］
ノードＮ３は、算出した想定リソース消費量が８０［％］以下のため、前段のノードＮ２と連動して、自ノードのリソースを増強しないと判断する。
（データ処理システム２００の動作例）
つぎに、図１２を用いて、データ処理システム２００の動作例について説明する。ここでは、データ処理システム２００が多段構成で複数経路構成の場合について説明する。
図１２は、データ処理システム２００の動作例を示す説明図である。図１２において、データ処理システム２００は、ノードＮ１～Ｎ８を含む。ノードＮ１は、メッセージキュー１のサービスを実行する。ノードＮ２は、メッセージキュー２のサービスを実行する。ノードＮ３は、データ処理１のサービスを実行する。
ノードＮ４は、メッセージキュー４のサービスを実行する。ノードＮ５は、メッセージキュー３のサービスを実行する。ノードＮ６は、データ処理２のサービスを実行する。ノードＮ７は、メッセージキュー５のサービスを実行する。ノードＮ８は、データ処理３のサービスを実行する。
ここで、ノードＮ１，Ｎ２は、ノードＮ３の前段のノード群である。ノードＮ３は、前段のノード群Ｎ１，Ｎ２のいずれかのノードから増強通知を受け付けたことに応じて、前段のノード群Ｎ１，Ｎ２のそれぞれの受信量の比率から、前段のノードＮ１，Ｎ２のそれぞれの依存比率を算出する。つぎに、ノードＮ３は、増強ノードの依存比率と自ノードの現在の使用リソース量および未使用リソース量から、想定リソース消費量を算出する。なお、増強ノードは、増強通知を受け付けたノードである。そして、ノードＮ３は、想定リソース消費量が増強条件を満たす場合に、自ノードのリソースを増強すると判断する。
また、ノードＮ２，Ｎ５は、ノードＮ６の前段のノード群である。ノードＮ６は、前段のノード群Ｎ２，Ｎ５のいずれかのノードから増強通知を受け付けたことに応じて、前段のノード群Ｎ２，Ｎ５のそれぞれの受信量の比率から、前段のノードＮ２，Ｎ５のそれぞれの依存比率を算出する。つぎに、ノードＮ６は、増強ノードの依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。そして、ノードＮ６は、想定リソース消費量が増強条件を満たす場合に、自ノードのリソースを増強すると判断する。
また、ノードＮ３，Ｎ６は、ノードＮ４の前段のノード群である。ノードＮ４は、前段のノード群Ｎ３，Ｎ６のいずれかのノードから増強通知を受け付けたことに応じて、前段のノード群Ｎ３，Ｎ６のそれぞれの受信量の比率から、前段のノードＮ３，Ｎ６のそれぞれの依存比率を算出する。つぎに、ノードＮ４、増強ノードの依存比率と自ノードの現在の使用リソース量および未使用リソース量から、自ノードの想定リソース消費量を算出する。そして、ノードＮ４は、想定リソース消費量が増強条件を満たす場合に、自ノードのリソースを増強すると判断する。
このように、データ処理システム２００内の各ノードＮｉは、前段のノードＮｊのリソース増強が行われたタイミングで、自ノードでのリソース増強の要否を判断することで、リソース増強の必要性を後段のノードに伝播させていくことができる。
（機械学習を利用したリソース増強の判断処理例）
つぎに、図１３を用いて、回帰分析やニューラルネットワークを用いた機械学習を利用して、自ノードのリソースを増強するか否かを判断する場合の処理例について説明する。
図１３は、機械学習を利用したリソース増強の判断処理例を示す説明図である。学習フェーズにおいて、判断部６０４は、前段のノードＮｊのリソースが増強された第１の時点の、前段のノードＮｊの依存比率と、自ノードのリソースの使用状況とを取得する。前段のノードＮｊの依存比率は、ノードＮｉの前段のノード群のそれぞれの受信量（例えば、第１の時点の直近３０分間の受信量）の合計に対する前段のノードＮｊの受信量の割合に相当する。
また、判断部６０４は、第１の時点以降の第２の時点の自ノードのリソースの使用状況を取得する。第２の時点は、例えば、第１の時点から、数分～数十分経過後の時点である。そして、判断部６０４は、取得した第１の時点の前段のノードＮｊの依存比率と自ノードのリソースの使用状況と第２の時点の自ノードのリソースの使用状況とを教師データとして機械学習を行って、リソース変化量モデルＭを生成する。
ここで、リソース変化量モデルＭは、前段のノードＮｊのリソースが増強されたときの前段のノードＮｊの依存比率と自ノードのリソースの使用状況とを入力として、将来のリソースの使用状況を出力する予測モデルである。
なお、図１３中、前段のノードＮｊの依存比率を「増強サービスへの依存度」と表記し、自ノードのリソースの使用状況を「リソース使用状況」と表記し、将来の自ノードのリソースの使用状況を「リソース変化量」と表記している。
予測フェーズにおいて、判断部６０４は、生成したリソース変化量モデルＭを用いて、算出された前段のノードＮｊの依存比率と自ノードのリソースの使用状況（現在）とに基づいて、自ノードのリソースを増強するか否かを判断する。なお、算出された前段のノードＮｊの依存比率とは、前段のノードＮｊからの増強通知に応じて算出部６０３によって算出された依存比率である。
具体的には、例えば、判断部６０４は、前段のノードＮｊの依存比率と自ノードのリソースの使用状況（現在）とをリソース変化量モデルＭに入力することによって、想定リソース消費量を算出する。前段のノードＮｊの依存比率と自ノードのリソースの使用状況（現在）は、図１３中、実測データに相当する。つぎに、判断部６０４は、算出した想定リソース消費量が増強条件を満たすか否かを判断する。
より詳細に説明すると、例えば、判断部６０４は、増強条件テーブル２２０を参照して、前段のノード数が２以上の場合の増強条件「想定リソース使用量が８０［％］超え」を特定する。そして、判断部６０４は、算出した想定リソース消費量が８０［％］より大きいか否かを判断する。ここで、想定リソース消費量が８０［％］より大きい場合、判断部６０４は、自ノードのリソースを増強すると判断する。一方、想定リソース消費量が８０［％］以下の場合には、判断部６０４は、自ノードのリソースを増強しないと判断する。
これにより、前段のノードＮｊが増強されたときの実際のリソースの使用状況の変化をもとに、将来のリソースの使用状況を予測することが可能となり、前段のノードＮｊが増強されたときの想定リソース消費量の予測精度の向上を図ることができる。
なお、リソース変化量モデルＭは、例えば、前段のノードＮｊのリソースが増強されるたびに、過去に増強されたときの前段のノードＮｊの依存比率とリソースの使用状況と、その増強から一定時間経過後のリソースの使用状況をもとに逐次更新されることにしてもよい。また、ノードＮｉにおいて、自ノードのリソースを増強するか否かを判断するにあたり、例えば、前段のノードＮｊのリソースが増強された最初の数回は上記式（１）を用いて判断し、それ以降はリソース変化量モデルＭを用いて判断することにしてもよい。
（ノードＮｉの増強制御処理手順）
つぎに、図１４を用いて、ノードＮｉの増強制御処理手順について説明する。
図１４は、ノードＮｉの増強制御処理手順の一例を示すフローチャートである。図１４において、ノードＮｉは、ノードＮ１～Ｎｎのうちの自ノードの前段のノードＮｊから増強通知を受け付けたか否かを判断する（ステップＳ１４０１）。ここで、ノードＮｉは、前段のノードＮｊから増強通知を受け付けるのを待つ（ステップＳ１４０１：Ｎｏ）。
ノードＮｉは、前段のノードＮｊから増強通知を受け付けた場合（ステップＳ１４０１：Ｙｅｓ）、自ノードの前段のノード群のそれぞれから所定期間Ｔ内に受信したデータの受信量を特定する（ステップＳ１４０２）。以下、前段のノードＮｊを「増強ノードＮｊ」と表記する場合がある。
そして、ノードＮｉは、特定した前段のノード群のそれぞれから所定期間Ｔ内に受信したデータの受信量に基づいて、前段のノード群のそれぞれの依存比率を算出する（ステップＳ１４０３）。つぎに、ノードＮｉは、自ノードの現在のリソースの使用状況を取得する（ステップＳ１４０４）。
そして、ノードＮｉは、算出した増強ノードＮｊの依存比率と、取得した自ノードの現在のリソースの使用状況とに基づいて、自ノードの想定リソース消費量を算出する（ステップＳ１４０５）。つぎに、ノードＮｉは、増強条件テーブル２２０を参照して、算出した想定リソース消費量が閾値を超えたか否かを判断する（ステップＳ１４０６）。
ここで、想定リソース消費量が閾値以下の場合（ステップＳ１４０６：Ｎｏ）、ノードＮｉは、本フローチャートによる一連の処理を終了する。一方、想定リソース消費量が閾値を超えた場合（ステップＳ１４０６：Ｙｅｓ）、ノードＮｉは、自ノードのリソース増強を行って（ステップＳ１４０７）、本フローチャートによる一連の処理を終了する。
これにより、ノードＮｉは、増強ノードＮｊの依存比率をもとに、前段のリソース増強が自ノードのリソース不足を引き起こすと予測した場合に、前段のリソース増強に連動して、自ノードのリソースを増強することができる。
以上説明したように、実施の形態にかかるノードＮｉによれば、ノードＮ１～Ｎｎのうち自ノードの前段のノードＮｊから増強通知を受け付けた場合、前段のノード群のそれぞれから所定期間Ｔ内に受信したデータの受信量に基づいて、前段のノードＮｊ（増強ノード）の依存比率を算出することができる。前段のノードＮｊの依存比率は、前段のノード群のそれぞれの受信量の合計に対する、前段のノードＮｊの受信量の割合である。所定期間Ｔは、増強通知を受け付けた時点を含む一定時間の期間、例えば、直近３０分の期間である。
これにより、ノードＮｉは、ノード間の直近のネットワーク通信量をもとに、前段のノードＮｊへの依存度合いを判断することができる。
また、ノードＮｉによれば、算出したノードＮｊの依存比率と自ノードのリソースの使用状況とに基づいて、自ノードのリソースを増強するか否かを判断することができる。
これにより、ノードＮｉは、前段のノードＮｊへの依存度合いをもとに、前段のノードＮｊの増強が自ノードにどのような影響を及ぼすかを推測して、前段のノードＮｊのリソース増強に連動して、自ノードのリソースを増強するか否かを判断することができる。このため、データ処理システム２００において、各ノードＮｉは、自ノードのリソース増強を行う適切なタイミングを判断することができる。
また、ノードＮｉによれば、前段のノードＮｊの依存比率と、自ノードの現在の使用リソース量および未使用リソース量に基づいて、自ノードの想定リソース消費量（将来の使用リソース量）を算出し、算出した想定リソース消費量が閾値を超える場合に、自ノードのリソースを増強すると判断することができる。
これにより、ノードＮｉは、前段のノードＮｊの依存比率に応じて、自ノードの未使用リソースが使用されると仮定して、想定リソース消費量（将来の使用リソース量）を推測することができる。
また、ノードＮｉによれば、前段のノードＮｊのリソースが増強された第１の時点の前段のノードＮｊの依存比率と自ノードのリソースの使用状況と、第１の時点以降の第２の時点の自ノードのリソースの使用状況を取得することができる。つぎに、ノードＮｉによれば、取得した第１の時点の前段のノードＮｊの依存比率、自ノードのリソースの使用状況、および第２の時点の自ノードのリソースの使用状況を教師データとして機械学習を行って、リソース変化量モデルＭを生成することができる。リソース変化量モデルＭは、前段のノードＮｊのリソースが増強されたときの前段のノードＮｊの依存比率と自ノードのリソースの使用状況とを入力として、将来のリソースの使用状況を出力する予測モデルである。
これにより、過去に前段のノードＮｊが増強されたときの実際のリソースの使用状況の変化をもとに、将来のリソースの使用状況を予測するモデルを生成でき、前段のノードＮｊが増強されたときの想定リソース消費量の予測精度の向上を図ることができる。
また、ノードＮｉによれば、生成したリソース変化量モデルＭを用いて、前段のノードＮｊから増強通知を受け付けた場合に算出した前段のノードＮｊの依存比率と自ノードのリソースの使用状況（現在）とに基づいて、自ノードのリソースを増強するか否かを判断することができる。
これにより、前段のノードＮｊが増強されたときの自ノードの将来の使用リソース量を精度よく推測することができる。
また、ノードＮｉによれば、データの受信量を、バイトサイズ、または、メッセージ数によって表すことができる。
これにより、ノードＮｉは、ノード間で送受信されるデータの特徴に応じて、バイトサイズ、または、メッセージ数のいずれの単位でデータ量を扱うかを切り替えることができる。例えば、ノードＮｉは、ノード間で１回の送受信でやり取りされるデータ量がほぼ一定の場合、メッセージ数でデータ量を扱うことで、バイトサイズよりも抽象化した値となり、自ノードの処理負荷を軽減することができる。また、ノードＮｉは、ノード間で１回の送受信でやり取りされるデータ量が変化する場合は、バイトサイズでデータ量を扱うことで、前段のノード群のそれぞれの受信量の比率を正確に把握することができる。
これらのことから、実施の形態にかかるデータ処理システム２００によれば、ストリームデータ処理を含むデジタルツインサービスなどにおいて、ノードＮｉの前段のノードＮｊのリソースが増強されたときに、ノードＮｉにおける将来のリソース不足を予測して、事前にリソース増強を行うことが可能となる。これにより、あるサービスが増強されたときに、その後段のサービスへのデータの流入量が増加することにより生じるリソース不足を回避し、サービスの品質低下を防ぐことができる。
また、データ処理システム２００によれば、例えば、従来技術１のように、個々のサービスが、自サービスの現在の使用済みリソースのみをもとにリソース増強を実施する場合に比べて、リソース不足状態を短くすることができ、利用者の利便性の向上を図ることができる。
また、データ処理システム２００によれば、例えば、従来技術２のように、サービス全体のリソースを一括で増強する場合に比べて、過剰な増強を避けることができ、システム運用にかかるコストを削減することができる。
また、データ処理システム２００によれば、例えば、従来技術３のように、サービス間の連携に起因する様々なパラメータ設定を事前にする必要がなく、構築者（例えば、データ処理システム２００の管理者）の手間を削減することができる。また、最新のネットワーク通信量を基準にして、リソース増強の要否を判断することができるため、リソース不足（前段のノードＮｊ）が発生した状況に応じた判断が可能となり、運用者の運用コストを削減することができる。
なお、本実施の形態で説明したデータ処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本データ処理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本データ処理プログラムは、インターネット等のネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
（付記１）受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置のうちのいずれかの処理装置に、
前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、
算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
処理を実行させることを特徴とするデータ処理プログラム。
（付記２）前記リソースの使用状況は、現在の使用リソース量および未使用リソース量を含み、
前記判断する処理は、
前記割合と前記現在の使用リソース量および未使用リソース量に基づいて、自装置の将来の使用リソース量を算出し、
算出した前記将来の使用リソース量が閾値を超える場合に、自装置のリソースを増強すると判断する、
ことを特徴とする付記１に記載のデータ処理プログラム。
（付記３）前記第１の処理装置のリソースが増強された第１の時点の前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合と自装置のリソースの使用状況と、前記第１の時点以降の第２の時点の自装置のリソースの使用状況とを取得し、
取得した前記第１の時点の前記割合と自装置のリソースの使用状況と、前記第２の時点の自装置のリソースの使用状況とを教師データとして機械学習を行って、前記第１の処理装置のリソースが増強されたときの前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合と自装置のリソースの使用状況とを入力として、将来のリソースの使用状況を出力する予測モデルを生成する、
処理を前記いずれかの処理装置に実行させ、
前記判断する処理は、
生成した前記予測モデルを用いて、算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
ことを特徴とする付記１または２に記載のデータ処理プログラム。
（付記４）前記受信量は、バイトサイズ、または、メッセージ数によって表される、ことを特徴とする付記１～３のいずれか一つに記載のデータ処理プログラム。
（付記５）前記所定期間は、前記通知を受け付けた時点を含む一定時間の期間である、ことを特徴とする付記１～４のいずれか一つに記載のデータ処理プログラム。
（付記６）受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置のうちのいずれかの処理装置が、
前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、
算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
処理を実行することを特徴とするデータ処理方法。
（付記７）受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置を含み、
前記複数の処理装置のうちのいずれかの処理装置は、
前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、
算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
ことを特徴とするデータ処理システム。
１０１，１０２，１０３ 処理装置
２００ データ処理システム
２０１ 管理端末
２１０ ネットワーク
２２０ 増強条件テーブル
３００ バス
３０１ ＣＰＵ
３０２ メモリ
３０３ ディスクドライブ
３０４ ディスク
３０５ 通信Ｉ／Ｆ
３０６ 可搬型記録媒体Ｉ／Ｆ
３０７ 可搬型記録媒体
６０１ 受付部
６０２ 特定部
６０３ 算出部
６０４ 判断部
６０５ 増強制御部
７００ 受信量収集テーブル
８００，９００，１０００，１１００ 通信状況テーブル
Ｎ１～Ｎｎ，Ｎｉ ノード

Claims (6)

  1. 受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置のうちのいずれかの処理装置に、
    前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、
    算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
    処理を実行させることを特徴とするデータ処理プログラム。
  2. 前記リソースの使用状況は、現在の使用リソース量および未使用リソース量を含み、
    前記判断する処理は、
    前記割合と前記現在の使用リソース量および未使用リソース量に基づいて、自装置の将来の使用リソース量を算出し、
    算出した前記将来の使用リソース量が閾値を超える場合に、自装置のリソースを増強すると判断する、
    ことを特徴とする請求項１に記載のデータ処理プログラム。
  3. 前記第１の処理装置のリソースが増強された第１の時点の前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合と自装置のリソースの使用状況と、前記第１の時点以降の第２の時点の自装置のリソースの使用状況とを取得し、
    取得した前記第１の時点の前記割合と自装置のリソースの使用状況と、前記第２の時点の自装置のリソースの使用状況とを教師データとして機械学習を行って、前記第１の処理装置のリソースが増強されたときの前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合と自装置のリソースの使用状況とを入力として、将来のリソースの使用状況を出力する予測モデルを生成する、
    処理を前記いずれかの処理装置に実行させ、
    前記判断する処理は、
    生成した前記予測モデルを用いて、算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
    ことを特徴とする請求項１または２に記載のデータ処理プログラム。
  4. 前記受信量は、バイトサイズ、または、メッセージ数によって表される、ことを特徴とする請求項１～３のいずれか一つに記載のデータ処理プログラム。
  5. 受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置のうちのいずれかの処理装置が、
    前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、
    算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
    処理を実行することを特徴とするデータ処理方法。
  6. 受信したデータに対して所定の処理を実行して結果を出力する複数の処理装置を含み、
    前記複数の処理装置のうちのいずれかの処理装置は、
    前記複数の処理装置のうちの自装置の前段の処理装置群の第１の処理装置からリソースを増強したことの通知を受け付けた場合、前記処理装置群のそれぞれから所定期間内に受信したデータの受信量に基づいて、前記処理装置群のそれぞれの受信量の合計に対する前記第１の処理装置の受信量の割合を算出し、
    算出した前記割合と自装置のリソースの使用状況とに基づいて、自装置のリソースを増強するか否かを判断する、
    ことを特徴とするデータ処理システム。
JP2021100932A 2021-06-17 2021-06-17 データ処理プログラム、データ処理方法およびデータ処理システム Pending JP2023000232A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021100932A JP2023000232A (ja) 2021-06-17 2021-06-17 データ処理プログラム、データ処理方法およびデータ処理システム
US17/712,388 US20220407821A1 (en) 2021-06-17 2022-04-04 Computer-readable recording medium storing data processing program, data processing method, and data processing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2021100932A JP2023000232A (ja) 2021-06-17 2021-06-17 データ処理プログラム、データ処理方法およびデータ処理システム

Publications (1)

Publication Number Publication Date
JP2023000232A true JP2023000232A (ja) 2023-01-04

Family

ID=84489637

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021100932A Pending JP2023000232A (ja) 2021-06-17 2021-06-17 データ処理プログラム、データ処理方法およびデータ処理システム

Country Status (2)

Country Link
US (1) US20220407821A1 (ja)
JP (1) JP2023000232A (ja)

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6525737B1 (en) * 1998-08-20 2003-02-25 Apple Computer, Inc. Graphics processor with pipeline state storage and retrieval
US6466980B1 (en) * 1999-06-17 2002-10-15 International Business Machines Corporation System and method for capacity shaping in an internet environment
US8650470B2 (en) * 2003-03-20 2014-02-11 Arm Limited Error recovery within integrated circuit
US20150081470A1 (en) * 2013-09-18 2015-03-19 W.W. Grainger, Inc. Methods and apparatus for providing supplemental content in communications sharing a webpage
EP3128423A1 (en) * 2015-08-06 2017-02-08 Hewlett-Packard Enterprise Development LP Distributed event processing
US10681110B2 (en) * 2016-05-04 2020-06-09 Radware, Ltd. Optimized stream management
US10380567B2 (en) * 2016-09-30 2019-08-13 Capital One Services, Llc Systems and methods for providing cash redemption to a third party
US10826840B1 (en) * 2017-07-23 2020-11-03 Barefoot Networks, Inc. Multiple copies of stateful tables
US11360804B2 (en) * 2018-06-29 2022-06-14 International Business Machines Corporation Resource management for parent child workload
US10901797B2 (en) * 2018-11-06 2021-01-26 International Business Machines Corporation Resource allocation
TWI725744B (zh) * 2020-02-19 2021-04-21 先智雲端數據股份有限公司 透過多層次相關性建立系統資源預測及資源管理模型的方法
US20210312336A1 (en) * 2020-04-03 2021-10-07 International Business Machines Corporation Federated learning of machine learning model features

Also Published As

Publication number Publication date
US20220407821A1 (en) 2022-12-22

Similar Documents

Publication Publication Date Title
CN112153700B (zh) 一种网络切片资源管理方法及设备
WO2015192627A1 (zh) 一种业务调度的方法、装置及系统
CN104901989B (zh) 一种现场服务提供系统及方法
WO2015101089A1 (zh) 大规模集群的管理方法、装置和系统
JP6823670B2 (ja) 複雑なシステムにおけるボトルネックの検出及び予測
CN112148468B (zh) 一种资源调度方法、装置、电子设备及存储介质
CN109615022B (zh) 模型上线配置方法和装置
CN110516714B (zh) 一种特征预测方法、系统及引擎
JP7006607B2 (ja) 分散処理システム、分散処理方法、及び記録媒体
CN111966289A (zh) 基于Kafka集群的分区优化方法和系统
CN112925637A (zh) 用于一边缘运算网络的负载平衡装置及方法
US11663505B2 (en) Estimating performance and required resources from shift-left analysis
CN114065864A (zh) 联邦学习方法、联邦学习装置、电子设备以及存储介质
CN114253695A (zh) 一种计算节点资源信息更新方法、节点和存储介质
WO2021238508A1 (zh) 一种数据处理的方法、装置和设备
JP2023000232A (ja) データ処理プログラム、データ処理方法およびデータ処理システム
CN114035906A (zh) 虚拟机迁移方法、装置、电子设备及存储介质
JPWO2016084327A1 (ja) 資源予測装置、資源予測方法、資源予測プログラムおよび分散処理システム
CN113364652A (zh) 网卡流量测试方法、装置、网络设备、系统及可读介质
Kuppusamy et al. Switch bandwidth congestion prediction in cloud environment
CN113760176A (zh) 数据存储方法和装置
CN112714037A (zh) 一种线上服务质量的保障性能评估方法、装置及设备
WO2021250830A1 (ja) 要求通信品質推定装置、要求通信品質推定方法及び要求通信品質推定プログラム
CN111381956B (zh) 一种任务处理的方法、装置及云分析系统
CN113839794B (zh) 数据处理方法、装置、设备及存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240307