JP6481299B2 - 監視装置、サーバ、監視システム、監視方法および監視プログラム - Google Patents

Description

本発明は、Ｗｅｂシステムにおいて、蓄積された情報に基づいてオートスケーリングを実施する技術に関する。

近年、クラウド・コンピューティング技術を用いたシステムモデルの構築が増えてきている。このようなシステムは、大多数のサーバマシンから構成され、また、それらのサーバを構成するアプリケーション層は、互いに同じ構成を取ることが多い。

昨今のＷｅｂシステムにおいては、Ｗｅｂアプリケーションサーバの負荷が高まると、関連するパラメータをチューニングしたり、あるいは、それを契機としてシステムのスケールアウトを実施したりすることが一般的である。

Ｗｅｂアプリケーションサーバの負荷が高まる要因は様々である。例えば、予め見積もったリクエスト量を超えたリクエストがＷｅｂアプリケーションサーバに同時に要求された場合、Ｗｅｂアプリケーションサーバの負荷が高まる。このような場合、チューニング不足が負荷の高まりの原因であるので、関連するパラメータをチューニングすることで対処できる。

しかしながら、ショッピングサイトや動画投稿サイト、オークションサイトなどのように、世間の注目度とコンテンツの関連性が深く、それに伴う負荷の増減が発生すると、その傾向を予測しない限り、負荷の増減に柔軟に対処することは困難である。

また、その予測には、専門的あるいは熟練した分析スキルに加え、多大な労力を要するので、その実現は現実的ではない。

このような予測が難しい負荷に対処する分散システムにおける一般的なアプローチとして、システムのスケールアウト／スケールインの手法がある。この手法では、Ｗｅｂアプリケーションサーバや、それが動作するマシンの負荷状況を測定し、予め定めた閾値を超えた負荷が検出された際に、監視システムが自動的にＷｅｂアプリケーションサーバの稼働数を増減させる。

しかしながら、上記手法では、最近の主流となりつつあるクラウドサービス型のシステムにおいては、運用面で以下の課題が生じる。すなわち、（１）閾値監視によるオートスケーリングの限界、（２）サーバマシンのウォームアップ期間の考慮不足、である。

以下、上記（１）および（２）について、具体的に説明する。（１）に関して、クラウドサービス型のシステムでは、大抵の場合、従量課金制を採用しているので、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やメモリなどマシンリソースの消費量に応じて費用が生じる。ここで、上述したような閾値監視によるスケールイン／スケールアウトを実施する場合、リクエスト量の増減が激しいシステムにおいては、サーバマシンの追加／削除が頻繁に実施されるので、マシンリソースの消費が激しくなる可能性が高い。よって、マシンリソースの消費量の増大に伴い、費用も増大してしまう。

（２）に関して、クラウドサービスでのスケールアウトにおけるサーバマシンの追加処理は、メジャーなサービスにおいても俊敏ではない場合が多い。すなわち、サーバマシンの追加処理は、サーバの起動処理に伴い一定のウォームアップ期間（システム構成に応じて数分〜数十分）を必要する。

この期間サーバマシンは本来の処理性能を発揮できないので、当該期間は、オートスケーリングに伴う判断ロス時間ともみなすことができる。そのため、サーバ負荷の検知を契機にオートスケーリングを実施していると、システムは、突発的な負荷の上昇に対処しきれないことになり得る。一方で、常に想定される最大のサーバマシン数でシステムを稼働し続けていると、余剰なシステムリソースに対する課金が発生してしまう。

これらの課題に対して、特許文献１は、過去に収集した負荷情報から複数のクラスタシステム間で負荷変動の類似度を導出し、収集した負荷情報からスケールアウトの必要性を判断する手法を開示する。

また、特許文献２は、アクセスログを読み込み、時刻や曜日などの統計的な手法で必要なサーバ台数を予測してサーバの運用計画を作成する手法を開示する。

特開２０１１−０９０５９４号公報 特開２００５−１４１４４１号公報

上記特許文献１に開示される手法では、負荷変動が時刻と因果関係を持つ場合には有効であるが、Ｗｅｂコンテンツに含まれる人気商品に関するキーワードや、閲覧数が多い特定のストリーミング動画など、コンテンツと負荷変動との関係性は考慮されない。したがって、例えば世の中の流行や注目度を起因とする負荷変動には、本手法では柔軟に対処できないという課題がある。加えて、上述したサーバの起動処理に伴うウォームアップ期間も考慮されていない。

また、上記特許文献２に開示される手法も、上記と同様に、コンテンツと負荷変動との関係性や、サーバの起動処理に伴うウォームアップ期間は考慮されていない。

本願発明は、上記課題を鑑みてなされたものであり、コンテンツと負荷変動との関係性を考慮したサーバ負荷の制御を実施可能な監視装置等を提供することを主要な目的とする。

本発明の第１の監視装置は、クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバを監視する監視装置であって、前記サーバから収集した、前記リクエストに関連するアクセス情報と前記リクエストを解析した結果であるリクエスト解析結果に基づいて、注目情報または時刻情報に応じたサーバ負荷の制御を実施する運用計画を作成する運用計画手段と、前記注目情報または前記時刻情報が、前記運用計画に含まれる実行条件を満たした場合、当該運用計画に基づいて前記サーバ負荷の制御を実施する制御手段とを備える。

本発明の第１のサーバは、クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信するサーバであって、前記リクエストを解析した結果であるリクエスト解析結果から注目情報を抽出し、前記リクエストに関連するアクセス情報に基づいて、前記注目情報に対する注目度を算出する統計手段と、ネットワークを介して自サーバを監視する監視装置に、前記統計手段が算出した前記注目情報に対する注目度を送信する送信手段とを備える。

本発明の第１の監視システムは、クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバと、当該サーバを監視する監視装置とを備えた監視システムであって、前記サーバは、前記リクエストを解析した結果であるリクエスト解析結果から注目情報を抽出し、前記リクエストに関連するアクセス情報に基づいて、前記注目情報に対する注目度を算出する統計手段と、前記監視装置に、前記統計手段が算出した前記注目情報に対する注目度を送信する送信手段とを備え、前記監視装置は、前記サーバから収集した、前記アクセス情報と前記リクエスト解析結果に基づいて、注目情報または時刻情報に応じたサーバ負荷の制御を実施する運用計画を作成する運用計画手段と、前記注目情報または前記時刻情報が、前記運用計画に含まれる実行条件を満たした場合、当該運用計画に基づいて前記サーバ負荷の制御を実施する制御手段とを備える。

本発明の第１の監視方法は、クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバを監視する監視方法であって、前記サーバから収集した、前記リクエストに関連するアクセス情報と前記リクエストを解析した結果であるリクエスト解析結果に基づいて、注目情報または時刻情報に応じたサーバ負荷の制御を実施する運用計画を作成し、前記注目情報または前記時刻情報が、前記運用計画に含まれる実行条件を満たした場合、当該運用計画に基づいて前記サーバ負荷の制御を実施する。

なお同目的は、上記の各構成を有する監視方法を、コンピュータによって実現するコンピュータ・プログラム、およびそのコンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記憶媒体によっても達成される。

本願発明によれば、コンテンツと負荷変動との関係性を考慮したサーバ負荷の制御を実施できるという効果が得られる。

本発明の第１の実施形態に係る情報処理システムの構成を示す図である。 本発明の第１の実施形態に係る情報処理システムが備えるサーバマシンとシステム監視装置の詳細な構成を示すブロック図である。 本発明の第１の実施形態に係るサーバマシンのアプリケーションサーバにおけるリクエスト受信の動作を示すフローチャートである。 本発明の第１の実施形態に係るサーバマシンのアプリケーションサーバにおけるリクエストデータを解析する動作を示すフローチャートである。 本発明の第１の実施形態に係るシステム監視装置が運用条件を生成する動作を示すフローチャートである。 本発明の第１の実施形態に係るシステム監視装置が運用条件生成の際に相関関係を導出する動作を示すフローチャートである。 本発明の第１の実施形態に係るシステム監視装置が生成する運用条件の一例を示す図である。 本発明の第１の実施形態に係るアプリケーションサーバが生成する監視情報の一例を示す図である。 本発明の第１の実施形態に係るシステム監視装置によるスケーリングの要否を決定する動作を示すフローチャートである。 本発明の第１の実施形態に係るシステム監視装置によるスケーリングの要否を決定する動作を示すフローチャートである。 本発明の第２の実施形態に係る情報処理システムの構成を示す図である。 本発明の各実施形態に係る情報処理装置のハードウエア構成を例示する図である。

以下、本発明の実施形態について図面を参照して詳細に説明する。

第１の実施形態
図１は、本発明の第１の実施形態に係る情報処理システム１００の構成を示す図である。図１に示すように、情報処理システム１００は、サーバマシン２００、システム監視装置３００およびクライアント４００を備える。

サーバマシン２００は、業務用等のＷｅｂシステムを稼働し、ユーザが使用するクライアント４００からのアクセスを受け付ける。Ｗｅｂシステムは、複数のサーバマシン２００により構築される。サーバマシン２００は、物理サーバであっても、仮想サーバであってもよい。

システム監視装置３００は、複数のサーバマシン２００を統合的に監視する。システム監視装置３００は、インターネットに接続される。クライアント４００は、Ｗｅｂシステムを利用するブラウザ等のクライアントアプリケーションを搭載する。

図２は、図１に示したサーバマシン２００とシステム監視装置３００の詳細な構成を示すブロック図である。図２では、Ｗｅｂシステムを構築する複数のサーバマシン２００のうちの１つを示す。

図２に示すように、サーバマシン２００は、Ｗｅｂシステムで動作する各種アプリケーションの実行基盤となるアプリケーションサーバ２１０を搭載する。

アプリケーションサーバ２１０は、リクエスト受付部２１１、アプリケーション実行制御部２１２、統計データ出力部２１３、操作命令受付部２１４、監視情報転送部２１５および解析データ転送部２１６を備える。

サーバマシン２００は、また、記憶装置２２０を備える。

サーバマシン２００を監視するシステム監視装置３００は、図２に示すように、サーバマシン計測部３１０、事象予測部３２０、運用計画生成部３３０、運用実行制御部３４０、操作命令発行部３５０、解析データ収集部３６０および記憶装置３７０を備える。

次に、アプリケーションサーバ２１０の各構成要素の概略について説明する。

リクエスト受付部２１１は、クライアントアプリケーションを介して送られる、システム利用者からの要求（リクエスト）を受け付ける。アプリケーション実行制御部２１２は、リクエストに対応するアプリケーションロジックを実行する。統計データ出力部２１３は、アプリケーションサーバ２１０におけるリクエスト処理数などの実行情報をファイルに出力する。操作命令受付部２１４は、アプリケーションサーバ２１０に対する外部からの操作命令を受け付ける。

監視情報転送部２１５は、アプリケーションサーバ２１０内で監視中の情報を、外部からの操作命令の呼び出し結果に含める。解析データ転送部２１６は、アプリケーションサーバ２１０が出力したリクエストデータやアクセスログ、統計データなどを、外部からの操作命令の呼び出し結果に含める。

次に、アプリケーションサーバ２１０が備えるアプリケーション実行制御部２１２の構成について説明する。

アプリケーション実行制御部２１２は、リクエストデータ解析部２３１、リクエストデータ統計部２３２、アクセスログ出力部２３３および記憶部２３４を備える。

リクエストデータ解析部２３１は、システム利用者からのリクエストに含まれるパラメータ情報を解析する。リクエストデータ統計部２３２は、リクエストに含まれるパラメータ情報の統計を取る。アクセスログ出力部２３３は、リクエストに関連するアクセス情報（時刻、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）、実行結果など）をログファイルに出力する。記憶部２３４は、統計処理における各種データを記憶する。

記憶装置２２０は、アプリケーションサーバ２１０が出力したリクエストデータやアクセスログ、統計データなどを保存する。

次に、システム監視装置３００の各構成要素の概略について説明する。

サーバマシン計測部３１０は、サーバマシン２００の稼働数や起動処理にかかるウォームアップ（初期化）時間を計測する。事象予測部３２０は、サーバマシンのスケーリング条件を予測する。運用計画生成部３３０は、データ分析部３２２によって予測分析されたサーバマシンのスケーリング条件を基に、運用条件（運用計画）を定義する。運用実行制御部３４０は、運用計画生成部３３０が生成した運用条件に従って運用制御を実施する。

操作命令発行部３５０は、運用実行制御部３４０からの指示に応じて、サーバマシン２００内のアプリケーションサーバ２１０に対して操作命令を発行する。解析データ収集部３６０は、サーバマシン内のアプリケーションサーバ２１０が出力したリクエストデータやアクセスログ、統計データなどを収集する。記憶装置３７０は、解析データ収集部３６０が収集したデータや、運用計画生成部３３０が生成した運用条件を保存する。

次に、システム監視装置３００が備える事象予測部３２０の構成について説明する。事象予測部３２０は、データ解析部３２１、データ分析部３２２および注目ワード収集部３２３を備える。

データ解析部３２１は、サーバマシン２００から収集したデータ構造を解析する。データ分析部３２２は、データ解析部３２１によって解析されたデータ構造を基に、将来のＷｅｂシステムにおける負荷状況と適切なサーバマシン数を予測分析する。注目ワード収集部３２３は、インターネットを介して、Ｇｏｏｇｌｅ（登録商標）などの主要な情報検索サイトから現在注目されている商品や人物などの注目ワードを収集する。

次に、運用実行制御部３４０について、具体的に説明する。運用実行制御部３４０は、サーバマシン制御部３４１および記憶部３４２を備える。サーバマシン制御部３４１は、運用条件に従ってサーバマシンを制御する。記憶部３４２は、制御に必要な一時的なデータを記憶する。

図３および図４は、サーバマシン２００のアプリケーションサーバ２１０におけるリクエスト受信の動作を示すフローチャートである。図３および図４を参照して、アプリケーションサーバ２１０におけるリクエスト受信の動作について説明する。

各サーバマシン２００において動作するアプリケーションサーバ２１０は、クライアント４００に搭載されるクライアントアプリケーションからのリクエストを、リクエスト受付部２１１において受信する。リクエスト受付部２１１は、受信したリクエストに含まれるリクエストパラメータ（以下、「リクエストデータ」とも称する）をアプリケーション実行制御部２１２に供給する。

アプリケーション実行制御部２１２は、リクエストパラメータに関連する業務処理を呼び出すと共に、それを実行する（Ｓ４１０）。業務処理の実行が正常に終了すると（Ｓ４２０においてＹｅｓ）、アプリケーション実行制御部２１２内のリクエストデータ解析部２３１は、リクエストデータを解析する（Ｓ４３０）。

具体的には、図４に示すように、リクエストデータ解析部２３１は、リクエストに対応するＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）コンテキストを抽出する（Ｓ４３１）。リクエストデータ解析部２３１は、リクエストデータにユーザパラメータが含まれる場合（Ｓ４３２においてＹｅｓ）、そのユーザパラメータ内のキーワードを抽出する（Ｓ４３３）。ユーザパラメータとは、例えば、通信プロトコルとしてＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）が使用される場合、”ＧＥＴ”や”ＰＯＳＴ”に含まれる任意のデータである。

ここで、抽出されたＵＲＬコンテキストやキーワードが記憶部２３４に格納されている場合（Ｓ４３４においてＹｅｓ）、リクエストデータ統計部２３２は、該当するカウンタをインクリメントする（Ｓ４３５）（詳細は後述する）。リクエストデータ統計部２３２は、解析した結果を記憶部２３４に格納する。

その後、図３に示すように、アプリケーション実行制御部２１２内のアクセスログ出力部２３３は、リクエストに関するアクセスログを、記憶装置２２０に格納する（Ｓ４４０）。そして、アプリケーション実行制御部２１２は、レスポンスデータをクライアントアプリケーションに返却する。

なお、リクエストデータの解析とアクセスログの出力は、性能面を考慮して必ずしも直列に実行される必要はなく、並列に実行されてもよい。また、本実施形態では、解析結果を記憶装置２２０に格納する際のフォーマットなどは限定せず、任意とする。

上記一連の処理が、リクエストごとに、アプリケーションサーバ２１０を動作するプロセス、またはそのスレッドにより実行される。

以上の処理が、Ｗｅｂシステム運用中に繰り返し発生することで、サーバマシン２００の記憶装置２２０に、リクエストデータを解析した解析データやアクセスログが蓄積されていく。

また、アプリケーションサーバ２１０は、内部を構成する機能に対するパフォーマンス情報として、統計データ出力部２１３により、統計データを定期的に記憶装置２２０に格納する。統計データは、プロセスのメモリ消費量や、クライアントからのリクエストを処理するワーカースレッド数などの計測データを含む。

次に、システム監視装置３００の動作について、図５および図６を参照して説明する。

まず、システム監視装置３００に関する前提事項について説明する。システム監視装置３００は、予めシステム運用者の運用作業によって、分散配置されたアプリケーションサーバ２１０の構成に関する情報を適切に管理している。また、システム監視装置３００は、管理下のサーバマシン２００と、その内部で動作するアプリケーションサーバ２１０に対して、ネットワークを介して、必要となる操作命令を指示できる。

また、システム監視装置３００が備える記憶装置３７０には、次の情報が予め格納されているか、システム運用者が格納する。すなわち、過去の業務システムの稼働実績を含むアクセスログ、統計データ、サーバマシン数の推移を識別できるデータ、およびオートスケーリングのための典型的な初期運用計画である。初期運用計画とは、例えば、「ＣＰＵ使用率が所定値を超えたらスケールアウトを実施する」等の運用条件に関する定義である。

さらに、システム監視装置３００内のサーバマシン計測部３１０は、管理対象のサーバマシン２００の稼働台数や、各サーバマシン２００の起動処理にかかる時間を計測する。これらの情報は、記憶装置３７０に格納されているものとする。

上記を前提事項として、システム監視装置３００が運用条件を生成する動作について、図５および図６を参照して説明する。

システム監視装置３００の解析データ収集部３６０は、予めシステム運用者によって設定されたタイミング（例えば１時間ごと）で、操作命令を操作命令発行部３５０に発行する。操作命令とは、各サーバマシン２００から、リクエストデータの解析データ、統計データ、およびアクセスログを収集する命令である。

上記操作命令は、各サーバマシン２００のアプリケーションサーバ２１０内の操作命令受付部２１４により受信される。操作命令受付部２１４は、解析データ転送部２１６に操作命令を転送する。解析データ転送部２１６は、記憶装置２２０から、アプリケーションサーバ２１０によって生成されたリクエストデータの解析データ、統計データ、およびアクセスログを収集し、システム監視装置３００に解析データを返却する（Ｓ５１０）。システム監視装置３００は、受け取った解析データを、記憶装置３７０に格納する（Ｓ５２０）。システム監視装置３００は、Ｓ５１０とＳ５２０の処理を、サーバマシンの数分実行する（Ｓ５３０）。

上記実行の後、システム監視装置３００は、記憶装置３７０に格納された前回の分析結果を一旦削除する（Ｓ５４０）。

次に、システム監視装置３００の事象予測部３２０は、記憶装置３７０から解析対象のデータを読み出す。データ解析部３２１は、必要なデータを解析し、それをデータ分析部３２２に転送する。データ分析部３２２は、既存のデータ分析技術によって、データ間の相関関係を導出する（Ｓ５５０）。

図６は、事象予測部３２０が相関関係を導出する動作を示すフローチャートである。図６に示すように、まず、データ分析部３２２は、データ分析を実施する（Ｓ５５１）。データ分析部３２２は、導出において、具体的には、まず次の観点から分析する。
・特定の期間に稼働するサーバマシン数の関係（例えば、平日、休日、特定日、特定曜日と、それらの期間に稼働するサーバマシン数との関係）
・特定のキーワードと、稼働するサーバマシン数との関係（例えば、「ＸＸＸ」というキーワードを含むと、サーバマシンがＸ台稼働する等）
・特定のＵＲＬコンテキストと稼働するサーバマシン数との関係（例えば、「jpn.nec.com/xxx/」というＵＲＬコンテキスト配下のＷｅｂページにアクセスが発生すると、サーバマシンがＸ台稼働する等）
なお、上記のような分析結果の導出手段については任意である。

次に、事象予測部３２０内の注目ワード収集部３２３は、インターネットを介して、Ｇｏｏｇｌｅ Ｔｒｅｎｄｓなどの情報検索サイトが提供するサービスや、関連するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用して、世の中の注目度が高いキーワード（注目ワード）を収集する（Ｓ５５２）。事象予測部３２０は、収集したキーワードに対して、上記の分析結果にまだ含まれていない注目ワードがある場合（Ｓ５５３においてＹｅｓ）、その注目ワードを分析結果の一部として追加する（Ｓ５５４）。事象予測部３２０は、Ｓ５５３とＳ５５４の処理を、収集したすべての注目ワードが分析結果に含まれるように実行する（Ｓ５５５）。

続いて、図５に示すように、データ分析部３２２によって得られた上記の分析結果を基に、システム監視装置３００内の運用計画生成部３３０は、順に図７に示すような運用条件を生成し（Ｓ５６０）、それを記憶装置３７０に格納する（Ｓ５７０）。

図７は、運用計画生成部３３０により生成された運用条件の一例を示す図である。図７に示すように、運用条件は、「スケーリングポリシー」、「カテゴリ」、「実行条件」、「キーワード」および「予測サーバ数」を含む。「スケーリングポリシー」は、スケーリング実施の指標を示し、例えば、時刻または注目度である。「カテゴリ」は、スケーリングポリシーの分類を示す情報であり、例えば、スケーリングポリシーが時刻の場合は平日、特定日等であり、スケーリングポリシーが注目度の場合はワード、ＵＲＬ等である。

「実行条件」は、スケーリング実施の条件（トリガ）であり、スケーリング実施の開始時刻や、ワードやＵＲＬに対するアクセス数（注目度）が上昇傾向にある等の条件である。「キーワード」は、コンテンツに関するキーとなる情報であり、例えば、日付に関する情報、コンテンツに含まれる文言、あるいはユーザリクエストにより指定されるＵＲＬ等の情報である。「予測サーバ数」は、上記各項目に含まれる条件を満たした状況において、必要となるサーバの数を、データ分析部３２２により予測された値である。データ分析部３２２は、アクセスログ等に基づいて、必要となるサーバ数を予測する。

運用計画生成部３３０は、データ分析部３２２によって得られたすべての分析結果から、上記のような運用条件を作成する（Ｓ５８０）。

さらに、特定のキーワードと稼働するサーバマシン数の関係が分析結果に含まれる場合（Ｓ５９０においてＹｅｓ）、操作命令発行部３５０は、各サーバマシン２００に対して、以下の操作命令を発行する（Ｓ５９１）。すなわち、操作命令発行部３５０は、各サーバマシン２００に対して、監視すべきキーワード情報をアプリケーションサーバ２１０内の記憶部２３４に含める操作命令を発行する。このとき、記憶部２３４には、図８に示すような監視情報が格納される。

図８は、監視情報の一例を示す図である。図８に示すように、監視情報は、「カテゴリ」、「キーワード」、「カウンタ（現在）」、「カウンタ（前回）」、「カウンタ（前々回）」を含む。「カテゴリ」と「キーワード」は、上述した運用条件に含まれる「カテゴリ」と「キーワード」と同様である。カウンタは、図８に示す監視情報に含まれるキーワードを含んでいるアクセスの数であり、現在、前回および前々回の監視タイミングにおけるアクセス数を保持する。

以上の処理により、システム監視装置３００は、運用条件を生成する。

次に、システム監視装置３００によるスケーリングの動作について説明する。

システム監視装置３００は、予めシステム運用者によって設定された定期的なタイミング（例えば１分間隔）で、運用実行制御部３４０において記憶装置３７０からそれぞれの運用条件を読み出し、それに基づいてスケーリング実施の要否とスケーリングの最適条件（必要サーバ数等）を決定する。このとき、運用実行制御部３４０は、記憶部３４２に、これから稼働すべきサーバマシンの数を意味する変数「必要サーバ数」を格納すると共に、その値を「１」で初期化しておく。

図９および図１０は、運用条件に基づくスケーリングの動作を示すフローチャートである。図９および図１０を参照して、スケーリングの動作について説明する。

運用実行制御部３４０は、最適条件を決定するにあたり、記憶装置３７０に格納された図７に示すような運用条件を順に調べる。まず、運用条件に含まれるスケーリングポリシー（ＳＰ）が「時刻」の場合（Ｓ６０１においてＹｅｓ）、運用実行制御部３４０は、現在の時刻が、運用条件に含まれる実行条件として指定された時刻に達したかどうかを調べる。より厳密には、運用実行制御部３４０は、上記指定された時刻に対して、サーバマシンの起動処理にかかるウォームアップ時間（起動時間）、およびこのスケーリングの最適条件を決定するための定期的な監視間隔を差し引いた時刻に達したかどうかを調べる。これは、業務が実行できるようになるまでのサーバマシンの準備期間を考慮するためである。

上記時刻に達している場合（Ｓ６０２においてＹｅｓ）、運用実行制御部３４０は、運用条件に含まれるカテゴリと、現在時刻が示すカテゴリとを比較して、両者が一致しているかを調べる。カテゴリが一致している場合（Ｓ６０３においてＹｅｓ）、サーバマシン計測部３１０によって得られた稼働中のサーバマシン数と、運用条件に含まれる予測サーバ数とを比較する。予測サーバ数が”０”より大きい場合（Ｓ６０４においてＹｅｓ）、運用実行制御部３４０は、さらに予測サーバ数と現在稼働中のサーバマシン数とを比較する。

予測サーバ数の方が大きい場合（Ｓ６０５においてＹｅｓ）、運用実行制御部３４０は、変数「必要サーバ数」を予測サーバ数で更新する（Ｓ６０６）。一方、予測サーバ数が”０”の場合（Ｓ６０４においてＮｏ）、運用実行制御部３４０は、変数「必要サーバ数」を、現在のサーバ数に１を加えた値で更新する（Ｓ６０７）。

一方、運用条件に含まれるスケーリングポリシーが、「時刻」でなく「注目度」の場合（Ｓ６０１においてＮｏ）、運用実行制御部３４０は、各サーバマシンからＵＲＬコンテキストまたはワードに対する監視情報を、以下のように取得する（Ｓ６０８）。

すなわち、運用実行制御部３４０は、監視情報を収集するため、操作命令発行部３５０に、監視情報を収集する操作命令の発行を要求する。操作命令発行部３５０は、監視情報を収集する操作命令を各サーバマシンに送信する。各サーバマシンは、操作命令受付部２１４において操作命令を受信し、監視情報転送部２１５に監視情報の転送を要求する。監視情報転送部２１５は、その要求に応じて、記憶部２３４から操作命令を読み出すと共に、読み出した監視情報を操作命令の返答に含める。操作命令受付部２１４は、監視情報を含む操作命令の返答を、システム監視装置３００に送信する。システム監視装置３００は、操作命令発行部３５０において上記返答を受信すると共に、それを運用実行制御部３４０に供給する。

運用実行制御部３４０は、取得した監視情報に基づいて、運用条件に含まれるキーワードを含んでいるアクセス数が、すべてのサーバマシンにおいて上昇していると判定した場合（Ｓ６０９においてＹｅｓ）、上記Ｓ６０４からＳ６０６と同様の処理により、変数「必要サーバ数」を更新する。

なお、運用実行制御部３４０は、アクセス数が上昇していることを、図８に示す監視情報に含まれる「カウンタ（現在）」、「カウンタ（前回）」、「カウンタ（前々回）」から得られる増加傾向に基づいて判断することを示したが、これに限らない。すなわち、運用実行制御部３４０は、例えば、二次関数を用いて上昇かどうかをチェックしてもよい。

運用実行制御部３４０は、上記Ｓ６０１からＳ６０９の処理を、記憶装置３７０に格納されるすべての運用条件に関して実行する（Ｓ６１０）。

続いて、変数「必要サーバ数」が、現在稼働中のサーバマシン数を超えている場合（Ｓ６１１においてＹｅｓ）、サーバマシン制御部３４１は、その差分となる数のサーバマシンを追加で起動するためのスケールアウト処理を実行する（Ｓ６１６）。一方、変数「必要サーバ数」が、現在稼働中のサーバマシン数以下である場合、運用実行制御部３４０は、さらに各サーバマシンの負荷状況を計測する（Ｓ６１２）。運用実行制御部３４０は、この負荷状況を、上述したオートスケーリングのための典型的な初期運用計画に含まれる条件に基づいて判断する。すなわち、運用実行制御部３４０は、サーバが初期運用計画に含まれる条件を満たした場合、高負荷であるとみなす。

運用実行制御部３４０は、高負荷であるとみなすサーバ数と、変数「必要サーバ数」から”１”を引いた値とを比較し、前者が大きい場合（Ｓ６１３においてＹｅｓ）、過去の稼働実績に沿わない突発的な負荷とみなして、実働に基づいてスケールアウト処理を実施する（Ｓ６１６）。一方、後者が大きい場合（Ｓ６１４においてＹｅｓ）、運用実行制御部３４０は、その差分となる数のサーバマシンを停止するためのスケールイン処理を実施する（Ｓ６１５）。

以上のように、本第１の実施形態によれば、システム監視装置３００は、ユーザリクエスト内に含むパラメータなどをリクエスト受付の際に解析し、それを用いてＷｅｂページの内容や特定のＷｅｂページと負荷変動との関係を導き出した結果に基づいて、オートスケーリングの実施計画を生成する。この構成を採用することにより、本第１の実施形態によれば、コンテンツと負荷変動との関係、すなわち、世間の流行や動向の変化を起因とした特定ページや特定サーバへの負荷の集中を考慮したスケーリングを実施できるという効果が得られる。

システム監視装置３００は、実施計画にしたがってスケーリングを実施しているので、本第１の実施形態によれば、スケーリングを自動化でき、ＳＩ（Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｏｎ）コストやメンテナンスコストを削減できるという効果が得られる。

また、システム監視装置３００は、事前にサーバマシンが使用可能になるまでのウォームアップ（初期化）時間を計測しておき、それを考慮して、スケールアウト処理を開始するように制御する。これにより、本第１の実施形態によれば、急速なアクセス増加のように、サーバの初期化時間に対するスケーリング処理の準備不足を発端とする性能劣化やアクセスエラーを防ぐことができる。したがって、サーバマシンの起動期間を起因とした高負荷によるシステム障害の発生を抑えられるという効果が得られる。

第２の実施形態
図１１は、本発明の第２の実施形態に係るシステム監視装置７００の構成を示す図である。図１１に示すように、監視装置７００は、運用計画部７１０および制御部７２０を備える。

監視装置７００は、クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバを監視する。

運用計画部７１０は、サーバから収集した、リクエストに関連するアクセス情報とリクエストを解析した結果であるリクエスト解析結果に基づいて、注目情報または時刻情報に応じたサーバ負荷の制御を実施する運用計画を作成する。

制御部７２０は、注目情報または時刻情報が、運用計画に含まれる実行条件を満たした場合、当該運用計画に基づいてサーバ負荷の制御を実施する。

運用計画部７１０は、上記第１の実施形態における運用計画作成部３３０に相当し、制御部７２０は、運用実行制御部３４０に相当する。

上記構成を採用することにより、本第２の実施形態によれば、コンテンツと負荷変動との関係性を考慮したサーバ負荷の制御を実施できるという効果が得られる。

なお、図２等に示したサーバマシンおよびシステム監視装置の各部は、図１２に例示するハードウエア資源において実現される。すなわち、図１２に示す構成は、ＣＰＵ１０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、外部接続インタフェース１３および記憶媒体１４を備える。ＣＰＵ１０は、ＲＯＭ１２または記憶媒体１４に記憶された各種ソフトウエア・プログラム（コンピュータ・プログラム）を、ＲＡＭ１１に読み出して実行することにより、サーバマシンおよびシステム監視装置の全体的な動作を司る。すなわち、上記各実施形態において、ＣＰＵ１０は、ＲＯＭ１２または記憶媒体１４を適宜参照しながら、サーバマシンおよびシステム監視装置が備える各機能（各部）を実行するソフトウエア・プログラムを実行する。

また、上述した各実施形態では、図２等に示したサーバマシンおよびシステム監視装置における各ブロックに示す機能を、図１２に示すＣＰＵ１０が実行する一例として、ソフトウエア・プログラムによって実現する場合について説明した。しかしながら、図２等に示した各ブロックに示す機能は、一部または全部を、ハードウエアとして実現してもよい。

また、各実施形態を例に説明した本発明は、サーバマシンおよびシステム監視装置に対して、上記説明した機能を実現可能なコンピュータ・プログラムを供給した後、そのコンピュータ・プログラムを、ＣＰＵ１０がＲＡＭ１１に読み出して実行することによって達成される。

また、係る供給されたコンピュータ・プログラムは、読み書き可能なメモリ（一時記憶媒体）またはハードディスク装置等のコンピュータ読み取り可能な記憶デバイスに格納すればよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムを表すコード或いは係るコンピュータ・プログラムを格納した記憶媒体によって構成されると捉えることができる。

本発明は、例えば、ショッピングサイト、動画サイト、オークションサイトのＷｅｂシステムを構築する情報処理システムに適用できる。

１０ ＣＰＵ
１１ ＲＡＭ
１２ ＲＯＭ
１３ 外部接続インタフェース
１４ 記憶媒体
１００ 情報処理システム
２００ サーバマシン
２１０ アプリケーションサーバ
２１１ リクエスト受付部
２１２ アプリケーション実行制御部
２１３ 統計データ出力部
２１４ 操作命令受付部
２１５ 監視情報転送部
２１６ 解析データ転送部
２２０ 記憶装置
２３１ リクエストデータ解析部
２３２ リクエストデータ統計部
２３３ アクセスログ出力部
２３４ 記憶部
３００ システム監視装置
３１０ サーバマシン計測部
３２０ 事象予測部
３２１ データ解析部
３２２ データ分析部
３２３ 注目ワード収集部
３３０ 運用計画生成部
３４０ 運用実行制御部
３４１ サーバマシン制御部
３４２ 記憶部
３５０ 操作命令発行部
３６０ 解析データ収集部
３７０ 記憶装置

Claims (9)

1. クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバを監視する監視装置であって、
   前記サーバから収集した、前記リクエストに関連するキーワードに対するアクセス数である注目度と前記リクエストを解析した結果であるリクエスト解析結果に基づいて、前記注目度に応じたサーバのスケールアウトの運用計画を作成する運用計画手段と、
   前記注目度が上昇した場合、当該運用計画に基づいて前記サーバにスケールアウトを実施させる制御手段と
   を備えた監視装置。
2. 前記運用計画手段は、前記注目度と前記リクエスト解析結果とに基づいて、前記キーワードと稼働中のサーバ数との関係を導出することにより、前記注目度に応じて必要となるサーバ数を予測し、その予測サーバ数を含む前記運用計画を作成する
   請求項１記載の監視装置。
3. 前記制御手段は、稼働中のサーバ数が、前記運用計画に含まれる予測サーバ数よりも少ない場合、前記サーバのスケールアウト処理を実施させる
   請求項２記載の監視装置。
4. 前記制御手段は、前記注目度の上昇を判定する
   請求項１ないし請求項３のいずれか１項記載の監視装置。
5. 前記運用計画手段は、ネットワークを介して情報検索サイトから収集された所定の条件を満たすワードに対する前記注目度に応じて前記運用計画を作成する
   請求項１ないし請求項４のいずれか１項記載の監視装置。
6. クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバと、当該サーバを監視し、前記サーバから収集した、前記リクエストに関連するキーワードに対するアクセス数である注目度と前記リクエストを解析した結果であるリクエスト解析結果に基づいて、前記注目度が上昇した場合、前記サーバのスケールアウトを実施させる監視装置とを有する監視システムにおけるサーバであって、
   前記リクエスト解析結果から前記キーワードを抽出し、前記アクセス数である注目度の統計を取る統計手段と、
   ネットワークを介して自サーバを監視する監視装置に、前記注目度を送信する送信手段と
   を備えたサーバ。
7. クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバと、当該サーバを監視する監視装置とを備えた監視システムであって、
   前記サーバは、
   前記リクエストを解析した結果であるリクエスト解析結果から前記リクエストに関連するキーワードを抽出し、前記キーワードに対するアクセス数である注目度の統計を取る統計手段と、
   前記監視装置に、前記注目度を送信する送信手段と
   を備え、
   前記監視装置は、
   前記サーバから収集した、前記注目度と前記リクエスト解析結果に基づいて、前記注目度に応じたサーバのスケールアウトの運用計画を作成する運用計画手段と、
   前記注目度が上昇した場合、当該運用計画に基づいて前記サーバのスケールアウトを実施させる制御手段と
   を備えた
   監視システム。
8. クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバを監視装置が監視する監視方法であって、
   前記監視装置が、
   前記サーバから収集した、前記リクエストに関連するキーワードに対するアクセス数である注目度と前記リクエストを解析した結果であるリクエスト解析結果に基づいて、前記注目度に応じたサーバのスケールアウトの運用計画を作成し、
   前記注目度が上昇した場合、当該運用計画に基づいて前記サーバのスケールアウトを実施させる
   監視方法。
9. クライアントからのリクエストに応じて処理を実行し、当該クライアントに応答を送信する１または複数のサーバを監視する監視プログラムであって、
   前記サーバから収集した、前記リクエストに関連するキーワードに対するアクセス数である注目度と前記リクエストを解析した結果であるリクエスト解析結果に基づいて、前記注目度に応じたサーバのスケールアウトの運用計画を作成する処理と、
   前記注目度が上昇した場合、当該運用計画に基づいて前記サーバのスケールアウトを実施させる処理と
   をコンピュータに実行させる監視プログラム。

Images