JP5801432B2 - 基盤運用管理システムおよび基盤運用管理方法 - Google Patents

Description

本発明は、情報処理システムの基盤、インフラの運用管理技術に関し、特に、クラウドコンピューティングサービス上に構築される情報処理システムの基盤の運用管理を行う基盤運用管理システムおよび基盤運用管理方法に適用して有効な技術に関するものである。

近年では、例えば、Ａｍａｚｏｎ ｗｅｂ ｓｅｒｖｉｃｅｓ（登録商標、以下では「ＡＷＳ」と記載する場合がある）や、Ｗｉｎｄｏｗｓ Ａｚｕｒｅ（登録商標） 、Ｇｏｏｇｌｅ（登録商標） Ａｐｐ Ｅｎｇｉｎｅなど、仮想サーバやストレージなどのリソースを提供する商用のクラウドコンピューティングサービス（以下では単に「クラウド」と略称する場合がある）が各種提供されて普及してきている。これらのサービスを利用することにより、自身でサーバ機器等を保持して運用管理することなく、ネットワークを介して必要なリソースを必要なだけ調達して、Ｗｅｂシステムなどの情報処理システムを低コストで柔軟に構築することができる。

仮想サーバを起動させる際には、ゼロからＯＳ（Operating System）やミドルウェア、アプリケーションプログラムなどのソフトウェアを導入してセットアップするのではなく、セットアップされた状態のベースとなる仮想サーバの稼動状態をキャプチャしたマシンイメージ、サーバイメージなどと呼ばれるイメージファイル（例えばＡＷＳではＡＭＩ（Amazon Machine Image））に基づいて、仮想サーバのインスタンスが複数起動されるのが通常である。

この場合、イメージファイルに含まれるソフトウェア等にバージョンアップや変更、リリース等があった場合には、最新の稼働状態でイメージファイルを再作成し、作成されたイメージファイルを新たにリリースしたり展開したりする作業が行われる。

これに関連する技術として、例えば、特開２０１２−７８８９３号公報（特許文献１）には、個々のユーザが利用するゲストＯＳの仮想イメージを、サーバで管理し、ユーザが利用者端末を起動する時に、仮想イメージ、または、仮想イメージの更新用の差分データをサーバから配信し、また、ユーザが利用者端末をシャットダウンする時に、利用者端末から、仮想イメージ、または、仮想イメージの更新用の差分データをサーバへアップロードし、サーバ上では、アップロードされた仮想イメージを使ってゲストＯＳを起動してアップデートを行うことで、個々のユーザが自由にカスタマイズすることが可能な仮想化されたＯＳ環境を、効率的にアップデートできるシステムを実現する技術が記載されている。

また、国際公開第２０１１／１１７５９４号パンフレット（特許文献２）には、所定の機能を実現する動作環境を仮想マシンに構築させるための構成情報を、管理者の操作入力に従って設定する構成情報設定部と、管理者からの操作入力に従って、ハードウェア資源を複数のユーザに共有させる仮想化システム内で仮想マシンの起動時に実行する起動スクリプトを生成する起動スクリプト生成部と、起動スクリプト生成部により生成された起動スクリプトを仮想化システムに送信する起動スクリプト送信部と、起動スクリプトにより仮想化システム内に起動した仮想マシンからの要求に応じて、構成情報設定部により設定された構成情報を、要求した仮想マシンに送信する構成情報送信部とから構成される仮想マシン管理装置が記載されている。

特開２０１２−７８８９３号公報 国際公開第２０１１／１１７５９４号

従来技術では、個々のユーザが利用する仮想マシンについてのイメージファイルの管理を効率的に行うことができるが、一方で、このようなイメージファイルに基づいて、同様の構成の仮想サーバを必要に応じて必要な数だけ起動し、さらに、起動後に必要に応じて構成の追加・変更等のカスタマイズを行うことも可能であり、クラウド上での仮想サーバの管理を行うことが可能である。

しかしながら、イメージファイルに基づいて情報処理システムに必要な仮想サーバをそれぞれ構築する場合、仮想サーバの種類に応じて異なるイメージファイルが必要となる場合があり、また、仮想サーバの環境を旧バージョンに切り戻し可能とするためにはイメージファイルをバージョン管理することが必要となるなど、イメージファイルの管理が煩雑となる。また、例えば、イメージファイルに含まれるアプリケーションの開発に複数チームが関連している場合、それぞれのチームによる並行開発とリリースによりイメージファイルのマスタ管理が破綻してしまう可能性も高くなる。

そこで本発明の目的は、クラウド環境上に構築される情報処理システムにおいて、仮想サーバのイメージファイルに対する管理を極小化して、仮想サーバの構成管理を効率的に行うことを可能とする基盤運用管理システムおよび基盤運用管理方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による基盤運用管理システムは、クラウドコンピューティング環境上に仮想サーバによって情報処理システムを構築するための基盤運用管理システムであって、前記仮想サーバが起動された後に適用されるソフトウェアおよび設定情報を含む構成情報を保管する仮想ストレージからなる構成保管ストレージを有し、前記仮想サーバの一部は、前記クラウドコンピューティング環境におけるオートスケール機能により一定の台数が維持されるよう自動的に運用されるグループとして構成され、前記グループに含まれる前記各仮想サーバは、ＯＳおよび構成管理部を少なくとも含む必要最小限のシステム構成からなるイメージファイルに基づいて起動され、前記構成管理部は、前記構成保管ストレージから当該仮想サーバに対応する前記構成情報を取得して、当該構成情報に基づいてソフトウェアのセットアップおよび設定変更を含む処理を実行して当該仮想サーバを構築するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、クラウド環境上に構築される情報処理システムにおいて、仮想サーバのイメージファイルに対する管理を極小化して、仮想サーバの構成管理を効率的に行うことが可能となる。

本発明の一実施の形態である基盤運用管理システムの構成例について概要を示した図である。 本発明の一実施の形態におけるフロントエンドサーバおよびバックエンドサーバの構成例について概要を示した図である。 本発明の一実施の形態におけるバッチサーバの構成例について概要を示した図である。 本発明の一実施の形態における仮想サーバを起動して構成する仕組みの例について概要を示した図である。 本発明の一実施の形態におけるサーバ間の接続構成を管理する仕組みの例について概要を示した図である。 本発明の一実施の形態におけるログの管理および監視の仕組みの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

本発明の一実施の形態である基盤運用管理システムは、クラウド環境上に仮想サーバによって情報処理システムを構築する際の基盤システムとして機能し、各仮想サーバを構築する際に用いられるイメージファイルとして、ＯＳや必要なミドルウェアなどの必要最小限度のソフトウェアのみが含まれるように作成されたものを用いる。

一方で、起動後の仮想サーバ上にインストールされて稼働するアプリケーションプログラムやパッケージなどの各種ソフトウェア、設定情報やパラメータ、さらにはＯＳやミドルウェアに対して適用されるパッチなど、およそ起動後の仮想サーバに対して適用される各種ソフトウェアやデータ等、およびこれらの構成情報は、各仮想サーバからアクセス可能なストレージに一元的に管理する。

これにより、各種ソフトウェアのインストールや、アプリケーションプログラムのリリース、さらにはこれらの切り戻しなどの作業を、イメージファイルの更新なしに、ストレージ上の構成情報を更新することで一元的かつ容易に行うことを可能とする。また、各仮想サーバにおけるＯＳやミドルウェア等の設定、更新なども含めたこれらの一連の処理を自動化することを可能とする。

＜システム構成＞
図１は、本発明の一実施の形態である基盤運用管理システムの構成例について概要を示した図である。基盤運用管理システム１は、例えば、ＡＷＳを例にすると、Ａｍａｚｏｎ ＥＣ２（登録商標）のようなクラウドホスティングサービスからなるクラウド基盤１０上に構成され、クラウド基盤１０上に構築された情報処理システムの運用管理を行う機能を有する基盤システムである。

クラウド基盤１０上で構築される情報処理システムは、Ｗｅｂシステム等、図示しないインターネット等を介して大量のリクエストを受け付けるものが多いことから、通常は、同様の処理を行う仮想サーバを複数台並列に設けてクラスタとし、クラスタ内のサーバに対してロードバランサ（クラウドサービスにより提供される場合もあり、例えば、ＡＷＳではＥｌａｓｔｉｃ Ｌｏａｄ Ｂａｌａｎｃｉｎｇ機能（以下では「ＥＬＢ」と記載する場合がある）として提供される）によりリクエストを振り分けることにより負荷分散が行われる。このとき、これらのクラウドサービスに特有のいわゆるオートスケール機能を利用して、サーバの負荷の増減等に応じてクラスタ内のサーバ台数を適宜増減（スケールアウト／スケールイン）したり、障害等によるサーバの停止に対して同数のサーバを追加起動して一定台数を維持したり等の運用を自動的に行うことができる。

これらのサービス上で構築される情報処理システムでは、さらに可用性を高めて災害対策にも適用できるよう、例えば、ＡＷＳではＡｖａｉｌａｂｉｌｉｔｙ Ｚｏｎｅ（以下では「ＡＺ」と記載する場合がある）という機能により、クラウド環境内であっても物理的に異なるロケーションにシステムを構築することで、多系統／多重化の構成とする場合もある。

本実施の形態では、情報処理システムは、それぞれ同様のサービスを提供するＡ系１１ａとＢ系１１ｂの２系統の構成を有することを示しており、各系統は、例えばＡＷＳにおけるＡＺ機能により、クラウド環境内であっても物理的に異なるロケーションに構築することができる。各系統では、仮想サーバにより構成された１つ以上のＷｅｂサーバ等からなるフロントエンドサーバのクラスタ構成（フロントエンドサーバ２０ａ、２０ｂ（以下ではフロントエンドサーバ２０と総称する場合がある））に対して、ＥＬＢ等により構成される外部ロードバランサ（ＬＢ）１２により、ユーザからのリクエスト（図中の実線矢印で示す）が割り振られることで負荷分散が行われる。

フロントエンドサーバ２０（２０ａ、２０ｂ）の各クラスタは、それぞれクラウド基盤１０が有するオートスケール機能により一定台数を維持するよう運用されるグループとして構成されている。この一定台数は、例えば、サービスの特性上、トランザクションの量が増減するタイミングが予測できる場合には、当該タイミングに合わせてスケールアウトして増加させたり、スケールインして減少させたりすることができる。例えば、サービスに係る取引が開始する時間や、取引が集中する時間帯に合わせてスケールアウトし、取引時間の終了する時間に合わせてスケールインするよう、台数調整することができる。時間帯だけに限らず、月末など時期に応じて調整することも可能である。

なお、スケールインする際に停止・終了させるフロントエンドサーバ２０については、例えば、最も長時間起動しているものから優先的に停止・終了させることで、常時稼働のコンピュータ機器について一般的に行われる定期的なリブート運用などの代替とし、長時間稼働による予期せぬ不具合発生の可能性を低減することができる。

さらに、本実施の形態では、オートスケール機能の実効性を簡易な手法により効率的に上げるため、負荷分散を行う外部ＬＢ１２が、負荷分散の対象となる各フロントエンドサーバ２０に対してロードバランサの標準機能として一般的に有するヘルスチェック機能（サーバとの間の通信可否を定期的にチェックする機能）を利用して、不具合のあるフロントエンドサーバ２０を停止させ、オートスケール機能により新たにフロントエンドサーバ２０のインスタンスを自動的に起動させる構成をとる。

具体的には、例えば、外部ＬＢ１２が各フロントエンドサーバ２０に対してヘルスチェック機能によりＨＴＴＰ（HyperText Transfer Protocol）通信を行って生死判断をし（図中の点線矢印で示す）、死状態である場合には当該サーバに対してクラウド基盤１０等の機能を利用してシステム終了のコマンドを発行する等によりシステムを停止・終了させる。このとき、クラウド基盤１０のオートスケール機能が自動的に働いて、停止・終了したフロントエンドサーバ２０に対応するフロントエンドサーバ２０を新たに起動する。これにより、障害状態までは至らないが動作が不安定な状態のフロントエンドサーバ２０について、強制的に停止させて新たなフロントエンドサーバ２０を起動させてリフレッシュすることができる。

なお、サーバの起動に際しては、後述するように、必要最小限度のソフトウェアのみが含まれたイメージファイルに基づいて仮想サーバを起動し、さらに、クラウド基盤１０上に仮想ストレージにより構成された構成保管ストレージ７０に一元的に管理されている構成情報を読み出して、その内容に基づいて必要なアプリケーションやソフトウェア等の追加導入・設定などを行ってセットアップする。

本実施の形態の情報処理システムでは、フロントエンドサーバ２０により受け付けられたリクエストは、業務処理等を行う各系統の１つ以上のバックエンドサーバ３０ａ、３０ｂ（以下ではバックエンドサーバ３０と総称する場合がある）に対して送信されて処理されるものとする。後述するように、各フロントエンドサーバ２０がどのバックエンドサーバ３０に接続してリクエストを送信するかについては、例えば、クラウド基盤１０上の仮想データベースサービス（例えば、ＡＷＳではＤｙｎａｍｏＤＢ）により構成された接続情報ＤＢ８０に一元的に管理されている接続情報に基づいて動的に判断された上で接続される。なお、バックエンドサーバ３０により処理された結果のレスポンスがフロントエンドサーバ２０を経由してユーザに応答される際の流れについては記載を省略する。

各系統のバックエンドサーバ３０においては、フロントエンドサーバ２０からの負荷分散は行われないが、フロントエンドサーバ２０と同様に、それぞれクラウド基盤１０が有するオートスケール機能により一定台数を維持するよう運用されるグループとして構成されている。

本実施の形態では、さらに、フロントエンドサーバ２０と同様のロードバランサによるヘルスチェック機能を利用したサーバのリフレッシュ機能を実現するため、各バックエンドサーバ３０に対するヘルスチェック機能を行うことを目的として内部ロードバランサ（ＬＢ）４０ａ、４０ｂ（以下では内部ＬＢ４０と総称する場合がある）を各系統にそれぞれ有する。内部ＬＢ４０は、各バックエンドサーバ３０に対してヘルスチェック機能により定期的に通信の生死判断をし（図中の点線矢印で示す）、死状態である場合には当該サーバを停止・終了させる。これにより、オートスケール機能によって対応するバックエンドサーバ３０が新たに起動される。

なお、本実施の形態では、内部ＬＢ４０は負荷分散を行わない構成としているが、例えば、フロントエンドサーバ２０からのリクエストを受け付けてバックエンドサーバ３０に対して負荷分散を行う構成とすることも可能である。

本実施の形態では、さらに、各系統には、トランザクション処理を行わずに各サーバのログの収集や運用状態の管理等の処理を所定のタイミングで行うバッチサーバ５０ａ、５０ｂ（以下ではバッチサーバ５０と総称する場合がある）をそれぞれ有する。バッチサーバ５０は、後述するように、オートスケール機能の対象でありトランザクション処理を行うフロントエンドサーバ２０やバックエンドサーバ３０等のサーバにより出力された各種ログファイルや監視結果の情報（以下ではこれらを単に「ログ」と総称する場合がある）を一元的に集約して管理するとともに、ログの種類等に応じて必要な場合には、クラウド基盤１０上に仮想ストレージにより構成されたログ保管ストレージ６０にログを退避させ、もしくはバックアップする。なお、バッチサーバ５０については、オートスケール機能の対象とする必要はない。

図２は、フロントエンドサーバ２０およびバックエンドサーバ３０の構成例について概要を示した図である。フロントエンドサーバ２０およびバックエンドサーバ３０は、いずれも基本的には同様の構成により起動される仮想サーバであり、例えば、ソフトウェアプログラムにより実装される、ＯＳ２１、構成管理部２２、ログ収集部２３、ヘルスチェック（ＨＣ）部２４、監視部２５、ミドルウェア２６、およびアプリケーション２７などの各部を有する。

ＯＳ２１は、仮想サーバの構成におけるゲストＯＳであり、例えば、Ｌｉｎｕｘ（登録商標）やＷｉｎｄｏｗｓ（登録商標）などが用いられる。フロントエンドサーバ２０とバックエンドサーバ３０とで異なるＯＳであってもよい。構成管理部２２は、仮想サーバにおける構成を管理し、各仮想サーバの構成や設定、アプリケーション等の導入・展開などを自動的に行って仮想サーバを構成する機能を有する。例えば、一般に用いられているオープンソースのサーバ構成管理ツールであるＣｈｅｆなどを用いて実装することができる。構成管理を行う際の構成情報（例えば、ＣｈｅｆにおけるＣｏｏｋＢｏｏｋ）は、上述したように、例えば、クラウド基盤１０上の構成保管ストレージ７０上に保管される。

ログ収集部２３は、当該仮想サーバ上で出力されたログファイルや、後述する監視部２５による監視結果において異常が検出された旨のイベントなど、情報処理システムの運用管理において必要となるデータを収集し、後述するように、リアルタイムで監視が必要なログについてはバッチサーバ５０に送信して一元的に集約するとともに、システム監査等のために一定期間の保存が必要なログについてはクラウド基盤１０上のログ保管ストレージ６０上に転送して保管する機能を有する。例えば、一般に用いられているオープンソースのログ収集基盤ツールであるＦｌｕｅｎｔｄなどを用いて実装することができる。

ＨＣ部２４は、外部ＬＢ１２や内部ＬＢ４０などのロードバランサからのヘルスチェック機能によるチェック対象となるモジュールであり、通常は、定期的なヘルスチェックのリクエストに対してＯＫを応答する。一方で、例えば、後述する監視部２５による監視結果において所定の異常が検出された場合には、ヘルスチェックのリクエストに対してＮＧを応答する。ＮＧが応答されることにより、上述したように、ロードバランサは当該サーバが死状態であると判断し、当該サーバに対してクラウド基盤１０等の機能を利用してシステム終了のコマンドを発行する等によりシステムを停止・終了させる。このとき、クラウド基盤１０のオートスケール機能が自動的に働いて、停止・終了したフロントエンドサーバ２０に対応するフロントエンドサーバ２０が新たに起動される。

サーバ全体もしくはＨＣ部２４自身が不具合となった場合は、ＨＣ部２４がヘルスチェックのリクエストに対して応答することができない結果、ヘルスチェックがタイムアウトし、当該サーバが死状態であると判断される。また、例えば、サーバ全体およびＨＣ部２４はシステム的には正常に稼働しているが、アプリケーション的に正常な処理が行えない状態であるというような場合にも、ＨＣ部２４がＮＧを応答することにより、当該サーバが死状態であると判断され、これを停止・終了させてリフレッシュすることができる。

監視部２５は、当該サーバ上において必要なプロセスや処理についての異常の有無を監視する機能を有する。例えば、常駐プログラムとして実装され、各種プロセスの起動状態や、処理結果などのチェックを常時行うよう構成される。所定のイベントやタイミングで随時起動されて処理を行うプログラムとして実装されていてもよい。監視結果のデータは、後述するように、例えば、ログ収集部２３を介してバッチサーバ５０上に一元的に集約することができる。

ミドルウェア２６は、例えば、ＤＢＭＳ（DataBase Management System）やＷｅｂサーバプログラムなど、当該サーバ上でトランザクションに係る処理を行うための機能を有する基盤ソフトウェアである。フロントエンドサーバ２０とバックエンドサーバ３０とで異なる種類のものが含まれていてもよい。アプリケーション２７は、当該サーバ上でトランザクションに係る業務処理を行うための機能を有するソフトウェアプログラムである。フロントエンドサーバ２０とバックエンドサーバ３０とでは異なるプログラムとなる。

図３は、バッチサーバ５０の構成例について概要を示した図である。バッチサーバ５０も、基本的にはフロントエンドサーバ２０やバックエンドサーバ３０と同様の構成により起動される仮想サーバであり、例えば、ソフトウェアプログラムにより実装される、ＯＳ５１、構成管理部５２、ログ収集部５３、ミドルウェア５４、およびログ監視部５５などの各部を有する。

ＯＳ５１、構成管理部５２、およびミドルウェア５４については、フロントエンドサーバ２０やバックエンドサーバ３０と同様であるため説明は省略する。ログ収集部５３は、各フロントエンドサーバ２０やバックエンドサーバ３０上のログ収集部２３と連携して、これらを介してログを収集して一元的に集約する機能を有する。クラウド基盤１０の機能によりクラウド基盤１０からログなどを取得することも可能である。バッチサーバ５０自身で生成されたログを収集する機能を有していてもよい。また、後述するように、必要に応じて収集したログをクラウド基盤１０上のログ保管ストレージ６０上に退避させ、もしくはバックアップする機能も有する。

ログ監視部５５は、ログ収集部５３によって一元的に集約されたログの内容をリアルタイムで監視し、異常の有無を検出する機能を有する。例えば、一般に用いられている運用監視ツールや、ＯＳ５１が有するコマンドなどを適宜用いて実装することができる。

＜サーバ構成管理＞
上述したように、従来は、仮想サーバの構成やソフトウェアについて変更や更新を行う場合、例えば、イメージファイルによって仮想サーバを起動した後、必要な変更等を行った上で新たにイメージを作り直すなどの手作業により行われていた。この場合、仮想サーバの種類や、旧バージョンへの切り戻し等のために、イメージファイルをバージョン管理することが必要となるなど、イメージファイルの管理が煩雑となる。また、例えば、イメージファイルに含まれるアプリケーションの開発に複数チームが関連している場合、それぞれのチームによる並行開発とリリースによりイメージファイルのマスタ管理が破綻してしまう可能性も高くなる。

そこで本実施の形態では、イメージファイルにはＯＳや必要なミドルウェアなどの必要最小限度のソフトウェアのみが含まれるように作成されたものを用いる。一方で、起動後の仮想サーバ上にインストールされて稼働するアプリケーションプログラムやパッケージなどの各種ソフトウェア、設定情報やパラメータ、さらにはＯＳやミドルウェアに対して適用されるパッチなど、およそ起動後の仮想サーバに対して適用される各種ソフトウェアやデータ等、およびこれらの構成情報は、クラウド基盤１０上の構成保管ストレージ７０に一元的に管理する。

図４は、本実施の形態における各仮想サーバ、特にオートスケール機能により台数が自動で増減するサーバについて、仮想サーバを起動して構成する仕組みの例について概要を示した図である。仮想サーバ（図４の例ではフロントエンドサーバ２０およびバックエンドサーバ３０）を新たに起動する必要が生じると、オートスケール機能により、クラウド基盤１０が、必要最小限のソフトウェアのみが含まれたイメージファイルであるイメージ７１に基づいて仮想サーバを起動する（Ｓ０１）。

本実施の形態では、イメージ７１には、必要最小限のソフトウェアとして、例えば、ＯＳ２１、構成管理部２２、およびログ収集部２３に対応するモジュールを含むものとしている。ＯＳ２１は、仮想サーバとして稼働するために必須の基本ソフトウェアであり、構成管理部２２は、仮想サーバの起動後にソフトウェアの導入、セットアップ、構成変更等の必要な処理を行ってサーバを構成するために必要なモジュールである。また、ログ収集部２３は、仮想サーバの起動、構成という観点では必ずしも必要ではないが、起動後の仮想サーバの構成の過程で発生した障害事象を把握するためにログを収集するのが望ましいことから含められる。さらに必要に応じてミドルウェア２６の全部もしくは一部をイメージ７１に含んでいてもよい。なお、フロントエンドサーバ２０とバックエンドサーバ３０とで共通のイメージ７１を用いるようにすることも可能である。

仮想サーバは、起動後、クラウド基盤１０上の構成保管ストレージ７０から構成情報７２を取得する（Ｓ０２）。構成情報７２には、アプリケーション２７のモジュールや、ミドルウェア２６の設定、その他の構成情報が含まれる。構成管理部２２がＣｈｅｆの場合にはＣｏｏｋＢｏｏｋが構成情報７２に該当する。障害等により構成保管ストレージ７０から構成情報７２が取得できない場合には、バッチサーバ５０から取得するようにして可用性を向上させてもよい。この場合、バッチサーバ５０にも構成情報７２を予め保管しておく必要がある。

構成情報７２を取得すると、仮想サーバは、構成管理部２２を起動させる（Ｓ０３）。ステップＳ０２、Ｓ０３の処理は、例えば、サーバ起動時の自動実行スクリプト（例えば、ＯＳ２１がＬｉｎｕｘ（登録商標）の場合はｃｒｏｎｄにより実行される）により自動的に実行されるようにする。構成管理部２２が起動されると、構成情報７２の内容に従って、アプリケーション２７のモジュールを取得してインストールしたり、ミドルウェア２６の設定変更、その他パラメータの設定などを行ったりして仮想サーバを構成する（Ｓ０４）。

このような手法をとることにより、オートスケール機能により仮想サーバが新たに起動される度に、構成保管ストレージ７０上に保管された最新の構成情報７２に従って最新の構成の仮想サーバを自動的に起動することができる。また、イメージ７１を変更することなく、構成情報７２を変更することで容易に仮想サーバの構成管理を行うことが可能である。

従って、例えば、アプリケーション２７のバージョンアップやリリースの際にも、イメージ７１に反映させて展開するという作業を要さず、構成保管ストレージ７０にリリースモジュールを配置し、構成情報７２に反映させておくだけで、リリースされた最新状態の仮想サーバに容易に切り替えることができる。例えば、上述したように、オートスケール機能により時間帯によりサーバ台数を増減させ、減少させる際に起動時間が最も長いものから優先的に停止・終了させるような運用をとる場合には、特に何も作業をしなくても数日の間に仮想サーバが順次自動的に最新の構成に切り替わっていくことになる。

＜接続構成管理＞
本実施の形態では、フロントエンドサーバ２０およびバックエンドサーバ３０は、相互に接続して処理を行う構成となっている。しかしながら、これらのオートスケール機能により起動される仮想サーバはＩＰアドレスが不定であるため、接続先のサーバとして予め固定のサーバを設定しておくことができない。そこで、サーバ間の接続構成を、例えば一部のサーバに接続が集中しないように分散させるなどの制御を行いつつ管理する必要がある。

本実施の形態では、クラウド基盤１０上の接続情報ＤＢ８０に、サーバ間の接続情報を保持することで、サーバ間の接続構成を動的に管理する。図５は、本実施の形態における各仮想サーバ、特にオートスケール機能により台数が自動で増減するサーバ（本実施の形態ではフロントエンドサーバ２０およびバックエンドサーバ３０）について、サーバ間の接続構成を管理する仕組みの例について概要を示した図である。

まず、接続を受け付けるサーバであるバックエンドサーバ３０は、オートスケール機能により起動・構成されると（Ｓ２１）、バックエンドサーバ３０についての接続情報を管理する接続情報ＤＢ（８０Ｂ）に対して自身のレコードを追加する（Ｓ２２）。ここでの接続情報には、例えば、対象のバックエンドサーバ３０を識別するキーとなるインスタンスＩＤなどの識別情報、系統、割り当てられたＩＰアドレスの値などの情報が含まれる。さらに、バックエンドサーバ３０については、自身に対して接続しているフロントエンドサーバ２０の台数の情報を保持するものとする。

一方、接続を行うサーバであるフロントエンドサーバ２０は、オートスケール機能により起動・構成されると（Ｓ１１）、フロントエンドサーバ２０についての接続情報を管理する接続情報ＤＢ（８０Ｆ）に対して自身のレコードを追加する（Ｓ１２）。ここでの接続情報には、例えば、対象のフロントエンドサーバ２０を識別するキーとなるインスタンスＩＤなどの識別情報、系統、割り当てられたＩＰアドレス、ホスト名などの情報が含まれる。

その後、フロントエンドサーバ２０は、接続情報ＤＢ（８０Ｂ）にアクセスして、各バックエンドサーバ３０についての接続数の情報を参照し（Ｓ１３）、接続数が最も少ないバックエンドサーバ３０を接続先として選択して（Ｓ１４）、当該バックエンドサーバ３０に対して接続する（Ｓ１５）。当該バックエンドサーバ３０において接続が許可されると（Ｓ２３）、フロントエンドサーバ２０は、接続情報ＤＢ（８０Ｂ）にアクセスして、当該バックエンドサーバ３０のレコードの接続数をインクリメントして更新する（Ｓ１６）。

これにより、各バックエンドサーバ３０に対するフロントエンドサーバ２０の接続が集中しないように分散させることができる。なお、バッチサーバ５０が定期的に接続情報ＤＢ（８０Ｂ）および接続情報ＤＢ（８０Ｆ）にアクセスして、接続数についての整合性をチェックし、不整合がある場合には修正したり、通知したりするようにしてもよい（Ｓ３１）。

フロントエンドサーバ２０およびバックエンドサーバ３０の上記処理は、仮想サーバの起動時にｃｒｏｎｄ等により自動実行されるスクリプトファイルなどにより自動実行することができる。なお、フロントエンドサーバ２０およびバックエンドサーバ３０の停止時には、接続情報ＤＢ（８０Ｂ）および接続情報ＤＢ（８０Ｆ）における自身のレコードを削除するものとする。

以上の処理により、オートスケール機能により動的に台数が変動し、ＩＰアドレスも不定である仮想サーバ間での接続構成を管理し、例えば一部のサーバに接続が集中しないように分散させるなどの制御を行うことができる。

なお、本実施の形態では、フロントエンドサーバ２０とバックエンドサーバ３０という２階層のグループからなるシステム構成における接続構成を管理しているが、これに限らず、さらに多段の階層を有していてもよいし、１つの仮想サーバが複数種類の仮想サーバに並列的に接続する構成であってもよい。この場合は、例えば、相互に接続される仮想サーバのグループ間毎にそれぞれ上記のような接続数等の管理を行えばよい。

＜ログの管理および監視＞
本実施の形態におけるフロントエンドサーバ２０やバックエンドサーバ３０は、オートスケール機能によって条件に応じて動的に起動・停止がなされて台数が変動する。また、これらの仮想サーバは、上述したようにＩＰアドレスが不定である。

従って、これらの仮想サーバの稼働状況を監視するに際して、例えば、監視サーバ等の独立したサーバからＩＰアドレスにより監視対象を特定して監視するような一般的な監視システムは適さない。また、オートスケール機能により仮想サーバが動的に起動・停止されるために、監視やシステム監査等のために保存しておくべきログが消失しないよう、これらを別のサーバやストレージ等に退避しておく必要がある。

そこで、本実施の形態では、フロントエンドサーバ２０やバックエンドサーバ３０についての稼働状況の監視は、自立的な監視やクラウド基盤１０が有する運用監視機能によりプロセス監視等を行うとともに、これらの監視により検出された異常に係るイベントや、フロントエンドサーバ２０およびバックエンドサーバ３０が出力したログファイルのうちリアルタイムでの監視、ログ解析が必要なものについては、バッチサーバ５０に一元的に集約し、バッチサーバ５０上でリアルタイムでの監視、解析処理を行う。また、ログファイルのうちシステム監査等のために一定期間保管しておく必要があるものについては、クラウド基盤１０上のログ保管ストレージ６０に退避させ、もしくはバックアップする。

図６は、本実施の形態におけるログの管理および監視の仕組みの例について概要を示した図である。本実施の形態では、フロントエンドサーバ２０およびバックエンドサーバ３０において、アプリケーション２７等が出力したログの全部もしくは一部のうち、リアルタイムでの監視が必要なものについては、例えば、ログ収集部２３とバッチサーバ５０上のログ収集部５３との間の連携によりバッチサーバ５０に転送して（例えば、Ｆｌｕｅｎｔｄ間の転送機能を利用）、一元的に集約する。集約したログについては、例えば、バッチサーバ５０上のログ監視部５５によりリアルタイムで集中監視する。

フロントエンドサーバ２０およびバックエンドサーバ３０におけるプロセス監視について、例えば、仮想サーバ自体の生死監視としては、上述したように、外部ＬＢ１２もしくは内部ＬＢ４０からのヘルスチェック機能を用いて、ＨＣ部２４による応答結果に基づいて生死判断を行う。当該監視は、正確にはＨＣ部２４に対するサービス監視であるが、便宜的に仮想サーバのプロセス監視と同等のものとして取り扱う。

なお、外部ＬＢ１２もしくは内部ＬＢ４０により検出したＨＣ部２４からのエラー応答（もしくは無応答）は、バッチサーバ５０のログ収集部５３を介してバッチサーバ５０上に集約し、ログ監視部５５によるリアルタイム監視につなげる。バッチサーバ５０への集約に際しては、クラウド基盤１０のメッセージ転送機能（例えば、ＡＷＳにおけるＡｍａｚｏｎ ＳＮＳ（Simple Notification Service）やＡｍａｚｏｎ ＳＱＳ（Simple Queue Service））等を利用することができる。

本実施の形態では、さらに、外部ＬＢ１２および内部ＬＢ４０によるヘルスチェック機能では検出できない、ログ収集部２３などの仮想サーバ上でのプロセス監視を行うため、フロントエンドサーバ２０およびバックエンドサーバ３０は、それぞれ常駐プログラムである監視部２５を有している。監視部２５により異常が検出された際には、上記と同様に、例えば、クラウド基盤１０のメッセージ転送機能等を利用してバッチサーバ５０のログ収集部５３を介してログを集約し、ログ監視部５５によるリアルタイム監視につなげる。なお、監視部２５自身に対するプロセス監視については、図示しないが、例えば、ｃｒｏｎｄ等により定期的に自動実行される監視スクリプト等により実施することができる。

各系統のフロントエンドサーバ２０およびバックエンドサーバ３０のログ収集部２３は、それぞれ自身の系統のバッチサーバ５０に対してログを転送する。しかしながら、バッチサーバ５０の障害によりログの集約ができなくなったり転送漏れが生じたりすることを防ぐため、各系統のフロントエンドサーバ２０およびバックエンドサーバ３０に対して、両系統のバッチサーバ５０はそれぞれがアクティブとなり、各系統のフロントエンドサーバ２０およびバックエンドサーバ３０は、いずれの系統のバッチサーバ５０に対してもログを転送可能なように構成するのが望ましい。

各フロントエンドサーバ２０およびバックエンドサーバ３０のＣＰＵ使用率等の閾値監視については、例えば、クラウド基盤１０が有する仮想サーバについての監視機能（例えば、ＡＷＳにおけるＡｍａｚｏｎ ＣｌｏｕｄＷａｔｃｈ）等を利用して行い、異常検出時には、クラウド基盤１０のメッセージ転送機能等を利用してバッチサーバ５０のログ収集部５３を介してログを集約し、ログ監視部５５によるリアルタイム監視につなげる。なお、バッチサーバ５０自身に対する各種プロセス監視や閾値監視については、ログ監視部５５やその他の監視ツール等によって行い、監視結果をそのままバッチサーバ５０上で利用することができる。

以上のような仕組みにより、リアルタイムで監視や解析が必要なログ等については、オートスケール機能によるサーバの停止・起動による消失を防いで、バッチサーバ５０上に一元的に集約し、効率的に監視、解析を行うことが可能である。

一方、システム監査等の目的や、キャパシティプランニングの基礎情報とする目的などのために一定期間保管しておく必要があるログについては、クラウド基盤１０上のログ保管ストレージ６０に退避させ、もしくはバックアップする。このログには、フロントエンドサーバ２０やバックエンドサーバ３０上で出力されたものに限らず、バッチサーバ５０上で出力されたものも含まれる。また、リアルタイム監視が必要であるとしてバッチサーバ５０上に集約されたログについても、バッチサーバ５０により一括してログ保管ストレージ６０に退避させてもよい。

ログ保管ストレージ６０での保管対象とするログおよび保存期間については、運用要件に応じて適宜設定することができる。ログ保管ストレージ６０上での保存期間経過後のログの削除運用については、当該運用を行うようなツールやプログラムを実装してもよいし、クラウド基盤１０が有する機能を利用して、例えば、仮想ストレージのライフサイクル（有効期限）ポリシーに従って期間経過後に自動消滅するような構成をとることも可能である。

なお、フロントエンドサーバ２０およびバックエンドサーバ３０については、例えば、上述したように、オートスケール機能により時間帯によりサーバ台数を増減させ、減少させる際に起動時間が最も長いものから優先的に停止・終了させるような運用をとる場合には、一定の期間で仮想サーバが停止・終了され、サーバに保持されているログについてもこれと同時にクリアされることから、ログのローテーション等の仕組みを特に実装する必要はない。一方、バッチサーバ５０については、オートスケール機能の対象ではないことから、ログのクリアやローテーションの仕組みを実装して運用する必要がある。

以上に説明したように、本発明の一実施の形態である基盤運用管理システム１によれば、クラウド基盤１０上において情報処理システムを構成する各仮想サーバを構築する際に用いられるイメージファイルとして、ＯＳや必要なミドルウェアなどの必要最小限度のソフトウェアのみが含まれるように作成されたイメージ７１を用いる。一方で、起動後の仮想サーバ上にインストールされて稼働するアプリケーションや各種設定情報等を含む構成情報については、クラウド基盤１０上の構成保管ストレージ７０上に一元的に管理し、仮想サーバの起動後に当該構成情報を参照して、これに基づいてセットアップする。

これにより、各種ソフトウェアのインストールや、アプリケーションプログラムのリリース、さらにはこれらの切り戻しなどの作業を、イメージファイルの更新なしに、構成保管ストレージ７０上の構成情報７２を更新することで一元的かつ容易に行うことが可能となる。また、各仮想サーバにおけるＯＳやミドルウェア等の設定、更新なども含めたこれらの一連の処理を自動化することが可能である。

また、オートスケール機能により動的に台数が変動し、ＩＰアドレスも不定である仮想サーバ間での接続構成を、クラウド基盤１０上の接続情報ＤＢ８０上で管理し、これを参照することで、例えば一部のサーバに接続が集中しないように分散させるなどの制御を行うことが可能である。

また、オートスケール機能により動的に起動・停止される仮想サーバにおいて出力される、リアルタイムで監視や解析が必要なログについては、バッチサーバ５０上に一元的に集約して監視することで、オートスケール機能によるサーバの停止・起動による消失を防いで、効率的に監視、解析を行うことが可能である。また、システム監査等のために一定期間の保存が必要なログについては、クラウド基盤１０上のログ保管ストレージ６０上に転送して保管する。これにより、オートスケール機能によるサーバの停止・起動による消失を防ぎつつ、クラウド基盤１０の機能を利用して効率的なログ保管の運用を行うことが可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、クラウドコンピューティングサービス上に構築される情報処理システムの基盤の運用管理を行う基盤運用管理システムおよび基盤運用管理方法に利用可能である。

１…基盤運用管理システム、
１０…クラウド基盤、１１ａ…Ａ系、１１ｂ…Ｂ系、１２…外部ＬＢ、
２０（２０ａ、２０ｂ）…フロントエンドサーバ、２１…ＯＳ、２２…構成管理部、２３…ログ収集部、２４…ＨＣ部、２５…監視部、２６…ミドルウェア、２７…アプリケーション、
３０（３０ａ、３０ｂ）…バックエンドサーバ、
４０ａ、４０ｂ…内部ＬＢ、
５０（５０ａ、５０ｂ）…バッチサーバ、５１…ＯＳ、５２…構成管理部、５３…ログ収集部、５４…ミドルウェア、５５…ログ監視部、
６０…ログ保管ストレージ、
７０…構成保管ストレージ、７１…イメージ、７２…構成情報、
８０…接続情報ＤＢ

Claims (2)

1. クラウドコンピューティング環境上に仮想サーバによって情報処理システムを構築するための基盤運用管理システムであって、
   前記仮想サーバが起動された後に適用されるソフトウェアおよび設定情報を含む構成情報を保管する仮想ストレージからなる構成保管ストレージを有し、
   前記仮想サーバの一部は、前記クラウドコンピューティング環境におけるオートスケール機能により一定の台数が維持されるよう自動的に運用されるグループとして構成され、
   オートスケール機能の対象外である他の仮想サーバのいずれかにも前記構成情報を保持し、
   前記グループに含まれる前記各仮想サーバは、ＯＳおよび構成管理部を少なくとも含む必要最小限のシステム構成からなるイメージファイルに基づいて起動され、
   前記構成管理部は、前記構成保管ストレージから当該仮想サーバに対応する前記構成情報を取得し、もしくは前記構成保管ストレージから前記構成情報を取得できない場合は前記構成情報を保持する前記他の仮想サーバから前記構成情報を取得し、前記構成情報に基づいてソフトウェアのセットアップおよび設定変更を含む処理を実行して当該仮想サーバを構築する、基盤運用管理システム。
2. クラウドコンピューティング環境上に仮想サーバによって情報処理システムを構築するための基盤運用管理方法であって、
   前記クラウドコンピューティング環境におけるオートスケール機能により、ＯＳおよび構成管理に係る処理を実行するモジュールを少なくとも含む必要最小限のシステム構成からなるイメージファイルに基づいて、前記仮想サーバを起動する工程と、
   前記仮想サーバが、起動後に適用されるソフトウェアおよび設定情報を含む構成情報を保管する仮想ストレージから前記構成情報を取得し、もしくは前記仮想ストレージから前記構成情報を取得できない場合は前記構成情報を別に保持しているオートスケール機能の対象外である他の仮想サーバから前記構成情報を取得する工程と、
   前記仮想サーバが、前記構成情報に基づいてソフトウェアのセットアップおよび設定変更を含む処理を実行して当該仮想サーバを構築する工程と、
   を有する、基盤運用管理方法。

Images