JP5833725B2 - 関係データ管理のための制御サービス - Google Patents

Description

本特許文書の開示の一部は、著作権保護の対象となる資料を含む。その著作権者は、いかなる者が、特許文書または特許開示を、それが特許事務所および商標事務所の特許ファイルまたは記録に現れるままに、複製することに対しても異議はないが、その他の場合、全ての著作権を留保する。

増加する数のアプリケーションおよびサービスが、インターネットなどのネットワークを通じて利用可能になるにつれて、増加する数のコンテンツ、アプリケーション、および／またはサービスプロバイダは、クラウドコンピューティングなどの技術を考慮するようになってきている。クラウドコンピューティングは、一般に、ウェブサービスなどのサービスを通して電子資源に対するアクセスを提供する手法であり、これらのサービスをサポートするために使用されるハードウェアおよび／またはソフトウェアは、任意の所与の時間にサービスの必要性を満たすために動的に拡張可能であるである。ユーザまたは顧客は、通常、クラウドを通した資源に対するアクセスのために賃貸する、リースする、またはその他の方法で支払うことになり、したがって、これらの資源に対するアクセスを提供するハードウェアおよび／またはソフトウェアを購入し維持する必要はない。

顧客がクラウド内のアプリケーションまたはサービスについてのコンピュータ能力を経時的に調整することを可能にする種々のサービスが開発されており、ウェブスケールコンピューティングを開発者にとってより容易にしている。ある場合には、ウェブサービスインタフェースが提供され、コンピューティング要件が変化するにつれて、能力を迅速にスケールアップまたスケールダウンするために、顧客が、新しいサーバインスタンスを取得するかまたはブートすることなどのコンピューティング能力を管理することを可能にする。

能力を調整することは、ネットワークにわたってまたは遠隔ロケーションから利用可能なアプリケーションについて有利でありうる。しばしば、これらのアプリケーションは、各アプリケーションによって使用される、少なくとも１つのデータストアまたは他のこうしたリポジトリホスティングデータに依存するか、または、それを利用することになる。アプリケーションまたはサービスについての処理能力は、これらのウェブサービスインタフェースを通して動的に調整されうるが、これらのアプリケーションが依存するデータリポジトリは、同じように調整することができない。通常、データ記憶部をプロビジョニングすることおよびスケーリングすることなどのタスクを実行することは、単調で時間のかかる手作業の手順であり、顧客は、構成情報および要件を、データベース管理者(database administrator)（ＤＢＡ）または同様なエキスパートユーザに提供して、構成が有効であるかどうかをデータベース管理者が判定できるようにしなければならない。その後、ＤＢＡは、通常、データリポジトリを有効にし、調整し、最適化しなければならない。顧客が、データ記憶容量を動的に調整するか、または、データリポジトリの他のこうした態様を管理するための容易な方法は存在しない。

本開示による種々の実施形態を、図面を参照して説明する。

種々の実施形態が実装されうる環境を示す図である。 種々の実施形態に従って使用されうる制御層およびデータ層の例示的な分離を示す図である。 一実施形態による、データ層で実施される動作を、制御層を通して要求する例示的なプロセスを示す図である。 一実施形態による、データ層における動作を監視し、自動的に実行する例示的なプロセスを示す図である。 一実施形態による、データ層内のホストと制御層内のワークフローサービスとの間の通信フローを示す図である。 一実施形態による、制御層のユーザインタフェースに送信される、データ層における動作に対する要求を生成するディスプレイの例を示す図である。

本開示の種々の実施形態によるシステムおよび方法は、電子環境内のデータ記憶の態様を管理する従来の手法において経験される上述のまた他の欠点の１つまたは複数を克服する可能性がある。特に、種々の実施形態は、データ環境またはデータ層の態様を制御するために使用されうる、別個の制御環境または制御層を提供する。制御層の機能は、１組のウェブサービスとして提供されることができ、制御層が仮想データベース管理者（ＤＢＡ）として働くことを可能にする。ユーザまたは顧客は、たとえば外部から見えるアプリケーションプログラミングインタフェース（ＡＰＩ）を通して制御層に要求を送信することができ、要求は、データストアまたはデータ記憶インスタンスを作成するか、削除するか、修正するか、拡張するか、またはその他の方法で修正する動作などの、データ層で実行される動作を確定するために解析されうる。制御層の監視要素もまた提供され得、データ層における構成要素の健全度またはステータスを監視し、また、データ層でとられる動作を自動的に確定しうる。状態情報は、データストアまたはデータ層の他のこうした構成要素に直接アクセスする必要なしで、制御層がタスクの実行を管理できるように、動作を実行するために必要な各タスクについて、データ層の構成要素に渡されうる。一旦プロビジョニングされると、ユーザは、データ層内のデータインスタンス（複数可）にネイティブアクセスすることができ、特定のインスタンスについてのＤＮＳ（ドメインネームシステム(domain name system)）アドレスまたは他のロケーション情報に対して既存のアプリケーション（ＭｙＳＱＬアプリケーションなど）を単に向けるだけでよい。ユーザが、ＭｙＳＱＬ、Ｏｒａｃｌｅ、または他のこうしたデータベース技術上で構築されるアプリケーションを使用し続けることができるため、クエリモデルまたは他のこうした機能の制限または修正は全く存在しない。

図１は、種々の実施形態による態様を実現する環境１００の例を示す。理解されるように、ウェブベース環境が説明のために使用されるが、異なる環境が、種々の実施形態を実現するために、必要に応じて使用されてもよい。示す環境１００は、試験または開発部分（またはサイド）と生産部分の両方を含む。生産部分は、電子クライアントデバイス１０２を含み、電子クライアントデバイス１０２は、適切なネットワーク１０４を通じて、要求、メッセージ、または情報を送信し受信し、デバイスのユーザに戻るように情報を伝達するように動作する任意の適切なデバイスを含みうる。こうしたクライアントデバイスの例は、パーソナルコンピュータ、携帯電話、手持ち式メッセージングデバイス、ラップトップコンピュータ、セットトップボックス、携帯情報端末、電子ブックリーダなどを含む。ネットワークは、イントラネット、インターネット、セルラーネットワーク、ローカルエリアネットワーク、または任意の他のこうしたネットワーク、あるいはその組合せを含む任意の適切なネットワークを含みうる。こうしたシステムのために使用される構成要素は、選択されるネットワークおよび／または環境のタイプに少なくとも部分的に依存しうる。こうしたネットワークを介した通信用のプロトコルおよび構成要素は、よく知られており、本明細書で詳細に論じない。ネットワークを通じた通信は、有線接続または無線接続およびその組合せによって使用可能にされうる。この例では、要求を受信し、受信に応答してコンテンツを供給するウェブサーバ１０６を環境が含むため、ネットワークはインターネットを含むが、他のネットワークの場合、同様な目的を果たす代替のデバイスが、当業者に明らかであるように使用されうる。

例証的な環境は、少なくとも１つのアプリケーションサーバ１０８およびデータストア１１０を含む。適切なデータストアからデータを取得することなどのタスクを実行するために相互作用しうる、鎖状に接続されるかまたはその他の方法で構成されてもよい、いくつかのアプリケーションサーバ、層、あるいは、他の要素、プロセス、または構成要素が存在しうることが理解されるべきである。本明細書で使用されるように、「データストア(data store)」用語は、データを記憶し、データにアクセスし、データを取出すことができる任意のデバイスまたはデバイスの組合せを指し、任意の標準環境、分散環境、またはクラスター化環境における、任意の組合せおよび任意の数のデータサーバ、データベース、データ記憶デバイス、およびデータ記憶媒体を含みうる。アプリケーションサーバは、クライアントデバイス用の１つまたは複数のアプリケーションの態様を実行するために必要に応じてデータストアと統合し、アプリケーション用の大多数のデータアクセスおよびビジネスロジックを処理するための任意の適切なハードウェアおよびソフトウェアを含みうる。アプリケーションサーバは、データストアと連携してアクセス制御サービスを提供し、ユーザに転送される、テキスト、グラフィクス、オーディオ、および／またはビデオなどのコンテンツを生成することができ、コンテンツは、この例では、ＨＴＭＬ、ＸＭＬ、または別の適切な構造化言語の形態でウェブサーバによってユーザに供給されうる。全ての要求および応答の処理ならびにクライアントデバイス１０２とアプリケーションサーバ１０８との間のコンテンツの送達は、ウェブサーバによって処理されうる。本明細書で論じる構造化コードが、本明細書の他の所で論じるように任意の適切なデバイスまたはホストマシン上で実行されうるため、ウェブサーバおよびアプリケーションサーバは、必要とされず、単に例となる構成要素であることが理解されるべきである。さらに、環境は、試験自動化フレームワークが、ユーザまたはアプリケーションが加入することができるサービスとして提供されうる方法でアーキテクチャを構築されうる。試験自動化フレームワークは、本明細書で論じる種々の試験パターンのうちの任意のパターンの実装形態として提供されうるが、本明細書で論じるかまたは提案されるように、種々の他の実装形態も使用されうる。

環境はまた、開発および／または試験サイドを含み、それは開発者、データ管理者、または試験者などのユーザがシステムにアクセスすることを可能にするユーザデバイス１１８を含む。ユーザデバイス１１８は、クライアントデバイス１０２に関して上述したような、任意の適切なデバイスまたはマシンでありうる。環境はまた、開発サーバ１２０を含み、開発サーバ１２０は、アプリケーションサーバ１０８と同様に機能するが、通常、コードが、たとえば、生産サイドで展開され実行され、外部ユーザにアクセス可能になる前に、開発および試験中にコードを実行(run)する。一部の実施形態では、アプリケーションサーバは、開発サーバとして機能することができ、別個の生産および試験記憶部は使用されなくてもよい。

データストア１１０は、いくつかの別個のデータテーブル、データベース、または他のデータ記憶メカニズム、および特定の態様に関連するデータを記憶する媒体を含みうる。たとえば、示すデータストアは、生産サイド用のコンテンツをサーブするために使用されうる、生産データ１１２およびユーザ情報１１６を記憶するメカニズムを含む。データストアは、試験データ１１４を記憶するメカニズムも含むことが示されており、試験データ１１４は試験サイド用にユーザ情報と共に使用されうる。ページ画像情報およびアクセス権情報などについて、データストアに記憶される必要がある可能性がある多くの他の態様が存在し得、必要に応じて先に挙げたメカニズムのうちの任意のメカニズムに、または、データストア１１０内のさらなるメカニズムに記憶されうることが理解されるべきである。データストア１１０は、アプリケーションサーバ１０８または開発サーバ１２０から命令を受信し、受信に応答してデータを取得するか、更新するか、またはその他の方法で処理するように、データストア１１０に関連するロジックを通して動作する。一例では、ユーザは、あるタイプのアイテムについて検索要求を送信しうる。この場合、データストアは、ユーザのアイデンティティを検証するためにユーザ情報にアクセスし得、また、そのタイプのアイテムに関する情報を取得するために、カタログ詳細情報にアクセスすることができる。情報は、その後、ユーザデバイス１０２上でブラウザを介してユーザが見ることができる、ウェブページ上にリストされる結果などの形態で、ユーザに返されうる。対象となる特定のアイテムについての情報は、ブラウザの専用ページまたはウィンドウで見ることができる。

各サーバは、通常、そのサーバの汎用管理およびオペレーション用の実行可能プログラム命令を提供するオペレーションシステムを含むことになり、また、通常、サーバのプロセッサによって実行されると、その意図される機能をサーバが実施することを可能にする命令を記憶するコンピュータ可読媒体を含むことになる。サーバのオペレーションシステムおよび汎用機能の適した実装態様は、知られているかまたは市販されており、特に本明細書の開示に照らして、当業者によって容易に実現される。

一実施形態の環境は、１つまたは複数のコンピュータネットワークあるいは直接接続を使用して、通信リンクを介して相互接続されるいくつかのコンピュータシステムおよび構成要素を利用する分散コンピューティング環境である。しかし、こうしたシステムは、図１に示すものに比べて、より少ないかまたはより多くの数の構成要素を有するシステムにおいて、同様にうまく動作しうることが当業者によって理解されるであろう。そのため、図１のシステム１００の説明は、開示の範囲に対して制限的であるのではなく、例証的な性質であるものとして考えられるべきである。

複数のホストが、コンテンツを提供すること、ユーザを認証すること、支払いトランザクションを実施することなどのタスクを実施するか、または、多数の他のこうしたタスクの任意のタスクを実施するために使用されてもよいｅマーケットプレイスなどの図１に示すような環境は、プロバイダにとって有用でありうる。これらのホストのいくつかは、同じ機能を提供するように構成されてもよく、一方、他のサーバは、少なくともいくつかの異なる機能を実施するように構成されてもよい。電子環境は、こうした場合、以下で詳細に論じる図２の構成２００に示すような、さらなる構成要素および／または他の配置構成を含む可能性がある。

一実施形態によるシステムおよび方法は、関係データベースサービス（「ＲＤＳ」）を提供し、ＲＤＳは、クラウド内で関係データセットを記憶すること、処理すること、および質問することなどのタスクをユーザが実施できるように、関係データベースを、開発者、顧客、または他の認可されたユーザが容易にかつ費用効果的に取得し構成することを可能にする。この例は、インターネット、ウェブサービス、およびインターネットベースの技術に関して論じられるが、種々の実施形態の態様が、電子環境においてネットワークを通じて利用可能なまたは提供される任意の適切なサービスと共に使用されうることが理解されるべきである。さらに、サービスは、本明細書で「関係データベースサービス(relational database service)」と呼ばれるが、こうしたサービスは、電子環境において任意の適切なタイプのデータリポジトリまたはデータ記憶部と共に使用されうることが理解されるべきである。ＲＤＳは、この例では、展開、アップグレード、パッチ管理、バックアップ、複製、フェールオーバー、容量管理、スケーリング、およびデータ管理の他のこうした態様の管理の複雑さを心配することなく、ユーザまたは顧客が関係データセットを容易に管理することを可能にする少なくとも１つのウェブサービスを含む。そのため、開発者は、データベースのインフラストラクチャを管理する複雑さを心配することなく、精緻なクラウドアプリケーションを自由に開発する。

ＲＤＳは、一実施形態では、データ記憶部の態様を管理するのに有用な構成要素（たとえば、ハードウェアまたはソフトウェア）を含む別個の「制御層(control plane)」を提供する。一実施形態では、１組のデータ管理アプリケーションプログラミングインタフェース（ＡＰＩ）または他のこうしたインタフェースが提供され、データ記憶部に関連するあるタスクを実施するために、ユーザまたは顧客がＲＤＳへのコールを行うことを可能にする。ユーザは、データリポジトリと通信するために、依然として直接インタフェースまたはＡＰＩを使用しうるが、データ記憶部を管理するかまたは同様なタスクを実施するために必要なときだけ、制御層のＲＤＳ固有ＡＰＩを使用することができる。

図２は、一実施形態に従って使用されうるＲＤＳの実現形態２００の例を示す。この例では、エンドユーザ用のコンピューティングデバイス２０２が、データ層２１０のデータリポジトリをプロビジョニングすることなどのタスクを実施するために、ネットワーク２０６を通して制御層２０８へのコールを行うことができることが示される。ユーザまたはアプリケーション２０４は、データ層２１０のインタフェースを通して、プロビジョニングされるリポジトリに直接アクセスしうる。１つのエンドユーザコンピューティングデバイスおよびアプリケーションが、説明のために使用されるが、任意の適切なユーザ、アプリケーション、サービス、デバイス、構成要素、または資源が、種々の実施形態において必要に応じて、制御層および／またはデータ層のインタフェース（複数可）にアクセスしうることが理解されるべきである。さらに、構成要素は、制御およびデータ「層(plane)」に分離されるが、これは、各機能を提供するために使用される少なくともいくつかの資源（たとえば、ハードウェアおよび／またはソフトウェア）の実際のまたは仮想の分離を指しうることが理解されるべきである。

制御層２０８は、この例では、本質的に、プロビジョニング、スケーリング、複製などのような制御および管理動作を処理するハードウェアおよびソフトウェアの仮想層である。制御層は、この実施形態では、ウェブサービス層２１２または階層を含み、それは、たとえばコンピュータ実行可能ソフトウェア、アプリケーションサーバ、または他のこうした構成要素と共に少なくとも１つのウェブサーバを含みうる。ウェブサービス層はまた、ネットワーク２０６からウェブサービスコールまたは要求を受信する１組のＡＰＩ２３２（または他のこうしたインタフェース）を含むことができ、ウェブサービス層は、ウェブサービスコールまたは要求を構文解析するかまたはその他の方法で解析して、そのコールにに対して動作するかまたはそのコールを処理するために必要とされるステップまたは動作を確定する。たとえば、データリポジトリを作成する要求を含むウェブサービスが受信される可能性がある。この例では、ウェブサービス層は、要求を構文解析して、作成されるデータリポジトリのタイプ、要求される記憶ボリューム、（もしあれば）要求されるハードウェアのタイプ、または他のこうした態様を確定しうる。要求についての情報は、後続の処理のために、管理（「Ａｄｍｉｎ」）データストア２２２、あるいは、他の適切な記憶ロケーションまたはジョブキューに書込まれうる。

ウェブサービス層は、一実施形態では、種々の制御層ＡＰＩを提供し、ＡＰＩ仕様に基づいて適切な応答を返しうるスケーラブルな組の顧客向きサーバを含む。ウェブサービス層はまた、一実施形態では顧客ＡＰＩを処理する、状態なし複製サーバからなる少なくとも１つのＡＰＩサービス層を含みうる。ウェブサービス層は、クレデンシャルに基づいてユーザを認証すること、ユーザを認可すること、ＡＰＩサーバに対する顧客要求を抑えること、ユーザ入力を確認すること、ならびに、要求および応答をマーシャリングするまたはアンマーシャリングすることなどのウェブサービスフロントエンド機能について責任を担いうる。ＡＰＩ層はまた、ＡＰＩコールに応答して、管理データストアから／にデータベース構成データを読み出し／書込むことについての責任を担いうる。多くの実施形態では、ウェブサービス層は、唯一の外部から見える要素、または、制御サービスの顧客に見えかつ制御サービスの顧客によってアクセス可能である唯一の構成要素であることになる。ウェブサービス層のサーバは、当技術分野で知られているように、状態なしでありかつ水平にスケーリングされうる。ＡＰＩサーバならびに永続的データストアは、たとえば、サーバが単一データセンター障害に対して強くなるように、ある領域内で複数のデータセンターにわたって分散されうる。

制御層は、この実施形態では、本明細書で「スイーパ(sweeper)」要素２１４と呼ばれるものを含む。スイーパ要素は、制御層の種々の構成要素をポーリングするか、または、未完了要求に応答して実行される任意のタスクをその他の方法で確定するように動作する任意の適切な構成要素でありうる。この例では、ウェブサービス層は、Ａｄｍｉｎデータストア２２２または同様なジョブキュー内に「データベース生成（create database）」要求のための命令または情報を発行してもよく、スイーパは、未完了ジョブがあるか、Ａｄｍｉｎデータストアを定期的にチェックすることができる。当業者に明らかになるように、ウェブサービス層が、ジョブが存在するという通知をスイーパに送出することなどの、種々の他の手法が使用されうる。スイーパ要素は、「データベース生成」要求をピックアップし、要求についての情報を使用して、その要求について少なくとも１つのワークフローをインスタンス化するように動作するワークフロー要素２１６に、要求、コール、または他のこうしたコマンドを送出しうる。ワークフローは、一実施形態では、本明細書の他の所で論じるワークフローサービスを使用して、生成され維持される。ワークフローは、一般に、特定のジョブを実施するために実行されるべきタスクのシーケンスである。ワークフローは、実際の仕事ではなく、情報の流れおよび仕事の実行を制御する仕事の抽象化である。ワークフローはまた、実行中の任意の時間にプロセスの状態を管理し、返すことができる状態マシンと考えられうる。要素（または構成要素のシステム）は、一実施形態では、リポジトリ作成、修正、および削除、復旧およびバックアップ、セキュリティグループ作成、削除、および修正、ユーザクレデンシャル管理、ならびに、キー回転およびクレデンシャル管理などのタスクについて、ワークフローのホスティングおよび実行を、管理し、かつ／または実施するように動作する。こうしたワークフローは、本明細書の他の所で論じるように、ワークフローサービスの上に実装されうる。ワークフロー要素はまた、基礎となるワークフローサービスが必ずしも変化しないため、ＭｙＳＱＬなどの異なるデータベースエンジンのために使用されるワークフローステップ間の差を管理しうる。

この例では、ワークフローは、データベースを作成し、元の要求から抽出される情報を適用するワークフローテンプレートを使用してインスタンス化されうる。たとえば、要求が、Ｏｒａｃｌｅ（登録商標）関係データベース管理システム（ＲＤＢＭＳ）または他のこうしたインスタンスではなく、ＭｙＳＱＬ（登録商標）ＲＤＢＭＳインスタンスのためのものである場合、ＭｙＳＱＬインスタンスに向けられる特定のタスクが、ワークフローに付加されることになる。ワークフロー要素はまた、要求される記憶量、任意の特定のハードウェア要件に関連する特定のタスク、または、他のこうしたタスクを選択しうる。これらのタスクは、全体のジョブについて有用な実行順序でワークフローに付加されうる。一部のタスクは、並列に実行されうるが、他のタスクは、最初に完了する前のタスクに依存する。ワークフロー要素またはサービスは、ワークフロー内にこの情報を含むことができ、タスクが実行され、必要に応じて情報が渡される。

顧客のための例の「データベース生成」ワークフローは、データストアインスタンスをプロビジョニングすること、オフインスタンス永続記憶ボリュームを割当てること、データストアインスタンスに永続記憶ボリュームをアタッチすること、そして、顧客がデータインスタンスにアクセスするかまたはその他の方法で接続するために使用しうる、ＤＮＳアドレスあるいは他のアドレス、ポート、インタフェース、または識別子を割当てアタッチすることなどのタスクを含む可能性がある。この例では、ユーザは、インスタンスにアクセスするために使用されるＤＮＳアドレスおよびポートアドレスを提供される。ワークフローはまた、特定のデータ記憶技術（たとえばＭｙＳＱＬ）のために使用される任意のバイナリまたは他の情報をダウンロードしインストールするタスクを含みうる。ワークフロー要素は、これらのタスクまた任意の関連タスクまたはこうしたタスクの任意の他の適切な組合せの実行を管理し、「データベース生成」要求に応答して「データベース(database)」の作成を示す要求に対する応答を生成することができ、応答は、実際には、データ層２１０内のデータストアインスタンスに対応し、インスタンスにアクセスするために使用されるＤＮＳアドレスを提供する。ユーザは、その後、制御層２０８にアクセスするかまたは制御層２０８を通過する必要なしで、ＤＮＳアドレスおよびポートを使用してデータストアインスタンスに直接アクセスしうる。種々の他のワークフローテンプレートを使用して、記憶を増加させるなどのために、多くのデータストアインスタンスのうちの１つを削除すること、作成すること、または修正することなどの同様のジョブが実施されうる。一部の実施形態では、ワークフロー情報は、記憶部に書込まれ、少なくとも１つの別個の実行要素（図示せず）は、ワークフロー情報に基づいて、実行されるタスクを引出すかあるいはその他の方法でそれにアクセスするかまたはそれを受信する。たとえば、プロビジョニングタスクを実行する専用プロビジョニング要素が存在する可能性があり、この構成要素は、ワークフロー要素によってコールされるのではなく、明らかであろういくつかの関連方法のうちの任意の方法で、タスクキューを監視しうるかまたはタスクをプロビジョニングするための情報を受信しうる。

述べたように、種々の実施形態は、リポジトリのプロビジョニングなどのプロセスまたはタスクの目下の状態についての要求またはコールを受信し、プロセスの目下の状態を返しうるワークフローサービスを利用することができる。ワークフロー要素および／またはワークフローサービスは、各タスクを実行するために実際のコールまたは要求を行うのではなく、代わりに、実施される次のタスクを制御層の構成要素が確定することを可能にするワークフローについての状態および構成情報、ならびに、そのタスクについて必要とされる任意の情報を管理し、次に、データ層へ、その状態情報を含む適切なコール（複数可）を生成し、それにより、データ層の構成要素が、タスクを実行するためにコールを発行することができる。ワークフローおよびタスクは、スループットを増加させ、処理資源を最大にするために並列にスケジューリングされうる。論じたように、タスクの実際の実行は、データ層で行われるが、タスクは、制御層から生じることになる。たとえば、ワークフロー要素、ホストマネジャと通信し得、ホストマネジャは、データストアへのコールを行うことができる。そのため、所与のタスクについて、いくつかのパラメータを渡すワークフローサービスに対するコールがを発行することができ、それにより、ワークフローサービスは、そのワークフローについてタスクのシーケンスを生成し、現在の状態についてのタスクが実行できるように、目下の状態を提供する。タスクが実行された（あるいは、その他の方法で解決されるかまたは完結された）後、ホストマネジャなどの構成要素が、サービスに返答することができ、サービスは、その後、次のタスクが実行できるように、ワークフロー内で次の状態に関する情報を提供することができる。ワークフローについてタスクのうちの１つのタスクが実行されるたびに、サービスは、ワークフローが終了するまで、実施される新しいタスクを提供することができる。さらに、複数のスレッドは、ワークフローの処理を加速するために、異なるワークフローについて並列に実行されうる。

制御層２０８はまた、この実施形態では、少なくとも１つの監視要素２１８を含む。データインスタンスが、データ層内で作成されると、インスタンスについての情報が、監視データストア２２０などの制御層内のデータストアに書込まれうる。監視データストアは、別個のデータストアでありうる、あるいは、Ａｄｍｉｎデータストア２２２内の異なる組のテーブルなどの別のデータストアまたは他の適切なリポジトリの一部分でありうることが理解されるべきである。監視要素は、データ層２１０内のアクティブなインスタンス２３４を確定するために、監視データストア内の情報にアクセスすることができる。監視要素はまた、ウェブサービス層、ワークフロー要素、スイープ要素、および種々のホストマネジャなどの、制御層および／またはデータ層の複数の構成要素からログおよび／またはイベント情報を収集することなどの他のタスクを実行することができる。こうしたイベント情報を使用して、監視要素は、顧客向きＡＰＩを実現することなどのために、顧客に見えるイベントを現すことができる。監視要素は、制御層について実行されている全てのリポジトリおよび／またはインスタンスの健全度を絶えず監視し、これらのインスタンスの任意のインスタンスの障害を検出し、適切な復旧プロセス（複数可）を始動することができる。

データ層内の各インスタンス２３４は、少なくとも１つのデータストア２２６、および、データストアに対するアクセスを提供するマシン用のホストマネジャ要素２２８を含みうる。ホストマネジャは、一実施形態では、ソフトウェア展開およびデータストアオペレーションなどのタスクを管理するようにプログラムされた、インスタンスおよび／またはＴｏｍｃａｔまたはＪａｖａ（登録商標）アプリケーションサーバなどのアプリケーションサーバ上で実行されると共に、データストアおよび／または各インスタンスの状態を監視するアプリケーションまたはソフトウェアエージェントである。ホストマネジャは、一実施形態では、内部システム構成要素からのみアクセスでき、顧客または他の外部エンティティにとって利用可能でないポート上でリッスンする。一部の実施形態では、ホストマネジャは、制御層層へコールを全く始動できない。ホストマネジャは、論理ボリュームおよびファイルシステムをセットアップすること、データベースバイナリおよびシードをインストールすること、およびリポジトリを起動するかまたは停止することを含む、新しいリポジトリのためのインスタンスをセットアップすることなどのタスクを管理することおよび／または実施することについて責任を担いうる。ホストマネジャは、データストアの健全度を監視すると共に、Ｉ／Ｏエラーまたはデータ記憶エラーなどのエラー状態があるかデータストアを監視することができ、また、必要がある場合、データストアを再起動することができる。ホストマネジャはまた、データストアおよび／またはオペレーションシステムについてのソフトウェアパッチおよびアップグレードのインストレーションを実行する、かつ／または、管理する。ホストマネジャはまた、ＣＰＵ、メモリ、およびＩ／Ｏ使用に関連しうる関連メトリクスを収集しうる。

監視要素は、特定の要求を送出すること、または、ホストマネジャからのハートビートを監視することなどによって、インスタンス２３４監視のために各ホストマネジャ２２８と定期的に通信して、各ホストのステータスを確定しうる。一実施形態では、監視要素は、特定のホストおよび／またはインスタンスのステータスを得るなどのために、各ホストマネジャのコマンドを発行するように構成された１組のイベントプロセッサ（または監視サーバ）を含む。指定数のリトライ後に応答が受信されない場合、監視要素は、問題が存在すると判定し、インスタンス用の動作を実行するための情報をＡｄｍｉｎデータストア２２２または別のこうしたジョブキューに格納して、問題を検証し、必要である場合、インスタンスを再プロビジョニングすることができる。スイーパは、この情報にアクセスし、インスタンスが障害から自動的に復旧しようと試みるために、復旧ワークフローを始動することができる。ホストマネジャ２２８は、制御層の他の構成要素を監視し、制御層構成要素の代わりにイスタンス用のタスクを実行するプロキシとして働きうる。時として、自動的に解決することができない、対応するホスト、インスタンス、またはボリュームのクラッシュ、再起動、再始動などのような問題が、インスタンスのうちの１つに関して起こるであろう。一実施形態では、これらのまた他の顧客可視性イベントを記録することができるロギング要素（図示せず）が存在する。ロギング要素は、インスタンスがある期間利用可能でない場合、顧客が、イベントに関する情報を得るために、適切な「イベント(event)」または同様なＡＰＩをコールできるように、ＡＰＩまたは他のこうしたインタフェースを含みうる。ある場合には、インスタンスが失敗すると、要求が、保留状態のままにされる可能性がある。制御層は、この実施形態では、データ層から離れているため、データ要求を受信することがなく、したがって、後続の送信のために要求をキューイングできない（しかし、一部の実施形態では、この情報は制御層に転送されうる）。そのため、制御層は、この実施形態では、障害に関する情報をユーザに提供して、ユーザが、必要に応じて要求を処理できるようにする。

論じたように、インスタンスがプロビジョニングされ、ユーザがＤＮＳアドレスあるいは他のアドレスまたはロケーションを提供されると、ユーザは、Ｊａｖａデータベースコネクティビティ(Java database Connectivity)（ＪＤＢＣ）または他のこうしたクライアントを使用してネットワークを通してデータ層２１０に要求を「直接(directly)」送出して、そのインスタンス２３４と直接やりとりすることができる。一実施形態では、データ層は、コンピューティングクラウド環境、すなわち、ハードウェアおよび／またはソフトウェア構成要素の「クラウド(cloud)」または動的ネットワークにわたってデータ記憶およびアクセスを提供する１組のウェブサービスまたは資源の形態をとる（または、それを少なくとも含む、または、その一部である）。ＤＮＳアドレスは、こうした動的クラウド環境では有益である。その理由は、たとえばインスタンスまたは可用性障害が、使用するための任意の適切な置換インスタンスにＤＮＳアドレスをプログラムで再マッピングすることによってマスクされうるからである。たとえばユーザ２０２またはアプリケーション２０４から受信される要求は、ネットワークアドレス変換(network address translation)（ＮＡＴ）ルータ２２４、あるいは、実際のインスタンス２３４または要求のＤＮＳに対応するホストに要求を送ることができる他の適切な構成要素送ることができる。論じたように、こうした手法は、インスタンスにアクセスするために使用されるＤＮＳまたは他のアドレスを変更するようにユーザまたはアプリケーションに要求することなく、インスタンスが、動的に移動され、更新され、複製されることなどを可能にする。論じたように、各インスタンス２３４は、ホストマネジャ２２８およびデータストア２２６を含み、永続的記憶部２３０内に少なくとも１つのバックアップインスタンスまたはコピーを有しうる。こうした手法を使用して、インスタンスが制御層を通して構成されると、ユーザ、アプリケーション、サービス、または構成要素は、制御層２３２にアクセスする必要なしで、データ層に対する要求を通してインスタンスと直接やりとりすることができる。たとえば、ユーザは、ＤＮＳアドレスを通して、構造化問合せ言語(structured query language)（ＳＱＬ）またはインスタンス内のデータに関連する他のこうしたコマンドを直接発行しうる。ユーザは、インスタンスの記憶容量を拡張することなどのタスクを実行したいと思う場合、制御層にアクセスしなければならないだけとなる。少なくとも１つの実施形態では、制御層２０８の機能は、データ層２１０のプロバイダに関連してもしなくてもよい少なくとも１つのサービスとしてプロバイダによって提供されうるが、データ層内のデータインスタンスをプロビジョニングし管理するために使用され、また、別個のデータ層２１０内のインスタンスの可用性を監視し保証することができる第３者サービスに過ぎなくてもよい。

論じるように、制御層の機能をウェブサービスまたは他のこうしたサービスとして提供する１つの利点は、制御層が、仮想データベース管理者(virtual database administrator)（ＤＢＡ）として機能し、データをプロビジョニングすることなどのタスクを人間のＤＢＡが実行する必要性を回避することである。データをプロビジョニングすることは、現在のところ、時間のかかる退屈な手作業の手順であり、必要な構成情報を受け取り、構成が有効であるかどうかを判定し、インスタンスを最適化し調節し、また他のこうしたタスクを実行することをＤＢＡに要求し、かなりの時間と労力がかかる。さらに、こうした手法は、多くのエラーの機会を与え、エラーは、データが喪失した後まで発見されない可能性がある。本明細書で述べるように制御層またはサービスを使用して、ユーザまたは顧客は、その代わりに、ハードウェアのタイプおよびデータベース製品のバージョンなどの情報を含むコールを送信することができる。制御層またはサービスは、そこで、データストアまたはデータ記憶インスタンスを作成、削除、修正、拡張、またはその他の方法で修正するための必要なタスクを実行することができる。制御層はまた、エンジンのそれぞれにおけるエキスパートであるようにＤＢＡに要求することなく、一貫した方式でいくつかの異なるデータベースエンジンをサポートすることができる。一旦プロビジョニングされると、ユーザは、データインスタンス（複数可）に対するネイティブなアクセスを有し、特定のインスタンスについてのＤＮＳアドレスまたは他のロケーション情報に対して既存のアプリケーション（ＭｙＳＱＬアプリケーションなど）を向けるだけで良い。ユーザが、ＭｙＳＱＬ、Ｏｒａｃｌｅ、または他のこうしたデータベース技術上で構築されるアプリケーションを使用し続けることができるため、クエリモデルまたは他のこうした機能の制限または修正は全く存在しない。

先に論じたような構成要素を使用して、図３は、制御層または同様なデータ制御サービスを使用して、データ環境、ここではデータ層内の少なくとも１つのデータインスタンスに関して制御関連タスクの実行を顧客が要求することができる例示的なプロセス３００を示す。「顧客(customer)」という用語は、データの「所有者(owner)」あるいはＲＤＳシステムによってホストされるデータストアまたはインスタンスを指すために本明細書で使用されるが、用語、顧客が例に過ぎないこと、および、任意の適切なユーザまたは開発者が、種々の実施形態で、制御層およびデータ層にアクセスすることを許容されうることが理解されるべきである。ウェブサービスコールなどの要求は、顧客向き制御層インタフェース要素を通して受信される３０２。要求は、要求を処理するために必要とされる少なくとも１つの動作を確定するために解析される３０４。論じるように、これは、要求される動作（複数可）を確定するために要求を構文解析するウェブサービス層の構成要素の形態をとりうる。この実施形態では、動作のタイプおよび動作を実施するために使用されるパラメータなどの動作についての情報は、Ａｄｍｉｎデータストアまたは他のこうした記憶ロケーションに位置しうるようなジョブキューに書込まれる３０６。ジョブキューは、ジョブ情報の存在を判定するためにスイーパ要素などによって監視されることができ３０８、ジョブ情報が検出されると、要求される動作についてのワークフローを始動する要求が送出されうる３１０。これは、スイーパ要素によってワークフロー要素に送出される要求および／またはワークフローをインスタンス化するサービスを含みうる。他の実施形態では、ワークフロー要素が、ジョブ用のジョブキューを監視することができ、または、ウェブサービス層の構成要素が、ジョブ情報をワークフロー要素に直接送出してもよい。

ジョブ情報を受信すると、要求される動作について適切なワークフローを確定するかつ／または組立てるために、情報が解析される３１２。論じるように、要求される動作のタイプおよび使用されるデータベースエンジンのタイプなどの因子に基づいて異なるタスクがワークフローについて選択されうる。ワークフローの第１のタスクで始めて、状態情報は、実行されるタスクを確定するために状態情報を使用し、データリポジトリおよび／またはデータインスタンスに関してタスクを実行し、タスクが終了するとすぐに応答を返すように動作するデータ環境内のホストマネジャに送出される３１４。応答を受信すると、ワークフロー要素は、実施される別のタスクが存在するかどうかを判定する３１６。別のタスクが存在する場合、次のタスクについての状態情報がホストマネジャに送出され、そのタスクが終了すると、ホストマネジャは、ワークフロー要素に応答を送出する。最後のタスクが終了した後、要求された動作が終了したというメッセージが、要求する顧客（あるいは、別の適切なユーザ、アプリケーション、またはロケーション）に送出される３１８。動作が終了した後、顧客は、制御層にアクセスすることなく、または、それを通過することなく、データ環境のデータインタフェースを使用して動作がその上で実行されたデータインスタンスに直接アクセスすることができる３２０。述べたように、ユーザは、たとえば動作がデータの移動または別の同様な動作をもたらした場合に、顧客またはアプリケーションが、データ層の適切なロケーションを割り当てられる、同じＤＮＳアドレスを使用し続けられるように、ＤＮＳアドレスおよびポート番号を提供されうる。

同様に、図４は、制御層または制御サービスが、データ環境、ここではデータ層内のデータインスタンス（または、データストア、リポジトリなど）の性能を監視できる例示的なプロセス４００を示す。ステータスについての要求は、データインスタンスについてホストマネジャ要素に送出される４０２。応答が、指定された時間内に受信されるかどうかについて判定が行われる４０４。応答が受信されない場合、閾値数の要求が送出されたかどうかが判定される４０６。閾値数の要求が送出されていない場合、もう一つの要求が送出されうる４０８。応答メッセージが受信される場合、応答が解析されて、任意のエラーまたはアドレス指定されるタスクをメッセージが含むかどうかが判定される４１０。それを含まず、また、インスタンスが健全であると判定される場合、プロセスが、引き続き行われ、ステータスについての別の要求が後で送出される。動作がデータインスタンスに関して実行される必要があることを応答メッセージが示す場合、動作のタイプおよび動作を実行するために使用されるパラメータなどの動作についての情報が、Ａｄｍｉｎデータストアまたは他のこうした記憶ロケーションに位置しうるようなジョブキューに書込まれる４１２。ジョブキューは、ジョブ情報の存在を判定するためにスイーパ要素などによって監視されることができ４１４、ジョブ情報が検出されると、要求される動作についてのワークフローを始動する要求が送出されうる４１６。他の実施形態では、ワークフロー要素が、ジョブ用のジョブキューを監視してもよく、または、ウェブサービス層の構成要素が、ジョブ情報をワークフロー要素に直接送出してもよい。

ジョブ情報を受信すると、要求される動作について適切なワークフローを確定するかつ／または組立てる４１８ために、情報が解析される。ワークフローの第１のタスクで始めて、状態情報は、データ環境内のホストマネジャに送出されて、図３のプロセスのステップ３１４〜３１６に関して述べたプロセスを使用して達成されうるような、タスクが実行され、ワークフローが実行される４２０。最終タスクが首尾よく終了する場合、データインスタンスは、データ層インタフェースを介して顧客またはアプリケーションから送出される要求を単に処理し続けることができる。タスクが首尾よく終了されることができない場合、データインスタンスに関する、可能性がある問題を示すメッセージが、顧客（または、別の適切なユーザ、アプリケーション、またはロケーション）に送出されうる。動作通知を生成すること、および／または、エラーログに情報を追加することなどの種々の他の通知動作が起こりうる。

具体的なインタフェースの例
先に論じたように、制御層のユーザは、１組のＡＰＩまたは他のこうしたインタフェースを使用してデータリポジトリおよびデータインスタンスに関連する種々のタスクを実行することができる。例示的なＡＰＩの選択および名前が、説明のために使用されるが、他の選択、組合せ、名前、および態様が、種々の実施形態の間で変わりうることが明らかであろう。上記例のうちの１つの例で論じるように、顧客は、「ＣｒｅａｔｅＤａｔａｂａｓｅ」（データベース生成）または同様なＡＰＩを使用してデータストアを作成することができる。ユーザは、ウェブサービスを呼び出して、インスタンスタイプ（ＣＰＵおよびメモリ容量を記述する）、記憶サイズ、リポジトリ名、ポート用の任意の所望の値、および他のこうした値を指定することができる。顧客はまた、「ＤｅｓｃｒｉｂｅＤａｔａｂａｓｅ」（データベース説明）または同様なＡＰＩを利用して、リポジトリ状態がプロビジョニングされているかどうかなど、リポジトリの状態を確定するためにリポジトリのステータスをポーリングすることができる。データベースのステータスが「利用可能(ＡＶＡＩＬＡＢＬＥ)」であるとき、たとえば、顧客は、ＤｅｓｃｒｉｂｅＤａｔａｂａｓｅコールに対する応答の一部として返されるエンドポイントを取出しうる。顧客は、「ＤｅｌｅｔｅＤａｔａｂａｓｅ」（データベース削除）または同様なＡＰＩを使用してリポジトリまたはインスタンスを削除することができうる。顧客はまた、たとえば「ＨｉｂｅｒｎａｔｅＤａｔａｂａｓｅ」（データベース休止）または同様なＡＰＩを使用してインスタンスを「スリープ(sleep)」状態にする、リポジトリまたはインスタンスを休止状態にする(hibernate)能力を有しうる。こうした「スリープ」状態中に、データは、通常、アクセス可能ではないが、永続的にバックアップされる。顧客は、「ＲｅｓｕｍｅＤａｔａｂａｓｅ」（データベース再開）または同様なＡＰＩを使用して、休止状態にされたデータリポジトリまたはインスタンスを覚醒させうる。

先に述べたように、制御層またはサービスは、データベースプロビジョニングの複雑さだけでなく、アップグレード、パッチ管理、バックアップ、およびフェールオーバーなどのタスクの複雑さも処理しうる。顧客は、「ＣｒｅａｔｅＤａｔａｂａｓｅ」（または「ＭｏｄｉｆｙＤａｔａｂａｓｅ」または同様なものの）ＡＰＩを呼び出しながら、顧客がバックアップウィンドウおよびメンテナンスウィンドウ時間を指定する（または修正する）ことを可能にすることによって、バックアップおよびメンテナンス活動についての時間を制御しうる。「ＭｏｄｉｆｙＤａｔａｂａｓｅ」（データベース修正）ＡＰＩを使用して、顧客は、記憶サイズを増加させるか、インスタンスタイプを変更するか、または種々の他のフィールドを修正できる。

顧客はまた、少なくとも１つの「Ｄａｔａｂａｓｅ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ」（データベースアクセスコントロール）または同様なＡＰＩを提供されうる。データリポジトリが作成されると、ユーザは、リポジトリに対するネットワークアクセスを制限するために、１つまたは複数の既存のセキュリティグループを指定することができる。顧客は、セキュリティグループに許可ルールを追加することによってリポジトリに対するアクセスを認可することができ、許可ルールは、ＡｕｔｈｏｒｉｚｅＤＢＳｅｃｕｒｉｔｙＧｒｏｕｐＩｎｇｒｅｓｓ（ＤＢセキュリティグループ侵入許可）ＡＰＩなどのＡＰＩを使用してリポジトリに適用される。顧客はまた、「ＭｏｄｉｆｙＤａｔａｂａｓｅ」ＡＰＩなどのＡＰＩを使用して任意の時間にセキュリティグループを追加するかまたはリポジトリから削除することができる。顧客は、「ＣｒｅａｔｅＤＢＳｅｃｕｒｉｔｙＧｒｏｕｐ」（ＤＢセキュリティグループ生成）（または「ＤｅｌｅｔｅＤＢＳｅｃｕｒｉｔｙＧｒｏｕｐｓ」（セキュリティグループ削除））ＡＰＩなどの同様なＡＰＩを使用して、セキュリティグループを作成（または削除）しうる。

制御層はまた、少なくとも１つの「Ｄａｔａｂａｓｅ Ｕｓｅｒ Ｍａｎａｇｅｍａｎｔ」（データベースユーザ管理）または同様なＡＰＩを提供しうる。ＣｒｅａｔｅＤａｔａｂａｓｅＡＰＩの一部として、たとえば、顧客は、一実施形態では、「リポジトリ所有者(Repository Owner)」と呼ばれてもよいような、特別のリポジトリユーザについてのユーザ名およびパスワードを供給することが期待されうる。リポジトリ所有者は、リポジトリスキーマオブジェクトを所有する特別のタイプのユーザである。リポジトリの作成後、顧客は、「ＣｒｅａｔｅＤａｔａｂａｓｅＵｓｅｒ」（データベースユーザ作成）ＡＰＩを使用してより多くのユーザを追加すること、「ＤｅｌｅｔｅＤａｔａｂａｓｅＵｓｅｒ」（データベースユーザ削除）ＡＰＩを使用してユーザを除去すること、また、「ＤｅｓｃｒｉｂｅＤａｔａｂａｓｅＵｓｅｒｓ」（データベースユーザ説明）ＡＰＩを使用して顧客の一覧表を作成することなどのタスクを実行しうる。顧客はまた、「ＤｅｓｃｒｉｂｅＥｖｅｎｔｓ」（イベント説明）または同様なＡＰＩを使用して、リポジトリおよびインスタンスに関連するイベント（メンテナンスまたはバックアップ関連イベントによ稼働停止など）の履歴を得ることができる。

顧客例
この例では、顧客は、既存のＭｙＳＱＬデータベースを維持し管理する代わりに、新しいデータインスタンスをプロビジョニングしたいと思う。この例では、既存の顧客(CUSTOMER)データベースは６０ＧＢであり、記憶成長推定値は約１０％／月である。これらの初期容量要件に基づいて、顧客は、８０ＧＢの初期容量によってプロビジョニングされるインスタンスを選択する。顧客は、マスターユーザおよびマスターユーザパスワードを選択し、ファイアウォール要件に基づいて、データインスタンスがその上でリッスンされることになる適切なポート番号（たとえば４０３０）を選択する。

顧客は、制御サービスにまだ契約していないかまたは加入していない場合、サービスについて契約しうる。一部の実施形態では、ユーザは、たとえばユーザが制御層またはサービスに要求を送信することを可能にする、ソフトウェアを受けるか、または、インタフェースページにインターネットを通してアクセスすることになる。たとえば、図５は、ユーザが制御層へのコールを行うことを可能にしうる、ディスプレイ５００、ここではブラウザアプリケーションにおいて表示されたページの例を示す。示すように、インタフェースは、データ層上で制御動作を実行するために必要とされる情報をユーザが入力することを可能にするオプションを含みうる。たとえば、インタフェースページは、動作についてリポジトリを指定するオプション５０２、実行される動作を選択するオプション５０４を含み、使用されるデータベースエンジン５０６または要求される容量ならびにバージョン情報５０８などの動作用のオプションあるいは他のこうしたオプションを指定する。他の実施形態では、ユーザは、制御層に対してウェブサービスコールを手動で（またはその他の方法で）作成し送信することができる。以下の例では、顧客は、コマンドラインツールを使用して新しいデータリポジトリを作成する要求を生成する。要求は、たとえば、
ｒｄｓ−ｃｒｅａｔｅ−ｄａｔａｂａｓｅ ――ｉｄｅｎｔｉｆｉｅｒ ｃｕｓｔｏｍｅｒｐｒｏｄ ――ｄｂｎａｍｅ ｃｕｓｔｏｍｅｒ ――ｓｉｚｅ ８０ −ｃｌａｓｓ ｓｍａｌｌ ――ｅｎｇｉｎｅ ｍｙｓｑｌ５．１ ――ｍａｓｔｅｒ ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅ ――ｐａｓｓｗｏｒｄ ｍａｓｔｅｒ＿ｐａｓｓｗｏｒｄ ――ｐｏｒｔ４０３０
の形態をとりうる。

顧客は、プロビジョニングステータスをチェックする能力を有し、また、
ｄｅｓｃｒｉｂｅ−ｒｅｐｏｓｉｔｏｒｉｅｓ ｃｕｓｔｏｍｅｒｐｒｏｄ
を送信することなどによって、リポジトリを記述するために、コマンドラインツールを使用してコネクトストリング(connect string)を要求することができる。

顧客は、
ａｕｔｈｏｒｉｚｅ ｄｅｆａｕｌｔ −ｓ２０５．１９２．０．０／１６
によって、アドレス範囲２０５．１９２．０．０／１６などからデフォルトセキュリティグループに対するアクセスを許可することができる。

顧客はまた、
ｄｅｓｃｒｉｂｅ−ｇｒｏｕｐ ｄｅｆａｕｌｔ
を送信することなどによって、セキュリティステータス変化をチェックすることができる。

要求が送信されると、制御層は、リポジトリをプロビジョニングする要求を非同期で実行することができる。「ＤｅｓｃｒｉｂｅＤａｔａｂａｓｅｓ」または同様なＡＰＩを、要求のステータスを確定するために使用することができる。プロビジョニングが依然として進行中である間に、ステータスは、たとえば「保留中の作成(Pending Creation)」として示されることになり、また、プロビジョニングが終了すると、「作成済み(Created)」などの状態に変更されうる。この時点で、顧客は、リポジトリに接続するために必要な全ての情報を有することができる。

リポジトリが、プロビジョニングされ利用可能になると、顧客は、データ層上で種々の動作を実行することができる。たとえば、顧客は、ＭｙＳＱＬダンプユーティリティまたは同様なデータ転送プロセスを使用することなどによって顧客（CUSTOMER）リポジトリをポピュレートしうる。顧客は、この例では、
＄ ｍｙｓｑｌｄｕｍｐ −ｏｐｔ ｃｕｓｔｍｅｒ | ｍｙｓｑｌ――ｈｏｓｔ
ｅｎｄ＿ｐｏｉｎｔ＿ｈｏｓｔｎａｍｅ ――ｐｏｒｔ ４０３０ −Ｃ ｃｕｓｔｏｍｅｒ
のように（すなわち、互換性のあるクライアントユーティリティを使用してソースＭｙＳ
ＱＬデータベースサーバ上で）コマンドを実行する。

顧客はまた、
＄ ｍｙｓｑｌ −ｕ ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅ ｈ− ｅｎｄ＿ｐｏｉｎｔ＿ｈｏｓｔｎａｍｅ ――ｐｏｒｔ ４０３０ −ｐ ｍａｓｔｅｒ＿ｐａｓｓｗｏｒｄ

Ｍｙｓｑｌ＞ ｓｈｏｗ ｔａｂｌｅｓ；

＋――――――――――――――――――＋
| Ｔａｂｌｅｓ ｉｎ ｃｕｓｔｏｍｅｒ|
＋――――――――――――――――――＋
| Ｔａｂｌｅ１ |
| Ｔａｂｌｅ２ |
| Ｔａｂｌｅ３ |
＋-――――――――――――――――――＋
を送信することなどによって、要求されたテーブルが作成されていることを検証しうる。
リポジトリは、顧客のアプリケーションのうちの１つのアプリケーションによっていつでも使用できる。顧客は、アプリケーションが元の自己管理データベースの代わりに新しいインスタンスデータベースを指示するためにコネクトストリング（または他のポインタ）を変更する。

この例では、顧客はまた、役割ベースアクセス制御を通してデータセキュリティを実装したいと思う。プロビジョニングされロードされたデータインスタンスをターンオンし、インスタンスを利用可能にする前に、開発チームはリポジトリに対するリード／ライトアクセスを有するが、ビジネス解析者はリードアクセスを得るだけであるように、顧客は、役割ベースアクセス制御を実装したいと思う。クライアントはまた、「マスターユーザ(master user)」アクセスを一握りの上級メンバーに制限したいと思うため、残りの開発者は、異なるデータベースのユーザ役割を必要とする。

制御層に関して、顧客は、たとえば、
ｃｒｅａｔｅ−ｕｓｅｒ ――ｉｄｅｎｔｉｆｉｅｒ ｃｕｓｔｏｍｅｒｐｒｏｄ
――ｕｓｅｒｎａｍｅ ｄｅｖｅｌｏｐ１ ――ｐａｓｓｗｏｒｄ ｄｅｖｅｌｏｐ
１
ｃｒｅａｔｅ−ｕｓｅｒ ――ｉｄｅｎｔｉｆｉｅｒ ｃｕｓｔｏｍｅｒｐｒｏｄ
――ｕｓｅｒｎａｍｅ ａｎａｌｙｓｔ１ ――ｐａｓｓｗｏｒｄ ａｎａｌｙｓｔ
１
を送信することなどによって、コマンドラインツールを使用して新しいデータベースユーザを作成する要求を送信することができる。

顧客はまた、
ｄｅｓｃｒｉｂｅ−ｕｓｅｒｓ ｃｕｓｔｏｍｅｒｐｒｏｄ
を送信することなどによって、要求についてのプロビジョニングステータスをチェックすることができる。

プロビジョニングが依然として進行中である間に、ステータスは、たとえば「保留中の作成(Pending Creation)」などの状態を示すことができ、また、プロビジョニングが終了すると、「作成済み(Created)」などの状態に変更されることになる。顧客は、今や、データ層内でユーザを安全にするために必要なタスクを実行することができる。

顧客は、その後、
＄ ｍｙｓｑｌ −ｕ ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅ ｈ− ｅｎｄ＿ｐｏｉｎｔ＿ｈｏｓｔｎａｍｅ ――ｐｏｒｔ ４０３０ −ｐ ｍａｓｔｅｒ１
Ｍｙｓｑｌ＞ｇｒａｎｔ ｓｅｌｅｃｔ，ｉｎｓｅｒｔ，ｕｐｄａｔｅ，ｄｅｌｅｔｅ
ｏｎ ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅ．^* ｔｏ ‘ｄｅｖｅｌｏｐ１’＠’％’；
を送信することなどによって、データ層に関連して、ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅが所有される全てのテーブルについてｄｅｖｅｌｏｐ１ユーザにリード／ライト特権を許可することができる。

顧客はまた、ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅが所有する全てのテーブルについてａｎａｌｙｓｔ１ユーザにリード特権を許可することができる。

＄ ｍｙｓｑｌ −ｕ ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅ −ｈ ｅｎｄ＿ｐｏｉｎｔ＿ｈｏｓｔｎａｍｅ ――ｐｏｒｔ ４０３０ −ｐ ｍａｓｔｅｒ１
Ｍｙｓｑｌ＞ｇｒａｎｔ ｓｅｌｅｃｔ ｏｎ ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅ，
^* ｔｏ ‘ａｎａｌｙｓｔ１’＠’％’；

インスタンスがしばらくの間実行された後、顧客は、イスタンスのサイズを、たとえば１５０ＧＢの記憶までスケールアップしたいと思う可能性がある。顧客は、この例では、
ｍｏｄｉｆｙ−ｄａｔａｂａｓｅ ――ｉｄｅｎｔｉｆｉｅｒ ｃｕｓｔｏｍｅｒｐｒ
ｏｄ ――ｓｉｚｅ １５０
を送信することなどによって、コマンドラインツールを使用してデータベースの容量を修正する要求を送信することができる。

システムが、計算または処理の必要性について、インスタンスのサイズを調整することを可能にする場合、その調整は、さらなるパラメータ値を指定することによって同じまたは同様のコマンドで行われうる。顧客はまた、
ｄｅｓｃｒｉｂｅ−ｄａｔａｂａｓｅｓ ｃｕｓｔｏｍｅｒｐｒｏｄ
などのコマンドを送信することによって、調整についてのプロビジョニングステータスをチェックすることができる。

要求されるリポジトリ修正は、一実施形態では、先に論じた、顧客によって指定されるメンテナンスウィンドウ中に起こる。変更が進行中である間、ステータスは、たとえば「保留中の修正(Pending Modification)」であり、「保留中の修正」は、プロビジョニングが終了すると、「アクティブ(Active)」などの値に変更されうる。論じたように、顧客は、この要求の実行中に、データ層サイドでいかなる動作もとる必要がない。制御層サイドで、顧客は、自動スケーリングプランなどのサービスに加入することができる。一旦加入すると、自動スケーリングが、顧客用の容量を管理し、必要に応じてスケールアップまたはスケールダウンするように構成されうるため、顧客は、制御層上でさえも、いかなる動作もとる必要がない。

ある時点で、顧客は、種々の開発ニーズのために改善されたまたは更新されたプロセスを実装したいと思い、特定のデータストアの試験インスタンスをセットアップしたいと思う可能性がある。顧客はまた、生産日に関して試験インスタンスが完全にポピュレートされ匹敵するように、生産インスタンスのスナップショットをとりたいと思う可能性がある。試験プロシージャの特定のニーズのために、顧客が、処理能力のために小さなインスタンスを利用し、生産のために使用されるのと同じ記憶容量をプロビジョニングしうることを、顧客が決定する。そして、顧客は、
ｃｒｅａｔｅ−ｄａｔａｂａｓｅ ――ｉｄｅｎｔｉｆｉｅｒ ｃｕｓｔｏｍｅｒ
ｔｅｓｔ ――ｄｂｎａｍｅ ｔｃｕｓｔｏｍｅｒ ――ｓｉｚａ １５０ ――
ｃｌａｓｓ ｓｍａｌｌ ――ｅｎｇｉｎｅ ｍｙｓｑｌ５．１ ――
ｍａｓｔｅｒ ｍａｓｔｅｒ＿ｕｓｅｒｎａｍｅ
――ｐａｓｓｗｏｒｄ ｍａｓｔｅｒ＿ｐａｓｓｗｏｒｄ ――ｐｏｒｔ ４０３０
を送信することなどによって、コマンドラインツールを使用してデータベースをクローン化する要求を送信しうる。

顧客はまた、
ｄｅｓｃｒｉｂｅ−ｄａｔａｂａｓｅｓ ｃｕｓｔｏｍｅｒｔｅｓｔ
などのコマンドを送信することによってプロビジョニングステータスをチェックすることができる。

要求される修正は、顧客によって以前に指定されたメンテナンスウィンドウ中に起こりうる。変更が進行中である間、ステータスは、たとえば「保留中の修正(Pending Modification)」として示されることになり、「保留中の修正」は、プロビジョニングが終了すると、「アクティブ」などの状態に変更されうる。論じたように、顧客は、この要求の実行中に、データ層サイドでいかなる動作もとる必要がない。制御層サイドで、顧客は、先に述べたように、自動スケーリングなどのサービスに加入することができ、それにより、一旦加入すると、自動スケーリングサービスが、顧客のためのスケーリングを管理することになるため、顧客は、制御層上でさえも、いかなる動作もとる必要がない。

先に論じたように、種々の実施形態による制御層またはサービスの使用は、顧客が実行しうるＳＱＬクエリのタイプを制限せず、また、パーティションが用意され、複数パーティションにまたがるクエリを許容しないというような、スキーマの構築に関する制限を全く課さない。代わりに、関係データベースなどのリポジトリは、ユーザのスキーマまたはクエリを制限することなく、コンピューティング「クラウド(cloud)」においてプロビジョニングされうる。一般に知られるように、たとえ理論的なＳＱＬ標準が存在しても、ＳＱＬの癖、文法、およびその挙動（たとえば、ヌル処理）は、異なる関係データベースエンジン（たとえば、ＭｙＳＱＬ、Ｏｒａｃｌｅ、またはＰｏｓｔｇｒｃｓ）にわたって変わる。少なくともこれらの理由で、ユーザは、プログラミングおよびオペレーションのために、よく知っている関係データベースエンジンを選択したいと思う可能性がある。こうした手法は、顧客が制御層を介して自分のデータストアをクラウド（または他の所）に移動させるときでも、データモデリング、開発、およびデバッギングなどのタスクのために顧客が以前に使用したのと同じ組のデータベースツールを顧客が使用することを可能にする。こうした手法を使用して、顧客は、自分のアプリケーションまたは任意のオペレーションツールを書き直すことを要求されず、それにより、顧客がクラウドにデータを移動させるための参入障壁が大幅に低くなる。

顧客のデータリポジトリは、一実施形態では、クラウドコンピューティング環境の計算ノード上でリポジトリを実行させることによってクラウドに移動されうる。インスタンスの寿命と無関係に永続するオフインスタンス記憶ボリュームなどのブロックレベル記憶ボリュームは、たとえばリポジトリバイナリ、ログ、およびボリュームを記憶するこれらのインスタンスによって使用されうる。こうした手法は、仮想化が、リポジトリについて計算および記憶資源を迅速かつ容易にスケーリングするという柔軟性を提供するため、有利でありうる。さらに、こうした手法は、クラウド内に永続的記憶を提供しうる。

当技術分野で知られているように、関係データベースは、独立型（非複製型）、複製型、または複製およびパーティション型を含んでもよいような、異なるモードで実行されうる。顧客は、通常、リポジトリの可用性およびスケーラビリティのニーズならびに科せられる総所有コスト(total cost of ownership)（ＴＣＯ）に基づいてリポジトリについてどのモードが実行されるかについての選択を行う。一部のアプリケーションおよびサービスは、高可用性および高耐久性であることをリポジトリに要求せず、代わりに、分単位の停電に耐えることができる独立型リポジトリを使用してもよい。他のアプリケーションおよびサービスは、常に可用であることをリポジトリに要求し、また、障害時でさえも決してデータを喪失しないことをリポジトリに要求しうる。この場合、アプリケーションおよびサービスは、通常、複製型データベース提供を要求する。一部のユーザ、アプリケーション、またはサービスは、スケーリングが、単一データベースの計算および記憶容量を超えて起こりうるように、複数リポジトリにわたってデータをパーティションしうる膨大にスケーラブルなリポジトリを要求する。これらの異なる使用事例に対処するために、一実施形態による手法は、各データベースエンジンについて、独立型および高可用型などの少なくとも２つのモードを提供する。一部の実施形態はまた、独立型または高可用型リポジトリの上部に、顧客が自分自身のパーティション用層を構築することを可能にする。

述べたように、制御層層は、ワークフローを実装すること、データ層のホストマネジャと制御層の構成要素との間にセキュアな通信チャネルを確立すること、データ層のインスタンス上にソフトウェアをインストールすること、および種々のデータベースバックアップおよび復旧手順を実行することなどのタスクを実行する種々の基本的なソフトウェアフレームワークを利用しうる、または、そのソフトウェアフレームワークの「上に位置し(sit on top)」うる。

たとえば、制御層の層は、ワークフローを管理するワークフローサービスを利用することができる。一般に知られているように、任意のワークフローエンジンの重要な特徴は、エンジンが非同期でかつ再開可能な処理を可能にすることである。先に論じたように、ワークフローは、初期状態で始まり、最終目標に達する前に、ワークフローの異なるステップを実行することによって、一連の中間状態遷移を通過する状態マシンと考えられうる。この最終目標は、状態マシンの終端状態と考えられうる。ワークフローサービスは、ワークフローを作成する能力を提供し、所与のワークフローおよび次に実行されるステップ（複数可）の目下の状態を確定するフックを提供する。サービスは、状態マシンの目下の状態を記憶し、成功裏に実行されるステップおよびワークフローの移動を維持するために実行されなければならないステップに追従しうる。サービスは、一般に、実際には私たちのために状態遷移を実行してはいない。ワークフローについてタスクを実行する厳密なタスクは、多くの実施形態では、ワークフローの「クライアント(client)」要素によって実行される。

制御層が、任意の所与の時間に並列に実行される複数のワークフローを有することができ、これらのワークフローが、異なるタスクを実施するためのものでありうるため、制御層は、複数のワークフローをスケジューリングし、複数の活動を並列に実行することができるアーキテクチャを利用することができる。一実施形態では、制御層は、種々のワークフロータスクを実行するようにプログラムされる種々のワーカーフリートを含む。ワーカーフリートとワークフローサービスとの間のやりとりは、図６の構成６００に関して述べる。各ワーカーホストは、３つの構成要素、この例では、ポーラー要素６０４決定要素６０２、およびディスパッチャー要素６０６を実行する。各ホストは、各ワークフロータイプについてデサイダーキューをポーリングする単一ポーラースレッドを実行する。決定キューは、一実施形態では、異なるワークフロータイプの優先順位に基づいてポーリングされる。たとえば、決定キューは、リポジトリ作成ワークフローより先に(ahead of)復旧ワークフローについてポーリングされうる。たとえばｐｏｌｌＤｅｃｉｄｅｒＱｕｅｕｅ（決定キューをポール）ＡＰＩが、決定の空でないリストを返す場合、ポーラーは、その決定を決定要素に転送することができる。決定要素は、その後、所与のワークフローにおいて実行する次のタスクに関して決定を行い、所与のワークフローについて動作キューにタスクを付加する「ｓｔａｒｔＡｃｔｉｖｉｔｙ」（動作開始）または同様なＡＰＩをコールしうる。ポーリング中に、ポーラーは、決定キューが空結果を返すと、次のタスクに移動し、「ＰｏｌｌＡｃｔｉｖｉｔｙＱｕｅｕｅ」動作キューをポール）または同様なＡＰＩを使用して活動キューをポーリングしうる。ＰｏｌｌＡｃｔｉｖｉｔｙＱｕｅｕｅのＡＰＩが空でないリストを返す場合、このリストは、ワークフロー活動を実行する仕事を課されうるディスパッチャースレッドプールに引き継がれうる。ワークフロー活動が首尾よく終了すると、「ＡｃｔｉｖｉｔｙＣｏｍｐｌｅｔｅｄ」（動作完了）または同様なＡＰＩがコールされることができ、決定キューに入れるワークフローサービスをコールする。

ワークフローフリート内の各ワークフローホストは、この例では、ポーラースレッダー、決定要素、およびディスパッチャースレッドプールを実行する。ワークフローは、一実施形態ではアノテーションフレームワークを使用して定義することができ、また、ワークフローアプリケーションは、適切なクラスパスから読取ることによって始動時にこれらの定義を構築することができる。ワークフローサービスホストは、「ｒｅｇｉｓｔｅｒＷｏｒｋｆｌｏｗＴｙｐｅ」（ワークフロー登録）および「ｒｅｇｉｓｔｅｒＡｃｔｉｖｉｔｙＴｙｐｅ」（動作タイプ登録）ＡＰＩなどのワークフローサービスのＡＰＩを使用して、登録されるワークフローおよび動作タイプのリストを最初に登録する。これらのＡＰＩは、この例では不変であるため、各ＡＰＩは、複数のフリートから複数回コールされうる。

異なるワークフロータイプの新しいワークフローインスタンスは、リポジトリ作成、リポジトリ削除、リポジトリ修正、リポジトリ復旧、リポジトリバックアップ、ユーザ作成、ユーザ削除、パスワードリセット、セキュリティ管理などのタスク、および他のこうしたタスクについて作成される必要がある可能性がある。これらのワークフローインスタンスはそれぞれ、図２に関して先に論じたように、任意の変更が実行されるために、Ａｄｍｉｎリポジトリを絶えず掃引するスイーパを使用して作成されうる。たとえば、ユーザが新しいリポジトリを作成したいと思う場合、ウェブサービス層は、「ＰＥＮＤＩＮＧ＿ＣＨＡＮＧＥＳ」などのステータスカラムを有するＡｄｍｉｎＤＢに、必要とされる構成を記憶しうる。各ワークフローホストは、ステータスがＰＥＮＤＩＮＧ＿ＣＨＡＮＧＥＳに設定されている、任意のデータベースまたはセキュリティグループについて掃引するスイーパスレッドを実行し、相応してワークフローを起動しうる。

一部の実施形態では、ワークフローサービスの「ｃｒｅａｔｅＷｏｒｋｆｌｏｗ」（ワークフロー作成）ＡＰＩは、要求される構成がＡｄｍｉｎリポジトリに記憶されるとすぐに、ウェブサービス層から直接コールされうるが、ワークフローサービスを直接コールすることは、２相コミットスタイル問題(two-phase commit style problem)をもたらしうる。ワークフローがワークフローサービスから利用可能でない場合、Ａｄｍｉｎリポジトリ更新が、ロールバックされなければならず、ＣｒｅａｔｅＤａｔａｂａｓｅのＡＰＩコールが受容されない。こうした２相コミットスタイル問題を回避するために、種々の実施形態は、たとえばステータスがＰＥＮＤＩＮＧ＿ＣＨＡＮＧＥＳに設定されているＡｄｍｉｎリポジトリレコードに対する変更を観察することによって、起動される新しいワークフロー活動があるか掃引するように動作するスイーパアーキテクチャを利用する。

利用されうる別のアーキテクチャは、有利には、ホスト層の構成要素からデータ層のホストマネジャにセキュアな通信を提供することに関する。一実施形態では、制御層のワークフローおよび監視要素は、種々のタスク（たとえば、データベースメンテナンスおよびソフトウェアインストレーション）を実行すると共に、種々のインスタンスおよび／またはリポジトリのステータスをチェックするために、ホストマネジャと絶えず通信している。制御層とホストマネジャとの間の全ての通信は、盗聴するかまたはホストマネジャに無認可コマンドを発行することを誰にもさせないセキュアなネットワークを通じて起こることが少なくとも一部の実施形態では重要である。

一実施形態では、ホストマネジャに対する全ての通信チャネルは、セキュアソケット層(secure socket layer)（ＳＳＬ）を通じたハイパーテキスト転送プロトコルを使用してセキュアである。ホストマネジャアプリケーションをホストする各アプリケーションサーバは、インスタンスの起動時にスクリプトを使用して起動されうる。アプリケーションサーバエンジンを始動させる前に、自己署名証明書を生成し、ＳＳＬ通信チャネル（複数可）を有効にするために証明書をインストールするスクリプトが実行されうる。ＳＳＬ通信は、一実施形態では、クライアント認証のためではなく、通信チャネルを暗号化するために使用される。クライアント認証は、代わりに、各要求に埋め込まれる公開鍵／秘密鍵の署名によって達成され、それにより、一実施形態では、全てのクライアントが、秘密鍵を使用してクエリストリングパラメータに署名する。この署名は、ホストマネジャ用のアプリケーションサーバによって展開されうるカスタムインターセプターによって確認されうる。さらに、セキュリティグループ（すなわちファイアウォールルール）は、所与のネットワークまたはセキュアグループ内に存在する(sit)ホストだけがホストマネジャポートを使用して通信できるように、データ層内の監視される各インスタンスについて確立されうる。セキュア情報およびクレデンシャル（秘密鍵など）は、適切な鍵ストアに記憶され、鍵管理および鍵回転などの機能を提供しうる。

別のアーキテクチャは、ソフトウェアインストレーションおよびメンテナンスを支援するために使用されうる。ソフトウェアは、一般に、リポジトリライフサイクルの種々のステージ中にデータ層インスタンス内のインスタンス上にインストールされる必要がある。リポジトリを作成するために、種々のバイナリおよび／またはシーズがインストールされる必要がある可能性がある。リポジトリが作成された後、種々のパッチ、ならびに、オペレーションシステムにインストールされる必要がある可能性があるクリティカルセキュリティパッチがデータベースに適用される必要がある可能性がある。そのため一部の実施形態では、種々のインスタンス上への異なるタイプのソフトウェアのインストレーションを可能にする柔軟性があるソフトウェアインストレーションアーキテクチャまたはフレームワークを構築することが望ましい場合がある。こうしたフレームワークの重要な要件のうちの１つの要件は、新しいソフトウェアをインストールするだけでなく、目下の組のインストール済みソフトウェアおよび各バージョンに関する情報を提供することである。こうしたフレームワークが、インストレーション中の競合を解決し、インストレーションの成功を検証し、インストール済みソフトウェアのリストにクエリするＡＰＩまたは他のメカニズムを提供する機能を提供することが望ましい。

インストレーションフレームワークは、一実施形態では、ソフトウェアが単一コマンドによってインストールされうるように、既にコンパイルされているソフトウェアが分配されることを可能にするＲＰＭ（レッドハットパッケージマネジャ(Red Hat Package Manager)）などのパケットマネジャを利用する。ソフトウェアは、事前定義されたＵＲＬからインストールされうるように、「バケット(bucket)」に記憶されうる。ＲＰＭまたは同様なインストーラコマンドは、２つの異なるパラメータとして、（別のＵＲＬでありうる）パッケージのマニフェストファイルおよびＲＰＭ ＵＲＬをとりうる。インストール済みＲＰＭは、制御層および／またはレッドハットによって署名されることになり、両方の鍵は、インスタンスのためにインストールされ維持されうる。ソフトウェアインストレーションは、こうした状況では、「ｉｎｓｔａｌｌＳｏｆｔｗａｒｅ」（ソフトウェアのインストール）または同様なＡＰＩを提供しうるホストマネジャによって実行されうる。こうしたＡＰＩは、パッケージＵＲＬ、マニフェストＵＲＬ、リトライカウント、フォースインストールフラグ、およびＲＰＭルートロケーションなどのパラメータを考慮しうる。このＡＰＩを呼び出すと、マニフェストファイルがダウンロードされ、各アイテムは、アプリケーションの目下インストールされているリストと比較される。アイテムが既にインストールされている場合、「強制インストール(force install)」または同様なフラグが指定されない限り、再インストールしようという試みは、行われない。個々のパッケージがインストールされたかどうかをチェックするために、各ホストマネジャは、「ｇｅｔＳｔａｔｕｓｏｆＳｏｆｔｗａｒｅ」（ソフトウエアステータスの取得）または同様なＡＰＩを提供しうる。「ｉｎｓｔａｌｌＳｏｆｔｗａｒｅ」ホストマネジャＡＰＩは、不変であり（ワークフローが機能停止し(die)、再びステップにリトライしてもよいため）かつ非同期でありうる（ソフトウェアインストレーションは、終了するのにしばらくかかるため）。これらの２つの態様は、第２の「ｉｎｓｔａｌｌＳｏｆｔｗａｒｅ」コールが第１のコールに干渉することを防止できる、同期のための静的オブジェクトを使用することによって達成されうる。

一実施形態による「ｉｎｓｔａａｌｌＳｏｆｔｗａｒｅ」ＡＰＩは、最大の「リトライカウント」回数についてループ内で実行される。このＡＰＩはまた、前の失敗した試みから存在する可能性がある任意のインストレーションファイルを除去する。ＡＰＩは、マニフェストファイルをダウンロードし、どのアイテムがインストールされる必要があるかを判定し、その後、適切なリポジトリまたは他のソースからファイル（複数可）またはパッケージをダウンロードすることができる。適切なＲＰＭファイルが、その後、処理されインストールされる。最終クリーンアップステップが、その後、インストレーションプロセス内にエラーが存在しても実行されうる。

ホストマネジャアプリケーションのインストレーションおよび任意の更新もまた、全ての他のイスタンスを書き留めることを必要としない方法で、各インスタンスについて管理されうる。一実施形態では、インスタンスは、起動時にアプリケーションサーバエンジンを起動し、ホストマネジャは、新しいホストアプリケーションを展開するためにアプリケーションサーバマネジャフレームワークをコールすることによってインストールされる。他の通信の場合と同様に、ホストマネジャに対してソフトウェアをインストールするかまたは更新をプッシュする前に、通信はさえぎられ、クライアントが認証されることができ、それは、既存のリポジトリの可用性に影響を及ぼすことなく達成されうる。

基礎になるフレームワークに依存しうる別の態様は、リポジトリおよびデータバックアップに関する。ユーザ始動バックアップ（バックアップ時間ウィンドウ中に実施されうる）およびデータベース修復中のシステム始動バックアップなどのような種々の理由で、制御層が、顧客リポジトリおよびインスタンスをバックアップすることが望ましい。単一フレームワークが、両方のインスタンスを処理するために実装されうる。リポジトリをバックアップするために、フレームワークは、データファイルと任意の関連ログファイルの両方のバックアップを処理しうる。種々のステップおよびプロセスが述べられるが、種々のステップおよび手法は、ＭｙＳＱＬおよび他のものなどの種々のデータベースエンジンで異なりうることが理解されるべきである。

一実施形態に従ってデータをバックアップする手法は、適切なデータボリュームのスナップショットがとられ、ログファイルが適切なロケーションに同様にコピーされるまでデータの演算を一時停止する。たとえば、Ａｄｍｉｎ階層は、バックアッププロシージャを始動する前に、バックアップウィンドウにたいして待機することができる。一旦バックアップウィンドウ内に入ると、Ａｄｍｉｎ階層は、リポジトリバックアップのためにワークフローインスタンスを作成することになるワークフローを作成することができる。一例では、ワークフローは、ホストマネジャについて「ｓｕｓｐｅｎｄＤａｔａｂａｓｅＦｏｒＢａｃｋｕｐ」（バックアップのためにデータベースを一時停止）または同様なＡＰＩを呼び出す。このＡＰＩは、たとえば、テーブルをフラッシュしロックし、データボリュームに対してＩ／Ｏを一時停止し、ログボリュームについてＬＶＭスナップショットを作成しマウントし、最後のログ位置を有するログ位置ファイルを作成し、データベースを再開するためにタイマを起動するタスクを管理しうる。このタイマは、スナップショットをとること、リポジトリが不定期間偶然に一時停止されることを防止することなどのタスクを実施している間に、Ａｄｍｉｎ階層がハングアップする場合に、リポジトリを再開するために使用することができる。ワークフローは、これらのタスクおよび／または他のこうしたタスクの終了についてホストマネジャをポーリングすることができる。ホストマネジャがリポジトリを一時停止したことをワークフローが確認すると、ワークフローは、１組の順序付きタスクを使用して、データボリュームをバックアップしようと試みる。たとえば、ワークフローは、各データボリュームのスナップショットを作成することを指示し、スナップショットが成功裏に作成されたことを検証することができる。一行が、ｂａｃｋｕｐ＿ｄａｔａ＿ｖｏｌｕｍｅｓテーブルなどのロケーションに、各スナップショットボリュームについて挿入されうる。その後、ワークフローは、ホストマネジャの「ｒｅｓｕｍｅＤａｔａｂａｓｅＦｒｏｍＢａｃｋｕｐ」データベースをバックアップから再開）または同様なＡＰＩを呼び出すことができる。このプロセスは、リポジトリログおよびログ位置情報を適切な記憶ロケーションにコピーし、ログスナップショットをアンマウントし、ログスナップショットログボリュムを除去し、全てのテーブルをアンロックすることができる。Ａｄｍｉｎ階層は、その後、バックアップが終了し、リポジトリが再び利用可能であることを示す顧客イベントを作成することができる。

論じたように、ログファイルはまた、同様な方式でバックアップされうる。ログは、データファイルが修復されなければならない場合に種々のトランザクションを再生することなどのタスクを実行するために使用することができる。エンジンログは、以前にバックアップされたログファイルが、簡単なリストコマンドを使用して得られるように、適切な記憶ロケーションにコピーすることができる。ホストマネジャは、この結果を使用して、コピーされる必要があるログが存在するかどうかを判定する。たとえば、ホストマネジャは、最後のシーケンスがバックアップされうるように書かれたログファイルのリストを得るように、バケットリストに要求することができる。新しいログが作成された場合、ログが、データベースエンジンに積極的に書込まれないことが最初に判定されることができ、その後、ログはコピーされ、コピーが、成功裏に実施されたことを検証することができる。

種々のフレームワークを利用することによって処理されうる別の態様は、セキュア鍵およびユーザクレデンシャルなどの種々のセキュリティ態様の管理を含む。セキュア鍵およびパスワードなどのセキュア情報は、参照により本明細書に組み込まれる、２００９年２月１７日に出願され、「Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ」という名称の同時係属中の米国特許出願番号第１２／３７２，５９７号に記載されるように、セキュア鍵管理システムまたはサービスを使用して記憶されうる。こうしたサービスは、各クレデンシャルについて少なくとも２つのバージョン、「古い(OLD)」バージョンと目下のバージョンを含みうる。鍵は、たとえば、鍵用のベース名を使用することなどによって鍵用の新しい値をサービスにアップロードし、必要に応じて、その鍵の値をホストマネジャに伝えるようにワークフローを起動することによって交代されうる。それぞれの適切なホストが新しいクレデンシャルを有するように、ワークフローが成功裏に終了されると、鍵の古いバージョンは、新しい値と効率的に置き換えることができる。任意のクレデンシャルについて、古い鍵が新しい鍵に一致しない場合、それは、鍵の交代プロセスが目下進行中であるということを示す。古い鍵が目下の鍵に一致しない場合、新しい鍵の交代は起動されず、したがって、依然として使用中である可能性がある手法が、クレデンシャルを喪失するリスクをとりうる。コマンドラインユーティリティまたは同様なインタフェースを、このチェックを強制しうる鍵管理サービスに鍵をプッシュするために使用することができる。

別個のワークフローが、全てのホストマネジャインスタンス上のホストマネジャクレデンシャルなどのクレデンシャルを更新するかつ／または交代するために定義されうる。こうした手法は、クレデンシャルタイプ、公開鍵、およびオプションの秘密鍵などの、同じ入力を、各ホストマネジャ上の「ＳｅｎｄＣｒｅｄｅｎｔｉａｌｓ」（クレデンシャル送出）または同様のＡＰＩとして利用しうる。しかし、クレデンシャル値の代わりに、ワークフローは、鍵管理サービスにその値を記憶するために使用される鍵の名前を受容しうる。ワークフローは、目下の値が新しい値と異なることを検証し、値が同じである場合、ワークフローは、適切なエラー条件で終了しうる。制御層によって管理されるアクティブな各ホストについて、各ホスト上のホストマネジャに新しいクレデンシャル（複数可）を送出することになるサブワークフローが起動されうる。全てのサブワークフローが終了すると、新しいクレデンシャル値が古い値を置換しうる。このワークフローが進行中である間に、作成されるかまたは再起動される任意のホストは、通常、元のクレデンシャルの代わりに、新しいバージョンのクレデンシャルが与えられる必要があることになる。

ホストにクレデンシャルを送出するサブワークフローは、オリジナルのワークフローと同じ入力ならびに特定のホストマネジャ用のホスト名およびポートを利用しうる。サブワークフローは、指定された各クレデンシャルについてホストマネジャ上で「ＵｐｄａｔｅＣｒｅｄｅｎｔｉａｌｓ」（クレデンシャル更新）または同様なＡＰＩをコールし、更新が終了したことを検証するために、ホストマネジャ上で「ＧｅｔＣｒｅｄｅｎｔｉａｌｓ」（クレデンシャル取得）または同様なＡＰＩをコールすることができる。ホストマネジャは、少なくとも１つの実施形態では、クレデンシャルを所定のロケーションに置くためにすべてのことが行われるまで、クレデンシャルについての新しい値を報告しない。全てのホストマネジャが、２時間（２時間は、構成可能であり、必要に応じて更新するのが容易である）などの適切な期間内に更新されない場合、ワーフフローは、タイムアウトし、エラーチケットまたは他のこうした障害の指示を生成しうる。リポジトリと通信するためにホストマネジャによって使用される全てのルート／ａｄｍｉｎクレデンシャルは、Ａｄｍｉｎリポジトリに暗号化形態で記憶することができる。Ａｄｍｉｎリポジトリにおいてパスワードを暗号化するために鍵を交代させるとき、新しい鍵が、管理サービスにアップロードされ、ワークフローが、新しい鍵を使用して全ての適切なユーザパスワードを再暗号化するために起動されうる。そのワークフローが成功裏に終了すると、新しい暗号鍵を使用することができる。暗号鍵を変更することに加えて、このワークフローはまた、各データベースについてルートパスワードを変更もすることができる。パスワード暗号鍵を交代させるワークフローは、新しい暗号鍵が古い暗号鍵と異なることを検証し、インフライトワークフローについての任意のユーザパスワードを新しい鍵で暗号化し、任意のアクティブでないリポジトリについてのルートパスワードを新しい鍵で暗号化することができる。リポジトリがアクティブでないため、パスワードは、変更されないが、新しい鍵で再暗号化されうる。アクティブな各リポジトリについて、新しいルートパスワードが、生成され、（新しい鍵で暗号化される）変更保留フィールドに記憶され、サブワークフローが、ホストマネジャクレデンシャルを新しいパスワードで更新するために起動されうる。サブワークフローが終了すると、新しいルートパスワードが、新しい暗号鍵を使用して、データリポジトリに書き戻されうる。ルートデータベースパスワードは、リポジトリがアクティブでないときには変更されないが、リポジトリを再起動するワークフローは、リポジトリがアクティブになるとルートパスワードを変更しうる。

一実施形態による手法は、リモートコマンドをラップし、クレデンシャルが交代される方法に関して制限を強制するコマンドラインユーティリティを利用する。これは、公開鍵および秘密鍵が、並んでのみ交代されること、および、前の交代が依然として進行中である場合、鍵は交代されないことを保証しうる。ユーティリティは、鍵が全てのホストに対して成功裏に展開され、その後、適切な制御層環境で適切なワークフローを起動することを検証する。コマンドラインユーティリティは、
ｒｏｔａｔｅ−ｒｄｓ−ｋｅｙ ＼
――ｓｔａｇｅ Ｏｎｅ ｏｆ Ｄｅｖｏ，Ｉｎｔｅｇ，ＱＡ，ｏｒ Ｐｒｏｄ＼
――ｔｙｐｅ ｃｒｅｄｅｎｔｉａｌ＿ｔｙｐｅ＼
――ｐｕｂｌｉｃＫｅｙ ｖａｌｕｅ ｆｏｒ ｐｕｂｌｉｃ ｋｅｙ ＼
――ｐｒｉｖａｔｅＫｅｙ ｏｐｔｉｏｎａｌ ｆｏｒ ｓｏｍｅ ｔｙｐｅｓ；
ｖａｌｕｅ ｆｏｒ ｐｒｉｖａｔｅ ｋｅｙ
などの文法を使用しうる。

こうしたユーティリティは、目下の鍵がフリート内の任意のホスト上で古い鍵と異なる場合、フリート内の任意のホストに対して新しい鍵のエラーコピー動作が存在する場合、またはワークフローステップが起動されることができなかった場合に障害を起こしうる。鍵が既に異なっている場合、ロールバックに対する変更は存在しない可能性がある。ユーティリティは、それ以外の場合にはいずれの変更もロールバックし、ロールバックが不成功であった事例をユーザに報知しうる。

ホストマネジャインスタンスが、「ＵｐｄａｔｅＣｒｅｄｅｎｔｉａｌｓ」または同様なワークフロー中に機能停止(die)する場合、ワークフローがリトライすることを可能にすることは、ワークフローサイドに特別なロジックがない状態での多くのシナリオに対処しうる。クレデンシャルを更新することであるステップ以外のワークフローステップは、ワークフローがそこから復旧する必要がある「ＭｉｓｓｉｎｇＣｒｅｄｅｎｔｉａｌ」（クレデンシャル不在）または同様な例外を受信しうる。こうした場合、新しいクレデンシャルをホストマネジャに送出することが受容されうる。データベース管理パスワードの場合、パスワード変更は、発効していない可能性がある。ルートパスワードを再送出しようとするワークフローステップ（ならびに、他のワークフローからルートパスワードを要求する、ホストマネジャに対する任意の他のコール）は、「ＭｉｓｓｉｎｇＣｒｅｄｅｎｔｉａｌ」または同様な例外によって障害を起こしうる。変更パスワードワークフロー以外のワークフローステップは、クレデンシャルを新しいパスワードに設定し、任意の障害を処理しようと試みうる。パスワードを積極的に変更しようとしているワークフローは、最初に、新しいパスワードを送出しようとしうる。それが成功する場合、ワークフローが行われ、そうでなければ、ワークフローは、古いパスワード、それに続いて、新しいパスワードでリトライしうる。ホストマネジャは、目下メモリにパスワードを持たない場合に、ルートパスワードについて「ＵｐｄａｔｅＣｒｅｄｅｎｔｉａｌｓ」または同様なコールを受信する場合、そのパスワードを使用してリポジトリに接続しようと試み、接続を確立することができない場合障害を起こしうる。

種々のクレデンシャルおよびセキュアオブジェクトの交代は、顧客に目立つ影響を与えることなく多くのインスタンスにおいて達成される。ウェブサービス層は、多くの実施形態で、顧客要求を処理することの一部としてこれらのクレデンシャルをいずれも使用しないため、顧客ＡＰＩコールは、通常通りに進み続けうる。クレデンシャルを交代させることの影響は、交代されるクレデンシャルのタイプに応じてある程度変わりうる。たとえば、新しい対のウェブサービス鍵が生成されるとき、元の対によって署名された要求は、失敗し始めうる。これは、一般に、ワークフローシステムがある期間にわたってリトライしうるワークフローステップに影響を及ぼすだけである。新しいウェブサービスクレデンシャルは、進行中のワークフローに対する混乱を最小にするために管理サービスに迅速にアップロードされうる。新しいパスワードを生成し伝えるワークフローが進行中である間、ワークフローボックスは、古い暗号鍵と新しい暗号鍵の両方にアクセスでき、それにより、各ワークフローが進行中である間に、個々のリポジトリおよびインスタンスに対する接続が行われうる。ホストマネジャ認証鍵の場合、実働ホストは、要求が拒否される場合に、古い鍵によって接続をリトライするリトライロジックを所定ロケーションに有しうる。ＲＰＭ署名鍵の場合、ホストマネジャは、鍵が交代される場合、ある期間、ソフトウェアをインストールできない可能性がある。

先に論じたように、種々の実施形態は、いろいろな動作環境で実装されることができ、ある場合には、１つまたは複数のユーザコンピュータ、コンピューティングデバイス、または多数のアプリケーションの任意のアプリケーションを動作させるために使用されうる処理デバイスを含みうる。ユーザまたはクライアントデバイスは、標準的なオペレーションシステムを実行するデスクトップまたはラップトップコンピュータなどの多数の汎用パーソナルコンピュータの任意の汎用パーソナルコンピュータ、ならびに、モバイルソフトウェアを実行しかつ多数のネットワーキングおよびメッセージングプロトコルをサポートすることが可能な携帯、無線、および手持ち式デバイスを含みうる。こうしたシステムはまた、種々の市販のオペレーションシステムならびに開発およびデータベース管理のための他の知られているアプリケーションのうちの任意のものを実行する多数のワークステーションを含みうる。これらのデバイスはまた、ダミー端末、シンクライアント、ゲーミングシステム、およびネットワークを介して通信することが可能な他の電子デバイスを含みうる。

種々の態様はまた、サービス向きアーキテクチャの一部でありうるような少なくとも１つのサービスまたはウェブサービスの一部として実装されうる。ウェブサービスなどのサービスは、拡張可能マークアップ言語(extensible markup language)（ＸＭＬ）フォーマットでかつＳＯＡＰ（「シンプルオブジェクトアクセスプロトコル(Simple Object Access Protocol)」から導出される）などの適切なプロトコルを使用して交換されるメッセージを使用することなどによる、任意の適切なタイプのメッセージングを使用して通信することができる。こうしたサービスによって提供される、または、実行されるプロセスは、ウェブサービス記述言語(Web Service Description Language)（ＷＳＤＬ）などの任意の適切な言語で書くことができる。こうしたＷＳＤＬなどの言語を使用することは、種々のＳＯＡＰフレームワークにおけるクライアントサイドのコードの自動生成などの機能を可能にする。

ほとんどの実施形態は、ＴＣＰ／ＩＰ、ＯＳＩ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ、ＣＩＦＳ、およびＡｐｐｌｅＴａｌｋなどの種々の市販のプロトコルのうちの任意のプロトコルを使用して通信をサポートすることについて当業者によく知られている少なくとも１つのネットワークを利用する。ネットワークは、たとえば、ローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、およびその任意の組合せでありうる。

ウェブサーバを利用する実施形態では、ウェブサーバは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データサーバ、Ｊａｖａサーバ、およびビジネスアプリケーションサーバを含む、種々のサーバまたは中間層アプリケーションの任意のアプリケーションを実行することができる。サーバ（複数可）はまた、Ｊａｖａ（登録商標）、Ｃ、Ｃ♯、またはＣ＋＋などの任意のプログラミング言語、あるいは、Ｐｅｒｌ、Ｐｙｔｈｏｎ、またはＴＣＬなどの任意のスクリプティング言語、ならびに、その組合せで書かれた１つまたは複数のスクリプトまたはプログラムとして実装されうる１つまたは複数のウェブアプリケーションを実行することなどによって、ユーザデバイスからの要求に応答して、プログラムまたはスクリプトを実行することができうる。サーバ（複数可）はまた、制限はしないがＯｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、およびＩＢＭ（登録商標）から商業的に入手可能なサーバを含むデータベースサーバを含んでもよい。

環境は、先に論じたように、種々のデータストアおよび他のメモリおよび記憶媒体を含むことができる。これらは、コンピュータの１つまたは複数にローカルな（かつ／またはそこに存在する）、または、ネットワークにわたるコンピュータの任意のまたは全てのコンピュータから遠隔の記憶媒体上などの、種々のロケーションに存在しうる。特定の組の実施形態では、情報は、当業者によく知られている記憶域ネットワーク(storage-area network)（「ＳＡＮ」）内に存在してもよい。同様に、コンピュータ、サーバ、または他のネットワークデバイスに起因する機能を実施するための任意の必要なファイルは、必要に応じて、ローカルにかつ／またはリモートに記憶されてもよい。システムが、コンピュータ化デバイスを含む場合、こうした各デバイスは、バスを介して電気結合されてもよいハードウェア要素を含むことができ、その要素は、たとえば、少なくとも１つの中央処理ユニット（ＣＰＵ）、少なくとも１つの入力デバイス（たとえば、マウス、キーボード、コントローラ、タッチスクリーン、またはキーパッド）、および少なくとも１つの出力デバイス（たとえば、ディスプレイデバイス、プリンタ、またはスピーカ）を含む。こうしたシステムはまた、ディスクドライブ、光記憶デバイス、ランダムアクセスメモリ（「ＲＡＭ」）または読取り専用メモリ（「ＲＯＭ」）などの固体記憶デバイス、ならびに、リムーバブルメディアデバイス、メモリカード、フラッシュカードなどのような１つまたは複数の記憶デバイスを含んでもよい。

こうしたデバイスはまた、上述のように、コンピュータ可読記憶媒体リーダ、通信デバイス（たとえば、モデム、ネットワークカード（有線または無線）、赤外線通信デバイスなど）、およびワーキングメモリを含みうる。コンピュータ可読記憶媒体リーダは、リモート、ローカル、固定、および／またはリムーバブル記憶デバイス、ならびに、コンピュータ可読情報を、一時的にかつ／またはより永続的に含む、記憶する、送信する、および取出す記憶媒体を表すコンピュータ可読記憶媒体に接続されうるか、または、その記憶媒体を受取るように構成されうる。システムおよび種々のデバイスはまた、通常、オペレーションシステムおよびクライアントアプリケーションまたはウェブブラウザなどのアプリケーションプログラムを含む、多数のソフトウェアアプリケーション、モジュール、サービス、または少なくとも１つのワーキングメモリデバイス内に位置する他の要素を含むであろう。代替の実施形態は、上述したものからのいくつかの変形を有してもよいことが理解されるべきである。たとえば、カスタマイズされたハードウェアが使用されてもよく、かつ／または、特定の要素がハードウェア、ソフトウェア（アプレットなどのポータブルソフトウェアを含む）、または両方で実装されてもよい。さらに、ネットワーク入力／出力デバイスなどの他のコンピューティングデバイスに対する接続が使用されてもよい。

コードまたはコードの所定部分を含む記憶媒体およびコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用され、システムデバイスによってアクセスされうる任意の他の媒体を含む、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶しかつ／または送信する任意の方法または技術において実装される、限定はしないが、揮発性および不揮発性でリムーバブルおよび非リムーバブルの媒体などの、記憶媒体および通信媒体を含む当技術分野で知られているかまたは使用される任意の適切な媒体を含みうる。本明細書に提供される開示および教示に基づいて、当業者は、種々の実施形態を実装するための他のやり方および／または方法を理解するであろう。

付記項１。
別個の制御環境を使用して関係データベースの態様を制御する、コンピュータによって実現される方法であって、
実行可能命令によって構成される１つまたは複数のコンピュータシステムの制御下で、制御インタフェースを通して、顧客から制御環境へのウェブサービスコールを受信すること、
関係データベースに関して実施される動作を確定するために、ウェブサービスコールを解析し、確定された動作についての情報をジョブキューに記憶すること、
ジョブキューから、確定された動作についての情報を抽出し、情報に少なくとも部分的に基づいてワークフローを生成することであって、ワークフローは、確定された動作に関してデータ環境で実行されるべき少なくとも一系列のタスクを含み、関係データベースはデータ環境内に存在すること、
ワークフローの各タスクについて、タスクを実行し、タスクの実行に関する応答を返すように動作するデータ環境内のホストマシン用のホストマネジャにタスクについての状態情報を送出することであって、最終でない各タスクの成功裏の終了は、ワークフローの後続のタスクについての状態情報をワークフローマネジャに送出することをもたらすこと、および、
ワークフローの最終タスクが成功裏に終了したことを示す応答がホストマシンから受信されると、動作が成功裏に実施されたという通知を顧客に送出することを含み、
顧客は、制御環境にアクセスすることなく、データ環境のデータインタフェースを使用して、動作が実施された後の関係データベースに直接アクセスできるコンピュータによって実現される方法。

付記項２。
データ環境に関して実行するべき任意の動作についての情報があるか、ジョブキューを監視することをさらに含む付記項１に記載のコンピュータによって実現される方法。

付記項３。
顧客にＤＮＳ（ドメイン名システム）アドレスおよびポート情報を提供することをさらに含み、顧客がデータインタフェースを使用して関係データベースにアクセスすることを可能にする付記項１に記載のコンピュータによって実現される方法。

付記項４。
別個の制御環境を使用してデータ環境の態様を制御するコンピュータによって実現される方法であって、
実行可能命令によって構成される１つまたは複数のコンピュータシステムの制御下で、
データ環境に関して実施される動作を確定するために、制御環境の制御インタフェースを通して受信される要求を解析すること、
確定された動作についてのワークフローであって、確定された動作に関してデータ環境で実行されるべき少なくとも１つのタスクを含む、ワークフローを生成すること、
ワークフローの各タスクについて、タスクを実行し、タスクの実行に関する応答を返すように動作するデータ環境内の構成要素に要求を送出すること、および、
ワークフローの最終タスクが終了したことを示す応答がホストマシンから受信されると、要求された動作が終了したという通知を、制御インタフェースを通して送出することを含み、
データ環境内のデータは、制御環境にアクセスすることなく、データ環境のデータインタフェースを使用してアクセス可能であるコンピュータによって実現される方法。

付記項５。
データは、少なくとも１つの関係データベースに記憶される付記項４に記載のコンピュータによって実現される方法。

付記項６。
要求は、ウェブサービスコールであり、
動作は、少なくとも１つの関係データベースの１つをプロビジョニングすることを含む付記項５に記載のコンピュータによって実現される方法。

付記項７。
動作は、データ環境内のデータインスタンスを、作成すること、削除すること、バックアップすること、スケーリングすること、複製すること、プロビジョニングすること、または修正することのうちの少なくとも１つを含む付記項４に記載のコンピュータによって実現される方法。

付記項８。
要求は、制御環境の外向きアプリケーションプログラミングインタフェース（ＡＰＩ）に対して受信されるウェブサービスコールである付記項４に記載のコンピュータによって実現される方法。

付記項９。
データインタフェースは、指定されたデータインスタンスについてＤＮＳアドレスを使用してアクセス可能な制御環境の外向きＡＰＩである付記項４に記載のコンピュータによって実現される方法。

付記項１０。
タスクの少なくとも１つは、データインスタンスを作成すること、データインスタンスの記憶ボリュームを設定すること、データインスタンスを修正すること、選択されたエンジンについてバイナリをダウンロードすること、データインスタンスのバックアップおよび復旧、データ複製およびフェールオーバー、セキュリティグループを作成し管理すること、ユーザクレデンシャルを管理すること、鍵交代の管理およびクレデンシャル管理、ならびに、データインスタンスをサポートするハードウェアにアタッチすることからなる群から選択される付記項４に記載のコンピュータによって実現される方法。

付記項１１。
要求は、クレデンシャルに基づいてユーザを認証すること、ユーザを認可すること、ユーザ要求を抑えること、ユーザ入力を確認すること、ならびに、要求および応答をマーシャリングするまたはアンマーシャリングすることからなる群から選択される少なくとも１つのタスクを実行するように動作する構成要素を含むウェブサービス層に対して受信される付記項４に記載のコンピュータによって実現される方法。

付記項１２。
要求に対応するデータ要素のために使用されるデータベースエンジンに少なくとも部分的に基づいて選択されるタスクを使用してワークフローを組立てることをさらに含む付記項４に記載のコンピュータによって実現される方法。

付記項１３。
データ環境についてのイベント情報を、制御環境内のデータストアに記録(log)することをさらに含む付記項４に記載のコンピュータによって実現される方法。

付記項１４。
さらに、データ環境内の構成要素は、データ環境内でタスクを実行するように動作するホストマシン用のホストマネジャであり、ホストマネジャは、さらに、データ環境の少なくとも１つの態様について健全度情報を収集し監視するように動作する付記項４に記載のコンピュータによって実現される方法。

付記項１５。
別個の制御環境を使用してデータ環境を維持するコンピュータによって実現される方法であって、
実行可能命令によって構成される１つまたは複数のコンピュータシステムの制御下で、
制御環境の監視要素から、データインスタンスの監視の責任を担うデータ環境内の少なくとも１つのホストマネジャへ、ステータスについての要求を定期的に送出すること、
ステータスについての要求のうちの１つを受信した少なくとも１つのホストマネジャから応答を受信すること、
データ環境に関して実施される任意の動作を確定するために応答を解析し、ワークフローであって、確定された動作に関してデータ環境で実施される少なくとも１つのタスクを含む、ワークフローを、確定された動作について生成すること、
ワークフローの各タスクについて、タスクを実行し、タスクの動作に関する情報を有する応答を返すために、ホストマネジャに状態情報を送出することであって、最後でない各タスクの成功裏の終了は、ワークフローの後続のタスクについての状態情報をワークフローマネジャに送出することをもたらすこと、および、
ワークフローの最終タスクが終了したことを示す応答がホストマシンから受信されると、実施された動作についての情報を、データ環境用のログに記憶することを含み、
データ環境内のデータは、制御環境にアクセスすることなく、データインタフェースを使用してアクセス可能であるコンピュータによって実現される方法。

付記項１６。
データインスタンスは、データ環境内の関係データベースに対応する付記項１５に記載のコンピュータによって実現される方法。

付記項１７。
実行される動作を確定するために要求を解析することに応答して、確定された動作についての情報を、ジョブキューにに格納することをさらに含み、
情報は、ワークフローを生成するために、ジョブキューから抽出(extract)されることができる付記項１５に記載のコンピュータによって実現される方法。

付記項１８。
ホストマネジャからの応答が所定の期間内に受信されないとき、ステータスについて別の要求を送出すること、および、
ホストマネジャからの応答が、所定数の要求後に受信されないとき、データ環境に関して実行されるべき動作を確定し、確定された動作についてワークフローを生成することをさらに含む付記項１５に記載のコンピュータによって実現される方法。

付記項１９。
ホストマネジャは、ステータスについての要求に対する応答を生成するときに使用するために、データ環境の少なくとも１つの態様について健全度情報を収集し監視するように動作する付記項１５に記載のコンピュータによって実現される方法。

付記項２０。
別個の制御環境を使用してデータ環境を制御するシステムであって、
少なくとも１つのプロセッサと、
命令を含むメモリとを備え、命令は、少なくとも１つのプロセッサによって実行されると、
データ環境に関して実行される動作を確定するために、制御環境の制御インタフェースを通して受信される要求を解析し、
確定された動作についてのワークフローであって、確定された動作に関してデータ環境で実施されるべき少なくとも１つのタスクを含む、ワークフローを生成し、
ワークフローの各タスクについて、タスクを実行し、タスクの実行に関する応答を返すように動作するデータ環境内の構成要素に要求を送出し、
ワークフローの最終タスクが終了したことを示す応答がホストマシンから受信されると、要求された動作が終了したという通知を、制御インタフェースを通して送出することを、
システムにさせ、
データ環境内のデータは、制御環境にアクセスすることなく、データ環境のデータインタフェースを使用してアクセス可能であるシステム。

付記項２１。
要求を受信するように動作する制御環境内の外向きＡＰＩをさらに含み、その要求はウェブサービスコールである、付記項２０に記載のシステム。

付記項２２。
データインタフェースは、指定されたデータインスタンスについてＤＮＳアドレスを使用してアクセス可能な制御環境の外向きＡＰＩである付記項２０に記載のシステム。

付記項２３。
前記要求を受信し、クレデンシャルに基づいてユーザを認証すること、ユーザを認可すること、ユーザ要求を抑えること、ユーザ入力を確認すること、ならびに、要求および応答をマーシャリングするまたはアンマーシャリングすることからなる群から選択される少なくとも１つのタスクを実行するように動作する制御環境内のウェブサービス層をさらに含む付記項２０に記載のシステム。

付記項２４。
要求に対応するデータ要素について使用されるデータベースエンジンに少なくとも部分的に基づいて選択されるタスクを使用してワークフローを組立てるように動作するワークフロー要素をさらに備える付記項２０に記載のシステム。

付記項２５。
コンピュータ可読媒体に埋め込まれ、かつ、命令を含むコンピュータプログラム製品であって、命令は、少なくとも１つのコンピューティングデバイスによって実行されると、
データ環境に関して実施される動作を確定するために、制御環境の制御インタフェースを通して受信される要求を解析し、
確定された動作についてのワークフローであって、確定された動作に関してデータ環境で実行されるべき少なくとも１つのタスクを含む、ワークフローを生成し、
ワークフローの各タスクについて、タスクを実行し、タスクの実行に関する応答を返すように動作するデータ環境内の構成要素に要求を送出し、
ワークフローの最終タスクが終了したことを示す応答がホストマシンから受信されると、要求された動作が終了したという通知を、制御インタフェースを通して送出することを、
少なくとも１つのコンピューティングデバイスにさせ、
データ環境内のデータは、制御環境にアクセスすることなく、データ環境のデータインタフェースを使用してアクセス可能であるコンピュータプログラム製品。

付記項２６。
少なくとも１つのコンピューティングデバイスによって実行されると、
要求を受信するように動作する制御環境内の外向きＡＰＩを提供することを
少なくとも１つのコンピューティングデバイスにさせる命令をさらに含む付記項２５に記載のコンピュータプログラム製品。

付記項２７。
少なくとも１つのコンピューティングデバイスによって実行されると、
要求を受信し、クレデンシャルに基づいてユーザを認証すること、ユーザを認可すること、ユーザ要求を抑えること、ユーザ入力を確認すること、ならびに、要求および応答をマーシャリングするまたはアンマーシャリングすることからなる群から選択される少なくとも１つのタスクを実行するように動作する制御環境内のウェブサービス層を提供することを
少なくとも１つのコンピューティングデバイスにさせる命令をさらに含む付記項２５に記載のコンピュータプログラム製品。

付記項２８。
少なくとも１つのコンピューティングデバイスによって実行されると、
要求に対応するデータ要素のために使用されるデータベースエンジンに少なくとも部分的に基づいて選択されるタスクを使用してワークフローを組立てるように動作するワークフロー要素を提供することを
少なくとも１つのコンピューティングデバイスにさせる命令をさらに含む付記項２５に記載のコンピュータプログラム製品。

したがって、明細書および図面は、制限的な意味ではなく例証的な意味で考察される。しかし、特許請求の範囲に述べる本発明のより広い趣旨および範囲から逸脱することなく、仕様および図面に種々の修正および変更が行われてもよいことが明らかである。

Claims (15)

1. データ記憶部およびホストマシンを含むデータ環境と、前記データ環境とは別個の制御環境であって、前記データ記憶部の構成制御を行うサーバーコンピューターを含む制御環境とを有するコンピュータシステムにおける、１つまたは複数のコンピュータが実行可能命令を実行することにより、前記制御環境を使用して前記データ環境の構成を制御する方法であって、
   前記制御環境において、
   前記データ環境における前記データ記憶部の少なくとも１つのデータインスタンスの構成制御であって、前記少なくとも１つのデータインスタンスを作成、削除、バックアップ、リカバリー、スケーリング、複製、プロビジョニング、アップグレード、パッチ管理、フェールオーバー、または容量管理する、構成制御に関して実行されるべき動作を確定するために、前記制御環境の制御インタフェースを介して受信した要求を解析することと、
   前記実行されるべき動作についてのワークフローであって、前記実行されるべき動作に関して前記データ環境で実行される少なくとも１つのタスクを含む、ワークフローを生成することと、
   前記タスクを実行し、前記タスクの実行に関する応答を返すように動作する前記データ環境内のホストマシンに、前記ワークフローの各タスクについての要求を送出することと、および、
   前記ワークフローの最終タスクが終了したことを示す応答を前記ホストマシンから受信すると、前記実行されるべき動作が終了したという通知を、前記制御インタフェースを通して送出することと、
   前記データ環境において、
   前記データ環境のデータインタフェースは、前記実行されるべき動作が終了したという通知が、前記制御インタフェースを通して送出された後には、前記データ環境内のデータへのアクセスを、前記制御環境を介さず直接受け付けることを有し
   顧客が自動スケーリングプランサービスに加入している場合、前記加入した顧客のリソースの容量のスケーリングは、前記容量を自動的にスケールアップまたはスケールダウンすることにより前記容量を管理するように構成される
   方法。
2. 前記データは、少なくとも１つのリレーショナルデータベースに記憶される請求項１に記載のコンピュータによって実現される方法。
3. 前記要求は、ウェブサービスコールであり、
   前記実行されるべき動作は、前記少なくとも１つのリレーショナルデータベースの１つの構成制御であって、前記少なくとも１つのデータインスタンスを作成、削除、バックアップ、リカバリー、スケーリング、複製、プロビジョニング、アップグレード、パッチ管理、フェールオーバー、または容量管理することを含む請求項２に記載のコンピュータによって実現される方法。
4. 前記要求は、前記制御環境の外向きアプリケーションプログラミングインタフェース（ＡＰＩ）に対して受信されるウェブサービスコールである請求項１に記載のコンピュータによって実現される方法。
5. 前記データインタフェースは、指定されたデータインスタンスについてのＤＮＳアドレスを使用してアクセス可能なＡＰＩである請求項１に記載のコンピュータによって実現される方法。
6. 前記要求は、
   クレデンシャルに基づいてユーザを認証すること、前記ユーザを認可すること、ユーザ要求を抑えること、ユーザ入力を確認すること、または、前記ユーザ要求およびユーザ応答をマーシャリングするまたはアンマーシャリングすること、からなる群から選択される少なくとも１つのタスクを実行するように動作する構成要素を含むウェブサービス層で受信される請求項１に記載のコンピュータによって実現される方法。
7. 前記ワークフローを生成する際に、前記要求に対応するタスクを実行する前記ホストマシンで使用されるデータベースエンジンに少なくとも部分的に基づいてタスクを選択し、前記選択されたタスクを使用して前記ワークフローを組立てることをさらに含む請求項１に記載のコンピュータによって実現される方法。
8. データ記憶部およびホストマネジャを含むデータ環境と、前記データ環境とは別個の制御環境であって、前記データ記憶部の構成制御を行うサーバーコンピューターを含む制御環境とを有するコンピュータシステムにおける、１つまたは複数のコンピュータが実行可能命令を実行することにより、前記制御環境を使用して前記データ環境の態様を制御する方法であって、
   前記制御環境において、
   前記制御環境の監視要素から、データインスタンスを監視することができる前記データ環境内の少なくとも１つのホストマネジャへ、ステータスについての要求を定期的に送出することと、
   前記ステータスについての前記要求のうちの１つを受信した少なくとも１つの前記ホストマネジャから、第１の応答を受信することと、
   前記データ環境における前記データ記憶部の少なくとも１つのデータインスタンスの構成制御であって、前記少なくとも１つのデータインスタンスを作成、削除、バックアップ、リカバリー、スケーリング、複製、プロビジョニング、アップグレード、パッチ管理、フェールオーバー、または容量管理する、構成制御に関して実行されるべき動作を確定するために、前記第１の応答を解析し、ワークフローであって、前記実行されるべき動作に関して前記データ環境で実行される少なくとも１つのタスクを含むワークフローを、前記実行されるべき動作について生成することと、
   前記ワークフローに含まれる各タスクを実行し、前記タスクの実行に関する情報を有する第２の応答を返す前記少なくとも１つのホストマネジャに対して、状態情報を送出することであって、前記ワークフローの最終タスクではないタスクの実行が成功すると、前記最終タスクではないタスクの後続のタスクについての前記状態情報を前記少なくとも１つのホストマネジャに送出することと、および、
   前記ワークフローの最終タスクが終了したことを示す応答が前記ホストマネジャから受信されると、前記実行されるべき動作についての情報を、前記データ環境用のログに記憶し、前記実行されるべき動作が終了したという通知を、制御インタフェースを通して送出することを含み、
   前記データ環境において、
   前記データ環境のデータインタフェースは、前記実行されるべき動作が終了したという通知が、前記制御インタフェースを通して送出された後には、前記データ環境内のデータへのアクセスを、前記制御環境を介さず直接受け付けることを有し、
   顧客が自動スケーリングプランサービスに加入している場合、前記加入した顧客のリソースの容量のスケーリングは、前記容量を自動的にスケールアップまたはスケールダウンすることにより前記容量を管理するように構成される
   方法。
9. 前記データインスタンスは、前記データ環境内のリレーショナルデータベースに対応する請求項８に記載のコンピュータによって実現される方法。
10. 前記実行されるべき動作を確定するために前記第１の応答を解析することに応答して、前記実行されるべき動作についての前記情報を、ジョブキューに格納することをさらに含み、
    前記実行されるべき動作についての前記情報は、前記ワークフローを生成するために、前記ジョブキューから抽出することができる請求項８に記載のコンピュータによって実現される方法。
11. 前記少なくとも１つのホストマネジャからの前記第１の応答が所定の期間内に受信されないとき、ステータスについてもう１つの要求を送出すること、および、
    前記少なくとも１つのホストマネジャからの前記第１の応答が、所定数の要求後に受信されないとき、前記データ環境に関して実行されるべき第２の動作を確定し、前記第２の実行されるべき動作について第２のワークフローを生成することをさらに含む請求項８に記載のコンピュータによって実現される方法。
12. データ記憶部およびホストマシンを含むデータ環境と、前記データ環境とは別個の制御環境であって、前記データ記憶部の構成制御を行うサーバーコンピューターを含む制御環境とを有するコンピュータシステムにおいて、
    少なくとも１つのプロセッサと、
    命令を含むメモリとを備え、前記命令は、前記少なくとも１つのプロセッサによって実行されると、
    前記制御環境において、
    前記データ環境における前記データ記憶部の少なくとも１つのデータインスタンスの構成制御であって、前記少なくとも１つのデータインスタンスを作成、削除、バックアップ、リカバリー、スケーリング、複製、プロビジョニング、アップグレード、パッチ管理、フェールオーバー、または容量管理する、構成制御に関して実行されるべき動作を確定するために、前記制御環境の制御インタフェースを通して受信される要求を解析し、
    前記実行されるべき動作についてのワークフローであって、前記実行されるべき動作に関して前記データ環境で実行されるべき少なくとも１つのタスクを含む、ワークフローを生成し、
    前記ワークフローの各タスクについて、前記タスクを実行し、前記タスクの実行に関する応答を返すように動作する前記データ環境内のホストマシンに要求を送出し、
    前記ワークフローの最終タスクが終了したことを示す前記応答が前記ホストマシンから受信されると、前記実行されるべき動作が終了したという通知を、前記制御インタフェースを通して送出させ、
    前記データ環境において、
    前記データ環境のデータインタフェースは、前記実行されるべき動作が終了したという通知が、前記制御インタフェースを通して送出された後には、前記データ環境内のデータへのアクセスを、前記制御環境を介さず直接受け付け、
    顧客が自動スケーリングプランサービスに加入している場合、前記加入した顧客のリソースの容量のスケーリングは、前記容量を自動的にスケールアップまたはスケールダウンすることにより前記容量を管理するように構成される
    システム。
13. 前記要求を受信するように動作する前記制御環境内の外向きＡＰＩをさらに含み、前記要求は、ウェブサービスコールである、請求項１２に記載のシステム。
14. 前記データインタフェースは、指定されたデータインスタンスについてのＤＮＳアドレスを使用してアクセス可能なＡＰＩである請求項１２に記載のシステム。
15. 前記要求を受信し、クレデンシャルに基づいてユーザを認証すること、前記ユーザを認可すること、ユーザ要求を抑えること、ユーザ入力を確認すること、または、前記ユーザ要求およびユーザ応答をマーシャリングするまたはアンマーシャリングすること、からなる群から選択される少なくとも１つのタスクを実行するように動作する前記制御環境内のウェブサービス層をさらに含む請求項１２に記載のシステム。

Images