JP2023511113A - 宣言型プロビジョニングツールを使用してインフラストラクチャリソースを展開するための技術 - Google Patents

Abstract

インフラストラクチャオーケストレーションサービスを実施するための技術が説明される。スケジューラは、実行対象におけるリソースの第１の展開のために、第１のリリース識別子を含み得る構成ファイルを受信することができる。リソースは、当該ファイルに従って実行対象に展開することができる。リソースの現在の状態は、記憶され得る。スケジューラは、当該実行対象における新しい展開のために、第２のリリース識別子を含み得る、当該ファイルの第２のバージョンを受信することができる。少なくとも１つのワーカーノードは、プラグインを実行して、第１の識別子を第２の識別子と比較することができる。第１の識別子が第２の識別子と異なる場合、当該プラグインは、第２の識別子に従ってリソースの現在の状態を所望の状態と比較することができる。所望の状態が現在の状態とは異なる場合、リソースは、第２の識別子に従って実行対象に展開される。

Description

本出願は、「宣言型プロビジョニングツールを使用してインフラストラクチャリソースを展開するための技術」と題される２０２０年１月２０日付提出の米国出願第６２／９６３，３３５号および「インフラストラクチャリソースを展開するための技術」と題される２０２０年９月１０日付提出の米国出願第１７／０１６,７５４号の米国特許法第１１９条（ｅ）の利益および優先権を主張し、それらの内容は、あらゆる目的のためにその全体が参照により本明細書に組み込まれる。

背景
今日、クラウドインフラストラクチャサービスは、多くの個々のサービスを利用して、当該クラウドインフラストラクチャサービスの多くの領域にわたって（それぞれ）コードおよび構成を準備（provisioning）および展開（deploy）する。特に、クラウドインフラストラクチャサービスをプロビジョニングすること（provisioning）が概して宣言的であること、および、コードをデプロイ（deploy）することが必須であることを考慮すると、これらのツールは、使用するためにかなりの手動の努力を必要とする。加えて、サービスチームおよび地域の数が増えるにつれて、クラウドインフラストラクチャサービスは成長し続ける必要がある。より多数の一層小さい領域にデプロイするいくつかのクラウドインフラストラクチャサービスの戦略は、領域ごとの支出を含み、これは上手くスケーリングされないことがある。

概要
インフラストラクチャオーケストレーションサービスを実施するための技術が説明される。いくつかの例では、方法は、実行対象におけるリソースの第１の展開のために、第１のリリース識別子を含み得る構成ファイルを受信することができるスケジューラを含み得る。当該リソースは、ファイルに従って実行対象に展開されることができる。リソースの現在の状態は、記憶されることができる。スケジューラは、実行対象における新しい展開のために、第２のリリース識別子を含み得るファイルの第２のバージョンを受信することができる。少なくとも１つのワーカーノードは、プラグインを実行して、第１の識別子を第２の識別子と比較することができる。第１の識別子が第２の識別子と異なる場合、プラグインは、リソースの現在の状態を、第２の識別子に従う所望の状態と比較することができる。所望の状態が現在の状態とは異なる場合、リソースは、第２の識別子に従って実行対象に展開される。

他の例では、システムは、少なくとも１つのプロセッサと、当該プロセッサによって実行されると動作を実行するように当該プロセッサを構成するコンピュータが実行可能な命令を記憶できる少なくとも１つのメモリとを含み得る。当該動作は、スケジューラが、実行対象におけるリソースの第１の展開のための、第１のリリース識別子を含み得る構成ファイルを受信することを含み得る。当該リソースは、当該構成ファイルに従って実行対象に展開されることができ、当該リソースの現在の状態は、記憶されることができる。スケジューラは、当該実行対象における新しい展開のために、第２のリリース識別子を含み得る、当該構成ファイルの第２のバージョンを受信できる。少なくとも１つのワーカーノードは、プラグインを実行して、第１のリリース識別子を第２のリリース識別子と比較することができる。第１のリリース識別子が第２のリリース識別子と異なる場合、プラグインは、リソースの現在の状態を第２の構成ファイルに従うリソースの所望の状態と比較するために使用され得る。所望の状態が現在の状態とは異なる場合、当該リソースは、構成ファイルの第２のバージョンに従って実行対象に展開され得る。

さらに他の例では、コンピュータ読み取り可能な記憶媒体は、少なくとも１つのプロセッサによって実行されると、当該プロセッサに動作を実行させることができるコンピュータ実行可能な命令を記憶することができる。当該動作は、スケジューラが、実行対象におけるリソースの第１の展開のための、第１のリリース識別子を含み得る構成ファイルを受信することを含み得る。当該リソースは、当該構成ファイルに従って実行対象に展開されることができ、当該リソースの現在の状態は記憶され得る。当該スケジューラは、実行対象における新しい展開のために、第２のリリース識別子を含み得る、当該構成ファイルの第２のバージョンを受信できる。少なくとも１つのワーカーノードは、プラグインを実行して、第１のリリース識別子を第２のリリース識別子と比較することができる。第１のリリース識別子が第２のリリース識別子と異なる場合、当該プラグインは、リソースの現在の状態を、第２の構成ファイルに従うリソースの所望の状態と比較するために使用され得る。当該所望の状態が現在の状態とは異なる場合、当該リソースは、構成ファイルの第２のバージョンに従って実行対象に展開され得る。

さらに他の例では、装置は、本明細書で説明される方法のいずれかによるステップを実行するための手段を備えることができる。

任意の特定の要素または動作の議論を容易に識別するために、参照番号の最上位の数字（単数または複数）は、その要素が最初に導入される図の番号を指す。

少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するためのアーキテクチャを示すためのブロック図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するためのアーキテクチャを示すためのブロック図である。 少なくとも１つの実施形態に従う例示的なフロックを示すためのフロー図である。 少なくとも１つの実施形態に従う例示的なフロックを示すためのフロー図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するためのアーキテクチャを示すためのブロック図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するためのアーキテクチャを示すためのブロック図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するために使用されるコードを示すための図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するために使用されるコードを示すための図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するための例示的なプロセスを示すためのフロー図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するためのアーキテクチャを示すためのブロック図である。 少なくとも１つの実施形態に従う、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実施するための例示的なプロセスを示すためのフロー図である。 少なくとも１つの実施形態に従う分散システムを示すためのブロック図である。 少なくとも１つの実施形態に従う、実施形態のシステムの１つまたは複数の構成要素によって提供されるサービスがクラウドサービスとして提供され得るシステム環境の１つまたは複数の構成要素を示すためのブロック図である。 本開示の様々な実施形態が実装され得る例示的なコンピュータシステムを示すブロック図である。

いくつかの例では、サービスとしてのインフラストラクチャ（ＩａａＳ）は、１つの特定のタイプのクラウドコンピューティングである。ＩａａＳは、パブリックネットワーク（たとえば、インターネット）を介して仮想化されたコンピューティングリソースを提供するように構成され得る。いくつかの例では、ＩａａＳは、クラウドコンピューティングサービスの３つの主要なカテゴリ（または、サブカテゴリ）のうちの１つである。大抵の人は、他の主なカテゴリが、ソフトウェア・アズ・ア・サービス（ＳａａＳ）およびプラットフォーム・アズ・ア・サービス（ＰａａＳ）であると考え、時には、ＳａａＳは、ＰａａＳおよびＩａａＳの両方を包含する、より広いカテゴリであると考えられ得、ＩａａＳもＰａａＳのサブカテゴリであると考える人もいる。

ＩａａＳモデルでは、クラウドコンピューティングプロバイダは、インフラストラクチャ構成要素（例えば、サーバ、記憶装置、ネットワークノード（例えば、ハードウェア）、デプロイメントソフトウェア、プラットフォーム仮想化（例えば、ハイパーバイザ層）等）をホストすることができる。

場合によっては、ＩａａＳプロバイダはまた、それらのインフラストラクチャ構成要素（例えば、課金、監視、ロギング、セキュリティ、負荷分散およびクラスタリング等）に付随する様々なサービスを提供し得る。したがって、これらのサービスはポリシー駆動型であり得るので、ＩａａＳユーザは、アプリケーションの可用性および性能を維持するために負荷分散を駆動するためのポリシーを実装することが可能であり得る。

いくつかの事例では、ＩａａＳ顧客は、インターネットのようなワイドエリアネットワーク（ＷＡＮ）を通してリソースおよびサービスにアクセスし得、クラウドプロバイダのサービスを使用して、アプリケーションスタックの残りの要素をインストールすることができる。たとえば、ユーザは、ＩａａＳプラットフォームにログインして、仮想マシン（ＶＭ）を作成し、各ＶＭにオペレーティングシステム（ＯＳ）をインストールし、データベースのようなミドルウェアを展開し、ワークロードおよびバックアップのためのストレージバケットを作成し、さらにはエンタープライズソフトウェアをＶＭにインストールできる。次いで、顧客は、プロバイダのサービスを使用して、ネットワークトラフィックのバランシング、アプリケーション問題のトラブルシューティング、性能の監視、災害復旧の管理等を含む様々な機能を実行できる。

ほとんどの場合、クラウドコンピューティングモデルは、クラウドプロバイダの参加を必要とする。クラウドプロバイダは、ＩａａＳの提供（例えば、提供、貸与、販売）に特化した第三者サービスであり得るが、そうである必要はない。エンティティはまた、プライベートクラウドをデプロイすることを選択し、インフラストラクチャサービスの独自のプロバイダになり得る。

いくつかの例では、ＩａａＳデプロイメントは、新しいアプリケーションまたは新しいアプリケーションの新しいバージョンを、準備されたアプリケーションサーバなどに置くプロセスである。これはまた、（例えば、ライブラリー、デーモンなどをインストールする）サーバを準備するプロセスを含み得る。これは、多くの場合、ハイパーバイザ層（例えば、サーバ、ストレージ、ネットワークハードウェア、および仮想化）の下のクラウドプロバイダによって管理される。したがって、顧客は、ハンドリング（ＯＳ）、ミドルウェア、および／またはアプリケーションデプロイメント（たとえば、（一例としてオンデマンドで起動され得る）セルフサービス仮想マシン上での）等に責任を有し得る。

いくつかの例では、ＩａａＳプロビジョニングは、使用のためにコンピュータまたは仮想ホストを取得すること、および、必要とされるライブラリまたはサービスをそれらにインストールすることさえも指し得る。ほとんどの場合、デプロイメントはプロビジョニングを含まず、当該プロビジョニングは最初に実行される必要があり得る。

場合によっては、ＩａａＳプロビジョニングには２つの異なる問題がある。第１に、何かが実行する前にインフラストラクチャの初期セットをプロビジョニングするという最初の課題がある。第２に、あらゆるものがプロビジョニングされると、既存のインフラストラクチャを発展させる（例えば、新しいサービスを追加すること、サービスを変更すること、サービスを削除すること等）という課題がある。場合によっては、これらの２つの課題は、インフラストラクチャの構成が宣言的に定義されることを可能にすることによって対処され得る。言い換えれば、インフラストラクチャ（例えば、どの構成要素が必要とされるか、および、それらがどのように相互作用するか）は、１つまたは複数の構成ファイルによって定義され得る。したがって、インフラストラクチャの全体的なトポロジー（例えば、どのリソースがどのリソースに依存するか、および、それらがそれぞれどのように協働するか）は、宣言的に説明され得る。いくつかの例では、トポロジが定義されると、構成ファイルに記述された異なる構成要素を作成および／または管理するワークフローが生成され得る。（例えば、所望の出力を単に含み得る、実行されるべきものについての情報を含む）宣言的命令とは対照的に、暗黙的命令は、（例えば、物事を実行させるために必要とされるステップ、構成要素、および状態についての情報を含む）実行されるべきことをどのように行うかについての情報を含む。

いくつかの例では、インフラストラクチャは、多くの相互接続された要素を有し得る。たとえば、コアネットワークとしても知られている、１つまたは複数の仮想プライベートクラウド（ＶＰＣ）（例えば、構成可能な、および／または、共有されたコンピューティングリソースの潜在的にオンデマンドのプール）があり得る。いくつかの例では、ネットワークのセキュリティがどのように設定されるか、および、１つまたは複数の仮想マシン（ＶＭ）を定義するために準備された１つまたは複数のセキュリティグループルールが存在する場合もある。ロードバランサ、データベース等のような他のインフラストラクチャ要素も準備され得る。ますます多くのインフラストラクチャ要素が望まれ、および／または、追加されると、インフラストラクチャは漸進的に進化し得る。

上述のように、インフラストラクチャを準備する１つの方法は、インフラストラクチャを宣言的に説明することである。したがって、構成ファイルは、上述のインフラストラクチャ構成要素の各々と、それらがどのように対話するかとを単に記述する宣言型ファイルであり得る。構成ファイルは、要素を作成するために必要とされるリソースおよび関連フィールドを記述することができ、次いで、前に記述された要素を参照する他の要素が記述され得る。いくつかの例では、プロビジョニングツールは、次いで、構成ファイルに記述される要素を作成および管理するためのワークフローを生成することができる。

いくつかの例では、プロビジョニングツールのワークフローは、様々なコマンドを実行するように構成され得る。実行可能な１つの機能は、ビュー調整であり、プロビジョニングツールは、現在のインフラストラクチャのビュー（例えば、インフラストラクチャの予想される状態）を、インフラストラクチャが実際にどのように動作しているかと比較することができる。いくつかの例では、ビュー調整機能を実行することは、様々なリソースプロバイダまたはインフラストラクチャリソースに問い合わせて、どのリソースが実際に実行されているかを識別することを含み得る。プロビジョニングツールが実行できる別の機能は、計画生成であり、ここで、プロビジョニングツールは、実際に実行されているインフラストラクチャ構成要素を、プロビジョニングツールがそのようにしたいとする状態（例えば、所望の構成）と比較することができる。言い換えれば、計画生成機能は、リソースを最新の期待値に近づけるために、どの変更を行う必要があるかを決定することができる。いくつかの例では、第３の機能は実行（例えば適用）機能であり、ここでプロビジョニングツールは当該計画生成機能によって生成された計画を実行することができる。

概して、プロビジョニングツールは、構成ファイルを取得し、その中に含まれる宣言的情報を解析し、計画を実行するためにリソースがプロビジョニングされる必要がある順序を、プログラム的に／自動的に、判定するように構成され得る。例えば、セキュリティグループルールおよびＶＭがブートされる前にＶＰＣがブートされる必要がある場合、プロビジョニングツールは、ユーザの介入なしに、および／または、情報が構成ファイルに必ずしも含まれることなく、その決定を行い、その順序で当該ブートを実施することができる。

いくつかの例では、様々な仮想コンピューティング環境にわたるインフラストラクチャコードの展開を可能にするために、連続デプロイメント技術が採用され得る。加えて、当該記述される技術は、これらの環境内で、インフラストラクチャ管理を可能にする。いくつかの例では、サービスチームは、１または複数、しかし、しばしば（例えば、様々な異なる地理的位置にわたって、時として世界全体に及ぶ）異なる製造環境に、展開されることが望まれるコードを書き込むことができる。しかしながら、いくつかの例において、コードが展開されるインフラストラクチャは、最初にセットアップされなければならない。いくつかの事例では、プロビジョニングは、手動で行われることができ、プロビジョニングツールは、リソースをプロビジョニングするために利用されてもよく、および／または、デプロイメントツールは、インフラストラクチャがプロビジョニングされると、コードをデプロイするために利用され得る。

上述のように、一般に、インフラストラクチャリソースのプロビジョニングおよびインフラストラクチャリソースを制御するためのコードのデプロイの各々を処理するために使用される２つの異なるツールがあり、２つのツール間のオーケストレーションは手動で実行される。しかしながら、大規模には、手動の実行は、常に偏差につながる。したがって、仮想インフラストラクチャをプロビジョニングおよびデプロイの両方を行うことができる自動化ツールは、仮想クラウド環境を実施するためのより効率的でかつ信頼できる技術を可能にする。

いくつかの例では、２つのツールが使用される場合、ユーザがプロビジョニングフェーズとデプロイメントフェーズとの間でコードに手動で変更を行うときに問題が生じ得る。本明細書で説明されるように、プロビジョニングおよびデプロイメントの両方のために単一のツールを使用する技術は、手動によるコード変更の機会がないように、プロセスを自動化することによってそれを軽減することができる。あるユーザが何かをコード化するやり方のわずかな変化が、デプロイメントフェーズにおいて大きな問題を引き起こす場合がある。いくつかの例では、オペレータが新しい領域においてアクション（たとえば、コード中のタイプミス）を最初に実行すると、当該タイプミスでコーディングされたオブジェクトは、常にその方法であり得る。アプリケーションがそのタイプミスで展開され、アプリケーションがそのタイプミスに敏感でない場合（例えば、それが依然として機能している場合）、将来的には、いつか、追加のコード変更がそのタイプミスの影響を受けやすくなり、システム全体がクラッシュする可能性がある。したがって、本明細書で提供される技術は、しばしば問題につながり得る、プロビジョニングとデプロイメントとの間のギャップを除去することができる。

概して、モデル化デプロイメントは、構成ファイルがインフラストラクチャリソースを宣言するために使用されることができるように、宣言的である。例えば、生成（create）、読出（read）、更新（update）、削除（delete）（ＣＲＵＤ）命令は、一般的なレプレゼンテイショナル・ステイト・トランスファー（ＲＥＳＴ）コンセプト（例えば、ＲＥＳＴアプリケーションプログラミングインターフェイス（ＡＰＩ））を用いてデプロイメントファイルを生成するために一般的に使用される。しかしながら、デプロイメント自体は、概して、同じ概念に従わない。加えて、インフラストラクチャプロビジョニングツールは、実際に強力かつ／または表現的である傾向がある一方、デプロイメントのためのツールは、それらが実行することができる動作（例えば、それらは宣言的とは対照的に必須である）に関して、はるかに制限的である傾向がある。いくつかの例では、必須ツールは、構成要素のワークフロー、状態などを必ずしも記述しない必須命令を受信する。例えば、中央インフラストラクチャサービスは、必須であってもよく、このことは、（例えば、タスクを実行するために必要とされる様々なステップを記述する）宣言的命令とは対照的に、必須命令（例えば、所望の出力）を受信することを意味する。しかしながら、いくつかの例では、本明細書で説明される中央インフラストラクチャサービスは宣言型であり得る。したがって、クラウド環境内で両方の機能的要件（例えば、インフラストラクチャ要素のプロビジョニングおよび展開）に対処することができるツールが長年にわたって必要とされている。

いくつかの例では、クラウドインフラストラクチャオーケストレーションサービス（ＣＩＯＳ）を実施するための技術が本明細書で説明される。そのような技術は、上で簡単に説明したように、クラウド環境内のインフラストラクチャ資産のプロビジョニングおよびデプロイメントの両方を管理するように構成され得る。幾つかの例では、ＣＩＯＳは、サービスの２つのクラス：中央および領域構成要素（例えば、ＣＩＯＳ中央およびＣＩＯＳ領域）を含み得る。以下の用語は、全体を通して使用される：
・インフラストラクチャ構成要素－実行コードをサポートする長寿命のインフラストラクチャの一部分。

- 例：デプロイメントアプリケーション、ロードバランサ、ドメインネームシステム（ＤＮＳ）エントリ、オブジェクトストレージバケット等。

・アーチファクト － デプロイメントアプリケーションまたはクーベネティス（Kubernetes）エンジンクラスタに展開されるコード、または、インフラストラクチャ構成要素に適用される構成情報（以下、「構成」）。これらは読み出し専用リソースであり得る。

・デプロイメントタスク － コードのデプロイまたはテストにしばしば関連付けられる短命タスク。加えて、デプロイメントタスクは、それらを作成するリリースを超えて生存しないリソースとしてモデル化される。

- 例:“deploy $artifact to $environment,”、“watch $alarm for １０ minutes,”、“execute $testSuite,”、または、“wait for $manualApproval”
- 例えば、ＣＩＯＳは、それが完了したときに利用可能状態に遷移するリソースの作成物として、デプロイメントケストレータデプロイメントをモデル化することができる。

- ＣＩＯＳは、関連付けられた宣言型プロビジョナの状態を維持するため、ＣＩＯＳは、リリースに関連するこれらの短寿命のリソースのライフサイクルを制御できる。

・リソース － ＣＲＵＤ可能なリソース。
- ＣＩＯＳは、上記に列挙した構築物の各々をリソースとしてモデル化する。次のセクションでは、このモデル化を詳細に説明する。

・フロック（Flock） － 制御領域およびその全ての構成要素をカプセル化するＣＩＯＳのモデル。主として、インフラストラクチャ構成要素の所有権をモデル化し、指すために存在する。

・フロック構成 － 単一サービスに関連付けられた全てのインフラストラクチャ構成要素、アーチファクト、およびデプロイメントタスクのセットを記述する。

- 各フロックは正確に１つのフロック構成を有する。フロック構成は、ソース制御にチェックインされる。

- フロック構成は、宣言的である。それらは、ＣＩＯＳが領域、地域、広告、およびアーチファクトバージョンを入力として提供することを期待する。

- フロックは粒状である。１つのフロックは、単一のサービスおよびサポートインフラストラクチャからなる。

・状態 － フロック内のあらゆるリソースの状態のその時点のスナップショット。
・リリース － フロック構成の特定のバージョンと、それが参照するあらゆるアーチファクトの特定のバージョンとのタプル。

- リリースを、まだ存在しないかもしれない状態を記述すると考える。
・リリース計画 － ＣＩＯＳが全ての領域をそれらの現在の状態からリリースによって記述される状態に遷移させるために取る一組のステップ。

- リリース計画は、有限数のステップと、明確に定義された開始および終了時間とを有する。

・適用 － これは名詞である。リリース計画を実行する単一の試み。実行は、フロックの現在の状態を変更する。

ＣＩＯＳは、下流システム（例えば、ワールドワイド）に構成を適用するオーケストレーション層として説明され得る。それは、サービスチームからの手作業なしで（例えば、いくつかの例における最初の承認を越えて）、ワールドワイドなインフラストラクチャプロビジョニングおよびコードデプロイメントを可能にするように設計される。ＣＩＯＳの高レベルの責任は、以下を含むが、これらに限定されない：
・任意の飛行中の変更活動を含む、ＣＩＯＳによって管理されるリソースの現在の状態に対するビューをチームに提供すること。

・チームが新しい変更を計画しリリースすることを支援すること。
・人の介入なしで、承認されたリリース計画を実行するために、領域内の様々な下流システムにわたって活動を調整すること。

・認可されたリリース計画をワールドワイドに実行するために地域／領域にわたって活動を調整すること。

いくつかの例では、ＣＩＯＳは、チームがチェックインコードを介して構成情報をＣＩＯＳに提供することを可能にすることによってオンボーディング（onboarding）を扱う。加えて、ＣＩＯＳは、より多くのものを自動化することができ、このことは、以前の実施形態よりも重い実施である。場合によっては、ＣＩＯＳは、自動的にデプロイし、かつ、コードを試験する能力をチームに提供することによって、デプロイメント前を扱う。いくつかの例では、ＣＩＯＳは、チームが新しいアーチファクトを構築するときに新しいアーチファクトを（例えば、ワールドワイドに）ロールアウトする計画を自動的に生成することを可能にすることによって、変更管理（ＣＭ）ポリシーの書き込みを処理することができる。これは、各領域の現在の状態および（それ自体がアーチファクトであり得る）現在のＣＩＯＳ構成を検査することによって行うことができる。加えて、チームはこれらの計画を調べることができ、ＣＩＯＳ構成を変更すること、および、ＣＩＯＳに再計画を依頼することによって、これらの計画を反復することができる。チームが計画に満足すると、チームは、計画を参照する「リリース」を作成することができる。次いで、当該計画は、承認済みまたは拒否済みとしてマークされ得る。チームは依然としてＣＭを書き込むことができる一方、ＣＭは単にＣＩＯＳ計画へのポインタである。したがって、チームは、計画についての推論に費やす時間を少なくすることができる。計画は、機械によって生成されているので、より正確である。計画は、人の消費にはほとんど細かすぎる。しかしながら、それは、高度なユーザインターフェイス（ＵＩ）を介して表示され得る。

いくつかの例では、ＣＩＯＳは、デプロイメント計画を自動的に実行することによってＣＭの実行を処理することができる。リリース計画が作成され承認されると、エンジニアは、ＣＩＯＳがロールバックを開始しない限り、もはやＣＭに参加しない。場合によっては、このことは、チームが現在手動のタスクを自動化することを要求するかもしれない。いくつかの例では、ＣＩＯＳは、ＣＩＯＳが実行中にサービス健全性の低下を検出すると、フロックをその元の（例えば、リリース前の）状態に戻す計画を自動的に生成することによって、変更管理（ＣＭ）をロールバックすることを処理できる。いくつかの例では、ＣＩＯＳは、ＣＩＯＳによって管理される領域のサブセットおよび／またはリソースのサブセットに詳しく調べられる（scoped）リリース計画を受信し、次いで当該計画を実行することによって、緊急の／戦術的な変更をデプロイすることに対処することができる。

加えて、ＣＩＯＳは、完全に自動化された世界的なデプロイメントを定義するために必要なプリミティブをサポートすることができる。例えば、ＣＩＯＳは、アラームを監視すること、および、統合テストを実行することによって、サービス健全性を測定することができる。ＣＩＯＳは、サービス劣化の場合にチームがロールバック挙動を迅速に定義するのを助けることができ、次いで、それを自動的に実行することができる。ＣＩＯＳは、リリース計画を自動的に生成および表示することができ、承認を追跡することができる。いくつかの例では、チームが所望のデプロイメント挙動を記述するために使用する言語は宣言的であり得る。ＣＩＯＳは、１つのシステムにおけるコードデプロイメントおよびインフラストラクチャ構成（たとえば、プロビジョニング）の機能を組み合わせることができる。ＣＩＯＳはまた、領域にわたって、および領域内の構成要素にわたって、柔軟な順序付けをサポートする。チームは、チェックインされた構成を介して順序付けを表現することができる。チームは、ＣＩＯＳの計画およびリリースＡＰＩをプログラム的に呼び出すことができる。

図１は、少なくともＣＩＯＳ中央１０２を実施するための技術を示すためのアーキテクチャ１００を示す。いくつかの例では、ＣＩＯＳ中央１０２は、「フロック」のレベルでの動作を取り扱うサービスであり得る。ＣＩＯＳ中央１０２は、以下を含むがこれらに限定されないいくつかの責任を有する：
・フロックメタデータ変更およびリリース動作のための認証ゲートウェイとしての役割を果たすこと。

・フロックの、デプロイメントアーチファクトおよびＣＩＯＳリポジトリへのフロックメタデータの信頼できるマッピングを記憶すること。

・フェイズおよびターゲットにわたるグローバルリリースを調整すること。
・「一度に１つのフロックに対して１つより多くの継続中のリリースがない」のようなポリシーを実施するための同期を取ること。

・フロック構成（config）およびアーチファクトに対する変化を検出し、そのような変化に対するリリース生成をトリガすること。

いくつかの例では、ソースコードバージョン制御管理サービス（ＳＣＶＭＳ）１０４は、信頼できるフロック構成を記憶するように構成されることができ、アーチファクト通知サービス（ＡＮＳ）１０６は、ＣＩＯＳ中央１０２が新しいアーチファクト構築を知らされることができるように、ＣＩＯＳ中央１０２によってサブスクライブされ得る。次いで、ＣＩＯＳ中央１０２は、影響を受けたフロックに対して入来する変更をマッピングし、所望であればリリース計画を開始することができる。加えて、いくつかの例では、アーチファクトプッシュサービス（ＡＰＳ）は、ターゲットへのリリースの前にＣＩＯＳ中央１０２によって呼び出されて、成功したリリースに必要とされるアーチファクトがリリースの前に当該ターゲットの領域に存在することを保証することができる。

いくつかの例では、顧客（例えば、エンジニア）１０８は、ＣＩＯＳ中央１０２を呼び出して、フロックおよび／またはリリースをＣＲＵＤし、進行中のＣＩＯＳ活動のステータスを見ることができる。フロック管理サービス１１０は、フロックを操作するための１つまたは複数のＡＰＩを含むことができ、閲覧／計画／承認サービス１１２は、計画を作成および承認するためのＣＲＵＤ ＡＰＩを含むことができ、全てのＣＩＯＳ管理リソースの状態の中央コピーを閲覧するために、変更監視サービス１１４は、ＳＣＶＭＳ１０４を、フロック構成に対する変更について見ることができ、ＡＮＳ１０６から他のアーチファクトに対する変更についての通知を受信でき、そして、状態取り込みサービス１１６は、閲覧／計画／承認１１２がそれらを公開できるように、ＣＩＯＳ中央データベース（ＤＢ）１１８内に地域状態のコピーを作成できる。いくつかの例では、ＣＩＯＳ中央ＤＢ１１８は、フロック、計画、および状態のＤＢであり得る。フロック情報は、信頼できるものであり得る一方、他のすべては、ＣＩＯＳ領域１２０からのデータの古いコピーであり得る。

いくつかの例では、エンジニア１０８は、（例えば、入口プロキシフリート１２２を介して）フロック管理サービス１１０に対するＡＰＩ呼び出しを実行して、フロックのリストを作成することができる。このようなＡＰＩ呼び出しを行うためのプロトコルは、ＨＴＴＰＳ（Hypertext transport protocol secure）等であり得る。この動作のための関連するアクセス制御リスト（ＡＣＬｓ）は、ローカルエリアネットワーク（ＬＡＮ）１２４または他のプライベート接続を含み得る。例えば、ＣＩＯＳは、顧客のオンプレミスデータセンタまたはネットワークをＣＩＯＳ（例えば、専用接続、リース接続、および／またはプライベート接続）と接続するために公衆インターネットを使用することの代替としてのネットワーク接続性を管理／制御することができる。加えて、（例えば、エンジニア１０８の）認証および承認は、ユーザが機械インフラストラクチャ（例えば、予約サービス）を管理することを可能にする予約システムポータルによって実行され得る。いくつかの例では、ＣＩＯＳ中央１０２は、Ｊａｖａデータベース接続性（ＪＤＢＣ）等を使用して、フロックメタデータ、計画、および状態を中央ＤＢ１１８に記憶し得る。いくつかの例では、ＡＮＳ１０６は、新しいアーチファクトが公開されたときに変更監視サービス１１４に通知するように構成され得る。ＡＮＳ１０６はＨＴＴＰＳを使用することができ、認証と承認の両方が相互トランスポート層セキュリティサービスによって処理され得る。加えて、いくつかの例では、変更監視サービス１１４は、フロック構成の変更についてＳＣＶＭＳ１０４をポーリングすることができる。このポーリングは、セキュアシェル（ＳＳＨ）または他のプロトコルを使用して実行され得る。変更監視サービス１１４の認証は、ＣＩＯＳシステムアカウントによって処理され得、承認は、ＳＣＶＭＳ１０４によって処理され得る。

いくつかの例では、エンジニア１０８は、閲覧／計画／承認サービス１１２を使用して、以下の動作のうちの１つまたは複数を行うことができる。エンジニア１０８は、計画を生成および承認するためのＣＩＯＳ中央１０２を呼び出すことによって、計画および／または承認することができる。エンジニア１０８は、進行中のＣＩＯＳ活動の状態を世界中で閲覧するためにＣＩＯＳ中央１０２を呼び出すことによって閲覧することができる。加えて、エンジニア１０８は、ＣＩＯＳ中央１０２を呼び出して、世界中のＣＩＯＳ管理リソースの状態のレプリカを見ることができる。これらのＡＰＩコール（または同様のもの）は、ＨＴＴＰＳプロトコルまたは同様のプロトコルを介して実行され得る。加えて、関連するＡＣＬｓは、ＬＡＮ１２４によって制御され得、認証および認可の両方が予約サービスによって処理され得る。いくつかの例では、閲覧／計画／承認サービス１１２は、計画を要求し、計画の承認を（例えば、ＨＴＴＰＳ等を使用して）ＣＩＯＳ領域１２０の全ての領域にプッシュすることができる。関連するＡＣＬｓは、ワイドエリアネットワーク（ＷＡＮ）ゲートウェイ１２６によって管理されるセキュリティリストを使用して制御され得る。認証は相互トランスポート層セキュリティによって処理されることができ、認可は様々なアイデンティティポリシーによって処理され得る。さらに、状態取り込みサービス１１６は、ジョブステータスまたはステータス変化についてＣＩＯＳ領域１２０を見ることができ、その結果、ＣＩＯＳは、（例えば、ＨＴＴＰＳなども用いて）要求時にそれらの中央ビューを提供することができる。このためのＡＣＬｓはまた、ＷＡＮゲートウェイ１２６によって処理され得、認証および認可の両方が、相互トランスポート層セキュリティサービスによって処理され得る。

図２は、少なくともＣＩＯＳ領域２０２を実施するための技術を示すためのアーキテクチャ２００を示す。いくつかの例では、ＣＩＯＳ領域２０２は、承認されたリリースアプリケーションはもちろん、宣言的プロビジョニングおよび計画の作業の多くが起こり得る場所である。いくつかの事例では、ＣＩＯＳ領域２０２の各インスタンスは、「実行対象」のレベルでの動作を取り扱うことができる領域フロントエンドを有し得る。それは、以下を実行するように構成され得る：
・ＣＩＯＳ中央１０２からの着信動作のための全てのＣＩＯＳ認証を処理すること。

・１つの「実行」（計画／リソースのインポート／計画の適用）のみが所与の実行対象に対して一度に進行中であり得るという規則を実施すること。

・宣言的インフラストラクチャプロビジョニング実行中に入力および出力のために使用される宣言的プロビジョニングアーチファクトのためのバイナリアーチファクトストレージを管理すること。入力の例は、宣言型インフラストラクチャプロビジョニング構成ファイルおよび入力状態ファイルである。典型的な出力は最終状態ファイルである。

・任意の所与の実行についてＣＩＯＳエグゼキュータからの作業を要求し、結果をポーリングすること。

いくつかの例では、ＣＩＯＳフロントエンドは、実際の実行を処理することができる（本明細書では「スケジューラ」とも呼ばれる）ＣＩＯＳエグゼキュータ２０６に依存し得る。当該ＣＩＯＳエグゼキュータは、いくつかの例では、「実行」のレベルで動作し、それは：
・利用可能なワーカーノードのプールを追跡することができる。

・入来するジョブ要求をクエリし、それらを利用可能な適格なワーカーに割り当てることができる。

・クライアントに報告するためにワーカーステータスおよび実行更新を追跡することができる。

・リースプロトコルを介してデッドノードを検出し、タスクステータスに応じて、デッドノードに割り当てられたタスクを失敗することができる。

・実行をキャンセル／キル／ポーズ／再開するためのファシリティを提供し、それらをファシリティにマッピングして、キャンセル／キル／再開の情報をワーカーノードに渡すことができる。

いくつかの例では、ＣＩＯＳエグゼキュータは、ＣＩＯＳワーカー（Workers）に依存することができ、ＣＩＯＳワーカーは、実行のためのタスクをワーカーに割り当てることができ、ワーカーがジョブの進捗を更新するためのファシリティを提供することができる。ワーカーサービスは、「タスク」の粒度で動作する。各ワーカーは、そのワーカーに割り当てられたタスクを実行し、タスクステータスおよび出力を報告するエージェントである。各ワーカーは、
・ 割り当てられた作業項目について、エグゼキュータワーカーＡＰＩをポーリングし、割り当て状態をそのローカル状態と一致させるために、以下のアクションを実行することができる：
・ローカルに存在しないタスク項目をポーリングするためにコンテナを開始すること
・対応する割り当てられたタスク項目を持たないローカルに実行中のコンテナを強制停止すること
・ジョブのステータスを報告することができる。

・ジョブコンテナ実行のための入力および出力を行なうことができる。
・実行対象のリリースの実際の作業を行うために宣言型インフラストラクチャプロビジョニングコンテナを起動および監視することができる。

ＣＩＯＳワーカーは、ＣＩＯＳエグゼキュータからワークをポーリングし、ＣＩＯＳエグゼキュータのワーカーエンドポイントに結果を報告するために、ＣＩＯＳエグゼキュータに依存し得る。当該ワーカーは、全ての調整について当該エグゼキュータに依存し得る。加えて、ＣＩＯＳワーカーは、ＣＩＯＳ領域２０２に依存することもでき、ここで、当該ワーカーサービスは、地域フロントエンドサービスに関連付けられた１つまたは複数のＡＰＩから入力を読み取り、それに出力を書き込む。入力の例は、構成および開始状態ファイルならびにインポートマッピングである。出力の例は、宣言型プロビジョニングプロセス、出力宣言型プロビジョニング状態ファイル、およびインポート結果状態である。

いくつかの例では、ＣＩＯＳ領域２０２は、ＣＩＯＳの地域インスタンス／デプロイメントを管理するための地域サービスであり得る。ＣＩＯＳ領域２０２は、特定の領域に関する計画および状態を信頼できる形で記憶および管理する責任をカバーする。地域ＤＢ２０４は、当該特定の領域における状態および計画のためのＣＩＯＳ ＤＢであり得る。これは、図１の中央ＤＢ１１８の領域の部分集合の信頼できるコピーである。スケジューラ２０６は、ワーカーフリート容量の管理、ワーカーへのタスクの割り当て、およびタスク状態の追跡の責任を負うことができる。いくつかの例では、タスクＤＢ２０８は、タスク状態のための別のＣＩＯＳ ＤＢである。このＤＢ内のデータは、主に動作目的のためのものである。加えて、ワーカー２１０は、宣言的プロビジョニング画像を管理するジャバ仮想マシン（ＪＶＭｓ）のフリートであり得る。これらは、スケジューラ２０６から命令を受信し、スケジューラ２０６およびＣＩＯＳ領域２０２の両方に結果を通信する。ＣＩＯＳコンテナ２１２は、独自のプライベートドッカー２１４コンテナにおいて宣言的プロビジョニングアクションを実行することができる。このコンテナは、秘密を含む必要はない。加えて、いくつかの例では、署名プロキシ２１６は、宣言型プロビジョニング画像内に秘密を置くことを回避するために、宣言型プロビジョニングツールを介して秘密の漏出を防止するように構成され得る。代わりに、ＣＩＯＳは、プロキシにおいて要求署名を実行するか、または相互トランスポート層セキュリティ（ｍＴＬＳ）サービスを開始することができる。これはまた、ＦＩＰＳ準拠暗号ライブラリの使用をより容易にする。

いくつかの例では、ＣＩＯＳ中央１０２は、ＣＩＯＳ領域２０２を呼び出して、計画を作成し、承認をプッシュし、ジョブ状態（サービスプリンシパル）を監視し、宣言型プロビジョナ状態（サービスプリンシパル）を抽出することができる。入口プロキシ２１８は、ＡＣＬとして構成され得、様々なアイデンティティポリシーが、認証と許可の両方のために使用され得る。代替的に、いくつかの例では、入口プロキシ２１８は、入来する要求、計画などの負荷をバランスさせるように構成された負荷バランサと置き換えられ得る。ある例では、ＣＩＯＳ領域２０２は、スケジューラ２０６にそうするように求めることによって宣言型プロビジョナを実行し得る。ワーカー２１０は、スケジューラ２０６に何を実行すべきかを尋ねることができ、完了したときにスケジューラ２０６に状態を報告することができる。ある場合には、ｍＴＬＳは、ＣＩＯＳ領域２０２およびワーカー２１０のための認証と許可の両方を扱うことができる。加えて、ワーカー２１０が宣言型プロビジョナを実行する必要があるとき、ローカルドッカー２１４と相互作用することによってドッカーコンテナ内でそうする。この段階の認証は、ローカルのユニックスソケットによって処理され得る。ドッカープロトコルは、この最後のステップのために使用され得るが、しかしながら、ＨＴＴＰＳは、以前のＨＴＴＰＳのために利用され得る。

いくつかの例では、宣言型プロビジョナが様々なＣＩＯＳサービスを呼び出しているとみなす間、ＣＩＯＳコンテナ２１２は、宣言型プロビジョナが署名プロキシ２１６と（ＡＰＩを介して）対話することを可能にする。署名プロキシ２１６は、宣言型プロビジョナの呼び出しインスタンスごとに、その宣言型プロビジョナにのみ知られる１つのエフェメラルポートをリッスンする。署名プロキシ２１６は、要求署名またはｍＴＬＳを開始することができ、宣言型プロビジョナのコールをサービスエンクレーブ内の他のＣＩＯＳサービスに渡すことができる。いくつかの例では、署名プロキシ２１６はまた、１つまたは複数のパブリックＣＩＯＳサービス２２０と通信することができる。例えば、署名プロキシ２１６は、可能な場合、パブリックサービスの内部エンドポイントを使用する。内部エンドポイントを持たないサービスの場合、外部エンドポイントに到達するために出口プロキシ２２２を使用しなければならない。署名プロキシ２１６のこの使用は、領域間通信のためのものでなくてもよく、例えば、各地域における出口プロキシホワイトリストは、その地域のパブリックＩＰ範囲についてのみであってもよい。いくつかの例では、ワーカー２１０は、次いで、ＣＩＯＳ領域２０２内の宣言型プロビジョナから状態およびログを持続することができ、その結果、それらは、ＣＩＯＳ中央１０２に抽出され得る。

ＣＩＯＳを使用すると、代表的な顧客体験のいくつかの段階がある：オンボーディング、プレリリース、世界的なリリース、および、戦術リリース。プレリリース段階について、以下は、新しいアーチファクトが構築されることと、アーチファクトをリリースして１つ（例えば、Ｒ１）をリリースすることとの間で何が起こるかの例である。これは、現在の変更管理プロセスのいくつかまたは大部分を置き換えるべきである。関連するアーチファクトが構築されると、ＣＩＯＳは、「フロック内の全てのものの最新バージョン」を使用して自動的にリリースを生成することができる。リリースは、特定の入力を有するフロック構成の特定のバージョンである（例えば、アーチファクトバージョン、範囲、領域、および広告）。リリースは、領域ごとの１つのロールフォワード計画と、領域順序付けを記述するメタデータとを含む。各地域計画は、宣言型プロビジョナがその地域におけるフロック構成を実現するために取る動作のセットである。プレリリース環境を有するチームは、ＣＩＯＳを使用して、前記環境においてソフトウェアを自動的にリリースし、テストすることができる。チームは、ロールバック計画を自動的に試験するようにＣＩＯＳを構成することができる。チームは、ＣＩＯＳ ＵＩを通じてリリースを検査し承認することができる。チームは、リリース内の地域計画の全てではないがいくつかを承認することができる。「あらゆるものの最新バージョン」が適切な計画をもたらさなかった場合、チームは、都合の良いアーチファクトバージョンの計画を生成することをＣＩＯＳに求めることができる。

世界的なリリース段階について、以下は、チームが今日の「通常のＣＭ」の今日のバージョンを実行する方法の例である。一旦リリースが承認されると、ＣＩＯＳは、各承認された地域計画をそれぞれの地域にプッシュする。ＣＩＯＳは、承認された計画を適用するために、各領域内で独立して動作する。ＣＩＯＳは、その領域の計画に明示に記載される一組の動作のみを実行する。「独立して考える」代わりに、それは失敗する。ＣＩＯＳ ＵＩは、チームに実行の進行を示す。ＣＩＯＳ ＵＩは、手動承認が必要とされるときにチームを促す。ＣＩＯＳまたは下流サービスにおける停止のために実行が失敗した場合、ＣＩＯＳは、チームに通知することができ、チームに次のステップ（例えば、中止、再試行）を促すことができる。ＣＩＯＳは、再試行を実行するが、いくつかの下流システムの停止は、再試行に対するその意思を超えるであろう。サービスの健全性の低下または試験の失敗のために実行が失敗した場合、ＣＩＯＳは、チームがフロックをその開始状態に戻すのを支援する。ＣＩＯＳは、自動ロールバックを開始するときにチームに通知する（例えば、ページングする）。チームはロールバック計画を承認しなければならず、ＣＩＯＳはそれを実行する。

戦術的リリース段階について、以下は、チームが「緊急ＣＭ」の明日のバージョンをどのように実行できるかの例である。計画を生成するとき、チームは、いくつかの方法で、すなわちトポロジー的に（例えば、領域、地域、ＡＤなど）、リソースタイプによって（例えば、「メトリック構成のみ」または「デプロイメント・オーケストレーション・サービス・デプロイメントのみ」など）、または、上記の組み合わせ（例えば、分離的態様）で、特定のリソースで計画を対象にするようにＣＩＯＳに求めることができる。チームは、世界的なリリースと同様に戦術的リリースを承認する。ＣＩＯＳは、それらを同様に編成する。アクティブな世界的なリリースがある間にチームが戦術的リリースをデプロイする必要がある場合、ＣＩＯＳは、対象とする領域における世界的なリリースの実行を中止し、次いで、戦術的リリースの実行を開始する。

いくつかの例では、宣言型プロビジョナの状態（例えば、伝統的には、ファイル）は、宣言型プロビジョナによって管理される一組のリソースの信頼できるレコードである。これは、構成ファイルからの各リソースの論理識別子と、当該リソースの実際の識別子と、の間のマッピングを含む。宣言的プロビジョナがリソースを作成しているとき、ある種の障害は、実際の識別子がその状態で記録されるのを防ぐことができる。これが起こると、実際の識別子は宣言型プロビジョナに対して失われる。これらを「孤立した（orphaned）リソース」と呼ばれ得る。

ほとんどのリソースについて、孤立（orphan）は、無駄を表し、宣言型プロビジョナは、（例えば）それが忘れたインスタンスを起動したが、それが次に実行されるときに代わりに別のインスタンスを起動する。一意性の制約またはクライアントが提供した識別子を有するリソースの場合、孤立は宣言型プロビジョナが前進することを防止する。例えば、宣言型プロビジョナがユーザ「nglass」を作成し、失敗がそれを放棄する場合、宣言型プロビジョナの次の実行は、「nglass」を作成しようとし、失敗するであろう。なぜなら、そのユーザ名を有するユーザがすでに存在するからである。場合によっては、孤立は、新しいリソースを状態に加えるときにのみ問題となる。いくつかの事例では、宣言的プロビジョナのリフレッシュ挙動は、更新および削除を記録することの失敗から自然に回復し得る。

ＣＩＯＳは、下流のサービス停止またはＣＩＯＳ自体の停止の場合にロバストである必要がある。ＣＩＯＳは、変更を適用するために宣言型プロビジョナを活用することができるので、このことは、宣言型プロビジョナを実行し、宣言型プロビジョナ状態を維持することに関してロバスト性があるはずであることを意味する。宣言型プロビジョニングプロバイダは、数分間続く停止を回避するのに十分な、「小規模」の再試行を実行する。例えば、クラウドプロバイダは、３０分まで再試行する。３０分より長く続く下流システムの停止は、宣言型プロビジョナを失敗させる。宣言型プロビジョナが失敗すると、それは、その状態で成功裡に行われた全ての変更を記録し、次いで終了する。再試行するために、ＣＩＯＳは宣言型プロビジョナを再実行しなければならない。宣言型プロビジョナを再実行することはまた、ＣＩＯＳ自体の障害の場合にＣＩＯＳが再試行することを可能にする。場合によっては、ＣＩＯＳは、ループ内で以下の動作を実行することができる：
・リフレッシュ－宣言型プロビジョナは、ＧＥＴ ＡＰＩをコールして、その状態で記述された全てのリソースの新しいスナップショットを取り出す。

・計画－宣言型プロビジョナは、最近リフレッシュされた現在の状態を前提として、所望の状態を実現する計画（具体的な一組のＡＰＩコール）を生成する。

・適用－宣言的プロビジョナは、計画におけるステップのセットを実行する。
ＣＩＯＳは、宣言型プロビジョナを実行するとき、これらのステップの３つ全てを常に実行することができる。リフレッシュ動作は、記録されなかった更新または削除から回復するのに役立つ。ＣＩＯＳは、計画動作の結果を検査し、それを承認されたリリース計画と比較する。新たに生成された計画が承認されたリリース計画になかった動作を含む場合、ＣＩＯＳは失敗するかもしれず、サービスチームに通知し得る。

図３は、例示的なフロック３０２を例示するための有向非巡回グラフ（ＤＡＧ）３００を示す。ＣＩＯＳにおける単一のフロック構成に対する、チェックインからプロダクションへのコード／構成の進行は、最初のテストデプロイメントから最後のプロダクションデプロイメントまでずっと説明され得る。内部的には、ＣＩＯＳは、進行中の各要素、実行対象（ＥＴ）－これは内部のＡＰＩスペックであり、フロック構成には漏出しない、を参照する。ＣＩＯＳは、フロック構成で定義されたＤＡＧ３００に基づいてＥＴを実行する。各ＥＴ（例えば、ＥＴ-１、ＥＴ-２、ＥＴ-３、ＥＴ-４、ＥＴ-５、ＥＴ-６、およびＥＴ-７）は、おおよそ、当該フロック構成によって記述されるサービスの１つのコピーである。

図４は、例示的なフロック４０２を示すためのＤＡＧ４００を表わす。フロック構成では、ＣＩＯＳは、チームがこの進行をどのように表現するかについて非常に頑固であり（opinionated）、それらは、クラウドインフラストラクチャテナンスおよび地域を使用してそれをモデル化しなければならない。チームは、領域を使用して進行をモデル化すべきではない。ＣＩＯＳは、チームが、領域内の多くのテナンシーおよびテナンシー内の多くの範囲を使用することを可能にする。しかし、ＣＩＯＳは、チームが（それらは、異なるテナンシーにおいて、領域内で同じ範囲を２回使用するかもしれないけれど）テナンシー内で同じ範囲を２回使用することを可能にしない。ＤＡＧ４００は、テナンシーおよび領域とともに表現される、図３からのＤＡＧ３００のバージョンを例示する。この例はオーバーレイサービスに関し、そこでは、事前プロッドＥＴがプロッド領域にある。サービスエンクレーブサービスは、リリース１において不安定かつ安定したテナンシーを有する。ＤＡＧ４００では、ＩＡＤは、ワシントンＤ．Ｃ．におけるダレス空港の地域空港コードであり、ＹＹＺは、オンタリオ州トロントの地域空港コードであり、ＰＨＸ、ＬＨＲ、およびＦＲＡは、それぞれ、フェニックス、ロンドン、およびフランクフルトの地域空港コードであり、ＬＵＦおよびＬＦＩは、２つの異なる空力ベースのものである。

一実施の形態では、本明細書で説明されるＣＩＯＳおよび／または他の技術は、Terraform（宣言型プロビジョニングツール）、Tanden（コード生成ツール）、およびオラクル・デプロイメント・オーケストレーター（Oracle Deployment Orchestrator（ＯＤＯ））のそれぞれに対する改良である。加えて、いくつかの例では、本明細書で説明されるＣＩＯＳおよび／または他の技術は、Terraform、Tanden、およびＯＤＯツールの少なくとも一部分を使用して実装され得る。

インフラストラクチャオーケストレーションサービスを実装するための技術が説明される。いくつかの例では、方法は、実行対象におけるリソースの第１の展開のための、第１のリリース識別子を含み得る構成ファイルを受信できるスケジューラを含み得る。リソースは、当該ファイルに従って実行対象に配備され得る。リソースの現在の状態は記憶されることができる。スケジューラは、実行対象における新しい展開のために、第２のリリース識別子を含み得る、当該ファイルの第２のバージョンを受信できる。少なくとも１つのワーカーノードは、プラグインを実行して、当該第１の識別子を当該第２の識別子と比較することができる。第１の識別子が第２の識別子と異なる場合、プラグインは、第２の識別子に従ってリソースの現在の状態を所望の状態と比較することができる。所望の状態が現在の状態とは異なる場合、リソースは、第２の識別子に従って実行対象に展開される。

他の例では、システムは、少なくとも１つのプロセッサと、当該プロセッサによって実行されると動作を実行するように当該プロセッサを構成するコンピュータが実行可能な命令を記憶できる少なくとも１つのメモリとを含み得る。動作は、スケジューラが、実行対象におけるリソースの第１の展開のための、第１のリリース識別子を含み得る構成ファイルを受信することを含み得る。リソースは、構成ファイルに従って実行対象に配備されることができ、リソースの現在の状態は記憶され得る。スケジューラは、実行対象における新しい展開のために、第２のリリース識別子を含み得る構成ファイルの第２のバージョンを受信することができる。少なくとも１つのワーカーノードは、プラグインを実行して、第１のリリース識別子を第２のリリース識別子と比較することができる。第１のリリース識別子が第２のリリース識別子と異なる場合、プラグインは、第２の構成ファイルに従って、リソースの現在の状態をリソースの所望の状態と比較するために使用され得る。所望の状態が現在の状態とは異なる場合、リソースは、構成ファイルの第２のバージョンに従って実行対象に展開され得る。

さらに他の例では、コンピュータ読み取り可能な記憶媒体は、少なくとも１つのプロセッサによって実行されると、当該プロセッサに動作を実行させることができるコンピュータが実行可能な命令を記憶することができる。動作は、スケジューラが、実行対象におけるリソースの第１の展開のための、第１のリリース識別子を含み得る構成ファイルを受信することを含み得る。リソースは、構成ファイルに従って実行対象に配備されることができ、リソースの現在の状態は、記憶されることができる。スケジューラは、実行対象における新しい展開のために、第２のリリース識別子を含み得る構成ファイルの第２のバージョンを受信できる。少なくとも１つのワーカーノードは、プラグインを実行して、第１のリリース識別子を第２のリリース識別子と比較することができる。第１のリリース識別子が第２のリリース識別子と異なる場合、プラグインは、第２の構成ファイルに従ってリソースの現在の状態をリソースの所望の状態と比較するために使用され得る。所望の状態が現在の状態とは異なる場合、リソースは、構成ファイルの第２のバージョンに従って実行対象に展開され得る。

図５は、少なくとも１つの実施形態による、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実装するためのアーキテクチャの組み合わせブロック図５００を示す。ブロック図５００は、ＣＩＯＳ中心５０２（例えば、図１のＣＩＯＳ中央１０２）およびＣＩＯＳ領域５０４の両方を示す。ＣＩＯＳ中央５０２は、制御プレーン５０６（例えば、図１の制御プレーン１１０）、閲覧／計画／承認サービス５０８（例えば、図１の閲覧／計画／承認サービス１１２）、変更管理サービス５１０（例えば、図１の変更管理サービス１１４）、および状態取り込みサービス５１２（例えば、図１の状態取り込みサービス１１６）を含み得る。

ユーザ５１４（例えば、図１のエンジニア１０８）は、リリースを作成することができ、リリースは、少なくとも１つの展開、少なくとも１つのテスト、両方、または適切な宣言型インフラストラクチャプロビジョニングツール動作の任意の他の組み合わせを含むことができ、ユーザ５１４は、ＬＡＮゲートウェイ５１６（例えば、図１のＬＡＮ１２４）を介してＣＩＯＳ中央５０２にリリースを送信することができる。ＣＩＯＳ中央５０２は、リリースを後処理することができる。制御プレーン５０６は、フロック管理構成要素であり得、ランダムリリースＩＤを生成でき、このランダムに生成されたリリースＩＤをリリースに割り当てることができる。制御プレーン５０６は、後処理において生成された少なくとも１つのコードファイルでリリースを増強することができる。これらのコードファイルの中には、プロバイダと呼ばれる少なくとも１つの宣言型インフラストラクチャプロビジョニングツールのプラグインを含み得るプロバイダファイルと、ローカルファイルとがあり得る。ローカルファイルは、ランダムリリースＩＤを生成するための動作を含むことができ、ローカルファイル内で生成されたランダムリリースＩＤは、プロバイダファイルに注入されることができる。制御プレーン５０６による後処理の結果は、ユーザによって生成された元のコードと、後処理によって生成された拡張コードとを伴うリリース（拡張リリース）であり得る。

閲覧／計画／承認サービス５０８は、ＷＡＮゲートウェイ５１８（例えば、図１のＷＡＮゲートウェイ１２６）を介してＣＩＯＳ領域５０４に拡張リリースを送信することができる。拡張リリースは、ＣＩＯＳ領域５２０（例えば、図２のＣＩＯＳ領域２０２）によって受信されることができ、それは、ステータスレポートを生成し、ＣＩＯＳ領域５０４に入るタスクを追跡するコンピューティングデバイスであり得る。ＣＩＯＳ領域５２０は、タスクを拡張リリースからスケジューラ５２２（例えば、図２のスケジューラ２０６）に送信することができ、それは、タスクをワーカー５２４（例えば、図２のワーカー２１０）に、典型的には最小の作業量を有するワーカーに割り当てることができるコンピューティングデバイスであり得る。いくつかの実施形態では、ＣＩＯＳ領域５２０およびスケジューラ５２２は、同じコンピューティングデバイス上にあり得る。ワーカー５２４は、スケジューラ５２２によって割り当てられたタスクおよびプラグインを実行することができるコンピューティングデバイスであり得、ワーカー５２４は、多くのワーカー５２４を含み得るワーカーフリートの一部であり得る。ワーカー５２４は、ドッカー５２８（例えば、図２のドッカー２１４）内に存在し得るＣＩＯＳコンテナ５２６（例えば、図２のＣＩＯＳコンテナ２１２）と対話することができる。ＣＩＯＳコンテナ５２６は、ワーカー５２４に割り当てられたタスクに関連する実行対象の実際の状態と比較される、当該実行対象の所望の状態の差異をチェックすることができる。ＣＩＯＳコンテナ５２６が差異を識別する場合、ワーカー５２４はタスクを実行でき、ＣＩＯＳコンテナ５２６が差異を識別しない場合、ワーカー５２４はタスクを実行しなくてもよい。タスクを実行することによって、クラウドサービスへのＡＰＩ呼び出しが行なわれることができ、ＡＰＩ呼び出しは署名プロキシ５３２（例えば、図２の署名プロキシ２１６）を通過することができる。署名プロキシ５３２は、汎用ＨＴＴＰプロキシであり得、署名プロキシ５３２は、ＣＩＯＳ領域５０４の発信ネットワークトラフィックを制御することができる。具体的には、署名プロキシ５３２は、図１０および１１でさらに論じられるある状況において、全ての発信ネットワークを遮断することができる。

いくつかの実施形態では、実行対象で実行されることが望まれるリリースは、現在実行対象にあるリソース（実行対象リソース）と同じリソース（リリースリソース）を含み得る。この場合、当該リリースを実行することが望ましいが、既存の宣言型インフラストラクチャプロビジョニングツール動作は、リリースリソースが実行対象リソースと同じであるため、リリースリソースを実行しないことがある。しかしながら、本明細書で説明される技術は、diff（例えば、構成ファイルの違いを識別する比較関数）を強制することによって、実行対象においてリリースリソースを実行するために使用され得る。したがって、本明細書で説明される技術によって実現される１つの技術的改善は、宣言型インフラストラクチャプロビジョニングツールにリリースを処理させ、宣言型インフラストラクチャプロビジョニングツールが、リリースに結び付けられるリソースの自動再展開を処理するように設計されていないにもかかわらず、すでに存在するおよび／またはすでに展開されたリソースを本質的に再展開させる能力である。

差異を強制することは、現在の状態と所望の状態との間に差異が存在することを宣言型インフラストラクチャプロビジョニングツールに指示することを含み得る。いくつかの実施形態では、差異を強制することは、ランダムリリースＩＤを生成することによって、少なくとも部分的に達成されることができる。ユーザ５１４は、実行対象のリソースがリリースリソースと同一であったとしても、実行対象のリソースの現在の状態にかかわらず、実行対象でリリースのリソースを実行させたい場合がある。この場合、ユーザ５１４は、制御プレーン５０６による後処理においてランダムリリースＩＤを生成するためのオプションを選択し得る。しかしながら、いくつかの事例では、制御プレーン５０６は、常にランダムリリースＩＤを生成し得る。次いで、ユーザ５１４は、より多くの（例えば、デフォルトの「差異を強制するためのリリースＩＤを使用する」挙動を無効にする）構成を書き込むことによって、それを使用するかどうかを選択することができる。いくつかの実施形態では、一旦生成されると、ランダムリリースＩＤは、リリースに恒久的に結び付けられることができる。リリースは、ＣＩＯＳ領域５０４に伝送されることができ、リリースのタスクは、スケジューラ５２２によってワーカー５２４に割り当てられることができる。ワーカー５２４は、宣言型インフラストラクチャプロビジョニングツール動作を実行することができるＣＩＯＳコンテナ５２６と通信することができる。ＣＩＯＳコンテナ５２６は、リソースの所望の状態と比較されるリソースの現在の状態の差異をチェックすることができる。このチェック内で、ＣＩＯＳコンテナ５２６は、リリースがランダムに生成されたリリースＩＤを含むかどうかを判定することができ、これは当該差異を強制すると考えられる。ランダムに生成されたリリースＩＤがユニークであり、ＣＩＯＳコンテナ５２６によって検出される場合、ＣＩＯＳコンテナ５２６は、たとえ、展開されるべきリソースが既に展開されたリソースと同じであったとしても、現在の状態と所望の状態との間に差異が存在すると判定し得る。この差異を識別することに応答して、新しいリリースのリソースは、展開されることができる。

図６は、少なくとも１つの実施形態による、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実装するためのＣＩＯＳ領域６０２（例えば、図５のＣＩＯＳ領域５０４）アーキテクチャのブロック図６００を示す。図５の部分と同様に、ＣＩＯＳ領域６０２は、ＣＩＯＳ領域６０４（例えば、図５のＣＩＯＳ領域５２０）およびスケジューラ６０６（例えば、図５のスケジューラ５２２）を含むことができ、両方ともコンピューティングデバイスであり得る。いくつかの実施形態では、ＣＩＯＳ領域６０４およびスケジューラ６０６は、同じコンピューティングデバイス上にあり得る。スケジューラ６０６は、割り当てられたタスクの追跡を助けることができるタスクＤＢ６０８と、タスクを実行するコンピューティングデバイスであり得るワーカー６１０とに通信可能に結合され得る。ワーカー６１０は、多くのワーカー６１０を含み得るワーカーフリートの一部であり得る。ワーカー６１０は、ドッカー６１４（例えば、図５のドッカー５３０）内で宣言型インフラストラクチャプロビジョニングツール動作を実行することができるコンピューティングデバイスであり得るＣＩＯＳコンテナ６１２（例えば、図５のＣＩＯＳコンテナ５２８）に通信可能に結合され得る。ワーカー６１０は、ＣＩＯＳコンテナ６１２と通信し、かつ、ＣＩＯＳコンテナ６１２にリリースを送信することができ、ＣＩＯＳコンテナ６１２は、現在の状態と所望の状態との間に差異が存在するかどうかを判定することができる。差異が存在する場合、ワーカー６１０は、割り当てられたタスクを実行することができ、割り当てられたタスクを実行することに従って、ワーカー６１０は、署名プロキシ６１６（例えば、図５の署名プロキシ５３２）を通過し得る発信ＡＰＩコールを実行することができる。署名プロキシ６１６は、図１０および図１１でさらに論じられるいくつかの状況において、発信ＡＰＩコールを可能にするか、または全ての発信ネットワークトラフィックを遮断し得る。タスクＤＢ６０８は、スケジューラ６０６のデータベースとして示されているが、それはまた（または代替として）、ＣＩＯＳ領域６０４の全てのためのデータベースとして構成され得る。このデータベース６０８は、領域内で起こる変更活動についての権限であり得る。「権限」が意味するものの例は以下の通りである：ＣＩＯＳ中央（例えば、図５の５０２）は、ＣＩＯＳ領域６０２内の特定の実行対象に起きているものについて古くなっている可能性があり、それは、ＣＩＯＳ領域６０４に対して、そうすることが安全でないときに変更を行うように、ＣＩＯＳ領域６０２に要求させることができる。この例では、ＣＩＯＳ領域のデータベース６００８は、そうすることが安全であるかどうか（例えば、その実行対象に対して既に起こっている変更アクティビティがある／ない）を決定することができるものである。この例では、ＣＩＯＳ領域６０４は、データベース６０８をチェックし、ＨＴＴＰ４０９（例えば、コンフリクト）をＣＩＯＳ中央５０２に返すであろう。

いくつかの実施形態では、ユーザ（例えば、図５のユーザ５１４）は、適切なリソースの配備、試験、または任意の他の好適な実行を再試行することを所望し得る。リソースの実行を再試行する理由のいくつかの非限定的な例は、前の実行のランダムな失敗、前の実行のコードのバグなどであり得る。ユニークなリリースＩＤがリリースに結び付けられているかどうかを判定することに加えて、ＣＩＯＳコンテナ６１２は、実行ＩＤおよび当該適切なリソースのステータスをチェックすることができる。リソースの実行が試みられるたびに、スケジューラ６１０は、リソースの実行に結び付けられることができる固有の実行ＩＤを生成することができる。ユーザがリリースのためのリトライコマンドを送信する非限定的な例では、スケジューラ６１０は、実行ＩＤを生成することができ、リトライコマンドに関連するタスクをワーカー６１２に割り当てることができる。ワーカー６１２は、リリースＩＤ、実行ＩＤ、およびリソースステータスをＣＩＯＳコンテナ６１２に送信することができる。リリースＩＤが現在の状態と異なる場合、ＣＩＯＳコンテナ６１２は、当該差異を識別することができ、ワーカー６１０は、タスクを実行することができる。所望の状態のリリースＩＤが現在の状態のリリースＩＤと同じである場合、ＣＩＯＳコンテナ６１２は、実行ＩＤおよびリリース状態をチェックすることができる。ＣＩＯＳコンテナ６１２が、現在の実行の実行ＩＤは前の実行の実行ＩＤと異なると判定した場合、および前の実行のリリースステータスが「失敗」または任意の適切な同様のステータスであるとＣＩＯＳコンテナ６１２が決定した場合、ワーカー６１０は、リソースのタスクを再び実行しようと試みることができる。ＣＩＯＳコンテナ６１２が、実行ＩＤは以前の実行と同じである、またはリリースステータスが失敗していないと判定した場合、ワーカー６１０は、タスクを実行しなくてもよい。

図７は、少なくとも１つの実施形態による、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実装するためのコードのスニペット７００を示す。スニペット７００は、実行対象においてデプロイメントを実行することができるリソースを定義するためのコードを示す。スニペット７００は、リソースタイプ７０２、リソース名７０４、リリースＩＤ７０６、およびリソース状態７０８を含み得る。リソースタイプ７０２は、デプロイメント、テスト、または関連するリソースのための任意の他の適切なリソースタイプを含み得る。スニペット７００に示されるリソース名７０４は「executor adl」であるが、リソース名７０４は、当該関連するリソースを記述するのに適した任意の名前とされ得る。スニペット７００に示されるリリースＩＤ７０６は、「7e29d6aa-7dc6-4268-9f90-e57caf76e714」であるが、リリースＩＤ７０６は、ユニークなリリースを識別するための任意のランダムに生成された文字列であり得る。スニペット７００に示されるリソース状態７０８は「成功」であるが、リソース状態７０８は、関連するリソースを記述するための任意の適切な状態（例えば、「成功」、「失敗」、「承認」、「承認が必要」など）であり得る。

いくつかの実施形態では、スニペット７００は、特定のリソースのアドレスまたは識別子として機能することができる。ワーカーノード（例えば、図６のワーカー６１０）は、リソースを実行するためのタスクを受信することができる。ワーカーノードは、リソースをＣＩＯＳコンテナ（例えば、図６のＣＩＯＳコンテナ６１２）に送信することができ、ＣＩＯＳコンテナは、スニペット７００を少なくとも部分的に使用してリソースが固有であるかどうかを判定することができる。ＣＩＯＳコンテナは、当該リソース（所望状態）からのリソースタイプ７０２、リソース名７０４、リリースＩＤ７０６を、現在実行対象のリソース（現在状態）と比較できる。所望の状態と現在の状態との間に差異が存在する場合、ＣＩＯＳコンテナは、差異が存在することを識別することができ、ワーカーノードは、実行対象のリソースを実行することができる。

いくつかの実施形態では、スニペット７００は、実行ＩＤと呼ばれる固有の実行試行を識別するためのコードの別の行を含み得る。実行ＩＤは、スケジューラノード（例えば、図６のスケジューラ６０６）によってランダムに生成され得る文字列であり得る。スケジューラノードは、リソースの実行試行ごとにランダム実行ＩＤを生成し、実行ＩＤを有するリソースをワーカーノードに送信することができる。ワーカーノードは、実行ＩＤを有するリソースをＣＩＯＳコンテナに送信することができ、これは、現在の状態と、実行ＩＤを有するリソース（所望の状態）との間に差異が存在するかどうかを判定することができる。所望の状態の実行ＩＤが現在の状態と異なり、現在の状態のリソース状態７０８が「失敗」である場合、ＣＩＯＳコンテナは、現在の状態と所望の状態との間に差異が存在すると判定することができる。差異を識別するＣＩＯＳコンテナに従って、ワーカーノードは、実行対象のリソースを実行することができる。この動作は、先に論じられたリトライ動作と同様であり得る。

図８は、少なくとも１つの実施形態による、クラウドインフラストラクチャオーケストレーションサービスの少なくともいくつかの要素を実装するためのコードのスニペット８００および８０２を示す。スニペット８００および８０２は、ユーザ（例えば、図５のユーザ５１４）によって作成されたリリースの後処理中にフロック管理コンポーネント（例えば、図５の制御プレーン５０６）によって生成され得るコードを示す。スニペット８００は、宣言型インフラストラクチャプロビジョニングツールプラグインであり得るプロバイダを含み得るプロバイダファイルの一例を示す。プロバイダファイルは、リリースＩＤコールアウト８０４および実行ＩＤコールアウト８０６を含み得る。プロバイダファイルはまた、関連するリリースのための任意の他の適切なプロバイダまたはプラグインを含み得る。リリースＩＤコールアウト８０４は、リソースにリリースＩＤ（例えば、図７のリリースＩＤ７０６）を注入する動作であり得、スニペット８００に示されるように、リリースＩＤコールアウト８０４は、「local.release.id」であるが、リソースにリリースＩＤを注入するための任意の適切なコールアウトであり得る。実行ＩＤコールアウト８０６は、実行ＩＤをリソースに注入する動作であり得、スニペット８００に示されるように、実行ＩＤコールアウト８０６は、「local.execution.id」であるが、実行ＩＤをリソースに注入するための任意の適切なコールアウトであり得る。

スニペット８０２は、リソースの後処理においてフロック管理コンポーネントによって生成され得るローカルファイルの一例を示す。ローカルファイルは、リリースＩＤ８０８と、実行対象情報８１０とを含み得る。スニペット８０２に示されるように、リリースＩＤ８０８は「39ed7b9c-5519-4069-896d-8el7ed4fc29e」であるが、リリースＩＤ８０８は、リリースを一意に識別するために適した任意の文字列であり得る。実行対象情報８１０は、リリースが実行されようとしている実行対象に関する様々な情報を含み得る。スニペット８０２に示されるように、実行対象情報８１０は、実行対象名８１２を含むが、当該実行対象情報は、実行対象に関連する任意の適切な情報であり得る。スニペット８０２に示されるように、実行対象名８１２は「ap-melbourne-1」であるが、実行対象名８１２は、リソースが配備されようとする実行対象の任意の適切な名前であり得る。

スニペット８０２のローカルファイルは、リリースＩＤ８０８と実行ＩＤとの両方を含み得る。ＣＩＯＳ中央（例えば、図１のＣＩＯＳ中央１０２）で起こり得るリリースの後処理の間、フロック管理コンポーネントは、ローカルファイルに含まれ得るリリースＩＤ８０８を生成することができる。実行ＩＤは、当該実行ＩＤでローカルファイルを更新することができるスケジューラノードによって生成され得る。スニペット８００のプロバイダファイルには、リリースＩＤコールアウト８０４および実行ＩＤコールアウト８０６を利用することによって、リリースＩＤ８０８および実行ＩＤの両方が入れられ得る。

図９は、本開示のいくつかの実施形態による、ＣＩＯＳの技術を実装するためのプロセス９００を示す例示的なフロー図を示す。このプロセスは、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはそれらの組み合わせで実施され得る。コンピュータ命令の文脈では、動作は、１つまたは複数のプロセッサによって実行されると、列挙された動作を実行する、１つまたは複数のコンピュータ読み取り可能な記憶媒体に記憶されたコンピュータが実行可能な命令を表し得る。概して、コンピュータが実行可能な命令は、特定の機能を実行するかまたは特定のデータタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が説明される順序は、限定として解釈されることを意図しておらず、任意の数の説明される動作が、プロセスを実装するために、任意の順序で、および／または並列に組み合わせられることができる。

加えて、プロセス９００は、実行可能命令で構成された１つ以上のコンピューティングデバイスまたはコンピュータシステムの制御下で実行されてもよく、１つ以上のプロセッサ上で集合的に実行するコード（例えば、実行可能命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として、ハードウェアによって、またはそれらの組み合わせによって実装され得る。上述のように、コードは、たとえば、１つまたは複数のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読み取り可能な記憶媒体に記憶され得る。いくつかの実施形態では、プロセス９００は、複数のプロセッサによって並列に実行され得る。コンピュータ読み取り可能な記憶媒体は、非一時的であり得る。

図９は、少なくとも１つの実施形態による、実行対象にリソースを展開するためのＣＩＯＳの技術を実装するためのプロセス９００を示す例示的なフロー図を示す。プロセス９００は、ブロック９０２で開始することができ、スケジューラノード（例えば、図２のスケジューラ２０６）は、実行対象におけるリソースの第１の展開のために、以下で第１のリリースＩＤと呼ばれる第１のリリース識別子（例えば、図８のリリースＩＤ８０８）を含み得る構成ファイルを受信する。スケジューラノードは、多くのワーカーノードを含むワーカーフリートの一部であり得るワーカーノード（例えば、図２のワーカー２１０）に当該構成ファイルを送信することができる。

ブロック９０４において、構成ファイルに従ったリソースの第１の展開が、実行対象において実行され、いくつかの実施形態では、ワーカーノードによって実行される。いくつかの例では、実行対象は、空であるか、そうでなければそれに配備されたいかなるリソースも伴わない可能性がある。ワーカーノードは、現在実行対象（現在の状態）にあるリソースと構成ファイル（所望の状態）内のリソースとの間に差異が存在するか否かを判定するために、構成ファイルをＣＩＯＳコンテナ（例えば、図２のＣＩＯＳコンテナ２１２）に送信することができる。ブロック９０４において、実行対象はいかなるリソースもないことがあり得るので、当該差異は存在し得、ワーカーノードは、実行対象においてリソースの第１の展開を実行することができる。

ブロック９０６において、実行対象におけるリソースの現在の状態が記憶される。いくつかの例では、実行対象におけるリソースの第１の展開がワーカーノードによって実行されると、実行対象におけるリソースの現在の状態が記憶され得る。現在の状態は、実行対象において後続のリリースを展開するか否かを決定するために、後続の比較において少なくとも部分的に利用され得る。

ブロック９０８において、スケジューラノードは、実行対象におけるリソースの第２の展開のための、以下では第２のリリースＩＤと呼ばれる第２のリリース識別子を含み得る第２の構成ファイルを受信する。スケジューラノードは、実行対象においてリソースの第２の展開を実行するタスクとともに、第２の構成ファイルをワーカーノードに送信することができる。

ブロック９１０において、ワーカーノードは、プラグインを実行して、第１のリリースＩＤを第２のリリースＩＤと比較する。ワーカーノードは、第２の構成ファイルをＣＩＯＳコンテナに送信することができる。いくつかの例では、ＣＩＯＳコンテナは、第１のリリースＩＤを第２のリリースＩＤと比較することによって、プロセス９００のブロック９０６に記憶された現在の状態と、第２の構成ファイルに定義された所望の状態との間に差が存在するかどうかを判定することができる。

ブロック９１２において、ＣＩＯＳコンテナが、差異は第１のリリースＩＤと第２のリリースＩＤとの間に存在しないと判定したことに従って、ワーカーノードはアクションを取らず、第２の展開は発生し得ない。ブロック９１４において、ＣＩＯＳコンテナが、差異は第１のリリースＩＤと第２のリリースＩＤとの間に存在すると判定したことに従って、ＣＩＯＳコンテナは、実行対象におけるリソースの現在の状態を、第２の構成ファイルにおいて定義されたリソースの所望の状態と比較することができる。いくつかの例では、ブロック９１０においてＣＩＯＳコンテナが差は第１のリリースＩＤと第２のリリースＩＤとの間に存在すると判定したことに従って、ＣＩＯＳコンテナは、ブロック９１６に直接スキップすることができる。

ブロック９１６において、ＣＩＯＳコンテナが、リソースの現在の状態は、第２の構成ファイルによって定義されるリソースの所望の状態とは異なると判定することに従って、リソースは、第２の構成ファイルに従って実行対象に展開され得る。ワーカーノードは、実行対象においてリソースの第２の展開を実行することによって、スケジューラノードによってそれに割り当てられたタスクを完了することができる。いくつかの例では、ＣＩＯＳコンテナは、第１のリリースＩＤおよび第２のリリースＩＤが同じであると判定するかもしれず、これは、ユーザが展開を再試行することを望むことを示し得る。この場合、ＣＩＯＳコンテナは、第１の構成ファイルの第１の実行ＩＤと第２の構成ファイルの第２の実行ＩＤとを比較し得る。ＣＩＯＳコンテナが第１の実行ＩＤと第２の実行ＩＤは異なると判断したことに応じて、ＣＩＯＳコンテナは、第１の構成ファイルのリリース状態を確認することができる。第１の構成ファイルのリリースステータスが「失敗」であるか、またはリソースの第１の展開が成功していない可能性があることを示す任意の他の同様のステータスである場合、ワーカーノードは、第２の構成ファイルによって定義されたリソースの第２の展開を実行することができる。

図１０は、少なくとも１つの実施形態による、宣言型インフラストラクチャプロビジョニングツールの同時実行を防止するための技術を例示するための簡略化されたアーキテクチャ１０００を示す。簡略化されたアーキテクチャ１０００は、ＣＩＯＳ領域１００２（例えば、図２のＣＩＯＳ領域２０２と同様である）、スケジューラ１００４（例えば、図２のスケジューラ２０６と同様である）、ワーカー１００６（例えば、図２のワーカー２１０と同様である）、ＣＩＯＳコンテナ１００８（例えば、図２のＣＩＯＳコンテナ２１２と同様である）、ドッカー１０１０（例えば、図２のドッカー２１４と同様である）、および署名プロキシ１０１２（例えば、図２の署名プロキシ２１６と同様である）を含み得る。スケジューラ１００４は、ワーカーフリートのワーカー１００６の容量の管理、ワーカー１００６へのタスクの割り当て、および、タスク状態の追跡の責任を負うことができる。ワーカーフリートは、宣言的プロビジョニング画像を管理するＪＶＭのフリートであり得る。ワーカーフリートは、スケジューラ１００４から命令を受信し、スケジューラ１００４とＣＩＯＳ領域１００２との両方に結果を通信する。ＣＩＯＳコンテナ１００８は、独自のプライベートドッカー１０１０コンテナにおいて宣言的プロビジョニングアクションを実行することができる。

署名プロキシ１０１２は、ＣＩＯＳ領域１００２のネットワーク接続性を制御することができ、これは、ＡＰＩコールがクラウドサービス１０１４に対して行われるか否かを指示することができる。署名プロキシ１０１２は、スケジューラ１００４とワーカーフリートからの各ワーカー１００６との間のリース１０１６をテストすることができる。例示的な実施形態では、リース１０１６はハートビート通知であり、各ワーカー１００６は、スケジューラ１００４に、それが実行中であり、それが割り当てられたタスクで動いているという通知を絶えず送信することができる。ハートビート通知の頻度は、ワーカーフリート内の全てのワーカー１００６の間で同じであり得るか、スケジューラ１００４によって選択され得るか、またはシステムのユーザ／開発者によって構成され得る。いくつかの例では、頻度は、２秒、３秒、４秒、５秒、又はワーカー１００６の進捗を監視するための任意の他の好適な時間量であり得る。リース１０１６が有効である、すなわちスケジューラ１００４がワーカー１００６からハートビート通知を受信することを意味する場合、署名プロキシ１０１２はクラウドサービス１０１４へのコール１０１８を実行し得る。リース１０１６が無効である、すなわちスケジューラ１００４がハートビート通知を受信しないことを意味する場合、署名プロキシ１０１２は、クラウドサービスへのコール１０１８を実行しなくてもよく、代わりに、署名プロキシ１０１２は、ワーカーフリートに割り当てられたタスクの同時実行を防止するために、全ての発信ネットワークトラフィックを遮断し、ＡＰＩコールを生じなくてもよい。署名プロキシ１０１２が全ての発信ネットワークトラフィックを遮断する例示的な場合において、ワーカー１００６、ＣＩＯＳコンテナ１００８、または任意の他の適切なコンポーネントは、宣言型プロビジョナを実行し続けることができるが、クラウドサービス１０１４へのＡＰＩコールの欠如に起因して進捗が起こらない場合がある。

例示的な実施形態では、ワーカーフリート内の各ワーカー１００６は、スケジューラ１００４によって最大１つの一意のタスクが与えられ、各ワーカーは、ハートビート通知をスケジューラ１００４に送信し、リース１０１６が有効であることをスケジューラ１００４に知らせる。ハートビート通知の送信に成功したワーカー１００６は健康なワーカーと見なされることができ、ハートビート通知の送信に成功しないワーカー１００６は不健康なワーカーと見なされ得る。ワーカー１００６がハートビート通知を送信しない理由は、ワーカーのホストが失敗したこと、ワーカーの処理が失敗したこと、ワーカー１００６とスケジューラ１００４との関係が失敗したこと（例えば、ロードバランサ、ネットワーク接続性など。）、またはハートビート通知を送信しないことについての任意の他の適切な理由を含む。ワーカーフリート内の不健康なワーカーの場合、タスクの同時実行のリスクがあり得る。当該タスクが同時に実行される場合、インフラストラクチャに対する破壊のリスクがあり得る。このリスクは、署名プロキシ１０１２が全ての発信ネットワークトラフィックを遮断し、いかなるＡＰＩコールも防止するとき、ハートビート通知を受信せず、不健康なワーカーを識別するとき、軽減または排除され得る。

図１１は、本開示のある実施形態による、ＣＩＯＳの技術を実装するためのプロセス１１００を示す例示的なフロー図を示す。このプロセスは、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはそれらの組み合わせで実装され得る。コンピュータ命令の文脈では、動作は、１つまたは複数のプロセッサによって実行されると、列挙された動作を実行する、１つまたは複数のコンピュータ読み取り可能な記憶媒体に記憶されたコンピュータが実行可能な命令を表し得る。概して、コンピュータが実行可能な命令は、特定の機能を実行するかまたは特定のデータタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が説明される順序は、限定として解釈されることを意図しておらず、任意の数の説明される動作が、プロセスを実装するために、任意の順序で、および／または並列に組み合わせられ得る。

加えて、プロセス１１００は、実行可能な命令で構成された１つ以上のコンピューティングデバイスまたはコンピュータシステムの制御下で実行されてもよく、１つ以上のプロセッサ上で集合的に実行するコード（例えば、実行可能な命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として、ハードウェアによって、またはそれらの組み合わせによって実装され得る。上述のように、コードは、たとえば、１つまたは複数のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読み取り可能な記憶媒体に記憶され得る。いくつかの実施形態では、プロセス１１００は、複数のプロセッサによって並列に実行され得る。コンピュータ読み取り可能な記憶媒体は、非一時的であり得る。

図１１は、少なくとも１つの実施形態による、宣言型インフラストラクチャプロビジョナーの同時実行を防止するためのＣＩＯＳの技術を実装するためのプロセス１１００を示す例示的フロー図を表わす。プロセス１１００は、ブロック１１０２で開始され得、ワーカーノード（例えば、図１０のワーカー１００６）は、インフラストラクチャリソースを展開するためのタスクを受信する。当該タスクは、スケジューラノード（例えば、図１０のスケジューラ１００４）によってワーカーノードに与えられることができ、当該ワーカーノードは、任意の所与の時間に１つの固有タスクのみが与えられ得る。しかしながら、いくつかの例では、ワーカーノードは、同時に多くのタスクをハングすることができる。

ブロック１１０４において、ワーカーノードは、ハートビート通知をスケジューラノードに提供する。ハートビート通知は、ワーカーノードが動作中であり、かつ、スケジューラノードによってワーカーノードに与えられたタスクをワーカーノードが実行中であるという通知であり得る。ワーカーノードからスケジューラノードへのハートビート通知の伝達は、リース（例えば、図１０のリース１０１６）と呼ばれることができる。

ブロック１１０６において、署名プロキシ（例えば、図１０の署名プロキシ１０１２）は、ワーカーノードがスケジューラノードに送信するハートビート通知を追跡する。ワーカーフリート内の各ワーカーノードは、ハートビート通知をスケジューラノードに送信することができ、署名プロキシは、不健康であり得る任意のワーカーノードを識別しようとして、これらのハートビート通知の各々を追跡することができる。

ブロック１１０８において、署名プロキシは、ワーカーノードに割り当てられたタスクの実行に対応する要求をワーカーノードから受信する。当該要求は、クラウドサービス（例えば、図１０のクラウドサービス１００２）へのＡＰＩ呼び出しを行うことを含み得る。

ブロック１１１０において、署名プロキシは、例えばブロック１１０８において要求を行ったワーカーノードのリースが有効であるか否かを判定する。署名プロキシは、ワーカーノードからのハートビート通知がスケジューラノードに正しく送信されたか否かを判定することができる。ハートビート通知がワーカーノードからスケジューラノードに適切に送信されなかった場合、署名プロキシは、ワーカーノードが不健康であると見なし得る。

ブロック１１１２において、署名プロキシがリースは有効であると判定したことに従って、署名プロキシは、ワーカーノードに代わってクラウドサービスへの呼び出しを行う。ワーカーノードがハートビート通知をスケジューラノードに成功裡に送信する場合、署名プロキシは、ワーカーノードが健康であると判定し得る。署名プロキシは、健康なワーカーノードに代わってクラウドサービスへのＡＰＩコールを実行し得る。

ブロック１１１４において、署名プロキシがリースは無効であると決定したことに従って、署名プロキシは、クラウドサービスへの呼び出しを行わず、代わりに、クラウドサービスへの、ワーカーノードのアクセスをブロックする。ワーカーノードがハートビート通知をスケジューラノードに首尾よく送信しない場合、署名プロキシは、ワーカーノードが不健康であると判定し得る。不健康なワーカーノードは、異なる健康なワーカーノードによって既に実行されているタスクを実行することができる。このようにタスクを同時に実行すると、インフラストラクチャを破壊するリスクを冒しうる。このリスクを軽減または排除するために、署名プロキシは、全ての発信ネットワークトラフィックを遮断し、ワーカーノードがクラウドサービスにアクセスすることを防止することができ、そしてそれは、ワーカーノードに割り当てられたタスクの同時実行を防止することができる。

図１２および図１３は、様々な実施の形態に従う、本開示の態様を実施するための例示的な環境の態様を示す。図１２は、本開示の実施の形態を実装するための分散システム１２００の簡略図を示す。図示された実施の形態では、分散システム１２００は、１つまたは複数のクライアントコンピューティング装置１２０２，１２０４，１２０６および１２０８を含み、これらは、１つまたは複数のネットワーク１２１０を介して、ウェブブラウザ、プロプライエタリクライアント（たとえば、オラクル・フォームズ（Oracle Forms））のようなクライアントアプリケーションを実行し動作させるように構成されている。サーバ１２１２は、ネットワーク１２１０を介して、クライアントコンピューティング装置１２０２，１２０４，１２０６および１２０８と通信可能に結合され得る。

様々な実施の形態では、サーバ１２１２は、識別管理サービスを提供するサービスおよびアプリケーションのような１つまたは複数のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。ある実施の形態では、サーバ１２１２はまた、他のサービスを提供することができ、または、ソフトウェアアプリケーションは、非仮想のおよび仮想の環境を含み得る。ある実施の形態では、これらのサービスは、クライアントコンピューティング装置１２０２，１２０４，１２０６および／または１２０８のユーザに、ウェブベースの若しくはクラウドのサービスとして、または、サービスとしてのソフトウェア（ＳａａＳ）モデルの下で提供され得る。クライアントコンピューティング装置１２０２，１２０４，１２０６および／または１２０８を操作するユーザは、次いで、サーバ１２１２と相互作用するための１つまたは複数のクライアントアプリケーションを利用して、これらの構成要素によって提供されるサービスを利用し得る。

図１２に示される構成では、システム１２００のソフトウェアコンポーネント１２１８，１２２０および１２２２は、サーバ１２１２上に実装されているものとして示されている。他の実施の形態では、システム１２００の構成要素および／またはこれらの構成要素によって提供されるサービスのうちの１つまたは複数はまた、クライアントコンピューティング装置１２０２，１２０４，１２０６および／または１２０８のうちの１つまたは複数によって実装され得る。クライアントコンピューティング装置を操作するユーザは、その後、これらの構成要素によって提供されるサービスを使用するために、１つまたは複数のクライアントアプリケーションを利用することができる。これらの構成要素は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実装され得る。分散システム１２００とは異なり得る様々な別個のシステム構成が可能であることが理解されるべきである。図１２に示される実施の形態は、したがって、実施の形態のシステムを実装するための分散システムの一例であり、限定することを意図しない。

クライアントコンピューティング装置１２０２，１２０４，１２０６および／または１２０８は、様々なタイプのコンピューティングシステムを含み得る。たとえば、クライアントコンピューティング装置は、マイクロソフト Windows Mobile（登録商標）のようなソフトウェアを実行するポータブルハンドヘルド装置（例えば、iPhone（登録商標）、携帯電話、iPad（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブル装置（例えば、グーグルグラス（登録商標）ヘッドマウントディスプレイ）、および／またはｉＯＳ、Windows Phone（登録商標）、Android（登録商標）、BlackBerry １０、Palm ＯＳなどの様々なモバイルオペレーティングシステムを含み得る。当該装置は、様々なインターネット関連アプリ、電子メール、ショートメッセージサービス（ＳＭＳ）アプリケーションのような様々なアプリケーションをサポートすることができ、様々な他の通信プロトコルを使用し得る。クライアントコンピューティング装置はまた、例として、マイクソフト ウインドウズ（登録商標）、アップルマッキントッシュ（登録商標）、および／またはＬｉｎｕｘオペレーティングシステムの様々なバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む、汎用のパーソナルコンピュータを含み得る。クライアントコンピューティング装置は、限定はしないが、たとえばグーグル・クロームＯＳのような様々なＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含む、様々な市販のＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステムのいずれかを実行するワークステーションコンピュータであり得る。クライアントコンピューティング装置はまた、ネットワーク１２１０を介して通信することができる、シンクライアントコンピュータ、インターネット対応ゲームシステム（例えば、Ｋｉｎｅｃｔ（登録商標）ジェスチャー入力装置を有する又は有さないマイクロソフトＸｂｏｘゲームコンソールである）、および／または、パーソナルメッセージング装置等の電子装置を含み得る。

図１２の分散システム１２００は、４つのクライアントコンピューティング装置とともに示されているが、任意の数のクライアントコンピューティング装置がサポートされ得る。センサを有する装置のような他の装置は、サーバ１２１２と対話することができる。

分散システム１２００におけるネットワーク１２１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、ＡｐｐｌｅＴａｌｋなどを含むがこれらに限定されない、様々な利用可能なプロトコルのいずれかを使用してデータ通信をサポートすることができる、当業者によく知られている任意のタイプのネットワークであり得る。単なる例として、ネットワーク１２１０は、ローカルエリアネットワーク（ＬＡＮ）、イーサネット（登録商標）に基づくネットワーク、トークンリング、広域ネットワーク、インターネット、仮想ネットワーク、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（例えば、ＩＥＥＥ（Institute of Electrical and Electronics）１００２.１６プロトコルスイート、Bluetooth（登録商標）、および／または、任意の他の無線プロトコル）のいずれかの下で動作するネットワーク）、および／又は、これらのおよび／又は他のネットワークの任意の組み合わせであり得る。

サーバ１２１２は、１つまたは複数の汎用コンピュータ、専用のサーバコンピュータ（例として、ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）、サーバファーム、サーバクラスタ、または任意の他の適切な構成および／もしくは組み合わせから構成され得る。サーバ１２１２は、仮想オペレーティングシステムを実行する１つまたは複数の仮想マシン、または、仮想化を含む他のコンピューティングアーキテクチャを含み得る。論理ストレージ装置の１つまたは複数のフレキシブルプールは、サーバ用の仮想ストレージ装置を維持するために、仮想化され得る。仮想ネットワークは、ソフトウェアで定義されるネットワーキングを使用してサーバ１２１２によって制御され得る。種々の実施の形態では、サーバ１２１２は、前述の開示で説明される１つまたは複数のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。例えば、サーバ１２１２は、本開示の実施の形態に従う、上記で説明されるような処理を実行するためのサーバに対応し得る。

サーバ１２１２は、上で論じたもののいずれかを含むオペレーティングシステム、および、市販されている任意のサーバオペレーティングシステムを実行することができる。サーバ１２１２はまた、ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバ等を含む様々な追加のサーバアプリケーション、および／または、ミッドティアアプリケーションのいずれかを実行し得る。データベースサーバの例としては、オラクル、マイクロソフト、Ｓｙｂａｓｅ、ＩＢＭ（インターナショナル・ビジネスマシーン）等から市販されているものが挙げられるが、これらに限定されない。

いくつかの実施形態では、サーバ１２１２は、クライアントコンピューティング装置１２０２，１２０４，１２０６および１２０８のユーザから受信されたデータフィードおよび／またはイベント更新を分析および統合するための１つまたは複数のアプリケーションを含み得る。一例として、データフィードおよび／またはイベント更新は、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（例えば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車トラフィック監視等に関連付けられたリアルタイムイベントを含み得る、１つまたは複数の第三者情報ソースおよび連続データストリームから受信されたＴｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新、または、リアルタイム更新を含み得るが、それらに限定されない。サーバ１２１２はまた、クライアントコンピューティング装置１２０２，１２０４，１２０６および１２０８の１つまたは複数の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つまたは複数のアプリケーションを含み得る。

分散システム１２００はまた、１つまたは複数のデータベース１２１４および１２１６を含み得る。これらのデータベースは、ユーザ識別情報のような情報、および本開示の実施の形態によって使用される他の情報を記憶するための機構を提供し得る。データベース１２１４および１２１６は、様々な場所に存在し得る。例として、データベース１２１４および１２１６のうちの１つまたは複数は、サーバ１２１２にローカルな（および／または常駐する）非一時的な記憶媒体上に常駐し得る。代替的に、データベース１２１４および１２１６は、サーバ１２１２から遠隔にあってもよく、ネットワークベースのまたは専用の接続を介してサーバ１２１２と通信し得る。一組の実施の形態では、データベース１２１４および１２１６は、ストレージエリアネットワーク（ＳＡＮ）内に常駐し得る。同様に、サーバ１２１２に帰属する機能を実行するための任意の必要なファイルは、適宜、サーバ１２１２上にローカルに、および／またはリモートに、記憶され得る。一組の実施の形態では、データベース１２１４および１２１６は、ＳＱＬフォーマットコマンドに応答してデータを記憶、更新、および検索するように適合される、オラクル社によって提供されるデータベースのようなリレーショナルデータベースを含み得る。

図１３は、本開示の実施の形態を実施するために使用され得る例示的なコンピュータシステム１３００を示す。ある実施の形態では、コンピュータシステム１３００は、上記で説明される種々のサーバおよびコンピュータシステムのうちのいずれかを実装するために使用され得る。図１３に示されるように、コンピュータシステム１３００は、バスサブシステム１３０２を介していくつかの周辺サブシステムと通信する処理サブシステム１３０４を含む種々のサブシステムを備える。これらの周辺サブシステムは、処理加速ユニット１３０６、Ｉ／Ｏサブシステム１３０８、記憶サブシステム１３１８、および通信サブシステム１３２４を含み得る。記憶サブシステム１３１８は、有形のコンピュータ読み取り可能な記憶媒体１３２２およびシステムメモリ１３１０を含み得る。

バスサブシステム１３０２は、コンピュータシステム１３００の種々の構成要素およびサブシステムを意図されるように相互に通信させるための機構を提供する。バスサブシステム１３０２は、単一のバスとして概略的に示されるが、当該バスサブシステムの代替の実施の形態は、複数のバスを利用し得る。バスサブシステム１３０２は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む、いくつかのタイプのバス構造のいずれかであり得る。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準協会（ＶＥＳＡ）ローカルバス、および、ＩＥＥＥＰ１３８６.１規格に従って製造されたメザニンバスなどとして実装され得る周辺構成要素インターコネクト（ＰＣＩ）バス等を含み得る。

処理サブシステム１３０４は、コンピュータシステム１３００の動作を制御し、１つまたは複数の処理ユニット１３３２、１３３４等を備え得る。処理ユニットは、シングルコアまたはマルチコアプロセッサを含む１つまたは複数のプロセッサ、プロセッサの１つまたは複数のコア、またはそれらの組み合わせを含み得る。ある実施の形態では、処理サブシステム１３０４は、グラフィックスプロセッサ、デジタル信号プロセッサ（ＤＳＰ）等のような１つまたは複数の専用のコプロセッサを含むことができる。ある実施の形態では、処理サブシステム１３０４の処理ユニットのいくつかまたは全ては、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のようなカスタマイズされた回路を使用して実装され得る。

ある実施の形態では、処理サブシステム１３０４内の処理ユニットは、システムメモリ１３１０内またはコンピュータ読み取り可能な記憶媒体１３２２上に記憶された命令を実行することができる。様々な実施の形態において、処理ユニットは、様々なプログラム又はコード命令を実行することができ、同時に実行される複数のプログラム又はプロセスを維持することができる。任意の所与の時点で、実行されるプログラムコードのいくつかまたは全ては、システムメモリ１３１０内に、および／または潜在的に１つまたは複数の記憶装置上を含むコンピュータ読み取り可能な記憶媒体１３１２上に常駐することができる。適切なプログラミングを通じて、処理サブシステム１３０４は、使用パターンに応じてドキュメント（例えば、ウェブページ）を動的に修正するための上述の様々な機能を提供することができる。

ある実施の形態では、処理加速ユニット１３０６は、コンピュータシステム１３００によって実行される全体的な処理を加速するように、カスタマイズされた処理を実行するために、または、処理サブシステム１３０４によって実行される処理のいくつかをオフロードするために提供され得る。

Ｉ／Ｏサブシステム１３０８は、コンピュータシステム１３００に情報を入力するため、および／または、コンピュータシステム１３００から、またはそれを介して情報を出力するための装置および機構を含み得る。概して、「入力装置」という用語の使用は、情報をコンピュータシステム１３００に入力するための全ての可能なタイプの装置および機構を含むことが意図されている。ユーザインターフェイス入力装置は、例えば、キーボード、マウスまたはトラックボールのようなポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを備えた音声入力装置、マイクロフォン、および他のタイプの入力装置を含み得る。ユーザインターフェイス入力装置はまた、ユーザが入力装置を制御し、それと対話することを可能にするマイクロソフトＫｉｎｅｃｔ（登録商標）モーションセンサ、マイクロソフトＸｂｏｘ（登録商標）３６０ゲームコントローラ、ジェスチャおよび発話コマンドを使用して入力を受信するためのインターフェイスを提供する装置のような、モーション感知および／またはジェスチャ認識装置を含み得る。ユーザインターフェイス入力装置はまた、ユーザから眼の活動（例えば、写真を撮っている間および／またはメニュー選択を行っている間の「まばたき」）を検出し、入力装置（例えば、グーグルグラス（登録商標））への入力として眼のジェスチャを変換する、グーグルグラス（登録商標）まばたき検出器のような眼のジェスチャ認識装置を含み得る。加えて、ユーザインターフェイス入力装置は、ユーザが音声コマンドを通して音声認識システム（例えば、Siri（登録商標）ナビゲータ）と相互作用することを可能にする、音声認識感知装置を含み得る。

ユーザインターフェイス入力装置の他の例は、限定はしないが、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカメラ、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザ距離計、および視線追跡装置のようなオーディオ／ビジュアル装置を含む。加えて、ユーザインターフェイス入力装置は、例えば、コンピュータ断層撮影、磁気共鳴撮像、陽電子放出断層撮影、医療超音波検査装置のような医療画像入力装置を含み得る。ユーザインターフェイス入力装置はまた、例えば、ＭＩＤＩキーボード、デジタル楽器等のオーディオ入力装置を含み得る。

ユーザインターフェイス出力装置は、ディスプレイサブシステム、インジケータライト、またはオーディオ出力装置のような非視覚的ディスプレイを含み得る。当該ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するようなフラットパネル装置、投影装置、タッチスクリーンなどであり得る。概して、「出力装置」という用語の使用は、コンピュータシステム１３００からユーザまたは他のコンピュータに情報を出力するための全ての可能なタイプの装置および機構を含むことが意図される。たとえば、ユーザインターフェイス出力装置は、限定はしないが、モニタ、プリンタ、スピーカー、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力装置、およびモデムのような、テキスト、グラフィックス、および音声／映像情報を視覚的に伝達する様々な表示装置を含み得る。

記憶サブシステム１３１８は、コンピュータシステム１３００によって使用される情報を記憶するためのリポジトリまたはデータストアを提供する。記憶サブシステム１３１８は、ある実施の形態の機能を提供する基本プログラミングおよびデータ構造を記憶するための有形の非一時的なコンピュータ読み取り可能な記憶媒体を提供する。処理サブシステム１３０４によって実行されると上述の機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、記憶サブシステム１３１８に記憶され得る。ソフトウェアは、処理サブシステム１３０４の１つまたは複数の処理ユニットによって実行され得る。記憶サブシステム１３１８はまた、本開示に従って使用されるデータを記憶するためのリポジトリを提供し得る。

記憶サブシステム１３１８は、揮発性および不揮発性メモリ装置を含む、１つまたは複数の非一時的メモリ装置を含み得る。図１３に示されるように、記憶サブシステム１３１８は、システムメモリ１３１０と、コンピュータ読み取り可能な記憶媒体１３２２とを含む。システムメモリ１３１０は、プログラム実行中に命令およびデータを記憶するための揮発性のメインランダムアクセスメモリ（ＲＡＭ）と、固定命令が記憶される不揮発性の読取専用メモリ（ＲＯＭ）またはフラッシュメモリとを含む、いくつかのメモリを含み得る。いくつかの実施形態では、起動中のようにコンピュータシステム１３００内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ）がＲＯＭに記憶され得る。ＲＡＭは、処理サブシステム１３０４によって現在動作および実行されているデータおよび／またはプログラムモジュールを含み得る。いくつかの実施形態では、システムメモリ１３１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）のような、複数の異なるタイプのメモリを含み得る。

限定ではなく例として、図１３に示されるように、システムメモリ１３１０は、クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）等を含み得るアプリケーションプログラム１３１４と、プログラムデータ１３１４と、オペレーティングシステム１３１６とを記憶し得る。例として、オペレーティングシステム１３１６は、様々なバージョンのマイクロソフトウインドウズ（登録商標）、アップルマッキントッシュ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステム、様々な市販のＵＮＩＸ（登録商標）または（様々なＧＮＵ・Ｌｉｎｕｘオペレーティングシステム、グーグル・クローム（登録商標）ＯＳ等を含むが、これらに限定されない）ＵＮＩＸのようなオペレーティングシステム、および／またはｉＯＳ、ウインドウズ（登録商標）Phone、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１０ ＯＳ、およびパーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。

コンピュータ読み取り可能な記憶媒体１３２２は、ある実施の形態の機能を提供するプログラミングおよびデータ構造を記憶し得る。処理サブシステム１３０４によって実行されるとプロセッサが上述の機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、記憶サブシステム１３１８に記憶され得る。例として、コンピュータ読み取り可能な記憶媒体１３２２は、ハードディスクドライブ、磁気ディスクドライブ、ＣＤＲＯＭ、ＤＶＤ、ブルーレイ（登録商標）ディスクのような光ディスクドライブ、または、他の光媒体のような不揮発性メモリを含み得る。コンピュータ読み取り可能な記憶媒体１３２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得るが、これらに限定されない。コンピュータ読み取り可能な記憶媒体１３２２はまた、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭ等の不揮発性メモリに基づくソリッドステートドライブ（ＳＳＤ）と、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤのような揮発性メモリに基づくＳＳＤと、ＤＲＡＭおよびフラッシュメモリベースのＳＳＤの組み合わせを使用するハイブリッドＳＳＤを含み得る。コンピュータ可読媒体１３２２は、コンピュータシステム１３００のための、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、および他のデータの記憶を提供し得る。

ある実施の形態では、記憶サブシステム１３００はまた、コンピュータ読み取り可能な記憶媒体１３２２にさらに接続され得るコンピュータ読み取り可能な記憶媒体リーダ１３４０を含み得る。システムメモリ１３１０と共に、または任意選択で組み合わせて、コンピュータ読み取り可能な記憶媒体１３２２は、コンピュータ読み取り可能な情報を記憶するための、リモートにある、ローカルの、固定された、および／または、記憶媒体を加えた着脱可能な記憶装置を包括的に表し得る。

ある実施の形態では、コンピュータシステム１３００は、１つまたは複数の仮想マシンを実行するためのサポートを提供し得る。コンピュータシステム１３００は、仮想マシンの構成および管理を容易にするためのハイパーバイザのようなプログラムを実行し得る。各仮想マシンは、メモリ、コンピュータ（例えば、プロセッサ、コア）、Ｉ／Ｏ、およびネットワーキングリソースに割り当てられ得る。各仮想マシンは、コンピュータシステム１３００によって実行される他の仮想マシンによって実行されるオペレーティングシステムと同じであり得るまたは異なり得る独自のオペレーティングシステムを実行し得る。したがって、複数のオペレーティングシステムは、潜在的に、コンピュータシステム１３００によって同時に実行され得る。各仮想マシンは、概して、他の仮想マシンから独立して動作する。

通信サブシステム１３２４は、他のコンピュータシステムおよびネットワークへのインターフェイスを提供する。通信サブシステム１３２４は、コンピュータシステム１３００から他のシステムからデータを受信し、かつ、他のシステムにデータを送信するためのインターフェイスとして機能する。例えば、通信サブシステム１３２４は、コンピュータシステム１３００が、１つまたは複数のクライアント装置との間で情報を送受信するために、インターネットを介して１つまたは複数のクライアント装置への通信チャネルを確立することを可能にし得る。加えて、通信サブシステム１３２４は、成功したログインの通知を、または、特権アカウントマネージャから要求側ユーザに対する、パスワードを再入力するための通知を通信するために使用され得る。

通信サブシステム１３２４は、有線および／または無線通信プロトコルの両方をサポートし得る。たとえば、ある実施の形態では、通信サブシステム１３２４は、（たとえば、セルラー電話技術、３Ｇ、４ＧまたはＥＤＧＥ（enhanced data rates for global evolution）のような高度データネットワーク技術を使用する）ワイヤレス音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）トランシーバ構成要素、ＷｉＦｉ（ＩＥＥＥ８０２.１３ファミリー規格、または他のモバイル通信技術、またはそれらの任意の組み合わせ）、全地球測位システム（ＧＰＳ）受信機構成要素、および／または、他の構成要素を含み得る。ある実施の形態では、通信サブシステム１３２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（例えば、イーサネット（登録商標））を提供することができる。

通信サブシステム１３２４は、様々な形態でデータを送受信することができる。例えば、ある実施の形態では、通信サブシステム１３２４は、構造化および／または非構造化データフィード１３２６、イベントストリーム１３２８、イベント更新１３３０等の形態で入力通信を受信し得る。例えば、通信サブシステム１３２４は、ソーシャルメディアネットワーク、Twitter（登録商標）フィード、Facebook（登録商標）更新、Rich Site Summary（RSS）フィードのようなウェブフィード、および／または、１つまたは複数の第三者情報ソースからのリアルタイム更新のような他の通信サービスのユーザから、リアルタイムでデータフィード１３２６を受信（または送信）するように構成され得る。

ある実施の形態では、通信サブシステム１３２４は、連続データストリームの形態でデータを受信するように構成され得、連続データストリームは、明示的な終了を伴わない、本質的に連続的または無限であり得る、リアルタイムイベントのイベントストリーム１３２８および／またはイベント更新１３３０を含み得る。連続データを生成するアプリケーションの例は、例えば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（例えば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車トラフィック監視などを含み得る。

通信サブシステム１３２４はまた、構造化および／または非構造化データフィード１３２６、イベントストリーム１３２８、イベント更新１３３０などを、コンピュータシステム１３００に結合された１つまたは複数のストリーミングデータソースコンピュータと通信し得る１つまたは複数のデータベースに出力するように構成され得る。

コンピュータシステム１３００は、ハンドヘルドポータブル装置（例えば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブル装置（例えば、グーグルグラス（登録商標）ヘッドマウントディスプレイ）、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、または任意の他のデータ処理システムを含む、種々のタイプの１つであり得る。

コンピュータおよびネットワークの絶えず変化する性質のため、図１３に描写されるコンピュータシステム１３００の説明は、具体例としてのみ意図される。図１３に示されるシステムよりも多いまたは少ない構成要素を有する多くの他の構成が可能である。本明細書に提供される開示および教示に基づいて、当業者は、種々の実施の形態を実装するための他の手段および／または方法を理解するであろう。

図面のいくつかに示されるシステムは、様々な構成で提供され得る。ある実施の形態では、システムは、当該システムの１つまたは複数の構成要素が１つまたは複数のクラウドインフラストラクチャシステムにおける１つまたは複数のネットワークにわたって分散される、分散システムとして構成され得る。

クラウドインフラストラクチャシステムは、１つまたは複数のサーバコンピューティング装置、ネットワーク装置、および／または記憶装置の集合である。これらのリソースは、クラウドサービスプロバイダによって分割され、何らかの態様でその顧客に割り当てられ得る。例えば、カリフォルニア州レッドウッドショアのオラクル社のようなクラウドサービスプロバイダは、限定はしないが、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリの下で提供される１つまたは複数のサービス、プラットフォーム・アズ・ア・サービス（ＰａａＳ）カテゴリの下で提供されるサービス、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）カテゴリの下で提供されるサービス、または、ハイブリッドサービスを含む他のカテゴリのサービスを含む、様々なタイプのクラウドサービスを提供し得る。ＳａａＳサービスの例は、限定はしないが、オラクルフュージョンアプリケーションのようなオンデマンドアプリケーションのスイートを構築および配信する能力を含む。ＳａａＳサービスは、顧客がアプリケーションのためのソフトウェアを購入する必要なしに、顧客がクラウドインフラストラクチャシステム上で実行するアプリケーションを利用することを可能にする。ＰａａＳサービスの例は、（オラクル社のような）組織が共有された共通アーキテクチャ上で既存のアプリケーションを統合することを可能にするサービス、ならびに、オラクルＪａｖａクラウドサービス（ＪＣＳ）、オラクルデータベースクラウドサービス（ＤＢＣＳ）等のプラットフォームによって提供される共有サービスを活用する新しいアプリケーションを構築する能力を含むが、これらに限定されない。ＩａａＳサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のために、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースのような基礎的コンピューティングリソースの管理および制御を促進し得る。

図１４は、本開示の一実施の形態に従う、実施の形態のシステムの１つまたは複数の構成要素によって提供されるサービスがクラウドサービスとして提供され得るシステム環境１４００の１つまたは複数の構成要素の簡略的なブロック図である。例示される実施の形態では、システム環境１４００は、クラウドサービスを提供するクラウドインフラストラクチャシステム１４０２と対話するためにユーザによって使用され得る１つまたは複数のクライアントコンピューティング装置１４０４，１４０６および１４０８を含む。クライアントコンピューティング装置は、クラウドインフラストラクチャシステム１４０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム１４０２と対話するためのクライアントコンピューティング装置のユーザによって使用され得る、ウェブブラウザ、専有クライアントアプリケーション（たとえば、オラクル・フォームズ）、または何らかの他のアプリケーションのようなクライアントアプリケーションを動作させるように構成され得る。

図に描かれているクラウドインフラストラクチャシステム１４０２は、描かれているもの以外のコンポーネントを有し得ることが理解されるべきである。さらに、図に示される実施の形態は、本開示の実施の形態を組み込み得るクラウドインフラストラクチャシステムの一例にすぎない。いくつかの他の実施の形態では、クラウドインフラストラクチャシステム１４０２は、図に示されるよりも多くの又は少ない構成要素を有してもよく、２つ以上の構成要素を組み合わせてもよく、あるいは、異なる構成もしくは構成要素の配置を有し得る。

クライアントコンピューティング装置１４０４，１４０６および１４０８は、１２０２，１２０４，１２０６および１２０８について上で説明されたものと同様の装置であり得る。

３つのクライアントコンピューティング装置を有する例示的なシステム環境１４００が示されているが、任意の数のクライアントコンピューティング装置がサポートされ得る。センサ等を有する装置のような他の装置は、クラウドインフラストラクチャシステム１４０２と対話し得る。

ネットワーク１４１０は、クライアント１４０４，１４０６および１４０８とクラウドインフラストラクチャシステム１４０２との間のデータの通信および交換を容易にし得る。各ネットワークは、ネットワーク１４１０について上述したものを含む、様々な市販のプロトコルのいずれかを使用してデータ通信をサポートすることができる、当業者によく知られている任意のタイプのネットワークであり得る。

クラウドインフラストラクチャシステム１４０２は、サーバ１２１２について上述したものを含み得る１つまたは複数のコンピュータおよび／またはサーバを含み得る。

ある実施の形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータ記憶およびバックアップソリューション、ウェブベースの電子メールサービス、ホストされたオフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービス等のような、オンデマンドでクラウドインフラストラクチャシステムのユーザに利用可能にされるサービスのホストを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリングすることができる。クラウドインフラストラクチャシステムによって提供されるサービスの特定のインスタンス化は、本明細書では「サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムからインターネットのような通信ネットワークを介してユーザに利用可能とされる任意のサービスは、「クラウドサービス」と呼ばれる。パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。例えば、クラウドサービスプロバイダのシステムは、アプリケーションをホストし得、ユーザは、インターネットのような通信ネットワークを介して、オンデマンドで、当該アプリケーションを注文および使用し得る。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、ストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供される他のサービスに対する保護されたコンピュータネットワークアクセス、または当技術分野で知られている他のサービスを含み得る。例えば、サービスは、インターネットを介したクラウド上のリモートストレージへのパスワードで保護されたアクセスを含むことができる。別の例として、サービスは、ウェブサービスベースのホストされたリレーショナルデータベースと、ネットワーク化された開発者によるプライベート使用のためのスクリプト言語ミドルウェアエンジンとを含むことができる。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含むことができる。

ある実施の形態では、クラウドインフラストラクチャシステム１４０２は、自己サービス、加入ベースの、弾性的にスケーラブルな、信頼性のある、高度に利用可能な、およびセキュアな態様で顧客に引き渡される、アプリケーション、ミドルウェア、およびデータベースサービス提供のスイートを含み得る。そのようなクラウドインフラストラクチャシステムの例は、本譲受人によって提供されるオラクルパブリッククラウドである。

さまざまな実施の形態において、クラウドインフラストラクチャシステム１４０２は、クラウドインフラストラクチャシステム１４０２によって提供されるサービスへの顧客の加入を自動的にプロビジョニングし、管理し、追跡するように適合され得る。クラウドインフラストラクチャシステム１４０２は、異なるデプロイメントモデルを介してクラウドサービスを提供し得る。例えば、サービスは、クラウドインフラストラクチャシステム１４０２が（例えば、オラクル社によって所有される）クラウドサービスを販売する組織によって所有され、かつ、サービスが一般公衆または異なる業界企業に利用可能にされる、公衆クラウドモデルの下で提供され得る。別の例として、サービスは、クラウドインフラストラクチャシステム１４０２が単一の組織に対してのみ動作し、当該組織における１つまたは複数のエンティティにサービスを提供し得るプライベートクラウドモデルの下で提供され得る。クラウドサービスはまた、クラウドインフラストラクチャシステム１４０２およびクラウドインフラストラクチャシステム１４０２によって提供されるサービスが関連するコミュニティ内のいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供され得る。クラウドサービスはまた、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供され得る。

ある実施の形態では、クラウドインフラストラクチャシステム１４０２によって提供されるサービスは、サービスとしてのソフトウェア（ＳａａＳ）カテゴリ、サービスとしてのプラットフォーム（ＰａａＳ）カテゴリ、サービスとしてのインフラストラクチャ（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される１つまたは複数のサービスを含み得る。顧客は、サブスクリプション注文を介して、クラウドインフラストラクチャシステム１４０２によって提供される１つまたは複数のサービスを注文し得る。次いで、クラウドインフラストラクチャシステム１４０２は、顧客のサブスクリプション注文でサービスを提供するための処理を実行する。

ある実施の形態では、クラウドインフラストラクチャシステム１４０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを含み得るが、それらに限定されない。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供され得る。ＳａａＳプラットフォームは、ＳａａＳカテゴリに該当するクラウドサービスを提供するように構成され得る。例えば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上でオンデマンドアプリケーションのスイートを構築および配信するための能力を提供し得る。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で実行するアプリケーションを利用することができる。顧客は、別個のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。様々な異なるＳａａＳサービスが提供され得る。例は、販売実績管理、企業統合、および大規模組織のためのビジネス柔軟性のためのソリューションを提供するサービスを含むが、それらに限定されない。

ある実施の形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供され得る。ＰａａＳプラットフォームは、ＰａａＳカテゴリに該当するクラウドサービスを提供するように構成され得る。プラットフォームサービスの例は、（オラクル社のような）組織が共有の共通アーキテクチャ上で既存のアプリケーションを統合することを可能にするサービス、ならびにプラットフォームによって提供される共有サービスを活用する新しいアプリケーションを構築する能力を含み得るが、それらに限定されない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得することができる。プラットフォームサービスの例は、オラクルＪａｖａクラウドサービス（ＪＣＳ）、オラクルデータベースクラウドサービス（ＤＢＣＳ）などを含むが、これらに限定されない。

ＰａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを採用することができ、また、展開されたサービスを制御することもできる。ある実施の形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（例えば、オラクルヒュージョンミドルウェアサービス）、およびＪａｖａクラウドサービスを含み得る。一実施の形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形態でサービスとしてデータベースを顧客に提供することを可能にする共有サービスデプロイメントモデルをサポートし得る。ミドルウェアクラウドサービスは、顧客が様々なビジネスアプリケーションを開発およびデプロイするためのプラットフォームを提供することができ、Ｊａｖａクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイするためのプラットフォームを提供することができる。

様々な異なるインフラストラクチャサービスが、クラウドインフラストラクチャシステムにおけるＩａａＳプラットフォームによって提供され得る。インフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースのような基礎的コンピューティングリソースの管理および制御を容易にする。

ある実施の形態では、クラウドインフラストラクチャシステム１４０２はまた、クラウドインフラストラクチャシステムの顧客に様々なサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１４３０もまた含み得る。一実施の形態では、インフラストラクチャリソース１４３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するための、サーバ、ストレージ、およびネットワーキングリソースのようなハードウェアの事前に統合されて、かつ最適化された組み合わせを含み得る。

ある実施の形態では、クラウドインフラストラクチャシステム１４０２におけるリソースは、複数のユーザによって共有され、需要ごとに動的に再割り当てされ得る。加えて、リソースは、異なる時間帯においてユーザに割り当てられ得る。たとえば、クラウドインフラストラクチャシステム１４３０は、第１の時間帯におけるある一組のユーザがクラウドインフラストラクチャシステムのリソースを指定された時間にわたって利用することを可能にし、次いで、異なる時間帯に位置する他の組のユーザに同じリソースを再割り当てすることを可能にし、それによってリソースの利用を最大にすることができる。

ある実施の形態では、クラウドインフラストラクチャシステム１４０２の異なる構成要素またはモジュールによって、およびクラウドインフラストラクチャシステム１４０２によって提供されるサービスによって共有されるいくつかの内部共有サービス１４３２が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよび回復サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービス、等を含み得るが、これらに限定されない。

ある実施の形態では、クラウドインフラストラクチャシステム１４０２は、当該クラウドインフラストラクチャシステムにおけるクラウドサービス（例えば、ＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的な管理を提供し得る。一実施の形態では、クラウド管理機能は、クラウドインフラストラクチャシステム１４０２によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含み得る。

一実施の形態では、図に示されるように、クラウド管理機能は、注文管理モジュール１４２０、注文オーケストレーションモジュール１４２２、注文プロビジョニングモジュール１４２４、注文管理および監視モジュール１４２６、ならびにアイデンティティ管理モジュール１４２８のような１つまたは複数のモジュールによって提供され得る。これらのモジュールは、１つまたは複数のコンピュータおよび／またはサーバを含むか、またはそれらを使用して提供され得、それらは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な構成であり得る。

例示的な動作１４３４において、クライアント装置１４０４，１４０６または１４０８のようなクライアント装置を使用する顧客は、クラウドインフラストラクチャシステム１４０２によって提供される１つまたは複数のサービスを要求し、かつ、クラウドインフラストラクチャシステム１４０２によって提供される１つまたは複数のサービスのサブスクリプションの注文を行うことによって、クラウドインフラストラクチャシステム１４０２と対話し得る。ある実施の形態では、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ１４１６、クラウドＵＩ１４１４、および／またはクラウドＵＩ１４１６にアクセスし、これらのＵＩを介してサブスクリプション注文を行ない得る。顧客が注文を行うことに応答してクラウドインフラストラクチャシステム１４０２によって受信される注文情報は、当該顧客と、当該顧客が加入しようとする、クラウドインフラストラクチャシステム１４０２によって提供される１つまたは複数のサービスとを識別する情報を含み得る。

注文が顧客によって行われた後、注文情報は、クラウドＵＩ１４１４，１４１４および／又は１４１６を介して受信される。

動作１４３６において、注文は注文データベース１４１８に記憶される。注文データベース１４１８は、クラウドインフラストラクチャシステム１４０２によって運用され、他のシステム要素とともに運用されるいくつかのデータベースのうちの１つであり得る。

動作１４３８において、注文情報は注文管理モジュール１４２０に転送される。いくつかの例では、注文管理モジュール１４２０は、注文を検証すること、検証時に注文を予約することのような、注文に関連付けられた請求および課金機能を実行するように構成され得る。

動作１４４０において、注文に関する情報は、注文オーケストレーションモジュール１４２２に通信される。注文オーケストレーションモジュール１４２２は、注文情報を利用して、顧客によって行われた注文のためのサービスおよびリソースのプロビジョニングを調整することができる。いくつかの例では、注文オーケストレーションモジュール１４２２は、リソースのプロビジョニングを調整して、注文プロビジョニングモジュール１４２４のサービスを使用して購読されたサービスをサポートすることができる。

ある実施の形態では、注文オーケストレーションモジュール１４２２は、各注文に関連付けられたビジネスプロセスの管理を可能にし、ビジネスロジックを適用して、注文がプロビジョニングに進むべきかどうかを決定する。動作１４４２において、新しいサブスクリプション注文を受信すると、注文オーケストレーションモジュール１４２２は、リソースを割り当て、当該サブスクリプション注文を満たすために必要とされるリソースを構成するように、要求を注文プロビジョニングモジュール１４２４に送信する。注文プロビジョニングモジュール１４２４は、顧客によって注文されたサービスのためのリソースの割り当てを可能にする。注文プロビジョニングモジュール１４２４は、クラウドインフラストラクチャシステム１４０２によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理実装レイヤとの間の抽象化のレベルを提供する。したがって、注文オーケストレーションモジュール１４２２は、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか、または事前にプロビジョニングされ、要求に応じてのみ割り振られる／割り当てられるかのような、実装の詳細から隔離され得る。

動作１４４４において、サービスおよびリソースがプロビジョニングされると、提供されたサービスの通知が、クラウドインフラストラクチャシステム１４０２の注文プロビジョニングモジュール１４２４によって、クライアントコンピューティング装置１４０４，１４０６および／または１４０８上の顧客に送信され得る。動作１４４６において、顧客のサブスクリプション注文は、注文管理および監視モジュール１４２６によって管理および追跡され得る。いくつかの事例では、注文管理および監視モジュール１４２６は、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステム起動時間およびシステム停止時間の量のような、サブスクリプション注文におけるサービスのための使用統計を収集するように構成され得る。

特定の実施の形態では、クラウドインフラストラクチャシステム１４０２は、アイデンティティ管理モジュール１４２８を含み得る。アイデンティティ管理モジュール１４２８は、クラウドインフラストラクチャシステム１４０２におけるアクセス管理および認可サービスのようなアイデンティティサービスを提供するように構成され得る。ある実施の形態では、アイデンティティ管理モジュール１４２８は、クラウドインフラストラクチャシステム１４０２によって提供されるサービスを利用することを望む顧客に関する情報を制御し得る。そのような情報は、そのような顧客のアイデンティティを認証する情報、およびそれらの顧客が様々なシステムリソース（例えば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど。）に対してどのアクションを実行することを許可されるかを記述する情報を含むことができる。アイデンティティ管理モジュール１４２８はまた、各顧客に関する記述情報、ならびにその記述情報がどのようにおよび誰によってアクセスおよび修正され得るかに関する記述情報の管理を含み得る。

本開示の特定の実施の形態について説明されたが、様々な修正、変更、代替構成、および均等物も本開示の範囲内に包含される。本開示の実施の形態は、ある特定のデータ処理環境内での動作に限定されず、複数のデータ処理環境内で自由に動作することができる。加えて、本開示の実施の形態は、特定の一連の処理およびステップを使用して説明されているが、本開示の範囲は、説明された一連の処理およびステップに限定されないことが、当業者に明白となるはずである。上述の実施の形態の様々な特徴および態様は、個々にまたは共同で使用され得る。

さらに、本開示の実施の形態は、ハードウェアおよびソフトウェアの特定の組み合わせを使用して説明されたが、ハードウェアおよびソフトウェアの他の組み合わせも本開示の範囲内であることが認識されるべきである。本開示の実施の形態は、ハードウェアのみで、またはソフトウェアのみで、またはそれらの組み合わせを使用して実施され得る。本明細書で説明する様々なプロセスは、同じプロセッサまたは異なるプロセッサ上で任意の組み合わせで実施され得る。したがって、構成要素またはモジュールがある動作を実行するように構成されるものとして説明される場合、そのような構成は、たとえば、当該動作を実行するように電子回路を設計することによって、その動作を実行するように（マイクロプロセッサのような）プログラマブル電子回路をプログラミングすることによって、または、それらの任意の組み合わせによって、達成され得る。プロセスは、プロセス間通信のための従来の技術を含むが、それらに限定されない、種々の技術を使用して通信することができ、プロセスの異なるペアは、異なる技術を使用してもよく、またはプロセスの同じペアは、異なる時間に異なる技術を使用し得る。

したがって、明細書および図面は、限定的な意味ではなく例示的な意味で見なされるべきである。しかしながら、特許請求の範囲に記載されるより広い精神および範囲から逸脱することなく、追加、削減（subtractions）、削除（deletions）、ならびに他の修正および変更がなされ得ることは明らかであろう。したがって、特定の開示の実施の形態が説明されてきたが、これらは限定を意図するものではない。様々な修正および均等物が、以下の特許請求の範囲内にある。当該修正は、開示された特徴の適切な組み合わせを含む。

Claims (21)

1. 方法であって、
   スケジューラが、実行対象におけるリソースの第１のデプロイメントのための構成ファイルを受信することを含み、前記構成ファイルは第１のリリース識別子を含み、前記方法はさらに、
   前記構成ファイルに従って前記実行対象にリソースをデプロイすることと、
   前記リソースの現在の状態を記憶することと、
   前記スケジューラが、前記実行対象における新しいデプロイメントのために前記構成ファイルの第２のバージョンを受信することとを含み、前記構成ファイルの前記第２のバージョンは第２のリリース識別子を含み、前記方法はさらに、
   複数のワーカーノードのうちの少なくとも１つが、プラグインを実行して、前記第１のリリース識別子を前記第２のリリース識別子と比較することと、
   前記第１のリリース識別子が前記第２のリリース識別子とは異なることに応じて、前記構成ファイルの前記第２のバージョンに従って前記実行対象にリソースをデプロイすることとを含む、方法。
2. 前記スケジュールは、地域インフラストラクチャサービスによって実施される、請求項１に記載の方法。
3. 前記地域インフラストラクチャサービスは、宣言型インフラストラクチャプロビジョニングツールを実施する、請求項２に記載の方法。
4. 前記スケジューラは、複数のワーカーノードと通信する、請求項２または請求項３に記載の方法。
5. 前記実行対象にリソースをデプロイすることは、前記複数のワーカーノードのうちの少なくとも１つにタスクを割り当てることを含む、請求項４に記載の方法。
6. 前記構成ファイルは、中央インフラストラクチャサービスのフロックマネージャから、前記スケジューラによって受信される、先行する請求項のいずれかに記載の方法。
7. 前記中央インフラストラクチャサービスは、必須である、請求項６に記載の方法。
8. 前記第１のリリース識別子または前記第２のリリース識別子のうちの少なくとも１つは、前記中央インフラストラクチャサービスの前記フロックマネージャによってランダムに生成される、請求項６または請求項７に記載の方法。
9. 前記フロックマネージャは、前記第１のリリース識別子または前記第２のリリース識別子のうちの少なくとも１つを前記構成ファイルに挿入するように構成されている、請求項８に記載の方法。
10. 前記プラグインを使用して、前記第２の構成ファイルに従って、前記リソースの前記現在の状態を、前記リソースの前記所望の状態と比較することと、
    前記所望の状態が前記現在の状態とは異なるという判定に応じて、前記構成ファイルの前記第２のバージョンに従って前記実行対象に前記リソースをデプロイすることのみを、さらに備える、先行する請求項のいずれかに記載の方法。
11. システムであって、
    １つまたは複数のプロセッサと、
    コンピュータが実行可能な命令を記憶する１つまたは複数のメモリとを備え、前記命令は、前記１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサを、
    スケジューラによって、実行対象におけるリソースの第１のデプロイメントのための構成ファイルを受信するように構成し、前記構成ファイルは第１のリリース識別子を含み、
    前記構成ファイルに従って前記実行対象にリソースをデプロイし、
    前記リソースの現在の状態を記憶するように構成し、
    前記スケジューラによって、前記実行対象における新しいデプロイメントのために前記構成ファイルの第２のバージョンを受信するように構成し、前記構成ファイルの前記第２のバージョンは第２のリリース識別子を含み、
    複数のワーカーノードのうちの少なくとも１つによって、プラグインを実行して、前記第１のリリース識別子を前記第２のリリース識別子と比較し、
    前記第１のリリース識別子が前記第２のリリース識別子とは異なることに応じて、前記構成ファイルの第２のバージョンに従って前記実行対象にリソースをデプロイするように構成する、システム。
12. 前記スケジュールは、地域インフラストラクチャサービスによって実施される、請求項１１に記載のシステム。
13. 前記スケジューラは、複数のワーカーノードと通信する、請求項１２に記載のシステム。
14. 前記構成ファイルは、前記スケジューラによって、中央インフラストラクチャサービスのフロックマネージャから、受信される、請求項１１～１３のいずれかに記載のシステム。
15. 前記第１のリリース識別子または前記第２のリリース識別子のうちの少なくとも１つは、前記中央インフラストラクチャサービスの前記フロックマネージャによってランダムに生成される、請求項１４に記載のシステム。
16. 前記フロックマネージャは、前記第１のリリース識別子または前記第２のリリース識別子のうちの少なくとも１つを前記構成ファイルに挿入するように構成されている、請求項１５に記載のシステム。
17. コンピュータが実行可能な命令を記憶するコンピュータ読み取り可能な記憶媒体であって、前記命令は、１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに動作を実行させ、前記動作は、
    スケジューラによって、実行対象におけるリソースの第１のデプロイメントのための構成ファイルを受信することを含み、前記構成ファイルは第１のリリース識別子を含み、前記動作はさらに、
    前記構成ファイルに従って前記実行対象にリソースをデプロイメントすることと、
    前記リソースの現在の状態を記憶することと、
    前記スケジューラによって、前記実行対象における新しいデプロイメントのための構成ファイルの第２のバージョンを受信することとを含み、前記構成ファイルの第２のバージョンは第２のリリース識別子を含み、前記動作はさらに、
    複数のワーカーノードのうちの少なくとも１つによって、プラグインを実行して、前記第１のリリース識別子を前記第２のリリース識別子と比較することと、
    前記第１のリリース識別子が前記第２のリリース識別子とは異なることに従って、前記構成ファイルの第２のバージョンに従って実行対象にリソースをデプロイメントすることとを含む、コンピュータ読み取り可能な記憶媒体。
18. 前記実行対象にリソースをデプロイメントすることは、前記スケジューラと通信する複数のワーカーノードのうちの少なくとも１つにタスクを割り当てることを含む、請求項１７に記載のコンピュータ読み取り可能な記憶媒体。
19. 前記構成ファイルは、中央インフラストラクチャサービスのフロックマネージャから、前記スケジューラによって受信される、請求項１７または請求項１８に記載のコンピュータ読み取り可能な記憶媒体。
20. 前記第１のリリース識別子または前記第２のリリース識別子のうちの少なくとも１つは、前記中央インフラストラクチャサービスの前記フロックマネージャによってランダムに生成され、前記フロックマネージャは、前記第１のリリース識別子または前記第２のリリース識別子のうちの少なくとも１つを前記構成ファイルに挿入するように構成される、請求項１９に記載のコンピュータ読み取り可能な記憶媒体。
21. 請求項１～１０に記載のステップを実行するための手段を備える、装置。

Images