JP2011113268A - クラウドファサード管理システム - Google Patents

Abstract

【課題】クラウド環境での仮想的なデータセンターを含む複数のデータセンターの連携によって運営されるシステムにおいて、ユーザからの処理要求を適切なデータセンターにて処理するように制御することが可能なクラウドファサード管理システムを提供する。
【解決手段】各データセンターにおける各サーバの稼働状況に係る情報を定期もしくは不定期に収集して稼働状況ＤＢ１１１に保持する稼働状況取得部１１０と、各データセンターにおける各サーバのシステム構成および処理能力に係る情報を取得して構成情報ＤＢ１２１に保持する構成管理部１２０と、処理要求を受け、稼働状況ＤＢ１１１および構成情報ＤＢ１２１に保持された情報に基づいて、処理要求を振り分けるデータセンターもしくはデータセンター内のサーバを選択し、選択したデータセンターもしくはデータセンター内のサーバに処理要求を振り分ける処理振分部１３０とを有する。
【選択図】図１

Description

本発明は、コンピュータシステムによりサービスを提供するデータセンターに係る技術に関し、特に、クラウドコンピューティングにより仮想化されたデータセンターを含む複数のデータセンターの連携によって運営されるシステムに対する窓口となるクラウドファサード管理システムに適用して有効な技術に関するものである。

コンピュータシステムによりインターネット等を介してユーザに種々のサービスを提供する際に、サービスの提供に係る多数のサーバやストレージなどの機器を集約して運用・管理するデータセンターが利用される場合が多くなっている。通常、データセンターでは、多数の機器について、人手や運用管理ソフトなどを利用して、ファイルの受け渡しやＯＳ（Operating System）のコマンド実行、アプリケーションの起動・設定など、非常に複雑な手順やツールを利用して運用が行われている。

一方、近年ではクラウドコンピューティング技術の進化により、例えば、“Ａｍａｚｏｎ ＥＣ２（登録商標）”（非特許文献１）などのように、データセンター自体を物理的な施設や設備を意識せずに仮想的に扱うことができるようになっている。このようなデータセンターでは、ユーザは、ＡＰＩ（Application Programming Interface）やこれを用いたコマンドを利用して、インスタンス（ＯＳなどを含む仮想サーバ）の起動や増設を行うことができる。データセンターに対するアクセスがＡＰＩ化されることにより、これをソフトウェアプログラムから利用することで、従来のデータセンターでは困難であった各サーバ間での連携などを伴う運用や制御を高度に自動化できる可能性がある。

"Amazon Elastic Compute Cloud (Amazon EC2)"、[online]、Amazon Web Services LLC、インターネット＜URL:http://aws.amazon.com/ec2/＞

コンピュータシステムによって一連のサービスを提供する際に、自社のデータセンターを利用するケースに加えて、“Ａｍａｚｏｎ ＥＣ２”のようなクラウド技術による仮想的なデータセンターを利用するケースは今後増えてくるものと考えられる。また、これらを連携させてシステムを運営するようなケースも出てくると考えられる。このようなケースでは、１社の仮想的なデータセンターだけで完結するケースは少ないと考えられ、複数の仮想的なデータセンターおよびこれらと自社データセンターとを連携して運営する必要が出てくる。

ここで、クラウド技術による仮想的なデータセンターでは、ユーザは、主に起動しているインスタンスの数と利用時間によって課金される。従って、必要なときのみインスタンスを起動することができれば低コストとなるため、連携に際しては、自社のデータセンターの資産を有効活用し、自社のデータセンターで処理しきれない分のみクラウドによる仮想的なデータセンターを利用するほうが低コスト化を考えた場合には望ましい。

一方、処理効率を考えた場合には、処理能力が高い、もしくは処理能力に余裕があるサーバやデータセンターを利用するほうが望ましい。しかしながら、このような制御について、例えば、サービスの利用者が処理を要求する際に指定等を行うということは難しく、また、システムの管理者や運用担当者が人手で行うという場合にもかなりのコストを要する。

そこで本発明の目的は、クラウド環境での仮想的なデータセンターを含む複数のデータセンターの連携によって運営されるシステムにおいて、ユーザからの処理要求を適切なデータセンターにて処理するように制御することが可能なクラウドファサード管理システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

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

本発明の代表的な実施の形態によるクラウドファサード管理システムは、クラウド環境におけるプログラミングインタフェースを有する仮想データセンターを含む、複数のデータセンターの連携によって運営されるシステムに対する処理要求を受けて、前記データセンターもしくは前記データセンター内のサーバを選択して前記処理要求を振り分けるクラウドファサード管理システムであって以下の特徴を有するものである。

すなわち、クラウドファサード管理システムは、前記各データセンターにおける各サーバの稼働状況に係る情報を定期もしくは不定期に収集して稼働状況データベースに保持する稼働状況取得部と、前記各データセンターにおける各サーバのシステム構成および処理能力に係る情報を取得して構成情報データベースに保持する構成管理部と、前記処理要求を受け、前記稼働状況データベースおよび前記構成情報データベースに保持された情報に基づいて、前記処理要求を振り分ける前記データセンターもしくは前記データセンター内のサーバを選択し、選択した前記データセンターもしくは前記データセンター内のサーバに前記処理要求を振り分ける処理振分部とを有することを特徴とするものである。

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

本発明の代表的な実施の形態によれば、クラウド環境での仮想的なデータセンターを含む複数のデータセンターについて、各サーバの稼働状況や構成情報、処理能力に関する情報、料金体系などの情報を取得して保持し、処理要求を受けた際にこれを参照することで、処理要求に対して処理効率やコストの観点から適切なデータセンターもしくはサーバを選択して処理を振り分ける制御をユーザ等の利用側に意識させずに自動で行うことが可能となり、複数のデータセンターを連携させて効果的なシステムの運営を行うことが可能となる。

本発明の一実施の形態であるクラウドファサード管理システムの構成例の概要を示した図である。 本発明の一実施の形態における稼働状況ＤＢのデータ構成と具体的なデータの例について示した図である。 本発明の一実施の形態における構成情報ＤＢのデータ構成と具体的なデータの例について示した図である。 本発明の一実施の形態における通常時の処理の例について概要を示した図である。 本発明の一実施の形態における振り分け処理の例について概要を示した図である。 本発明の一実施の形態における振り分け処理の別の例について概要を示した図である。 本発明の一実施の形態における振り分け処理の別の例について概要を示した図である。 本発明の一実施の形態における振り分け処理の別の例について概要を示した図である。 本発明の一実施の形態における振り分け処理の別の例について概要を示した図である。 本発明の一実施の形態における振り分け処理の別の例について概要を示した図である。

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

本発明の一実施の形態であるクラウドファサード管理システムは、上述した“Ａｍａｚｏｎ ＥＣ２”のようなＡＰＩを有するクラウド環境での仮想的なデータセンターを含む複数のデータセンターに対して、ユーザ等の利用側からの処理要求を受ける窓口（いわゆるデザインパターンにおけるFacadeパターンに類似の機能を有する）となり、処理効率やコストの観点から適切なデータセンターもしくはサーバを選択して処理を振り分ける制御を行うことが可能な仕組みを有するシステムである。

本実施の形態のクラウドファサード管理システムは、通常時には定期もしくは不定期に自社データセンターやクラウド環境での仮想的なデータセンターにおける各サーバに関する稼働状況や構成等についての情報を収集し保持している。

ユーザ等からの処理要求に対して、例えば、期間的に余裕がある場合には、自社データセンターに優先的に処理を振り分けることでコストを削減する。一方、迅速な処理が必要な場合には、稼働状況や構成等の情報に基づいて、必要に応じて仮想的なデータセンターにおいてインスタンスを起動して追加し、処理を振り分ける。また、クラウド環境での仮想的なデータセンターにおけるサーバの構成や料金体系を把握しておくことで、処理要求の内容に応じて処理効率（処理速度）やコスト（料金）の観点から適切なサーバに処理を振り分ける。

ここで、例えば“Ａｍａｚｏｎ ＥＣ２”では、インスタンス（仮想サーバ）の構成イメージであるＡＭＩ（Amazon Machine Image）を、クラウド環境でのストレージサービスである“Ａｍａｚｏｎ Ｓ３”の仮想ストレージに保持することができる。また、“Ａｍａｚｏｎ Ｓ３”に保持されているＡＭＩから所望のものを選択し、選択したＡＭＩを利用して“Ａｍａｚｏｎ ＥＣ２”上でインスタンスを起動することができる。“Ａｍａｚｏｎ ＥＣ２”では、このようなインスタンス管理（インスタンスの起動・停止、リソース管理）やストレージ管理を行ったり、クライアント端末から問い合わせを行ったりするためのいわゆるＷｅｂ ＡＰＩが提供されている。

このようなＡＰＩを利用することで、クラウド環境での仮想的なデータセンターにおいて、インスタンスの起動・停止やリソース管理などの運用を、プログラミングの技術を適用して自動化することが可能である。すなわち、クラウドファサード管理システムにおいてこれらのＡＰＩを利用することで上記の運用を自動的に行うことが可能となる。

［システム構成］
図１は、本発明の一実施の形態であるクラウドファサード管理システムの構成例の概要を示した図である。クラウドファサード管理システム１００は、サーバやＰＣ（Personal Computer）等のコンピュータシステムによって構成され、インターネット等を介して“Ａｍａｚｏｎ ＥＣ２”等のクラウド環境での複数の仮想データセンター２１０にアクセスすることができるシステムである。また、自社データセンター２００にアクセス可能な構成であってもよい。なお、自社データセンター２００とは、一般的なデータセンターとしての固定的な設備を備えた実データセンターであり、自社で運用・管理を行うものである。

クラウドファサード管理システム１００は、例えば、ソフトウェアプログラムによって実装される稼働状況取得部１１０、構成管理部１２０、および処理振分部１３０の各部と、稼働状況ＤＢ１１１、および構成情報ＤＢ１２１の各データベースを有する。

稼働状況取得部１１０は、自社データセンター２００や仮想データセンター２１０における各サーバの現在の稼働状況に係る情報を定期もしくは不定期に収集して、稼働状況ＤＢ１１１に保持する機能を有する。稼働状況に係る情報の収集に際しては、仮想データセンター２１０が提供するＡＰＩを利用したり（例えばＣＰＵ（Central Processing Unit）使用率など）、自社データセンター２００や仮想データセンター２１０内のサーバ上で動作する稼働状況取得用のソフトウェアプログラム等と連携して情報（例えばサービスの処理件数の実績情報など）を取得したりすることができる。

構成管理部１２０は、自社データセンター２００や仮想データセンター２１０における各サーバの構成に係る情報を取得して、構成情報ＤＢ１２１に保持する機能を有する。また、仮想データセンター２１０について必要に応じてサーバ（インスタンス）の起動・停止を行い、サーバの数を調整する機能も有する。

構成に係る情報の取得に際しては、管理者や運用担当者等により予め設定しておいたり、仮想データセンター２１０が提供するＡＰＩを利用して取得したりすることができる。また、自社データセンター２００や仮想データセンター２１０内のサーバ上で動作する構成取得用のソフトウェアプログラムやコマンド等を利用して問い合わせたりすることができる。なお、構成に係る情報には、例えば、サーバのシステム構成（スペック）に関する情報や、処理能力、サービス等の種別などが含まれる。また、仮想データセンター２１０のサーバについては、料金体系の情報も含まれる。

処理振分部１３０は、ユーザ等の利用側からの自社データセンター２００や仮想データセンター２１０に対する処理要求を受け付け、稼働状況ＤＢ１１１や構成情報ＤＢ１２１の情報を参照して、処理要求をいずれのデータセンター、もしくはデータセンター内のサーバに振り分けるかを選択して振り分ける機能を有する。振り分ける処理の詳細については後述する。

なお、図１の例では、処理要求をクライアント端末３００から受ける構成となっているが、処理要求は、例えば、ユーザがクライアント端末３００上の図示しないＷｅｂブラウザを利用したＷｅｂアプリケーションに対するオンラインでの処理要求であってもよいし、バッチ処理用のデータファイル等をアップロードしてバッチ処理の要求を行う形態であってもよい。また、クライアント端末３００に限らず、別のＷｅｂサーバやアプリケーションサーバ等から連携する形で処理要求を受ける構成であってもよい。

［データ構成］
図２は、本実施の形態のクラウドファサード管理システム１００における稼働状況ＤＢ１１１のデータ構成と具体的なデータの例について示した図である。稼働状況ＤＢ１１１は、自社データセンター２００や仮想データセンター２１０における各サーバの現在の稼働状況に係る情報を保持するデータベースであり、例えば、サーバＩＤ、所属、稼働状態、ＣＰＵ使用率、処理件数、スタックなどの各項目を有する。

サーバＩＤの項目は、稼働中の各サーバを一意に識別するＩＤの情報を保持する。サーバＩＤについては、例えば、ホスト名やＩＰアドレス等、各サーバを一意に識別することが可能な情報であればこれを利用することもできる。所属の項目は、各サーバが属するデータセンター（自社データセンター２００や仮想データセンター２１０）を特定する情報を保持する。

稼働状態の項目は、各サーバが、例えば「待機中」であるか「処理中」であるか、すなわち、各サーバが空き状態であるか否かのステータスの情報を保持する。この稼働状態は、例えば、後述するＣＰＵ使用率や処理件数などの項目の値から判断することができるため、稼働状態の項目を有さず、これらの項目の値から直接判断するようにしてもよい。

ＣＰＵ使用率の項目は、各サーバの処理状況に関する情報として、ＣＰＵの使用率の情報を保持する。ここでは、例えば、仮想データセンター２１０が提供するＡＰＩ等を利用して取得した値、もしくはそれらの所定の時間範囲での平均値などを利用することができる。

また、処理件数の項目は、各サーバの処理状況に関する情報として、サービスに係る処理の単位時間あたりの実際の処理件数の情報を保持する。図２の例では、処理件数としてＴｒａｎ／ｓｅｃ（Transaction/sec：アプリケーションサーバやＤＢサーバによる１秒あたりの処理件数）の指標を用いているが、これに限らず他の指標（例えばＷｅｂサーバの場合はＰＶ／ｓｅｃ（Page View/sec：Ｗｅｂサーバによる１秒あたりの画面表示の回数）など）を用いてもよい。また処理件数に替え、もしくは処理件数に加えて、例えば、ＴＡＴ（Turn Around Time）の平均値等の他の指標を項目として有していてもよい。

また、スタックの項目は、データセンターの処理状況に関する情報として、現時点でのバッチ処理の依頼に係る処理スタックの情報を保持する。図２の例ではサーバ“Ｂ００１”に処理スタックの情報が保持されているが、これはサーバ毎の処理スタックではなく当該サーバが属するデータセンターについての処理スタックを示している（例えば、データセンターにおいて当該サーバが代表となって処理スタックを保持し、各サーバは当該サーバの処理スタックから処理要求を取り出して処理する）。なお、図２に示すように処理スタックの情報として処理要求毎の個別の件数情報を保持する必要はなく、処理スタック全体での処理要求の合計件数のみを保持するようにしてもよい。

上記のＣＰＵ使用率や処理件数、スタックなどの情報に基づいて、処理振分部１３０では各サーバやデータセンターが処理余力を有しているか（空き状態にあるか）否かを判断することができる。例えば、ＣＰＵ使用率や処理件数の値が一定期間以上所定の閾値以下である場合には当該サーバは“待機中”（空き状態）であると判断することができる。また、当該判断結果に基づいて稼働状態の項目の値を設定・更新するようにしてもよい。

図３は、本実施の形態のクラウドファサード管理システム１００における構成情報ＤＢ１２１のデータ構成と具体的なデータの例について示した図である。構成情報ＤＢ１２１は、自社データセンター２００や仮想データセンター２１０における各サーバの構成に係る情報を保持するデータベースであり、例えば、サーバＩＤ、所属、種別、サービス、構成、処理能力、料金などの各項目を有する。

サーバＩＤおよび所属の項目は、図２に示した稼働状況ＤＢ１１１のものと同様である。種別の項目は、各サーバの種別（例えば、ＷｅｂサーバやＤＢサーバ、アプリケーションサーバなど）の情報を保持する。また、サービスの項目は、各サーバが処理可能なサービス（アプリケーションやバッチ処理など）の種類についての情報を保持する。これらの情報に基づいて、処理振分部１３０では処理要求をいずれのサーバが処理することができるかを判断することができる。

構成の項目は、各サーバのシステム構成（スペック）の情報を保持する。ここでは、例えば、ＣＰＵやメモリなどのスペック、ＯＳや各種ミドルウェアの種類やバージョンなどの情報を保持する。また、処理能力の項目は、各サーバの処理能力（キャパシティ）の情報を保持する。ここでは、例えば、各サーバが処理可能なスループット（例えば、Ｔｒａｎ／ｓｅｃ）などの情報を保持する。処理能力の値については、例えば、各サーバについて別途測定しておいた値を保持してもよいし、各サーバから定期的に現在の実績値を取得して保持するようにしてもよい。これらの情報に基づいて、処理振分部１３０では各サーバの性能やその優劣を判断することができる。

料金の項目は、仮想データセンター２１０における各サーバの料金体系の情報を保持する。図３の例では、サーバ（インスタンス）毎に１日単位で課金される料金体系を示しているが、例えば、時間単位や月単位での課金であったり、サーバ（インスタンス）の数によるボリュームディスカウントなどの付帯条件を有していたりする場合もある。これらの情報についても料金の項目に保持することができるものとする。この料金の項目の情報に基づいて、処理振分部１３０ではいずれのサーバに処理要求を振り分けた場合にコストが最小になるかを判断することができる。

構成情報ＤＢ１２１には、現在稼働中の各サーバの情報に限らず、仮想データセンター２１０における起動していないサーバ（インスタンス）の情報を保持するようにしてもよい。この情報を参照することにより、構成管理部１２０は、例えば、自社データセンター２００で処理しきれない処理要求を振り分けるための、仮想データセンター２１０において追加で起動するサーバ（インスタンス）の数等を決定することができる。

なお、図２に示した稼働状況ＤＢ１１１、および図３に示した構成情報ＤＢ１２１の例における各項目はあくまで一例であり、これらと同等の情報を有する項目や、これら以外の他の項目を有していてもよいことは当然である。

［振り分け処理］
図４は、本実施の形態のクラウドファサード管理システム１００における通常時の処理の例について概要を示した図である。通常時は、クラウドファサード管理システム１００は、自社データセンター２００や仮想データセンター２１０についての稼働状況に係る情報や構成に係る情報を収集して把握している。

上述したように、稼働状況取得部１１０は、自社データセンター２００や仮想データセンター２１０において起動中の各サーバについての稼働状態や、ＣＰＵ使用率、処理件数、スタック件数などの処理状況の情報を、定期もしくは不定期に収集して、稼働状況ＤＢ１１１に保持する。

また、構成管理部１２０は、自社データセンター２００や仮想データセンター２１０の各サーバについてのシステム構成や種別、処理能力などの情報を、予めもしくは定期・不定期に取得して、構成情報ＤＢ１２１に保持しておく。また、仮想データセンター２１０の各サーバ（インスタンス）については、各サーバの料金体系についても予めもしくは定期・不定期に取得して、構成情報ＤＢ１２１に保持しておく。起動中の各サーバについては処理能力の実績値を定期もしくは不定期に収集して構成情報ＤＢ１２１に保持してもよい。

図５は、本実施の形態のクラウドファサード管理システム１００における振り分け処理の例について概要を示した図である。図５の例では、クラウドファサード管理システム１００は、“依頼Ｚ”として１億件のバッチ処理を７日以内で処理するよう要求を受けていることを示している。

ここで、低コスト化を図るためには、自社データセンター２００の資産を最大限に有効活用し、自社データセンター２００で処理しきれない分のみ仮想データセンター２１０を利用するようにしたほうがよい。図５の例では、処理要求が７日以内と期間的に余裕があるため、自社データセンター２００を優先的に活用するよう、処理振分部１３０は、“依頼Ｚ”を全て自社データセンター２００に振り分ける。すなわち、“依頼Ｚ”は自社データセンター２００の処理スタックに積まれる（処理スタックに空きがある）。

なお、「期間的に余裕がある」か否かの判断は、例えば、自社データセンター２００の処理スタックに積まれている処理要求の件数とサーバの処理能力などに基づいて、処理要求を期間内に処理することが可能か否かを推測することによって、「期間的に余裕がある」か否かを判断することができる。また、例えば、期限が「××日」以上であれば余裕があるというような一律の判断基準とすることもできる。

図６は、本実施の形態のクラウドファサード管理システム１００における振り分け処理の別の例について概要を示した図である。図６の例では、クラウドファサード管理システム１００は、“依頼Ｚ”として１億件のバッチ処理を１日以内で処理するよう要求を受けていることを示している。

図６の例では、処理要求が１日以内と迅速に処理する必要があり、期間的に余裕がないため（期間内に自社データセンター２００では処理しきれない）、自社データセンター２００だけではなく必要に応じて仮想データセンター２１０を利用する。このとき、自社データセンター２００の処理スタックに積まれている処理要求の合計件数と、自社データセンター２００の各サーバの処理能力や処理状況の実績などを考慮して、処理振分部１３０は、自社データセンター２００に振り分ける件数と、仮想データセンター２１０に振り分ける件数とを判断する。図６の例では、自社データセンター２００に１０００万件、仮想データセンター２１０に９０００万件を振り分けることを示している。

また、仮想データセンター２１０に振り分ける処理要求について、処理振分部１３０は、構成管理部１２０に指示して、処理のための期間や要求件数、各仮想データセンター２１０における各サーバの処理能力などに基づいて、振り分ける仮想データセンター２１０、および起動するサーバ（インスタンス）数やスペックを決定して仮想データセンター２１０が提供するＡＰＩを利用してサーバ（インスタンス）を起動させ、起動したサーバに対して処理要求を振り分ける。

図７は、本実施の形態のクラウドファサード管理システム１００における振り分け処理の別の例について概要を示した図である。図７の例では、クラウドファサード管理システム１００は、“依頼Ｙ”として１億件のバッチ処理を７日以内で処理するよう要求を受け、さらに“依頼Ｚ”として１億件のバッチ処理を１日以内で処理するよう要求を受けていることを示している。また、自社データセンター２００に処理余力がなく（処理スタックに空きがない等）、全ての処理要求を仮想データセンター２１０に振り分ける場合の例を示している。

図７の例では、“依頼Ｙ”については、処理要求が７日以内と期間的に余裕があるため、単価の安い仮想データセンターＡ（２１０ａ）に振り分け、“依頼Ｚ”については、処理要求が１日以内と迅速に処理する必要があるため、処理効率を考慮して、単価は高いものの高い性能を有する仮想データセンターＢ（２１０ｂ）に振り分けることを示している。

ここで、仮想データセンターＡ（２１０ａ）については、ＣＰＵ１ＧＨｚあたりの単価（１＄／日）が仮想データセンターＢ（２１０ｂ）の単価（３．３３＄／日）よりも安いため、期間的に余裕がある処理要求については低コスト（料金）となるほうを優先して仮想データセンターＡ（２１０ａ）に振り分ける判断をしている。なお、ここではＣＰＵ１ＧＨｚあたりの単価によって判断しているが、これに限らず、最終的に課金される料金を推測できる指標であれば他の指標によって判断してもよい。

このように、各仮想データセンター２１０および各サーバの料金体系や構成（スペック）を把握しておくことで、処理要求に応じて、課金料金が安くなるクラウドや迅速な処理が可能なクラウドなど、複数のクラウドにおいて適切なクラウドに処理を振り分けることができる。また、クラウド単位での振り分けに限らず、クラウド内の複数のサーバについても、課金料金が安くなるサーバや迅速な処理が可能なサーバなど、適切なサーバに処理を振り分けることができる。

図８は、本実施の形態のクラウドファサード管理システム１００における振り分け処理の別の例について概要を示した図である。図８の例では、クラウドファサード管理システム１００は、“依頼Ｚ”として１億件のバッチ処理を７日以内で処理するよう要求を受けていることを示している。なお、図８以降の例では、処理要求を各データセンターの処理スタックに積むのではなく、処理スタックを介さずに直接各サーバに対して処理要求を行う場合の例を示している。従って、ここではバッチ処理の処理要求を受けた場合の例を示しているが、リアルタイム処理についても適用することができる。

ここで、自社データセンター２００のサーバに空きがある（“待機中”のサーバがある）場合は、自社データセンター２００の資産を最大限に有効活用して低コスト化を図るため、処理振分部１３０は、自社データセンター２００のサーバに優先的に処理を振り分ける。なお、サーバに空きがあるか否かについては、稼働状況ＤＢ１１１の稼働状態の項目、もしくはＣＰＵ使用率や処理件数などの項目から、各サーバが“処理中”であるか“待機中”であるかによって把握することができる。

図９は、本実施の形態のクラウドファサード管理システム１００における振り分け処理の別の例について概要を示した図である。図９の例では、クラウドファサード管理システム１００は、図８の例と同様に、“依頼Ｚ”として１億件のバッチ処理を７日以内で処理するよう要求を受けていることを示している。

ここで、自社データセンター２００のサーバに空きがない（“待機中”のサーバがない）場合は、必要に応じて仮想データセンター２１０を利用する。このとき、図６の例と同様に、処理振分部１３０は、構成管理部１２０に指示して、処理のための期間や要求件数、仮想データセンター２１０における各サーバの処理能力などに基づいて、起動するサーバ数やスペックを決定して仮想データセンター２１０が提供するＡＰＩを利用してサーバ（インスタンス）を起動させ、起動したサーバに対して処理要求を振り分ける。

図１０は、本実施の形態のクラウドファサード管理システム１００における振り分け処理の別の例について概要を示した図である。図１０の例では、仮想データセンター２１０において空き状態である（“待機中”である）サーバ（インスタンス）は、コスト削減の観点から速やかに停止させることを示している。例えば、稼働状況取得部１１０は、稼働状況ＤＢ１１１において稼働状態が一定期間以上“待機中”となっているサーバについては、構成管理部１２０に指示して当該サーバ（インスタンス）を停止させる。

なお、上記の図４〜図１０に示した例では、処理要求の形式が「××件の処理を××日以内に」というものであったが、他の形式の処理要求であっても対応することが可能である。例えば、「××のスペックを有するサーバ××台を使用して処理して欲しい」というような要求形式の場合は、処理振分部１３０によって、要求スペックを満たすサーバで空き状態にあるものの数を取得し、不足する場合は仮想データセンター２１０に対して必要な数のサーバ（インスタンス）を起動した上で処理を振り分けるということが可能である。

以上に説明したように、本発明の一実施の形態であるクラウドファサード管理システム１００によれば、クラウド環境での仮想データセンター２１０を含む複数のデータセンターに対して、ユーザからの処理要求を受ける窓口となり、各サーバの稼働状況や、構成情報、処理能力に関する情報、料金体系などの情報を取得して保持し、処理要求を受けた際にこれを参照することで、処理効率やコストの観点から適切なデータセンターもしくはサーバを選択して処理を振り分ける制御をユーザ等の利用側に意識させずに自動で行うことが可能となる。

また、処理要求を振り分ける際に、自社データセンター２００を優先させ、自社データセンター２００で処理しきれない場合に、必要に応じて仮想データセンター２１０においてサーバ（インスタンス）を追加で起動し、また、不要となった場合にサーバ（インスタンス）を停止することでさらなる低コスト化を図ることが可能となる。これらにより、複数のデータセンターを連携させて効果的なシステムの運営を行うことが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、クラウドコンピューティングにより仮想化されたデータセンターを含む複数のデータセンターの連携によって運営されるシステムに対する窓口となるクラウドファサード管理システムに利用可能である。

１００…クラウドファサード管理システム、１１０…稼働状況取得部、１１１…稼働状況ＤＢ、１２０…構成管理部、１２１…構成情報ＤＢ、１３０…処理振分部、
２００…自社データセンター、２１０…仮想データセンター、２１０ａ…仮想データセンターＡ、２１０ｂ…仮想データセンターｂ、
３００…クライアント端末。

Claims (10)

1. クラウド環境におけるプログラミングインタフェースを有する仮想データセンターを含む、複数のデータセンターの連携によって運営されるシステムに対する処理要求を受けて、前記データセンターもしくは前記データセンター内のサーバを選択して前記処理要求を振り分けるクラウドファサード管理システムであって、
   前記各データセンターにおける各サーバの稼働状況に係る情報を定期もしくは不定期に収集して稼働状況データベースに保持する稼働状況取得部と、
   前記各データセンターにおける各サーバのシステム構成および処理能力に係る情報を取得して構成情報データベースに保持する構成管理部と、
   前記処理要求を受け、前記稼働状況データベースおよび前記構成情報データベースに保持された情報に基づいて、前記処理要求を振り分ける前記データセンターもしくは前記データセンター内のサーバを選択し、選択した前記データセンターもしくは前記データセンター内のサーバに前記処理要求を振り分ける処理振分部とを有することを特徴とするクラウドファサード管理システム。
2. 請求項１に記載のクラウドファサード管理システムにおいて、
   複数の前記データセンターの連携によって運営される前記システムには、前記システムの運営主体が運用する固定的な設備を有する実データセンターを含み、
   前記処理振分部は、前記処理要求を振り分ける際に、前記実データセンター内の各サーバについての前記稼働状況データベースに保持された前記稼働状況に係る情報に基づいて、前記実データセンターおよび前記実データセンター内のサーバに空きがあると判断した場合には、前記実データセンターもしくは前記実データセンター内のサーバに優先的に前記処理要求を振り分けることを特徴とするクラウドファサード管理システム。
3. 請求項２に記載のクラウドファサード管理システムにおいて、
   前記処理振分部は、前記処理要求を振り分ける際に、前記実データセンター内の各サーバについての前記稼働状況データベースに保持された前記稼働状況に係る情報に基づいて、前記実データセンターおよび前記実データセンター内のサーバに空きがないと判断した場合には、前記仮想データセンターもしくは前記仮想データセンター内のサーバに前記処理要求を振り分けることを特徴とするクラウドファサード管理システム。
4. 請求項２に記載のクラウドファサード管理システムにおいて、
   前記処理振分部は、前記処理要求を振り分ける際に、前記実データセンター内の各サーバについての前記稼働状況データベースに保持された前記稼働状況に係る情報、および前記構成情報データベースに保持された前記処理能力に係る情報に基づいて、前記実データセンターおよび前記実データセンター内のサーバによっては前記処理要求を要求された期間内に処理しきれないと判断した場合には、前記仮想データセンターもしくは前記仮想データセンター内のサーバに前記処理要求の全部または一部を振り分けることを特徴とするクラウドファサード管理システム。
5. 請求項４に記載のクラウドファサード管理システムにおいて、
   前記処理振分部は、前記仮想データセンターもしくは前記仮想データセンター内のサーバに前記処理要求の一部を振り分ける際に、前記実データセンター内の各サーバについての前記稼働状況データベースに保持された前記稼働状況に係る情報、および前記構成情報データベースに保持された前記処理能力に係る情報に基づいて、前記実データセンターもしくは前記実データセンター内のサーバに振り分ける前記処理要求の件数を取得し、残余の前記処理要求を前記仮想データセンターもしくは前記仮想データセンター内のサーバに振り分けることを特徴とするクラウドファサード管理システム。
6. 請求項１〜５のいずれか１項記載のクラウドファサード管理システムにおいて、
   前記処理振分部が、前記仮想データセンターもしくは前記仮想データセンター内のサーバに前記処理要求の全部もしくは一部を振り分ける際に、
   前記構成管理部は、前記仮想データセンターにおいて必要な数のサーバを起動することを特徴とするクラウドファサード管理システム。
7. 請求項６に記載のクラウドファサード管理システムにおいて、
   前記構成管理部は、前記仮想データセンターにおいて必要な数のサーバを起動する際に、前記仮想データセンター内のサーバについての前記構成情報データベースに保持された前記システム構成に係る情報に基づいて、前記処理要求を要求された期間内に処理するために必要なサーバおよびその数を判断することを特徴とするクラウドファサード管理システム。
8. 請求項１〜７のいずれか１項記載のクラウドファサード管理システムにおいて、
   前記構成管理部は、さらに、前記仮想データセンター内の各サーバについての料金体系に係る情報を取得して前記構成情報データベースに保持し、
   前記処理振分部は、複数の前記仮想データセンターもしくは複数の前記仮想データセンター内のサーバに前記処理要求の全部もしくは一部を振り分ける際に、前記各仮想データセンター内の各サーバについての前記構成情報データベースに保持された前記料金体系に係る情報に基づいて、課金料金が安くなる前記仮想データセンターのサーバに振り分けることを特徴とするクラウドファサード管理システム。
9. 請求項１〜７のいずれか１項記載のクラウドファサード管理システムにおいて、
   前記構成管理部は、さらに、前記仮想データセンター内の各サーバについての料金体系に係る情報を取得して前記構成情報データベースに保持し、
   前記処理振分部は、前記仮想データセンターもしくは前記仮想データセンター内のサーバに前記処理要求の全部もしくは一部を振り分ける際に、前記仮想データセンター内の各サーバについての前記構成情報データベースに保持された前記料金体系に係る情報に基づいて、課金料金が安くなるサーバに振り分けることを特徴とするクラウドファサード管理システム。
10. 請求項１〜９のいずれか１項記載のクラウドファサード管理システムにおいて、
    前記稼働状況管理部が、前記仮想データセンター内の各サーバについての前記稼働状況データベースに保持された前記稼働状況に係る情報に基づいて、前記仮想データセンター内に待機状態のサーバがあると判断した場合に、
    前記構成管理部は、前記待機状態にあるサーバを停止させることを特徴とするクラウドファサード管理システム。