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

Abstract

【課題】クラウド環境上で、オートスケール機能により自動的に台数が増減する仮想サーバによって構築される情報処理システムにおいて、ログの消失を回避してこれを監視可能とする。【解決手段】クラウド基盤１０上に仮想サーバによって情報処理システムを構築するための基盤運用管理システムであって、フロントエンドサーバ２０は、クラウド基盤１０におけるオートスケール機能により一定の台数が維持されるよう自動的に運用されるグループとして構成され、フロントエンドサーバ２０は、当該フロントエンドサーバ２０に係るログのうち、リアルタイム監視が必要な所定のものについては、オートスケール機能の対象外であるバッチサーバ５０に対して転送し、その他のものについては、仮想ストレージからなるログ保管ストレージ６０に転送するログ収集部２３を有する。【選択図】図６

Description

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

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

クラウド環境上で構築される情報処理システムは、Ｗｅｂシステム等、インターネットなどを介して大量のリクエストを受け付けるものが多いことから、通常は、同様の処理を行う仮想サーバを複数台並列に設けてクラスタとし、クラスタ内のサーバに対してロードバランサによりリクエストを振り分けることにより負荷分散が行われる。このとき、これらのクラウドサービスに特有のいわゆるオートスケール機能を利用して、サーバの負荷の増減等に応じてクラスタ内のサーバ台数を適宜増減（スケールアウト／スケールイン）したり、障害等によるサーバの停止に対して同数のサーバを追加起動して一定台数を維持したり等の運用を自動的に行うことができる。

これに関連する技術として、例えば、特開２０１２−２０８７８１号公報（特許文献１）には、複数の処理サーバを含む処理サーバ群と、処理サーバ群に代替して応答するための代替サーバと、処理サーバ群にトラフィックを分散するとともに、処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサとを含み、さらに、ロードバランサにより処理サーバ群へ転送される転送量と代替サーバへ転送される転送量とに応じて、処理サーバ群の目標規模を演算し、処理サーバ群の現在の規模から目標規模へ増強するため処理サーバ群の処理サーバを準備することで、クラウド環境において、需要変化に応答してサーバ規模を増減させるオートスケーリング機構を実現する技術が記載されている。

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

オートスケール機能により仮想サーバについて一定の稼働台数が維持される構成では、起動される仮想サーバに対して割り当てられるＩＰアドレスが不定となることから、例えば、情報処理システムの運用監視の仕組みにおいて、監視サーバ等の独立したサーバからＩＰアドレスにより監視対象を特定して監視するような一般的な監視システムは適さず、運用監視の仕組みの構築に考慮を要する。また、運用監視のために、各仮想サーバにおいて出力されたログファイルや各仮想サーバ単位での監視結果の情報（以下ではこれらを単に「ログ」と総称する場合がある）などを参照しようとしても、オートスケール機能により各仮想サーバは自動的に停止・起動されるため、監視目的や、システム監査等の目的のために保存しておくべきログが消失してしまうという課題を有する。

また、オートスケール機能により自動的に起動・停止されるとともに、仮想サーバに割り当てられるＩＰアドレスが不定であることから、例えば、複数種類の仮想サーバ間で相互に接続してトランザクション処理を行うような構成とする場合、ある仮想サーバについて接続先のサーバとして予め固定のサーバを設定しておくことが困難であり、動的に接続を構成した結果、仮想サーバ間の接続において一部のサーバに接続が集中するという状況が生じ得るという課題も有する。

そこで本発明の目的は、クラウド環境上で、オートスケール機能により自動的に台数が増減する仮想サーバによって構築される情報処理システムにおいて、ログの消失を回避してこれを監視可能とする基盤運用管理システムおよび基盤運用管理方法を提供することにある。また、本発明の他の目的は、オートスケール機能により自動的に台数が増減する仮想サーバ間での接続構成を管理することを可能とする。

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

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

本発明の代表的な実施の形態による基盤運用管理システムは、クラウドコンピューティング環境上に仮想サーバによって情報処理システムを構築するための基盤運用管理システムであって、前記仮想サーバの一部は、前記クラウドコンピューティング環境におけるオートスケール機能により一定の台数が維持されるよう自動的に運用されるグループとして構成され、前記グループに含まれる前記各仮想サーバは、当該仮想サーバに係るログのうち、リアルタイム監視が必要な所定のものについては、オートスケール機能の対象外である他の仮想サーバに対して転送し、その他のものについては、仮想ストレージからなるログ保管ストレージに転送するログ収集部を有するものである。

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

すなわち、本発明の代表的な実施の形態によれば、クラウド環境上で、オートスケール機能により自動的に台数が増減する仮想サーバによって構築される情報処理システムにおいて、ログの消失を回避してこれを監視することが可能となる。また、オートスケール機能により自動的に台数が増減する仮想サーバ間での接続構成を管理することが可能となる。

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

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

本発明の一実施の形態である基盤運用管理システムは、クラウド環境上にオートスケール機能により自動的に台数が増減する仮想サーバによって情報処理システムを構築する際の基盤システムとして機能する。各仮想サーバ単位での稼働状況の監視結果に係るイベントや、各仮想サーバが出力したログのうち、リアルタイムでの監視、ログ解析が必要なものについては、オートスケール機能の対象外のサーバに一元的に集約し、当該サーバ上でリアルタイムでの監視、解析処理を行う。また、ログのうちシステム監査等のために一定期間保管しておく必要があるものについては、クラウド環境上の仮想ストレージに退避させ、もしくはバックアップする。

これにより、オートスケール機能によるサーバの停止・起動によるログの消失を防いで、ＩＰアドレスが不定な仮想サーバに対しても効率的に監視、解析を行うことを可能とするとともに、クラウド環境の機能を利用して効率的なログ保管の運用を行うことが可能である。

また、本実施の形態では、クラウド環境上の仮想データベースにサーバ間の接続情報を保持し、これを参照可能とすることで、サーバ間の接続構成を動的に管理する。これにより、例えば、仮想サーバ間の接続において、一部のサーバに接続が集中しないように分散させるなどの制御を行うことが可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (9)

1. クラウドコンピューティング環境上に仮想サーバによって情報処理システムを構築するための基盤運用管理システムであって、
   前記仮想サーバの一部は、前記クラウドコンピューティング環境におけるオートスケール機能により一定の台数が維持されるよう自動的に運用されるグループとして構成され、
   前記グループに含まれる仮想サーバであるオートスケール仮想サーバは、当該オートスケール仮想サーバに係るログのうち、リアルタイム監視が必要な所定のものについては、オートスケール機能の対象外の仮想サーバである非オートスケール仮想サーバに対して転送し、その他のものについては、仮想ストレージからなるログ保管ストレージに転送するログ収集部を有する、基盤運用管理システム。
2. 請求項１に記載の基盤運用管理システムにおいて、
   前記非オートスケール仮想サーバは、前記各オートスケール仮想サーバから転送されたログ、および当該非オートスケール仮想サーバに係るログの内容をリアルタイムで監視もしくは解析するログ監視部を有する、基盤運用管理システム。
3. 請求項２に記載の基盤運用管理システムにおいて、
   前記非オートスケール仮想サーバの前記ログ収集部は、当該非オートスケール仮想サーバにおいて集約されたログを前記ログ保管ストレージに転送する、基盤運用管理システム。
4. 請求項１〜３のいずれか１項に記載の基盤運用管理システムにおいて、
   前記各オートスケール仮想サーバは、当該オートスケール仮想サーバにおける前記ログ収集部の稼働状況を監視し、異常を検知した場合には、当該異常に係るログを、前記クラウドコンピューティング環境における転送機能を介して前記非オートスケール仮想サーバに対して転送する、基盤運用管理システム。
5. 請求項１〜４のいずれか１項に記載の基盤運用管理システムにおいて、
   前記非オートスケール仮想サーバは、前記クラウドコンピューティング環境により検知された前記各オートスケール仮想サーバについての異常に係るログを、前記クラウドコンピューティング環境における転送機能を介して取得する、基盤運用管理システム。
6. 請求項１〜５のいずれか１項に記載の基盤運用管理システムにおいて、
   前記グループに含まれる前記各オートスケール仮想サーバに対して生死状態をチェックするヘルスチェックに係る処理を行うロードバランサを有し、
   前記各オートスケール仮想サーバは、前記ロードバランサからの定期的なヘルスチェックの要求に対して、当該オートスケール仮想サーバの稼働状況に応じて生死の情報を応答するヘルスチェック部を有する、基盤運用管理システム。
7. 請求項１〜６のいずれか１項に記載の基盤運用管理システムにおいて、
   複数の前記グループを有し、第１のグループに含まれる第１のオートスケール仮想サーバが他の第２のグループに含まれる第２のオートスケール仮想サーバとの間で相互に接続する構成を有し、
   前記第２のオートスケール仮想サーバに対して接続する前記第１のオートスケール仮想サーバの台数を示す接続数の情報を含む、前記第１のオートスケール仮想サーバと前記第２のオートスケール仮想サーバとの間の接続に係る情報を保持する仮想データベースからなる接続情報データベースを有し、
   前記第１のオートスケール仮想サーバは、起動後、前記接続情報データベースを参照し、前記接続数が最も少ない前記第２のオートスケール仮想サーバに対して接続する、基盤運用管理システム。
8. クラウドコンピューティング環境上に仮想サーバによって情報処理システムを構築するための基盤運用管理方法であって、
   前記クラウドコンピューティング環境におけるオートスケール機能により一定の台数が維持されるよう自動的に運用されるグループに含まれる仮想サーバであるオートスケール仮想サーバが、当該オートスケール仮想サーバに係るログのうち、リアルタイム監視が必要な所定のものについては、オートスケール機能の対象外の仮想サーバである非オートスケール仮想サーバに対して転送し、その他のものについては、仮想ストレージからなるログ保管ストレージに転送する工程と、
   前記非オートスケール仮想サーバが、前記各オートスケール仮想サーバから転送されたログ、および当該非オートスケール仮想サーバに係るログの内容をリアルタイムで監視もしくは解析する工程と、
   を有する、基盤運用管理方法。
9. 請求項８に記載の基盤運用管理方法において、
   さらに、第１のグループに含まれる第１のオートスケール仮想サーバから接続される、第２のグループに含まれる第２のオートスケール仮想サーバが、起動後、前記第２のオートスケール仮想サーバに対して接続する前記第１のオートスケール仮想サーバの台数を示す接続数の情報を含む、前記第１のオートスケール仮想サーバと前記第２のオートスケール仮想サーバとの間の接続に係る情報を保持する仮想データベースからなる接続情報データベースに、当該第２のオートスケール仮想サーバの情報を記録する工程と、
   前記第１のオートスケール仮想サーバが、起動後、前記接続情報データベースに記録された、前記第２のオートスケール仮想サーバ毎の前記接続数の情報を参照する工程と、
   前記第１のオートスケール仮想サーバが、前記接続数が最も少ない前記第２のオートスケール仮想サーバを接続先として選択し、接続する工程と、
   前記第１のオートスケール仮想サーバが、前記接続情報データベースにおける、接続した前記第２のオートスケール仮想サーバに係る前記接続数の値を更新する工程と、
   を有する、基盤運用管理方法。

Images