JP2022030101A - 情報処理プログラム、情報処理方法、情報処理装置 - Google Patents

Abstract

【課題】ロボットの実行に関する処理負荷に応じてリソースを効率的に利用する。【解決手段】一実施形態に係る情報処理装置は、第１のサーバによる制御対象の複数のロボットの実行スケジュールと、複数のロボットの実行に関する処理で使用されるリソースの量とに基づいて、リソースの使用が所定の使用量を超える処理負荷の発生を予測する予測部と、所定の使用量を超える処理負荷の発生前に第２のサーバの起動が完了するようにリクエストを管理サーバに送信する送信部と、複数のロボットのうち、処理負荷の発生期間に実行されるロボットのうちの一部のロボットに関する情報を第２のサーバに提供して、第２のサーバに一部のロボットの実行に関する処理を実行させる、提供部と、を含む。【選択図】図１

Description

本発明は、情報処理プログラム、情報処理方法、情報処理装置に関する。

近年、ＲＰＡ（Robotics Process Automation）技術を使用し、様々な業務の自動化が進められている。ＲＰＡ製品は、業務自動化のためのロボットを実行する環境およびマシンなどに応じて、例えば、サーバ型とデスクトップ型の２種に大別することができる。サーバ型は、例えば、サーバにてロボットを集中管理し、サーバでロボットを実行する形式である。デスクトップ型は、例えば、業務を担当するユーザが使用する端末にロボットを配備して実行する形式である。

また、処理のためのリソースの管理に関連する技術が知られている（例えば、特許文献１および特許文献２）。

特開２０１９－００８４５４号公報 特開２０１３－１６４７５０号公報

しかしながら、例えば、サーバに複数のロボットを配備して実行する場合に、ロボットの実行にかかる処理負荷が大きく、サーバのリソースが不足することがある。その結果、ロボットの実行スケジュールに遅れが発生することがある。

１つの側面では、本発明は、ロボットの実行に関する処理の負荷に応じてリソースを効率的に利用することを目的とする。

本発明の一つの態様の情報処理装置は、第１のサーバによる制御対象の複数のロボットの実行スケジュールと、複数のロボットの実行に関する処理で使用されるリソースの量とに基づいて、リソースの使用が所定の使用量を超える処理負荷の発生を予測する予測部と、所定の使用量を超える処理負荷の発生前に第２のサーバの起動が完了するようにリクエストを管理サーバに送信する送信部と、複数のロボットのうち、処理負荷の発生期間に実行されるロボットのうちの一部のロボットに関する情報を第２のサーバに提供して、第２のサーバに一部のロボットの実行に関する処理を実行させる、提供部と、を含む。

ロボットの実行に関する処理負荷に応じてリソースを効率的に利用することができる。

実施形態に係るＲＰＡシステムの一例を示す図である。 実施形態に係るサーバのブロック構成を例示する図である。 実施形態に係る副系サーバのブロック構成を例示する図である。 実施形態に係るサーバ情報を例示する図である。 実施形態に係る実行スケジュールを例示する図である。 実施形態に係るリソースの不足発生期間の特定を例示する図である。 実施形態に係るサーバによるロボット実行処理の動作フローを例示する図である。 実施形態に係る副系サーバによるロボット実行処理の動作フローを例示する図である。 変形例に係る構成候補情報を例示する図である。 第２の実施形態に係るリクエストの履歴情報を例示する図である。 第２の実施形態に係る稼働スケジュールの生成処理の動作フローを例示する図である。 第２の実施形態に係る稼働スケジュールを例示する図である。 第２の実施形態に係るサーバによるロボット実行処理の動作フローを例示する図である。 第３の実施形態に係るＲＰＡシステムを例示する図である。 実施形態に係るサーバおよび副系サーバを実現するためのコンピュータのハードウェア構成を例示する図である。

以下、図面を参照しながら、本発明のいくつかの実施形態について詳細に説明する。なお、複数の図面において対応する要素には同一の符号を付す。

上述のように、例えば、サーバに複数のロボットを配備して実行する場合に、ロボットの実行にかかる処理負荷が大きく、ＣＰＵ（Central Processing Unit）数およびメモリ容量などのサーバのリソースが不足することがある。一例として、実行スケジュールにおいて複数のロボットの実行が重なると、サーバで遅滞なく処理を実行する上で許容可能なリソースの使用量を超えてしまいリソースが足りなくなることがある。その結果、ロボットの実行に実行スケジュールからの遅れが発生することがある。

例えば、同時期に実行されるロボットの数がサーバに備えられたＣＰＵ数よりも多くなると、ロボットの実行速度が低下することがある。一例として、サーバに備えられたＣＰＵ数の倍の数のロボットを実行すると、実行速度が１／２程度に減速することがある。また、例えば、サーバに設定されているＲＰＡ製品で利用可能なメモリ使用量の上限値（例えば、８０％）を超えた場合などメモリ容量に不足が発生した場合、実行制限によりロボットの実行が待ち状態となることがある。その結果、実行スケジュールで予定されていた時刻にロボットを実行できないことがある。

ＲＰＡでは、或るロボットの処理の実行結果を他のロボットで利用することもしばしばある。そのため、例えば、実行スケジュールからの遅れが生じると、他のロボットの実行時に処理で利用する情報が得られていない状況などが発生し得、業務を安定して処理できなくなることがある。そのため、実行スケジュールに従ってロボットを実行できることは好ましい。

リソースの不足に対処する手法の一つとして、サーバに予めリソースを多めに配備しておくことが考えられる。しかしながら、負荷の高い状況に合わせてリソースを配備するとコストがかかる。また、一方で、負荷が低下した状況では未使用のリソースが増加することになる。そのため、リソースの不足が発生する状況に合わせて、リソースを配備することのできる技術の提供が望まれている。

また、例えば、サーバにおいて実行可能なロボットの数を予め定めておくなど運用を管理することでロボットの処理負荷が高くなる状況を回避することも考えられる。しかしながら、この場合、システムの運用を管理する管理者の負担が増加する。

また、例えば、オートスケーリング技術に見られるように、リソースの使用量を監視してリソースの不足を検出し、リソースの不足を検出したタイミングでリソースを追加することも考えられる。例えば、仮想マシン（ＶＭ：Virtual Machine）では、再起動時にリソース量を変更することが可能であり、リソースの不足の検出時に、仮想マシンを再起動してリソース量を変更することが考えられる。しかしながら、リソースの不足を検出してからリソース量を調節する対応では、リソースの不足の発生時にはロボットの実行が既に開始してしまっているため、ロボットの実行の遅れを回避することが難しいことがある。そのため、ロボットの実行開始前に、不足するリソースを配備することのできる技術の提供が望まれている。

以下で述べる実施形態では、ロボットの実行を制御するサーバは、ロボットの実行スケジュールと、ロボットが使用するリソースに関する情報とに基づいて、リソースの使用量が所定の使用量を超える処理負荷が発生する期間を予測する。なお、リソースの使用量が所定の使用量を超える処理負荷が発生する期間を以下では、不足発生期間と呼ぶことがある。そして、不足発生期間が予測される場合、サーバは、不足発生期間になる前に副系のサーバが起動されるようにリクエストを送信する。そして、サーバは、不足発生期間において動作するロボットのうちの一部のロボットを副系サーバに配備して実行させる。

それにより、リソースの不足に起因するロボットの処理の遅延を回避することができる。また、例えば、不足発生期間でのみ副系サーバのリソースを利用することで、リソースを効率的に利用することができる。例えば、サーバが副系サーバに一部のロボットの処理を実行させていない時間帯に、別のサーバが副系サーバに他の処理を実行させることも可能になる。

また、例えば、パブリッククラウドを利用して副系サーバを配備する場合、不足発生期間にのみ副系サーバを起動すればよいため、コストの削減を図ることができる。以下、実施形態を更に詳細に説明する。

図１は、実施形態に係るＲＰＡシステム１００の一例を示す図である。ＲＰＡシステム１００は、例えば、サーバ１０１、副系サーバ１０２、および管理サーバ１０３を含む。管理サーバ１０３は、一例ではパブリッククラウドにおいてサーバリソース１０５を管理するサーバであってよい。サーバリソース１０５は、例えば、複数の情報処理装置で構築されたリソースであってよい。

管理サーバ１０３は、例えば、リクエストに応じてサーバリソース１０５内のリソースをサーバに割り当てる。例えば、サーバ１０１および副系サーバ１０２は、サーバリソース１０５から割り当てられたリソースを備える情報処理装置において動作する仮想マシンなどであってよい。なお、サーバ１０１は、例えば、主系サーバおよび第１のサーバなどと呼ばれてよい。副系サーバ１０２は、例えば、第２のサーバと呼ばれてよい。

サーバ１０１は、例えば、実行スケジュールに従って複数のロボットを稼働させるサーバである。また、副系サーバ１０２は、例えば、サーバ１０１においてリソースの不足が発生する不足発生期間に起動されるサーバである。例えば、実施形態ではサーバ１０１は、ロボットの実行スケジュールと、ロボットが使用するリソースに関する情報とに基づいて、リソースの不足が発生する不足発生期間を予測する。そして、サーバ１０１は、不足発生期間になる前に副系サーバ１０２の配備および起動が完了するように管理サーバ１０３にリクエストを送信する。更に、サーバ１０１は、不足発生期間になる前に、不足発生期間に動作するロボットの一部の処理のプログラムを副系サーバ１０２に配備する。それにより、不足発生期間に動作するロボットの一部を副系サーバ１０２に実行させることができる。そのため、サーバ１０１ではリソースが足りず時間通りに処理できなかったロボットを副系サーバ１０２において時間通りに処理することができる。その結果、ロボットの処理を実行スケジュール通りに完了できるため、その後の他のロボットの処理も安定して実行することができる。

また、リソースが不足している不足発生期間に合わせて副系サーバ１０２を利用し、不足発生期間が終わると副系サーバ１０２の利用を停止することで、効率的にリソースを活用することができる。例えば、パブリッククラウドのサービスでリソースの提供を受ける場合、提供を受けるリソースの量を抑えてコストの削減を図ることができる。

図２は、実施形態に係るサーバ１０１のブロック構成を例示する図である。サーバ１０１は、例えば、制御部２０１、記憶部２０２、および通信部２０３を含む。制御部２０１は、例えば予測部２１１、送信部２１２、および提供部２１３などを含み、またその他の機能部を含んでもよい。記憶部２０２は、例えば、後述するサーバ情報４００、実行スケジュール５００、構成候補情報９００、履歴情報１０００、および稼働スケジュール１２００などの情報を記憶している。通信部２０３は、例えば、制御部２０１の指示に従って副系サーバ１０２および管理サーバ１０３などの他の装置と通信する。これらの各部の詳細および記憶部２０２に格納されている情報の詳細については後述する。

図３は、実施形態に係る副系サーバ１０２のブロック構成を例示する図である。副系サーバ１０２は、例えば、制御部３０１、記憶部３０２、および通信部３０３を含む。制御部３０１は、例えば副系サーバ１０２の各部を制御する。記憶部３０２は、例えば、サーバ１０１から配備された一部のロボットの実行に関する処理のプログラムなどの情報を記憶していてよい。通信部３０３は、例えば、制御部３０１の指示に従ってサーバ１０１および管理サーバ１０３などの他の装置と通信する。これらの各部の詳細および記憶部３０２に格納されている情報の詳細については後述する。

図４は、実施形態に係るサーバ情報４００を例示する図である。サーバ情報４００には、例えば、サーバ１０１のスペックを示す情報が登録されている。例えば、図４のサーバ情報４００には、スペックＩＤ、ＣＰＵ数、メモリ容量、およびオペレーティングシステム（ＯＳ：Operating System）の情報が登録されている。スペックＩＤは、例えば、サーバのスペックを識別するための識別子である。ＣＰＵ数は、例えば、同時に実行できる処理の数を表す値であってよい。ＣＰＵ数は、例えば、サーバ１０１に備えられているＣＰＵの数またはコアの数であってよい。メモリ容量は、例えば、サーバ１０１に備えられているメモリのサイズを示す情報である。オペレーティングシステムは、例えば、サーバ１０１に導入されているＯＳの種別を示す情報である。制御部２０１は、例えば、サーバ情報４００を参照することで、サーバ１０１のスペックを取得することができる。

図５は、実施形態に係る実行スケジュール５００を例示する図である。実行スケジュール５００は、例えば、サーバ１０１に配備されているロボットの実行に関する情報が登録されている。例えば、実行スケジュール５００には、ロボットＩＤ、実行時刻、ＣＰＵ数、メモリ容量、および実行時間を対応づけるレコードが登録されている。

ロボットＩＤは、例えば、サーバ１０１に配備されているロボットを識別するための識別子である。実行時刻は、例えば、レコードのロボットＩＤで識別されるロボットの実行を開始する時刻である。ＣＰＵ数は、例えば、レコードのロボットＩＤで識別されるロボットの実行で使用するＣＰＵの数またはコアの数である。メモリ容量は、例えば、レコードのロボットＩＤで識別されるロボットの実行で使用するメモリの量を示す情報である。実行時間は、例えば、レコードのロボットＩＤで識別されるロボットの実行にかかる時間を示す情報である。実行時間には、例えば、レコードのＣＰＵ数およびメモリ容量が確保できた状態でロボットの実行にかかる時間が登録されてよい。制御部２０１は、例えば、実行スケジュール５００に基づいてそれぞれの時刻でロボットの実行に使用されるリソースの量を見積もることができ、それにより、リソースが不足する不足発生期間を特定することができる。

図６は、実施形態に係るリソースの不足発生期間の特定を例示する図である。図６では、縦軸にリソースの使用量、横軸に時間がとられている。なお、リソースの使用量は、例えば、ロボットが使用するＣＰＵ数またはコアの数、或いはロボットが使用するメモリの容量であってよい。図６では、ロボット１からロボット４のそれぞれのロボットについて、時間に応じたリソースの使用量が示されている。ロボットは、実行スケジュール５００の実行時刻になると実行を開始してリソースを使用し、その後、実行時間が経過するとロボットの処理が完了してリソースを使用しなくなる。

また、制御部２０１は、例えば、実行スケジュール５００に基づいて時刻ごとのロボット全体でのリソースの使用量を予測することができる。例えば、図６では、ロボット１からロボット４のそれぞれのリソースの使用量を合計したロボット全体でのリソースの使用量が、合計使用リソースとして時系列で示されている。そして、制御部２０１は、所定の使用量を超えてリソースが使用される期間６０１を、リソースが不足する不足発生期間として特定する。なお、所定の使用量は、例えば、サーバ１０１で遅滞なく処理を実行する上で許容可能なリソースの使用量の上限であってよく、サーバ情報４００から特定することができる。この場合に、制御部２０１は、副系サーバ１０２を起動して、不足発生期間に動作するロボット１～３のうちからリソースの使用量が所定の使用量以下となるように、一部のロボットを副系サーバ１０２に配備して実行させてよい。図６の例では、ロボット２が副系サーバ１０２に配備される例が示されている。それにより、サーバ１０１ではリソースが足りずに時間通りに処理できなかったロボット２を副系サーバ１０２において時間通りに処理することができる。

続いて、実施形態に係るサーバ１０１が実行するロボット実行処理について説明する。図７は、実施形態に係るサーバ１０１の制御部２０１によるロボット実行処理の動作フローを例示する図である。例えば、制御部２０１は、ロボット実行処理の実行指示が入力されると図７の動作フローを開始してよい。

Ｓ７０１において制御部２０１は、実行スケジュール５００に登録されている各ロボットの実行スケジュールと、サーバ情報４００に登録されているサーバのスペックとに基づいて、不足発生期間を予測する。

Ｓ７０２において制御部２０１は、ロボットの実行スケジュールに基づいて、不足発生期間か否かを判定する。一例では、制御部２０１は、Ｓ７０２で現在時刻が不足発生期間の準備時刻になったか否かを判定してよい。なお、不足発生期間の準備時刻は、例えば、実行スケジュールに基づいて特定された不足発生期間の開始時刻から所定時間前の時刻であってよい。所定時間は、例えば、不足発生期間の開始時刻よりも前に副系サーバ１０２の起動が完了するように設定されていてよい。また、所定時間は、例えば、不足発生期間の開始時刻よりも前に、不足発生期間に動作するロボットの一部の処理のプログラムの副系サーバ１０２への配備が完了するように設定されていてよい。それにより、例えば、副系サーバ１０２に不足発生期間に動作するロボットの一部の処理を実行させることができる。一方で、所定時間は、例えば、副系サーバ１０２を配備する期間ができるだけ短くなるように設定されてよい。それにより、副系サーバ１０２の利用を最小限にすることができる。Ｓ７０２において不足発生期間である場合（Ｓ７０２がＹＥＳ）、フローはＳ７０３に進む。

Ｓ７０３において制御部２０１は、副系サーバ１０２を選定する。例えば、制御部２０１は、実行スケジュール５００に基づいて不足発生期間に足りなくなるリソース量を見積もる。一例では、制御部２０１は、リソースの不足が解消されるように副系サーバ１０２に配備するロボットを決定し、決定したロボットが不足発生期間に使用するリソースの最大値以上となるように副系サーバ１０２のスペックを選定してよい。例えば、副系サーバ１０２に配備するロボットが使用するＣＰＵ数の最大値が４個であれば、制御部２０１は、４個よりも多いＣＰＵ数を備えるように副系サーバ１０２のスペックを選定してよい。なお、Ｓ７０３の処理では、制御部２０１は、例えば、管理サーバ１０３に問い合わせを送信して、管理サーバ１０３が提供可能なサーバのスペックを示す一覧の情報を受信してよい。そして、制御部２０１は、受信したスペック一覧の情報から不足するリソースの量と対応するサーバのスペックを選定してよい。

Ｓ７０４において制御部２０１は、副系サーバ１０２の配備および起動をリクエストする。例えば、制御部２０１は、選定したスペックを有する副系サーバ１０２を配備して起動するように管理サーバ１０３にリクエストを送信してよい。管理サーバ１０３は、一例では、パブリッククラウドのサービスを提供するサーバであってよく、リクエストに応じてサーバリソース１０５内に副系サーバ１０２を配備して起動してよい。

Ｓ７０５において制御部２０１は、不足発生期間に足りなくなるリソース量に応じて決定した配備対象のロボットを副系サーバ１０２に配備する。

また、Ｓ７０２において不足発生期間でない場合（Ｓ７０２がＮＯ）、フローはＳ７０６に進む。

Ｓ７０６において制御部２０１は、副系サーバ１０２の停止日時となったか否かを判定する。例えば、制御部２０１は、起動中の副系サーバ１０２と対応する不足発生期間を過ぎている場合に停止日時になったと判定してよい。副系サーバ１０２の停止日時となっていない場合（Ｓ７０６がＮＯ）、フローはＳ７０７に進む。一方、副系サーバ１０２の停止日時となった場合（Ｓ７０６がＹＥＳ）、フローはＳ７０９に進む。Ｓ７０９において制御部２０１は、停止日時となった副系サーバ１０２に停止リクエストを送信し、フローはＳ７０７に進む。

Ｓ７０７において制御部２０１は、ロボットの実行時間になったか否かを判定する。例えば、制御部２０１は、実行スケジュール５００に登録されているロボットの実行時刻となった場合に、ＹＥＳと判定してよい。ロボットの実行時刻になっていない場合（Ｓ７０７がＮＯ）、フローはＳ７０２に戻る。一方、ロボットの実行時刻になっている場合（Ｓ７０７がＹＥＳ）、フローはＳ７０８に進む。

Ｓ７０８において制御部２０１は、実行時刻となったロボットを実行し、フローはＳ７０２に戻り処理を繰り返す。なお、制御部２０１は、実行時刻となったロボットが副系サーバ１０２に配備したロボットである場合、副系サーバ１０２に実行指示を送信してよい。

例えば、以上で述べたように、ロボットの実行スケジュールに基づいてリソースの不足が予測される場合には、副系サーバ１０２を起動し、不足するリソースの分のロボットを配備して実行させることができる。それにより、ロボットを実行スケジュールに従って安定して実行することができる。

続いて、サーバ１０１のリクエストによって起動される副系サーバ１０２におけるロボット実行処理について説明する。図８は、実施形態に係る副系サーバ１０２の制御部３０１によるロボット実行処理を例示する図である。例えば、制御部３０１は、管理サーバ１０３からリクエストを受信すると、図８の動作フローを開始してよい。

Ｓ８０１において制御部３０１は、リクエストされた副系サーバ１０２を起動する。例えば、制御部３０１は、管理サーバ１０３からの起動指示に従って副系サーバ１０２を起動してよい。なお、起動指示には、例えば、副系サーバ１０２のスペックを指定する情報が含まれていてよい。

Ｓ８０２において制御部３０１は、ロボットの情報を取得する。例えば、制御部３０１は、サーバ１０１から実行対象のロボットの実行プログラムを受信してよい。

Ｓ８０３において制御部３０１は、サーバ１０１から配備されたロボットの実行指示を受信したか否かを判定する。ロボットの実行指示を受信している場合（Ｓ８０３がＹＥＳ）、フローはＳ８０４に進む。そして、Ｓ８０４において制御部３０１は、実行指示を受けたロボットを実行する。一方、ロボットの実行指示を受信していない場合（Ｓ８０３がＮＯ）、フローはＳ８０５に進む。

Ｓ８０５において制御部３０１は、サーバ１０１から停止リクエストを受信したか否かを判定する。サーバ１０１から停止リクエストを受信していない場合（Ｓ８０５がＮＯ）、フローはＳ８０３に戻り処理を繰り返す。一方、サーバ１０１から停止リクエストを受信している場合（Ｓ８０５がＹＥＳ）、フローはＳ８０６に進む。

Ｓ８０６において制御部３０１は、自装置に割り当てられたリソースの停止およびリソースの解放を管理サーバ１０３にリクエストし、本動作フローは終了する。それにより、管理サーバ１０３は、副系サーバ１０２を停止させ、その後、副系サーバ１０２に割り当てていたリソースを解放することができる。

以上述べたように図８の動作フローによれば、副系サーバ１０２は、サーバ１０１から配備されたロボットを実行し、実行が完了すると、自装置を停止して自装置に割り当てられたリソースを解放することができる。

（変形例）
続いて、変形例を説明する。なお、上述の実施形態では、サーバ１０１は、管理サーバ１０３が提供可能なサーバのスペックを示す一覧の情報を受信する。そして、サーバ１０１は、受信したスペック一覧の情報から不足するリソースの量と対応するサーバのスペックを指定して副系サーバ１０２の配備および起動をリクエストする。しかしながら、実施形態はこれに限定されるものではない。例えば、別の実施形態ではサーバ１０１は、記憶部２０２に副系サーバ１０２のスペックの候補となる構成を予め記憶していてもよい。そして、サーバ１０１は、副系サーバ１０２の起動の際に、記憶部２０２に記憶されているスペックの候補の中から不足するリソースの量と対応する構成を選択して管理サーバ１０３に副系サーバ１０２の配備および起動のリクエストを送信してよい。

図９は、変形例に係る構成候補情報９００を例示する図である。構成候補情報９００には、例えば、スペックＩＤ、ＣＰＵ数、メモリ容量、記憶領域容量、ＯＳなどのサーバ構成を示す情報を対応づけたレコードが登録されている。スペックＩＤは、例えば、レコードと対応するサーバ構成のスペックを識別する情報である。ＣＰＵ数、メモリ容量、記憶領域容量、およびＯＳなどの情報は、例えば、レコードのスペックＩＤで識別されるサーバ構成のＣＰＵ数、メモリ容量、記憶領域容量、ＯＳの種別などを示す情報である。なお、記憶領域容量は、例えば、ＨＤＤ（Hard Disk Drive）およびＳＳＤ（Solid State Drive）などの記憶装置に確保される記憶領域の容量を示す情報である。また、構成候補情報９００には、更に、レコードのスペックＩＤで識別されるサーバに関するその他の情報が含まれていてもよい。

そして、制御部２０１は、例えば、Ｓ７０３の処理においてサーバの構成を選定する際に、構成候補情報９００に登録されているレコードのうちからサーバの構成を選定してよい。そして、制御部２０１は、続くＳ７０４の処理において、選定した構成を指定して副系サーバ１０２の配備および起動のリクエストを管理サーバ１０３に送信してよい。それにより、制御部２０１は、管理サーバ１０３から提供可能なサーバのスペックを示す一覧の情報を取得しなくても、副系サーバ１０２の配備および起動のリクエストを送信することができる。

（第２の実施形態）
続いて、第２の実施形態を説明する。例えば、ＲＰＡではロボットは、毎日の決まった時刻、毎週末、月初めなどの所定の周期で実行されることがしばしばある。この様な場合、サーバ１０１に配備されているロボットに変更がなければ、不足発生期間の予測を行うと、同じ演算を繰り返し実行することになることがある。

そこで、第２の実施形態ではサーバ１０１の制御部２０１は、副系サーバ１０２の配備および起動のリクエストを送信する場合に、送信したリクエストの履歴を記録する。そして、制御部２０１は、リクエストの履歴に基づいてリソースの不足が発生する周期を特定する。それにより、制御部２０１は、サーバ１０１に配備されているロボットに変更がなければ、不足発生期間を予測する演算を実行しなくても、特定した周期から副系サーバ１０２を起動してロボットの処理を実行させることができる。一方で、制御部２０１は、サーバ１０１に配備されているロボットに変更が行われた場合には、ロボットの実行スケジュールとロボットが使用するリソースに関する情報とに基づいて不足発生期間を予測してよい。それにより、ロボットに変更が行われた場合にも予測に基づいて副系サーバ１０２を起動してロボットの処理を実行させることができる。

図１０は、第２の実施形態に係るリクエストの履歴情報１０００を例示する図である。履歴情報１０００には、例えば、サーバＩＤ、ＣＰＵ数、メモリ容量、記憶領域容量、ＯＳ、ロボットＩＤ、起動日時、および停止日時が対応付けられたレコードが登録されている。履歴情報１０００のサーバＩＤは、例えば、レコードと対応するリクエストで配備および起動が依頼される副系サーバ１０２を識別する識別子である。履歴情報１０００のＣＰＵ数、メモリ容量、記憶領域容量、およびＯＳは、例えば、レコードと対応するリクエストで配備および起動が依頼される副系サーバ１０２のスペックを示す情報である。ロボットＩＤは、例えば、リクエストで副系サーバ１０２に配備するロボットを識別するための識別子である。起動日時および停止日時は、例えば、レコードと対応するリクエストで配備および起動が依頼される副系サーバ１０２の起動日時および停止日時である。例えば、制御部２０１は、Ｓ７０４において副系サーバ１０２の配備および起動のリクエストを送信する際に、リクエストで指定される副系サーバ１０２のスペックを示す情報とともに、現在の日時を起動日時に含めたレコードを履歴情報１０００に登録してよい。また、サーバ１０１の制御部２０１は、Ｓ７０９の処理で停止リクエストを送信する際に、履歴情報１０００において停止リクエストで停止対象となる副系サーバ１０２と対応するレコードの停止日時に現在の日時を登録してよい。

続いて、図１１を参照して、サーバ１０１による履歴情報１０００に基づく副系サーバ１０２の稼働スケジュールの生成処理について説明する。例えば、サーバ１０１の制御部２０１は、所定のタイミングで図１１の動作フローを開始してよい。

Ｓ１１０１において制御部２０１は、履歴のリクエストを類似するリクエストごとに分類する。例えば、制御部２０１は、履歴情報１０００に登録されているレコードのうちで、起動するサーバのスペックと、配備されるロボットとが一致するレコードを類似するリクエストとして同じグループに分類してよい。

Ｓ１１０２において制御部２０１は、分類されたグループが所定数以上のレコードを含むか否かを判定する。所定数以上のレコードを含まない場合（Ｓ１１０２がＮＯ）、本動作フローは終了する。一方、所定数以上のレコードを含む場合（Ｓ１１０２がＹＥＳ）、フローはＳ１１０３に進む。所定数は、副系サーバ１０２の稼働周期を特定するのに十分な数に設定されていてよく、例えば、３個以上の数であってよく、一例では、１５個であってよい。

Ｓ１１０３において制御部２０１は、各グループに含まれるレコードの情報から副系サーバ１０２の稼働周期を特定する。例えば、制御部２０１は、グループに含まれるレコードの起動日時および終了日時の情報から得たリクエストの送信間隔を副系サーバ１０２の稼働周期として特定してよい。また、例えば、グループに同じ日付のレコードが複数含まれる場合、制御部２０１は、同じ日付の複数のレコードから得られた複数の起動時刻および停止時刻を、副系サーバ１０２の稼働周期の起動日時および停止日時の時刻として用いてよい。

Ｓ１１０４において制御部２０１は、特定した副系サーバ１０２の稼働周期を稼働スケジュール１２００に登録し、本動作フローは終了する。

図１２は、第２の実施形態に係る稼働スケジュール１２００を例示する図である。稼働スケジュール１２００には、例えば、リクエストＩＤ、副系サーバＩＤ、ＣＰＵ数、メモリ容量、記憶領域容量、ＯＳ、ロボットＩＤ、起動日時、および停止日時の情報を対応づけたレコードが登録されている。稼働スケジュール１２００のリクエストＩＤは、例えば、レコードと対応するリクエストを識別する識別子である。稼働スケジュール１２００の副系サーバＩＤは、例えば、レコードと対応するリクエストで起動される副系サーバ１０２を識別するための識別子である。稼働スケジュール１２００のＣＰＵ数、メモリ容量、記憶領域容量、およびＯＳは、例えば、レコードと対応するリクエストで起動される副系サーバ１０２のスペックを示す情報である。ロボットＩＤは、例えば、レコードと対応するリクエストで起動される副系サーバ１０２に配備するロボットを識別する識別子である。起動日時および停止日時は、例えば、レコードと対応する副系サーバ１０２の起動リクエストおよび停止リクエストを送信する日時を示す情報である。

制御部２０１は、例えば、稼働スケジュール１２００を参照することで、リソースが不足するタイミングで起動リクエストを送信して副系サーバ１０２を起動したり、その後、停止リクエストを送信して副系サーバ１０２を停止したりすることができる。

図１３は、第２の実施形態に係るサーバ１０１の制御部２０１によるロボット実行処理の動作フローを例示する図である。例えば、制御部２０１は、ロボット実行処理の実行指示が入力されると図１３の動作フローを開始してよい。

Ｓ１３０１において制御部２０１は、例えば、サーバ１０１に配備されているロボットに変更が行われたか否かを判定する。例えば、制御部２０１は、図１１の動作フローで最新の稼働スケジュール１２００を生成した以降に、ロボットの実行スケジュール５００に変更が行われていれば（Ｓ１３０１がＹＥＳ）、フローをＳ１３０２に進めてよい。

なお、図１３においてＳ１３０２からＳ１３１０の処理は、図７のＳ７０１からＳ７０９の処理と対応していてよく、一例では、制御部２０１は、Ｓ７０１からＳ７０９の処理と同様の処理を実行してよい。

一方、Ｓ１３０１においてサーバ１０１に配備されているロボットに変更が行われていない場合（Ｓ１３０１がＮＯ）、フローはＳ１３１１に進む。Ｓ１３１１において制御部２０１は、現在時刻が稼働スケジュール１２００に登録されている起動日時となったか否かを判定する。現在時刻が起動日時になっていない場合（Ｓ１３１１がＮＯ）、フローはＳ１３０７に進む。一方、現在時刻が起動日時になった場合（Ｓ１３１１がＹＥＳ）、フローはＳ１３０５に進む。この場合、制御部２０１は、Ｓ１３０５において起動日時となった稼働スケジュール１２００のレコードに登録されているリクエストを送信し、副系サーバ１０２の起動を管理サーバ１０３に依頼してよい。

続く、Ｓ１３０６の処理で制御部２０１は、送信したリクエストと対応する稼働スケジュール１２００のレコードのロボットＩＤで識別されるロボットを、起動した副系サーバ１０２に配備してよい。

また、稼働スケジュール１２００のレコードと対応するリクエストで起動した副系サーバ１０２については、制御部２０１は、Ｓ１３０７およびＳ１３１０の処理で稼働スケジュール１２００の停止日時に従って停止させてよい。

以上で述べたように、図１３の動作フローよれば、制御部２０１は、サーバ１０１に配備されているロボットに変更が行われていない場合には、稼働スケジュール１２００に従って副系サーバ１０２の起動および停止を実行する。それにより、リソースが不足する期間の予測のために同じ演算を繰り返し実行することを抑制することができる。

（第３の実施形態）
上述の実施形態では、サーバでロボットを集約して管理するサーバ型のＲＰＡ製品を例に説明を行っているが、実施形態はこれに限定されるものではない。例えば、業務を担当するユーザの端末にロボットを配備して実行するデスクトップ型のＲＰＡ製品でも、各端末に配備されているロボットの制御をサーバ１０１で実行する場合、ロボットの制御負荷が増大すると、サーバ１０１のリソースが足りなくなることがある。この場合にも、リソースが不足する期間におけるロボットの制御処理を、副系サーバ１０２に移すことで、リソースの不足による処理の遅れを抑制することができる。

図１４は、第３の実施形態に係るＲＰＡシステム１４００を例示する図である。ＲＰＡシステム１４００は、例えば、サーバ１０１、副系サーバ１０２、管理サーバ１０３、ロードバランサ１４０１、および端末１４０２を含む。ロードバランサ１４０１は、例えば、端末１４０２に配備されたロボットの制御にかかる処理負荷を、サーバ１０１または副系サーバ１０２に振り分ける。端末１４０２にはロボットが配備されており、端末１４０２は、サーバ１０１または副系サーバ１０２の制御に従ってロボットを実行する。

なお、第３の実施形態では実行スケジュール５００には、ロボットの実行にかかるリソースの情報として、端末１４０２に配備されたロボットの制御処理にかかるリソースの情報が登録されていてよい。そして、制御部２０１は、Ｓ７０２の処理で実行スケジュール５００に登録されているロボットの制御処理にかかるリソースの情報に基づいてリソースの不足する不足発生期間か否かを判定してよい。不足発生期間である場合、制御部２０１は、Ｓ７０４の処理で副系サーバ１０２を起動するように管理サーバ１０３にリクエストを送信する（図１４の（１））。管理サーバ１０３は、リクエストを受けると副系サーバ１０２を配備して起動する（図１４の（２））。そして、制御部２０１は、Ｓ７０５の処理で不足発生期間に動作するロボットの制御処理の少なくとも一部を、起動した副系サーバ１０２に移す（図１４の（３））。なお、制御部２０１は、Ｓ７０５の処理において、副系サーバ１０２に移した端末１４０２のロボットの制御処理については副系サーバ１０２に振り分けるようにロードバランサに指示を送信してよい。それにより、ロードバランサ１４０１は、副系サーバ１０２に制御処理が移されたロボットについては、制御処理を副系サーバ１０２に振り分けることができる。従って、サーバ１０１のリソースの不足に起因して端末１４０２に配備されたロボットの制御処理が遅れてしまうことを抑制することができる。

以上において、実施形態を例示したが、実施形態はこれに限定されるものではない。例えば、上述の動作フローは例示であり、実施形態はこれに限定されるものではない。可能な場合には、動作フローは、処理の順番を変更して実行されてもよく、別に更なる処理を含んでもよく、または、一部の処理が省略されてもよい。例えば、上述の実施形態ではＳ７０８において、副系サーバ１０２に配備したロボットに対する実行指示をサーバ１０１から副系サーバ１０２に送信する例を述べているが実施形態はこれに限定されるものではない。別の実施形態では、Ｓ７０５の処理で制御部２０１は、ロボットを配備する際にロボットの実行スケジュールの情報を副系サーバ１０２に送信してよい。そして、副系サーバ１０２の制御部３０１は、例えば、Ｓ８０３の処理でサーバ１０１から受信した実行スケジュールに従ってロボットの実行タイミングとなったか否かを判定してよい。また、この場合、制御部２０１は、Ｓ７０９で停止リクエストを副系サーバ１０２に送信しなくてもよい。代わりに、制御部３０１は、受信した実行スケジュールに基づいて、配備されたロボットの全ての実行が完了している場合に、Ｓ８０５においてＹＥＳと判定し、副系サーバ１０２を停止させてよい。

また、上述のＳ７０５の処理においてロボットを副系サーバ１０２に配備する例を述べているが、実施形態はこれに限定されるものではない。例えば、別の実施形態では、サーバ１０１の制御部２０１は、ロボットの実行に関する少なくとも一部の処理の情報を副系サーバ１０２に配備してもよい。例えば、上述の第２の実施形態では、ロボットの実行に関する少なくとも一部の処理として、ロボットの制御処理を副系サーバ１０２に配備する例が示されている。

なお、上述の実施形態のＳ７０１およびＳ１３０２の処理において制御部２０１は、例えば、予測部２１１として動作する。また、Ｓ７０４およびＳ１３０５の処理において制御部２０１は、例えば、送信部２１２として動作する。Ｓ７０５およびＳ１３０６の処理において制御部２０１は、例えば、提供部２１３として動作する。

図１５は、実施形態に係るサーバ１０１および副系サーバ１０２を実現するための情報処理装置１５００のハードウェア構成を例示する図である。なお、情報処理装置１５００は、例えば、コンピュータである。図１５のハードウェア構成は、例えば、プロセッサ１５０１、メモリ１５０２、記憶装置１５０３、読取装置１５０４、通信インタフェース１５０６、および入出力インタフェース１５０７を備える。なお、プロセッサ１５０１、メモリ１５０２、記憶装置１５０３、読取装置１５０４、通信インタフェース１５０６、入出力インタフェース１５０７は、例えば、バス１５０８を介して互いに接続されている。

プロセッサ１５０１は、例えば、シングルプロセッサであっても、マルチプロセッサやマルチコアであってもよい。プロセッサ１５０１は、メモリ１５０２を利用して例えば上述の動作フローの手順を記述したプログラムを実行することにより、上述したサーバ１０１または副系サーバ１０２の一部または全部の機能を提供する。例えば、サーバ１０１のプロセッサ１５０１は、記憶装置１５０３に格納されているプログラムを読み出して実行することで、例えば、予測部２１１、送信部２１２、および提供部２１３として動作する。また、例えば、副系サーバ１０２のプロセッサ１５０１は、記憶装置１５０３に格納されているプログラムを読み出して実行することで、制御部３０１として動作する。

メモリ１５０２は、例えば半導体メモリであり、ＲＡＭ領域およびＲＯＭ領域を含んでいてよい。記憶装置１５０３は、例えばハードディスク、フラッシュメモリ等の半導体メモリ、または外部記憶装置である。なお、ＲＡＭは、Random Access Memoryの略称である。また、ＲＯＭは、Read Only Memoryの略称である。

読取装置１５０４は、プロセッサ１５０１の指示に従って着脱可能記憶媒体１５０５にアクセスする。着脱可能記憶媒体１５０５は、例えば、半導体デバイス、磁気的作用により情報が入出力される媒体、光学的作用により情報が入出力される媒体などにより実現される。なお、半導体デバイスは、例えば、ＵＳＢ（Universal Serial Bus）メモリである。また、磁気的作用により情報が入出力される媒体は、例えば、磁気ディスクである。光学的作用により情報が入出力される媒体は、例えば、ＣＤ－ＲＯＭ、ＤＶＤ、Blu-ray Disc等（Blu-rayは登録商標）である。ＣＤは、Compact Discの略称である。ＤＶＤは、Digital Versatile Diskの略称である。

記憶部２０２および記憶部３０２は、例えばメモリ１５０２、記憶装置１５０３、および着脱可能記憶媒体１５０５を含んでいる。例えば、サーバ１０１の記憶装置１５０３には、例えば、サーバ情報４００、実行スケジュール５００、構成候補情報９００、履歴情報１０００、および稼働スケジュール１２００などが格納されていてよい。また、例えば、副系サーバ１０２の記憶装置１５０３には、例えば、サーバ１０１から受信したロボットのプログラム、および実行スケジュールなどの情報が格納されていてよい。

通信インタフェース１５０６は、プロセッサ１５０１の指示に従って他の装置と通信する。例えば、サーバ１０１は、通信インタフェース１５０６を介して副系サーバ１０２および管理サーバ１０３と通信してよい。また、例えば、副系サーバ１０２は、通信インタフェース１５０６を介してサーバ１０１および管理サーバ１０３と通信してよい。通信インタフェース１５０６は、上述の通信部２０３および通信部３０３の一例である。

入出力インタフェース１５０７は、例えば、入力装置および出力装置との間のインタフェースであってよい。入力装置は、例えばユーザからの指示を受け付けるキーボード、マウス、タッチパネルなどのデバイスである。出力装置は、例えばディスプレーなどの表示装置、およびスピーカなどの音声装置である。

実施形態に係る各プログラムは、例えば、下記の形態でサーバ１０１および副系サーバ１０２に提供される。
（１）記憶装置１５０３に予めインストールされている。
（２）着脱可能記憶媒体１５０５により提供される。
（３）プログラムサーバなどのサーバから提供される。

なお、図１５を参照して述べたハードウェア構成は、例示であり、実施形態はこれに限定されるものではない。例えば、上述の構成の一部が、削除されてもよく、また、新たな構成が追加されてもよい。また、別の実施形態では、例えば、上述の制御部２０１および制御部３０１の一部または全部の機能がＦＰＧＡ、ＳｏＣ、ＡＳＩＣ、およびＰＬＤなどによるハードウェアとして実装されてもよい。なお、ＦＰＧＡは、Field Programmable Gate Arrayの略称である。ＳｏＣは、System-on-a-chipの略称である。ＡＳＩＣは、Application Specific Integrated Circuitの略称である。ＰＬＤは、Programmable Logic Deviceの略称である。

以上において、いくつかの実施形態が説明される。しかしながら、実施形態は上記の実施形態に限定されるものではなく、上述の実施形態の各種変形形態および代替形態を包含するものとして理解されるべきである。例えば、各種実施形態は、その趣旨および範囲を逸脱しない範囲で構成要素を変形して具体化できることが理解されよう。また、前述した実施形態に開示されている複数の構成要素を適宜組み合わせることにより、種々の実施形態が実施され得ることが理解されよう。更には、実施形態に示される全構成要素からいくつかの構成要素を削除して、または実施形態に示される構成要素にいくつかの構成要素を追加して種々の実施形態が実施され得ることが当業者には理解されよう。

１００ ＲＰＡシステム
１０１ サーバ
１０２ 副系サーバ
１０３ 管理サーバ
１０５ サーバリソース
２０１ 制御部
２０２ 記憶部
２０３ 通信部
２１１ 予測部
２１２ 送信部
２１３ 提供部
３０１ 制御部
３０２ 記憶部
３０３ 通信部
１４００ ＲＰＡシステム
１４０１ ロードバランサ
１４０２ 端末
１５００ 情報処理装置
１５０１ プロセッサ
１５０２ メモリ
１５０３ 記憶装置
１５０４ 読取装置
１５０５ 着脱可能記憶媒体
１５０６ 通信インタフェース
１５０７ 入出力インタフェース
１５０８ バス

Claims (6)

1. 第１のサーバによる制御対象の複数のロボットの実行スケジュールと、前記複数のロボットの実行に関する処理で使用されるリソースの量とに基づいて、リソースの使用が所定の使用量を超える処理負荷の発生を予測し、
   前記所定の使用量を超える前記処理負荷の発生前に第２のサーバの起動が完了するようにリクエストを管理サーバに送信し、
   前記複数のロボットのうち、前記処理負荷の発生期間に実行されるロボットのうちの一部のロボットに関する情報を前記第２のサーバに提供して、前記第２のサーバに前記一部のロボットの実行に関する処理を実行させる、
   処理をコンピュータに実行させる情報処理プログラム。
2. 前記一部のロボットの実行に関する処理で使用されるリソースの量に基づいて複数のサーバ構成の候補のうちから前記第２のサーバの構成を選定する処理を更に含む、請求項１に記載の情報処理プログラム。
3. 前記リクエストの送信履歴に基づいて前記第２のサーバの稼働スケジュールを生成する処理を更に含み、
   前記予測する処理は、前記稼働スケジュールの生成後に前記複数のロボットの前記実行スケジュールに変更が行われた場合に実行される、請求項１または請求項２に記載の情報処理プログラム。
4. 前記予測する処理は、前記複数のロボットの実行スケジュールと、前記複数のロボットの実行に関する処理で使用されるリソースの量とに基づいて、時刻ごとの前記第１のサーバで使用されるリソースの量を予測し、
   前記送信する処理は、予測されたリソースの量が前記所定の使用量を超える期間になる前に前記第２のサーバの起動が完了するように前記リクエストを前記管理サーバに送信する、ことを特徴とする請求項１から請求項３のいずれか１項に記載の情報処理プログラム。
5. 第１のサーバによる制御対象の複数のロボットの実行スケジュールと、前記複数のロボットの実行に関する処理で使用されるリソースの量とに基づいて、リソースの使用が所定の使用量を超える処理負荷の発生を予測し、
   前記所定の使用量を超える前記処理負荷の発生前に第２のサーバの起動が完了するようにリクエストを管理サーバに送信し、
   前記複数のロボットのうち、前記処理負荷の発生期間に実行されるロボットのうちの一部のロボットに関する情報を前記第２のサーバに提供して、前記第２のサーバに前記一部のロボットの実行に関する処理を実行させる、
   ことを含む、コンピュータが実行する情報処理方法。
6. 第１のサーバによる制御対象の複数のロボットの実行スケジュールと、前記複数のロボットの実行に関する処理で使用されるリソースの量とに基づいて、リソースの使用が所定の使用量を超える処理負荷の発生を予測する予測部と、
   前記所定の使用量を超える前記処理負荷の発生前に第２のサーバの起動が完了するようにリクエストを管理サーバに送信する送信部と、
   前記複数のロボットのうち、前記処理負荷の発生期間に実行されるロボットのうちの一部のロボットに関する情報を前記第２のサーバに提供して、前記第２のサーバに前記一部のロボットの実行に関する処理を実行させる、提供部と、
   を含む、情報処理装置。
   

Images