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

Abstract

【課題】情報処理装置、情報処理方法及び情報処理プログラムに関し、すべてのゾーンのコントローラへＷｅｂ ＡＰＩを発行することにより生じる負荷を軽減することができる。【解決手段】リソースとリソースが存在するゾーンの対応を記録する第１テーブルと、Ｗｅｂ ＡＰＩに対するゾーンのコントローラ３０からの応答の内容を記録する第２テーブルと、応答内容の第２テーブルへの記録後、所望のリソースを探索するＷｅｂ ＡＰＩを受信し、第１テーブルに基づいて所望のリソースに対応するゾーンのコントローラへ発行された所望のリソースの存在確認の確認ＡＰＩに対する応答によって所望のリソースを取得できない場合、第２テーブルの記録に基づいて第１テーブルを更新する更新処理部３５とを有する。【選択図】図３

Description

情報処理装置、情報処理方法及び情報処理プログラムに関する。

一般のユーザ向けにクラウドコンピューティング環境をインターネットを介して提供するパブリッククラウドというサービスがある（特許文献１を参照）。パブリッククラウドでは、Web Application Programming Interface（Ｗｅｂ ＡＰＩ）の発行により、イメージ、ボリューム、ネットワークなどのリソースの探索が可能である。パブリッククラウドでは、地理的な場所を指すリージョンと、リージョン内において独立したロケーションを指すゾーンがあり、ゾーンはリージョン内に複数存在する。

特開２０１７−６８２９６号公報

しかし、リソースは主にゾーンごとに存在するため、Ｗｅｂ ＡＰＩを受け取るリージョンマネージャは、リソースがどのゾーンに存在するか不明の場合にはすべてのゾーンのコントローラへＷｅｂ ＡＰＩを発行する必要があり、効率が悪く膨大な負荷となっていた。

そこで、本発明の１つの側面では、すべてのゾーンのコントローラへＷｅｂ ＡＰＩを発行することにより生じる負荷を軽減させることを目的とする。

態様の一例では、リソースと前記リソースが存在するゾーンの対応を記録する第１テーブルと、Ｗｅｂ ＡＰＩに対する前記ゾーンのコントローラからの応答の内容を記録する第２テーブルと、前記応答内容の前記第２テーブルへの記録後、所望のリソースを探索するＷｅｂ ＡＰＩを受信し、前記第１テーブルに基づいて前記所望のリソースに対応するゾーンのコントローラへ発行された前記所望のリソースの存在確認の確認ＡＰＩに対する応答によって前記所望のリソースを取得できない場合、前記第２テーブルの記録に基づいて前記第１テーブルを更新する更新処理部とを有する。

すべてのゾーンのコントローラへＷｅｂ ＡＰＩを発行することにより生じる負荷を軽減することができる。

実施形態の情報処理装置を含むパブリッククラウドシステムの構成を示す図である。 レスポンス送信と内部処理が非同期により不要なＡＰＩの発行が生じる場合の処理フローを示すフローチャートである。 実施形態の情報処理装置の機能構成を示す図である。 実施形態における第１テーブル及び第２テーブルを説明するための図である。 実施形態の情報処理装置のハードウェア構成を示す図である。 実施形態の情報処理装置におけるＡＰＩを受信した場合の処理フロー（内部処理が成功する場合）を示すフローチャートである。 実施形態の情報処理装置におけるＡＰＩを受信した時点の各テーブルを示す図である。 実施形態の情報処理装置におけるＡＰＩの処理により第２テーブルに記録されたことを説明するための図である。 実施形態の情報処理装置における第１テーブルの更新のタイミングについて説明するためのフローチャートである。 実施形態の情報処理装置における第１テーブルの他の更新のタイミングについて説明するためのフローチャートである。 実施形態の情報処理装置における探索ＡＰＩを受信した場合の処理フローを示すフローチャートである。 実施形態の情報処理装置における探索ＡＰＩを受信した時点の各テーブルを示す図である。 実施形態の情報処理装置における探索ＡＰＩの処理により第１テーブルを第２テーブルの内容で更新した際の各テーブルを示す図である。 実施形態の情報処理装置における探索ＡＰＩの処理により第２テーブルに記録されたことを説明するための図である。 実施形態の情報処理装置におけるＡＰＩを受信した場合の処理フロー（内部処理が失敗する場合）を示すフローチャートである。 実施形態の情報処理装置におけるＡＰＩの処理により第２テーブルが記録されたことを説明するための図である。 実施形態の情報処理装置における探索ＡＰＩの処理により第２テーブルが記録されたことを説明するための図である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
図１は実施形態の情報処理装置（リージョンマネージャ）を含むパブリッククラウドシステム（以下、システムとも言う）の構成の一例を示す。なお、以下ではパブリッククラウドシステムを例にとって説明するが、これに限定されるものではなく、Ｗｅｂ ＡＰＩ（以下、単にＡＰＩとも言う）の送信先が多数存在する通信システムなどにおいても適用可能である。

システム１には、地理的な場所を指すリージョン２と、リージョン２内において独立したロケーションを指すゾーン３（３ａ、３ｂ）が存在する。ゾーン３はリージョン２内に複数存在する。例えば、ゾーン３ａを第１ゾーン、ゾーン３ｂを第２ゾーンとする。システム１では、ユーザの要求を受け付けるユーザ装置４からＡＰＩを発行することにより、イメージ、ボリューム、ネットワークなどのリソースの情報を探索することなどが可能である。

リージョン２には、ユーザ装置４からのＡＰＩを受け取り、受け取ったＡＰＩに応じてゾーン３のコントローラ３０（３０ａ、３０ｂ）へＡＰＩを発行するリージョンマネージャ１０がある。リージョンマネージャ１０における処理の詳細については後述する。

ゾーン３には、リソースが存在し、リソースを管理するコントローラ３０が存在する。ゾーン３とコントローラ３０は１対１の関係である。すなわち、１つのゾーン３には１つのコントローラ３０が存在し、コントローラ３０がゾーン３のリソースを管理している。コントローラ３０は、リージョンマネージャ１０から発行されるＡＰＩを受信し、受信したＡＰＩに応じて応答（レスポンス）をリージョンマネージャ２０へ送信する。具体的には、あるリソースがゾーン３ａに存在するか否かを確認するＡＰＩに対して、コントローラ３０ａは当該リソースが存在すると判断した場合には自身が管理するゾーン３ａに当該リソースが存在する旨のレスポンスをリージョンマネージャ１０へ返す。

また、コントローラ３０は、リソース（例えば、仮想マシンＶＭ（Virtual Machine）１）のスペックを変更したいというＡＰＩに対して、他のゾーン３でなければＶＭ１のスペックを変更できない場合、他のゾーン３へ移動させることを決定する。この決定に基づいて、コントローラ３０は、他のゾーン３へＶＭ１を移動させる旨の情報を含むレスポンスをリージョンマネージャ１０へ返すとともに、レスポンスとは非同期にＶＭ１を他のゾーン３へ移動させる。

このような非同期処理では、レスポンスは成功しても内部処理（ＶＭ１のゾーン間の移動処理）は失敗するケースがある。具体的には、ＡＰＩを受け付けた際はＶＭ１の第１ゾーンから第２ゾーンへの移動を行うことが可能であったため、ＶＭ１のゾーン移動をする旨のレスポンスを送ったが、その後の状況の変化（例えば、拡張処理中に空き容量がなくなる）などによりゾーン移動できなくなり、内部処理が失敗するケースである。このケースにおいてＶＭ１がどのゾーンにあるか探索するためのＡＰＩをユーザ装置４が発行した場合のリージョンマネージャ１０の処理について図２を用いて説明する。

リージョンマネージャ１０はユーザ装置４からＡＰＩを受信すると（ステップＳ２０１）、後述する第１テーブルにゾーンの情報の記録があるか否かを判断する（ステップＳ２０２）。第１テーブルに全く記録がない場合（ステップＳ２０２でＮｏ）、リージョンマネージャ１０は全てのゾーンのコントローラ３０へＡＰＩを発行する（ステップＳ２０３）。このとき発行されるＡＰＩはＶＭ１がどのゾーンに存在するかを確認するためのものである。リージョンマネージャ１０は、各ゾーンのコントローラ３０からのレスポンスを受信すると、ステップＳ２０６へ進んでレスポンス内容に応じて第１テーブルを更新する。

一方、第１テーブルに記録がある場合（ステップＳ２０２でＹｅｓ）、リージョンマネージャ１０は第１テーブルにＶＭ１があるか確認し、ＶＭ１がある場合にＶＭ１に対応付けられたゾーン（例えば、第２ゾーン）にＶＭ１が存在するか判断する（ステップＳ２０４）。このときの第１テーブルは、コントローラ３０からのレスポンスに基づいてＶＭ１が存在するゾーンが第１ゾーンから第２ゾーンへ更新されている。そのため、リージョンマネージャ１０は、第２ゾーンのコントローラ３０に対してＶＭ１の存在確認のためのＡＰＩ（確認ＡＰＩ）を発行し、コントローラ３０からのレスポンス（ＶＭ１が存在するか否かの情報を含む）に基づいてＶＭ１が存在するか判断する。

ＶＭ１は内部処理の失敗によって第１ゾーンに留まった状態のため、第２ゾーンのコントローラ３０からのレスポンスにはＶＭ１は存在しない旨の情報が含まれている。そのため、リージョンマネージャ１０はＶＭ１が第２ゾーンに存在しないと判断し（ステップＳ２０４でＮｏ）、ＶＭ１がどのゾーンに存在するかを確認するため、全てのゾーンのコントローラ３０へＡＰＩを発行する（ステップＳ２０３）。

なお、ＶＭ１が第２ゾーンに存在する場合（ステップＳ２０４でＹｅｓ）、すなわち内部処理が成功している場合、リージョンマネージャ１０は該当ゾーンの第２ゾーンへユーザ装置４からのＡＰＩを発行する（ステップＳ２０５）。リージョンマネージャ１０は発行したＡＰＩに対するレスポンスを第２ゾーンのコントローラ３０から受信してレスポンス内容に応じて第１テーブルを更新する（ステップＳ２０６）。その後、リージョンマネージャ１０はＶＭ１が存在するゾーンの情報を含むレスポンスをユーザ装置４へ返す（ステップＳ２０７）。

このように、コントローラ３０によるレスポンス送信と内部処理が非同期のため、不要なＡＰＩの発行が生じ、負荷が増大してしまう。

実施形態の情報処理装置（リージョンマネージャ）ではそのような不要なＡＰＩの発行を削減し、負荷を軽減させることを目的としている。

以下で実施形態の情報処理装置の機能構成について図３を用いて説明する。
リージョンマネージャ１０は、受信部３１、発行部３２、判断部３３、記録部３４、更新処理部３５、格納部３６から構成されている。なお、構成はこれに限定されるものではなく、他の構成を含むものであってもよい。

受信部３１は、ユーザ装置４からＡＰＩを受信したり、コントローラ３０からＡＰＩに対するレスポンスを受信したりする。ユーザ装置４から受信するＡＰＩは、リソース（例えば、ＶＭ１）のスペックを変更したい旨の要求や、リソース（例えば、ＶＭ１）が存在するゾーンを確認したい旨の要求などを含むものである。また、コントローラ３０から受信するレスポンスは、リソース（例えば、ＶＭ１）のスペック変更に対応するために現在のゾーンから他のゾーンへリソースを移動する旨の情報や、リソース（例えば、ＶＭ１）の存在確認に対するリソースが存在するゾーンの情報などを含むものである。

発行部３２は、ユーザ装置４から受信したＡＰＩに基づいて、コントローラ３０が管理するゾーン３にリソース（例えば、ＶＭ１）が存在するかを確認する存在確認のためのＡＰＩを格納部３６の第１テーブルを用いてコントローラ３０へ発行する。また、発行部３２は、ユーザ装置４から受信したＡＰＩに基づいて、リソース（例えば、ＶＭ１）のスペックを変更したい旨の要求を含むＡＰＩを第１テーブルを用いてコントローラ３０へ発行する。また、発行部３２は、更新後の第１テーブルに基づいて、コントローラ３０が管理するゾーン３にリソース（例えば、ＶＭ１）が存在するか確認する存在確認のためのＡＰＩ（確認ＡＰＩ）を発行する。また、発行部３２はコントローラ３０からのレスポンス結果をユーザ装置４へ送信する。

判断部３３は、ユーザ装置４から受信したＡＰＩに基づいて、第１テーブルにゾーン情報が存在するか否かを判断する。また、判断部３３は、発行部３２によって発行された存在確認のためのＡＰＩに対するコントローラ３０からのレスポンスに基づいて、スペックを変更したいリソースや探索対象のリソースがゾーン３に存在するか否かを判断する。すなわち、所望のリソースの存在確認の確認ＡＰＩに対する応答に基づいて、所望のリソースが取得できたか否かを判断する。

記録部３４は、例えばＶＭ１のスペックを変更したい旨の要求のＡＰＩに対するレスポンスがＶＭ１を現在のゾーン（例えば、第１ゾーン）から他のゾーン（例えば、第２ゾーン）へ移動する旨の場合、ＶＭ１の移動元（移動前）及び移動先（移動後）のゾーンの情報などを第２テーブルに記録する。すなわち、記録部３４は、発行されたＷｅｂ ＡＰＩに対するコントローラ３０からの応答内容に基づいて第２テーブルに記録を行う。

更新処理部３５は、ユーザ装置４から受信したリソース（例えば、ＶＭ１）を探索するＡＰＩにより、第１テーブルを用いてＶＭ１が存在するゾーンのコントローラ３０へＶＭ１の存在が確認されたが、存在しない場合に第１テーブルを第２テーブルに基づいて更新する。

格納部３６は、各種情報を格納し、例えば第１テーブル及び第２テーブルを格納する。ここで、第１テーブル及び第２テーブルについて図４を用いて説明する。

第１テーブルは、ＶＭ、ボリューム、仮想イメージ、ネットワークなどのリソース情報を格納するリソースと、そのリソースが存在するゾーンの情報を格納するゾーンから構成されている。すなわち、第１テーブルはリソースと、リソースが存在するゾーンの対応を記録するものである。

第１テーブルにより、各リソースがどのゾーンに存在するか把握することができる。この例ではＶＭ１は第１ゾーンに存在し、ＶＭ２は第２ゾーンに存在し、ストレージ１は第３ゾーンに存在するとわかる。第１テーブルは後述する更新処理の際に更新されたり、定期的に更新されたりする。

第２テーブルは、タイム（時間）、リソース、デリート、ビフォー、アフターの項目から構成されている。すなわち、第２テーブルは、Ｗｅｂ ＡＰＩに対するゾーンのコントローラ３０からの応答の内容を記録している。

タイムには、リージョンマネージャ１０からのＡＰＩに対してコントローラ３０がレスポンスを発行した時間が格納される。

デリートには、リージョンマネージャ１０からのＡＰＩに対してコントローラ３０がレスポンスを発行した際、リソースの削除がされたか否かを示す情報が格納される。リソースが削除される場合にはＴｒｕｅ、削除されない場合にはＦａｌｓｅが格納される。例えば、第１ゾーンからリソースを削除する要求のＡＰＩに対するレスポンス（リソースを削除する旨のレスポンス）をコントローラ３０から受信した場合、Ｔｒｕｅが格納される。なお、リソースの削除以外の場合にはＦａｌｓｅが格納される。

ビフォーには、リージョンマネージャ１０からのＡＰＩに対してコントローラ３０がレスポンスを発行した際のリソースの移動元のゾーン情報が格納される。

アフターには、リージョンマネージャ１０からのＡＰＩに対してコントローラ３０がレスポンスを発行した際のリソースの移動先のゾーン情報が格納される。

図４の第２テーブルの１行目は、レスポンスを発行した時間が２０１６年１月６日の１２時２３分２３．３４５秒、対象リソースがＶＭ１、リソースの移動のためデリートがＦａｌｓｅ、ＶＭ１の移動元が第１ゾーンで移動先が第２ゾーンであることを示している。また、第２テーブルの３行目では、ビフォー及びアフターの項目がＮｕｌｌ（空白）となっている。これは、リソースが削除されるため、リソースの移動元及び移動先の情報を空白としている。

次に、実施形態の情報処理装置のハードウェア構成について図５を用いて説明する。リージョンマネージャ１０のハードウェアは、Central Processor Unit（ＣＰＵ）５０、Hard Disk Drive（ＨＤＤ）５１、Random Access Memory（ＲＡＭ）５２、Read Only Memory（ＲＯＭ）５３、通信インタフェース５４、バス５５から構成されている。ＣＰＵ５０、ＨＤＤ５１、ＲＡＭ５２、ＲＯＭ５３、通信インタフェース５４は、例えばバス５５を介して互いに接続されている。

ＣＰＵ５０は、バス５５を介して、ＨＤＤ５１などに格納される各種処理（例えば、後述する第１テーブルの更新処理など）を行うためのプログラムを読み込み、読み込んだプログラムをＲＡＭ５２に一時的に格納し、そのプログラムにしたがって各種処理を行う。ＣＰＵ５０は、主として、上述した判断部３３、記録部３４、更新処理部３５として機能する。

ＨＤＤ５１には、情報処理装置１０の各種処理を行うためのアプリケーションプログラムや、情報処理装置１０の処理に必要なデータなどが格納される。ＨＤＤ５１は、主として格納部３６として機能する。

ＲＡＭ５２は、揮発性メモリであって、ＣＰＵ５０に実行させるためのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）プログラムやアプリケーションプログラムの一部が一時的に格納される。また、ＲＡＭ５２には、ＣＰＵ５０による処理に必要な各種データが格納される。

ＲＯＭ５３は、不揮発性メモリであって、ブートプログラムやＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）などのプログラムを記憶する。

通信インタフェース５４は、外部（ユーザ装置４やコントローラ３０など）とネットワークを介してデータの送受信を行うものである。通信インタフェース５４は、主として受信部３１、発行部３２として機能する。

バス５５は、各装置間の制御信号、データ信号などの授受を媒介する経路である。
次に、実施形態の情報処理装置におけるユーザ装置からＡＰＩを受信した場合の処理について図６を用いて説明する。

例えば、ユーザ装置４から発行されたＡＰＩを受信したリージョンマネージャ１０がＡＰＩを処理し、コントローラ３０がリソース（例えば、ＶＭ１）を第１ゾーンから第２ゾーンへ移動させる処理を決定したことによる処理（テーブルの更新処理）について説明する。ここでのユーザ装置４からのＡＰＩは、例えばＶＭ１のスペックの変更を要求するためのＡＰＩである。

リージョンマネージャ１０は、ユーザ装置４によって発行されたＡＰＩを受信すると（ステップＳ６０１）、ＡＰＩの受信に基づいて格納部３６の第１テーブルにゾーン情報の記録があるか否かを判断する（ステップＳ６０２）。すなわち、リージョンマネージャ１０は、第１テーブルに全くゾーンの情報の記録がないか否かを確認する。

第１テーブルに記録がない場合（ステップＳ６０２でＮｏ）、リージョンマネージャ１０は全てのゾーンのコントローラ３０へＡＰＩを発行する（ステップＳ６０３）。このとき発行されるＡＰＩはＶＭ１がゾーンに存在するか否かを確認するためのものである。第１テーブルに全く記録がないため、全てのコントローラ３０に確認する。リージョンマネージャ１０は、各ゾーンのコントローラ３０からのレスポンスを受信するとステップＳ６０６へ進んでレスポンス内容に応じて第２テーブルに記録する。

一方、第１テーブルに記録がある場合（ステップＳ６０２でＹｅｓ）、リージョンマネージャ１０は第１テーブルにＶＭ１があるか確認し、ＶＭ１がある場合にＶＭ１に対応付けられたゾーン（例えば、第１ゾーン）にＶＭ１が存在するか判断する（ステップＳ６０４）。このとき、リージョンマネージャ１０は、第１ゾーンのコントローラ３０に対してＶＭ１の存在確認のためのＡＰＩを発行し、コントローラ３０からのレスポンス（ＶＭ１が存在するか否かの情報を含む）に基づいてＶＭ１が存在するか判断する。すなわち、所望のリソース（ＶＭ１）の存在確認の確認ＡＰＩに対する応答に基づいて、所望のリソースが取得できたか否かを判断する。

ユーザ装置４からＡＰＩを受信した時点における第１テーブル及び第２テーブルの例を図７に示す。第１テーブルではＶＭ１は第１ゾーン、ＶＭ２は第２ゾーンに存在することを示しており、第２テーブルには記録がないことを示している。

ＶＭ１が第１ゾーンに存在する場合（ステップＳ６０４でＹｅｓ）、リージョンマネージャ１０はＶＭ１が存在する第１ゾーンのコントローラ３０に対してＡＰＩを発行する（ステップＳ６０５）。ここで発行されるＡＰＩは、ユーザ装置４からのＡＰＩ、すなわちＶＭ１のスペックの変更を要求するためのＡＰＩである。なお、ＶＭ１が第１ゾーンに存在しない場合（ステップＳ６０４でＮｏ）には第１テーブル更新処理ステップ（破線の処理ステップ）が行われるが、第１テーブルの更新処理が行われる場合については以下で図１０を用いて説明する。

ＡＰＩを受信したコントローラ３０は、ＶＭ１のスペックを第１ゾーンでは変更することができないと判断し、変更可能なゾーン（例えば、第２ゾーン）へＶＭ１を移動させることを決定する。コントローラ３０はＶＭ１を第１ゾーンから第２ゾーンへ移動させる旨のレスポンスをリージョンマネージャ１０へ送信するとともに、レスポンスの送信とは非同期にＶＭ１を第１ゾーンから第２ゾーンへ移動する処理を行う。

リージョンマネージャ１０は、コントローラ３０からレスポンスを受信すると、レスポンス内容に応じて第２テーブルに記録を行う（ステップＳ６０６）。このとき記録される内容が図８の第２テーブルに示されている。タイムにはコントローラ３０がレスポンスを発行した時間が記録され、リソースには対象リソースのＶＭ１が記録され、デリートにはＶＭ１が削除されていないためＦａｌｓｅが記録され、ビフォーには移動元の第１ゾーンが記録され、アフターには移動先の第２ゾーンが記録される。このとき、リージョンマネージャ１０は第１テーブルの更新を行わない。第１テーブルの更新のタイミングについては以下で説明する。

第２テーブルの記録が完了すると、リージョンマネージャ１０はユーザ装置４に対してＶＭ１のスペックの変更のために第１ゾーンから第２ゾーンへＶＭ１が移動される旨のレスポンスを返す（ステップＳ６０７）。

ここで、第１テーブルの更新タイミングについて図９Ａ、図９Ｂを用いて説明する。図９Ａは後述する第１テーブル更新処理が発生した際に第１テーブルを更新するフローであり、図９Ｂは第１テーブル更新処理の有無に関わらず所定の時間経過によって第１テーブルを更新するフローである。

まず、図９Ａのフローについて説明する。後述する第１テーブル更新処理が開始されると、リージョンマネージャ１０は第１テーブル上の該当リソースを第２テーブルの最新の記録に基づいて更新する（ステップＳ９０１ａ）。具体的には、第２テーブルの最新の記録においてＶＭ１が第１ゾーンから第２ゾーンへ移動したと記録されている場合には、第１テーブルにおけるＶＭ１のゾーンを第１ゾーンから第２ゾーンへ変更する。すなわち、リージョンマネージャ１０は、ステップＳ６０６では第２テーブルへの記録のみで第１テーブルの更新をせず、第１テーブルの更新処理が開始された際に第２テーブルの記録に基づいて第１テーブルを更新する。

また、図９Ｂのフローについて説明する。リージョンマネージャ１０は、前回に第１テーブルを更新してから一定の時間ｘ（秒）以上が経過したか否かを判断する（ステップＳ９０１ｂ）。一定の時間ｘ以上が経過した場合（ステップＳ９０１ｂでＹｅｓ）、リージョンマネージャ１０は第１テーブルを第２テーブルの記録に基づいて更新する（ステップＳ９０２ｂ）。一方、一定の時間ｘ以上が経過していない場合（ステップＳ９０１ｂでＮｏ）、リージョンマネージャ１０は第１テーブルを更新しない。

図６のステップＳ６０１からＳ６０７の処理によりＶＭ１は第２ゾーンへ移動し、第２ゾーンへの移動の記録が第２テーブルにされているが、第１テーブルはまだ更新されていない状態となっている。以下では、時間の経過による第１テーブルの更新ではない第１テーブルの更新処理（図９Ａの場合の更新処理）について図１０を用いて説明する。

図１０に示すフローは、図６のステップＳ６０１からＳ６０７の処理が完了した後に、ユーザ装置４によってＡＰＩが発行された場合のフローである。

リージョンマネージャ１０は、ユーザ装置４によって発行されたＡＰＩを受信する（ステップＳ１００１）。ここでのユーザ装置４からのＡＰＩは、例えばＶＭ１がどのゾーンにあるか探索するためのＡＰＩ（探索ＡＰＩ）である。

リージョンマネージャ１０は、ＡＰＩの受信に基づいて格納部３６の第１テーブルにゾーン情報の記録があるか否かを判断する（ステップＳ１００２）。すなわち、リージョンマネージャ１０は、第１テーブルに全くゾーンの情報の記録がないか否かを確認する。

ユーザ装置４から探索ＡＰＩを受信した時点における第１テーブル及び第２テーブルの例を図１１に示す。第１テーブルは更新されておらず図８の第１テーブルと同様である。また、第２テーブルについても図８の第２テーブルと同様である。このとき、コントローラ３０の移動処理によって第１ゾーンのＶＭ１（破線）は第２ゾーンへ移動された状態となっている。すなわち、内部処理が成功した状態となっている。

第１テーブルに記録がない場合（ステップＳ１００２でＮｏ）、リージョンマネージャ１０は全てのゾーンのコントローラ３０へＡＰＩを発行する（ステップＳ１００３）。このとき発行されるＡＰＩはＶＭ１がどのゾーンに存在するか否かを確認するためのものである。第１テーブルに全く記録がないため、全てのコントローラ３０に確認する。リージョンマネージャ１０は、各ゾーンのコントローラ３０からのレスポンスを受信すると、ステップＳ１００７へ進んでレスポンス内容に応じて第２テーブルに記録する。

一方、第１テーブルに記録がある場合（ステップＳ１００２でＹｅｓ）、リージョンマネージャ１０は第１テーブルにＶＭ１があるか確認し、ＶＭ１がある場合にＶＭ１に対応付けられたゾーン（例えば、第１ゾーン）にＶＭ１が存在するか判断する（ステップＳ１００４）。このとき、リージョンマネージャ１０は、第１ゾーンのコントローラ３０に対してＶＭ１の存在確認のためのＡＰＩを発行し、コントローラ３０からのレスポンス（ＶＭ１が存在するか否かの情報を含む）に基づいてＶＭ１が存在するか判断する。

ＶＭ１は第１ゾーンから第２ゾーンへ移動しているため、コントローラ３０からのレスポンスにはＶＭ１は第１ゾーンに存在しない旨の情報が含まれている。すなわち、所望のリソース（ＶＭ１）に対応するゾーン（第１ゾーン）のコントローラ３０へ発行された所望のリソースの存在確認のＡＰＩに対する応答によって所望のリソースを取得できない。

これにより、ＶＭ１は第１ゾーンに存在しない（ステップＳ１００４でＮｏ）と判断し、リージョンマネージャ１０は第１テーブルの更新処理を行う（ステップＳ１００５）。すなわち、リージョンマネージャ１０は第２テーブルの内容（アフターに記録された最新の第２ゾーン）で第１テーブルのＶＭ１のゾーンを第１ゾーンから第２ゾーンへ更新する。更新後の第１テーブルの内容を図１２に示す。第１テーブルのＶＭ１のゾーンが第１ゾーンから第２ゾーンへ更新されている。なお、このとき第２テーブルの変更はない。

その後、リージョンマネージャ１０はステップＳ１００２へ戻り、格納部３６の第１テーブルにゾーン情報の記録があるか否かを判断する。記録はあるため、ステップＳ１００４と同様、リージョンマネージャ１０は更新された第１テーブルに基づいてＶＭ１が第２ゾーンに存在するか判断する。この場合、ＶＭ１は第２ゾーンに存在するため、リージョンマネージャ１０はＶＭ１が存在する第２ゾーンのコントローラ３０に対してＡＰＩを発行する（ステップＳ１００６）。ここで発行されるＡＰＩは、ユーザ装置４からのＡＰＩ、すなわちＶＭ１がどのゾーンにあるか探索するための探索ＡＰＩである。

このＡＰＩを受信したコントローラ３０は、ＶＭ１が第２ゾーンに存在するため、ＶＭ１が第２ゾーンに存在する旨のレスポンスをリージョンマネージャ１０へ送信する。

リージョンマネージャ１０は、コントローラ３０からレスポンスを受信すると、レスポンス内容に応じて第２テーブルに記録する（ステップＳ１００７）。このとき記録された第２テーブルの内容が図１３に示されている。２行目のデータが今回記録された内容である。タイムにはコントローラ３０がレスポンスを発行した時間が記録され、リソースには対象リソースのＶＭ１が記録され、デリートにはＶＭ１が削除されていないためＦａｌｓｅが記録され、ビフォーには移動元の第２ゾーンが記録され、アフターには移動先の第２ゾーンが記録される。ここで、ＶＭ１は既に第２ゾーンへ移動され、レスポンスを返す時点では移動前も移動後も第２ゾーンに存在しているため、ビフォーもアフターも第２ゾーンとなっている。このとき、リージョンマネージャ１０は第１テーブルの更新を行わない。

第２テーブルの記録が完了すると、リージョンマネージャ１０はユーザ装置４に対してＶＭ１が第２ゾーンに存在する旨のレスポンスを返す（ステップＳ１００８）。

上述したように、図６のステップＳ６０１からＳ６０７の処理の間にＶＭ１が第２ゾーンへ移動するケースもある。しかし、コントローラ３０による移動処理はリージョンマネージャ１０へのレスポンス送信とは非同期であるため、ＶＭ１が第２ゾーンへ移動せずに第１ゾーンに残ったままのケースもある。

以下では、ＶＭ１が第１ゾーンから第２ゾーンへ移動したとするレスポンスを返信したが、実際にはＶＭ１が第１ゾーンに未だ残っている状態におけるリージョンマネージャの処理について図１４を用いて説明する。

図１４に示すフローは、図６のステップＳ６０１からＳ６０７の処理が完了した後に、ユーザ装置４によってＡＰＩが発行された場合のフローである。このとき、第２テーブルは図１５に示すようにコントローラ３０からのレスポンスに基づいて記録されたが、第１ゾーンのＶＭ１は第２ゾーンへ移動せずに第１ゾーンに残った状態（内部処理が失敗した状態）となっている。

この状態において、リージョンマネージャ１０は、ユーザ装置４によって発行されたＡＰＩを受信する（ステップＳ１４０１）。ここでのユーザ装置４からのＡＰＩは、例えばＶＭ１がどのゾーンにあるか探索するための探索ＡＰＩである。

リージョンマネージャ１０は、ＡＰＩの受信に基づいて格納部３６の第１テーブルにゾーン情報の記録があるか否かを判断する（ステップＳ１４０２）。すなわち、リージョンマネージャ１０は、第１テーブルに全くゾーンの情報の記録がないか否かを確認する。

第１テーブルに記録がない場合（ステップＳ１４０２でＮｏ）、リージョンマネージャ１０は全てのゾーンのコントローラ３０へＡＰＩを発行する（ステップＳ１４０３）。このとき発行されるＡＰＩはＶＭ１がゾーンに存在するか否かを確認するためのものである。第１テーブルに全く記録がないため、全てのコントローラ３０に確認する。リージョンマネージャ１０は、各ゾーンのコントローラ３０からのレスポンスを受信すると、ステップＳ１４０７へ進んでレスポンス内容に応じて第２テーブルに記録する。

一方、第１テーブルに記録がある場合（ステップＳ１４０２でＹｅｓ）、リージョンマネージャ１０は第１テーブルにＶＭ１があるか確認し、ＶＭ１がある場合にＶＭ１に対応付けられたゾーン（例えば、第１ゾーン）にＶＭ１が存在するか判断する（ステップＳ１４０４）。このとき、リージョンマネージャ１０は、第１ゾーンのコントローラ３０に対してＶＭ１の存在確認のためのＡＰＩを発行し、コントローラ３０からのレスポンス（ＶＭ１が存在するか否かの情報を含む）に基づいてＶＭ１が存在するか判断する。

この場合、ＶＭ１は第１ゾーンに存在するため、コントローラ３０からのレスポンスにはＶＭ１が第１ゾーンに存在する旨の情報が含まれている。これにより、ＶＭ１は第１ゾーンに存在する（ステップＳ１４０４でＹｅｓ）と判断し、リージョンマネージャ１０はＶＭ１が存在する第１ゾーンのコントローラ３０に対してＡＰＩを発行する（ステップＳ１４０５）。ここで発行されるＡＰＩは、ユーザ装置４からのＡＰＩ、すなわちＶＭ１がどのゾーンにあるか探索するためのＡＰＩである。なお、ＶＭ１が第１ゾーンに存在しない場合（ステップＳ１４０４でＮｏ）には第１テーブル更新処理ステップ（破線の処理ステップ）が行われるが、このケースでは第１テーブルの更新処理は行われない。

ＡＰＩを受信したコントローラ３０は、ＶＭ１が第１ゾーンに存在するため、ＶＭ１が第１ゾーンに存在する旨の情報を含むレスポンスをリージョンマネージャ１０へ返す。

リージョンマネージャ１０は、コントローラ３０からレスポンスを受信すると、レスポンス内容に応じて第２テーブルに記録する（ステップＳ１４０６）。このとき記録された第２テーブルの内容が図１６に示されている。タイムにはコントローラ３０がレスポンスを発行した時間が記録され、リソースにはリソース対象のＶＭ１が記録され、デリートにはＶＭ１が削除されていないためＦａｌｓｅが記録され、ビフォーには移動元の第１ゾーンが記録され、アフターには移動先の第１ゾーンが記録される。このとき、リージョンマネージャ１０は第１テーブルの更新を行わない。

第２テーブルの記録が完了すると、リージョンマネージャ１０はユーザ装置４に対してＶＭ１が第１ゾーンに存在する旨の情報を含むレスポンスを返す（ステップＳ１４０７）。

実施形態の情報処理装置の１つの側面によれば、すべてのゾーンのコントローラへＷｅｂ ＡＰＩを発行することにより生じる負荷を軽減することができる。第１テーブルの更新処理を遅らせることで、内部処理が成功した場合、従来よりも更新時間を要する。しかし、近年のパブリッククラウドにおける膨大なゾーンの増加が予想され、内部処理が失敗するケースも多い。そのため、更新処理を遅らせることで全てのコントローラへＡＰＩを発行することによる負荷を軽減でき、リソース情報を取得することができる。

以上の実施形態に関して、更に以下の付記を開示する。
（付記１）リソースと前記リソースが存在するゾーンの対応を記録する第１テーブルと、
Ｗｅｂ ＡＰＩに対する前記ゾーンのコントローラからの応答の内容を記録する第２テーブルとを備える情報処理装置における情報処理方法であって、
前記応答内容の前記第２テーブルへの記録後、所望のリソースを探索するＷｅｂ ＡＰＩを受信し、前記第１テーブルに基づいて前記所望のリソースに対応するゾーンのコントローラへ発行された前記所望のリソースの存在確認の確認ＡＰＩに対する応答によって前記所望のリソースを取得できない場合、
前記第２テーブルの記録に基づいて前記第１テーブルを更新する、
ことを特徴とする情報処理方法。
（付記２）前記第２テーブルにおけるリソースの移動先に記録されたゾーンの情報に基づいて前記第１テーブルを更新することを特徴とする付記１に記載の情報処理方法。
（付記３）前記所望のリソースの存在確認の確認ＡＰＩに対する応答に基づいて、前記所望のリソースが取得できたか否かを判断する、
ことを特徴とする付記１又は２に記載の情報処理方法。
（付記４）前記第１テーブルの更新後、
前記更新後の第１テーブルに基づいて、前記所望のリソースに対応するゾーンのコントローラへ前記所望のリソースの存在確認の確認ＡＰＩを発行し、
発行された前記Ｗｅｂ ＡＰＩに対する前記コントローラからの応答内容に基づいて前記第２テーブルに記録を行う、
ことを特徴とする付記１から３のいずれかに記載の情報処理方法。
（付記５）リソースと前記リソースが存在するゾーンの対応を記録する第１テーブルと、
Ｗｅｂ ＡＰＩに対する前記ゾーンのコントローラからの応答の内容を記録する第２テーブルとを備える情報処理装置によって実行される情報処理プログラムであって、
前記応答内容の前記第２テーブルへの記録後、所望のリソースを探索するＷｅｂ ＡＰＩを受信し、前記第１テーブルに基づいて前記所望のリソースに対応するゾーンのコントローラへ発行された前記所望のリソースの存在確認の確認ＡＰＩに対する応答によって前記所望のリソースを取得できない場合、
前記第２テーブルの記録に基づいて前記第１テーブルを更新する、
処理を前記情報処理装置のコンピュータに実行させることを特徴とする情報処理プログラム。
（付記６）前記第２テーブルにおけるリソースの移動先に記録されたゾーンの情報に基づいて前記第１テーブルを更新することを特徴とする付記５に記載の情報処理プログラム。
（付記７）前記所望のリソースの存在確認の確認ＡＰＩに対する応答に基づいて、前記所望のリソースが取得できたか否かを判断する、
ことを特徴とする付記５又は６に記載の情報処理プログラム。
（付記８）前記第１テーブルの更新後、
前記更新後の第１テーブルに基づいて、前記所望のリソースに対応するゾーンのコントローラへ前記所望のリソースの存在確認の確認ＡＰＩを発行し、
発行された前記Ｗｅｂ ＡＰＩに対する前記コントローラからの応答内容に基づいて前記第２テーブルに記録を行う、
ことを特徴とする付記５から７のいずれかに記載の情報処理プログラム。

１ パブリッククラウドシステム
２ リージョン
３（３ａ、３ｂ） ゾーン
４ ユーザ装置
１０ リージョンマネージャ
３０（３０ａ、３０ｂ） コントローラ
３１ 受信部
３２ 発行部
３３ 判断部
３４ 記録部
３５ 更新処理部
３６ 格納部
５０ ＣＰＵ
５１ ＨＤＤ
５２ ＲＡＭ
５３ ＲＯＭ
５４ 通信インタフェース
５５ バス

Claims (6)

1. リソースと前記リソースが存在するゾーンの対応を記録する第１テーブルと、
   Ｗｅｂ ＡＰＩに対する前記ゾーンのコントローラからの応答の内容を記録する第２テーブルと、
   前記応答内容の前記第２テーブルへの記録後、所望のリソースを探索するＷｅｂ ＡＰＩを受信し、前記第１テーブルに基づいて前記所望のリソースに対応するゾーンのコントローラへ発行された前記所望のリソースの存在確認の確認ＡＰＩに対する応答によって前記所望のリソースを取得できない場合、
   前記第２テーブルの記録に基づいて前記第１テーブルを更新する更新処理部とを、
   有することを特徴とする情報処理装置。
2. 前記更新処理部は、前記第２テーブルにおけるリソースの移動先に記録されたゾーンの情報に基づいて前記第１テーブルを更新することを特徴とする請求項１に記載の情報処理装置。
3. 前記所望のリソースの存在確認の確認ＡＰＩに対する応答に基づいて、前記所望のリソースが取得できたか否かを判断する判断部を、
   更に有することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第１テーブルの更新後、
   前記更新後の第１テーブルに基づいて、前記所望のリソースに対応するゾーンのコントローラへ前記所望のリソースの存在確認の確認ＡＰＩを発行する発行部と、
   発行された前記確認ＡＰＩに対する前記コントローラからの応答内容に基づいて前記第２テーブルに記録を行う記録部とを、
   更に有することを特徴とする請求項１から３のいずれかに記載の情報処理装置。
5. リソースと前記リソースが存在するゾーンの対応を記録する第１テーブルと、
   Ｗｅｂ ＡＰＩに対する前記ゾーンのコントローラからの応答の内容を記録する第２テーブルとを備える情報処理装置における情報処理方法であって、
   前記応答内容の前記第２テーブルへの記録後、所望のリソースを探索するＷｅｂ ＡＰＩを受信し、前記第１テーブルに基づいて前記所望のリソースに対応するゾーンのコントローラへ発行された前記所望のリソースの存在確認の確認ＡＰＩに対する応答によって前記所望のリソースを取得できない場合、
   前記第２テーブルの記録に基づいて前記第１テーブルを更新する、
   ことを特徴とする情報処理方法。
6. リソースと前記リソースが存在するゾーンの対応を記録する第１テーブルと、
   Ｗｅｂ ＡＰＩに対する前記ゾーンのコントローラからの応答の内容を記録する第２テーブルとを備える情報処理装置によって実行される情報処理プログラムであって、
   前記応答内容の前記第２テーブルへの記録後、所望のリソースを探索するＷｅｂ ＡＰＩを受信し、前記第１テーブルに基づいて前記所望のリソースに対応するゾーンのコントローラへ発行された前記所望のリソースの存在確認の確認ＡＰＩに対する応答によって前記所望のリソースを取得できない場合、
   前記第２テーブルの記録に基づいて前記第１テーブルを更新する、
   処理を前記情報処理装置のコンピュータに実行させることを特徴とする情報処理プログラム。

Images