JP2023511114A - デプロイ命令のために有向非巡回グラフを利用するための技術 - Google Patents

Abstract

デプロイ命令のために有向非巡回グラフを利用するための技術を開示する。コンピュータにより実現される方法は、様々な動作を含み得る。コンピューティングデバイスによって、デプロイに関連する設定データの複数回の解析を実行する命令が実行され得る。コンピューティングデバイスは、第１ＤＡＧ（有向非巡回グラフ）を生成させてもよく、第１ＤＡＧは、解析に基づいて第１リソースをデプロイするために利用される。解析に基づいて実行ターゲットをデプロイするための第２ＤＡＧが生成されてもよく、第２ＤＡＧは、デプロイメントの実行ターゲット間の依存関係を指定する。コンピューティングデバイスは、解析に基づいて連結リストデータ構造を生成してもよく、連結リストデータ構造を横断することによってコンピューティングシステムをデプロイし得る。

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. コンピュータ命令を備えるコンピュータプログラムプロダクトであって、前記コンピュータ命令は、プロセッサによって実行されると、請求項１～９のいずれか１項に記載の方法のステップを実行する、コンピュータプログラムプロダクト。

Images