JP6885264B2 - 情報処理装置、情報処理システム、及びプログラム - Google Patents

Description

本発明は、情報処理装置、情報処理システム、及びプログラムに関する。

クラウドサービスを構成するサーバ装置等で実行される仮想マシン（以下「ＶＭ」）をメンテナンスする際、いわゆるＶＭの毎回の作り直しを行うＩｍｍｕｔａｂｌｅ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅと呼ばれる方式が採用される。また、同一環境のＶＭを用意しておいて切替えを行うＢｌｕｅ／Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔと呼ばれる方式が採用される。ここで、「メンテナンス」とは、「ＶＭを作成し直す」、「ＶＭを削除する」等の保守作業を意味する。

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

しかし、ＶＭのメンテナンスの上記従来方式では、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスやサーバリソースを潤沢に用意することが望ましく、リソースが限られている状況では利用に制限が生じる。

また、メンテナンス対象のＶＭを特別な考慮なく選択した場合、下記の場合に、選択されなかったＶＭでサービスを維持する時間も長くなってしまう。

・時間がかかる処理をしているＶＭを選択した場合
・選択しなかったＶＭの性能が著しく劣化している場合
・通常と傾向が異なり例えば非常に大きなリクエスト数が見込まれる場合

このため、結果的にユーザへのサービス保証値を守ることが難しくなったり、システムダウンを引き起こしたりする可能性がある。

そこで、本発明の１つの側面では、過去のモニタリング傾向からコンピュータのメンテナンスを開始する時間を決定する場合に、システムダウンを起こさないようにメンテナンスを行うコンピュータの順番を決定することを目的とする。

態様の一例では、複数のコンピュータのメンテナンスを制御するプロセッサを備える情報処理装置であって、前記複数のプロセッサは、前記コンピュータへのリクエストを記録し、過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、前記メンテナンスの実施候補のコンピュータに対し前記メンテナンスを実施する時間帯を決定し、前記決定した時間帯まで待機し、前記待機の後、前記メンテナンスの実施候補のコンピュータ毎に、前記コンピュータに割当て済みのリクエストから前記コンピュータのメンテナンス待機時間を決定し、前記決定されたメンテナンス待機時間に基づいて、前記メンテナンスの実施候補のコンピュータについて前記メンテナンスを実行する順番を決定する。

過去のモニタリング傾向からコンピュータのメンテナンスを開始する時間を決定する場合に、システムダウンを起こさないようにメンテナンスを行うコンピュータの順番を決定することが可能となる。

情報処理装置の実施形態が適用されるクラウドシステムの例を示す図である。 情報処理装置のブロック図である。 メンテナンス制御処理の例を示すフローチャート（その１）である。 メンテナンス制御処理の例を示すフローチャート（その２）である。 実施形態の説明図である。 メンテナンス処理の詳細例を示すフローチャートである。 情報処理装置の実施形態を実現可能なコンピュータのハードウェアの一例を示す図である。

以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。図１は、情報処理装置の実施形態が適用されるクラウドシステムの例を示す図である。クラウドシステム１００は、１つ以上のサーバ装置（コンピュータ）１０４上で実行される＃１から＃ＮのＮ台（Ｎは１以上の整数）のＶＭ１０２を含む。また、クラウドシステム１００は、外部からのアクセスをＮ台のＶＭ１０２のうちの何れかに振り分けるロードバランサ（以下「ＬＢ」）１０３を含む。更に、クラウドシステム１００は、Ｎ台のＶＭ１０２に対してメンテナンスを実施する情報処理装置１０１を含む。

図２は、図１の情報処理装置１０１の実施形態を示すブロック図である。情報処理装置１０１は、図１の複数台のＶＭ１０２を制御するプロセッサ２００を備える。

プロセッサ２００は、図１の＃１から＃Ｎの夫々のＶＭ１０２へのリクエストを記録する（Ｓ２０１）。

次に、プロセッサ２００は、過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、各ＶＭ１０２に対しメンテナンスを実施する時間帯を決定する（Ｓ２０２）。

プロセッサ２００は、上記決定した時間帯まで待機する（Ｓ２０３→Ｓ２０４→Ｓ２０３の繰返し）。ここで、「メンテナンス時間帯」とは、一日の中の時間帯のうち、図１のクラウドシステム１００全体でリクエストの処理数が少なく、メンテナンスを実施するのに適した時間帯をいう。

プロセッサ２００は、上記待機の後、メンテナンスの実施候補のＶＭ１０２毎に、ＶＭ１０２のメンテナンス待機時間を決定する（Ｓ２０４→Ｓ２０５）。「メンテナンス待機時間」とは、メンテナンス対象のＶＭ１０２について、現在の処理状況から、メンテナンス処理の開始指示が出されてからメンテナンスが開始できるまでに必要な待機時間をいう。プロセッサ２００は、ＶＭ１０２のメンテナンス待機時間を例えば、ＶＭ１０２のリクエストの種別及び数とリクエスト処理性能や負荷から決まる処理速度とに基づいて決定する。メンテナンス対象のＶＭ１０２について、メンテナンス処理の開始が指示された場合、そのＶＭ１０２は図１のＬＢ１０３によって切り離されるが、その時点で現在処理中のリクエストの実行が完了してから、メンテナンス処理が開始される。プロセッサ２００は、メンテナンスの時間帯が到来したと判定された後、メンテナンス対象のＶＭ１０２毎に、メンテナンス処理の開始が指示されてからメンテナンス処理が開始されるまでの時間であるメンテナンス待機時間を決定する。

プロセッサ２００は、決定されたメンテナンスの時間帯にメンテナンスが実行される場合に、上記決定されたメンテナンス待機時間が短い順に、メンテナンスの実施候補のＶＭ１０２についてメンテナンスを実行する順番を決定する（Ｓ２０６）。メンテナンス処理の開始が指示されてからメンテナンス処理が開始されるまでの時間であるメンテナンス待機時間が短いＶＭ１０２からメンテナンス処理を開始したほうが、古いＶＭ１０２が開放され新しいＶＭ１０２に切り替わる時間が短く、全体への影響が少ない。そこで、本実施形態では、メンテナンス待機時間が短い順に、メンテナンス処理が実行されることになる。

上述の構成において、プロセッサ２００は例えば、ＶＭ１０２に対してサービス保証上限値が設定されている場合には、そのサービス保証上限値を考慮してメンテナンスを実施する時間帯を決定する。より具体的には、プロセッサ２００は例えば、現在のリクエスト傾向が過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が過去のリクエスト傾向におけるリクエスト数に対して多い場合には、サービス保証上限値を考慮して警告を行って、ＶＭ１０２の管理者がメンテナンスの実行又は見送りを選択可能とする。上記管理者がメンテナンスを実行することを選択した場合には、プロセッサ２００は例えば、決定した時間帯まで待機した後にメンテナンス処理を開始する。また、上記管理者がメンテナンスを実行しないことを選択した場合には、プロセッサ２００は例えば、メンテナンスの実行を例えば翌日以降に見送る。

また、プロセッサ２００は例えば、現在のリクエスト傾向が過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が過去のリクエスト傾向におけるリクエスト数に対して少ない場合には、上記管理者がメンテナンスを直ちに実行するか否かを選択可能とする。上記管理者が、メンテナンスを直ちに実行することを選択した場合には、プロセッサ２００は例えば、前述した待機をせずにメンテナンス処理を開始する。また、上記管理者がメンテナンスを直ちには実行しないことを選択した場合には、プロセッサ２００は例えば、決定した時間帯まで待機した後にメンテナンス処理を開始させる。

更に、プロセッサ２００は例えば、現在のリクエスト傾向が過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が過去のリクエスト傾向におけるリクエスト数に対して平均的である場合には、決定した時間帯まで待機した後にメンテナンス処理を開始する。

一方、プロセッサ２００は例えば、現在のリクエスト傾向が過去のリクエスト傾向に沿っていない特異傾向にある場合には、警告を行って上記管理者がメンテナンスの実行又は見送りを選択可能とする。上記管理者がメンテナンスを実行する選択を行った場合には、プロセッサ２００は例えば、上記待機をせずにメンテナンス処理を開始する。また、上記管理者がメンテナンスを実行しないことを選択した場合には、プロセッサ２００は例えば、メンテナンスの実行を例えば翌日以降に見送る。

以上の情報処理装置１０１によるメンテナンス制御の動作により、本実施形態では、メンテナンスの実行に先立って常時、プロセッサ２００が、過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、各ＶＭ１０２に対しメンテナンスを実施する大まかな時間帯をまず決定して、それまで待機する。そして、プロセッサ２００が、各ＶＭ１０２のリクエストの種別及び数とリクエスト処理性能から決定した各ＶＭ１０２のメンテナンス待機時間が短い順に、メンテナンスの実施候補のＶＭ１０２のメンテナンス実行順を決定する。これらの制御により、本実施形態では、メンテナンス待機時間が長いＶＭ１０２がメンテナンスのために選択されてしまったり、逆にメンテナンスのために選択されなかったＶＭの性能が著しく劣化した状態であったり、といった状況を回避することが可能となる。より具体的には、本実施形態では、リクエスト数が多めの傾向であって、かつサービス保証上限値が設定されているような場合には、そのサービス保証上限値を考慮して警告を行って、管理者がメンテナンスの実行又は見送りを選択できる。逆に、リクエスト数が少なめの傾向である場合には、管理者が過去の傾向に基づく待機を行わずに、メンテナンスを直ちに実行することを選択できる。更に、本実施形態では、過去の傾向と異なる、例えば非常に大きなリクエスト数が見込まれるような特異傾向が検出されることにより、管理者がメンテナンスの実施／見送りを選択できる。この結果、本実施形態では、選択されなかったＶＭ１０２でサービスを維持する時間が長くなってしまい、結果的にユーザへのサービス保証値を守ることが難しくなったり、システムダウンを引き起こしたりする可能性を回避することが可能となる。

したがって、本実施形態によれば、新規作成分のサーバリソース等の余剰なサーバリソースが存在する時間を最小限にする効果と、例えばメンテナンス対象として選択されていないＶＭによる片系処理時間を最小限にする効果が得られる。さらにメンテナンスに適した日や時間を提案できる効果も得られる。

図３及び図４は、メンテナンス制御処理の例を示すフローチャートである。まず、図１の情報処理装置１０１は、＃１から＃Ｎの各ＶＭ１０２のリクエスト数をモニタリングする（ステップＳ３０１）。例えば、仮想マシンサービスを例にとると、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を介したリクエスト数を、例えば以下のような形式でモニタリングする。なお実際には、このモニタリングは常に実施されているので、統計量の出し方(毎時、毎分等)は問わない。

・１０時−１１時 １００ＡＰＩリクエスト／時
・１１時−１２時 １２０ＡＰＩリクエスト／時
・１２時−１３時 ９０ＡＰＩリクエスト／時

次に、情報処理装置１０１内のプロセッサ２００（図２）は、過去の傾向とメンテナンス実施時間とから、メンテナンスを実施する最良タイミングを判断する（ステップＳ３０２）。この判断は例えば、「日曜日の朝がもっとも時間あたりのリクエスト数が少ない」等の判断である。具体的には、メンテナンスの管理者によりメンテナンス実施時間が例えば「夜の時間帯」と指定された場合に、プロセッサ２００は、過去にモニタリングしている例えば１時間毎のリクエスト数のうち、夜の時間帯の中でリクエスト数が最も少ない時間を、最良タイミングとして判断する。

続いて、プロセッサ２００は、現在（当日）のリクエスト傾向が、過去のリクエスト傾向の通り（ほぼ沿っている）か、特異傾向であるか（沿っていないか）を判定する（ステップＳ３０３）。

プロセッサ２００は、現在（当日）のリクエスト傾向が過去のリクエスト傾向の通りであると判定すると、更に、現在（当日）のリクエスト数を過去のリクエスト傾向におけるリクエスト数と比較して判定する（ステップＳ３０３→Ｓ３０４）。

プロセッサ２００は、現在（当日）のリクエスト数が多いと判定した場合、サービス保証上限値を考慮して情報処理装置１０１のディスプレイ（後述する図７の７０４等）に警告を行う（ステップＳ３０５）。サービス保証上限値としては例えば、下記のような数値が設定されており、上記警告としては、これらの保証値が満たされなくなる旨の表示がなされる。

・１分以内にレスポンスが返却されること
・レスポンス成功率が９９．９９９９９９％以上であること
・１分間に３００多重のＡＰＩ実施まで保証すること

その後、プロセッサ２００は、メンテナンスを実行するか否かを選択する（ステップＳ３０６）。

プロセッサ２００がメンテナンスを実行することを選択した場合、プロセッサ２００は、ステップＳ３０２で判断した最良タイミングが到来するまで待機する（ステップＳ３０６→Ｓ３０９→Ｓ３１０の判定がＮＯ→Ｓ３０９の繰返し処理）。プロセッサ２００は、その後（ステップＳ３１０の判定がＹＥＳとなったとき）、図４のステップＳ３１４の処理に移行する。

プロセッサ２００がメンテナンスを実行しないことを選択した場合、プロセッサ２００は、メンテナンスの実行を例えば翌日以降に見送る（ステップＳ３０６→Ｓ３０７）。

プロセッサ２００は、現在（当日）のリクエスト数が少ないと判定した場合、メンテナンスを直ちに実行するか否かを選択する（ステップＳ３０８）。

プロセッサ２００がメンテナンスを直ちに実行することを選択した場合、プロセッサ２００は、図４のステップＳ３１４の処理に移行する。

プロセッサ２００がメンテナンスを直ちには実行しないことを選択した場合、プロセッサ２００は、ステップＳ３０２で判断した最良タイミングが到来するまで待機する（ステップＳ３０６→Ｓ３０９→Ｓ３１０の判定がＮＯ→Ｓ３０９の繰返し処理）。プロセッサ２００は、その後（ステップＳ３１０の判定がＹＥＳとなったとき）、図４のステップＳ３１４の処理に移行する。

プロセッサ２００は、現在（当日）のリクエスト数が平均的であると判定した場合、ステップＳ３０２で判断した最良タイミングが到来するまで待機する（ステップＳ３０６→Ｓ３０９→Ｓ３１０の判定がＮＯ→Ｓ３０９の繰返し処理）。プロセッサ２００は、その後（ステップＳ３１０の判定がＹＥＳとなったとき）、図４のステップＳ３１４の処理に移行する。

プロセッサ２００は、現在のリクエスト傾向が過去のリクエスト傾向に沿っていない特異傾向にある場合には、情報処理装置１０１のディスプレイに警告を行い（ステップＳ３０３→Ｓ３１１）。その後、プロセッサ２００は、メンテナンスを実行するか否かを選択する（ステップＳ３１２）。

プロセッサ２００がメンテナンスを実行することを選択した場合、プロセッサ２００は、図４のステップＳ３１４の処理に移行する。

プロセッサ２００がメンテナンスを実行しないことを選択した場合、プロセッサ２００は、メンテナンスの実行を例えば翌日以降に見送る（ステップＳ３１２→Ｓ３１３）。

図５は、上記傾向の比較処理を説明するための実施形態の説明図である。横軸が経過時刻を示しており、縦軸がリクエスト数を示している。いま、メンテナンス実施時間が例えば１１時であるとする。過去のリクエスト傾向が５０１に示される変化であった場合、１１時時点での現在のリクエスト傾向が、例えば５０２に示される変化であれば、現在のリクエスト傾向は過去のリクエスト傾向の通りであり、リクエスト数は多いと判定される。また、１１時時点での現在のリクエスト傾向が、例えば５０３に示される変化であれば、現在のリクエスト傾向は過去のリクエスト傾向の通りであり、リクエスト数は少ないと判定される。更に、１１時時点での現在のリクエスト傾向が、例えば５０４に示される変化であれば、現在のリクエスト傾向は過去のリクエスト傾向の通りであり、リクエスト数は平均的であると判定される。一方、１１時時点での現在のリクエスト傾向が、例えば５０５に示される変化であれば、現在のリクエスト傾向は過去のリクエスト傾向に沿っておらず特異傾向であると判定される。図５に示されるような判定は、例えば現在から１日前までのリクエスト数の変化と、過去の同じ時間帯でのリクエスト数の変化とで、同時刻毎の差分を計算し、平均値との標準偏差を算出する等により、その値を判定して行うことができる。

以上のようにして、図２のプロセッサ２００の制御により、メンテナンスの時間帯が到来すると、図１の情報処理装置１０１内のプロセッサ２００は、図４のステップＳ３１４からＳ３１９の制御処理を実行する。

プロセッサ２００はまず、図１の＃１から＃ＮのＶＭ１０２のうち、メンテナンス実施候補のノード（＝ＶＭ１０２）の一覧を取得する（ステップＳ３１４）。

次に、プロセッサ２００は、ステップＳ３１５でステップＳ３１４にて取得したノード一覧からメンテナンスを実施する候補のノードを１つずつ選択しながら、ステップＳ３１９で全実施候補のノードの処理が終了したと判定するまで、ステップＳ３１６からＳ３１８の一連の処理を実行する。

上記一連の処理において、プロセッサ２００はまず、現在選択されているノード（＝ＶＭ１０２）に対応するリクエスト種別とリクエスト数を取得する（ステップＳ３１６）。リクエスト種別としては例えば、次のようなものがある。

・ＧＥＴ−ｓｅｒｖｅｒ：ＶＭ１０２の一覧取得
・ＰＯＳＴ−ｓｅｒｖｅｒ：ＶＭ１０２の作成
・ＤＥＬＥＴＥ−ｓｅｒｖｅｒ：ＶＭ１０２の削除
・ＰＵＴ−ｓｅｒｖｅｒ：ＶＭ１０２の変更
・ＰＯＳＴ−ｏｓ−ａｃｔｉｏｎｓ：ＶＭ１０２の移動（マイグレーション）
・ＰＯＳＴ−ｏｓ−ａｃｔｉｏｎｓ：ＶＭ１０２の移動（ライブマイグレーション）
・ＰＯＳＴ−ｏｓ−ａｃｔｉｏｎｓ：ＶＭ１０２の移動（ｒｅｓｉｚｅ）

次に、プロセッサ２００は、現在選択されているノード（＝ＶＭ１０２）に対応するリクエスト処理性能を取得する（ステップＳ３１７）。リクエスト処理性能としては、例えば或るＡＰＩ処理を受け付けてからレスポンスまでのリクエスト処理時間を採用でき、例えば次のように計算される。

・ＧＥＴ−ｓｅｒｖｅｒ：１２：００：００．０００受付け
・ＧＥＴ−ｓｅｒｖｅｒ：１２：００：００．８００返却
・リクエスト処理時間：０．８秒

そして、プロセッサ２００は、現在選択されているノード（＝ＶＭ１０２）に対応するメンテナンス待機時間を算出する（ステップＳ３１８）。メンテナンス待機時間は例えば、ステップＳ３１６で取得したリクエスト種別毎のリクエスト数と、ステップＳ３１７で取得したリクエスト種別毎の平均処理時間を用いて、以下のように算出できる。

メンテナンス待機時間＝Σ（リクエスト種別毎の平均処理時間×リクエスト数）

右辺のΣは、すべてのリクエスト種別に関する総和を表す。以上のステップＳ３１６からＳ３１８の一連の処理の繰返しにより、全てのメンテナンス実施候補のノードに対するメンテナンス待機時間が算出される（ステップＳ３１９の判定がＮＯの繰返し）。

全ての処理が終了する（ステップＳ３１９の判定がＹＥＳになる）と、次に、図１の情報処理装置１０１内のプロセッサ２００（図２）が、ステップＳ３２０からＳ３２２の一連の処理を実行する。

プロセッサ２００はまず、ステップＳ３１４で取得したノード一覧中で、までメンテナンスが実施されておらず、かつステップＳ３１８で算出されたメンテナンス待機時間が最短であるノード（＝ＶＭ１０２）を、メンテナンス対象のノードとして選択する（ステップＳ３２０）。

次に、プロセッサ２００は、ステップＳ３２０で選択したノード（＝ＶＭ１０２）に対して、メンテナンス処理を実行する（ステップＳ３２１）。

その後、プロセッサ２００は、メンテナンスを未だ実施していないノード候補が残っているか否かを判定する（ステップＳ３２２）。

ステップＳ３２２の判定がＹＥＳならば、プロセッサ２００は、ステップＳ３２０の処理に戻って、次にメンテナンス待機時間が短いノード候補を選択してメンテナンス処理を実行する。

ステップＳ３２２の判定がＮＯになると、プロセッサ２００は、図３及び図４のフローチャートで示されるメンテナンス制御処理を終了する。

以上のようにして、本実施形態では、メンテナンス待機時間が短いノード（＝ＶＭ１０２）から順にメンテナンス処理を実行することが可能となる。これにより、本実施形態によれば、システムダウンを起こさないようにメンテナンスを行うコンピュータの順番を決定することが可能となる。

図６は、図４のステップＳ３２１のメンテナンス処理の詳細例を示すフローチャートである。

図１の情報処理装置１０１はまず、図１のＬＢ１０３において、メンテナンス対象のＶＭ１０２を切り離す（ステップＳ６０１）。これとともに、情報処理装置１０１は、新たなＶＭ１０２の構築を実施する（ステップＳ６１０）。例えば図１において、＃ｉのＶＭ１０２がメンテナンス対象であったとすると、このＶＭ１０２（＃ｉ）がＬＢ１０３により切り離される。また例えば、図１に示される＃ｊのＶＭ１０２が、新たに構築される。

次に、情報処理装置１０１は、メンテナンス対象のＶＭ１０２において処理中のＡＰＩリクエスト数を確認する（ステップＳ６０２）。この処理により、例えば次のような情報が取得される。

・ＧＥＴ−ｓｅｒｖｅｒ：２０件
・ＰＯＳＴ−ｓｅｒｖｅｒ：１０件
・ＤＥＬＴＥ−ｓｅｒｖｅｒ：５件

次に、情報処理装置１０１は、ステップＳ６０１でのＬＢ１０３によるメンテナンス対象のＶＭ１０２の切離しの後、ステップＳ６０２で確認した全てのリクエストの処理が終了まで待機する（ステップＳ６０３→Ｓ６０４の判定がＮＯ→Ｓ６０３の繰返し処理）。

処理が終了する（ステップＳ６０４の判定がＹＥＳになる）と、情報処理装置１０１は、今まで稼働していた例えば図１の＃ｉのＶＭ１０２のサービス（図中「Ｓｅｒｖｉｃｅ」）を停止させる（ステップＳ６１１）。

次に、情報処理装置１０１は、新規構築された例えば図１の＃ｊのＶＭ１０２のＩＰアドレス（図中「ＩＰアドレス（＃ｊ）」）を、新たに設定されるＩＰアドレスに変更する（ステップＳ６１２）。

そして、情報処理装置１０１は、新たに構築したＶＭ１０２（＃ｊ）のサービスを起動し、図１のＬＢ１０３に、ＶＭ１０２（＃ｊ）を接続させる（ステップＳ６１３）。その後、情報処理装置１０１は、図６のフローチャートで示される図４のステップＳ３２１のメンテナンス処理を終了する。

図６のフローチャートで例示したメンテナンス方式は、メンテナンス対象のＶＭ１０２を新規で作成する方式であるが、ＶＭ１０２を新規で作成し直さない場合には、同一のＶＭ１０２でサービス停止・メンテナンス・サービス起動とする方式が採用されてもよい。その他、ＶＭ１０２に関して、様々なメンテナンス方式が採用されてもよい。

以上の図３、図４、及び図６のフローチャートで示されるメンテナンス制御処理の具体的な動作例について、以下に説明する。以下の説明では、図１のＶＭ１０２として＃１と＃２の２台のＶＭ１０２をメンテナンスする場合の例について説明する。

まず、リクエスト数がモニタリングされる（図３のステップＳ３０１）。例えば、現在時刻は９：００であり、２０１７／５／１１（木）の時刻毎のリクエストは以下であったとする。

・０時−１時：３０ＡＰＩリクエスト／時
・１時−２時：２０ＡＰＩリクエスト／時
・２時−３時：５０ＡＰＩリクエスト／時
・３時−４時：７０ＡＰＩリクエスト／時
・４時−５時：６０ＡＰＩリクエスト／時
・５時−６時：７０ＡＰＩリクエスト／時
・６時−７時：７０ＡＰＩリクエスト／時
・７時−８時：６０ＡＰＩリクエスト／時
・８時−９時：１８０ＡＰＩリクエスト／時

過去のデータより、平日木曜日の１日の平均リクエスト数は以下であったとする。

・０時−１時：２８ＡＰＩリクエスト／時
・１時−２時：１８ＡＰＩリクエスト／時
・２時−３時：４８ＡＰＩリクエスト／時
・３時−４時：６８ＡＰＩリクエスト／時
・４時−５時：５８ＡＰＩリクエスト／時
・５時−６時：６８ＡＰＩリクエスト／時
・６時−７時：６８ＡＰＩリクエスト／時
・７時−８時：６８ＡＰＩリクエスト／時
・８時−９時：１７８ＡＰＩリクエスト／時
・９時−１０時：２５０ＡＰＩリクエスト／時
・１０時−１１時：２８０ＡＰＩリクエスト／時
・１１時−１２時：２００ＡＰＩリクエスト／時
・１２時−１３時：１８０ＡＰＩリクエスト／時
・１３時−１４時：２９０ＡＰＩリクエスト／時
・１４時−１５時：３１０ＡＰＩリクエスト／時
・１５時−１６時：３００ＡＰＩリクエスト／時
・１６時−１７時：２５０ＡＰＩリクエスト／時
・１７時−１８時：２００ＡＰＩリクエスト／時
・１８時−１９時：１８０ＡＰＩリクエスト／時
・１９時−２０時：１６５ＡＰＩリクエスト／時
・２０時−２１時：１３０ＡＰＩリクエスト／時
・２１時−２２時：８０ＡＰＩリクエスト／時
・２２時−２３時：５０ＡＰＩリクエスト／時
・２３時−２４時：３０ＡＰＩリクエスト／時

これによると、深夜２３時がもっとも少ないため、最良タイミングであるといえる（図３のステップＳ３０２）。

０時〜９時までを見ると、平均値より本日のＡＰＩ数は若干多いのみで、傾向通りといえる（図３のステップＳ３０３→Ｓ３０４→Ｓ３０５）。特異傾向であるかどうかを判断するため、今回は各時間帯の平均値との差の標準偏差をとる。今回は全ての値が＋２の例をあげているため、標準偏差は0になる。標準偏差が0に近ければ近いほど傾向通りといえる。特異傾向であるかどうかの判定のための閾値は、平均値の標準偏差が、平均値の平均より大きい場合とする。傾向通りである場合の、多いか少ないかについては、平均値で判断する。多い場合、仮に本日のＡＰＩ数が毎時＋１００多かったとすると、標準偏差は0で傾向通りである。

サービス保証上限値（図３のステップＳ３０５）は１時間に３００だとすると、メンテナンスをしてしまった場合は処理性能が１／２になるため、１時間に１５０を超えてはならない。更に、通常より＋１００であることを考慮すると、過去の平均値が６０より大きい時間にメンテナンスをしてしまうとサービス保証上限値を超えてしまう。今回では２３時−２４時以外の時間帯が該当する。その場合は翌日以降に見送るかどうか、運用者に判断を委ねる（図３のステップＳ３０６）。

どの場合でも、メンテナンスを実施すると決めた場合は、２３時まで待機する（図３のステップＳ３０９→Ｓ３１０→Ｓ３０９の繰返し処理）。

２３時時点での各ノードが処理しているＡＰＩを確認し、メンテナンス待機時間を算出する（図４のステップＳ３１６〜Ｓ３１８）。単純にＡＰＩの数と過去の平均値から算出すると、例えば下記のような結果が得られる。

※ＶＭ３０２（＃１）：合計３３５０秒
・ＧＥＴ−ｓｅｒｖｅｒ：平均１秒×リクエスト数１００＝１００秒
・ＰＯＳＴ−ｓｅｒｖｅｒ：平均６０秒×リクエスト数５０＝３０００秒
・ＤＥＬＥＴＥ−ｓｅｒｖｅｒ：平均５秒×リクエスト数５０＝２５０秒
※ＶＭ３０２（＃２）：合計２１５０秒
・ＧＥＴ−ｓｅｒｖｅｒ：平均１秒×リクエスト数１００＝１００秒
・ＰＯＳＴ−ｓｅｒｖｅｒ：平均６０秒×リクエスト数３０＝１８００秒
・ＤＥＬＥＴＥ−ｓｅｒｖｅｒ：平均５秒×リクエスト数５０＝２５０秒

以上の結果より、ＶＭ１０２（＃２）からメンテナンスが開始される。
しかし、平均値ではなく、各ＶＭ１０２毎の現在の処理時間で再計算すると、下記の結果が得られる。

※ＶＭ３０２（＃１）：合計３３５０秒
・ＧＥＴ−ｓｅｒｖｅｒ：平均１秒×リクエスト数１００＝１００秒
・ＰＯＳＴ−ｓｅｒｖｅｒ：平均６０秒×リクエスト数５０＝３０００秒
・ＤＥＬＥＴＥ−ｓｅｒｖｅｒ：平均５秒×リクエスト数５０＝２５０秒
※ＶＭ３０２（＃２）：合計６４５０秒
・ＧＥＴ−ｓｅｒｖｅｒ：平均３秒×リクエスト数１００＝３００秒
・ＰＯＳＴ−ｓｅｒｖｅｒ：平均１８０秒×リクエスト数３０＝５４００秒
・ＤＥＬＥＴＥ−ｓｅｒｖｅｒ：平均１５秒×リクエスト数５０＝７５０秒

この場合には、ＶＭ１０２（＃１）からメンテナンスが開始される。
ＬＢ１０３（図１）による切離し以降の処理は計算は発生しない。今回は＃１と＃２の２台のＶＭ１０２が対象となるため、＃１のＶＭ１０２のメンテナンス終了後は自動的に＃２のＶＭ１０２が選択されることになる。

図７は、図１及び図２の情報処理装置１０１又はＶＭ１０２を実行するサーバ装置１０４の実施形態を実現可能なコンピュータのハードウェアの一例を示す図である。

図７に示されるコンピュータは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）７０１、メモリ７０２、入力装置７０３、出力装置７０４、補助情報記憶装置７０５、可搬型記録媒体７０９が挿入される媒体駆動装置７０６、及びネットワーク接続装置７０７を有する。これらの構成要素は、バス７０８により相互に接続されている。同図に示される構成は上記情報処理装置１０１を実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。

メモリ７０２は、例えば、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）、フラッシュメモリ等の半導体メモリであり、処理に用いられるプログラム及びデータを格納する。

ＣＰＵ（プロセッサ）７０１は、例えば、メモリ７０２を利用してプログラムを実行することにより、例えば図２のプロセッサ２００又は図１のサーバ装置１０４のプロセッサとして動作する。ＣＰＵ７０１がサーバ装置１０４のプロセッサである場合、ＣＰＵ７０１は、メモリ７０２を利用してプログラムを実行することにより、ＶＭ１０２を動作させる。

入力装置７０３は、例えば、キーボード、ポインティングデバイス等であり、オペレータ又はユーザからの指示又は情報の入力に用いられる。出力装置７０４は、例えば、表示装置、プリンタ、スピーカ等であり、オペレータ又はユーザへの問合せ（図３のステップＳ３０６、Ｓ３０８、又はＳ３１２等）又は処理結果の出力に用いられる。

補助情報記憶装置７０５は、例えば、ハードディスク記憶装置、磁気ディスク記憶装置、光ディスク装置、光磁気ディスク装置、テープ装置、又は半導体記憶装置である。図１又は図２の情報処理装置１０１は、補助情報記憶装置７０５にプログラム及びデータを格納しておき、それらをメモリ７０２にロードして使用することができる。

媒体駆動装置７０６は、可搬型記録媒体７０９を駆動し、その記録内容にアクセスする。可搬型記録媒体７０９は、メモリデバイス、フレキシブルディスク、光ディスク、光磁気ディスク等である。可搬型記録媒体７０９は、Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＣＤ−ＲＯＭ）、Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ（ＤＶＤ）、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）メモリ等であってもよい。オペレータ又はユーザは、この可搬型記録媒体７０９にプログラム及びデータを格納しておき、メモリ７０２にロードして使用することができる。

このように、図１又は図２の情報処理装置１０１の処理又は図１のＶＭ１０２を実行するサーバ装置１０４の処理に用いられるプログラム及びデータを格納するコンピュータ読取り可能な記録媒体は、メモリ７０２、補助情報記憶装置７０５、又は可搬型記録媒体７０９のような、物理的な（非一時的な）記録媒体である。

ネットワーク接続装置７０７は、例えばＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）等の通信ネットワークに接続され、通信に伴うデータ変換を行う通信インタフェースである。図１又は図２の情報処理装置１０１又は図１のサーバ装置１０４は、プログラム又はデータを外部の装置からネットワーク接続装置７０７を介して受信し、それらをメモリ７０２にロードして使用することができる。

なお、図１又は図２の情報処理装置１０１又は図１のサーバ装置が図７の全ての構成要素を含む必要はなく、用途又は条件に応じて一部の構成要素を省略することも可能である。例えば、可搬型記録媒体７０９を利用しない場合は、媒体駆動装置７０６が省略されてもよい。

以上の説明において、メンテナンス対象は必ずしも仮想マシン（ＶＭ）である必要はなく、物理的なサーバ装置等のコンピュータであってもよい。

その他、本発明は上述した実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、上述した実施形態で実行される機能は可能な限り適宜組み合わせて実施しても良い。上述した実施形態には種々の段階が含まれており、開示される複数の構成要件による適宜の組み合せにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、効果が得られるのであれば、この構成要件が削除された構成が発明として抽出され得る。

以上の実施形態に関して、更に以下の付記を開示する。
（付記１）
複数のコンピュータのメンテナンスを制御するプロセッサを備える情報処理装置であって、
前記プロセッサは、
前記複数のコンピュータへのリクエストを記録し、
過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、
前記メンテナンスの実施候補のコンピュータに対し前記メンテナンスを実施する時間帯を決定し、
前記決定した時間帯まで待機し、
前記待機の後、前記メンテナンスの実施候補のコンピュータ毎に、前記コンピュータに割当て済みのリクエストから前記コンピュータのメンテナンス待機時間を決定し、
前記決定されたメンテナンス待機時間に基づいて、前記メンテナンスの実施候補のコンピュータについて前記メンテナンスを実行する順番を決定する、
ことを特徴とする情報処理装置。
（付記２）
前記プロセッサは、前記コンピュータのリクエストの種別及び数とリクエスト処理性能とに基づいて、前記コンピュータのメンテナンス待機時間を決定する、ことを特徴とする付記１に記載の情報処理装置。
（付記３）
前記プロセッサは、前記コンピュータに対してサービス保証上限値が設定されている場合には、前記サービス保証上限値に少なくとも基づいて前記メンテナンスを実施する時間帯を決定する、付記１又は２に記載の情報処理装置。
（付記４）
前記プロセッサは、前記コンピュータに対してサービス保証上限値が設定されている場合であって、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が前記過去のリクエスト傾向におけるリクエスト数に対して多い場合には、前記サービス保証上限値に基づいて警告を行って前記メンテナンスの実行又は見送りを選択可能とし、前記メンテナンスを実行する場合には前記決定した時間帯まで待機した後に前記メンテナンスの処理を開始させる、付記１に記載の情報処理装置。
（付記５）
前記プロセッサは、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が前記過去のリクエスト傾向におけるリクエスト数に対して少ない場合には、前記メンテナンスを直ちに実行するか否かを選択可能とし、前記メンテナンスを直ちに実行する場合には前記待機をせずに前記メンテナンスの処理を開始させ、前記メンテナンスを直ちに実行しない場合には前記決定した時間帯まで待機した後に前記メンテナンスの処理を開始させる、付記１に記載の情報処理装置。
（付記６）
前記プロセッサは、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が前記過去のリクエスト傾向におけるリクエスト数に対して平均的である場合には、前記決定した時間帯まで待機した後に前記メンテナンス待機時間の決定の処理を開始させる、付記１に記載の情報処理装置。
（付記７）
前記プロセッサは、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っていない場合には、警告を行って前記メンテナンスの実行又は見送りを選択可能とし、前記メンテナンスを実行する場合には前記待機をせずに前記メンテナンス待機時間の決定の処理を開始させる、付記１に記載の情報処理装置。
（付記８）
前記メンテナンスを実行する順番を決定する場合に、決定された前記メンテナンス待機時間が少ない順に、前記メンテナンスの実施候補のコンピュータについて、前記メンテナンスを実行する、
付記１記載の情報処理装置。
（付記９）
複数のコンピュータと、前記コンピュータのメンテナンス処理を制御するプロセッサを備える情報処理装置とを含む情報処理システムであって、
前記情報処理システムのプロセッサは、
前記複数のコンピュータへのリクエストを記録し、
過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、前記各コンピュータに対し前記メンテナンスを実施する時間帯を決定し、
前記決定した時間帯まで待機し、
前記待機の後、前記メンテナンスの実施候補のコンピュータ毎に、前記コンピュータに割当て済みのリクエストから前記コンピュータのメンテナンス待機時間を決定し、
前記決定されたメンテナンス待機時間が短い順に、前記メンテナンスの実施候補のコンピュータについて前記メンテナンスを実行する順番を決定する、
ことを特徴とする情報処理システム。
（付記１０）
複数のコンピュータのメンテナンス処理を制御するプロセッサに、
前記複数のコンピュータへのリクエストを記録するステップと、
過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、前記各コンピュータに対し前記メンテナンスを実施する時間帯を決定するステップと、
前記決定した時間帯まで待機するステップと、
前記待機の後、前記メンテナンスの実施候補のコンピュータ毎に、前記コンピュータに割当て済みのリクエストから前記コンピュータのメンテナンス待機時間を決定するステップと、
前記決定されたメンテナンス待機時間が短い順に、前記メンテナンスの実施候補のコンピュータについて前記メンテナンスを実行する順番を決定するステップと、
を実行させるためのプログラム。

１００ クラウドシステム
１０１ 情報処理装置
１０２ ＶＭ（仮想マシン）
１０３ ＬＢ（ロードバランサ）
２００ プロセッサ
７０１ ＣＰＵ
７０２ メモリ
７０３ 入力装置
７０４ 出力装置
７０５ 補助情報記憶装置
７０６ 媒体駆動装置
７０７ ネットワーク接続装置
７０８ バス
７０９ 可搬型記録媒体

Claims (10)

1. 複数のコンピュータのメンテナンスを制御するプロセッサを備える情報処理装置であって、
   前記プロセッサは、
   前記複数のコンピュータへのリクエストを記録し、
   過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、
   前記メンテナンスの実施候補のコンピュータに対し前記メンテナンスを実施する時間帯を決定し、
   前記決定した時間帯まで待機し、
   前記待機の後、前記メンテナンスの実施候補のコンピュータ毎に、前記コンピュータに割当て済みのリクエストから前記コンピュータのメンテナンス待機時間を決定し、
   前記決定されたメンテナンス待機時間に基づいて、前記メンテナンスの実施候補のコンピュータについて前記メンテナンスを実行する順番を決定する、
   ことを特徴とする情報処理装置。
2. 前記プロセッサは、前記コンピュータのリクエストの種別及び数とリクエスト処理性能とに基づいて、前記コンピュータのメンテナンス待機時間を決定する、ことを特徴とする請求項１に記載の情報処理装置。
3. 前記プロセッサは、前記コンピュータに対してサービス保証上限値が設定されている場合には、前記サービス保証上限値に少なくとも基づいて前記メンテナンスを実施する時間帯を決定する、請求項１または２に記載の情報処理装置。
4. 前記プロセッサは、前記コンピュータに対してサービス保証上限値が設定されている場合であって、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が前記過去のリクエスト傾向におけるリクエスト数に対して多い場合には、前記サービス保証上限値に基づいて警告を行って前記メンテナンスの実行又は見送りを選択可能とし、前記メンテナンスを実行する場合には前記決定した時間帯まで待機した後に前記メンテナンスの処理を開始させる、請求項１に記載の情報処理装置。
5. 前記プロセッサは、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が前記過去のリクエスト傾向におけるリクエスト数に対して少ない場合には、前記メンテナンスを直ちに実行するか否かを選択可能とし、前記メンテナンスを直ちに実行する場合には前記待機をせずに前記メンテナンスの処理を開始させ、前記メンテナンスを直ちには実行しない場合には前記決定した時間帯まで待機した後に前記メンテナンスの処理を開始させる、請求項１に記載の情報処理装置。
6. 前記プロセッサは、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っており、かつ現在のリクエストの数が前記過去のリクエスト傾向におけるリクエスト数に対して平均的である場合には、前記決定した時間帯まで待機した後に前記メンテナンスの処理を開始させる、請求項１に記載の情報処理装置。
7. 前記プロセッサは、現在のリクエスト傾向が前記過去のリクエスト傾向に沿っていない場合には、警告を行って前記メンテナンスの実行又は見送りを選択可能とし、前記メンテナンスを実行する場合には前記待機をせずに前記メンテナンスの処理を開始させる、請求項１に記載の情報処理装置。
8. 前記メンテナンスを実行する順番を決定する場合に、決定された前記メンテナンス待機時間が少ない順に、前記メンテナンスの実施候補のコンピュータについて、前記メンテナンスを実行する、
   請求項１記載の情報処理装置。
9. 複数のコンピュータと、前記コンピュータのメンテナンス処理を制御するプロセッサを備える情報処理装置と含む情報処理システムであって、
   前記情報処理システムのプロセッサは、
   前記複数のコンピュータへのリクエストを記録し、
   過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、前記各コンピュータに対し前記メンテナンスを実施する時間帯を決定し、
   前記決定した時間帯まで待機し、
   前記待機の後、前記メンテナンスの実施候補のコンピュータ毎に、前記コンピュータに割当て済みのリクエストから前記コンピュータのメンテナンス待機時間を決定し、
   前記決定されたメンテナンス待機時間が短い順に、前記メンテナンスの実施候補のコンピュータについて前記メンテナンスを実行する順番を決定する、
   ことを特徴とする情報処理システム。
10. 複数のコンピュータのメンテナンス処理を制御するプロセッサに、
    前記複数のコンピュータへのリクエストを記録するステップと、
    過去のリクエスト傾向と、メンテナンスの実施時間とに基づいて、前記各コンピュータに対し前記メンテナンスを実施する時間帯を決定するステップと、
    前記決定した時間帯まで待機するステップと、
    前記待機の後、前記メンテナンスの実施候補のコンピュータ毎に、前記コンピュータに割当て済みのリクエストから前記コンピュータのメンテナンス時間を決定するステップと、
    前記決定されたメンテナンス待機時間が短い順に、前記メンテナンスの実施候補のコンピュータについて前記メンテナンスを実行する順番を決定するステップと、
    を実行させるためのプログラム。

Images