JP6346377B2 - １つまたは複数のクラウドシステムにアプリケーションを移動可能にデプロイする方法及びシステム - Google Patents

Description

本発明は、１つまたは複数のクラウドサービングインフラストラクチャへのサービスのプロビジョニングあるいは準備と移動可能性とを必要とするアプリケーションを効率的にデプロイできる方法及びシステムに関する。

コンピュータ産業の爆発的な成長により、１つまたは複数の環境（例えば、クラウドサービス）でアプリケーションを起動できるプロビジョニングを必要とするアプリケーションの数が増加した。そのようなアプリケーションは、異なるハードウェア／ソフトウェアプラットフォームに対して設計され得るビジネスアプリケーション、ソーシャルメディアアプリケーション、ゲームアプリケーション等を含む。時には、最初は１つの特定の環境で起動するようにプロビジョニングされたアプリケーションが、異なる環境で起動することが必要になる場合がある。別のまたは異なる環境でアプリケーションが成功裏に起動するために、アプリケーション開発者は、各環境でアプリケーションの実行に成功する再プロビジョニングに要する必要最小限ハードウェア／ソフトウェアリソースを識別／指定することが求められる。

残念ながら、最初の起動の要件を設計した開発者／プロビジョニングエンジニアが、同じエンティティの仕事にもはや関わってないことがよくある、または、最初に割り当てられたリソースが、時間が経って時代遅れ若しくは置き換えられてよいと決定される場合がある。結果として、古い方のアプリケーションを維持し、且つ、異なる起動環境にアプリケーションを移動することは非常に難しいことが多い。異なる起動環境は、完全に異なったリソース、プロビジョニングルール、及び、他の動作要件を有すことがある。

アプリケーションの移動は、例えば、第１のリソースセットを有する１つのクラウドサービスから第１のリソースセットとは異なる第２のリソースセットを有する第２のクラウドサービスに切り替えることを含み得る。切り替える必要は、コスト、性能、使用量、リソースの利用可能性等によって推進される場合があり、アプリケーション実行環境のコスト効率を高くしながら、環境リソースを最適、有効に使用するために変更が必要となり得る。新しい環境でアプリケーションを成功裏に実行するためには、新しい環境内で最小のリソース要件を満たし、リソース／サービス依存性の準備を整え、明確に規定することを確実にするために多くのリエンジニアリングを行わなければならない。通常、アプリケーション環境へのこのような変更は、手動で行われる。しかし、多くの場合、手動の検証はコスト効率が高くないことに加えて、詳細が見落とされたり、失われたりする確率が高いので、望まない結果や過度のリエンジニアリングにつながってしまう。

本発明の実施形態は、上記背景の下になされたものである。

本発明の実施形態は、１つのクラウドサービス／プラットフォームにおいて、または複数のクラウドサービス／プラットフォームに亘ってアプリケーションのインスタンスをデプロイできるマルチクラウドデプロイメント機構を提供する。デプロイメント機構は、アプリケーションをインスタンス化するクラウドサービス／プラットフォームのいずれかにおいて、アプリケーションで提供される仕様を用いて、サービス、リソース、及び、サービス状態を管理するワークフローを含む。デプロイメント機構は、クラウドサービス環境でアプリケーションを成功裏に実行するためにアプリケーション開発者がリソース要件を指定するフレームワークを提供し、デプロイメント機構は、環境に必要なリソース／サービスを自動的にプロビジョニングする。必要なリソース／サービスをプロビジョニングするタスクを達成するために、デプロイメント機構は、必要または十分なサービス／リソースがプロビジョニングされたか否かを決定するために、また、アプリケーションの実行に成功する環境のステータスを提供するために、取る必要のあるアクションを決定し、各ワークフローを通してアクションをスケジュールし、アクションを監視し、且つ、取られたアクションのログを提供する。

一実施形態においては、フレームワークは、記述子法を備えてよい。記述子法は、デプロイメントエンジニアが、具体的なサービスを詳細に識別、プロビジョニングする必要なく、アプリケーションに必要なリソースを指定することを可能にする。記述子法は、一実施態様においては、ＪＳＯＮ記述子ドキュメントの形態であってよい。ＪＳＯＮ記述子ドキュメントは、アプリケーションが実行するように設計された各環境のレコードを含む。ＪＳＯＮレコードを使用して、クラウドサービス、ネットワーク、ストレージ、プロセッサの種類、または、アプリケーションが実行する環境内にプロビジョニングする必要のある任意の他の種類の技術リソースを含む、アプリケーション実行に必要な全てのサービスとリソースの仕様の概要を記述する。デプロイメント機構は、次に、取る必要のある具体的なアクションに要件を翻訳する。翻訳で識別された各アクションは、インスタンス化されると必要なリソースまたはサービスをプロビジョニングするように設計されたワークフローに関連付けられる。デプロイメント機構は、従って、相互依存のサービスからなる複雑でスケーラブルなシステムであり、相互依存のサービスは、集中メッセージブローカを通して互いに通信して、情報を取得し、ワークフロータスクの複雑な時間依存のオーケストレーションの調整あるいは編成の調整を行う。デプロイメント機構は、疎結合の分散サービスコンポーネントとバックエンドサービスを含み、アプリケーションをホストする信頼できる環境プラットフォームを提供する。デプロイメント機構は、ゲームアプリケーション、娯楽アプリケーション、ビジネスサービスアプリケーション、インターネットアプリケーション、ウェブサイト割り当て等のアプリケーションのデプロイメント、テスト、制作、及び、保守の間、サービス／リソースをプロビジョニング、コンテキスト化、構成、使用、監視、トラブルシューティング、スケール、及び、廃止する能力を提供する。

一実施形態において、方法が提供される。方法は、クラウドサービス環境においてアプリケーションを実行する要求を検出することを含む。要求に応答して、記述子ファイルが、リポジトリからアクセスされる。記述子ファイルは、１つまたは複数のクラウドサービスを実行するために各アプリケーションに関して規定された１つまたは複数の記述子レコードを含む。アプリケーションの記述子レコードが、要求に応答して、記述子ファイルから読み出される。記述子レコードは、クラウドサービス環境に固有で、クラウドサービスでアプリケーションを実行するのに必要な環境リソースまたはサービスの詳細を提供する。記述子レコードに規定されたリソースとサービスの要件は、アプリケーション実行のためのサービスとリソースをプロビジョニングするためにクラウドサービス環境で取る必要がある１つまたは複数のアクションに翻訳される。取られたアクションのステータスが、要求に応じて提供される。ステータスは、クラウドサービスでアプリケーションを成功裏に実行するために必要なリソースとサービスがプロビジョニングされたか否かの決定に使用される。

別の実施形態において、方法が開示される。方法は、アプリケーション実行のためにクラウドシステムで必要とされる１つまたは複数のリソースと１つまたは複数のサービスの属性を受信することを含む。受信した属性を用いて、アプリケーションの記述子レコードが生成される。記述子レコードは、クラウドシステムに固有の環境プロファイルを規定する。記述子レコードは、アプリケーションを成功裏に実行するためにクラウドシステムに必要なリソースとサービスをプロビジョニングするために取ることが必要な１つまたは複数のアクションにリソースとサービスの要件を翻訳することによって生成される。記述子レコードは、クラウドシステムにおいてアプリケーションを後に実行する際に読み出すために、デプロイメントシステムデータベースに保持される記述子ファイルに記憶される。読み出しによって、クラウドシステムで必要なサービスとリソースのプロビジョニングのために記述子レコードで識別されたアクションをトリガして、アプリケーション実行の成功を可能にする。

発明の他の態様は、例を挙げて発明の原理を示す添付の図面と以下の詳細な説明とから明らかにされる。

発明は、添付の図面と併せて以下の説明を参照することでよく理解されるであろう。

発明の実施形態に係る、デプロイメント機構を備えたシステムの概略を示す図である。 発明の実施形態に係る、クラウドシステムにデプロイされたサービス（すなわち、アプリケーション）のライフサイクルを示す図である。 発明の実施形態に係る、デプロイメント機構の簡単な概略図である。 発明の異なる実施形態に係る、デプロイメント機構の様々なコアサービスモジュール及びサービスコンポーネントを識別するサービスアーキテクチャを示す図である。 発明の実施形態に係る、例示の環境公開ビューを示す。 発明の実施形態に係る、環境を公開するための例示のプレビューウィンドウ画面表示を示す。 発明の一実施形態における、環境履歴ページ内の特定のワークフローから実行された（ワークフローアクション／アクティビティを識別する）例示のワークフローステップを指定するログの例示のビューを示す図である。 発明の一実施形態に係る、例示の環境アクション（ワークフロー実行）プレビューウィンドウを示す図である。 発明の実施形態に係る、例示の環境アクション（ワークフロー実行）ステータスウィンドウを示す図である。 発明の実施形態に係る、環境履歴の概略をレンダリングする例示の画面を示す図である。 発明の実施形態に係る、環境履歴の概略内のワークフローエラーをレンダリングする例示の画面を示す図である。 発明の実施形態に係る、環境履歴の要求者の詳細をレンダリングする例示の画面を示す。 発明の実施形態に係る、アプリケーション実行に使用されるユーザプロファイルの例示の画面を示す図である。 発明の実施形態に係る、個人がデプロイメント機構へのアクセスを要求する一般的ワークフローを示す図である。 発明の実施形態に係る、デプロイメント機構に提供されるアクセスレベル間の階層関係を示す図である。 発明の実施形態に係る、デプロイメントシステム環境記述子ワークフローを示す図である。 発明の実施形態に係る、アプリケーションサービス状態を捕捉する例示の画面表示を示す図である。 発明の実施形態に係る、デプロイシステムの例示の公開モデルを示す図である。 発明の実施形態に係る、デプロイメント機構が従う方法を示すプロセスフロー図である。 発明の代替実施形態に係る、デプロイメント機構が従う方法を示すプロセスフロー図である。

本発明の実施形態は、１つまたはマルチクラウドのデプロイメント機構を提供する。１つまたはマルチクラウドのデプロイメント機構は、アプリケーションのインスタンスを１つまたは複数のクラウドサービス／プラットフォームにデプロイするのを可能にし、且つ、デプロイしたクラウドサービス／プラットフォームでアプリケーションインスタンスを成功裏に実行するために必要なリソース／サービスを自動的にプロビジョニングするのを可能にする。デプロイメント機構は、互いに通信してワークフロータスクの複雑なオーケストレーションあるいは組織化を調整する相互依存のサービスからなるスケーラブルなシステムである。ワークフロータスクは、時系列で、または、逐次的に行われ、その間デプロイメント機構フレームワークは、どのタスクが完了し、他のタスクの前にどのタスクを処理する必要があるかを追跡して調整された相互依存の実行を維持する。デプロイメント機構は、集中コアサービスコンポーネントセットと、バックエンドサービスセットと、サービス層とを含む。コアサービスコンポーネントは、エンドユーザとやりとりし、動作ワークフローを管理し、且つ、コアサービスコンポーネントと環境内にホストされる環境リソースとの間の通信を調整するように構成される。コアサービスコンポーネントは、サーバ／プロセッサ、メモリ等のリソースをプロビジョニングし、サービス／アプリケーションを設定し、ソフトウェアをデプロイし、ドメインネーミングシステムを設定し、リソース／サービスをオートスケールし、アプリケーションとリソースのステータスを監視し、ストレージを管理するように等、構成される。コアサービスコンポーネントは、サービス層を介してバックエンドサービスと通信する。サービス層は、コアサービスコンポーネントとバックエンドサービスの連携として働く。分散サービス層は、抽象化層を提供し、抽象化層によって、コアサービスコンポーネントは、メッセージベースの通信を用いて相互運用可能になり、技術の進化にあわせて容易に交換可能になる。スケーラブルなフレームワークによって、新しい技術をサービス層内でラップし、コアサービスコンポーネントセットに影響を与えることなく、クラウドサービスに組み込むことができる。スケーラブルなフレームワークによって、エンドユーザは、ニーズの変更及び／または経時的に起こった技術的進歩に基づいて、既存のサービスを更新し、古いサービスを変更若しくは取り除き、新しいサービスを組み込むことができる。

一実施形態においては、フレームワークは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）記述子ファイルの形式で提供される。要件を規定するＪＳＯＮ記述子の使用は、例示的なもので、他のプログラム言語または他の構文若しくはファイル形式またはデータ構造を使用してよいので、制限とみなすべきではない。記述子ファイルは、名前／値のペアの木構造を表し、複数のレコードを含み、記述子ファイルの各レコードは、特定のクラウドサービスまたはサーバコンピューティングシステムの環境でアプリケーションを実行するためのサービス／リソース要件を指定する。各レコードは、例えば、アプリケーションが特定の環境で実行するためにプロビジョニングされる必要があるストレージ、ネットワーク、処理リソース、クラウドサービス、及び、他の種類の技術的リソースの要件を指定する。

図１は、一実施形態において、クラウドサービスの特定の環境にアプリケーションをデプロイするために使用されるデプロイメント機構の簡単な概略図を示す。この実施形態においては、アプリケーション１１０を開発しているアプリケーション開発者は、アプリケーションプログラミングインタフェース（ＡＰＩ）を介してデプロイメント機構にアクセスして、アプリケーション１１０を成功裏に実行するために必要とされるリソース／サービスを指定できる。デプロイメント機構は、クラウドエコシステム（ＥＣＯ）コアモジュール１２０として図１に表され、ＥＣＯコアにアクセスするためのＡＰＩは、ＥＣＯ ＡＰＩとして表される。デプロイメント機構１２０によって、開発者は、アプリケーション１１０が実行する環境１２２を記述できる。例えば、デプロイメント機構は、グラフィカルユーザインタフェースまたはコマンドラインインタフェースを通してアクセスされるＡＰＩ等のツールを提供して、開発者が、アプリケーション１１０が実行できるように環境に必要な最小のリソース及び／またはサービスを指定するのを可能にしてよい。上記ツール（複数可）は、例示的で、包括的とみなすべきではない。開発者が、自分が開発したアプリケーションを実行する環境を指定するのを可能にする他のツールまたは方法が提供されてよい。開発者によって指定された環境記述１２２は、ＪＳＯＮ記述子ファイル等の記述子ファイル１２４に更新される記述子レコードとして提供される。代替実施形態において、開発者は、アプリケーションのコードをデプロイメント機構１２０に提供してよい。デプロイメント機構１２０は、アプリケーションのコードを分析して、特定の環境でアプリケーションを成功裏に実行するために必要なリソース／サービスを決定してよい。リソース／サービス要件情報は、記述子ファイルに更新される記述子レコードを規定するために使用され、且つ、特定の環境にサービス／リソースをプロビジョニングするためにアプリケーション実行中に用いられる。

名前が示すように、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｎｌｉｎｅ Ｎｏｔａｔｉｏｎ）記述子は、ＪａｖａＳｃｒｉｐｔ（登録商標）スクリプト言語を用いて、属性名／属性値ペアの形でデータオブジェクトを規定し、アプリケーションとサービスコンポーネント間でデータを送信するのに用いられる。ＪＳＯＮは、コード言語の一例にすぎず、機能が提供される限り、他の言語を使用してよいことは理解されたい。この例において、ＪＳＯＮ記述子１２４は、開発者が提供した仕様または機構によって識別された要件を受け、アプリケーションが実行のためにホストされるクラウドサービスの各環境に関して必要なサービス／リソース（すなわち、属性名／属性値のペアのうちの値）をプロビジョニングするために必要なアクションにサービス／リソース要件（すなわち、属性名／属性値のペアのうちの属性名）をマッピングするレコード（例えば、記述子またはＥＣＯレコード１２６）を生成する。記述子レコードは、アプリケーションのインスタンスに関連付けられるので、アプリケーションを後に環境で実行する必要がある時、アプリケーションの正確な記述子レコードがすぐに識別され、適切なリソースとサービスが、環境でアプリケーションインスタンスが成功裏に実行するためにプロビジョニングされ得る。一実施形態においては、生成されたレコード１２６のそれぞれは、例えば、各環境でアプリケーションが成功裏に実行するために必要な、データベース／ストレージ１２４ａ、プロセッサ１２４ｂ、ネットワーク１２４ｃ、キー管理１２４ｄ、他のリソース１２４ｅ、他のサービス１２４ｆ等、最小のリソース／サービスを識別する。ＥＣＯ記述子レコード（すなわち、記述子レコード）で提供された情報を用いて、ＥＣＯコア（すなわち、デプロイメント機構）は、サービス／リソースをプロビジョニングするために取るべき必要なアクション１２８を識別する。ワークフロー１２８ａが、ＥＣＯ記述子レコードで識別された各アクションに関してインスタンス化され、その結果、必要なサービスとリソースが各環境にプロビジョニングされる。識別されたアクションは、アプリケーションのインスタンスを実行する前に取る必要のあるアクション、アプリケーションのインスタンスを実行中に取る必要のあるアクション、及び、アプリケーションのインスタンスの完了後に取る必要のあるアクションを含んでよい。従って、アクションは、必要なリソースをプロビジョニングし、プロビジョニングされたリソースのリソース依存性をチェックし、１つまたは複数のリソース若しくはサービスを移行し、サービスを停止し、アプリケーション及び／若しくはリソース／サービスをインスタンス化し、アプリケーションの完了の成功を検証し、エラーログをチェックしてアプリケーションの実行に成功したか否かを決定する。

ワークフロー１２８ａが識別されると、ワークフロー１２８ａは、ワークフローサービスワーカプロセスのセットによって実行されて、適切なクラウドサービス１３０にリソース／サービスをプロビジョニングし、アプリケーションをインスタンス化し、サービス／リソースに関連して取られた／取られなかったアクションのステータスのログを生成し、且つ、取られた／取られなかったアクションのステータスを返信するという必要なアクションをワークフローが取ることを可能にする。アプリケーション実行更新を開発者に提供するためにアクションステータスを用いてよい。アプリケーションを実行するためのリソース／サービスがプロビジョニングされたクラウドサービス環境は、プライベートまたはパブリックに利用可能なクラウドサービス／環境であってよい。

ＥＣＯレコードは、アプリケーションにマッピングされる１つまたは複数のリソース／サービスで検出された変更に基づいて、定期的に更新される。例えば、一実施形態においては、古いリソースが取り除かれてよく、新しいリソースが追加されてよく、障害、日常の保守等のために、リソースは、取り除かれたり、変更されたり、置き換えられたり、及び／または、アップグレードされてよく、ＥＣＯコアによって、バックグラウンドで１つのリソースから他のリソースへのシームレスな移行が可能になり、その結果、アプリケーションは、顕著なダウンタイムなく実行する。一実施形態においては、古いリソースが取り除かれ、新しいリソースが追加されると、ＥＣＯコアは、古いリソースから新しいリソースへのデータ移行を自動でオーケストレートし、特定の環境におけるアプリケーションのＥＣＯレコードを更新して、変更を反映する。代替例においては、既存のリソースは、日常の保守の一部としてアップグレードされてよい。例えば、追加のストレージが、既存のストレージリソースプロバイダに追加されてよい。この実施形態においては、アップグレードは、サーバまたはクラウドサービスで実行するアプリケーションの性能に影響を与えることなく、バックグランドでシームレスに行われ得、アップグレードによるリソースへの変更は、実質的にリアルタイムでＥＣＯレコードに更新され得る。一実施形態においては、１つまたは複数のリソースへのアップグレードは、一時的なアップグレードであってよく、アプリケーションが最適に実行できるように行われてよい。この実施形態においては、ＥＣＯレコードは、アップグレードによる変更を反映するように更新されなくてよい。代替実施形態においては、リソースに対するアップグレードは、永続的であってよく、このようなアップグレード情報は、ＥＣＯレコードに更新されてよい。同様に、サービスがアップグレードされる時、ＥＣＯレコードは、アップグレード情報を含むように更新されてよい。デプロイメント機構内のサービス層は、コアサービス／リソース要件を受け止める抽象化層を提供し、それらの要件をクラウドサービス内で利用可能な実際のサービス／リソースにマッピングする。

別の実施形態においては、アプリケーションは、１つのクラウドサービスから異なるクラウドサービスに移行されてよい。そのような移行は、アプリケーションに望む性能の種類に基づいて行われてよい。例えば、移行は、リソース利用可能性等に基づいて、コストを減らし、性能を向上させるために、ＥＣＯコアによって自動的に開始されてよい。いくつかの実施形態においては、所定のルールセットが、アプリケーションに関して規定されてよく、サービス及び／またはリソースを移行する決定は、所定のルールに基づいて自動であってよい。所定のルールは、開発者によって規定されてよく、環境で検出された変更に基づいて、開発者またはデプロイメント機構のいずれかによって定期的に更新されてよい。例えば、所定のルールのうちの１つは、コストに基づいて、環境及び／またはリソース／サービスを選択することを示してよい。別の例においては、所定のルールは、性能に基づいて、環境及び／またはリソース／サービスを選択することを示してよい。両方の例において、ＥＣＯコアは、定期的に、（ａ）所定のルールに基づいて、アプリケーションのインスタンスを実行するためにクラウドにプロビジョニングされた様々なリソースから受信されたデータを収集、分析してよく、（ｂ）リソースの価格またはアプリケーションの性能を決定してよく、（ｃ）様々なリソース／環境のプロファイルを生成してよく、（ｄ）同じクラウドサービスまたは異なるクラウドサービスでリソースのうちの特定のリソースを異なるリソースに移行すべき時、１つのクラウドサービスから別のクラウドサービスにアプリケーションを移行すべき時、既存リソースの使用を継続すべき時、既存クラウドサービスの使用を継続すべき時等を決定してよい。分析及び決定に基づいて、ＥＣＯコアは、クラウドサービスと、クラウドサービスの既存のリソース／サービスの使用を継続してよく、または、古いクラウドサービスから新しいクラウドサービスにアプリケーションの移行を行ってよい。移行は、新しいクラウドサービスにプロビジョニングする必要のあるリソース／サービスを識別することと、新しいクラウドサービスにリソース／サービスをプロビジョニングするように適切なワークフロー（複数可）をトリガすることと、アプリケーションをインスタンス化して新しいクラウドサービスにプロビジョニングされたサービス／リソースを使用することを含む。移行は、ＥＣＯレコード内のアプリケーションインスタンスを再マッピングして、１つまたは複数のリソース／サービスへの変更またはクラウドサービスへの変更を反映することを伴ってよい。

一実施形態においては、所定のルールは、アプリケーションに対する時間的及び／または地理的需要に基づいて、リソース利用可能性に基づいて、または、異なる地理における異なる期間のリソースの使用量履歴の予測分析に基づいて、移行を開始することを示してよい。アプリケーションのメタデータで提供された使用量履歴データを調査して、異なる時間中、及び、異なるジオロケーションにおけるリソースの使用量パターンを決定し、異なるジオロケーションにおける異なる期間のアプリケーションの需要を識別し、異なる期間中のリソース／サービスの利用可能性、利用可能なリソース／サービスのコスト、リソース／サービスの需要を満たす能力、所定のルールによって規定されたアプリケーションに関して期待される性能の種類（すなわち、コストベース、性能ベース、リソース最適性ベース等）等を決定する。調査に基づいて、既存の環境を維持する決定、または、異なる環境に移行する決定が行われる。

引き続き図１を参照する。アプリケーションを実行するためのリソースとサービスのプロビジョニングのワークフローは、アプリケーションが実行のためにデプロイされるプライベートまたはパブリッククラウド（１３０‐ａ〜１３０‐ｎ）のうちの任意のクラウドにデプロイされてよい。アプリケーションが新しいクラウドサービスに移行する時、対応するワークフローが、新しいクラウドサービスで識別、デプロイされる。一実施形態においては、アプリケーションを移行すると、アプリケーションの新しいインスタンスが新しいクラウドサービスのために提供され、アプリケーションの新しいインスタンスを移行されたクラウドサービスに関連付けられたリソース／サービスにマッピングする新しいＥＣＯレコードが生成される。この実施形態においては、最初のＥＣＯレコードは、古いクラウドサービスに関連付けられたリソース／サービスに引き続きマッピングされてよく、その結果、古いクラウドサービスで実行するアプリケーションが選択される場合、既存のアプリケーションインスタンスは、古いクラウドサービスのアプリケーションインスタンスにプロビジョニング、マッピングされたリソース／サービスを実行、使用してよい。代替実施形態においては、再マッピングの結果、既存のＥＣＯレコードが更新されて、古いクラウドサービスからのリソース／サービスに代わって新しいクラウドサービスのリソース／サービスにアプリケーションインスタンスがマッピングされてよく、その結果、アプリケーションが実行される時はいつでも、アプリケーションは、新しいクラウドサービスのリソース／サービスを用いて、新しいクラウドサービスで実行する。

図１Ａは、一実施形態において、選択された環境で実行するためにデプロイされたアプリケーション１１０の例示のライフサイクルを示す。デプロイメントの一部として、ＪＳＯＮ記述子ファイル１２４が、コマンドラインインタフェース１３２またはグラフィカルユーザインタフェース１３４を用いて、ＥＣＯ ＡＰＩ１３１等、ＡＰＩを介してアクセスされてよい。ＪＳＯＮ記述子ファイル１２４は、環境データベースで維持されてよく、ＥＣＯコア１２０によって管理されてよい。ＪＳＯＮ記述子ファイルは、アプリケーションに関して規定された各サービス環境（１３０‐ａ〜１３０‐ｎ）のサービス記述子レコード（１２６‐１〜１２６‐ｎ）を識別する。例えば、図１Ａに示すように、サービス記述子レコード１（１２６‐１）は、クラウドサービス１（１３０‐ａ）のリソース／サービス要件の概略を記述し、サービス記述子レコード２（１２６‐２）は、クラウドサービス２（１３０‐ｂ）に固有である等である。ＪＳＯＮ記述子ファイル１２４で指定される１つまたは複数のサービス記述子レコードは、異なるクラウドサービスで実行する同じアプリケーションに関してよい。サービス記述子レコードは、アプリケーションを成功裏に実行するために委託する必要のある様々なリソース／サービスの最小の要件を特定する。アプリケーションは、ビジネスアプリケーション、ビデオゲームアプリケーション、ソーシャルメディアアプリケーション等であってよい。ＥＣＯ機構は、フレームワークを提供し、そのフレームワークによって、アプリケーションコードがシステム内に受け入れられるのを可能にし、アプリケーションの実行可能インスタンスが様々な環境に対して生成され、アプリケーションの実行に必要なリソース／サービスがプロビジョニングされ、特定の環境に対してアプリケーションの適切なインスタンスが識別、デプロイされ、アプリケーション及びプロビジョニングされたリソース／サービスのステータスを含むデプロイメントの結果の報告を返すのを可能にする。

一実施形態においては、アプリケーションの開発者は、アプリケーションコードをＥＣＯ機構に提供してよい。ＥＣＯ機構内のロジックは、アプリケーションコードを分析して、各環境においてゲームのインスタンス実行に必要なリソースを識別してよい。ＥＣＯ機構は、ＪＳＯＮ記述子ファイル上に必要なリソース情報を更新してよく、検証及び／または更新のために開発者に情報を提示してよい。開発者は、ＪＳＯＮ記述子ファイルを編集して、必要なリソース／サービスを更新してよい。代替実施形態においては、ＪＳＯＮ記述子ファイルのリソース情報の全ては、開発者によって更新される。

アプリケーションが、実行のために特定のクラウドサービスにデプロイされる時、ＥＣＯコアは、その特定のクラウドサービスに関連付けられたアプリケーションに関して適切な記述子レコードを識別し、識別されたサービス記述子レコードを分析して、行う必要のあるアクションを決定し、そのアクションをレビューのためにエンドユーザに提示する。ユーザが承認／受諾／検証すると、ＥＣＯコアは、アプリケーションを成功裏に起動するためにクラウドサービスに必要なリソースをプロビジョニングする適切なワークフローを開始する。取られたまたは取られなかったアクションの結果がログされ、アクションのステータスを提供する定期的な報告が生成される。様々なアクションのステータスに基づいて、ＥＣＯコアは、追加のリソースを委託し、１つまたは複数のプロビジョニングされたリソースをアップグレードし、１つまたは複数のリソースを移行する等してよい。ＥＣＯ機構は、必要に応じて、アプリケーションの速度を上げることも含めて、アプリケーション全体のライフサイクルを有効に管理する。

図１Ｂは、デプロイメント機構の簡単なブロック図を示す。前述のように、デプロイメント機構は、クラウドサービスで必要とされるコアサービスコンポーネントセットと、利用可能なバックエンドサービス及びリソースと、コアサービスコンポーネント要件と利用可能なバックエンドサービスとの間の連携として働くサービス層とを含む。サービス層は、コアサービスコンポーネントをより相互運用可能でありながら交換可能にする抽象化層を提供する。詳細には、サービス層は、ロジックコンポーネントを含み、ロジックコンポーネントは、要件を抽出し、要件を解釈し、利用可能なサービスとリソースにマッピングし、そのサービスとリソースに接続する。この目的で、ＥＣＯサービス層内の抽出器コンポーネントは、特定のクラウドサービスで実行するようにスケジュールされたアプリケーションによって、その特定のクラウドサービスに関して規定されたクラウドサービス要件仕様１２４ａを識別する。クラウドサービス要件仕様１２４ａは、記述子ファイル内の記述子レコードで提供される。要件仕様は、ＥＣＯ機構に保持される記述子レコードにアプリケーション開発者によって手動でアップロードされてよい。記述子レコードの仕様１２４ａを調査して、アプリケーション実行のためにどの特定のリソースとサービスが必要かを決定する。いくつかの実施形態においては、要件は、(例えば、特定のブランドまたは特定の能力のＳＤＲＡＭメモリの量に関して等)、非常に具体的に規定されてよく、また、他のいくつかの実施形態においては、要件は、（例えば、必要とされる最小メモリ要件を規定する等）、より一般的に規定されてよい。

抽出器コンポーネント１２０ａによって提供された情報を用いて、ＥＣＯサービス層内のマッパーコンポーネント１２０ｂは、利用可能なバックエンドサービス及びリソースを調査して、アプリケーションの要件を満たす特定のサービスとリソースを識別してよい。特定のサービスとリソースを識別すると、ＥＣＯサービス層内のコネクタコンポーネント１２０ｃは、識別されたサービスとリソースをアプリケーションにマッピングする。一実施形態においては、マッピングは、アプリケーションを成功裏に実行するために識別されたサービスとリソースをプロビジョニングするために行う必要があるアクションを決定することと、これらのアクションを行う適切なワークフローを識別することと、識別されたワークフローをアプリケーションにマッピングすることとを含み、その結果、アプリケーションのインスタンスを実行すると、マッピングされたワークフローがトリガされて、アプリケーションに適切なサービスとリソースがプロビジョニングされる。

最初のプロビジョニング後、ＥＣＯサービス層内のマッパーコンポーネントは、クライアントサービスで利用可能なリソースとサービスの監視を続けて、追加、削除、アップグレード、変更等によるクライアントサービスに割り当てられたリソース及び／またはサービスに変更があるか否かを決定してよい。監視に基づいて、変更に対応するために追加のワークフロー（複数可）のインスタンス化が必要になる場合がある。これは、例えば、１つまたは複数のワークフローを実行して、サービスを停止、リソースを削除、新しいリソースを追加する等を含み得る。マッパーコンポーネントは、アプリケーションに関するワークフローマッピングを更新して、追加のワークフロー（複数可）を含んでよい。

ＥＣＯサービス層は、従って、アプリケーションに関して規定された要件仕様を翻訳して、特定のリソースとサービスをプロビジョニングするワークフローにマッピングすることによって、翻訳サービスを提供する。いくつかの実施形態においては、翻訳サービスは、記述子レコードで指定された正確なリソース／サービスをプロビジョニングするワークフローを識別、マッピングしてよく、他の実施形態においては、翻訳サービスは、仕様によって必要とされるリソース／サービスと同等であるが互換性のあるリソース／サービスをプロビジョニングするワークフローにマッピングしてよい、このようにして、実際のサービス／リソースに対する仕様要件のマッピングで抽象化レベルを提供する。

図２は、デプロイメント機構のサービスアーキテクチャの簡単なブロック図を示す。デプロイメント機構は、完全なマルチクラウドホスティング管理ソリューションである。デプロイメント機構の中心には、相互依存のサービスからなる複雑でスケーラブルなシステムがあり、相互依存のサービスは、集中型メッセージブローカを介して互いに通信して情報を交換し、クラウドサービスにデプロイされたアプリケーションを実行するワークフロータスクの複雑なオーケストレーションを調整する。デプロイメント機構内の集中コアサービスコンポーネントセットは、エンドユーザとのやりとりと、動作ワークフローの管理と、デプロイメント機構を用いてホストされたサービス、アプリケーション、及び、環境間の通信の調整とを担当する。デプロイメント機構内のサービスコンポーネントの幾つかの機能を、図２に示す例示のコンポーネントを参照して詳細に記載する。図２に示すコンポーネントは例示的であり、より少ないまたはより多い数のコンポーネントがコアサービスアーキテクチャ内に含まれてよいことに注意されたい。サービス要件は経時的に変わるので、コンポーネントの一部は、非推奨となってよく、アプリケーションのサービス要件によって規定された必要なサービス／リソースのプロビジョニングを可能にする新しいコンポーネントが追加されてよい。コアサービスアーキテクチャは、このように変化するサービス要件に容易に動的に適応するこのような柔軟性を提供する。

ブローカ管理サービス２．２は、対応するＡＰＩを通して、メッセージングインタフェースをメッセージングブローカ管理に提供する。

メッセージングブローカ２．１は、通信ハブとして働き、メッセージングブローカ２．１を介して、ＥＣＯシステムに備えられたデプロイメント機構の異なるモジュール／コンポーネントは、互いに通信して、サービス要求の送信、サービスのプロビジョニング、記述子レコードの更新、サービス／リソースの設定、アプリケーションのインスタンス化、アクションの識別、ワークフローのインスタンス化、ステータス情報の受信、及び、規定された環境（すなわち、クラウドサービングインフラストラクチャ）におけるアプリケーション実行に成功するために必要な他の動作を行う。メッセージングブローカ２．１は、例えば、ワークフローサービス２．１４と様々なコンポーネント間の対話を促進してよい。ワークフローサービス２．１４は、アプリケーション要件及びサービス／リソース依存性に基づいて、異なるタスクのシーケンスをインテリジェントに予測するロジックを含む。メッセージングブローカ２．１は、プロビジョニングされたリソース／サービスに関する情報と対応する性能ステータス情報とを集めるように、プロビジョニングされた異なるリソース／サービスに関するメッセージ交換を有効に可能にし、次に、情報を用いて、プロビジョニングされたリソース／サービスがアプリケーションに関して規定された必要な性能基準を満たすか否かが決定される。この目的で、メッセージングブローカ２．１は、監視サービス２．２０がプロビジョニングサービス２．９と定期的にメッセージを交換して、アプリケーションにプロビジョニングされた様々なリソース／サービスに関する情報を要求、取得して、リソース／サービスが最適に機能しているかを決定するのを促進してよい。

メッセージングブローカ２．１は、例えば、インフラストラクチャ管理サービス２．２８、設定管理サービス２．１７、環境サービス２．７、課金サービス２．１９、プロビジョニングサービス２．９、監視サービス２．２０、Ｓｅｎｓｕ（商標）コンポーネント２．３０等にルートを提供して、互いのメッセージ交換を調整する。一実施形態においては、Ｓｅｎｓｕ（商標）コンポーネント２．３０は、アプリケーションのリソース及び／またはサービスの全てのインスタンスの健全性を監視してよく、任意の所定の閾値に到達した場合、適切なアクションを取るようにＥＣＯ機構に通知する信号を生成する。ＥＣＯシステムは、次に、所定のルールセットを実行して、インスタンスまたはリソース／サービスを（例えば、オートヒーリングの一部として）置き換える必要があるか否か、または、（例えば、オートスケールの一部として）スケールアップ若しくはスケールダウンする必要があるか否かを決定する。従って、所望のクラウドサービス環境内でコスト効率及び／または性能効果がより高い同等のリソース／サービスが利用可能か否かを決定するために、メッセージを交換して、異なるクラウドサービス環境で利用可能なリソース／サービスと、それらのコスト及び／または性能に関する情報を取得してよい。そのような情報を使用して、必要に応じて、リソース／サービスの切り替えを実施して、アプリケーション実行に最適な環境を提供してよい。様々なサービスモジュール（監視サービスモジュール２．２０、プロビジョニングサービスモジュール２．９等）を用いてメッセージングブローカによって促進されるメッセージ交換を使用して、プロビジョニングされたサービス／リソースがクラウドサービス環境でアプリケーションの最適な実行を可能にするのに十分か否か、または、アプリケーションの最適な実行を可能にするために追加／代替のリソース／サービスをプロビジョニングする必要があるか否かを決定してよい。いくつかの実施形態においては、リソース及び／またはサービスの性能に関連する情報に基づいて、メッセージングブローカ２．１は、インフラストラクチャ管理サービス２．２８、ブローカ管理サービス２．２、環境サービス２．７間のメッセージ交換を調整して、関連するリソース／サービスの動的切り替え／プロビジョニングを可能にして、アプリケーションの実行を最適化してよい。そのようなステータスのチェックと切り替えは、アプリケーション実行前のリソース／サービスがプロビジョニングされている間、アプリケーション実行中、及び／または、アプリケーション実行終了後に行われてよい。いくつかの実施形態においては、切り替えは、環境内にプロビジョニングされたリソース／サービスで検出された変更によって引き起こされてよい。変更は、既存のリソース／サービスのアップグレード、プロビジョニングされたリソース／サービスの除去、性能を改良した新しいが互換性のあるリソース／サービスの追加等によって引き起こされてよい。そのような変更が環境内で検出されると、対応するサービスモジュールが、適切な信号を生成して、その信号をメッセージの形でメッセージングブローカ２．１に送信してよく、メッセージングブローカ２．１は、これらのメッセージを関連するサービスモジュールに導いて、関連するサービスモジュールが、変更によって起こり得る任意の潜在的な問題及び／またはリソース／サービスの相違点に対処する予防的なステップを取ることを可能にする。一実施形態においては、メッセージは、適切なリソース／サービスによってメッセージングブローカからフェッチ／引き出される。他の実施形態においては、メッセージングブローカは、メッセージの受信に登録されている適切なリソース／サービスにメッセージを配信する。引き出された／配信されたメッセージは、ＥＣＯシステムの様々なコンポーネントによって提供されたデータを含み、プロビジョニングされるサービス／リソースに関連する情報を含む。

監視サービスコンポーネント及びワークフローサービスコンポーネントによって提供されるオートスケールまたはオートヒーリング機能は、一実施形態においては、ルールセットを用いて、サービスまたはリソースをプロビジョニングしてよい。ルールは、記述子レコードを介してユーザによって管理されてよい。ルールは、メッセージングブローカからのメッセージに基づいて（時には繰り返して）オートヒーリングまたはオートスケール機能に従って評価されてよい。評価中、ルールが適切な基準に一致すると、選択されたワークフローを実行してよい。

ルールセットは、ユーザがアプリケーションを実行したい環境にビジネスロジックを直接組み込む能力をユーザに提供する。ルールエンジンは、特に、コンポーネントを修正／交換する必要がある時を検出し、アクションを取るワークフロー動作とは別のサービスで信号を送る能力を提供する。いくつかの実施形態においては、メッセージングブローカ２．１は、修正／交換する必要があるコンポーネントに関連するメッセージを監視サービスロジック２．２０に送信してよい。監視サービスロジック２．２０は、ＥＣＯシステムのメッセージングブローカからメッセージングイベントを受信するいくつかの方法を含み、取る必要のある適切なアクションを論理的に決定し、これらのアクションを実施するワークフローサービスモジュール２．１４に適切なメッセージを送る。取られるアクションは、プロセスアクションタイプ及びステータスアクションタイプを含む、異なるタイプであってよい。例示のいくつかのプロセスアクションタイプには、作成、読み取り、更新、削除（ＣＲＵＤ）等のアクションが含まれる。本明細書に列挙したアクションタイプは、例示的であり、包括的であると考えるべきではない。他のアクションタイプもルールに従って考えられてよい。取られたアクションに関する応答／ステータスは、分析されて、ＥＣＯシステム内の異なるコンポーネントに向けられるメッセージに解釈されてよい。メッセージングブローカは、これらのメッセージをワークフローサービス２．１４から受信して、ルールエンジンに指定されたルールに従って、さらなる処理のために、どこに、いつ、どのようにメッセージを送信するかを決定する。

監視サービス２．２０によって提供される標準的な監視に加えて、強化監視サービスも行ってよい。Ｓｅｎｓｕ（商標）コンポーネント２．３０と協調した監視サービスは、幾つかのオブジェクト／テスト／閾値／アラートの作成／編集／削除に向けられるメッセージを生成するように構成されてよく、アラート識別子及び閾値サービスを示す信号を受信する能力を含む。強化監視サービスは、標準監視サービス２．２０と一体化されてよく、ＥＣＯシステムが、ＥＣＯシステムの環境の監視を管理し、監視イベント（閾値等）にプログラムで応答するのを可能にする。

一実施形態においては、監視サービスは、オートスケールワークフロー及びオートヒーリングワークフローにおいて、「検出」機構として監視機構を使用する能力を提供する。別の実施形態においては、ＥＣＯシステムは、共通のアプリケーション関連監視オブジェクトをプロビジョニングするスクリプトを使用する。監視サービスは、ＥＣＯシステムから依存性を取り除いて、スクリプトに埋め込まれたロジック／ルールセットをネイティブなＥＣＯ機能で置き換えるように構成され、その結果、複数の監視サービスを用いた監視を均一に実施し得る。監視サービスは、ＥＣＯが任意の現在または今後のサービスの監視をプロビジョニング／管理する方法を標準化もして、強化監視をより予測可能で変更に適応するようにする。

オートヒーリング／オートスケール機能の提供に使用されるコンポーネントの１つは、ロードバランササービスコンポーネントである。このＥＣＯ対応ロードバランサは、プログラムで制御できる。個別のロードバランサ（ＬＢ）レコードは、アプリケーションに関連付けられた記述子レコードによって参照されてよく、ユーザは、クラウドにソフトウェアベースのロードバランサをプロビジョニング／管理するために必要なパラメータを投入するのに適切なユーザインタフェースを提供されてよい。ＬＢレコードは、ＥＣＯシステムのワークフロー及びルールエンジンによってオーケストレートされるロードバランサコンポーネント、ＡＰＩ等を含む、複数のコンポーネントを識別してよい。記述子レコードのサービスタイプとしてロードバランサを追加することによって、多くの構成点をユーザによって直接、管理することができる。ロードバランサコンポーネントのＡＰＩ制御を許可することによって、ＥＣＯシステムは、プログラムイベントに基づいて、アプリケーションスタックをスケール及びヒーリングする簡単で進歩したワークフローをインスタンス化できる。進歩した構成を容易な再使用できるように、テンプレートを使用して、ターゲットロードバランサが従う明示的なプロファイルを記述してよい。さらに、ロードバランササービスコンポーネントは、内部及び外部の監視サービスの両方にステータス信号を送るように構成される。

いくつかの実施形態においては、ワークフローサービス２．１４は、全ての既存のパブリックドメインの内部アプリケーションスタック及びＤＮＳレコードを管理することによって、ＥＣＯシステムのドメイン名システム（ＤＮＳ）リソースをサービスに管理させてよい。

いくつかの実施形態においては、オートヒーリング及びオートスケールに関連するモジュールは、ワークフローサービス２．１４に、特定のジオロケーション及び／または異なる時間に亘るアプリケーション実行中のリソース／サービスの使用量パターンを追跡させ、使用量パターンから集められた情報を使用して、そのジオロケーションの、または、特定の時間のアプリケーションの需要をインテリジェントに予測させてよい。予測に基づいて、オートヒーリング／オートスケール関連のモジュールは、プロビジョニングサービス２．９に、適切なリソース／サービスを仲介させてコスト及び／または性能効果を高くし、且つ、適切なリソース／サービスを、環境でアプリケーションを実行する後続の要求（複数可）に供するのに間に合うようにプロビジョニングさせてよい。いくつかの実施形態においては、オートヒーリング／オートスケール関連モジュールは、既存の環境とは異なる環境から適切なリソース／サービスを仲介して、アプリケーションが実行に成功できるように必要なサービス／リソースを要求してよい。いくつかの実施形態においては、必要なリソース及び／またはサービスが識別されると、オートヒーリング／オートスケール関連のモジュールは、プロビジョニングサービス２．９及びワークフローサービス２．１４と共に、アプリケーションの実行に成功するために必要な異なるリソース及び／またはサービスに関連して存在し得る相互依存性を決定してよく、必要なリソース／サービスをプロビジョニングするシーケンスを規定してよい。メッセージングブローカ２．１は、異なるリソース／サービス要求及びニーズを満たすために、且つ、要求を満たす所望のワークフローシーケンスを開始するために、ＥＣＯシステム内の異なるサービスモジュールへのメッセージ、または、当該モジュールからのメッセージを制御するＥＣＯ環境の集中ハブにおけるトラフィックコントローラのように働く。ＥＣＯシステムのメッセージングブローカ２．１を通して様々なコンポーネント／サービス間で交換されるメッセージはステータス、フラグ（成功フラグ及び失敗フラグを含む）、コメント、エラー、要求、及び、アプリケーションの実行に成功するためにサービス／リソースをプロビジョニングするために必要な他の関連情報に関するデータを含んでよいことに注意されたい。

コマンドラインインタフェース（ＣＬＩ）２．３及びグラフィカルユーザインタフェース（ＧＵＩ）２．４は、代替のフロントエンドユーザインタフェースをＥＣＯ ＡＰＩ２．５に提供してエンドユーザ相互作用を可能にする。ＥＣＯ ＡＰＩ２．５は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を、サービス動作要求を行うのに適切なメッセージに翻訳するサービスで、そのようなメッセージは、フォーマットと送信に関して特定のプロトコルに従ってよい。ＣＬＩ２．３は、ＥＣＯ ＡＰＩ２．５、メッセージングブローカ２．１を介して、サービスディレクトリサービス２．１１に動的にクエリを行い、どのサービス動作が利用可能かに基づいて、ＣＬＩ２．３のコマンドを構築する。ＧＵＩ２．４は、基本的に、グラフィカルエディタであり、ＥＣＯ ＡＰＩ２．５と対話し、異なる環境記述子フィールドを表示する、また、エンドユーザが各既存の環境記述子フィールドのメタデータ値を規定でき、新しいフィールドを追加でき、ワークフローサービススクリプトを支援できるようにして、エンドユーザによる環境記述子の管理を可能にする。

データディレクトリサービス２．６は、環境記述子内で用いられる様々なフィールドを記述するメタデータを管理する。データディレクトリサービス２．６の目的の１つは、グラフィカルユーザインタフェース２．４の環境記述子フィールドの動的表示を支援し、エンドユーザが各フィールドのメタデータを規定し、新しいフィールドを追加するのを可能にすることである。メタデータは、ＧＵＩでフィールドをどのように表示し、有効にし、変更するか、及び、最初のデフォルトデータのソース、翻訳のためのフィールドラベルを規定する。

ＥＣＯ ＡＰＩ２．５は、ＨＴＴＰ（専用及び非専用プロトコルを含むハイパーテキスト転送プロトコル）要求をＥＣＯ機構が支援するサービス（すなわち、ＥＣＯサービス）に仲介するためのインタフェースを提供する。その基本目的は、要求ＵＲＬを受け取り、各要求を特定のサービス動作を求める適切なメッセージング要求に翻訳することである。各要求の翻訳は、一定のビジネスロジックを適用し、メッセージ応答の形でＨＴＴＰ応答を返すことによって、行われる。エンドユーザは、どのサービスが利用可能で、どの動作が支援され、どのパラメータを使用でき、及び、どの情報の返信を期待し得るかを知るために、ＣＬＩ２．３またはＧＵＩ２．４を介してＥＣＯ ＡＰＩ２．５を用いて、サービスディレクトリ２．１１にクエリを行うことができる。

エンドユーザは、ＧＵＩまたはＣＬＩとやりとりして、ＥＣＯ ＡＰＩ２．５に要求を提出する。ＥＣＯ ＡＰＩ２．５は、これらの要求を翻訳して、ＥＣＯメッセージングブローカ２．１に各ＥＣＯサービス／リソースに要求を転送させる。一実施形態においては、サービスは、クラウドサービスまたはクラウドサービス内で提供される任意の他のサービスを含んでよい。一実施形態においては、ＥＣＯ ＡＰＩのメッセージングブローカ２．１は、異なるクラウドサービスによって用いられる複数の異なる「言語」（ＡＰＩ）を理解できる組み込みロジックを有し、特定のターゲットクラウドサービスに向けられた要求を適切に翻訳する。ＥＣＯ ＡＰＩは、従って、複数のサービスとの相互作用を可能にするトランスレータ及び管理者として働くメッセージングブローカ２．１を使用することによって、単一のＡＰＩを用いて異なるサービスをエンドユーザが管理できるようにする。例えば、単一のクラウドサービスに関わる要求がＥＣＯ ＡＰＩで受信される場合、ＥＣＯ内のプロビジョニングサービス２．９は、その要求をターゲットクラウドサービスが解釈できるＡＰＩ要求に単に翻訳する。プロビジョニングサービス２．９は、次に、翻訳されたＡＰＩ要求を処理のために適切なターゲットクラウドサービスに送信する。要求がより複雑で、複数のクラウドサービス間での調整が必要な場合、ワークフローサービス２．１４は、ビジネスロジックを適用して、どのステップをどの順序で取る必要があるかを正確に決定し、適用されたビジネスロジックで規定された順序に従ったステップを異なるサービス／リソースに実施させる。

ワークフローサービス２．１４は、所定のルールセットとワークフロー情報とを記憶し、特定の順序で行うべき細かいステップに複雑な要求を分割することができる。例えば、要求は、「第２の制作環境をスピンアップする」簡単な要求であってよい。要求は、簡単な要求に見えるかもしれないが、この要求を行うために複数の小さいステップが必要となり得る。例えば、所与の制作環境が、（仮想マシンを含む）複数のマシンからなる場合がある。簡単な例として、制作環境は、１０の仮想マシンを有してよい。ワークフローサービス２．１４内のビジネスロジックは、要求をより小さい要求に分解して、要求を行うために従うべきシーケンスを構築してよい。この例においては、要求は、１０の別々の要求に分解され、各要求は、制作環境内に個別の仮想マシンをプロビジョニングし、正確なソフトウェアを各仮想マシンにデプロイする１０の別々の追加の要求が続く。

環境サービス２．７を用いて、環境の規定（「環境記述子」としても知られる）を作成、更新し、環境データを管理する際、ビジネスルールを実施して、一貫性とバージョニングを維持する。バージョニングは、データ（環境及び他のデータ）の保持、回復中、特に役に立つ。環境記述子データは、どのクラウドテナント（複数可）で環境が実行しているか、従事しているマシン及びサービスの数、従事している各マシンの設定データ等、環境の識別に必要な情報を含む。環境データ情報は、記憶、及び／または、データベースにバックアップされる。

アイデンティティ管理サービス２．８は、各サービスのユーザ、役割、及び、組織関連の情報をデプロイメント機構内から管理する。これは、正式な許可及びアクセスレベルを有する適切なユーザに、サービス動作、アプリケーション、その環境へのアクセスを保護するシステム内のガバナンスの基礎である。

プロビジョニングサービス２．９は、異なるクラウドサービスプロバイダ、及び、異なるバックエンドインフラストラクチャサービスにフロントエンドサービス層を提供する。プロビジョニングサービス２．９は、複数のクラウドから仮想マシンを作成するための統一インタフェースを提供する。一実施形態においては、ＤＮＳサービス２．１０ａとオープンスタックＡＰＩ２．１０ｂは、プロビジョニングサービス２．９の一部である。この実施形態においては、プロビジョニングサービス２．９を用いて、１つまたは複数のクラウドサービスプロバイダにフロントエンドサービス層を提供し、ＤＮＳサービスＡＰＩ２．１０ａ及びオープンスタックＡＰＩ２．１０ｂは、バックエンドインフラストラクチャサービスをリダイレクトするインタフェースを提供する。ＤＮＳサービス２．１０ａを用いて、ＥＣＯシステムでホストされた環境にＤＮＳホスト名を割り当て、複数のシステム内の全てのＤＮＳ修正ニーズを管理する。

サービスディレクトリ２．１１は、要求に応じて、利用可能なＥＣＯサービスの動的インデックスを提供する。サービスディレクトリ２．１１の目的は、サービスレジストリを有効に提供することであり、ＥＣＯサービス指向アーキテクチャ（ＳＯＡ）内の他のサービスの呼び出しのために利用可能なサービス、及び、それらの使用方法をプログラムで明らかにすることができる。ＣＬＩ２．３は、サービスディレクトリ２．１１にクエリを行って、どのサービス及び動作がユーザに利用可能かを決定し、サービスディレクトリは、クエリに応答して、サービス動作、オプション、及び、他の詳細と共に、サービスを返信する。サービスがＥＣＯアーキテクチャ内で実施されるので、また、実施される時、各サービスは、ＣＬＩ２．３からの任意の要求に応答して、発見、返信できるように、サービスディレクトリ２．１１に登録される。

テナントメッセージングサービス２．１２は、ＥＣＯによって管理されているホストマシンにクエリ、通信し、ホストマシンを用いて実行する機能を提供する。ホストマシンは、ＥＣＯシステムによってクラウドに最初にプロビジョニングされたマシンであってもよく、または、ＥＣＯシステムにインポートされた既存のクラウドベース若しくは物理的マシンであってもよい。

トランザクションロギングサービス２．１３を使用して、典型的には、非同期ワークフローを実行する結果として、ＥＣＯとＥＣＯが管理するホストの間のＥＣＯシステム内で生じる全てのトランザクションをログする。

ワークフローサービス２．１４は、ＣＬＩ／ＧＵＩから受信した要求によって規定された具体的なアクションのための、ソフトウェアのダウンロード、ソフトウェアの設定、ソフトウェアの起動、サービスのデプロイ等、タスクセットをオーケストレートする機能を提供する。ワークフローサービス２．１４は、複数のワーカーキューを含み、そこからジョブの同時管理のためにジョブワーカーをスポーンできる。ワークフローサービス２．１４は、ＥＣＯ ＡＰＩ２．５を介して開始されると、環境サービス２．７から環境データを読み出すことができ、且つ、ＥＣＯが管理しているホストマシンで必要なアクション（例えば、環境の複製、サーバのプロビジョニング、サービスの開始／停止、サービスのデプロイ等）を行うコマンド／アクションを、テナントメッセージングサービス２．１２を介して発することができる。当然、コマンド／アクションは、ワークフローサービス２．１４からテナントメッセージングサービス２．１２にメッセージングブローカ２．１を介して送信してよい。ステータス、ソフトウェア及びバージョン、ＩＰアドレス等、結果としての情報は、環境設定データを正確な値（もしあれば）で更新するために、環境サービス２．７に通信して戻される。ワークフロー実行の一部として、ワークフローサービス２．１４が行う最後のステップは、公開されたバージョンはプロビジョニング及びサービス起動によって変更されるようになるので、現在公開されているバージョンに一致するように環境設定データを更新することである。

ワークフローサービス２．１４は、一実施形態においては、ＥＣＯ機構の外部で、内部のＥＣＯサービスファサードを介してクラウドサービス等のサービスと接触、通信して、必要に応じてそれらのサービスからリソースを使用してよい。例えば、この機能によって、ＥＣＯ機構内から制御可能なハイブリッドホスティングソリューションの作成を可能にする。コンピューティングリソースは、この例においては、第１のクラウドサービスから利用されてよく、ストレージは、第２のクラウドサービスから利用されてよい等。別の例においては、この機能は、バーストアウト使用時の支援を助ける。バーストアウト時は、重負荷の下で、１つのクラウドプロバイダ（または、クラウドサービス）にＥＣＯによってプロビジョニングされた環境は、より重い負荷の処理が必要な一時的な時間、追加のリソースを求めて別のクラウドプロバイダにバーストアウトし、その後、負荷が通常のレベルに戻ると、そのリソースを放出する。

ワークフローサービス２．１４は、ワークフロー構文を提供して、アクションを開始するコマンドを実行する。アプリケーション設定スクリプトは、このようなコマンドの実行に必要なプログラミングのほとんどを有しているので、ワークフローサービス２．１４は、アプリケーションが、必要に応じて、アプリケーション自身の設定を制御し、カスタムワークフローを規定するのを可能にするという究極のゴールを提供する。

分散リビジョン制御とソースコードリポジトリ２．１６は、サービスのコアセットと、スクリプト実行に使用されるフレームワークと共に、エンドユーザのアプリケーション設定管理（ＡＣＭ）スクリプトのソースコード管理システムとして使用される。

テナントメッセージングサービス２．１２は、管理されたホストサーバ上で並行ジョブ実行システムを実行するためのフレームワークを提供する。フレームワークは、サーバのクラスタ上でアクションを実行するための、分散した、エージェントベースのアーキテクチャを使用する。一実施形態においては、クライアント内のコマンド構造は、下にあるトランスポート機構とは別個である。クライアントが使用するメッセージングプロトコルは、トランスポート機構によって利用できる。

クライアント２．１５は、テナントメッセージングサービス２．１２から（メッセージングブローカ２．１を通して）コマンドセットを受信して、１つまたは複数のコマンドを行い、応答して、リモートホストサーバにメッセージを送る。各リモートホストサーバは、ＥＣＯエージェント２．１５ａを含む。コマンドは、環境の複製、サービスの開始／停止、サービスのデプロイ等に関連付けられてよい。単一の参照番号２．１５を、異なるホストサーバ（ゲームサービスサーバ、ウェブサービスＶＭサーバ、「Ｎｉｃｅ Ｊｏｂ」ＶＭサーバ等）のＥＣＯエージェントの識別に用いているが、異なるサーバにデプロイされたクライアントエージェント２．１５ａは、各サーバに固有であってよいことは理解されたい。ＥＣＯエージェントは、各サーバ内で全てのローカルワークを行い、ワークフローサービスは、全てのサーバ／クライアントサービスに亘るタスクのオーケストレーションと、ローカルホストに亘るアクションの調整とに使用される。クライアントエージェント２．１５ａは、テナントメッセージングサービス２．１２からコマンドを聴き、１つまたは複数のアクションを行い、次に、タスク／アクションが完了する時を折り返し報告する。

メッセージングブローカ２．１は、バイナリメッセージとしてのデータの送受信を通して様々なＥＣＯサービス間の通信を可能にするメッセージングプロトコルの実現形態である。メッセージは、１対１または１対多数であってよく、システムコンポーネント間で通信するためのメッセージペイロード内の異なるプロトコルの使用を支援する。サービス指向アーキテクチャ（ＳＯＡ）のコアでメッセージングを使用することによって、システムの疎結合が可能になり、且つ、システムの残りの部分の変更を最小限にして経時的にシステムを拡張することができる。

メッセージングプロトコルによって、クライアントアプリケーションは、メッセージングミドルウェアブローカと通信して、サービスプロバイダアプリケーションからのサービスを要求することができる。メッセージングプロトコルは、また、サービスツーサービス通信を可能にし、非同期処理のためにイベントメッセージの公開を可能にする。メッセージングブローカ２．１は、（例えば、制作者アプリケーションに関する）サービスを要求するメッセージを公開するアプリケーションからのメッセージを受信し、サービスアプリケーションにメッセージをルーティングする。サービスアプリケーションは、これらのメッセージを消費し、（例えば、コンシューマアプリケーションに）そのサービスを提供する。一実施形態においては、メッセージングブローカ２．１は、キューに加入している消費者にメッセージを届ける。代替実施形態においては、メッセージングブローカ２．１によって、消費者は、キューからオンデマンドでメッセージをフェッチ／引き出すことが可能になる。

メッセージングプロトコルは、メッセージが別々にルーティングできるように、エクスチェンジを有して構成された抽象化層を提供する。メッセージは、エクスチェンジに公開される。エクスチェンジから、メッセージは、メッセージヘッダに含まれるルーティングパターンに基づいて様々なキューにルーティングされる。キューは、アプリケーションが消費するメッセージを記憶する。このように、エクスチェンジは、郵便局として働き、キューは郵便受けとして働く。サービスワーカーは、キューに分散されて、メッセージを受信し、オンデマンドで、スケールアップまたはスケールダウンすることができる。キューは、ディスクにバックアップされて、障害回復に使用される。例えば、障害のシナリオでは、ユーザは、システムが回復された時、ユーザがやめた場所から始めることができる。メッセージ配信確認も、メッセージ障害の防止を助ける。

個別のサービスエクスチェンジ（図示せず）及びイベントエクスチェンジ（図示せず）は、セキュリティとトラフィックシェーピングを考慮して、メッセージングを分離するために使用される。異なるエクスチェンジを容易に管理して、負荷バランシングを処理し、性能を最適化し、待ち時間を改善し、且つ、使用可能な帯域幅を拡大することができる。サービスエクスチェンジは、クライアントがＥＣＯサービスを対象としたサービス要求メッセージを送る場所である。一実施形態においては、エクスチェンジは、ブローカによって維持、管理されるキューの論理的なグループと規定される。サービスエクスチェンジは、サービス動作要求メッセージのグループであり、イベントエクスチェンジは、システム内の様々なコンポーネントに送られる対象の非同期信号のグループである。

環境固有のエクスチェンジは、セキュリティとアプリケーション環境の分離を提供する。これによって、正しいメッセージが環境を構成する正確なホストマシンセットにルーティングされることを確実にする。ユーザは、同様に、機密な環境データを含み得るユーザのメッセージの宛先を分離することができ、他の環境がこれらのメッセージを聴くのを防ぐことができる。

データベース２．２５は、非ＳＱＬソリューションをデータストレージに提供し、データストレージにおいて、環境データは、本質的に、キーと値のペアの集まりであるドキュメントオブジェクト（ＪＳＯＮのようなブロック）の形態で管理される。一実施形態においては、データベース２．２５は、アプリケーションを実行するように設計された異なる環境に関連するデータを記憶するように構成される。データベースの目的は、一実施形態においては、トランザクションロギングサービス２．１３、ワークフローサービス２．１４、及び、環境サービス２．７からデータを収集、記憶することである。環境及びアプリケーションに関連する他の情報も、データベース２．２５に記憶されてよい。

外部データサービス２．２６は、サービスコンポーネントであり、他のシステムと通信して、マスタープロダクト管理システム（図示せず）からのタイトル情報等のデータを交換する。外部データサービス２．２６は、一実施形態においては、データが必要に応じて他のシステムと交換されて、データは、経時的に増える。

データベースサービス２．２７は、サービス機能としてデータベースを提供して、アプリケーションが自身のデータベースを管理するのを可能にする。同様に、監視サービス２．２０は、ＥＣＯによって管理されるホストシステムの監視を行うＴｒａｖｅｒｓｅ（商標）２．２９及びＳｅｎｓｕ（商標）２．３０のような外部サービスと一体化されることによって、サービス機能として監視を行う。Ｓｅｎｓｕ（商標）２．３０は、監視サービス２．２０の一部であり、ルーティングエージェントを備える。ルーティングエージェントは、「チェック」スクリプトを用いてアプリケーション実行とシステムサービスを監視し、異なるフォーマットでメトリックを収集し、異なるフォーマット及び媒体で（サービス障害を含む）異なるイベントの通知を送信するように構成される。監視ルーティングエージェント内のＡＰＩは、実行をチェックするように、また、様々なシステムサービスに亘るイベントを解決するために、様々なイベント及びエージェントに関連するデータにアクセスを提供する。追加のロジック及びビジネスルールは、オートヒーリング及びオートスケール機能を提供、管理するために、ＥＣＯシステム内でＳｅｎｓｕ（商標）によって提供される関数ロジックでラップされる。

デプロイメント機構のコアサービスコンポーネントは、ＥＣＯファサードサービス層を介してバックエンドサービスと通信する。ファサードサービスは、コアサービスとバックエンドサービスの間の連携として働き、バックエンドサービスを相互運用可能で交換可能にする抽象化層を提供し、且つ、必要に応じて、ＥＣＯシステムにＥＣＯ固有のビジネスロジックを提供する。ファサードサービスは、デプロイメント機構（「ＥＣＯコア」とも称される）内に一体化され、他のＥＣＯコアサービスと同じ種類のメッセージベースのサービス要求に応答する。前述のように、スケーラブルなフレームワークによって、ＥＣＯサービスのコアのセットに影響を与えることなく、ファサードサービスによって新しい技術を抽象化して、クラウドＥＣＯシステム内に統合することが可能になる。デプロイメント機構で提供されるサービスには、Ｅメールサービス２．１８、課金サービス２．１９、監視サービス２．２０、ストレージサービス２．２１、設定管理サービス２．１７等が含まれる。

Ｅメールサービス２．１８を使用して、メッセージング目的で、既存のＥメールインフラストラクチャにプラグインする。

課金サービス２．１９は、インスタンスアップタイム、プロセッサ使用量、メモリ使用量等を含む、既存の課金システム２．２４のための環境リソース使用量を捕捉するのに使用されるライブ課金フィードを実行する。課金サービス２．１９は、使用量データを読み出す収集エージェントと、使用量データを既存の課金システムに送信する課金ＡＰＩとを含む。

規則的にスケジュールされた間隔で、課金サービスエージェントは、使用量データを求めるクエリを行うメッセージを送る。使用量データは、受信されると、専用データベース（図示せず）に送られる。使用量データは、次に、専用データベースから動作データストア（図示せず）に引き出される。ここから、ＥＴＬ（抽出、加工、及び、書き込み）プロセスによって、課金及び報告のためにデータウェアハウスにデータを入れる。

一実施形態においては、課金サービス２．１９は、ＥＣＯ機構によって使用されて、サービスのコストを比較し、性能メトリック及びコストメトリックを生成し、各リソースのコストを追跡し、コスト最適化のために様々なサービスのギアリングまたはフローティングを変更してよい。サービスのフローティングは、アプリケーションを最適に実行するために１つのサービス環境から他のサービス環境の１つまたは複数に移ることを含む。コスト追跡、コスト最適化を達成するために、ＥＣＯシステムは、様々な課金データ及び測定データを定期的に収集、分析してよく、一実施形態においては、クエリを行って、異なるクラウドサービスからフィードバックを受信して、リソースのコストを決定し、バックエンドで、アプリケーションの環境プロファイルを自動的に決定してよい。アプリケーションの環境プロファイルは、高価なプロファイル、倹約的なプロファイル、中間のプロファイル等として分類されてよい。環境プロファイルに基づいて、また、（例えば、性能、コスト、リソース、使用量等に関連付けられたルールに関する）所定のルールセットに基づいて、ＥＣＯシステムは、コストと性能を最適にするためにどのサービス（複数可）を使用すべきかを決定してよい。

監視サービス２．２０を使用して、サービススタックの監視に関連するアラート、拡大、及び、通信に関する情報を集中させる方法として、デプロイメント機構プラットフォームにホストされた環境で実行するサービスの健全性と性能を監視する。例えば、監視サービス２．２０は、サービスの健全性を監視してよく、特定のジオロケーションで、または、特定の時間（例えば、時刻、曜日等）に環境内でアプリケーションに関するトラフィックのスパイクを検出してよい。監視に基づいて、ＥＣＯシステムは、アプリケーションのインスタンス１つでは、トラフィックに対処するのに十分ではない場合があることを決定し得、アプリケーションの１つまたは複数の追加のインスタンスをインテリジェントに追加してよい。ＥＣＯシステムは、監視サービス２．２０からメッセージを受信してよく、受信したメッセージに応答して、追加のアプリケーションインスタンスをインスタンス化し、これらのアプリケーションインスタンスを記述子ファイルに追加し、且つ、必要なリソースにマッピングしてアプリケーションを最適に実行させることによって、これを行ってよい。アプリケーションの追加のインスタンスを提供することは、アプリケーションの性能を最適化する一方法である。アプリケーションの性能を最適化する他の方法は、アプリケーションが使用する環境内で、追加のリソースを提供すること、リソースをアップグレードすること、リソースを変更すること、リソースを移すこと等であってよい。一実施形態においては、監視は、組織レベルで行われる。別の実施形態においては、監視は、アプリケーションレベルで行われる。監視サービス２．２０は、監視ルール、アラート等をプロビジョニングする、または、削除するために、環境記述子に提供された情報に基づいて動的ドキュメントを構築し、その情報をリソース管理モジュールに供給する。言い換えると、監視サービス２．２０からのデータは、必要に応じて、アプリケーション／サービスのスピードアップを含む、アプリケーション／サービス全体のライフサイクルを有効に管理するためにＥＣＯシステムによって使用される。ＥＣＯシステムは、アプリケーション／サービスの継続的な監視と、アプリケーション／サービスのリソースの効率的な管理によって、これを行う。

設定管理システム（ＣＭＳ）サービス２．１７は、集中型の仕様に基づいて管理タスクと設定管理を自動化し、特に、ＥＣＯコアの対象であるホスト上のオペレーティングシステムと適用前提条件を管理するために、使用される。ＣＭＳは、情報技術や情報セキュリティスタッフ等、ユーザの一定のコアグループによって監査、利用され得るポリシーベースの設定管理を行う方法として実施される。ＣＭＳは、一実施形態においては、一連の階層マニフェストを使用して、個々のホストに命令を送る。一実施形態においては、ＣＭＳは、オープンスタックプライベートクラウド等、プライベートクラウドに組み込まれる。

ストレージサービス２．２１は、一実施形態においては、１つまたは複数のクラウドストレージサービス２．２２とローカルストレージバックエンドサービス２．２３にフロントエンドサービス層を提供する。ストレージサービス２．２１は、環境記述子から記載されたストレージニーズを解釈し、複数のストレージバックエンドに対して結果を伝達するのに使用されるポリシーエンジンとファサードサービスの組み合わせである。ストレージサービス２．２１は、ストレージをプロビジョニングする能力を提供するだけでなく、アプリケーションがデータストレージを経時的にどのように扱うかを記述するポリシー／ルールも保持する。この実施形態においては、ストレージサービス２．２１は、ＥＣＯコア内の別個のスタンドアロンサービスコンポーネントである。別の実施形態においては、ストレージサービス２．２１は、インフラストラクチャ管理サービス２．２８と一体化されている。ポリシーエンジンは、環境記述子に供給されて、ワークフロー及びストレージエンドポイントを操作し、ポリシールールに一致する変更をシステムに生じさせる。

図２を参照して記載したサービスは、例示的なものであり、制限と見なすべきではないことに注意されたい。いくつかの実施形態においては、サービス／リソースの１つまたは複数は、他のサービス／リソースと統合されて、統合サービス／リソースを規定してよい。結果として、このような統合サービス／リソースの機能または属性は組み合わされてよい。さらに、サービス／リソースのうちの全てをアプリケーションにプロビジョニングする必要はないことに注意されたい。追加の機能を追加するように１つまたは複数のサービス／リソースを調整若しくは構成してよく、または、ＥＣＯシステム内に追加の機能を提供するように追加のリソース／サービスを導入してもよい。ＥＣＯ機構はスケーラブルなフレームワークを提供するので、アプリケーションの性能やシステムのコアな機能に影響を与えることなく、そのような構成変更を容易にシームレスに行うことができる。

ＥＣＯシステム内で利用可能で、且つ、アプリケーションが必要とする様々なサービス／リソースは、ＥＣＯシステム内に保持される環境記述子ファイル内の環境記述子レコードに記述される。環境記述子ファイルは、ＥＣＯシステム内でアプリケーションソフトウェアを管理するためのインタフェースを提供するＪＳＯＮフォーマットファイルである。環境記述子ファイル内の環境記述子レコードは、テナント環境でアプリケーション実行に成功するためにリモートクラウドテナントまたは物理ホストに設定される必要のあるものを表したものである。

一実施形態においては、環境記述子レコードは、アプリケーション実行に必要なパラメータリストを含む。記述子レコードは、データベース、仮想マシン、サービスとソフトウェア、記憶場所、ＡＣＭ（アプリケーション設定管理）構成、ＣＭＳ（設定管理サービス）構成、及び、他の環境メタデータを含む、特定の環境に関するリソース／サービスの規定及び仕様を含む。

ＥＣＯ ＧＵＩ２．４は、その利用可能なメニューアクションを、環境記述子内に指定及び記憶されたアクションに基づいて、動的に設定できる。例えば、ＧＵＩで「スタート」ボタンをクリックすると、「スタート」アクションがＥＣＯ ＡＰＩコールに渡される。応答して、「スタート」を処理するように登録されたＥＣＯワークフローが実行され、そのワークフローは、最後に、１つまたは複数のホストインスタンス上のＡＣＭの「スタート」機能へのコールを含み、ホストインスタンス上で、ＡＣＭは、アクションを開始、実行する。環境記述子は、ＥＣＯシステムとＡＣＭの間のインタフェースとして働く。環境記述子で適切なＡＣＭを指定することによって、ＥＣＯシステムは、指定されたＡＣＭをどこで取得するべきか、そのＡＣＭを環境内の異なるマシン上のどこに配置するべきか、及び、どのＡＣＭコマンドが使用するために入手可能かが分かる。環境記述子に指定されたアクションは、環境内の特定のワークフローをトリガして、必要なリソース、サービス、及び／または、アプリケーションのプロビジョニングを可能にする。

一実施形態においては、ＡＣＭは、ＥＣＯシステム内の適切な環境にアプリケーションをデプロイするために使用される管理スクリプトロジックを含む。ＡＣＭスクリプトは、環境のステータスのスタート／ストップ／更新／再スタート／チェックの方法を知るためのアプリケーションに対するインタフェースである。ＥＣＯシステムは、ＥＣＯシステム内に、これらのアクションをオーケストレートするデフォルトの一般的ワークフローを提供する。開発者は、特定のアプリケーションのワークフローの詳細が何かを規定し、これは、アプリケーションのＡＣＭと環境記述子の間の調整を伴う。

ＡＣＭスクリプトは、バックエンドタスクも指定してよい。所与のＥＣＯワークフロー中に実行されるバックエンドタスクは、環境記述子に規定されるものに一部、依存する。例えば、「公開」ワークフローにおいては、ＥＣＯシステムは、環境記述子で何が変更されたかに応じて、タスクのうちの特定のタスクを実行する。新しいマシンを追加するように環境記述子が編集された場合、ＥＣＯシステムは、プロビジョニングサービス２．９を介して新しいマシンを起動するためのタスク／アクションを識別、実行する。環境記述子がＣＭＳリポジトリ情報及び／または分散リビジョン制御とソースコードリポジトリ２．１６を変更するように編集されており、マシンが既に環境で稼働している場合、ＥＣＯシステムは、プロビジョニングプロセスを開始するアクションをスキップし、環境内で影響を受けるサービス（複数可）上のソフトウェアを単に更新するアクションを識別、開始する。

ＡＣＭが、各マシンにデプロイされて、アプリケーションのインストール、設定に必要とされるステップの全てが実行される。ＥＣＯワークフローは、アプリケーションが実行する環境に適切なＡＣＭをコールし、所与のアクションを関連付ける。ＡＣＭは、環境情報を求めて環境記述子を参照し、内部で規定されるロジックに基づいて、その特定のホスト上で行う必要があることに関して決定を行う。ロジックは、どの設定ファイルを変更する必要があるか、ファイルをどのように変更するか、ホスト内でどのリソースが利用可能か、ホスト毎に幾つのサービスがあるか等を指定する。

一実施形態においては、マシンをプロビジョニングする時、ユーザは、ＧＵＩ２．４またはＣＬＩ２．３を使うことを指定してよく、マシンをプロビジョニングするクラウドサービスを識別し、環境記述子から取得したマシンに関する情報に基づいてマシンを作成するようにクラウドサービスに命令する。代替実施形態においては、マシンをプロビジョニングする時、ＥＣＯシステム内のロジックは、ユーザからの何らかのやりとりを用いて、マシンをプロビジョニングするクラウドサービスを識別してよく、適切な環境記述子レコードを識別して、環境記述子レコードからの情報に従って、マシンを作成するようにクラウドサービスに命令する。情報フィードは、クラウドサービスから起動されたマシンに翻訳される。プロビジョニングプロセスの一部として、ＡＣＭ環境記述子の仕様に基づいて、ＡＣＭが、起動されたマシンにインストールされる。次に、設定管理サービス（ＣＭＳ）２．１７が実行されて、マシンをコンテキスト化する。ＣＭＳは、システム設定管理の役割をする。詳細には、ＣＭＳは、必須のソフトウェア、設定、及び、許可の全ての準備が整っており、当該インスタンスの特定のデータセンター／場所に関連していることを保証することによって、ＥＣＯと共に使用する（クラウドの）インスタンスの準備をする。任意の利用可能な設定管理ソフトウェアが、この役割のために採用されてよい。この役割に従って、コンテキスト化は、そのマシンの役割に関連付けられたパッケージ（ソフトウェア及びその他）の全てをインストールすることを伴う。コンテキスト化を完了した後、ＡＣＭは、環境記述子を構文分析するように命令されて、コードベースを調べ、依存性を満たしていることを検証し、アプリケーションに関する詳細を全て実行する。

言い換えると、ＡＣＭは、ＥＣＯシステムが発したコマンドを内部に構築されたロジックを用いて翻訳する。コマンドがマシン上でサービスをスタートすることである場合、ＡＣＭの組み込みロジックは、どのアーギュメントがコマンド実行に必要か、サービスのアーギュメントを用いてコマンドを実行する特定の方法（各サービスは、コマンドを実行する異なる方法を有し得る）を知っており、コマンドに関連付けられた様々なタスクを実行するシーケンスを規定する。ＡＣＭは、ＡＣＭがサービスを開始している環境の種類を、その特定の環境に関する環境記述子を参照することによって識別し、設定ファイルを用いてサービスを構築する。

環境記述子ファイルは、ＥＣＯシステムにおいてアプリケーションソフトウェア管理にインタフェースを提供するＪＳＯＮフォーマットファイルである。環境記述子ファイルは、アプリケーション実行のためにリモートクラウドテナントで設定されたものを表す。

環境記述子ファイルは、アプリケーション実行に必要なパラメータリストを有する記述子レコードを含む。例えば、記述子レコードは、データベース、仮想マシン、サービスとソフトウェア、記憶場所、ＡＣＭ構成、ＣＭＳ構成、及び、他の環境メタデータを含む、特定の環境に関する規定及び仕様を含んでよい。ＡＣＭを作成可能にするには、その前に、環境記述子レコードの準備が整っており、ＡＣＭ管理スクリプトが環境記述子レコードの「ｅｃｏ」ブロックに規定されている必要がある。これによって、ＡＣＭは、環境を設定するために、環境記述子レコードで指定された設定情報を使用できる。環境記述子レコードは、従って、環境設定に必要な全てのサービスに関する情報の全てを含み、アプリケーションのＡＣＭが支援するアクションを規定する。ｅｃｏブロックは、アプリケーションのＡＣＭを取得すべき場所、ＡＣＭの実行方法、及び、ＥＣＯワークフロー中に実行すべきＡＣＭが支援するアクションに関する情報を提供する。ＥＣＯワークフローは、実行されると、ストップ／スタート／更新／チェック／等のためにＡＣＭをコール／開始する。ワークフローは、ＡＣＭを実行する必要があるマシンと連絡し、ＡＣＭ管理スクリプトを実行し、ＡＣＭを実行するために必要なアーギュメントを提供する。見本のｅｃｏブロック疑似コードを以下に示す。

クラウドサービスの環境に仮想ホストを規定する見本のｅｃｏブロック疑似コードを以下に示す。ｍａｃｈｉｎｅｓ（マシン）ブロックは、クラウドサービスプロバイダによって提供された情報、サービスからの情報、サービス毎のマシン固有のメタデータ、及び、他の設定属性を含んでよい。

アプリケーションスタック毎に、サービス及びリポジトリ情報の各種類を規定する見本のｅｃｏブロック疑似コードを以下に示す。ＡＣＭは、リポジトリ情報を使用して、最新のアプリケーションコードを取得してよい。複数のサービスが同じ名前を有する時、１つまたは複数のａｔｔｒｉｂｕｔｅｓ（属性）特徴を使用して、環境内のあるサービスを他のサービスと区別することができる。

アプリケーションのリモートストレージ情報を規定する見本のｅｃｏブロック疑似コードを以下に示す。

サービス／リソースをプロビジョニングするためのｅｃｏブロックに含まれる上記疑似コードは、例示的であり、制限と考えるべきではない。ｅｃｏブロック内にサービス／リソースをプロビジョニングする他の方法を使用してよい。アプリケーションのソフトウェアソースコードは、クラウドプロバイダテナントのウェブサーバ上、ソースコードリポジトリ、または、コードをダウンロードすべきマシンにアクセス可能な任意の場所に記憶されてよい。ＡＣＭは、場所を識別するように更新される。

環境記述子内の任意のフィールドが、変更される時、一実施形態においては、変更は、「環境公開」オプションを用いて公開できる。あるいは、更新は、環境において、異なるサービスに変更をデプロイするように実行されてよい。更新オプションを選択する時、更新ソフトウェアは、最新のリビジョンでアプリケーションソフトウェアを更新し、環境記述子を更新して変更を反映し、全てのマシン上に更新された環境記述子を押し出し、最後に、ＡＣＭを更新する。

公開オプションが選択されると、公開プレビューウィンドウ（すなわち、ＧＵＩ）は、現在の環境バージョンと更新された環境バージョンの間で変更されたものの詳細を表示する。さらに、「環境公開」ワークフローが実行される。ワークフローは、アプリケーションソフトウェアの更新を含むアクションストリングを識別、実行する。例えば、一実施形態においては、以下のアクションが、環境公開ワークフローによって実行されてよい。すなわち、１．環境ドラフトバージョンをコミット、２．現在のサービス状態及び環境にデプロイされたリビジョンをログ、３．マシンが終了したのをチェック、全てのＤＮＳレコードが有効であることをチェック、４．新しいマシンをプロビジョニングし、既存のマシンが実行していることを検証、５．マシン上の新しいＤＮＳレコードを更新、フローティングＩＰアドレスをチェック／追加、６．マシン上でＡＣＭを更新、７．アプリケーションソフトウェアを更新、８．最後に公開された環境バージョンを設定。上記アクションのリストは、例示的であり、より少ないまたは多いアクションが更新に基づいて実行されてよい。いくつかの実施形態においては、識別されたアクションを完了するために、複数のワークフローを並行してデプロイしてよい。

図３は、一実施形態における、公開環境の例示のスクリーンショットを示す。公開環境ワークフローが提供する選択オプションは少ない。例えば、丸１によって示される「強制公開」オプションをオンにすると、環境全体が再スタート／更新される。「強制公開」をオフにすると、変更されたサービスのみが再スタート／更新される。図３Ａは、フィールド上にカーソルを合わせる等、強制公開オプションで入力アクションが検出される時、強制公開のオフとオンのオプションの間の相違を示す。ＥＣＯ機構は、変更された環境サービスを識別し、且つ、そのサービスを有するまたは使用するマシンを更新する組み込み知能を有する。

引き続き、図３を参照する。丸２によって示される「ソフトウェア更新をスキップ」オプションは、オンまたはオフされて、アプリケーションソフトウェア全体の更新を実行するか否かを制御してよい。「レビューを変更」オプションを使用して、ワークフローがトリガされると実行される別々のアクティビティを見てよい。アクティビティは、ワークフロープロセッサを介してＥＣＯワークフローサービスに送られて、丸３で示されるように、折り畳み可能なセクションに表示される。プリプロセッサは、環境記述子で指定されたロジックを使用して、環境記述子によって規定された順で、様々なアクティビティを行う。

図４は、発明の一実施形態において、行われた様々なアクティビティをユーザに知らせるために使用される環境履歴ウィンドウのスクリーンキャプチャの見本を示す。環境履歴で「実行履歴」セクションの下に列挙されたアクティビティは、図４に示すプレビューウィンドウの折り畳み可能なセクションに列挙されたのと同じアクティビティセットである。

図５は、一実施形態において、実施するようにスケジュールされたＥＣＯ「ワークフロー」アクションの例示的なスクリーンキャプチャを示す。一実施形態においては、ＥＣＯワークフローアクションは全て、プレビューウィンドウで折り畳み可能なオプションとしてレンダリングされる。一実施形態においては、プレビューウィンドウは、プログレスバーをレンダリング、または、任意の他のステータスインジケータ機構を使用して、現在取られているアクション、または、既に取られたアクションのステータスを識別してよい。図３を参照して示すように、折り畳み可能なセクションは、ワークフロー実行中に実行されるアクティビティと、アクティビティの順序をウィンドウに表し、一実施形態においては、アクティビティを実行する順序を表してよい。列挙されるアクティビティは、図３の「環境履歴」ウィンドウと図４の「実行履歴」セクションに示されるアクティビティと同様である。

図６は、一実施形態における、ワークフローによって開始されたアクションに関する「現在のアクションステータス」ウィンドウの例示的なスクリーンキャプチャを示す。現在のアクションステータスウィンドウは、ワークフローアクションを開始すると、開かれる。ワークフローアクション完了後、メッセージまたはインジケータが、ウィンドウにレンダリングされたページの最上部または最下部に表示されてよい。現在のアクションステータスウィンドウは、丸１によって示されるプログレスインジケータを備えて、ワークフローアクションの現在のステータスを提供する。ワークフローの詳細は、丸２によって表されるセクションに提供され、ここに、ワークフローアクション識別子、ワークフローアクションの状態、ログされた最後のトランザクションメッセージのタイムスタンプ、及び、実行履歴の詳細が提供される。ワークフローアクションのログをリフレッシュするオプションが、丸３で示されるように、提供されている。リフレッシュオプションを選択すると、ワークフローアクションを詳述するログが、丸４に示すサブウィンドウに提示される。ワークフローアクションは、丸５で示されるように、「ワークフローをキャンセル」オプションを用いていつでもキャンセルできる。丸６に示す「閉じる」オプションを用いて、ウィンドウを閉じてよい。一実施形態においては、閉じるオプションは、ウィンドウを閉じるだけで、ワークフロー動作をキャンセルしなくてもよい。代替実施形態においては、閉じるオプションは、ワークフロー動作をキャンセルして、ウィンドウを閉じてよい。

ＥＣＯ機構は、環境の全てのログされたトランザクションの詳細を提供する。環境履歴データベースは、環境の異なるトランザクションの履歴を記憶してよく、図７に示すような「環境履歴」ウィンドウに投入してよい。図７の環境履歴ウィンドウは図４の環境履歴ウィンドウとは異なる情報を提供する。例えば、図４の環境履歴ウィンドウは、トリガされた各ワークフローに関するワークフロー詳細セクションに実行履歴の詳細を提示する。一方、図７の環境履歴ウィンドウに提示されたログは、環境をプロビジョニングするために取られたアクション、ワークフロー、及び、イベントに関するＥＣＯサービスメッセージを表す。トランザクションリストは、トランザクションタイムスタンプ（すなわち、日付）、アクションを開始したユーザ名（要求者名）、ＥＣＯトランザクションメッセージ、アクションを実行する時に使用されたパラメータ等を含む、環境アクティビティの詳細を記録する。図７の矢印で示すように、１つまたは複数のリンクが、各アクティビティログで提示されて、そのアクティビティのインライントランザクションの詳細を見ることを可能にしてよい。リンクが選択されると、図４に示されたのと同様のインライントランザクションの詳細が、別個のウィンドウに、または、既存のウィンドウの代わりに提示される。

エラーによって完了しなかったイベントに関しては、エラーの詳細を見るためにオプションのリンクが提供されてよい。図８は、ワークフローアクティビティの１つでエラーに遭遇した際の、環境履歴のビューをキャプチャした例示の画面を示す。オプションのリンクが、エラーの追跡ログを見るために選択されてよい。オプションで、リンクは、要求を開始するユーザに遭遇したエラーを通知するために選択されてよい。一実施形態においては、ユーザは、ｅメールを通してエラーを通知されてよく、ｅメールは、エラーログを含んでよい。代替実施形態においては、ユーザが望むフォーマット及びメッセージツールで、情報メッセージが生成されて、ユーザに提示されてよい。

一実施形態においては、エラーログは、エラーログで提供される詳細にアクセスするために必要なリンクと共にウィンドウでユーザに提示されてよい。図９は、エラーログにアクセスするオプションをユーザに提供する例示のウィンドウを示す。この実施形態においては、エラーログは、ｅメール内のリンクでユーザに提供される。一実施形態においては、リンクにアクセスすると、エラーログは、ワークフローアクティビティ実行中に遭遇した様々なエラーを詳述する複数のエントリを識別し、エラーの重大性に基づいて、エントリを編成してよい。代替実施形態においては、エントリは、時間順で配置されてよい。リンクは、ユーザのさらなる詳細と、遭遇したエラーをユーザに知らせるために使用するモードとを提供する。

特定の環境が、１つまたは複数の属性に基づいて、検索、識別されてよい。検索オプションは、ユーザが属性の値を入力できるように提供されてよく、検索ツールは、属性とその値を用いて、環境記述子ファイルを検索して、一致する環境の詳細を識別して返信してよい。

一実施形態においては、エンティティは、各環境で割り当てられた役割に基づいて、一人または複数のユーザに管理されてよく、クラウドエンティティは割り当てられてよい。エンティティの管理は、ＥＣＯシステムのリソースへのアクセスを制御するユーザの役割を追加することと、アプリケーション及び環境が組織内に作成できるように組織を追加することと、テナントを組織に関連付けることができるようにテナントを追加することと、クラウドプロバイダを組織内のテナントに関連付けることができるようにクラウドプロバイダを追加することと、セキュリティキーを組織内のテナントに関連付けることができるようにセキュリティキーを追加することと、を含み得る。ユーザが追加されると、そのユーザは、組織内のリソースにアクセスを有するように組織に割り当てられる。役割は、ユーザがＥＣＯシステムのリソースに制御されたアクセスを有し、規定された役割と適切な許可を有するように、ユーザに割り当てられる。アプリケーションへのアクセスは、ユーザが、その組織内のアプリケーションにアクセスできるように、ユーザの割り当てられた役割に基づいてユーザに割り当てられる。この実施形態においては、クラウドプロバイダ（または、任意のリソース／サービスプロバイダ）は、コンピューティングサービス、ストレージサービス、データベースサービス等のサービスを提供するシステムプロバイダとして構成されてよい。これらのサービスは、次に、サービスのシステムカタログに「登録」され、場所によって整理される。サービスのシステムカタログは、集中クラウドデータセンターと、複数のジオロケーションを含み得る異なるジオロケーションまたはジオリージョンのクラウドデータセンターとに保持されてよい。組織は、各システムプロバイダに維持された組織のアカウントとの関連付けを通して、特定のシステムプロバイダに関連付けられる。組織内のアプリケーションの環境は、所望のジオロケーションのシステムプロバイダによって提供されたサービス／リソースにアクセスを有する。従って、リソース（ストレージ、データベーススキーマ、固定のＩＰ等）は、他の環境によって使用される環境に規定された仕様または条件に従って、環境によって消費される。

図１０は、ユーザのプロファイルを表す例示の画面を示す。ユーザプロファイルは、ユーザの名前、ログイン識別子等、（丸１によって示される）ユーザの個人情報、ユーザが割り当てられた組織等、（丸２によって示される）組織情報、ユーザの割り当てられた役割、アクセスレベル、許可リスト等、（丸３によって示される）ユーザの役割及び許可情報、（丸３によって示される）ユーザのタイムゾーンプリファレンスを含んでよい。アイデンティティ管理サービス（図２の２．８）を用いて、ユーザプロファイルを規定してよく、ユーザプロファイル情報は、データベースに保存されて、環境及び／またはアプリケーションが必要とするので、及び、必要とする時、アイデンティティ管理サービスによって参照されてよい。

図１１は、一実施形態における、ＥＣＯシステムへのアクセスを要求する個人のための一般的ワークフローを示す。個人が、ＥＣＯ ＧＵＩの使用を開始したい時、外部で管理されたライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）を用いて、ＥＣＯシステムへのログインを最初に要求される。認証情報によって、要求者の名前はＥＣＯシステムに登録できる。動作１１．１に示すように、ホスト管理サービス（ＨＭＳ）に要求を送信するようにという命令を有する「無許可の」メッセージが要求者に送られる。要求者が属する組織とアクセス要求を指定する要求者からＨＭＳへの要求は、ｅメールの形で、動作１１．２で示されるように、ＨＭＳで受信される。ＨＭＳのアドミニストレータ（「アドミンユーザ」とも称される）は、次に、要求者（すなわち、新しいユーザ）をユーザの役割に割り当てる。割り当てるために、アドミニストレータは、最初に、デシジョンボックス１１．３に示すように、ユーザの役割が存在するか否かを知るためにチェックを行う。デシジョンボックス１１．３の「Ｎｏ」ブランチで示すように、役割が存在しない場合、アドミニストレータは、動作１１．４で示すように、ＥＣＯシステムでユーザの役割を作成する。通常、デフォルトのユーザの役割セットが、必要な許可と共に既に規定されており、ＥＣＯシステムで利用できる。ユーザの役割を作成すると、または、適切なユーザの役割を既存のデフォルトのユーザの役割から識別すると、アドミンユーザは、動作１１．５で示すように、新しく作成または識別したユーザの役割に要求者を割り当てる。

アドミンユーザは、次に、要求者を組織に割り当てる。アドミンユーザは、デシジョンボックス１１．６に示すように、最初に、組織が存在するか否かを決定する。ＥＣＯシステムに組織が存在しない場合、アドミンユーザは、動作１１．７に示すように、ＥＣＯシステムに組織を追加する。既存の組織に関しては、１つまたは複数の関連するジオロケーションが既に存在し、その各ジオロケーションは、既に、関連するクラウドと、クラウドに関連付けられたセキュリティキーを有するはずである。アドミンユーザは、デシジョンボックス１１．８に示すように、組織に対して特定のジオロケーションが存在するか否かを知るために検証を行い、存在しない場合、アドミンユーザは、動作１１．９に示すようにジオロケーションを作成し、動作１１．１０に示すようにジオロケーションに組織を割り当てる。

テナントが作成されると、アドミンユーザは、デシジョンボックス１１．１１に示すように、ジオロケーションに対してクラウドが存在するか否かを決定する。デシジョンボックス１１．１１の「Ｎｏ」ブランチによって示されるように、クラウドが存在しない場合、アドミンは、動作１１．１２に示すように、クラウドを作成する。アドミンは、動作１１．１３に示すように、新しく作成されたジオロケーションを新しいクラウドに割り当てる。アドミンユーザは、次に、デシジョンボックス１１．１４に示すように、セキュリティキーが存在するか否かを決定する。デシジョンボックス１１．１４の「Ｎｏ」ブランチによって示されるように、セキュリティキーが存在しない場合、アドミンユーザは、動作１１．１５によって示されるように、セキュリティキーを作成し、動作１１．１６に示すように、新しく作成されたセキュリティキーをジオロケーションに割り当てる。

他方、デシジョンボックス１１．６の「Ｙｅｓ」ブランチが示すように、組織が存在する場合、アドミンユーザは、動作１１．１７に示すように、要求者を組織に割り当てる。アドミンユーザは、次に、デシジョンボックス１１．１８に示すように、要求者の役割が「開発者」または「制作者」であるか否かを決定する。デシジョンボックス１１．１８の「Ｎｏ」ブランチによって示されるように、要求者の役割が開発者でも制作者でもない場合、要求者は、動作１１．２２に示すように、ＥＣＯシステムにログインするのを許可され、認定される。要求者の役割が開発者または制作者の場合、アドミンユーザは、アプリケーションアクセスを要求者に割り当てる必要がある。一実施形態においては、組織内の全ての既存のアプリケーションが、要求者に割り当てられる。アプリケーションアクセスを割り当てるために、アドミンユーザは、デシジョンボックス１１．１９に示すように、アプリケーションが存在するか否かを決定する必要がある。デシジョンボックス１１．１９の「Ｎｏ」ブランチによって示されるように、アプリケーションが存在しない場合、アドミンユーザは、動作１１．２０によって示されるように、アプリケーションを作成する。他方、デシジョンボックス１１．１９の「Ｙｅｓ」ブランチによって示されるように、アプリケーションが存在する場合、アドミンユーザは、動作１１．２１に示すように、「制作者」及び／または「開発者」の役割を有する要求者をアプリケーション（複数可）に割り当て、動作１１．２２に示すように、要求者は、ＥＣＯシステムにログインを許可され、アプリケーションへのアクセスを認められる。一実施形態においては、アドミンユーザの役割は、手動プロセスに見えるが、自動化されてよい。この実施形態においては、役割または許可をユーザに与える前に、適切なユーザ認証が行われることを保証する十分なセキュリティ対策が自動プロセスに組み込まれてよい。

ユーザに割り当てられる役割は、サービス動作及びＧＵＩ機能へのアクセス権を決定する。役割は、どのＧＵＩ要素がユーザに利用可能で作成／読み取り／更新／削除（ＣＲＵＤ）のどの許可がユーザに利用可能かを決定する。ユーザの役割は、アクセスレベル間の階層関係を決定する。図１２は、一実施形態における、ユーザに割り当てられた役割に基づいた、アクセスレベル間の例示の階層関係を示す。例えば、スーパーアドミンユーザまたは管理者等、ＥＣＯレベルのユーザは、全てのデータ、組織、アプリケーション、及び、環境へのシステム全体に亘るアクセスを与えられる。組織管理者及び組織アドミン等、組織レベルのユーザは、当該ユーザ自身の組織、アプリケーション、及び、環境へのアクセスを与えられる。開発者及び制作者等、アプリケーションレベルのユーザは、当該ユーザ自身の組織のタイトル／アプリケーション内のアプリケーション及び環境へのアクセスを与えられる。ゲスト及びコントリビュータ等、環境レベルのユーザは、当該ユーザ自身の組織のアプリケーション内の環境へのアクセスを与えられる。

一実施形態においては、新しい環境は、図１３に示すように、環境記述子ワークフローを行うことによって作成、管理できる。環境記述子ワークフローは、環境内に必要なリソース／サービスを識別し、このようなリソース／サービスをプロビジョニングする追加のワークフローをトリガする。この実施形態においては、新しい環境を作成する時、環境は、バージョン番号を用いて指定され、この環境が変更されると、変更された環境に対して新しいバージョン番号が指定される。環境記述子ワークフローは、環境設定の複数のリリースの作成及び管理を助け、後続の各リリースは、前のリリースと同じ一般的機能を有するが、改良、アップグレード、または、カスタマイズされている。複数のバージョンによって、リリースが、間違って削除されたり、上書きされたりするのを防止し、リリースがいつでも読み出せるようにリリースのアーカイバルを可能にする。

図１３は、環境記述子ワークフローに新しい環境を作成させる実施形態を示す。新しい環境が、環境記述子ワークフローを用いて最初に作成される時、「ドラフト」環境１３．１バージョンが生成される。環境が公開されると、ドラフト環境は、「ライブ」環境１３．２に変換される。アップグレードまたはカスタマイズのために環境の変更が必要になる時、図１３に示すように、変更は、通常、「ドラフト」バージョンに行われ、「ライブ」の公開された環境バージョンには行われない。変更か公開される時、新しいバージョンの「ライブ」環境が生成される。変更を保存する時、以前の環境バージョン（複数可）１３．３と共に、変更された現在の「ライブ」環境バージョンが保存され、バージョン番号がインクリメントされる。「ライブ」環境バージョンの新しいドラフトが自動的に作成され、環境に対するその後の変更は、ドラフトバージョンに行われる。一実施形態においては、環境のバージョン番号は、ライブバージョンにのみに適用され、「環境公開」アクションが成功した後に、インクリメントされる。環境の古いバージョンは、維持され、データベース（例えば、データベース２．２５内）から読み出すことができ、環境を規定するのに、必要に応じて、古いバージョンからの環境設定を使用できる。

一実施形態においては、環境が変化すると、環境記述子ワークフローをトリガして、環境記述子ファイル内の環境に関する環境記述子レコードを、変更を反映するように更新する。環境を公開する必要がある（すなわち、変更を環境にデプロイする必要がある）時、環境記述子ワークフローは、「環境公開」ワークフローを開始する。環境公開ワークフローは、一連のアクションを実行する。一連のアクションは、アプリケーション更新と、必要なサービス／リソースの更新と、変更内で１つまたは複数のマシンに変更が検出されなくても、更新された環境記述子レコードを環境内の全てのマシンに送り出すこととを含む。環境公開ワークフローは、一実施形態においては、以下のアクションを含むいくつかのアクションを実行する。
１．環境ドラフトバージョンをコミットする
２．現在のサービス状態と、環境にデプロイされたリビジョンをログする
３．マシンが終了することをチェックし、且つ、全てのＤＮＳレコードが有効であることをチェックする
４．新しいマシンをプロビジョニングし、且つ、任意の既存のマシンが動作していることを検証する
５．マシン上で新しいＤＮＳレコードを更新し、且つ、フローティングＩＰアドレスをチェック／追加する
６．マシン上でＡＣＭを更新する
７．アプリケーションスタックソフトウェアを更新する
８．最後に公開した環境バージョンをストレージに設定する

一実施形態においては、環境公開ワークフローは、ワークフローを介して実行されている様々なアクションの最新のステータスをチェックするオプションを提供する。図１４は、ステータスプレビューウィンドウの例示の画面ビューを示す。画面ビューは、「スナップショット」ウィンドウを示し、「スナップショットウィンドウ」は、どのサービスが環境で実行しているか、及び、各サービスのリビジョン情報を含む、環境サービスのステータスをチェックするためにデプロイメント機構によって提供される。ウィンドウは、幾つか例を挙げると、マシン名、各マシンで実行しているサービスの名前、各サービスのサービス状態、サービスのバージョン番号に関する情報を提供する。ウィンドウに提供されるフィールドのリストは、例示的であり、様々なアクションの最新のステータスを提供する、より少ないまたは多いフィールドが含まれてよい。

図１５は、一実施形態における、アプリケーションのリソース／サービスのプロビジョニングに使用されるデプロイメント機構のプロセスフローの概要を示すモデルである。タイトルＡ１５．１というアプリケーションが、ＥＣＯシステム１５．２が支援する環境で実行するためにＥＣＯシステムにアップロードされる。グラフィカルユーザインタフェース１５．３またはコマンドラインインタフェース１５．４を使用して、アプリケーション１５．１が環境で成功裏に実行するために必要となる全てのサービス／リソースを指定する環境の概要を提供する。ＧＵＩ１５．３またはＣＬＩ１５．４を通して入力された情報を使用して、環境記述子レコードを規定する（１５．５）。記述子レコードからの情報を処理して、記述子実行ファイルを生成する（１５．６）。アプリケーションを実行するその特定の環境に関するレコードが存在しない場合、記述子実行ファイルは、ＪＳＯＮ記述子ファイル１５．７内にＪＳＯＮ記述子レコードを作成する。あるいは、その特定の環境に関するレコードが存在する場合、記述子実行ファイルは、ＧＵＩまたはＣＬＩから受信した情報で、既存のＪＳＯＮ記述子レコードを更新する。ＪＳＯＮ記述子は、環境がアプリケーション実行のために存在するように、消費に必要なサービス／リソースの階層リストを規定する。

アプリケーションが実行のために選択される時、ＪＳＯＮ記述子ファイル１５．７が読み取られて、アプリケーションを成功裏に実行するために必要なリソース／サービスを識別し、適切なワークフローが実行されて（１５．８）、環境を作成し、必要なサービス／リソースがプロビジョニングされる。ワークフローによって、環境が規定され（１５．９）、環境内でリソース／サービスがインスタンス化される（１５．１０）。環境が規定され、サービス／リソースがプロビジョニングされると、アプリケーションがその環境で実行され、アプリケーションの状態、リソース／サービス、及び、ユーザが管理される（１５．１１）。

アプリケーション、リソース／サービスを管理することは、サービス／リソースならびにアプリケーションが実行する環境とを監視して、アプリケーションの性能が最適になるように環境が構成されているか否かを決定することを含み得る。結果として、サービスログ、アクションログ、ユーザログ、セッションログ、システムログ等を分析して、アプリケーションの追加のインスタンスをインスタンス化する必要があるか否か、アプリケーションの実行が需要、コスト、性能等を満たすために、プロビジョニングされたリソース／サービスが十分及び最適か否かを決定する。一実施形態においては、デプロイメント機構は、所定のルールセットを参照して、アプリケーションが最適に実行しているか否かを決定してよい。一実施形態においては、分析に基づいて、１つまたは複数のリソースまたはサービスを、同じクラウドサービス内で、若しくは、異なるクラウドサービス上で、１つのサーバから別のサーバに移す必要があり得ること、１つまたは複数のリソースまたはサービスをアップグレード、削除、追加、若しくは、変更する必要があり得ること、または、環境が１つのクラウドサービスから別のクラウドサービスに移される必要があることを決定してよい。変更を行う必要があると決定される時、環境内のアプリケーション実行に関連する様々な状態が保存され、環境に対する変更が行われ、適切な環境記述子レコードが更新され、変更が公開され、そして、アプリケーションは、様々な保存された環境の状態を用いて、新しい環境または変更された既存の環境のいずれかで、環境記述子レコードの情報を用いて再スタートされる。様々な状態は、ユーザ状態、サービス状態、アプリケーション状態等を含んでよい。

様々な実施形態から分かるように、デプロイメント機構は、アプリケーションをクラウドにデプロイするためのマルチクラウドオーケストレーションプラットフォームを提供する。アプリケーションが環境で実行するための全ての要件の概要を示す環境記述子ファイルは、集中的に維持されて、環境内の様々なマシンに配信される。アプリケーションが実行される時、環境記述子ファイルが読み取られ、どのアクションを行う必要があるかが決定され、アクションが行われ、アクションのステータスがログされ、取られた／取られなかったアクションのステータスがユーザに報告される。１つの組み込みＡＰＩが、ＥＣＯシステムと、様々なサービス／リソース、マシン、及び、様々なクラウドシステムサービスとの間の通信を複数のフォーマットを用いて可能にするように構成される。

様々な実施形態の詳細な記載を用いて、図１６を参照しながら方法を記載する。図１６は、一実施形態において、アプリケーションを成功裏に実行するためにクラウドシステム内にサービス／リソースをプロビジョニングするために使用する方法の動作を示す。方法は、動作１６１０で開始する。１６１０において、クラウドサービスでアプリケーションを実行する要求が検出される。アプリケーションは、異なるハードウェア／ソフトウェアプラットフォームで実行するように設計された、ビジネスアプリケーション、ソーシャルメディアアプリケーション、ゲームアプリケーション等を含む、任意の種類のアプリケーションであってよい。要求に応答して、動作１６２０に示すように、記述子ファイルにアクセスする。記述子ファイルは、リポジトリであり、１つまたは複数のクラウドサービスで実行される各アプリケーションに関して複数の記述子レコードを含む。動作１６３０に示すように、アプリケーションの記述子レコードが記述子ファイルから読み出される。読み出された記述子レコードは、そのクラウドサービスに固有であり、クラウドサービス環境でアプリケーションを成功裏に実行するために必要な環境リソース及び／またはサービスの詳細な仕様を提供する。

動作１６４０に示すように、記述子レコードで提供されたリソースとサービスの要件は、必要なリソースまたはサービスをプロビジョニングするためにクラウドサービス環境で取る必要のある１つまたは複数のアクションに翻訳される。リソースまたはサービスは、ストレージリソース、メモリ、ネットワークリソース、処理リソース等の技術リソース、及び／または、アプリケーションで指定された任意の依存性を満足させるサービスを含んでよい。サービスに関連付けられた行われ得る幾つかの例示のアクションは、ソフトウェアのダウンロード、ソフトウェアの設定、ソフトウェアの起動、サービスのデプロイ等に関連するアクションを含む。環境に関連付けられた行われ得る幾つかの例示のアクションは、環境の複製、サーバのプロビジョニング、サービスの開始／停止、サービスのデプロイ等に関連するアクションを含む。動作１６５０で示されるように、取られた（取られなかった）アクションのステータスが、要求に応答して、提供される。アクションのステータスは、環境設定データ（すなわち、ステータス、ソフトウェア及びバージョン、ＩＰアドレス等）の現在のステータスを提供するように、環境記述子レコードの様々なアクションフィールド／サブレコードのステータスを更新することによって提供されてよい。ステータスを用いて、クラウドサービスでアプリケーションを成功裏に実行するためにアプリケーションに必要なリソース及びサービスがプロビジョニングされたか否かを決定する。記述子レコードで規定された環境設定の結果、リソースが複数のクラウドサービスから活用されるハイブリッドホスティングソリューションを生じ得ることに注意されたい。デプロイメント機構によって、アプリケーションは、ハイブリッドホスティングソリューションを含む自身の環境設定を制御し、それ自体のワークフローセットを決定することができ、アプリケーションを真にマルチクラウドホスティング管理ソリューションにする。

図１７は、クラウドサービスでアプリケーションを成功裏に実行するためにリソース／サービスのプロビジョニングに使用する方法の代替実施形態を示す。方法は、動作１７１０で開始する。動作１７１０において、アプリケーションが成功裏に実行するためにクラウドシステムで必要とされる１つまたは複数のリソースまたはサービスの属性を受信する。属性は、必要なリソースまたはサービスの種類、必要なリソースまたはサービスの量／レベル／バージョン等を識別してよい。動作１７２０に示すように、受信したリソースまたはサービスの属性を用いて、アプリケーションの記述子レコードが生成される。記述子レコードは、クラウドシステムに固有の環境プロファイルを規定する、また、記述子レコードは、リソースとサービスの要件をクラウドシステムで必要なリソース及びサービスをプロビジョニングするために取るべき１つまたは複数のアクションに翻訳することによって生成される。生成された記述子レコードは、デプロイメントシステムデータベースに維持される記述子ファイルに記憶される。後続のアプリケーション実行要求が受信されると、記述子レコードが、記述子ファイルから読み出される。動作１７３０に示すように、読み出しによって、識別されたアクションが自動的にトリガされる。アクションのトリガによって、クラウドシステムにおけるアプリケーションの実行を可能にするためにクラウドシステムにサービスまたはリソースをプロビジョニングする１つまたは複数のワークフローがインスタンス化されてよい。

本発明の実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベース若しくはプログラム可能家庭用電化製品、ミニコンピュータ、メインフレームコンピュータ等を含む、様々なコンピュータシステム構成を用いて実践されてよい。本発明は、有線または無線のネットワークでリンクされたリモート処理装置によってタスクが行われる分散コンピュータ環境で実践することもできる。

上記実施形態を考慮して、発明は、コンピュータシステムに記憶されたデータを伴う様々なコンピュータ実施動作を採用できることを理解されたい。これらの動作は、物理量の物理的操作を必要とする動作である。発明の一部を形成する本明細書に記載の動作はいずれも、有用なマシン動作である。発明は、これらの動作を行うデバイスまたは装置にも関する。装置は、必要な目的に合わせて特に構築することができる、または、装置は、コンピュータに記憶されたコンピュータプログラムによって選択的に起動または構成された汎用コンピュータであってよい。詳細には、本明細書の教示に従って書かれたコンピュータプログラムと共に様々な汎用マシンを使用することができ、または、必要な動作を行うより専門的な装置を構築するとより便利であろう。

発明は、コンピュータ可読媒体上のコンピュータ可読コードとして具体化することもできる。コンピュータ可読媒体は、データを記憶することができ、そのデータを後にコンピュータシステムで読み取ることができる任意のデータ記憶装置である。コンピュータ可読媒体の例は、ハードドライブ、ネットワーク接続ストレージ（ＮＡＳ）、リードオンリメモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、及び、他の光学若しくは非光学データ記憶装置を含む。コンピュータ可読媒体は、コンピュータ可読コードを記憶し、分散して実行するように、ネットワーク接続コンピュータシステムを介して分散されたコンピュータ可読有形媒体を含むことができる。

方法の動作は特定の順序で記載したが、動作の間に他のハウスキーピング動作を行ってよく、動作は、少しずつ異なる時間に行われるように調整されてよく、または、オーバーレイ動作の処理が所望のように行われる限り、処理に関連付けられた様々な間隔で処理動作を行うことができるシステムに分散されてよいことは理解されたい。

上記発明は、理解しやすいように、いくらかの詳細を記載したが、添付の請求項の範囲内で一定の変更及び修正を行うことができるのは明らかである。従って、本実施形態は、制限的なものではなく例証的なものとみなすべきであり、発明は、本明細書に記載の詳細に制限されず、請求項の範囲及びその同等物の範囲で修正されてよい。

Claims (22)

1. クラウドサービスの環境においてアプリケーションを実行する要求を検出し、
   前記要求に応答して、リポジトリから記述子ファイルであって、１つまたは複数のクラウドサービスで実行するべき各アプリケーションに関して１つまたは複数の記述子レコードを有する前記記述子ファイルにアクセスし、
   前記アプリケーションの記述子レコードを前記記述子ファイルから読み出すことであって、前記読み出された記述子レコードは、前記クラウドサービス環境に固有で、前記クラウドサービス環境で前記アプリケーションを実行するために必要なリソースとサービスの要件を提供する、前記記述子レコードを読み出し、
   前記アプリケーションに前記サービスとリソースをプロビジョニングするために前記クラウドサービス環境で取るべき１つまたは複数のアクションに前記リソースとサービスの要件を翻訳し、前記取るべきタスクは、前記アプリケーションの前記記述子レコードで提供される前記リソースとサービスの要件の詳細に基づいて、所定のシーケンスで生じるように仲介される、前記リソースとサービスの要件を翻訳し、
   前記要求に応答して、取るべきアクションのステータスを提供し、前記ステータスは、前記要求されたリソースとサービスが前記クラウドサービスで前記アプリケーションの実行に成功するためにプロビジョニングされたか否かを決定するために使用される、前記ステータスを提供する方法であって、プロセッサによって実行される方法。
2. 前記取るべきアクションは、
   前記翻訳で識別された前記アクションのそれぞれに関するワークフローを識別、インスタンス化することを含み、前記ワークフローは、前記アプリケーションの前記サービスとリソースのプロビジョニングに使用される、
   請求項１に記載の方法。
3. 前記ワークフローは、前記１つまたは複数のアクションで提供された仕様に従って、様々なクラウドサービスでインスタンス化され、前記様々なクラウドサービスは、それぞれ、前記アプリケーションの前記記述子レコードで指定された前記リソースまたはサービスの要件を満たす別個のサービスまたはリソースを含む、請求項２に記載の方法。
4. ステータスの提供には、取られないアクションのステータスを提供することがさらに含まれる、請求項１に記載の方法。
5. 前記クラウドサービスの前記環境の前記サービスとリソースとやりとりしてアクションの前記ステータスを取得するためにアプリケーションプログラミングインタフェース（ＡＰＩ）を更に備える、請求項１に記載の方法。
6. 前記ＡＰＩは、前記アプリケーションを実行するために必要なリソースとサービスの要件の前記詳細を取得するようにさらに構成され、前記詳細は、前記記述子レコードの生成に使用される前記ＡＰＩによって取得される、請求項５に記載の方法。
7. 前記ＡＰＩは、コマンドラインインタフェースまたはグラフィカルユーザインタフェースを通してアクセスされる、請求項５に記載の方法。
8. 前記アプリケーションが利用可能な前記リソースまたはサービスの１つまたは複数の変更を検出し、
   前記アプリケーションの後続の実行のために前記適切なリソースとサービスのプロビジョニングを可能にするように、前記検出した変更に従って、実質的にリアルタイムで、前記アプリケーションの前記クラウドサービスに関連付けられた前記記述子レコードを自動的に更新し、
   前記１つまたは複数のリソースまたはサービスの前記変更は、追加、削除、変更、アップグレード、または、それらの組み合わせを含む、
   請求項１に記載の方法。
9. 前記アプリケーションの性能を監視し、前記アプリケーションにプロビジョニングされた前記リソースとサービスの１つまたは複数を動的調整して、前記アプリケーションの最適な実行を可能にすることをさらに含み、前記動的調整には、前記クラウドサービスの前記アプリケーションの前記対応する記述子レコードの前記１つまたは複数のリソースとサービスの詳細を自動的に更新することがさらに含まれ、
   前記動的調整には、追加のリソースまたはサービスをプロビジョニングすることが含まれる、
   請求項１に記載の方法。
10. 前記動的調整は、前記アプリケーションに望む性能の種類に基づくものである、請求項９に記載の方法。
11. 前記監視からの情報は、前記アプリケーションの使用量プロファイルの予測に用いられ、且つ、前記予測された使用量プロファイルに基づいて前記リソースとサービスを動的に調整するために用いられる、請求項９に記載の方法。
12. 前記使用量プロファイルの予測には、
    前記アプリケーションの異なる実行時間中に、前記アプリケーションが使用するリソースとサービスの使用量履歴であって、前記アプリケーションのメタデータから取得される前記使用量履歴を決定し、
    前記メタデータで提供される前記リソースとサービスの前記使用量履歴に基づいて、前記クラウドサービスの前記環境の前記使用量プロファイルを規定することが含まれる、請求項１１に記載の方法。
13. 前記リソースとサービスの動的調整には、前記アプリケーションの前記予測された使用量プロファイルに基づいて、前記アプリケーションの新しいクラウドサービスへの移行が含まれ、前記新しいクラウドサービスは、前記アプリケーションを最適に実行するために前記必要なリソースとサービスを有する、請求項１１に記載の方法。
14. 前記アプリケーションの移行には、
    ユーザ状態、アプリケーション状態、再スタート点、及び、前記アプリケーションに関連する他のデータを記憶し、
    前記記述子レコードに規定された適切なアクションを取ることによって、前記新しいクラウドサービスに前記リソースとサービスをプロビジョニングし、
    前記アクションの前記ステータスに基づいて、前記新しいクラウドサービス内にプロビジョニングされた前記リソースとサービスの詳細を規定するように前記アプリケーションの前記記述子レコードを更新し、
    前記新しいクラウドサービスの前記アプリケーションのインスタンスを実行することがさらに含まれ、前記アプリケーションは、前記記憶されたアプリケーション状態、前記ユーザ状態、再スタート点、及び、実行中の前記他のデータを使用し、
    前記記憶、プロビジョニング、更新、及び、実行は、実質的にリアルタイムで行われる、
    請求項１３に記載の方法。
15. アプリケーションを実行するためにクラウドシステム上で必要な１つまたは複数のリソースとサービスの属性を受信し、
    前記受信した属性を用いて、前記アプリケーションの記述子レコードを生成し、前記記述子レコードは、前記クラウドシステムに固有の環境プロファイルを規定し、前記記述子レコードは、前記アプリケーションの実行に成功するために前記クラウドシステムに前記必要なリソースとサービスをプロビジョニングするために取るべき１つまたは複数のアクションに前記リソースとサービスの要件を翻訳することによって生成され、前記生成された記述子レコードは、前記受信した属性に基づいて、前記取るべきアクションの所定のシーケンスを識別することである、前記記述子レコードを生成し、
    前記クラウドシステムで前記アプリケーションのその後の実行中に読み出すために、デプロイメントシステムデータベースに維持された記述子ファイルに前記記述子レコードを記憶し、を含む方法であって、前記読み出しによって、前記記述子レコードで識別されたアクションが自動的にトリガされて、前記アプリケーションの実行を成功させることを可能にする前記必要なサービスとリソースの前記クラウドシステムへの前記プロビジョニングが行われ、
    方法の動作は、プロセッサによって行われる、
    前記方法。
16. 前記属性は、コマンドラインインタフェースまたはグラフィカルユーザインタフェースを用いて、アプリケーションプログラミングインタフェース（ＡＰＩ）を通して受信される、請求項１５に記載の方法。
17. 前記リソースとサービスの前記属性は、前記アプリケーションのコードの調査に基づいて、受信される、請求項１５に記載の方法。
18. 前記取るべきアクションは、
    前記記述子レコードで識別された前記アクションのそれぞれのワークフローを識別、インスタンス化することをさらに含む、請求項１５に記載の方法。
19. 前記クラウドシステムの前記アプリケーションの性能を監視し、
    前記リソースとサービスの１つまたは複数を動的に調整して、前記アプリケーションの最適性能を可能にし、
    前記１つまたは複数のリソースとサービスに対して行われる前記調整に従って前記アプリケーションの前記記述子レコードを自動的に更新し、
    をさらに含み、前記記述子レコードは、前記クラウドシステムの現在の環境プロファイルを規定する、請求項１５に記載の方法。
20. 前記動的な調整は、前記アプリケーションを新しいクラウドシステムに移すことを含み、前記新しいクラウドサービスは、前記アプリケーションの最適性能のための前記必要なリソースとサービスを有し、
    前記新しいクラウドシステムは、前記アプリケーションに望まれる性能の種類に基づいて識別される、請求項１９に記載の方法。
21. 前記アプリケーションの移行には、
    ユーザ状態、アプリケーション状態、再スタート点、及び、前記アプリケーションに関連する他のデータを記憶し、
    前記リソースとサービスを前記新しいクラウドシステムにプロビジョニングし、
    前記新しいクラウドシステム内にプロビジョニングされた前記リソースとサービスの詳細を規定するように前記アプリケーションの前記記述子レコードを更新し、
    前記新しいクラウドシステムで前記アプリケーションのインスタンスを実行することがさらに含まれ、前記アプリケーションは、実行中、前記記憶されたアプリケーション状態、前記ユーザ状態、再スタート点、及び、前記他のデータを使用し、
    前記記憶、プロビジョニング、更新、及び、実行は、実質的にリアルタイムで行われる、請求項２０に記載の方法。
22. 前記アプリケーションが利用可能な１つまたは複数のリソースとサービスの変更を検出し、
    前記アプリケーションのその後の実行のために前記適切なリソースのプロビジョニングを可能にするように、前記検出された変更に従って、前記アプリケーションに関連付けられた前記記述子レコードを実質的にリアルタイムで更新し、
    前記１つまたは複数のリソースとサービスの前記変更は、追加、変更、削除、アップグレード、または、それらの組み合わせを含み、前記更新された記述子レコードは、前記アプリケーションの前記実行に使用される現在の環境プロファイルを規定する、
    請求項１５に記載の方法。