JP2016126693A - 制御手順方法、制御手順プログラム及び制御手順装置 - Google Patents

Abstract

【課題】情報処理システムの状態の変更が行われる場合、その変更後の状態に至るまでの情報処理システムの最適な制御手順を提供することを目的とする。
【解決手段】 コンピュータが、複数の装置を含む情報処理システムの状態の変更内容を取得し、記憶装置に記憶された複数の装置の状態情報と、受信した変更内容とを用いて、変更内容による変更後の情報処理システムの状態に至るまでの遷移にて複数の装置各々がとり得る状態に基づいて状態遷移毎の情報処理システムの状態情報を生成し、記憶装置に記憶された状態遷移ルールに基づいて、生成した状態遷移毎の情報処理システムの状態情報から、変更後の情報処理システムの状態に至るまでの複数の装置の制御手順の候補を抽出し、制御手順の候補から、最も手順数が少ない制御手順を特定することにより、上記課題の解決を図る。
【選択図】図１

Description

本明細書は、制御手順方法、制御手順プログラム及び制御手順装置に関する。

顧客からのサービス要件に応じる多階層（例えば、Ｗｅｂサーバ層、アプリケーション（ＡＰＰ）サーバ層、データベース（ＤＢ）サーバ層の３階層）で形成される情報処理システムがある。ＷＥＢサーバ層やＡＰＰサーバ層は、複数の機器から形成されている。このような情報システムでは、機器の保守する場合または機器に障害が発生した場合に、機器を待機状態／運用状態と切り替え、システム全体として停止することがないようにしている。

このようなシステムの一例として、例えば、二重化装置において、通常運用を停止することなく、運用系のモジュールと、待機系のモジュールとを、自動的にアップデートするシステムがある（例えば、特許文献１）。

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

このような多階層の情報処理システムにおいて、ある階層の機能（アプリケーションプログラム）の更新処理をする場合、システムの無停止を考慮しながら機能の更新を行うことが可能である。

ところが、機能の更新が他の階層の機能に影響を及ぼす場合があり、さらに影響を受ける機能の更新順序も考慮する必要がある。例えば、情報処理システムの構成が固定であれば、予め更新手順を作成しておくことが可能である。

しかしながら、システム構成も利用状況に応じて変動するため、固定された更新手順では意味がなく、ある機能の更新処理を行うときの、現在の様々な状況から機能の更新手順を作成する必要がある。ところが、機能の特徴や機能ごとの関連などの把握は困難であるため、動的に更新手順を生成することができない。

本発明は、一側面として、情報処理システムの状態の変更が行われる場合、その変更後の状態に至るまでの情報処理システムの最適な制御手順を提供することを目的とする。

本発明の一側面に係る制御手順生成方法において、コンピュータは、次の処理を行う。すなわち、コンピュータは、複数の装置を含む情報処理システムの状態の変更内容を取得する。コンピュータは、記憶装置に記憶された複数の装置の状態情報と、受信した変更内容とを用いて、変更内容による変更後の情報処理システムの状態に至るまでの遷移にて複数の装置各々がとり得る状態に基づいて、状態遷移毎の情報処理システムの状態情報を生成する。コンピュータは、記憶装置に記憶された状態遷移ルールに基づいて、生成した状態遷移毎の情報処理システムの状態情報から、変更後の情報処理システムの状態に至るまでの複数の装置の制御手順の候補を抽出する。コンピュータは、制御手順の候補から、最も手順数が少ない制御手順を特定する。

本発明の一側面によれば、情報処理システムの状態の変更が行われる場合、その変更後の状態に至るまでの情報処理システムの最適な制御手順を提供することができる。

本実施形態における制御手順生成装置の一例を示す。 本実施形態における手順生成装置と手順生成の対象となるシステムとの例を示す。 本実施形態における新旧アプリケーションのバージョンとＤＢスキーマのバージョンとの組み合わせによる動作例について説明するための図である。 本実施形態における初期状態情報と終了状態情報の一例を示す。 本実施形態における状態遷移グラフと遷移ルールを利用した無停止手順生成処理フローを示す。 本実施形態におけるシステム状態テーブルの一例を示す。 本実施形態における遷移ルール適用前の状態遷移グラフの一例を示す。 本実施形態における遷移ルールの一例を示す。 図７の状態遷移グラフに遷移ルールを適用した場合の状態遷移グラフを示す。 本実施形態における遷移ルールを適用した状態遷移グラフから、初期状態から終了状態への最短遷移ルートを探索し、各遷移を手順と対応づけることを説明するための図である。 本実施形態における遷移ルール１「バージョンダウンを禁止する」を、「バージョンアップを禁止する」に置き換えた場合の手順の生成を説明するための図である。 本実施形態の実施例１におけるクラウドシステムとユーザ端末を示す。 本実施形態の実施例１におけるクラウド管理機構で管理される情報及びユーザ端末より送信される情報の一例を示す。 本実施形態の実施例１におけるシステム状態テーブルの一例を示す。 本実施形態の実施例１における遷移ルール適用前後の状態遷移グラフの一例を示す。 本実施形態の実施例１における遷移リストの一例を示す。 本実施形態の実施例１における手順リストの一例を示す。 本実施形態の実施例１における状態遷移グラフ生成処理のフローチャート（その１）を示す。 本実施形態の実施例１における状態遷移グラフ生成処理のフローチャート（その２）を示す。 本実施形態の実施例１における、遷移ルール適用前状態遷移グラフに含まれる各状態遷移が遷移ルール１を満たすかを判定する処理（Ｓ１４−６）のフローチャートを示す。 本実施形態の実施例１における、遷移ルール適用前状態遷移グラフに含まれる各状態遷移が遷移ルール２を満たすかを判定する処理（Ｓ１４−６）のフローチャートを示す。 本実施形態の実施例１における、遷移ルール適用前状態遷移グラフに含まれる各状態遷移が遷移ルール３を満たすかを判定する処理（Ｓ１４−６）のフローチャートを示す。 本実施形態の実施例１におけるグラフ経路探索処理（Ｓ１５）の詳細なフローチャートを示す。 本実施形態の実施例１における各遷移と手順との対応付け処理（Ｓ１６）の詳細なフローチャートを示す。 本実施形態の実施例２における対象システムの初期状態と終了状態の説明図である。 本実施形態の実施例２における状態遷移グラフを示す。 本実施形態の実施例３における対象システムの初期状態と終了状態の説明図である。 本実施形態の実施例３における状態遷移グラフを示す。 本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

情報処理システムでは、ロードバランサ（ＬＢ）等の切り替え装置を用いて、待機系と運用系を組み合わせる場合が多い。待機系と運用系の切替を行う場合の一例としては、次の場合が想定される。

例えば、１台のロードバランサと、２台のＡＰＰサーバと、１台のＤＢサーバを含む情報処理システムがあるとする。ここで、２台のＡＰＰサーバの一方は、待機系として用いられ、他方は運用系として用いられるとする。この情報処理システムに新バージョンのプログラムを導入する場合、まず、待機系のＡＰＰサーバで動作するアプリケーションプログラム（以下、「アプリケーション」と称する）が、バージョン２に更新される。次に、ロードバランサの設定が変更され、待機系と運用系が切り替えられる。そして、ＤＢスキーマが、バージョン２に更新される。

このようにして、システム全体として停止することがない無停止システムが実現されている。

このような情報処理システムに関して、昨今、顧客のサービス要件に応じてシステム構成を変えることが頻繁に行われている。

ところが、システムの一部の更新が、他の部分の動作に影響を及ぼすため、更新手順（コマンド列もしくは自然言語で記述された作業の列）の決定が難しい。例えばＡＰＰサーバ等のシステムの構成要素が複数存在するシステムにおいて、それらの構成要素を更新する場合、どのサーバから更新していくか、という順序が、サービスの停止／無停止に影響を与える。

例えば、運用系のアプリケーションを更新してしまうと、ユーザに応答を返すことが出来ない時間が発生する。また、そのアプリケーションによる計算途中のデータが失われてしまう。そのような事態を避けるには、先にロードバランサの設定を変更し、待機系と運用系とを切り替える作業が行われる。

また、例えば、アプリケーションを更新せずにＤＢスキーマを更新してしまうと、データアクセス時にデータ形式の不整合が発生するため、情報処理システムが正常動作しない可能性もある。

また、更新手順は、システム構成ごとに異なるため、システム構成の変更に合わせて更新手順決定（および検証）を行う必要がある。これは、更新手順において、満たすべき順序関係があったり、また、サーバの種類（ロードバランサ、Ｗｅｂサーバ、ＡＰＰサーバ、ＤＢサーバ）によって、現状の確認方法・サーバの更新方法が異なったりするためである。

そこで、本実施形態では、動的に変更されるシステム構成を有する情報処理システムの、マイグレーション時に行う操作手順を決定する手順生成技術について説明する。

図１は、本実施形態における制御手順生成装置の一例を示す。制御手順生成装置１は、取得部２、記憶部３、生成部４、抽出部５、特定部６を含む。

取得部２は、複数の装置を含む情報処理システムの状態の変更内容を取得する。取得部２の一例として、後述する終了状態情報３４の読み込み（図１２のＳ１４）を行うＣＰＵ４２が挙げられる。

記憶部３は、複数の装置の状態情報と、状態遷移ルールとを記憶する。記憶部３の一例として、後述する記憶装置４７が挙げられる。複数の装置の状態情報の一例として、後述する初期状態情報３３が挙げられる。状態遷移ルールの一例として、後述する遷移ルール１４が挙げられる。

生成部４は、複数の装置の状態情報と、受信した変更内容とを用いて、変更内容による変更後の情報処理システムの状態に至るまでの遷移にて複数の装置各々がとり得る状態に基づいて、状態遷移毎の情報処理システムの状態情報を生成する。生成部４の一例として、後述するＳ１４−４の処理（図１８Ａ）を行うＣＰＵ４２が挙げられる。

抽出部５は、状態遷移ルールに基づいて、生成した状態遷移毎の情報処理システムの状態情報から、変更後の情報処理システムの状態に至るまでの複数の装置の制御手順の候補を抽出する。抽出部５の一例として、後述するＳ１４−６の処理（図１８Ｂ）を行うＣＰＵ４２が挙げられる。

特定部６は、制御手順の候補から、最も手順数が少ない制御手順を特定する。特定部６の一例として、後述するＳ１５の処理（図１２）を行うＣＰＵ４２が挙げられる。

このように構成することにより、情報処理システムの状態の変更が行われる場合、その変更後の状態に至るまでの情報処理システムの最適な制御手順を提供することができる。

生成部４は、情報処理システムの状態情報から２つの状態情報を取得して状態情報に含まれる、対応する属性同士の値を比較する。生成部４は、比較の結果、異なる属性の値が１つである状態情報同士を遷移前後の状態情報として関係付ける。

このように構成することにより、情報処理システムのとり得る全状態情報のうち隣接関係にある状態情報を相互に関係付けることができる。

遷移ルールは、次の３つを含む。１つ目の遷移ルールは、関係付けた２つの状態情報間の遷移のうちプログラムのバージョンダウンをする遷移の禁止である。２つ目の遷移ルールは、関係付けた２つの状態情報間の遷移のうち状態が変更された装置が運用中である場合の遷移の禁止である。３つ目の遷移ルールは、関係付けた２つの状態情報間の遷移のうち状態の変更が複数の機器間で動作確認がとれていないプログラムのバージョンの組み合わせである場合の遷移の禁止である。

このように構成することにより、２つの状態間の状態遷移に対して、無停止でシステムのマイグレーションを行う条件を形式化した遷移ルールを用いることにより、制御手順の候補を選択することができる。

制御手順生成装置１は、さらに、出力部７を含む。出力部７は、記憶装置に記憶された、状態が変更された場合の複数の装置のそれぞれの制御内容を用いて、特定した制御手順に含まれる各手順に、手順に対応する該装置の制御内容を対応させた制御手順情報を出力する。出力部７の一例として、後述するＳ１６の処理（図１２）を行うＣＰＵ４２が挙げられる。

このように構成することにより、情報処理システムの変更に応じて、具体的な制御手順をユーザに提供することができる。

図２は、本実施形態における手順生成装置と手順生成の対象となるシステムとの例を示す。対象システム１１は、ＬＢ等の切替装置により運用系のサーバと待機系のサーバとが切り替えられる情報処理システムである。図２には、対象システム例として、システム構成Ａ，Ｂ，Ｃを示す。なお、図２において、太枠は、運用系を示す。

例えば、システム構成Ａでは、１台のＬＢが２台のＡＰＰサーバ（ＡＰＰ０１、ＡＰＰ０２）と接続されている。そして、ＡＰＰ０１が運用系として有効になるようにＬＢが切り替えられている。一方、ＡＰＰ０２は、待機系となっている。

例えば、システム構成Ｂでは、１台のロードバランＬＢが２台のＡＰＰサーバ（ＡＰＰ０１、ＡＰＰ０２）と接続されている。２台のＡＰＰサーバ（ＡＰＰ０１、ＡＰＰ０２）は、ＤＢサーバと接続されている。そして、ＡＰＰ０１、ＤＢサーバが運用系として有効になるようにＬＢが切り替えられている。一方、ＡＰＰ０２は、待機系となっている。

また、例えば、ＬＢで区切られた多層型システム（例：ＷＥＢ−ＡＰＰ−ＤＢの３層）で、ＷＥＢサーバ、ＡＰＰサーバは２台以上としてもよい。この場合、各層のＷＥＢサーバ、ＡＰＰサーバは負荷分散のために３台以上に数が増えても良い。例えば、システム構成Ｃでは、１台のロードバランＬＢが２台のＷＥＢサーバ（ＷＥＢ０１、ＷＥＢ０２）と接続されている。２台のＷＥＢサーバはそれぞれ、ＡＰＰサーバ（ＡＰＰ０１、ＡＰＰ０２）と接続されている。２台のＡＰＰサーバ（ＡＰＰ０１、ＡＰＰ０２）は、ＤＢサーバと接続されている。そして、ＷＥＢ０１、ＡＰＰ０１、ＤＢサーバが運用系として有効になるようにＬＢが切り替えられている。一方、ＷＥＢ０２、ＡＰＰ０２は、待機系となっている。

本実施形態では、対象システムを構成する各サーバのプログラムのバージョンやＤＢスキーマのバージョン、ＬＢによる切替先等、各機器に設定される項目を「属性」という。また、各機器に設定される項目において、設定される値またはとり得る値を「属性値」という。

手順生成装置１２は、無停止システムのマイグレーションの際の機器に関する作業を生成する。手順生成装置１２は、対象システム１１を構成する全機器の属性値の組を、システムの状態として取り扱う。また、機器に対する作業は、対象システムをある状態から別の状態に変化（遷移）させると考える。ここでは、マイグレーション前の初期状態と、マイグレーション後の終了状態が与えられる。具体的には、手順生成装置１２は、対象システム１０から、マイグレーション前の現在設定されている各機器の属性値を初期状態情報１５として取得する。また、手順生成装置１２は、ユーザより入力されたマイグレーション後の各機器の属性値を終了状態情報１６として取得する。

ここで、マイグレーションとは、コンピュータに導入されたオペレーティングシステム（ＯＳ）やアプリケーションなどのプログラムを、古いバージョンから新しいバージョンに入れ替えることをいう。

手順生成装置１２は、初期状態情報１５と終了状態情報１６とを用いて、その初期状態から終了状態までに、対象システムが取り得る全状態をシステム状態テーブル１３として生成する。手順生成装置１２は、遷移ルール１４を用いて、システム状態テーブル１３からその初期状態と終了状態との間をつなぐ最適な状態遷移を決定し、その状態遷移に必要なシステム中の機器に関する作業を順に出力する。これにより、マイグレーション中に実行する手順の決定が可能になる。

ここで、サーバに関する作業とは、例えばアプリケーションをダウンロードし、指定の場所に配置、設定、起動、動作確認を行う各操作を指す。また、手順とは、上記作業を特定の順に並べたものを指す。

遷移ルールについて説明する。マイグレーションの際にシステムが無停止であるためには、サーバに関する作業を並べることに加えて、無停止であることを担保するチェックの仕組みが必要である。そのために、本実施形態では、２つの状態間の状態遷移に対して、無停止システムのマイグレーション条件を形式化した遷移ルール（後述）１４が定義される。

手順生成装置１２は、遷移ルール１４を用いて、遷移前と遷移後との状態のうち特定の属性値を比較し、遷移ルール１４を満たさない設定値（属性値）の組み合わせを禁止遷移と判定する。

本実施形態では、手順生成装置１２は、例えば、各機器の以下の設定値（i）〜（iii）の組み合わせを、システム状態情報として管理する。
（i）ＬＢ：振分先サーバ
（ii）ＷＥＢサーバ、ＡＰＰサーバ：サーバ内のアプリケーションのバージョン
（iii）ＤＢサーバ：ＤＢスキーマのバージョン

さらに、無停止システムのマイグレーション条件を形式化した、以下の３つの満たすべき制約が、遷移ルール１４として設定されている。

（制約１） アプリケーション及びＤＢスキーマのバージョンダウンを禁止する（マイグレーションが行われると、バージョンを示す数値は大きくなる。）。例えば、手順生成装置１２は、状態遷移前後で設定値（ii）（iii）のそれぞれの値を比較し、遷移後の設定値が小さい場合には禁止遷移と判定する。

（制約２）運用系のサーバは更新しない。すなわち、状態遷移の前後で、アプリケーションのバージョン（ii）が変わっている場合、そのアプリケーションがインストールされたサーバが運用中であれば、遷移を禁止する。ここで、そのサーバの前段のＬＢの設定値を確認することにより、そのサーバが運用中であるか否かを判定することができる。例えば、クラウド管理機構が全サーバ間の接続関係を保持しているため、その情報を問い合わせることで、当該サーバの前段のＬＢを特定できる。

（制約３）遷移後の状態が、ＡＰＰサーバのＡＰＰプログラムのバージョン（（ii））とＤＢサーバのスキーマのバージョン（（iii））とが対応している状態であること。

例えば、旧版のＡＰＰプログラムと新版ＤＢスキーマの組み合わせでは、ＡＰＰプログラムが誤ったデータ形式でＤＢにアクセスするため、異常動作となる。そのため、運用系ＡＰＰサーバのアプリケーションのバージョン（（ii））と、ＤＢスキーマのバージョン（（iii））とが対応していない場合には遷移を禁止する。これについて、図３を用いて説明する。

図３は、本実施形態における新旧アプリケーションのバージョンとＤＢスキーマのバージョンとの組み合わせによる動作例について説明するための図である。「旧版アプリケーションと旧版ＤＢスキーマ」の組み合わせ、「新版アプリケーションと旧版ＤＢスキーマ」の組み合わせ、及び「新版アプリケーションと新版ＤＢスキーマ」の組み合わせでは、対象システムは正常動作する。

一方で、「旧版アプリケーションと新版ＤＢスキーマ」の組み合わせでは、アプリケーションが正常動作しない可能性がある。例えば、ＤＢスキーマの変更としてテーブルのカラム名を変更する場合、アプリケーションｖ１は変更前のカラム名でＤＢアクセスしてしまうと、正常動作することができない。

したがって、上述した制約３では、運用系ＡＰＰサーバのアプリケーションのバージョン（（ii））と、ＤＢスキーマのバージョン（（iii））とが対応していない場合には、遷移を禁止する。

図４は、本実施形態における初期状態情報と終了状態情報の一例を示す。初期状態情報１５は、マイグレーション前の各機器の状態情報を示す。終了状態情報１６は、マイグレーション後の各サーバの状態情報の一例を示す。

図４の場合、ＬＢの属性値は、「ＡＰＰ０１」、「ＡＰＰ０２」である。ＡＰＰサーバの属性値は、「ｖ１」、「ｖ２」である。ここで、Ｖ１は、マイグレーション前のアプリケーションまたはＤＢスキーマのバージョンを示す。Ｖ２は、マイグレーション後のアプリケーションまたはＤＢスキーマのバージョンを示す。

図５は、本実施形態における状態遷移グラフと遷移ルールを利用した無停止手順生成処理フローを示す。以下では、図５〜図１１のそれぞれの図を用いて、図４を説明する。なお、本実施形態では、説明の便宜上、対象システム１１として、図２のシステム構成Ａを例に用いて説明する。

手順生成装置１２は、初期状態情報１５及び終了状態情報１６に基づいて、マイグレーションの初期から終了までに取り得る対象システムの全状態（（i）（ii）（iii）の組み合わせ）を計算し、システム状態テーブル１３を生成する（Ｓ１）。これについては、図６を用いて説明する。

図６は、本実施形態におけるシステム状態テーブルの一例を示す。本実施形態では、対象システム１１を形成する全機器の属性値の組み合わせを、システムの状態をみなす。システム状態テーブル１３は、「状態」、「属性値」の項目を含む。

項目「状態Ｎｏ．」は、対象システム１１の各状態を一意に識別するために付与される情報である。「属性値」は、マイグレーションの過程において、各機器が取り得る項目の状態を示す。図４の場合には、「属性値」として、「ＬＢの振り分け先」（ＬＢの属性値）、「ＡＰＰサーバ０１のバージョンＮｏ．」（ＡＰＰサーバ０１の属性値）、「ＡＰＰサーバ０２のバージョンＮｏ．」（ＡＰＰサーバ０２の属性値）がある。

ＬＢの属性値としては、「ＡＰＰ０１」、「ＡＰＰ０２」の２つがある。ＡＰＰ０１の属性値としては、「ｖ１」、「ｖ２」の２つがある。ＡＰＰ０２の属性値としては、「ｖ１」、「ｖ２」の２つがある。したがって、ＬＢ，ＡＰＰ０１、ＡＰＰ０２の属性値の組み合わせは、２×２×２＝８種類存在する。図６では、この８種類の組み合わせにより示される状態に、０〜７の一意の番号が付与されている。ここで、状態“０”には、初期状態（マイグレーション前）の属性値の組み合わせが該当する。状態“７”には、終了状態（マイグレーション後）の属性値の組み合わせが該当する。図５の説明に戻る。

次に、手順生成装置１２は、システム状態テーブル１３に登録された状態から順次２つの状態を取り出し、２つの状態を比較する。比較結果に基づいて、手順生成装置１２は、システム状態を形成する属性値のうち、属性値の違いが１箇所である隣接関係を抽出し、（遷移ルール適用前の）状態遷移グラフを生成する（Ｓ２）。これについて、図７を用いて説明する。

図７は、本実施形態における遷移ルール適用前の状態遷移グラフの一例を示す。例えば、手順生成装置１２は、システム状態テーブル１３から、状態０と状態１とを取得し、状態０の属性値と、状態１の属性値とを比較する。状態０の属性値と、状態１の属性値とは、ＡＰＰサーバ０２の属性値（「ＡＰＰサーバ０２のバージョン」）が異なるだけであるので、属性値の違いが１箇所である隣接関係に該当する。そこで、図７に示すように、手順生成装置１２は、状態０と状態１との間を双方向の矢印で関係付ける。ここで関係付けた矢印は、一方の状態から他方の状態への遷移を示す。

手順生成装置１２は、システム状態テーブル１３から、状態０と状態２とを取得し、状態０の属性値と、状態２の属性値とを比較する。状態０の属性値と、状態２の属性値とは、ＡＰＰサーバ０１の属性値（「ＡＰＰサーバ０１のバージョン」）が異なるだけであるので、属性値の違いが１箇所である隣接関係に該当する。そこで、図７に示すように、手順生成装置１２は、状態０と状態２との間を双方向の矢印で関係付けて、状態間の遷移を生成する。

手順生成装置１２は、システム状態テーブル１３から、状態０と状態３とを取得し、状態０の属性値と、状態３の属性値とを比較する。状態０の属性値と、状態３の属性値とは、ＡＰＰサーバ０１の属性値（「ＡＰＰサーバ０１のバージョン」）とＡＰＰサーバ０２の属性値（「ＡＰＰサーバ０２のバージョン」）とが異なるので、属性値の違いが１箇所である隣接関係に該当しない。この場合、図７に示すように、手順生成装置１２は、状態０と状態３との間を双方向の矢印で関係付けない。

この隣接関係の判定処理を、システム状態テーブル１３に登録された状態のうち、２つの状態の全組み合わせについて行う。すると、図７の状態遷移グラフが得られる。図４の説明に戻る。

次に、手順生成装置は、図７の状態遷移グラフ内の遷移（矢印）のうち、図８に示す遷移ルール１４を満たす遷移のみ残すことで、図９で示す（遷移ルール適用後の）状態遷移グラフを形成する（Ｓ３）。

図８は、本実施形態における遷移ルールの一例を示す。遷移ルール１として、遷移前後で、ＡＰＰ層のサーバ内のアプリケーションの属性値を比較し、遷移後の属性値の値が小さい場合には、その遷移を禁止することが規定されている。ＡＰＰ層のサーバは、ＷＥＢサーバ、ＡＰＰサーバ等の、ＬＢ及びＤＢサーバ以外の機器を含む。

遷移ルール２として、遷移前後で、ＡＰＰ層のサーバの属性値が変わっている場合であって、遷移後のサーバが運用中の場合、その遷移を禁止することが規定されている。

遷移ルール３として、運用系ＡＰＰサーバの属性値と、ＤＢサーバの属性値が対応していない場合には、その遷移を禁止することが規定されている。

図９は、図７の状態遷移グラフに遷移ルールを適用した場合の状態遷移グラフを示す。手順生成装置１２は、図７の状態遷移グラフ内のそれぞれ遷移（矢印）について、遷移ルール１〜３に従って、禁止する遷移を判別し、禁止する遷移を除外する。

例えば、状態１から状態０への遷移は、ＡＰＰサーバ０２のバージョンが下がっている。この場合、手順生成装置１２は、遷移ルール１に基づいて、図７の状態遷移グラフからその遷移を削除する。

また、例えば、状態４から状態５への遷移は、遷移前後でＡＰＰサーバ０２の属性値が変わっている場合であって、遷移後のＡＰＰサーバ０２が運用中である。この場合、手順生成装置１２は、遷移ルール２に基づいて、図７の状態遷移グラフからその遷移を削除する。

このように、図７の状態遷移グラフに、図８の遷移ルール１４を適用すると、図９の状態遷移グラフが得られる。図４の説明に戻る。

次に、手順生成装置１２は、図１０に示すように、遷移ルール１４を適用した状態遷移グラフから、初期状態から終了状態への最短遷移ルートを探索し、各遷移を手順と対応づける（Ｓ４）。

図１０は、本実施形態における遷移ルールを適用した状態遷移グラフから、初期状態から終了状態への最短遷移ルートを探索し、各遷移を手順と対応づけることを説明するための図である。図６で説明したように、初期状態は、状態０であり、終了状態は、状態７である。この場合、図１０に示すように状態０から状態７への最短遷移ルートは、状態０→状態１→状態５→状態７である。

手順生成装置１２は、状態０→状態１への遷移を手順１と対応付け、状態１→状態５への遷移を手順２と対応付け、状態５→状態７への遷移を手順３と対応付ける。

本実施形態によれば、ＬＢ、ＷＥＢサーバ、ＡＰＰサーバ、ＤＢサーバを組み合わせた多重化システムにおいて、無停止条件を形式化した遷移ルールにより、無停止マイグレーション手順を自動生成することができる。

また、無停止手順が複数ある場合に、最短手順を出力することができる。例えば、図６に示すように、初期状態＝０、終了状態＝７を与え、最短経路を探索すると、図１０に示すように、状態０→状態１→状態５→状態７（３ステップ）という遷移リストを得ることができる。また、最短で無い遷移リストとして、図１０より状態０→状態４→状態６→状態２→状態３→状態７（５ステップ）もありえる。

また、遷移ルール１「バージョンダウンを禁止する」を、「バージョンアップを禁止する」に置き換えると、図１１に示すように、無停止のバージョンダウン手順の生成が可能となる。

図１１は、本実施形態における遷移ルール１「バージョンダウンを禁止する」を、「バージョンアップを禁止する」に置き換えた場合の手順の生成を説明するための図である。この場合、初期状態７→状態５→状態１→終了状態０の３ステップという手順が生成される。

次に、本実施形態の実施例について詳述する。
（実施例１）
図１２は、本実施形態の実施例１におけるクラウドシステムとユーザ端末を示す。図１２では、クラウドシステム２１と、ユーザ端末２６とが通信ネットワークで接続されている。クラウドシステム２１は、ＩＣＴ（Information and Communication Technology）リソースにより形成されている。クラウドシステム２１は、手順生成装置２２、クラウド管理機構２３、対象システム２５を含む。

対象システム２５は、例えば、ＬＢ、ＷＥＢサーバ、ＡＰＰサーバ、ＤＢサーバ等を含み、システムのマイグレーションを無停止で行う。実施例１では、説明の便宜上、図２で説明したシステム構成Ａを対象システム２５として用いる。

クラウド管理機構２３は、対象システム２５を管理する管理サーバ等を含む。クラウド管理機構２３の記憶装置２４には、機器接続情報３１、機器一覧情報３２、初期状態情報３３を格納する。

機器接続情報３１は、対象システム２５に含まれる機器間の接続関係を示す情報である。機器一覧情報３２は、対象システム２５に含まれる機器の一覧情報である。初期状態情報３３は、対象システム２５に含まれる機器（ＬＢ、ＷＥＢサーバ、ＡＰＰサーバ、ＤＢサーバ）に現在設定されている設定値（属性値）、すなわち初期状態についての情報である。

手順生成装置２２は、対象システム２５のマイグレーションをする場合、マイグレーションの手順を生成する情報処理装置である。なお、手順生成装置２２は、クラウドシステム２１の外部にあってもよい。

ユーザ端末２６は、対象システム２５のマイグレーションの操作をする場合にユーザによって操作される情報処理端末である。

クラウド管理機構２３は、対象システム２５から、対象システム２５に含まれる機器に現在設定されている設定値を取得し、初期状態情報３３として記憶装置２４に格納する（Ｓ１１）。

ユーザは、対象システム２５のマイグレーションの操作手順を作成する場合、ユーザ端末１６を用いて、必要に応じてクラウド管理機構２３の記憶装置２４に格納された機器接続情報３１、機器一覧情報３２、初期状態情報３３を参照する（Ｓ１２）。ユーザは、操作手順の作成時に必要に応じて参照した機器接続情報３１、機器一覧情報３２、初期状態情報３３を用いて、終了状態情報３４を作成する。終了状態情報３４は、マイグレーション後の対象システム２５に含まれる各機器の設定値の情報である。ユーザは、ユーザ端末２６を用いて、終了状態情報３４を含む操作手順作成要求を手順生成装置２２へ送信する（Ｓ１３）。

手順生成装置２２は、操作手順作成要求を受信すると、機器接続情報３１、機器一覧情報３２、初期状態情報３３、終了状態情報３４を用いて、状態遷移グラフ３７を作成する（Ｓ１４）。

手順生成装置２２は、状態遷移グラフ３７から、初期状態から終了状態へ遷移する最短の経路を探索し、遷移リスト３８を生成する（Ｓ１５）。

手順生成装置２２は、遷移リスト３８を用いて、各遷移と操作手順とを対応付けた手順リスト３９を作成する（Ｓ１６）。手順生成装置２２は、作成した手順リスト３９をユーザ端末２６へ応答する（Ｓ１７）。

図１３は、本実施形態の実施例１におけるクラウド管理機構で管理される情報及びユーザ端末より送信される情報の一例を示す。

図１３（Ａ）は、機器接続情報３１の一例を示す。機器接続情報３１は、機器名と、その機器名で示される機器の接続先の機器名とを関係付けて保持する情報である。

図１３（Ｂ）は、機器一覧情報３２の一例を示す。機器一覧情報３２は、機器名と、その機器名で示される機器の役割または機能とを関係付けて保持する情報である。

図１３（Ｃ）は、初期状態情報３３の一例を示す。初期状態情報３３は、マイグレーション前の対象システム２５に含まれる機器名と、その機器の属性名と、その属性名に対応する属性値とを関係付けて保持する情報である。

図１３（Ｄ）は、終了状態情報３４の一例を示す。終了状態情報３４は、マイグレーション後の対象システム２５に含まれる機器名と、その機器の属性名と、その属性名に対応する属性値とを関係付けて保持する情報である。

なお、ＬＢの属性は、振り分け先の後段のサーバ名であり、ＬＢの属性に変更がない場合には、省略してもよい。

図１４は、本実施形態の実施例１におけるシステム状態テーブルの一例を示す。システム状態テーブル３５は、マイグレーションの過程における、対象システム２５に含まれる各機器の初期状態から終了状態までの状態の属性値の組み合わせを示す。手順生成装置２２は、機器接続情報３１、機器一覧情報３２、初期状態情報３３、終了状態情報３４を用いて、システム状態テーブル３５を作成する。システム状態テーブル３５の内容は、図６と同じなので、その説明を省略する。

図１５は、本実施形態の実施例１における遷移ルール適用前後の状態遷移グラフの一例を示す。遷移ルール適用前の状態遷移グラフ３６は、システム状態テーブル３５に登録された状態から順次取り出した２つの状態を比較し、比較の結果、対応する属性の値の相違が１箇所である隣接関係が抽出されて生成された遷移情報である。状態遷移グラフ３６は、図７の状態遷移グラフに対応する。

状態遷移グラフ３７は、遷移ルール適用前の状態遷移グラフ３６から、遷移ルールで禁止されている遷移を除外した遷移情報である。状態遷移グラフ３７は、図９の状態遷移グラフに対応する。

いずれの状態遷移グラフ３６，３７も、遷移前の状態Ｎｏ．と、遷移後の状態Ｎｏ．とを対として保持している。

図１６は、本実施形態の実施例１における遷移リストの一例を示す。遷移リスト３７は、遷移する状態順に状態Ｎｏ．が登録されている。

図１７は、本実施形態の実施例１における手順リストの一例を示す。手順リスト３９には、遷移リスト３８の登録順で状態間を遷移する順で行う操作手順が出力されている。

次に、手順生成装置２２によるＳ１４〜Ｓ１７の詳細な処理について、図１８〜図２３を用いて説明する。

図１８Ａ及び図１８Ｂは、本実施形態の実施例１における状態遷移グラフ生成処理のフローチャートを示す。実施例１では、終了状態情報３４において、ＬＢの属性は、ＬＢの属性に変更がない場合には、省略可能であるとする。

機器接続情報３１、機器一覧情報３２、初期状態情報３３、終了状態情報３４を用いて、システム状態テーブル３５を作成する場合、まず始めに、手順生成装置２２は、次の処理を行う。すなわち、ＬＢの属性値が終了状態情報３４に含まれていないか否か、すなわち初期状態情報３３に比べ、終了状態情報３４の機器数が少ないか否かを判定する（Ｓ１４−１）。ＬＢの属性値が終了状態情報３４に含まれている場合（Ｓ１４−１で「ＮＯ」）、処理は、Ｓ１４−４の処理へ進む。

ＬＢの属性値が終了状態情報３４に含まれていない場合、すなわち、初期状態情報３３に比べ、終了状態情報３４の機器数が少ない場合（Ｓ１４−１で「ＹＥＳ」）、手順生成装置２２は、次の処理を行う。すなわち、手順生成装置２２は、機器一覧情報３２に基づいて、省略された機器の役割がＬＢであるか否かを判定する（Ｓ１４−２）。省略された機器の役割がＬＢでない場合（Ｓ１４−２で「ＮＯ」）、本フローは終了する。

省略された機器の役割がＬＢである場合（Ｓ１４−２で「ＹＥＳ」）、手順生成装置２２は、機器接続情報３１から、そのＬＢと接続されている全てのサーバを特定する。手順生成装置２２は、その特定されたサーバ名を、そのＬＢである機器のとり得る値として取得する（Ｓ１４−３）。

手順生成装置２２は、初期状態情報３３および終了状態情報３４に含まれる各機器の属性の取り得る値の組み合わせ（システム状態情報）を、システム状態テーブル３５に全て出力する（Ｓ１４−４）。

手順生成装置２２は、システム状態テーブル３５から、２つの状態を選び、対応する属性を比較して、異なる属性値が１項目であれば、隣接関係とみなし、遷移ルール適用前状態遷移グラフ３６に登録する（Ｓ１４−５）。Ｓ１４−５の処理は、全ての組み合わせについて行われる。

次に、手順生成装置２２は、無停止手順判定処理を行う（Ｓ１４−６）。手順生成装置２２は、遷移ルール適用前状態遷移グラフ３６に含まれる各状態遷移が遷移ルール１〜３を満たすかを判定する。ここで、遷移ルール１〜３は、図８で説明したルールと同じである。遷移ルール適用前状態遷移グラフ３６から、状態遷移が遷移ルール１〜３を満たさない状態遷移を除外する。Ｓ１４−６の処理の詳細については、図１９〜図２１を用いて説明する。

図１９は、本実施形態の実施例１における、遷移ルール適用前状態遷移グラフに含まれる各状態遷移が遷移ルール１を満たすかを判定する処理（Ｓ１４−６）のフローチャートを示す。遷移ルール１を用いた無停止手順判定処理は、遷移ルール適用前状態遷移グラフ３６の２状態間の遷移が、プログラムのバージョンダウンであればｆａｌｓｅを、それ以外であればｔｒｕｅを返す処理を行う。

まず、手順生成装置２２は、遷移ルール適用前状態遷移グラフ３６から１つのエントリ（状態遷移）を読み出す。ここで、読み出した状態遷移のうち、遷移前の状態を「ｓｔａｔｅＡ」、遷移後の状態を「ｓｔａｔｅＢ」と定義する（Ｓ１４−６−１１）。

手順生成装置２２は、機器一覧情報３２とシステム状態テーブル３５を用いて、読み出した状態遷移がどの機器の状態遷移であるかを判定する（Ｓ１４−６−１２）。読み出した状態遷移がＬＢの状態遷移である場合、手順生成装置２２は、「ｔｒｕｅ」を返す（Ｓ１４−６−１４）。

読み出した状態遷移がＷＥＢサーバ、ＡＰＰサーバ、またはＤＢサーバの状態遷移である場合、手順生成装置２２は、変更されたＷＥＢサーバ、ＡＰＰサーバ、またはＤＢサーバのバージョンを比較する。その比較結果、手順生成装置２２は、ｓｔａｔｅＢの属性値よりもｓｔａｔｅＡの属性値が大きいか否かを判定する（Ｓ１４−６−１３）。

ｓｔａｔｅＢの属性値よりもｓｔａｔｅＡの属性値が大きい場合（Ｓ１４−６−１３で「ＹＥＳ」）、手順生成装置２２は、「ｆａｌｓｅ」を返す（Ｓ１４−６−１５）。一方、ｓｔａｔｅＡの属性値がｓｔａｔｅＢの属性値以下である場合（Ｓ１４−６−１３で「ＮＯ」）、手順生成装置２２は、「ｔｒｕｅ」を返す（Ｓ１４−６−１４）。

遷移ルール適用前状態遷移グラフ３６の全エントリ分、本フローチャートの処理を繰り返す。

図２０は、本実施形態の実施例１における、遷移ルール適用前状態遷移グラフに含まれる各状態遷移が遷移ルール２を満たすかを判定する処理（Ｓ１４−６）のフローチャートを示す。遷移ルール２を用いた無停止手順判定処理は、状態間の遷移が、ＬＢが向いている先のサーバの変更であればｆａｌｓｅを返し、それ以外であればｔｒｕｅを返す処理を行う。

まず、手順生成装置２２は、遷移ルール適用前状態遷移グラフ３６から１つのエントリ（状態遷移（遷移前の状態：ｓｔａｔｅＡ、遷移後の状態：ｓｔａｔｅＢ））を読み出す。（Ｓ１４−６−１１）。

手順生成装置２２は、機器接続情報３１、機器一覧情報３２、システム状態テーブル３５を用いて、読み出した状態遷移がどの機器の状態遷移であるかを判定する（Ｓ１４−６−２２）。読み出した状態遷移がＬＢの状態遷移である場合、手順生成装置２２は、「ｔｒｕｅ」を返す（Ｓ１４−６−２４）。

読み出した状態遷移がＷＥＢサーバまたはＡＰＰサーバの状態遷移である場合、手順生成装置２２は、ＬＢの振向先機器が、遷移前後で状態に変更のある機器に該当するか否かを判定する（Ｓ１４−６−２３）。

ＬＢの振向先機器が、遷移前後で状態に変更のある機器に該当する場合（Ｓ１４−６−２３で「ＹＥＳ」）、手順生成装置２２は、「ｆａｌｓｅ」を返す（Ｓ１４−６−２５）。一方、遷移前後で状態に変更のある機器に該当しない場合（Ｓ１４−６−２３で「ＮＯ」）、手順生成装置２２は、「ｔｒｕｅ」を返す（Ｓ１４−６−２４）。

遷移ルール適用前状態遷移グラフ３６の全エントリ分、本フローチャートの処理を繰り返す。

図２１は、本実施形態の実施例１における、遷移ルール適用前状態遷移グラフに含まれる各状態遷移が遷移ルール３を満たすかを判定する処理（Ｓ１４−６）のフローチャートを示す。遷移ルール３を用いた無停止手順判定処理は、遷移後のＬＢの振向先のアプリケーションのバージョンとＤＢスキーマのバージョンとが、「旧版ＡＰＰ」と「新版ＤＢ」の組み合わせであれば「ｆａｌｓｅ」を返し、それ以外であれば「ｔｒｕｅ」を返す。

まず、手順生成装置２２は、遷移ルール適用前状態遷移グラフ３６から１つのエントリ（状態遷移（遷移前の状態：ｓｔａｔｅＡ、遷移後の状態：ｓｔａｔｅＢ））を読み出す。（Ｓ１４−６−３１）。

手順生成装置２２は、機器接続情報３１、機器一覧情報３２、システム状態テーブル３５を用いて、読み出した状態遷移がどの機器の状態遷移であるかを判定する（Ｓ１４−６−３２）。読み出した状態遷移がＬＢ及びＤＢサーバ以外の機器の状態遷移である場合、手順生成装置２２は、「ｔｒｕｅ」を返す（Ｓ１４−６−３４）。

読み出した状態遷移がＬＢまたはＤＢサーバの状態遷移である場合、手順生成装置２２は、次の処理を行う。すなわち、手順生成装置２２は、初期状態情報３３及び終了状態情報３４に基づいて、遷移後のＬＢの振向先の機器のアプリケーションのバージョンが初期状態の版で、かつ、ＤＢスキーマのバージョンが終了状態の版であるか否かを判定する（Ｓ１４−６−３３）。

遷移後のＬＢの振向先の機器のアプリケーションのバージョンが初期状態の版で、かつ、ＤＢスキーマのバージョンが終了状態の版である場合（Ｓ１４−６−３３で「ＹＥＳ」）、手順生成装置２２は、「ｆａｌｓｅ」を返す（Ｓ１４−６−３５）。一方、遷移後のＬＢの振向先の機器のアプリケーションのバージョンが初期状態の版でなく、または、ＤＢスキーマのバージョンが終了状態の版でない場合（Ｓ１４−６−３３で「ＮＯ」）、手順生成装置２２は、「ｔｒｕｅ」を返す（Ｓ１４−６−３４）。

遷移ルール適用前状態遷移グラフ３６の全エントリ分、本フローチャートの処理を繰り返す。

図２２は、本実施形態の実施例１におけるグラフ経路探索処理（Ｓ１５）の詳細なフローチャートを示す。手順生成装置２２は、初期状態情報３３、終了状態情報３４、システム状態テーブル３５、状態遷移グラフ３７を用いて、状態遷移グラフ３７から、初期状態から終了状態に至る最短経路を探索する（Ｓ１５−１）。最短経路の探索処理には、例えば、ダイクストラ法等のアルゴリズムを用いても良い。

最短経路が探索された場合（Ｓ１５−２で「ＹＥＳ」）、手順生成装置２２は、その探索された経路を遷移リスト３８として出力する（Ｓ１５−３）。最短経路が探索されなかった場合（Ｓ１５−２で「ＮＯ」）、例外処理が発生する（Ｓ１５−４）。

図２３は、本実施形態の実施例１における各遷移と手順との対応付け処理（Ｓ１６）の詳細なフローチャートを示す。図２３のフローでは、手順生成装置２２は、遷移リスト３８のそれぞれの遷移を、以下の手順に対応付ける。すなわち、ＬＢの設定値が変わる遷移は、ＬＢの振分先を、指定のサーバに変更する手順に対応付ける。ＷＥＢ／ＡＰＰ／ＤＢの設定値が変わる遷移は、アプリケーションまたはＤＢスキーマを、指定の属性値（アプリケーションまたはＤＢスキーマのバージョン）にする手順に対応付ける。

まず、手順生成装置２２は、手順リスト３９を初期化する（Ｓ１６−１）。手順生成装置２２は、遷移リスト３８を読み出す（Ｓ１６−２）。

手順生成装置２２は、遷移リスト３８から１ステップの遷移前後の２状態を読み出す。手順生成装置２２は、システム状態テーブル３５から、その読み出した２状態の変更箇所の、機器名、属性名及び属性値を取得する（Ｓ１６−３）。

手順生成装置２２は、機器一覧情報３２に基づいて、Ｓ１６−３で取得した機器の役割を判定する（Ｓ１６−４）。

機器の役割が「ＬＢ」である場合、手順生成装置２２は、手順リスト３９に、「ＬＢの向きを、遷移先状態のＬＢの値に切り替える」という手順を追加する（Ｓ１６−５）。

機器の役割が「ＷＥＢサーバ」または「ＡＰＰサーバ」である場合、手順生成装置２２は、手順リスト３９に、「変更のあるサーバに、遷移先状態のバージョンを配備する」という手順を追加する（Ｓ１６−６）。

機器の役割が「ＤＢサーバ」である場合、手順生成装置２２は、手順リスト３９に、「変更のあるＤＢサーバに、遷移先状態のスキーマのバージョンを配備する」という手順を追加する（Ｓ１６−７）。

機器の役割が「ＬＢ」「ＷＥＢサーバ」「ＡＰＰサーバ」及び「ＤＢサーバ」のいずれにも該当しない場合、例外処理が発生する（Ｓ１６−８）。

手順生成装置２２は、Ｓ１６−３〜Ｓ１６−８の処理を、遷移リスト３８の状態遷移の全ステップ分繰り返し、手順リスト３９を出力する。

（実施例２）
実施例２は、対象システムとして、図２のシステム構成Ｂを用いた場合の実施例である。

図２４は、本実施形態の実施例２における対象システムの初期状態と終了状態の説明図である。初期状態では、運用系は、ＡＰＰ０１サーバ（アプリケーションのバージョン：ｖ１）、ＤＢサーバ（スキーマのバージョン：ｖ１）である。待機系は、ＡＰＰ０２サーバ（アプリケーションのバージョン：ｖ１）である。

終了状態では、運用系は、ＡＰＰ０２サーバ（アプリケーションのバージョン：ｖ２）、ＤＢサーバ（スキーマのバージョン：ｖ２）である。待機系は、ＡＰＰ０１サーバ（アプリケーションのバージョン：ｖ１）である。

図２５は、本実施形態の実施例２における状態遷移グラフを示す。図２５内のそれぞれの楕円は、図２４のシステム状態情報を示す。システム状態情報は、４桁のビットで表示される。４桁のビットについて左から、ＬＢの状態、ＡＰＰ０１の状態、ＡＰＰ０２の状態、ＤＢの状態を示す。「０」は、その機器の状態について変更がないことを示す。「１」は、その機器の状態について変更があることを示す。

システム構成が図２４の場合、遷移ルール１〜３から、図２５の状態遷移グラフと、初期状態から終了状態までの最短経路である３ホップの状態遷移経路と、無停止マイグレーション手順とが得られる。３ホップの状態遷移経路とは、「００００」→「００１０」→「１０１０」→「１０１１」の経路である。

（実施例３）
実施例３は、対象システムとして、図２のシステム構成Ｃを用いた場合の実施例である。

図２６は、本実施形態の実施例３における対象システムの初期状態と終了状態の説明図である。初期状態では、運用系は、ＷＥＢ０１サーバ（アプリケーションのバージョン：ｖ１）、ＡＰＰ０１サーバ（アプリケーションのバージョン：ｖ１）、ＤＢサーバ（スキーマのバージョン：ｖ１）である。待機系は、ＷＥＢ０２サーバ（アプリケーションのバージョン：ｖ１）、ＡＰＰ０２サーバ（アプリケーションのバージョン：ｖ１）である。

終了状態では、運用系は、ＷＥＢ０２サーバ（アプリケーションのバージョン：ｖ２）、ＡＰＰ０２サーバ（アプリケーションのバージョン：ｖ２）、ＤＢサーバ（スキーマのバージョン：ｖ２）である。待機系は、ＷＥＢ０１サーバ（アプリケーションのバージョン：ｖ１）、ＡＰＰ０１サーバ（アプリケーションのバージョン：ｖ１）である。

図２７は、本実施形態の実施例３における状態遷移グラフを示す。図２７内のそれぞれの楕円は、図２６のシステム状態情報を示す。システム状態情報は、６桁のビットで表示される。６桁のビットについて左から、ＬＢの状態、ＷＥＢ０１の状態、ＡＰＰ０１の状態、ＷＥＢ０２の状態、ＡＰＰ０２の状態、ＤＢの状態を示す。「０」は、その機器の状態について変更がないことを示す。「１」は、その機器の状態について変更があることを示す。

システム構成が図２６の場合、遷移ルール１〜３から、図２５の状態遷移グラフと、初期状態から終了状態までの最短経路である４ホップの状態遷移経路と、無停止マイグレーション手順とが得られる。４ホップの状態遷移経路とは、「００００００」→「００００１０」→「０００１１０」→「１００１１０」→「１００１１１」または「００００００」→「０００１００」→「０００１１０」→「１００１１０」→「１００１１１」の経路である。このように、ホップ数が同数の状態遷移が複数ある場合がある。実施例３では、先に終了状態に達した状態遷移（に対応する手順）を返すが、どちらを経路も遷移ルールを満たすため、どちらを選んでも問題ない。この例では、ＷＥＢ→ＡＰＰの順か、ＡＰＰ→ＷＥＢの順が異なるだけでなる。

図２８は、本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ４０は、手順生成装置２２として機能する。コンピュータ４０は、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４６、通信Ｉ／Ｆ４４、記憶装置４７、出力Ｉ／Ｆ４１、入力Ｉ／Ｆ４５、読み取り装置４８、バス４９、出力機器５１、入力機器５２によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス４９には、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４６、通信Ｉ／Ｆ４４、記憶装置４７、出力Ｉ／Ｆ４１、入力Ｉ／Ｆ４５、及び読み取り装置４８が接続されている。読み取り装置４８は、可搬型記録媒体を読み出す装置である。出力機器５１は、出力Ｉ／Ｆ４１に接続されている。入力機器５２は、入力Ｉ／Ｆ４５に接続にされている。

記憶装置４７としては、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。記憶装置４７またはＲＯＭ４３には、ＣＰＵ４２を取得部２、記憶部３、生成部４、抽出部５、特定部６、出力部７として機能させる本実施形態に係るプログラムが格納されている。また、記憶装置４７は、機器接続情報３１、機器一覧情報３２、初期状態情報３３、終了状態情報３４、システム状態テーブル３５、状態遷移グラフ３６，３７、遷移リスト３８、手順リスト３９、遷移ルール１〜３（１４）等を格納する。ＲＡＭ４６には、情報が一時的に記憶される。

ＣＰＵ４２は、制御部２２として、記憶装置４７またはＲＯＭ４３から本実施形態に係るプログラムを読み出し、当該プログラムを実行する。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク５０、および通信Ｉ／Ｆ４４を介して、例えば記憶装置４７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置４８にセットされて、ＣＰＵ４２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置４８によって読み取られる。

また、入力機器５２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレットなどを用いることが可能である。また、出力機器５１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。また、ネットワーク５０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 制御手順生成装置
２ 取得部
３ 記憶部
４ 生成部
５ 抽出部
６ 特定部
７ 出力部
１１ 対象システム
１２ 手順生成装置
１３ システム状態テーブル
１４ 遷移ルール
１５ 初期状態情報
１６ 終了状態情報
２１ クラウドシステム
２２ 手順生成装置
２３ クラウド管理機構
２４ 記憶部
２５ 対象システム
２６ ユーザ端末
３１ 機器接続情報
３２ 機器一覧情報
３３ 初期状態情報
３４ 終了状態情報
３５ システム状態テーブル
３６ 遷移ルール適用前状態遷移グラフ
３７ 状態遷移グラフ
３８ 遷移リスト
３９ 手順リスト

Claims (6)

1. コンピュータが、
   複数の装置を含む情報処理システムの状態の変更内容を取得し、
   記憶装置に記憶された前記複数の装置の状態情報と、受信した前記変更内容とを用いて、該変更内容による変更後の情報処理システムの状態に至るまでの遷移にて前記複数の装置各々がとり得る状態に基づいて状態遷移毎の該情報処理システムの状態情報を生成し、
   前記記憶装置に記憶された状態遷移ルールに基づいて、生成した前記状態遷移毎の情報処理システムの状態情報ら、前記変更後の情報処理システムの状態に至るまでの前記複数の装置の制御手順の候補を抽出し、
   前記制御手順の候補から、最も手順数が少ない制御手順を特定する
   ことを特徴とする制御手順生成方法。
2. 前記状態情報の生成において、
   前記情報処理システムの状態情報から２つの状態情報を取得して該状態情報に含まれる、対応する属性同士の値を比較し、比較の結果、異なる属性の値が１つである該状態情報同士を遷移前後の状態情報として関係付ける
   ことを特徴とする請求項１に記載の制御手順生成方法。
3. 前記遷移ルールは、関係付けた２つの状態情報間の遷移のうちプログラムのバージョンダウンをする遷移の禁止、前記関係付けた２つの状態情報間の遷移のうち前記状態が変更された装置が運用中である場合の該遷移の禁止、前記関係付けた２つの状態情報間の遷移のうち前記状態の変更が前記複数の機器間で動作確認がとれていないプログラムのバージョンの組み合わせである場合の該遷移の禁止を含む
   ことを特徴とする請求項２に記載の制御手順生成方法。
4. 前記制御手順算出方法は、さらに、
   前記記憶装置に記憶された、状態が変更された場合の前記複数の装置のそれぞれの制御内容を用いて、特定した前記制御手順に含まれる各手順に、該手順に対応する該装置の制御内容を対応させた制御手順情報を出力する
   ことを特徴とする請求項１〜３のうちいずれか１項に記載の制御手順生成方法。
5. コンピュータに、
   複数の装置を含む情報処理システムの状態の変更内容を取得し、
   記憶装置に記憶された前記複数の装置の状態情報と、受信した前記変更内容とを用いて、該変更内容による変更後の情報処理システムの状態に至るまでの遷移にて該複数の装置各々がとり得る状態に基づいて状態遷移毎の該情報処理システムの状態情報を生成し、
   前記記憶装置に記憶された状態遷移ルールに基づいて、生成した前記状態遷移毎の情報処理システムの状態情報から、前記変更後の情報処理システムの状態に至るまでの前記複数の装置の制御手順の候補を抽出し、
   前記制御手順の候補から、最も手順数が少ない制御手順を特定する
   処理を実行させる制御手順生成プログラム。
6. 複数の装置を含む情報処理システムの状態の変更内容を取得する取得部と、
   前記複数の装置の状態情報と、状態遷移ルールとを記憶する記憶部と、
   前記複数の装置の状態情報と、受信した前記変更内容とを用いて、該変更内容による変更後の情報処理システムの状態に至るまでの遷移にて前記複数の装置各々がとり得る状態に基づいて状態遷移毎の該情報処理システムの状態情報を生成する生成部と、
   前記状態遷移ルールに基づいて、生成した前記状態遷移毎の情報処理システムの状態情報から、前記変更後の情報処理システムの状態に至るまでの前記複数の装置の制御手順の候補を抽出する抽出部と、
   前記制御手順の候補から、最も手順数が少ない制御手順を特定する特定部と、
   ことを特徴とする制御手順生成装置。