(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-03-16
(54)【発明の名称】デプロイ命令のために有向非巡回グラフを利用するための技術
(51)【国際特許分類】
G06F 9/50 20060101AFI20230309BHJP
G06F 8/60 20180101ALI20230309BHJP
H04L 67/10 20220101ALI20230309BHJP
【FI】
G06F9/50 150A
G06F8/60
H04L67/10
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022543757
(86)(22)【出願日】2021-01-15
(85)【翻訳文提出日】2022-09-15
(86)【国際出願番号】 US2021013585
(87)【国際公開番号】W WO2021150435
(87)【国際公開日】2021-07-29
(32)【優先日】2020-01-20
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2020-11-19
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】グラス,ナサニエル・マーティン
(72)【発明者】
【氏名】ヤブロンスキー,グレゴリー・マーク
【テーマコード(参考)】
5B376
【Fターム(参考)】
5B376BC11
5B376BC43
(57)【要約】
デプロイ命令のために有向非巡回グラフを利用するための技術を開示する。コンピュータにより実現される方法は、様々な動作を含み得る。コンピューティングデバイスによって、デプロイに関連する設定データの複数回の解析を実行する命令が実行され得る。コンピューティングデバイスは、第1DAG(有向非巡回グラフ)を生成させてもよく、第1DAGは、解析に基づいて第1リソースをデプロイするために利用される。解析に基づいて実行ターゲットをデプロイするための第2DAGが生成されてもよく、第2DAGは、デプロイメントの実行ターゲット間の依存関係を指定する。コンピューティングデバイスは、解析に基づいて連結リストデータ構造を生成してもよく、連結リストデータ構造を横断することによってコンピューティングシステムをデプロイし得る。
【特許請求の範囲】
【請求項1】
コンピュータにより実現される方法であって、
コンピューティングデバイスが、コンピューティングシステムのデプロイに関連する設定データの1回以上の解析を実行するための命令を実行するステップと、
前記コンピューティングデバイスが、第1DAG(有向非巡回グラフ)を生成させるステップとを含み、前記第1DAGは、前記1回以上の解析の実行に少なくとも一部基づいて第1リソースをデプロイするために利用され、前記方法は、さらに、
前記コンピューティングデバイスが、前記1回以上の解析の実行に少なくとも一部基づいて、複数の実行ターゲットをデプロイするための第2DAGを生成するステップを含み、前記第2DAGは、前記デプロイメントの実行ターゲット間の依存関係を指定し、前記方法は、さらに、
前記コンピューティングデバイスが、前記1回以上の解析の実行に少なくとも一部基づいて、連結リストデータ構造を生成するステップを含み、前記連結リストデータ構造は、複数のデプロイフェーズ間の依存関係を指定し、前記方法は、さらに、
前記コンピューティングデバイスが、前記連結リストデータ構造、前記第2DAG、前記第1DAGを横断することに少なくとも一部基づいて、前記コンピューティングシステムをデプロイするステップを含む、方法。
【請求項2】
前記第1DAGは、宣言型インフラストラクチャプロビジョナーによって生成される、請求項1に記載のコンピュータにより実現される方法。
【請求項3】
前記第1DAGは、前記コンピューティングシステムの第1リソースの、前記コンピューティングシステムの第2リソースの能力への依存を指定する、請求項1または2に記載のコンピュータにより実現される方法。
【請求項4】
前記第1リソースまたは前記第2リソースの各々は、複数のコンピューティングサービスのうち1つのコンピューティングサービスであり、前記能力は、前記第2リソースの機能の一部である、請求項3に記載のコンピュータにより実現される方法。
【請求項5】
前記第2DAGの少なくとも1つのノードは、前記第1DAGのノードを参照する、請求項1~4のいずれか1項に記載のコンピュータにより実現される方法。
【請求項6】
前記連結リストデータ構造のノードは、前記第2DAGの少なくとも1つのノードを参照する、請求項1~5のいずれか1項に記載のコンピュータにより実現される方法。
【請求項7】
前記設定データの1回以上の解析を実行するための前記命令は、
前記設定データで提供される明示的なステートメントを介して第1の依存関係を検出するステップ、または、
前記設定データで提供される暗黙的依存関係を識別することに少なくとも一部基づいて、第2の依存関係を検出するステップを含む、請求項1~6のいずれか1項に記載のコンピュータにより実現される方法。
【請求項8】
前記設定データは、1つ以上の依存関係を介して、複数のリソースをデプロイするためのインフラストラクチャデプロイメント操作を実行する順序を示す、請求項1~7のいずれか1項に記載のコンピュータにより実現される方法。
【請求項9】
前記1つ以上の依存関係は、宣言型ステートメントを利用して定められる、請求項1~8のいずれか1項に記載のコンピュータにより実現される方法。
【請求項10】
システムであって、
1つ以上のプロセッサと、
コンピュータ実行可能な命令を格納した1つ以上のメモリとを備え、前記コンピュータ実行可能な命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサを、
コンピューティングデバイスが、コンピューティングシステムのデプロイに関連する設定データの1回以上の解析を実行するための命令を実行し、
前記コンピューティングデバイスが、第1DAGを生成させるように構成し、前記第1DAGは、前記1回以上の解析の実行に少なくとも一部基づいて第1リソースをデプロイするために利用され、前記コンピュータ実行可能な命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサを、さらに、
前記コンピューティングデバイスが、前記1回以上の解析の実行に少なくとも一部基づいて、複数の実行ターゲットをデプロイするための第2DAGを生成するように構成し、前記第2DAGは、前記デプロイメントの実行ターゲット間の依存関係を指定し、前記コンピュータ実行可能な命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサを、さらに、
前記コンピューティングデバイスが、前記1回以上の解析の実行に少なくとも一部基づいて、連結リストデータ構造を生成するように構成し、前記連結リストデータ構造は、複数のデプロイフェーズ間の依存関係を指定し、前記コンピュータ実行可能な命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサを、さらに、
前記コンピューティングデバイスが、前記連結リストデータ構造、前記第2DAG、前記第1DAGを横断することに少なくとも一部基づいて、前記コンピューティングシステムをデプロイするように構成する、システム。
【請求項11】
前記第1DAGは、宣言型インフラストラクチャプロビジョナーによって生成され、前記第1DAGは、前記コンピューティングシステムの第1リソースの、前記コンピューティングシステムの第2リソースの能力への依存を指定する、請求項10に記載のシステム。
【請求項12】
前記第1リソースまたは前記第2リソースの各々は、複数のコンピューティングサービスのうち1つのコンピューティングサービスであり、前記能力は、前記第2リソースの機能の一部である、請求項11に記載のシステム。
【請求項13】
前記第2DAGの少なくとも1つのノードは、前記第1DAGのノードを参照し、前記連結リストデータ構造のノードは、前記第2DAGの少なくとも1つのノードを参照する、請求項10~12のいずれか1項に記載のシステム。
【請求項14】
前記設定データは、1つ以上の依存関係を介して、複数のリソースをデプロイするためのインフラストラクチャデプロイメント操作を実行する順序を示し、前記1つ以上の依存関係は、宣言型ステートメントを利用して定められ、前記設定データの1回以上の解析を実行するための前記命令は、
前記設定データで提供される明示的なステートメントを介して第1の依存関係を検出すること、または、
前記設定データで提供される暗黙的依存関係を識別することに少なくとも一部基づいて、第2の依存関係を検出することを含む、請求項10~13のいずれか1項に記載のシステム。
【請求項15】
コンピュータ実行可能な命令を格納するコンピュータ読み取り可能な記憶媒体であって、前記コンピュータ実行可能な命令は、1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、動作を実行させ、前記動作は、
コンピューティングデバイスが、コンピューティングシステムのデプロイに関連する設定データの1回以上の解析を実行するための命令を実行することと、
前記コンピューティングデバイスが、第1DAGを生成させることとを含み、前記第1DAGは、前記1回以上の解析の実行に少なくとも一部基づいて第1リソースをデプロイするために利用され、前記動作は、さらに、
前記コンピューティングデバイスが、前記1回以上の解析の実行に少なくとも一部基づいて、複数の実行ターゲットをデプロイするための第2DAGを生成することを含み、前記第2DAGは、前記デプロイメントの実行ターゲット間の依存関係を指定し、前記動作は、さらに、
前記コンピューティングデバイスが、前記1回以上の解析の実行に少なくとも一部基づいて、連結リストデータ構造を生成することを含み、前記連結リストデータ構造は、複数のデプロイフェーズ間の依存関係を指定し、前記動作は、さらに、
前記コンピューティングデバイスが、前記連結リストデータ構造、前記第2DAG、前記第1DAGを横断することに少なくとも一部基づいて、前記コンピューティングシステムをデプロイすることを含む、コンピュータ読み取り可能な記憶媒体。
【請求項16】
前記第1DAGは、宣言型インフラストラクチャプロビジョナーによって生成され、前記第1DAGは、前記コンピューティングシステムの第1リソースの、前記コンピューティングシステムの第2リソースの能力への依存を指定する、請求項15に記載のコンピュータ読み取り可能な記憶媒体。
【請求項17】
前記第1リソースまたは前記第2リソースの各々は、複数のコンピューティングサービスのうち1つのコンピューティングサービスであり、前記能力は、前記第2リソースの機能の一部である、請求項16に記載のコンピュータ読み取り可能な記憶媒体。
【請求項18】
前記第2DAGの少なくとも1つのノードは、前記第1DAGのノードを参照し、前記連結リストデータ構造のノードは、前記第2DAGの少なくとも1つのノードを参照する、請求項15~17のいずれか1項に記載のコンピュータ読み取り可能な記憶媒体。
【請求項19】
前記設定データの1回以上の解析を実行するための前記命令は、
前記設定データで提供される明示的なステートメントを介して第1の依存関係を検出すること、または、
前記設定データで提供される暗黙的依存関係を識別することに少なくとも一部基づいて、第2の依存関係を検出することを含む、請求項15~18のいずれか1項に記載のコンピュータ読み取り可能な記憶媒体。
【請求項20】
前記設定データは、1つ以上の依存関係を介して、複数のリソースをデプロイするためのインフラストラクチャデプロイメント操作を実行する順序を示し、前記1つ以上の依存関係は、宣言型ステートメントを利用して定められる、請求項15~19のいずれか1項に記載のコンピュータ読み取り可能な記憶媒体。
【請求項21】
請求項1~9のいずれか1項に記載のステップを実行するための手段を含む、装置。
【請求項22】
コンピュータ命令を備えるコンピュータプログラムプロダクトであって、前記コンピュータ命令は、プロセッサによって実行されると、請求項1~9のいずれか1項に記載の方法のステップを実行する、コンピュータプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、通常出願であり、米国特許法第119条(e)の下、2020年1月20日に出願され「TECHNIQUES FOR UTILIZING DIRECTED ACYCLIC GRAPHS FOR DEPLOYMENT INSTRUCTIONS(デプロイ命令のために有向非巡回グラフを利用するための技術)」と題された米国仮出願第62/963,477号、および2020年11月19日に出願され「TECHNIQUES FOR UTILIZING DIRECTED ACYCLIC GRAPHS FOR DEPLOYMENT INSTRUCTIONS(デプロイ命令のために有向非巡回グラフを利用するための技術)」と題された米国通常出願第16/953,262号の利益および優先権を主張するものであり、あらゆる目的のためにそのすべての記載内容を引用により本明細書に援用する。
【背景技術】
【0002】
背景
今日、クラウドインフラストラクチャサービスは、クラウドインフラストラクチャサービスの多くの分野間でコードおよび設定を(それぞれ)プロビジョニングおよびデプロイするための多くの個々のサービスを利用している。特に、プロビジョニングが概して宣言的であり、コードのデプロイが命令的であることを考えると、これらのツールは、使用するためにかなりの手作業を必要とする。これに加えて、サービスチームおよびリージョンの数が増えるにつれて、クラウドインフラストラクチャサービスも成長し続ける必要がある。より多くのより小さいリージョンにデプロイするという一部のクラウドインフラストラクチャサービスの戦略として、支出をリージョンごとにする戦略があるが、うまく対応できていない。
【発明の概要】
【課題を解決するための手段】
【0003】
概要
デプロイ命令のために有向非巡回グラフを利用するための技術を開示する。いくつかの実施の形態では、コンピュータにより実現される方法は、様々な動作を含み得る。デプロイに関連する設定データの解析を実行するための命令がコンピューティングデバイスによって実行され得る。コンピューティングデバイスは、第1DAG(有向非巡回グラフ)を生成させてもよく、第1DAGは、解析に基づいて第1リソース(たとえば、ソフトウェアサービス)をデプロイするために利用される。フェーズに基づいて実行ターゲットをデプロイするための第2DAGを生成してもよく、第2DAGは、デプロイメントの実行ターゲット間の依存関係を指定する。コンピューティングデバイスは、解析に基づいて連結リストデータ構造を生成してもよく、連結リストデータ構造を横断することによってコンピューティングシステムをデプロイし得る。
【0004】
その他の実施の形態では、デプロイ命令のためにDAGを利用するためのシステムを開示する。このシステムは、1つ以上のプロセッサと、コンピュータ実行可能な命令を格納した1つ以上のメモリとを備えてもよく、コンピュータ実行可能な命令は、当該1つ以上のプロセッサによって実行されると、1つ以上のプロセッサを、様々な動作を実行するよう構成する。コンピューティングデバイスは、コンピューティングシステムのデプロイに関連する設定データの1回以上の解析を実行するための命令を実行し得る。コンピューティングデバイスは、第1DAGを生成させてもよく、第1DAGは、1回以上の解析の実行に少なくとも一部基づいて第1リソースをデプロイするために利用される。コンピューティングデバイスは、1回以上の解析の実行に少なくとも一部基づいて、複数の実行ターゲットをデプロイするための第2DAGを生成してもよく、第2DAGは、デプロイメントの実行ターゲット間の依存関係を指定する。コンピューティングデバイスは、1回以上の解析の実行に少なくとも一部基づいて、連結リストデータ構造を生成してもよく、連結リストデータ構造は、複数のデプロイフェーズ間の依存関係を指定する。そして、コンピューティングデバイスは、連結リストデータ構造、第2DAG、第1DAGを横断することに少なくとも一部基づいて、コンピューティングシステムをデプロイし得る。
【0005】
その他の実施の形態では、コンピュータ実行可能な命令を格納し得る、デプロイ命令のためにDAGを利用するためのコンピュータ読み取り可能な記憶媒体を開示する。コンピュータ実行可能な命令は、1つ以上のプロセッサによって実行されると、当該1つ以上のプロセッサに様々な動作を実行させる。コンピューティングデバイスが、コンピューティングシステムのデプロイに関連する設定データの1回以上の解析を実行するための命令を実行し得る。コンピューティングデバイスは、第1DAGを生成させてもよく、第1DAGは、1回以上の解析の実行に少なくとも一部基づいて第1リソースをデプロイするために利用される。コンピューティングデバイスは、1回以上の解析の実行に少なくとも一部基づいて、複数の実行ターゲットをデプロイするための第2DAGを生成してもよく、第2DAGは、デプロイメントの実行ターゲット間の依存関係を指定する。コンピューティングデバイスは、1回以上の解析の実行に少なくとも一部基づいて、連結リストデータ構造を生成してもよく、連結リストデータ構造は、複数のデプロイフェーズ間の依存関係を指定する。そして、コンピューティングデバイスは、連結リストデータ構造、第2DAG、第1DAGを横断することに少なくとも一部基づいて、コンピューティングシステムをデプロイし得る。
【0006】
その他の実施の形態では、装置を開示する。この装置は、本明細書に開示の方法のステップを実行するための手段を備え得る。
【0007】
その他の実施の形態では、コンピュータプログラムプロダクトを開示する。このコンピュータプログラムプロダクトは、コンピュータ命令を含んでもよい。当該コンピュータ命令は、プロセッサによって実行されると、本明細書に開示の方法のステップを実行する。
【0008】
特定の要素または動作についての説明を容易に把握できるようにするために、参照番号で表される最上位の1つまたは複数の数字は、その要素が最初に紹介される図面の番号を指す。
【図面の簡単な説明】
【0009】
【
図1】少なくとも1つの実施の形態に係る、クラウドインフラストラクチャオーケストレーションサービスの少なくとも一部の要素を実装するためのアーキテクチャのブロック図である。
【
図2】少なくとも1つの実施の形態に係る、クラウドインフラストラクチャオーケストレーションサービスの少なくとも一部の要素を実装するためのアーキテクチャのブロック図である。
【
図3】少なくとも1つの実施の形態に係る、例示的なFlockを説明するためのフロー図である。
【
図4】少なくとも1つの実施の形態に係る、例示的なFlockを説明するためのフロー図である。
【
図5】少なくとも1つの実施の形態に係る、複数のフェーズおよび複数の実行ターゲットを含むリリースに関する情報を提示するユーザーインターフェースである。
【
図6】少なくとも1つの実施の形態に係る、フェーズのリストおよび順序を定めるための例示的なコードセグメントである。
【
図7】少なくとも1つの実施の形態に係る、1つ以上のフェーズに関連するリストおよび順序を保持するためにCIOS(クラウドインフラストラクチャオーケストレーションサービス)によって生成され得る例示的なデータ構造である。
【
図8】少なくとも1つの実施の形態に係る、実行ターゲットのリストおよび順序を定めるための例示的なコードセグメントである。
【
図9】少なくとも1つの実施の形態に係る、フェーズに関連する1つ以上の実行ターゲットに関連するリストおよび順序を保持するためにCIOS(クラウドインフラストラクチャオーケストレーションサービス)によって生成され得る例示的なデータ構造である。
【
図10】少なくとも1つの実施の形態に係る、実行ターゲットのリソース間の明示的依存関係および暗黙的依存関係を構築するための例示的なコードセグメントである。
【
図11】少なくとも1つの実施の形態に係る、実行ターゲットのリソース間の明示的依存関係および暗黙的依存関係を構築するための例示的なコードセグメントである。
【
図12】少なくとも1つの実施の形態に係る、クラウドコンピューティングシステムのリソースに対応する例示的な有向非巡回グラフである。
【
図13】少なくとも1つの実施の形態に係る、少なくとも1つの能力への依存を含むタスクの実行のオーケストレーションを行うための例示的なプロセスを示すフロー図である。
【
図14】少なくとも1つの実施の形態に係る、コンピュータインフラストラクチャオーケストレーションサービスの例示的な処理の流れであり、連結リスト、実行ターゲットの有向非巡回グラフ、および能力の有向非巡回グラフを横断する。
【
図15】少なくとも1つの実施の形態に係る、コンピュータインフラストラクチャオーケストレーションサービスにある有向非巡回グラフを用いてコンピューティングシステムをデプロイするためのプロセスのフローチャートである。
【
図16】少なくとも1つの実施の形態に係る、分散システムのブロック図である。
【
図17】少なくとも1つの実施の形態に係る、システム環境の1つ以上の構成要素のブロック図であり、これらの構成要素によって、実施の形態のシステムの1つ以上の構成要素が提供するサービスが、クラウドサービスとして提供され得る。
【
図18】本開示の様々な実施の形態が実装され得る例示的なコンピュータシステムのブロック図である。
【発明を実施するための形態】
【0010】
詳細な説明
いくつかの例では、IaaS(infrastructure as a service)は、1つの特定の種類のクラウドコンピューティングである。IaaSは、仮想化されたコンピューティングリソースをパブリックネットワーク(たとえば、インターネット)で提供するように構成できる。いくつかの例では、IaaSは、クラウドコンピューティングサービスの3つの主要な分類(または、下位分類)のうちの1つである。多くの人は、それ以外の主要な分類がSaaS(Software as a Service)およびPaaS(Platform as a Service)であると考え、SaaSは、PaaSおよびIaaSの両方を含んだより広い分類とみなされる場合もあり、IaaSをPaaSの下位分類とみなす人もいるであろう。
【0011】
IaaSモデルでは、クラウドコンピューティングプロバイダは、インフラストラクチャコンポーネント(たとえば、サーバ、記憶装置、ネットワークノード(たとえば、ハードウェア)、デプロイメントソフトウェア、プラットフォーム仮想化(たとえば、ハイパーバイザ層)など)をホストできる。
【0012】
場合によっては、IaaSプロバイダは、これらのインフラストラクチャコンポーネントに付随する様々なサービス(たとえば、請求、監視、ロギング、セキュリティ、負荷分散、およびクラスタリングなど)を供給し得る。よって、これらのサービスは、ポリシー駆動型サービスであり得るので、IaaSユーザは、負荷分散を駆動するポリシーを実装して、アプリケーション可用性と、当該アプリケーションのパフォーマンスとを維持できるようになるであろう。
【0013】
場合によっては、IaaS顧客は、インターネットなどのWAN(ワイドエリアネットワーク)を通してリソースおよびサービスにアクセスしてもよく、クラウドプロバイダのサービスを利用してアプリケーションスタックの残りの要素をインストールすることができる。たとえば、ユーザは、IaaSプラットフォームにログインしてVM(仮想マシン)を作成でき、各VMにOS(オペレーティングシステム)をインストールでき、データベースなどのミドルウェアをデプロイでき、作業負荷用およびバックアップ用のストレージバケットを作成でき、さらには、そのVMにエンタープライズソフトウェアをインストールすることもできる。その後、顧客は、プロバイダのサービスを用いて、ネットワークトラフィックの負荷分散、アプリケーションの問題のトラブルシューティング、パフォーマンスの監視、ディザスタリカバリの管理などを含む、様々な機能を実行できる。
【0014】
ほとんどの場合、クラウドコンピューティングモデルは、クラウドプロバイダの参加を必要とする。クラウドプロバイダは、IaaSの提供(たとえば、販売)を専門とするサードパーティーサービスであってもよいが、そうである必要はない。また、エンティティは、プライベートクラウドをデプロイすることを選んで、独自のインフラストラクチャサービスのプロバイダになってもよい。
【0015】
いくつかの例では、IaaSデプロイメントとは、新しいアプリケーションまたは新しいバージョンを、用意したアプリケーションサーバ等の上に載せるプロセスである。また、サーバを準備する(たとえば、ライブラリ、デーモンなどをインストールする)プロセスを含んでもよい。これは、多くの場合、クラウドプロバイダによって、ハイパーバイザ層(たとえば、サーバ、ストレージ、ネットワークハードウェア、および仮想化)よりも下の層で管理される。よって、顧客は、(OS)、ミドルウェア、および/または(たとえば、(たとえば、要求に基づいてスピンアップできる)セルフサービス仮想マシンその他での)アプリケーションデプロイメントなどに対処する責任を担い得る。
【0016】
いくつかの例では、IaaSプロビジョニングとは、使用するコンピュータまたは仮想ホストを取得すること、さらには、それらの上に必要なライブラリまたはサービスをインストールすることを指し得る。ほとんどの場合、デプロイメントは、プロビジョニングを含まず、プロビジョニングが最初に行われる必要があるであろう。
【0017】
場合によっては、IaaSプロビジョニングには、2つの異なる問題がある。最初に、何かを実行するよりも先にインフラストラクチャの初期セットをプロビジョニングするという最初の課題がある。次に、すべてがプロビジョニングされると、既存のインフラストラクチャを発展させる(たとえば、新しいサービスの追加、サービスの変更、サービスの削除など)という課題がある。場合によっては、インフラストラクチャの構成を宣言的に定義できるようにすることによって、これらの2つの課題に対処するであろう。すなわち、1つ以上の設定ファイルによってインフラストラクチャ(たとえば、どのコンポーネントが必要であり、それらがどのように相互作用するか)を定義できる。よって、インフラストラクチャの全体的なトポロジー(たとえば、どのリソースがどのリソースに依存しており、それらが互いにどう作用するか)を宣言的に記述できる。場合によっては、トポロジーが定義されると、設定ファイルに記述されたそれぞれ異なるコンポーネントを作成および/または管理するワークフローを生成できる。
【0018】
いくつかの実施の形態では、IaaSプロビジョニングは、DAG(有向非巡回グラフ)を生成することを含んでもよい。DAGは、任意の適切な数のノードおよびエッジを含む有限の有向グラフであり得る。各エッジは、1つのノードから別のノードに向けられる。ノードおよびエッジは、有向閉路とならないように配置され得る。すなわち、DAGは、任意のノードから出発した後、一貫して有向な一連のエッジが最終的にその同じノードに巡回して戻ってくることのないように定められている。IaaSプロビジョニングは、システムの1つ以上のリソース(たとえば、サービス、ソフトウェアリソースなど)に対応する設定ファイルを解析することを含んでもよい。リソースごとに別個のDAGが生成され得る。リソースごとのDAGは、そのリソースの、システムの1つ以上のその他のリソース(たとえば、サービス、ソフトウェアリソースなど)の能力への依存を定め得る。たとえば、第1DAGを生成し、第1リソース(たとえば、1人以上のユーザの電子メッセージを管理するように構成されたEメールサービスなどのソフトウェアサービス、「コンピューティングサービス」とも称す)をデプロイするために利用することができる。第1DAGは、第2リソース(たとえば、以前取得したクレデンシャルに基づいてユーザのIDを検証/認証するように構成されたIDサービスなど、第1リソースとは異なる他のソフトウェアサービス)が提供する能力への第1リソースの依存を示し得る。第1リソースおよび/または第2リソースは、それぞれ、コンピューティングシステムが提供する複数のサービスのうち1つのサービスであり得る。「能力」とは、所与のリソースの機能の一部(たとえば、ユーザのIDを検証/認証するという第2リソースの能力)を指し得る。DAGを横断するためのプロセスがインスタンス化され得る。プロセスは、現在利用できない能力に対応するDAGのノードに到達した場合、プロセスが当該能力への依存に到達したので、続行する前にその特定の能力が利用可能になるのを待っているという表示を、スケジューリングサービスに公表し得る。システムの様々なリソースがデプロイおよび/または起動されると、これらのリソースは、様々な能力が利用可能になると、これらの能力が利用可能であるという表示を、スケジューリングサービスに公表し得る。本明細書において使用するとき、「起動する」、「起動している」、「起動された」という用語は、特定のリソース(たとえば、ソフトウェア/コンピューティングサービス、コンピューティングデバイスなど)に対応する動作から構成されるスタートアップシーケンスを行うプロセスを指す。リソース(たとえば、ソフトウェアサービス)をデプロイすることは、リソースが提供する機能の少なくとも一部の機能(たとえば、1つ以上の能力)を起動および/または利用可能にすることを含んでもよい。特定の能力が利用可能になったとスケジューリングサービスが判断した場合、最後に終了した地点(たとえば、能力が必要であることを公表した直後)からプロセスを再開し得る。このプロセスは、DAGを生成し直して、(たとえば、最後にアクセスされたノードから)横断を再開し得る。リソースごとにDAGを利用することによって、システムは、人間のオペレータが複雑なシステムを手動で起動させる必要がなくなるよう、それぞれ異なるリソースの能力間の依存関係を管理し得る。
【0019】
いくつかの例では、インフラストラクチャは、多くの互いに接続された要素を有し得る。たとえば、コアネットワークとしても知られている1つ以上のVPC(仮想プライベートクラウド)があってもよい(たとえば、構成可能なコンピューティングリソースおよび/または共有コンピューティングリソースのオンデマンドプールであり得る)。また、いくつかの例では、ネットワークのセキュリティがどのようにセットアップされるかを定めるためにプロビジョニングされた1つ以上のセキュリティグループのルールと、1つ以上のVM(仮想マシン)とがあってもよい。また、ロードバランサ、データベースなど、その他のインフラストラクチャ要素がプロビジョニングされ得る。より多くのインフラストラクチャ要素が要望および/または追加されると、インフラストラクチャは、漸進的に進化するであろう。
【0020】
上述したように、インフラストラクチャをプロビジョニングする1つの方法は、インフラストラクチャを宣言的に記述することである。したがって、設定ファイルは、上記のインフラストラクチャコンポーネントの各々、およびこれらがどのように相互作用するかに関して記述しているだけの宣言型ファイルであってもよい。設定ファイルは、要素を作成するために必要なリソースおよび関連性のあるフィールドを記述することができ、先に記述された要素を参照するその他の要素が記述され得る。いくつかの例では、その後、プロビジョニングツールは、設定ファイルに記述される要素を作成および管理するためのワークフローを生成し得る。
【0021】
場合によっては、プロビジョニングツールのワークフローは、様々なコマンドを実行するように構成され得る。実行できる1つの機能は、ビューリコンシリエーション(View Reconciliation)である。ビューリコンシリエーションでは、プロビジョニングツールは、現在のインフラストラクチャのビュー(たとえば、予想されるインフラストラクチャの状態)を、インフラストラクチャの実際の動作と比較することができる。場合によっては、ビューリコンシリエーション機能を実行することは、様々なリソースプロバイダまたはインフラストラクチャリソースを問い合わせて、どのリソースが実際に動作中であるのかを識別することを含んでもよい。プロビジョニングツールが実行できる別の機能は、プラン生成である。プラン生成では、プロビジョニングツールは、実際に動作しているインフラストラクチャコンポーネントを、プロビジョニングツールが望む状態の見え方(たとえば、所望の構成)と比較することができる。すなわち、プラン生成機能は、リソースを最新の期待される状態にするためにどのような変更を加える必要があるかを決定できる。場合によっては、第3の機能は、実行(たとえば、適用)機能である。実行機能では、プロビジョニングツールは、プラン生成機能によって生成されたプランを実行できる。
【0022】
一般に、プロビジョニングツールは、設定ファイルを取得し、設定ファイル内に含まれる宣言型情報を解析し、プランを実行するためにリソースがプロビジョニングされなければならない順序をプログラムで/自動的に決定するように構成され得る。たとえば、セキュリティグループのルールおよびVMが起動される前に、VPCが起動される必要がある場合、プロビジョニングツールは、この決定を行って、決定した順序での起動を、ユーザの介在なしで、および/またはその情報を設定ファイルに含む必要なしで実施できるようになる。
【0023】
場合によっては、継続的デプロイメント技術を採用して、様々な仮想コンピューティング環境間でインフラストラクチャコードをデプロイすることを可能にし得る。これに加えて、記載の技術は、これらの環境内でのインフラストラクチャ管理を可能にできる。いくつかの例では、サービスチームは、1つ以上の本番環境、多くの場合、(たとえば、様々な異なる地理的位置をまたいで、場合によっては全世界をまたいで)多くのそれぞれ異なる本番環境にデプロイすることが望まれるコードを書くことができる。しかしながら、いくつかの例では、コードがデプロイされるインフラストラクチャを最初にセットアップしなければならない。場合によっては、プロビジョニングを手動で行うことができ、リソースをプロビジョニングするためにプロビジョニングツールが利用されてもよく、および/または、インフラストラクチャがプロビジョニングされると、コードをデプロイするためにデプロイメントツールが利用され得る。
【0024】
上述したように、概して2つの異なるツールがあり、これらのツールは、ツール間で手動のオーケストレーションが行われながら、インフラストラクチャリソースのプロビジョニングおよびインフラストラクチャリソースを制御するためのコードのデプロイメントのそれぞれに対処するために利用される。しかしながら、大規模に実現すると、手動による実装では、常にずれが生じてしまう。よって、仮想インフラストラクチャのプロビジョニングおよびデプロイの両方を行うことができる自動ツールによって、仮想クラウド環境を実装するためのより効率的かつ信頼性のある技術が可能になる。
【0025】
いくつかの例では、2つのツールが用いられた場合、プロビジョニングフェーズとデプロイフェーズとの間でユーザが手動でコードに変更を加えると、問題が生じる可能性がある。本明細書に記載するように、プロビジョニングおよびデプロイの両方に対して1つのツールを使用する技術は、プロセスを自動化することによってこのような問題を軽減させることができ、コードを手動で変更する機会をなくすことができる。1人のユーザのコーディングをわずかに変更することで、デプロイフェーズで大きな問題が引き起こされてしまう可能性がある場合もあるであろう。いくつかの例では、オペレータが(たとえば、コードに入力ミスがある)新しいリージョンで初めて動作を行う時、入力ミスのあるコーディングがされたオブジェクトは、そのまま残り続ける可能性がある。その入力ミスがある状態でアプリケーションがデプロイされ、アプリケーションがその入力ミスに左右されない(たとえば、とりあえず動作する)場合、今後、追加のコード変更がその入力ミスに左右されてシステム全体をクラッシュさせてしまう可能性がある。よって、本明細書において提供する技術は、しばしば問題を招き得るプロビジョニングとデプロイメントとのギャップを、取り除くことができる。
【0026】
一般に、デプロイメントをモデル化することは、インフラストラクチャリソースを宣言するために設定ファイルを使うことができるように宣言型である。たとえば、一般的なREST(Representational State Transfer)概念(たとえば、REST API(アプリケーションプログラミングインターフェース))を用いてデプロイメントファイルを生成するために、CRUD(生成、読み取り、更新、および削除)命令が一般的に用いられる。しかしながら、デプロイメント自体は、一般に、同じ概念に従わない。これに加えて、インフラストラクチャプロビジョニングツールが非常に強力および/または表現的なツールになる傾向がある一方で、デプロイメント用のツールは、実行できる操作に関しては、はるかに限定的である傾向がある(たとえば、デプロイメント用のツールは、宣言的とは対照的に、命令的である)。よって、長い間、クラウド環境内で機能要件の両方(たとえば、インフラストラクチャ要素のプロビジョニングおよびデプロイメント)に対処できる1つのツールのニーズがある。
【0027】
いくつかの例では、CIOS(クラウドインフラストラクチャオーケストレーションサービス)を実装するための技術について説明する。これらの技術は、簡単に上述したように、クラウド環境内のインフラストラクチャのリソースのプロビジョニングおよびデプロイメントの両方を管理できるように構成できる。場合によっては、CIOSは、セントラルコンポーネントと、リージョナルコンポーネント(たとえば、CIOSセントラルおよびCIOSリージョナル)という2つのサービスクラスを含み得る。明細書全体を通して、下記の用語を用いる。
【0028】
●インフラストラクチャコンポーネント-動作中のコードをサポートするインフラストラクチャの長期部品。
【0029】
○例:デプロイメントアプリケーション、ロードバランサ、DNS(ドメインネームシステム)エントリ、オブジェクトストレージバケットなど。
【0030】
●アーティファクト-デプロイメントアプリケーションもしくはKubernetes Engineクラスタにデプロイされているコード、またはインフラストラクチャコンポーネントに適用されている設定情報(以下、「設定(config)」)。これらは、読み取り専用リソースであってもよい。
【0031】
●デプロイメントタスク-コードをデプロイまたはテストすることに関連することが多い短期タスク。これに加えて、デプロイメントタスクは、リソースとしてモデル化される。当該リソースは、リソースを作成するリリースよりも長く存在することはない。
【0032】
○例:「deploy $artifact to $environment」、「watch $alarm for 10 minutes」、「execute $testSuite」、または「wait for $manualApproval」
○たとえば、CIOSは、デプロイメントオーケストレーターのデプロイメントを、完了したときに利用可能状態に遷移するリソースの作成としてモデル化できる。
【0033】
○CIOSは、そのクラウドインフラストラクチャサービス宣言型プロビジョナーの状態を保持するため、CIOSは、これらの短期リソースのライフサイクルを、当該ライフサイクルがリリースに関連するので、制御することができる。
【0034】
●リソース-CRUD可能なリソース。
○CIOSは、リソースとして先に列挙したコンストラクトの各々をモデル化する。次のセクションでは、このモデル化について詳細を説明する。
【0035】
●Flock-制御エリアおよびすべてのコンポーネントをカプセル化するCIOSのモデル。主に、インフラストラクチャコンポーネントの所有権をモデル化する、および当該インフラストラクチャコンポーネントを指し示すために存在する。
【0036】
●Flock設定-1つのサービスに関連する一連のすべてのインフラストラクチャコンポーネント、アーティファクト、およびデプロイメントタスクについて記述する。
【0037】
○各Flockは、正確に1つのFlock設定しか有さない。Flock設定は、コントロールの出所を得るためにチェックインされる。
【0038】
○Flock設定は、宣言的である。レルム、リージョン、広告、およびアーティファクトのバージョンをCIOSが入力として提供することを要求する。
【0039】
○Flockの粒度は細かい-Flockは、1つのサービスから構成され、インフラストラクチャをサポートする。
【0040】
●状態-Flockにあるすべてのリソースの状態の現時点でのスナップショット。
●リリース-Flock設定の具体的なバージョン、およびそれが参照するすべてのアーティファクトの具体的なバージョンから構成されるタプル。
【0041】
○まだ存在していないであろう状態をリリースが記述していると考える。
●リリースプラン-すべてのリージョンを現在の状態からリリースが記述した状態に遷移させるためにCIOSがとる一連のステップ。
【0042】
○リリースプランは、有限数のステップと、明確な開始時刻および終了時刻とを有する。
【0043】
●適用-これは、名詞である。リリースプランを実行する1つの試行。実行によってFlockの現在の状態が変更される。
【0044】
CIOSを、下流システムに設定を適用(たとえば、世界規模で)するオーケストレーションレイヤーとして記述することができる。サービスチームによる手作業なしで(たとえば、場合によっては、最初の承認以降)、世界規模のインフラストラクチャのプロビジョニングおよびコードのデプロイメントを可能にするように設計されている。CIOSのレベルの高い責任として、以下を含むが、これらに限定されない。
【0045】
●インフライト変更動作を含む、CIOSが管理するリソースの現在の状態のビューをチームに提供する。
【0046】
●チームが新しい変更をプランおよびリリースすることを補助する。
●リージョン内の様々な下流システム間で動作を調整して、承認されたリリースプランを、人間の介在なしで、実行する。
【0047】
●リージョン/レルム間で動作を調整して、承認されたリリースプランを世界規模で実行する。
【0048】
いくつかの例では、CIOSは、チームがチェックイン済みコードを介して設定情報を有するCIOSを提供することを可能にすることによって、オンボーディングに対処する。これに加えて、CIOSは、その他のことを自動化できるので、以前の実装における運用よりも重要性が大きい運用である。場合によっては、CIOSは、コードを自動的にデプロイしてテストする機能をチームに提供することによって、デプロイメント前に対処する。場合によっては、CIOSは、チームが新しいアーティファクトを構築した場合に、これらのアーティファクトを(たとえば、世界中に)ロールアウトするためのプランを自動生成することを可能にすることによって、CM(変更管理)ポリシーの書き込みに対処できる。これは、各リージョンの現在の状態と、現在のCIOS設定(これ自体がアーティファクトであり得る)とを検査することによってできる。これに加えて、チームは、これらのプランを検査することができ、CIOS設定を変更することおよびCIOSにプランを作り直すよう要求することによって、これらのプランを繰り返し得る。プランに納得すると、チームは、プランを参照する「リリース」を作成できる。その後、プランを採点して承認または拒否を判断できる。チームは引き続きCMを書き込むことができるが、これらはCIOSプランへのポインターに過ぎない。よって、チームは、プランについて考えるのに費やす時間を減らすことができる。プランはマシン生成されるので、精度は向上する。プランは、人が理解するには詳細すぎるが、高度なUI(ユーザーインターフェース)を介して表示できる。
【0049】
いくつかの例では、CIOSは、デプロイメントプランを自動的に実行することによって、CMの実行に対処できる。リリースプランが作成および承認されると、エンジニアは、CIOSがロールバックを開始しない限り、CMにこれ以上参加しなくなる。これにより、場合によっては、チームは、現在手動のタスクを自動化する必要がある場合がある。いくつかの例では、CIOSは、動作中にサービスヘルスの低下を検出するとFlockを元の(たとえば、プレリリース)状態に戻すプランを自動生成することによって、CM(変更管理)のロールバックに対処できる。いくつかの例では、CIOSは、リージョンのサブセットおよび/またはCIOSが管理するリソースのサブセットに範囲が限定されるリリースプランを受信してからプランを実行することによって、突然の変更/戦略的変更をデプロイすることに対処できる。
【0050】
これに加えて、CIOSは、全自動の世界規模のデプロイメントを定めるために必要なプリミティブをサポートし得る。たとえば、CIOSは、アラームを監視すること、および統合テストを実行することによってサービスヘルスを測定できる。CIOSは、サービスが低下したときにチームがロールバックの挙動を速やかに定めることを補助でき、その後、それを自動的に実行させることができる。CIOSは、リリースプランを自動的に生成および表示することができ、承認を追跡できる。場合によっては、所望のデプロイメントの挙動を記述するためにチームが使用する言語は、宣言的であってもよい。CIOSは、コードデプロイメントの機能とインフラストラクチャ設定(たとえば、プロビジョニング)とを組み合わせて1つのシステムにすることができる。また、CIOSは、リージョン間、およびリージョン内のコンポーネント間の柔軟な順序付けをサポートする。チームは、チェックイン済みの設定を介して順序付けを示し得る。チームは、CIOSのプランニングAPIおよびリリースAPIをプログラムで呼び出し得る。
【0051】
図1は、少なくともCIOSセントラル102を実装するための技術を説明するためのアーキテクチャ100を示す。いくつかの例では、CIOSセントラル102は、「Flock」レベルの動作に対処するサービスであってもよい。CIOSセントラル102には、以下に示すいくつかの責任があるが、これらに限定されない。
【0052】
●Flockのメタデータの変更およびリリース操作のための認証ゲートウェイとしての責任を担う。
【0053】
●Flockのメタデータの信頼できるマッピングを、デプロイメントアーティファクトおよびFlockのCIOSリポジトリに格納する。
【0054】
●フェーズおよびターゲット間での世界規模リリースを調整する。
●「Flockへの進行中のリリースは、一度に1回まで」のようなポリシーを実施するための同期。
【0055】
●Flock設定およびアーティファクトに対する変更を検知し、変更に応じてリリースの生成をトリガする。
【0056】
いくつかの例では、信頼できるFlock設定を格納するようにSCVMS(ソースコードバージョン制御/管理サービス)104を構成でき、CIOSセントラル102がANS(アーティファクト通知サービス)106へのサブスクリプションを行うことができ、CIOSセントラル102は、新しいアーティファクトの構築について通知されるようになる。その後、CIOSセントラル102は、影響を受けたFlockに届く変更をマッピングし、必要であれば、リリースプランニングを開始できる。これに加えて、いくつかの例では、ターゲットへのリリースよりも前にAPS(アーティファクトプッシュサービス)をCIOSセントラル102によって呼び出すことができ、正常なリリースに必要なアーティファクトのすべてがリリースよりも前にターゲットのリージョンにおいて提示されることを確実にする。
【0057】
いくつかの例では、顧客(たとえば、エンジニア)108は、CRUDのFlockおよび/またはリリースにCIOSセントラル102を呼び出して、進行中のCIOSアクティビティのステータスを見ることができる。Flock管理サービス110は、Flockを操作するための1つ以上のAPIを含むことができ、ビュー/プラン/承認サービス112は、プランを作成および承認するためのCRUD API、CIOSが管理するリソースのすべての状態のセントラルコピーを見るためのCRUD APIを含むことができ、変更監視サービス114は、SCVMS104をウォッチして、Flock設定に加えられた変更を確認でき、ANS106からのその他のアーティファクトに加えられた変更についての通知を受信でき、状態Ingesterサービス116は、ビュー/プラン/承認112が公開できるよう、CIOSセントラルDB(データベース)118にリージョナル状態のコピーを作成できる。いくつかの例では、CIOSセントラルDB118は、Flock、プラン、および状態のDBであり得る。Flock情報は、信頼できる情報であり得る一方、その他は、CIOSリージョナル120からのデータの古いコピーであってもよい。CIOSセントラル102は、Flock、リリース、インフラストラクチャコンポーネント、アーティファクトなどに関する任意の適切なデータを提示するためのユーザーインターフェース(たとえば、ユーザーインターフェース500~1300)の任意の適切な部分および/または任意の数の当該ユーザーインターフェースを提供するように構成され得る。いくつかの実施の形態では、CIOSセントラル102は、1つ以上のリリースに関するデータを、任意の適切なインターフェースを介して提示し得る。リリースは、1つ以上のインフラストラクチャコンポーネントに関するタスクの任意の適切な組合せおよび/または1つ以上のアプリケーション(たとえば、アーティファクト)に対する1つ以上のコードの変更を含んでもよい。CIOSセントラル102が提供するユーザーインターフェースのいくつかの例について、
図5~
図13で後述する。
【0058】
いくつかの例では、エンジニア108は、(たとえば、イングレスプロキシフリート122を通して)Flock管理サービス110のAPI呼び出しを実行し、Flockのリストを作成できる。このようなAPI呼び出しを行うプロトコルは、HTTPS(ハイパーテキストトランスポートプロトコルセキュア)などであってもよい。この操作のための関連性のあるACL(アクセス制御リスト)は、LAN(ローカルエリアネットワーク)124またはその他のプライベート接続を含んでもよい。たとえば、CIOSは、顧客のオンプレミスデータセンターまたはネットワークをCIOSと接続するためのパブリックインターネット(たとえば、専用接続、リース接続、および/またはプライベート接続)を利用することに代えて、ネットワーク接続性を管理/制御し得る。これに加えて、ユーザがマシンインフラストラクチャ(たとえば、リザベーションサービス)を管理することを可能にするリザベーションシステムポータルによって、(たとえば、エンジニア108の)認証および認可を行ってもよい。場合によっては、CIOSセントラル102は、JDBC(Java Database Connectivity)などを利用して、Flockのメタデータ、プラン、および状態をセントラルDB118に格納できる。いくつかの例では、ANS106は、新しいアーティファクトが公表されると、変更監視サービス114に通知するように構成できる。ANS106は、HTTPSを利用してもよく、認証と認可の両方が相互トランスポート層セキュリティサービスによって対処され得る。これに加えて、場合によっては、変更監視サービス114は、Flock設定の変更についてSCVMS104にポーリングを行うことができる。このポーリングは、SSH(セキュアシェル)またはその他のプロトコルを利用して行うことができる。変更監視サービス114の認証は、CIOSシステムアカウントによって対処されてもよく、認可は、SCVMS104によって対処され得る。
【0059】
いくつかの例では、エンジニア108は、ビュー/プラン/承認サービス112を用いて、次の動作のうち1つ以上を行うことができる。エンジニア108は、CIOSセントラル102を呼び出してプランを生成および承認することによって、プランおよび/または承認を行うことができる。エンジニア108は、CIOSセントラル102を呼び出すことによって、進行中の世界規模のCIOSの動作のステータスを見ることができる。これに加えて、エンジニア108は、CIOSセントラル102を呼び出して、CIOSが管理する世界規模のリソースの状態の写しを見ることができる。HTTPSプロトコルまたは同様のプロトコルを介してこれらのAPI呼び出し(または同様のもの)を行うことができる。これに加えて、LAN124によって関連性のあるACLを制御でき、認証と認可の両方は、リザベーションサービスによって対処できる。いくつかの例では、ビュー/プラン/承認サービス112は、プランニングを要求し、(たとえば、HTTPSなどを用いて)CIOSリージョナル120のすべてのリージョンに対してプランの承認を推進することができる。関連性のあるACLは、WAN(ワイドエリアネットワーク)ゲートウェイ126が管理するセキュリティリストを用いて制御できる。認証は、相互トランスポート層セキュリティによって対処でき、認可は、様々なIDポリシーによって対処できる。さらには、状態Ingesterサービス116は、CIOSリージョナル120をウォッチして、ジョブステータスまたは状態の変更を確認でき、CIOSは、(たとえば、HTTPSも用いるなどして)これらのセントラルビューを要求に応じて提供できる。また、これについてのACLSも、WANゲートウェイ126によって対処でき、認証と認可の両方は、相互トランスポート層セキュリティサービスによって対処できる。
【0060】
図2は、少なくともCIOSリージョナル202を実装するための技術を説明するためのアーキテクチャ200を示す図である。いくつかの例では、CIOSリージョナル202において、宣言型プロビジョニングおよびプランニング、ならびに承認されたリリースアプリケーションの作業の多くが生じ得る。場合によっては、CIOSリージョナル202の各インスタンスは、「実行ターゲット」レベルの動作に対処できるリージョナルフロントエンドを有し得る。下記の動作を行うように構成できる。
【0061】
●CIOSセントラル102から受信する操作に関するCIOS認証のすべてに対処する。
【0062】
●所与の実行ターゲットについて、一度に1つの「実行」(リソースを計画/インポートする/プランを適用する)のみが進行中であってもよいというルールを実施する。
【0063】
●宣言型インフラストラクチャプロビジョニングの実行中の入力および出力に用いられる宣言型プロビジョニングのアーティファクトのためのバイナリアーティファクトの格納を管理する。入力の例として、宣言型インフラストラクチャプロビジョニング設定ファイルおよび入力状態ファイルなどがある。通常出力は、最終状態ファイルである。
【0064】
●所与の実行についてCIOSエクスキューターに作業を要求し、かつ、結果をCIOSエクスキューターからポーリングする。
【0065】
場合によっては、CIOSフロントエンドは、実際の実行に対処できるCIOSエクスキューター206(本明細書において「スケジューラー」とも称す)に依存し得る。CIOSエクスキューターは、いくつかの例では、「実行」レベルで動作し、以下の動作を行うことができる。
【0066】
●利用可能なワーカーノードのプールを追跡する。
●受信するジョブ要求を問い合わせて、適格なワーカーが利用可能になると、これらの要求を割り当てる。
【0067】
●ワーカーのステータス、およびクライアントに報告するための実行の更新を追跡する。
【0068】
●リーシングプロトコルを介してデッドノードを検出し、タスクのステータスに応じて、デッドノードに割り当てられたタスクの機能を停止させることができる。
【0069】
●実行をキャンセル/強制終了/一旦停止/再開するためのファシリティを提供し、これらをファシリティにマッピングしてワーカーノードにキャンセル/強制終了/再開情報を渡すことができる。
【0070】
場合によっては、CIOSエクスキューターは、ワーカーに実行するタスクを割り当てることができるCIOSワーカーに依存してもよく、ワーカーがジョブの進行を更新できるようにするファシリティを提供できる。ワーカーサービスは、「タスク」の粒度で動作する。各ワーカーは、そのワーカーに割り当てられたタスクを実行し、タスクのステータスおよび出力を報告するエージェントである。各ワーカーは、以下の動作を行うことができる。
【0071】
●割り当てられた作業項目についてエクスキューターワーカーAPIをポーリングし、割り当てた状態を、そのローカル状態に一致させるための動作を行う。
【0072】
○ローカルで存在しないタスク項目をポーリングするためのコンテナを開始する。
○割り当てられた対応するタスク項目を有さないコンテナをローカルで実行するためのコンテナを、強制終了する。
【0073】
●ジョブのステータスを報告する。
●ジョブコンテナの実行のためのステージ入出力。
【0074】
●実行ターゲットのためのリリースの実際の作業を行うための宣言型インフラストラクチャプロビジョニングコンテナを起動および監視する。
【0075】
CIOSワーカーは、CIOSエクスキューターに依存して、CIOSエクスキューターのワーカーエンドポイントからワークをポーリングしてもよく、CIOSエクスキューターのワーカーエンドポイントに結果を報告し得る。ワーカーは、すべての調整についてエクスキューターに依存し得る。また、これに加えて、CIOSワーカーは、CIOSリージョナル202に依存し得る。CIOSリージョナル202では、ワーカーサービスがリージョナルフロントエンドサービスに関連する1つ以上のAPIからの入力を読み出して当該APIに出力を書き出す。入力の例として、設定ファイルおよび開始状態ファイルならびにインポートマッピングなどがある。出力の例として、宣言型プロビジョニングプロセス、宣言型プロビジョニング状態ファイルの出力、および結果状態のインポートなどがある。
【0076】
いくつかの例では、CIOSリージョナル202は、CIOSのリージョナルインスタンス/デプロイメントを管理するためのリージョナルサービスであってもよい。CIOSリージョナル202は、プラン、および特定のリージョンに関連する状態を、権限を持って格納および管理する責任をカバーする。リージョナルDB204は、特定のリージョンにおける状態およびプランについてのCIOS DBであってもよい。これは、
図1のセントラルDB118のリージョンのサブセットの、信頼できるコピーである。スケジューラー206は、ワーカーのフリート容量を管理する責任、ワーカーにタスクを割り当てる責任、およびタスクの状態を追跡する責任を担うことができる。場合によっては、タスクDB208は、タスクの状態についての別のCIOS DBである。このDBにあるデータは、ほとんどの場合、運用上のデータである。これに加えて、ワーカー210は、宣言型プロビジョニング画像を管理するJVM(Java(登録商標)仮想マシン)のフリートであってもよい。これらは、スケジューラー206から命令を受信し、スケジューラー206およびCIOSリージョナル202の両方に結果を通信する。CIOSコンテナ212は、宣言型プロビジョニング操作を自身のプライベートDocker214コンテナで実行できる。このコンテナは、シークレットを含む必要はない。これに加えて、いくつかの例では、宣言型プロビジョニング画像にシークレットが入れられるのを回避するために、署名プロキシ216は、宣言型プロビジョニングツールを経由してシークレットが流出することを防ぐように構成できる。その代わりに、CIOSは、要求署名を実行できる、またはプロキシでmTLS(相互トランスポート層セキュリティ)サービスを始動させることができる。また、これにより、FIPSに準拠した暗号ライブラリの利用が容易になる。
【0077】
いくつかの例では、CIOSセントラル102は、CIOSリージョナル202を呼び出して、プランを作成、承認を推進する、ジョブステータス(サービスプリンシパル)をウォッチする、および宣言型プロビジョナー状態(サービスプリンシパル)を抽出することができる。イングレスプロキシ218をACLとして構成することができ、認証および認可のために様々なIDポリシーが使用され得る。これに代えて、いくつかの例では、イングレスプロキシ218を、送信されてくる要求、プランなどの負荷を分散させるように構成されたロードバランサに置き換えてもよい。場合によっては、CIOSリージョナル202は、スケジューラー206に宣言型プロビジョナーを実行するよう依頼して当該実行を行ってもよい。ワーカー210は、動作しているべきものが何なのかについて、スケジューラー206に確認をとることができ、完了時に、スケジューラー206にステータスを報告できる。場合によっては、mTLSは、CIOSリージョナル202およびワーカー210の認証と認可の両方に対処し得る。これに加えて、宣言型プロビジョナーを実行する必要がある場合、ワーカー210は、ローカルDocker214とやり取りすることによってDockerコンテナ内で当該実行を行う。この段階の認証は、ローカルのUnix(登録商標)ソケットが対処し得る。この最後にステップにDockerプロトコルを用いてもよいが、それまでのステップにはHTTPSが利用され得る。
【0078】
いくつかの実施の形態では、CIOSリージョナル202は、Flock、リリース、インフラストラクチャコンポーネント、アーティファクトなどに関する任意の適切なデータを提示するためのユーザーインターフェース(たとえば、ユーザーインターフェース500~1300)の任意の適切な部分および/または任意の数の当該ユーザーインターフェースを提供するように構成され得る。いくつかの実施の形態では、CIOSリージョナル202は、1つ以上のリリースに関するデータを、任意の適切なインターフェースを介して提示し得る。リリースには、1つ以上のインフラストラクチャコンポーネントに関するタスクの任意の適切な組合せ、および/または1つ以上のアプリケーション(たとえば、アーティファクト)に対する1つ以上のコード変更が含まれ得る。CIOSリージョナル202が提供するユーザーインターフェースのいくつかの例について、
図5~
図13で後述する。
【0079】
いくつかの例では、CIOSコンテナ212は、宣言型プロビジョナーが、署名プロキシ216が様々なCIOSサービスを呼び出していると考えている間に、宣言型プロビジョナーが署名プロキシ216と(APIを介して)やり取りすることを可能にする。署名プロキシ216は、宣言型プロビジョナーのみが知っているその宣言型プロビジョナーの呼び出しインスタンスごとに、1つのエフェメラルポートを待ち受ける。署名プロキシ216は、シグネチャまたはmTLSの要求を開始することができ、宣言型プロビジョナーの呼び出しをサービスエンクレーブ内のその他のCIOSサービスに渡すことができる。また、場合によっては、署名プロキシ216は、1つ以上のパブリックCIOSサービス220と通信できる。たとえば、署名プロキシ216は、パブリックサービスの内部エンドポイントを、可能な場合、利用する。内部エンドポイントを有さないサービスの場合、外部エンドポイントに到達するためにエグレスプロキシ222を利用しなければならない。この署名プロキシ216の利用は、リージョン間通信のためでなくてもよく、たとえば、各リージョンにあるエグレスプロキシホワイトリストは、そのリージョンのパブリックIPの範囲に対してのみ、ホワイトリストであってもよい。いくつかの例では、ワーカー210は、その後、CIOSリージョナル202にある宣言型プロビジョナーからの状態およびログを、これらがCIOSセントラル102に流出されるよう、保持し得る。
【0080】
CIOSを利用した場合、オンボーディング、プレリリース、世界規模のリリース、および戦略的リリースという代表的なカスタマーエクスペリエンスの4つのフェーズがある。プレリリースフェーズの場合、構築される新しいアーティファクトとリリース1(たとえば、R1)にリリースされるアーティファクトとの間に生じる出来事の例として、以下がある。これにより、現在の変更管理プロセスの一部またはほとんどが置き換えられることになる。関連性のあるアーティファクトが構築されると、CIOSは、「Flockにあるすべての最新バージョン」を用いて、リリースを自動的に生成できる。リリースは、具体的な入力(たとえば、アーティファクトのバージョン、レルム、リージョン、および広告)があるFlock設定の具体的なバージョンである。リリースは、リージョン当たり1つのロールフォワードプランと、リージョンの順序付けを記述したメタデータとを含む。各リージョナルプランは、そのリージョンにあるFlock設定を実現するために宣言型プロビジョナーが行い得る一連の動作である。プレリリース環境を有するチームは、CIOSを用いて、当該環境でソフトウェアを自動的にリリースおよびテストすることができる。チームは、ロールバックプランを自動的にテストするようCIOSを構成できる。チームは、CIOS UIを通じて、リリースを検査および承認できるようになる。チームは、リリース内のリージョナルプランのすべてではなく、その一部を承認できる。「すべての最新バージョン」によって適したプランがもたらされなかった場合、チームは、厳選されたアーティファクトのバージョンのためのプランを生成するよう、CIOSに要求できる。
【0081】
世界規模リリースフェーズの場合、今日の「通常CM」の明日のバージョンをチームがどのように実行するかについての例として、以下がある。リリースが承認されると、CIOSは、承認されたリージョナルプランをそれぞれのリージョンに推進する。CIOSは、各リージョン内で単独で動作して、承認されたプランを適用する。CIOSは、そのリージョンのプランで明示的に記述された一連の動作のみを行う。「独自に考える」のではなく、機能しなくなる。CIOS UIは、チームに実行の進行状況を表示する。手作業による承認が必要である場合、CIOS UIは、チームにプロンプトを表示する。CIOSまたは下流サービスにおける機能停止のせいで実行が失敗すると、CIOSは、チームに通知を行うことができ、次のステップ(たとえば、中止、再試行)についてのプロンプトを表示できる。CIOSは再試行を行うが、下流システムにおける機能停止が再試行する意欲を上回ってしまう。サービスヘルスの低下またはテスト失敗のせいで実行が失敗した場合、CIOSは、チームがFlockをその開始状態にロールバックするのを補助する。CIOSは、自動ロールバックを開始するときをチームに通知(たとえば、呼出)する。チームは、は、このロールバックプランを承認しなければならず、その後、CIOSがこれを実行する。
【0082】
戦略的リリースフェーズの場合、明日のバージョンの「新たなCM」をチームがどのように実行するかについての例として、以下がある。プランを生成する際、チームは、CIOSに、いくつかの方法(トポロジカルに(たとえば、レルム、リージョン、広告など)、リソースタイプ(たとえば、「メトリック設定のみ」もしくは「デプロイメントオーケストレーションサービスのデプロイメントのみ」など)ごとに、または上記の組合せ(たとえば、分離させて)で)で特定のリソースにおけるプランを対象にするよう要求し得る。チームは、世界規模リリースと同じように戦略的リリースを承認する。CIOSは、同様に戦略的リリースのオーケストレーションを行う。有効な世界規模リリースがあるにも関わらず、チームが戦略的リリースをデプロイする必要がある場合、CIOSは、ターゲットのリージョンにある世界規模リリースの実行を中止してから、戦略的リリースの実行を開始する。
【0083】
いくつかの例では、宣言型プロビジョナーの状態(たとえば、通常、ファイル)は、宣言型プロビジョナーが管理する一連のリソースの信頼できるレコードである。これには、設定ファイルからの各リソースの論理的な識別子と、リソースの実際の識別子とのマッピングが含まれている。宣言型プロビジョナーがリソースを作成する際、特定の種類の障害より、実際の識別子が状態に記録されなくなる。これは、実際の識別子がもはや宣言型プロビジョナーのものではなくなった場合に起こる。これらは、「孤立リソース」と呼ばれ得る。
【0084】
ほとんどのリソースにとって、孤立は、ゴミを表す。宣言型プロビジョナーは、忘れていた(たとえば)インスタンスを起動するが、次回それが実行されるのではなく、宣言型プロビジョナーは、別のインスタンスを起動する。一意性制約またはクライアントが提供した識別子を有するリソースの場合、孤立により、宣言型プロビジョナーは、進行を前に進めることができなくなる。たとえば、宣言型プロビジョナーが「nglass」というユーザを作成し、失敗によってこれが孤立した場合、宣言型プロビジョナーの次の実行では、「nglass」を作成しようとするが、そのユーザ名を有するユーザが既に存在しているので、作成は失敗する。場合によっては、孤立は、新しいリソースを状態に追加する際にのみ問題となる。場合によっては、宣言型プロビジョナーの更新動作は、更新および削除の記録の失敗から自然に回復し得る。
【0085】
CIOSは、下流サービスの機能停止またはCIOS自体の機能停止の際にロバスト性がなければならない。CIOSは、宣言型プロビジョナーを利用して変更を適用することができるので、宣言型プロビジョナーを実行するおよび宣言型プロビジョナー状態を保持する事に関してロバスト性があると言えるであろう。宣言型プロビジョナープロバイダは、数分間継続する機能停止を回避するには十分な「小規模の」再試行を実行する。たとえば、クラウドプロバイダは、最大で30分間再試行を行う。下流システムの機能停止が30分よりも長く続くと、宣言型プロビジョナーは機能しなくなる。宣言型プロビジョナーは、機能しなくなると、正常時に行ったすべての変更を状態に記録してから終了する。再試行のために、CIOSは、宣言型プロビジョナーを再実行しなければならない。また、宣言型プロビジョナーを再実行することで、CIOS自体に障害が発生した場合に、CIOSを再試行できるようになる。場合によっては、CIOSは、次の動作をループ実行できる。
【0086】
●更新-宣言型プロビジョナーは、GET APIを呼び出して、状態に記述されたすべてのリソースの最近のスナップショットを検索する。
【0087】
●プラン-最近更新された現在の状態を考慮して、宣言型プロビジョナーが所望の状態を実現できるプラン(一連の具体的なAPI呼び出し)を生成する。
【0088】
●適用-宣言型プロビジョナーがプランに含まれる一連のステップを実行する。
CIOSは、宣言型プロビジョナーを実行しているとき、これらのステップの3つすべてを常に実行し得る。更新操作は、記録されなかった更新または削除からの回復を補助する。CIOSは、プランを実施した結果を検査し、承認されたリリースプランと比較する。承認されたリリースプランには含まれていなかった動作が新しく生成されたプランに含まれていた場合、CIOSは機能しなくなり得、サービスチームに通知し得る。
【0089】
図3は、例示的なFlock302を説明するためのDAG(有向非巡回グラフ)300を示す。最初のテスト環境のデプロイメントから最後の本番環境のデプロイメントまで、CIOSにある1つのFlock設定についてのチェックインから制作までのコード/設定の進行が記述され得る。内部的には、CIOSは、ET(実行ターゲット)の進行において各要素を呼び出す。これは、内部APIの至る所で存在するが、Flock設定にはリークしない。CIOSは、Flock設定で定められたDAG200に基づいてETを実行する。各ET(たとえば、ET-1、ET-2、ET-3、ET-4、ET-5、ET-6、およびET-7)は、概して、Flock設定が記述したサービスの1つのコピーである。
【0090】
図4は、例示的なFlock402を説明するためのDAG400である。Flock設定では、CIOSは、チームがこの進行状況をどのように表現するかについて非常に独断的である。チームは、クラウドインフラストラクチャのテナンシおよびリージョンを用いて進行をモデル化しなければならない。チームは、レルムを用いて進行をモデル化するべきではない。CIOSは、チームがレルム内の多くのテナンシおよびテナンシ内の多くのリージョンを利用することを許可している。しかしながら、CIOSは、チームが1つのテナンシ内で同じリージョンを2回使用するのを禁止している(しかし、それぞれ異なるテナンシにある1つのレルム内で同じリージョンを2回使用し得る)。DAG400は、テナンシおよびリージョンを用いて表された
図3のDAG300の一種を示す。この実施例は、プレ本番環境のETが本番環境リージョンにある、オーバーレイサービスについての実施例である。サービスエンクレーブサービスリリース1には、不安定なテナンシおよび安定したテナンシがある。DAG400では、IADは、ワシントンDCにあるダレス空港の地方空港コードであり、YYZは、オンタリオ州にあるトロントの地方空港コードであり、PHX、LHR、およびFRAは、それぞれフェニックス、ロンドン、およびフランクフルトの地方空港コードであり、LUFおよびLFIは、2つの異なる空軍基地の空港コードである。
【0091】
一実施の形態において、CIOSおよび/または本明細書に記載のその他の技術は、Terraform(宣言型プロビジョニングツール)、Tanden(コード生成ツール)、およびODO(Oracle Deployment Orchestrator)の各々の改良版である。これに加えて、いくつかの例では、CIOSおよび/または本明細書に記載のその他の技術は、Terraform、Tanden、およびODOツールのうち少なくとも一部を用いて実装できる。
【0092】
図5は、少なくとも1つの実施の形態に係る、複数のフェーズおよび複数の実行ターゲットを含むリリースに関する情報を提示するUI(ユーザーインターフェース)500である。UI500は、フェーズエリア502と、実行ターゲットエリア504とを含んでもよい。フェーズエリア502は、フェーズ506(たとえば、「R_n」)、フェーズ507(たとえば、「R_s」)、フェーズ508、(たとえば、「R_e」)、およびフェーズ509(たとえば、「R_w」)など、フェーズの順序付きリストを示し得る。いくつかの実施の形態では、左から右へのフェーズの順序が表示され得る。ここで、左端のフェーズは、右側にあるフェーズが完了する前に完了し、そして、当該右側にあるフェーズは、右側にあるフェーズよりも前に完了する、以下同様である。いくつかの実施の形態では、フェーズの順序付きリストは、連結リストなど任意の適切なデータ構造に格納され得る。例示的な連結リストについては、
図7でさらに詳細を後述する。
【0093】
各フェーズは、複数のタスク(たとえば、1つ以上の実行ターゲットの1つ以上のインフラストラクチャリソースをデプロイすることを含む複数のタスク)に対応付けられ得る。UI500に示されているフェーズのリストは4つのフェーズを含むが、フェーズエリア502には、1つ以上の実行ターゲットにおいてインフラストラクチャリソースをデプロイするための任意の適切な数のフェーズが含まれ得る。いくつかの実施の形態では、フェーズエリア502内に提示されているフェーズの順序付きリストは、横方向にスクロール可能であってもよい。フェーズエリア502は、フェーズ数510、ステータス511、完了した実行ターゲットの数および/または実行ターゲットの数513、およびFlock設定識別子514を示し得る。フェーズ数510は、連結リストに含まれるフェーズの数を示し得、ステータス511は、リリースのステータスを示し得る。
図5に示すように、ステータス511は、「適用中」を示し得るが、ステータス511は、任意の適切なステータスインジケーター(たとえば、「開始前」、「完了」、「失敗」など)であってもよい。
図5に示すように、完了した実行ターゲットの数および/または実行ターゲットの数513は、実行ターゲットについて、トータルで57個の実行ターゲットのうち24個のデプロイメントが完了したことを示す。完了した実行ターゲットの数および/または実行ターゲットの数512は、任意の適切な方法でUI500上に提示され得る。Flock設定識別子514は、UI500上に「13380fb2832」と提示されるが、Flock設定514は、
図5に示すリリースに対応するFlock設定ファイルの一意の識別子を伝えるための任意の適切な方法でUI500上に提示され得る。
【0094】
フェーズに対応する各サブエリアは、フェーズ識別子(たとえば、フェーズ識別子516)、トータル実行ターゲット数インジケーター(たとえば、トータル実行ターゲット数インジケーター518)、タイムスタンプ情報(たとえば、タイムスタンプ情報520、実行ターゲットトラッカーエリア(たとえば、実行ターゲットトラッカーエリア522)、およびフェーズに関するその他の適した情報を含んでもよい。たとえば、識別子516(たとえば、「R_s」)は、フェーズを一意に識別するための任意の適切な英数字文字列であってもよい。いくつかの実施の形態では、識別子516に隣接してトータル実行ターゲット数インジケーター518が提示され得る。トータル実行ターゲット数インジケーター518は、所与のフェーズに関連する実行ターゲットの総数(たとえば、14)を示す。
【0095】
タイムスタンプ情報520は、フェーズが開始した時刻および/または完了した時刻にそれぞれ関連する開始時刻および/または終了時刻を含んでもよい。いくつかの実施の形態では、タイムスタンプ情報520は、対応するフェーズのステータスを示すための任意の適切なインジケーター(たとえば、「開始前」、「失敗」、「完了」など)を含んでもよい。いくつかの実施の形態では、フェーズエリア502に、フェーズに関する任意の適切な情報が示され得る。各フェーズに関する情報を同様に提示してもよく、フェーズ情報の提示は、異なったフォーマットであってもよく、および/または、
図5に示す情報よりも多いもしくは少ない情報を含んでもよい。
【0096】
実行ターゲットトラッカーエリア(たとえば、フェーズ506の実行ターゲットトラッカーエリア522)は、各フェーズ内に提示され得る。各フェーズの実行ターゲットトラッカーエリアは、1つ以上の実行ターゲットインジケーター(たとえば、実行ターゲットインジケーター524、526、および528)を含んでもよい。各実行ターゲットインジケーターは、同時に実行されるタスク(たとえば、対応する実行ターゲットへのデプロイメント)の数を示す数字を含んでもよい。一例として、実行ターゲットインジケーター524は、特定の実行ターゲットへのデプロイメントが実行され得ると示している。実行ターゲットインジケーター526およびそれが実行ターゲットインジケーター524の右側に配置されていることは、実行ターゲットインジケーター524に対応する第1タスクの完了後、異なる実行ターゲットへの別のデプロイメントが実行されることを示す。実行ターゲットインジケーター528およびそれが実行ターゲットインジケーター526の右側に配置されていることは、実行ターゲットインジケーター524に対応する第2タスクの完了後、12個の異なる実行ターゲットへの12個の別個のデプロイメントが実行されることを示す。実行ターゲットインジケーター524、526、および528の組合せは、まとめて、有向非巡回グラフ(たとえば、
図9で後述するDAG900)を折りたたんだ形を示している。
【0097】
いくつかの実施の形態では、実行ターゲットインジケーター524~528は、フェーズに関連する実行ターゲットのリスト、およびタスク(たとえば、各実行ターゲットへのデプロイメント)が実行される順序を保持するように構成されたデータ構造に対応し得る。このリストおよび順序を保持するための例示的なデータ構造の詳細については、
図9に関連して後述する。各実行ターゲットインジケーターは、リング(たとえば、リング530)を含んでもよい。リングは、実行ターゲットインジケーターに関連する実行ターゲットの数に対応する任意の適切な数の部分に分割され得る。図示した例では、リング530は、12個の均等な部分に分割され得る。リング530の各部分は、特定の実行ターゲットに対応してもよく、その特定の実行ターゲットに対応するタスクのステータスに相当する色で色付けされ得る。一例として、リング530は、実行ターゲットに対する9個のデプロイメントが完了したことを(たとえば、9つの緑色部分によって)示し得る。リング530の残りの3つの部分(たとえば、白く色付けされている)は、3つの実行ターゲットに対応する3つのタスクがまだ開始されていないことを示し得る。別の例として、リング530の残りの3つの部分は、異なる色(たとえば、黄色)で色付けされてもよく、対応するタスクが開始したが、まだ完了していないことを示す。よって、リング530を見ることによって、ユーザは、実行ターゲットインジケーター528に関連するタスクの現在のステータスを速やかに視覚的に識別できる。実行ターゲットトラッカーエリア522内の実行ターゲットインジケーターを見ることによって、ユーザは、11個の実行ターゲットへのデプロイメントが完了しており、3つが進行中であることを把握できる。いくつかの実施の形態では、各実行ターゲットインジケーターは、所与のフェーズ(たとえば、「R_s」)に関連するDAG(有向非巡回グラフ)(たとえば、
図9のDAG900)のノードに対応し得る。
【0098】
実行ターゲットエリア504は、実行ターゲットカラム532と、進行カラム534と、操作カラム536とを含んでもよい。実行ターゲットカラム532は、所与のフェーズ(たとえば、図示のとおり、フェーズ506)に関連して実行されたタスク(たとえば、デプロイメント)に対応するターゲット(たとえば、実行ターゲット)のリストを含んでもよい。いくつかの実施の形態では、実行ターゲットカラム532は、時系列で格納されてもよく、タスク実行を格納するためのその他の適した方法で格納され得る。進行カラム534は、各実行ターゲットに対応するステータス(たとえば、「正常終了」、「開始前」、「進行中」など)を示す進行インジケーターのリストを含んでもよい。操作カラム536は、実行ターゲットカラム532に示す実行ターゲットに関して実行される操作のリストを含んでもよい。たとえば、操作カラム536に含まれている操作のリストは、CRUD(生成、読み取り、更新、および削除)操作などを含んでもよい。
【0099】
図6は、少なくとも1つの実施の形態に係る、フェーズのリストおよび順序を定めるための例示的なコードセグメント600である。
図6に示すように、コードセグメント600には、4つのフェーズが定められている。各フェーズは、「フェーズ」というタイプのリソースとして定められており、識別子(たとえば、「R_n」、「R_s」、「R_e」、および「R_n」)が割り当てられている。コードセグメント600に示されているように、リソース602、604、606、および608は、それぞれのフェーズに一致する。各フェーズは、1つ以上の変数を含んでもよく、変数のうち1つは、各フェーズの実行順序を示すためのインジケーターを含んでもよい。いくつかの実施の形態では、インジケーターは、1つ以上のその他のフェーズへの依存があるおよび/または依存がないことを示し得る。一例として、インジケーター618(たとえば、5行目のpredecessors=[])は、その他のフェーズとの関係がないことを示し得る。これは、システムによって、最初のフェーズが実行されることを定義していると解釈され得る。インジケーター620(たとえば、predecessors=[phase.R_n.variable1])を利用して、別のフェーズ(たとえば、フェーズ「R_n」)への依存を、別のフェーズ(たとえば、フェーズ「R_n」)に関連する変数に対応する値の割り当てを含めることによって、示し得る。同様に、インジケーター622は、別のフェーズ(たとえば、「R_s」)への依存を示してもよく(たとえば、「R_s」に関連する変数に対応する値の割り当てを含めることによって)、インジケーター624は、さらに別のフェーズ(フェーズ「R_e」)への依存を示し得る(「R_e」に関連する変数に対応する値の割り当てを含めることによって)。
【0100】
いくつかの実施の形態では、リリースに対応する設定ファイルに、コードセグメント600が含まれ得る。前処理プロシージャの実行の一部として、設定ファイルを1回以上解析/横断し得る。これらの横断のうち1つの横断では、コードセグメント600を分析して、1つ以上のフェーズに対応する実行のIDおよび順序が保持され得るデータ構造を生成し得る。
図7は、この情報を保持するために利用され得るデータ構造の一例(たとえば、連結リスト)を示す。
【0101】
インジケーター618~624を利用して、フェーズが実行される具体的な順序を構築し得る。たとえば、
図6に示すように、フェーズ「R_n」が最初に実行され、続いてフェーズ「R_s」、フェーズ「R_e」、そしてフェーズ「R_w」が実行される。所与のフェーズに関連するタスクが開始する前に完了する、1つ以上のその他のフェーズを、依存関係が示し得ることがわかるであろう。
図6では4つのフェーズが定められているが、任意の適切な数のフェーズが同様に定められ得ることがわかるであろう。
【0102】
図7は、1つ以上のフェーズに関連するリストおよび順序を保持するためにCIOS(クラウドインフラストラクチャオーケストレーションサービス)が生成した例示的なデータ構造(たとえば、連結リスト700)である。連結リスト700を生成して、
図6のコードセグメント600で定められたフェーズおよび実行順序を識別し得る。
図7に示すように、連結リスト700は、4つのノード702、704、706、および708を含む。ノード702、704、706、および708は、各々、コードセグメント600に定められた4つのフェーズのうち1つのフェーズに相当し得る。連結リストの各ノードは、所与のフェーズに対応する任意の適切な情報を格納するように構成されるデータオブジェクトに相当し得る。一例として、所与のノードは、特定のフェーズに対応する任意の適切な数の変数、識別子、データ構造、ポインター、リファレンスなどを格納し得る。非限定例として、フェーズ「R_n」に対応するノード702は、フェーズ「R_n」に対応するとコードセグメント600で定義された3つの変数を格納し得る。各連結リスト700のノードは、所与のフェーズに対応する任意の適切な数の変数を含んでもよい。
【0103】
連結リストの各ノードは、連結リストにある別のノードへのポインター/リファレンスを含んでもよい(複数のフェーズがある場合)。一例として、ノード702は、ノード704へのリファレンスを含んでもよい。ノード704は、ノード706へのリファレンスを含んでもよい。ノード706は、ノード708へのリファレンスを含んでもよい。ノード708は、連結リスト700のエンドノードであることを(たとえば、ヌルポインターによって)示し得る。いくつかの実施の形態では、これらのポインター/リファレンスは、コードセグメント600のインジケーター618~624に基づいて識別され得る。
【0104】
いくつかの実施の形態では、実行時、CIOSは、ノード702(たとえば、開始ノード)から始まる連結リスト700の横断に少なくとも一部基づいて、特定のフェーズが実行される順序を識別し得る。これらのフェーズの実行には、各対応するノード内に格納されたデータの任意の適切な組合せを使用され得る。所与のフェーズに対応する操作が完了すると、CIOSは、次のフェーズに横断してもよく、連結リスト700のエンドノード(たとえば、ノード708)に対応する操作が完了するまで、このプロセスを任意の適切な回数繰り返す。いくつかの実施の形態では、所与のノードの操作が正常に行われなかった場合(たとえば、エラーが発生した場合)、CIOSは、次のノードまで横断しなくてもよく、代わりに、デプロイメントを中止して、ユーザにアラートを出してこの状況を知らせる通知を返し得る。
【0105】
各連結リスト700のノードは、1つ以上の実行ターゲットに対応する実行順序を識別および保持するように構成されたデータ構造に相当し得る。
図8および
図9では、このようなデータ構造の定義および使用法についてより詳細に説明する。連結リスト700が、フェーズに関連する任意の適切な情報(たとえば、識別子516、タイムスタンプ情報520、実行ターゲット518など)を提示するために
図5のUI500が利用する情報を提供し得ることがわかるであろう。
【0106】
図8は、少なくとも1つの実施の形態に係る、実行ターゲット(たとえば、特定のフェーズに対応する実行ターゲット)のリストおよび順序を定めるための例示的なコードセグメント800である。
図8に示すように、コードセグメント800には、4つの実行ターゲットが定められている。各実行ターゲットは、「実行ターゲット」というタイプのリソースとして定められており、識別子(たとえば、「us-la」、「us-sj」、「us-sf」、および「us-sd」)が割り当てられている。コードセグメント800に示されているように、リソース802~808は、各々、一意の実行ターゲットに一致する。各実行ターゲットは、1つ以上の変数に対応付けられてもよく、変数のうち1つは、各フェーズの実行順序を示すためのインジケーターを含んでもよい。いくつかの実施の形態では、インジケーターは、1つ以上のその他の実行ターゲットへの1つ以上の依存があるおよび/または依存がないことを示し得る。一例として、インジケーター818(たとえば、5行目のpredecessors=[])は、その他のフェーズとの関係がないことを示し得る。これは、システムによって、最初の実行ターゲットが実行されることを定義していると解釈され得る。インジケーター620(たとえば、predecessors=[execution_target.us-la.variable1])を利用して、別の実行ターゲット(たとえば、実行ターゲット「us-la」)に関連する変数に対応する値の割り当てを含めることによって、別の実行(たとえば、フェーズ「us-la」)への依存を示し得る。同様に、インジケーター822は、別のフェーズ(たとえば、実行ターゲット「us-sj」に関連する変数に対応する値の割り当てを含めることによって、実行ターゲット「us-sj」)への依存を示してもよく、インジケーター624は、さらに別のフェーズ(たとえば、実行ターゲット「us-sf」に関連する変数に対応する値の割り当てを含めることによって、実行ターゲット「us-sf」)への依存を示し得る。
【0107】
いくつかの実施の形態では、リリースに対応する設定ファイル(たとえば、コードセグメント800を含む同じまたは異なる設定ファイル)に、コードセグメント800が含まれ得る。前処理プロシージャの実行の一部として、設定ファイルを1回以上解析/横断し得る。これらの横断のうち1つの横断では、コードセグメント800を分析して、所与のフェーズに対応する実行ターゲットのIDおよび順序が保持され得るデータ構造を生成し得る。
図9は、この情報を保持するために利用され得るデータ構造の一例(たとえば、DAG(有向非巡回グラフ))を示す。
【0108】
インジケーター818~824を利用して、実行ターゲットが実行される具体的な順序を構築し得る。たとえば、
図8に示すように、実行ターゲット「us-la」に関連するタスクが最初に実行され、続いて実行ターゲット「us-sj」に関連するタスクが実行され、実行ターゲット「us-sf」に関連するタスクが実行され、そして実行ターゲット「us-sd」に関連するタスクが実行される。所与の実行ターゲットに関連するタスクが開始する前に対応するタスクが完了する、1つ以上のその他の実行ターゲットを、依存関係が示し得ることがわかるであろう。
図8では4つの実行ターゲットが定められているが、任意の適切な数のフェーズが同様に定められ得ることがわかるであろう。いくつかの実施の形態では、実行ターゲットは、共通の依存関係(たとえば、同じpredecessorsの定義)を共有し得る。共通の依存関係を利用して、当該共通の依存関係を共有する実行ターゲットに関連するタスクが同時に実行され得ることを示し得る。
【0109】
図9は、少なくとも1つの実施の形態に係る、フェーズに関連する1つ以上の実行ターゲットに関連するリストおよび順序を保持するためにCIOS(クラウドインフラストラクチャオーケストレーションサービス)が生成し得る例示的なデータ構造(たとえば、DAG(有向非巡回グラフ)900)である。DAG900は、CIOSによるリリースに関連する設定ファイルが1回以上解析されたことに応答して生成される複数のDAGのうち1つであってもよい。DAG900の各ノードは、1つの実行ターゲットに相当し得る。
図9に示すように、DAG900は、6つのノード(たとえば、ノード902、904、906、908、910、および912)を含む。これらのノードは、各々、
図8のコードセグメント800で説明した方法と同様の方法で定められた6つの実行ターゲットのうち1つに相当し得る。DAG900の各ノードは、所与の実行ターゲットに対応する任意の適切な情報を格納するように構成されるデータオブジェクトに相当し得る。一例として、所与のノードは、特定の実行ターゲットに対応する任意の適切な数の変数、識別子、データ構造、ポインター、リファレンスなどを格納し得る。
【0110】
DAG900の各ノードは、DAG90にある1つ以上のノードへのポインター/リファレンスを含んでもよい。一例として、ノード902は、ノード904へのリファレンスを含んでもよい。ノード904は、ノード906~910へのリファレンスを含んでもよい。ノード906~910は、各々、ノード912へのリファレンスを含んでもよい。ノード912は、DAG900のエンドノードであることを(たとえば、ヌルポインターによって)示し得る。いくつかの実施の形態では、これらのポインター/リファレンスは、
図8に関して上述したインジケーター818~824と同様のインジケーターに基づいて識別され得る。いくつかの実施の形態では、ノード906、908、および910は、ノード904への共通の依存を含んでもよいので、ノード906~910に関連するタスクが少なくとも一部同時に実行され得る。いくつかの実施の形態では、ノード912は、ノード906~910に依存する実行ターゲットに相当し得る。よって、ノード912に対応する実行ターゲットに関連するタスクは、ノード906~910に対応する実行ターゲットのすべてに関連するタスクが完了した後にのみ実行され得る。
【0111】
いくつかの実施の形態では、DAG900は、
図7に関して上述した1つの連結リスト700のノードに対応付けられ得る。すなわち、(たとえば、DAG900のノードによって識別および表される)1つ以上の実行ターゲットは、連結リスト700の特定のフェーズ(たとえば、1つのノード)に対応付けられ得る。いくつかの実施の形態では、連結リスト700のノードは、DAG900へのリファレンスを含んでもよく、または、DAG9001つ以上のノードは、連結リスト700のノードへのリファレンスを含んでもよい。
【0112】
いくつかの実施の形態では、CIOSは、設定ファイル(たとえば、
図8のコードセグメント800を含む)を横断して、この横断からDAG900を生成し得る。DAG900の生成は、ランタイム前またはランタイムに実行される前処理プロシージャの一部として完了し得る。所与の実行ターゲットに対応する操作が完了すると、CIOSは、次の実行ターゲット(複数可)に横断してもよく、DAG900の1つ以上のエンドノード(たとえば、ノード912)に対応する操作が完了するまで、このプロセスを任意の適切な回数繰り返す。いくつかの実施の形態では、所与のノードに対応する操作が正常に行われなかった場合(たとえば、エラーが発生した場合)、CIOSは、次のノードを横断しなくてもよく、代わりに、ユーザにアラートを出してこの状況を知らせる通知を返し得る。
【0113】
DAG900の各ノードは、1つ以上のリソース(たとえば、サービス、ソフトウェアモジュールなど)に対応する実行順序を識別および保持するように構成されたデータ構造に相当し得る。
図10~
図12では、このようなデータ構造(たとえば、能力のDAG)の定義および使用法についてより詳細に説明する。一例として、DAG900の各ノードが別のDAG(たとえば、
図12のDAG1200。リソースおよび/または能力のリストおよび順序を示し、タスク実行の順序を識別する)に相当し得る。DAG900が、実行ターゲットインジケーター524~528に関連する任意の適切な情報を提示するために
図5のUI500が利用する情報を提供し得ることがわかるであろう。よって、実行ターゲット追跡エリア522に示されている情報は、DAG900(フェーズ「R_s」など所与のフェーズに対応するDAG)の簡素版を示し得る。DAGの簡素版では、DAG900の同時に実行可能なノードを1つのノードに凝縮され得る(たとえば、DAGの12個のノードが1つのノードに濃縮されていることを示す実行ターゲットインジケーター528を参照)。いくつかの実施の形態では、CIOSは、DAG900を横断することに少なくとも一部基づいて、インフラストラクチャリソースおよび/またはリリースソフトウェアのアーティファクトをデプロイし得る。具体的なタスクおよびタスクの具体的な順序は、
図10~
図12に関して説明するように識別される。
【0114】
図10は、少なくとも1つの実施の形態に係る、実行ターゲットのリソース間の明示的依存関係および暗黙的依存関係を構築するための例示的なコードセグメント1000である。コードセグメント1000は、
図10に示すように、2つのモジュール1002および1004と、リソース1006とを含む。モジュール1002および1004は、各々、それぞれ「apps_example1」および「apps_example2」と示された名前1008および1010を含む。モジュールは、任意の適切な英数文字(複数可)を含んだ任意の適切な長さの名前を含んでもよい。モジュール1002および1004は、ユーザが起動またはプロビジョニングしたいアプリケーション/サービスを定め得る。モジュール1002および1004を用いて、利用可能なドメイン1および利用可能なドメイン2にそれぞれアプリケーションをデプロイし得る。リソース1006は、
図10に「type」として示されているリソースタイプ1012と、
図10に「executor」として示されているリソース名1014とを含むマルチパラメータリストを含むことができる。リソースタイプ1012は、デプロイメントに適した任意のタイプであってもよく、リソース名1014は、任意の名前であってもよい。
【0115】
リソース1006は、能力であってもよく、暗黙的依存、明示的依存、またはその両方を含んでもよい。コードセグメント1000に示されているように、リソース1006は、「module.apps_example1.variable1」に等しい値、およびapps_example1というモジュール(たとえば、モジュール1002)を介してアクセス可能な値に、変数「variable1」を割り当てようとする。これには、リソース1006とモジュール1002との間に形成される暗黙的依存関係を示すという意図がある。形成された暗黙的依存関係によって、モジュール1002がデプロイメントを完了する前にリソース1006が動作しないようにし得る。リソース1006を起動する責任を担うプロセスは、モジュール1002がデプロイメントを完了したという通知を受信し得る。この通知は、スケジューラー(たとえば、
図2のスケジューラー206)によって送信されてもよく、リソース1006を起動する責任を担うプロセスによって受信され得る。
図10に示すリソース1006がモジュール1002とリソース1006との依存関係を直接定めないので、形成された暗黙的依存関係は、暗黙的であると考えられる。
【0116】
対照的に、リソース1006には、
図10の29行目に、リソース1006とapp_example2モジュールとの依存関係を明示的に定めている明示的依存関係が含まれる。コードセグメント1000の29行目に示されているように、リソース1006は、「depends_on=apps_example2.variable2」を含む。29行目のコードに基づいて、明示的依存関係が形成されてもよく、明示的依存関係によって、apps_example2が正常にデプロイされるまでリソース1006がデプロイされないようにし得る。apps_example2が正常にデプロイされると、スケジューラーによって通知が送信されてもよく、リソース1006をデプロイする責任を担うプロセスによって当該通知が受信され得る。なお、
図10のコードセグメント1000には、1つの暗黙的依存と1つの明示的依存とを含む1つのリソース1006が含まれているが、当業者であれば、CIOSのユーザの目標を実現するために、リソース1006と、暗黙的依存と、明示的依存との任意の組合せが用いられ得ることがわかるであろう。
【0117】
コードセグメント1000を含む設定ファイルを解析するために、CIOS(または、上述したCIOSの宣言型プロビジョニングツールなど、宣言型インフラストラクチャプロビジョナー)が利用され得る。この解析を通して、CIOS(または、宣言型プロビジョニングプロビジョナー)は、その他のリソース、モジュール、および/または能力への依存の順序付きリストをコンパイルおよび定めるリソース、モジュール、および/または能力ごとに、DAG(有向非巡回グラフ)を生成し得る。リソースのデプロイを試行する間、CIOSは、DAGを横断して、リソースが別のリソース、モジュール、および/または能力に依存しているときを識別し得る。リソースごとのDAGは、暗黙的依存、明示的依存、または、それらの組合せを指定してもよく、CIOSを有する対応するリソースを起動またはデプロイするために用いられ得る。
【0118】
図11は、少なくとも1つの実施の形態に係る、実行ターゲットのリソース間の明示的依存関係および暗黙的依存関係を構築するための例示的なコードセグメント1100である。
図11に示すコードセグメント1100は、4つのリソース1102、1104、1106、および1108を含む。リソース1102、1104、1106、および1108の各リソースは、能力に相当してもよく、暗黙的依存、明示的依存、または、それらの組合せを含んでもよい。
【0119】
図11に示すリソース1102は、「object_storage」と示されている名前1110、「type1」と示されているタイプ1112(たとえば、リソースが能力であることを示す)、および複数の変数(たとえば、変数1~3。しかし、より多くの変数、またはより少ない変数が利用され得る)を含む。
図11に示すリソース1104は、「worker」と示されている名前1116と、「depends_on=type1.object_storage」と示されている明示的依存1118とを含む。リソース1102のパラメータリストは、識別子1115を含む。識別子1115は、そのリソースを参照するために用いられ得る(または、名前1110が同様に利用され得る)。ステートメント1118は、type1.object_storageへの参照によって、リソース1102への明示的依存を形成する。この明示的依存により、リソース1104は、リソース1102がデプロイメントを完了するまでデプロイされなくてもよい。
図11に示すリソース1106は、「peacock」と示されている識別子1120と、タイプ(たとえば、能力を示す「type1」)と、複数の変数(たとえば、variable1およびvariable2)とを含む。
図11に示すリソース1108は、タイプ(たとえば、「type4」)と、「LB」と示されている名前1124と、ステートメント1126(「count=type1.peacock.exists.」)とを含む。ステートメント1126を使用することにより、リソース1106への暗黙的依存が形成され得る。リソース1108は、明示的依存コンストラクト(たとえば、「depends_on」)を使用しないが、「peacock」という能力が存在するかどうか(type1.peacock.existsというステートメントから判断される)に等しい値を、変数「count」に割り当てようとするため、暗黙的依存は存在する。よって、18行目で試行される割り当てがあるので、リソース1106「peacock」がデプロイするまでリソース1108はデプロイされなくてもよい。
図11のコードセグメント1100は1つの暗黙的依存と1つの明示的依存とを含む4つのリソース1102、1104、1106、および1108を含むが、当業者であれば、CIOSのユーザの目標を実現するために、リソースと、暗黙的依存と、明示的依存との任意の組合せが用いられ得ることがわかるであろう。
【0120】
CIOS(または、上述したCIOSの宣言型プロビジョニングツールなど、宣言型インフラストラクチャプロビジョナー)を利用して、コードセグメント1100を含む設定ファイルを解析し得る。この解析を通して、CIOS(または、宣言型プロビジョニングプロビジョナー)は、リソース、モジュール、および/または能力ごとにDAG(有向非巡回グラフ)を生成し得る。当該リソース、モジュール、および/または能力は、その他のリソース、モジュール、および/または能力への依存の順序付きリストをコンパイルおよび定める。リソースをデプロイしようとする間、CIOSは、DAGを横断して、リソースが別のリソース、モジュール、および/または別のリソースの能力にいつ依存するかを識別し得る。リソースごとのDAGは、暗黙的依存、明示的依存、または、それらの組合せを指定してもよく、CIOSを有する対応するリソースを起動またはデプロイするために用いられ得る。
【0121】
図12は、少なくとも1つの実施の形態に係る、クラウドコンピューティングシステムのリソース(たとえば、リソースA)に対応する例示的なDAG(有向非巡回グラフ)1200である。図に示すように、DAG1200は、任意の適切な数のノード(たとえば、
図12に示す6つのノード)およびエッジ(たとえば、
図12に示す7つのエッジ)を含む有限の有向グラフであり得る。各エッジは、
図12に示すように、1つのノードから別のノードに向けられる。ノードおよびエッジは、有向閉路とならないように配置され得る。すなわち、DAG1200は、任意のノードから出発した後、一貫して有向な一連のエッジが最終的にその同じノードに巡回して戻ってくることのないように定められている。最後のノード(たとえば、ノード「6」)は、ヌル値を指してもよいし、DAGの終点を示し得る。
【0122】
DAG1200は6つのノードおよび7つのエッジを示すが、DAGは、任意の適切な数のノードおよび有向エッジを含んでもよい。いくつかの実施の形態では、各ノードは、一連の操作(たとえば、リソースAなどのリソースをデプロイするおよび/もしくは起動するなどのタスクを実行するための操作)、または複数の操作から構成される次のノードが依存する一連の能力に相当する。各DAGの有向エッジによって、これらの操作が実行される順序および/またはノードに関連する操作のサブセットとそのノードの直前のノードに関連する能力のサブセットとの依存関係が定められる。
【0123】
簡単な実施例として、DAG1200のノード1、2、5、6は、4つの別個の一連の操作に相当するノードを示す。
図1200に示すエッジに基づいて、ノード1、2、5、そして6という順序に対応する順序で各ノードの操作が実行される。ノード3および4は、1つ以上の依存と個々に一致する複数のノードを示す。一例として、ノード3は、ノード5に対応する操作の、異なるリソース(たとえば、リソースB)に関連する能力への依存に相当し得る。同様に、ノード4は、ノード5に対応する操作の、異なるリソース(たとえば、リソースC)に関連する能力への依存に相当し得る。いくつかの実施の形態では、異なるリソースのために異なる能力ノード(たとえば、特定のリソースの1つの能力/複数の能力への依存を識別するノード)が用いられてもよく、依存がどれほど多くのリソースを参照しているかに関係なく、1つのノードを利用してすべての依存関係を指定し得る。よって、いくつかの実施の形態では、(たとえば、ノード3において識別された)リソースBに対応する依存と、(たとえば、ノード4において識別された)リソースCに対応する依存とを組み合わせて、1つのノードにし得る。
【0124】
DAG1200は、
図10~
図12に関してより詳細を説明する方法で横断され、リソースを、その他のリソースの能力(または、その他のリソース自体)への1つ以上の依存に関連して、クラウドコンピューティング環境において起動および/またはデプロイするための操作の実行のオーケストレーションを行ない得る。
【0125】
図13は、少なくとも1つの実施の形態に係る、少なくとも1つの能力への依存(たとえば、異なるリソースの能力)を含むタスクの実行(たとえば、リソースをデプロイすること)のオーケストレーションを行うための例示的なプロセス1300を示すフロー図である。
図13に示すように、処理の流れ1300には、スケジューラー1302(たとえば、
図2のスケジューラー206)、ワーカー1304(たとえば、
図2のワーカー210)、およびIPプロセス1306(たとえば、
図2のCIOSコンテナ212)が含まれる。
【0126】
1308において、スケジューラー1302は、リージョンでインフラストラクチャリソースをデプロイするためのタスクを受信してもよく、スケジューラー1302は、当該タスクに関係するデータをワーカー1304に送信し得る。いくつかの実施の形態では、スケジューラー1302は、ワーカー1304をインスタンス化して、リソース(たとえば、サービス)のデプロイメントに対処し得る。
【0127】
1310において、ワーカー1304は、IPプロセス1306をインスタンス化し得る。IPプロセス1306は、宣言型インフラストラクチャプロビジョナー(たとえば、上述した宣言型プロビジョニングツール、Terraform)のインスタンスを実行するように構成され得る。
【0128】
1312において、IPプロセス1306は、デプロイメントに関連する設定ファイル(たとえば、
図10および
図11のコードセグメント1000および/または1100を含む設定ファイル)を解析して、特定のリソースのDAG(有向非巡回グラフ)を生成し得る。設定の解析を通じて、IPプロセス1306(宣言型インフラストラクチャプロビジョナー)は、その他のリソースの、能力への任意の適切な数の暗黙的依存および/または明示的依存を識別し得る。識別されると、IPプロセス1306は、当該リソースが依存する能力に相当する1つ以上のノードを有する、リソースを起動および/またはデプロイするためのタスクを指定するDAGを(たとえば、解析中に識別された暗黙的依存および/または明示的依存に従って)構築する。
【0129】
1314において、IPプロセス1306は、DAGの横断を開始してもよく、DAGの様々なノードに到達すると、特定のリソースのデプロイメントおよび/または起動の少なくとも一部を実行する。DAGの少なくとも1つのノードに従って任意の適切な操作が行われて、リソースに対応する機能の一部を利用可能にし得る。リソースに対応する機能の複数部分が利用可能になってもよい。いくつかの実施の形態では、IPプロセス1306は、リソースの1つ以上の能力が現在利用可能であることを示す通知をスケジューラー1302に送信し得る(図示せず)。DAGのノードのうち少なくとも1つは、1つ以上のその他のリソースの能力に相当し得る。これらのタイプのノードに到達すると、IPプロセス1306は、能力が利用可能であるかどうかを確認し得る。利用可能である場合、IPプロセス1306は、DAGの横断を進め得る。
【0130】
1316において、IPプロセス1306は、1つ以上のその他のリソースの1つ以上の能力に相当するDAGのノードに到達し得る。いくつかの実施の形態では、IPプロセス1306は、ノードに関連する少なくとも1つの能力がまだ利用できないと判断し得る。
【0131】
1320において、ノードに関連する少なくとも1つの能力が利用できないと判断したことに応答して、IPプロセス1306は、IPプロセス1306に対応するリソースが依存する1つ以上の能力が利用可能でないと判断されたことを示すデータを、スケジューラー1302に送信し得る。
【0132】
1322において、場合によっては、どの操作および/またはDAGのどのノードが完了済みであるかを示す状態情報および/または、DAGのどの特定のノードにIPプロセス1306が最後にアクセスしたかを示す状態情報を格納した後に、IPプロセス1306は、終了し得る。IPプロセス1306は、終了する、強制終了される、一旦停止される、または実行を中止する。
【0133】
1324において、スケジューラー1302は、特定のリソースが、起動を再開するおよび/またはデプロイメントする目的のために必要とする1つ以上の特定の能力を待ち受け中であったことを示す情報を格納し得る。
【0134】
1326において、スケジューラー1302は、リソースが待ち受けていた1つ以上の能力が利用可能になったことを知らせる1つ以上の通知を受信し得る。いくつかの実施の形態では、スケジューラー1302は、対応するリソースの様々な能力についての様々な通知を、これらが利用可能になると、その他のIPプロセスから受信し得る。スケジューラー1302は、利用可能なこれらの様々な能力の1つ以上のレコードおよび/またはリソースが現在待ち受け中の様々な能力の1つ以上のレコードを保持し得る。スケジューラー1302は、IPプロセス1306に対応するリソースが待ち受け中の特定の1つ/複数の能力が利用可能になったことを、これらの1つ以上のレコードから識別し得る。したがって、スケジューラー1302は、1328に進み得る。
【0135】
1328において、IPプロセス1306に対応するリソースが依存する能力が利用可能になったと判断されたことに応答して、スケジューラー1302は、ステップ1308に戻ってもよい。ステップ1308では、スケジューラー1302は、元のタスク(たとえば、リソースをデプロイすること)に関係するデータをワーカー1304に送信する。いくつかの実施の形態では、スケジューラー1302は、新しいワーカーをインスタンス化してもよく、または(図示した)以前のワーカー1304を利用して、リソースに関連するタスクへの対処を継続し得る。ワーカー1304は、設定ファイルを実行および解析してリソースについてのDAGを生成するように構成され得るIPプロセス(図示せず)をインスタンス化し得る。IPプロセスは、格納されている状態情報にアクセスして、DAGにおいて最後にアクセスされたノード(たとえば、リソースが応答待機していた1つ以上の能力に相当するノード)を識別し得る。1つ以上の能力が利用可能になったので、IPプロセスは、上述した方法と同様の方法でDAGの横断に進んでもよく、DAGのエンドノードの操作が完了するまで、各ノードにおける操作を実行する、タスクの一部を実行する、またはタスクの次の一部が依存する能力を確認する。
【0136】
タスクのすべてのリソースについて、上述したプロセスと同様のプロセスが実行され得る。一例として、複数のリソース(たとえば、複数のサービス)を有するシステムをデプロイする場合、システムの各リソースをデプロイするために、各リソースに代わってプロセス1300が実行され得る。
【0137】
図14は、少なくとも1つの実施の形態に係る、(たとえば、CIOSが)リリースを実行するための例示的な処理の流れ1400である。イベント番号1において、スケジューラー1402(たとえば、
図2のスケジューラー206)は、ワーカー1404(たとえば、
図2のワーカー210)にタスクを送信し得る。このタスクは、インフラストラクチャリソースを一連の実行ターゲットにデプロイするなど、コンピューティングシステムまたはそのサブセットをデプロイすることを含んでもよい。タスクでは、連結リスト(たとえば、
図7の連結リスト700の例)、DAG(たとえば、それぞれ
図9および
図12のDAG900および1200)、それらの組合せ、またはコンピューティングシステムをデプロイするためのその他の適したタスクを横断する必要がある。ワーカー1404は、このタスクをスケジューラー206から受信し得る。ワーカー1404は、ワーカーノードのフリートにある1つのワーカーノードであってもよい。ワーカーノードのフリートは、コンピューティングシステムをデプロイするための任意の適切な数のワーカーノードを含んでもよい。スケジューラー1402によって、ワーカー1404の容量に少なくとも一部基づいて、ワーカー1404を選択し得る。たとえば、ワーカー1404の計算能力がワーカーノードのフリートにおいてが最も多い場合、スケジューラー1402は、ワーカー1404にタスクを送ることを選択し得る。
【0138】
イベント番号2において、ワーカー1404は、設定ファイル1406を1回以上解析/横断し得る。設定ファイル1406は、コンピューティングシステムをデプロイするための命令を含んでもよく、解析を1回以上行うことによって、コンピューティングシステムをデプロイするための、起動もしくはそうでなければデプロイされることが望まれるリソースまたはその他の能力が識別され得る。非限定例として、設定ファイル1406は、
図6、
図8、
図10、および
図11のそれぞれのコードセグメント600、800、1000、および1100を含んでもよい。
【0139】
イベント番号3において、設定ファイル1406からの情報は、IPプロセス1408(たとえば、
図2のIPプロセス212)に送信され得る。IPプロセス1408は、ワーカー1404が実行した1回以上の解析/横断に基づいて、設定ファイル1406からの情報を受信し得る。この情報は、一連の能力、実行ターゲット、またはコンピューティングシステムをデプロイするためのその他の適したリソースを含んでもよい。
【0140】
イベント番号4において、設定ファイル1406からこの情報を受信したことに応答して、IPプロセス1408は、能力、またはコンピューティングシステムをデプロイするためのその他の適したリソースがデプロイされる順序を決定し得る。IPプロセス1408は、フェーズの連結リスト1410(たとえば、
図7の連結リスト700の例)、実行ターゲットのDAG1412(たとえば、
図9のDAG900の例)、能力のDAG1414(たとえば、
図12のDAG1200の例)、またはその他の適したリスト、グラフ、もしくはデータ構造を生成し得る。フェーズの連結リスト1410、実行ターゲットのDAG1412、および能力のDAG1414(まとめて「リリースデータ構造」と称す)は、任意の適切な順序で生成され得る。
【0141】
リリースデータ構造は、リリースのタスクを実行するための順序を識別および決定するために使用され得る。たとえば、フェーズの連結リスト1410の各ノードは、実行ターゲットのDAGの別個のインスタンス(たとえば、実行ターゲットのDAG1412の例)に相当する。ここで、実行ターゲットのDAGの各ノードは、能力のDAG(たとえば、能力のDAG1414の例)に相当する。IPプロセス1408は、連結リスト1400の最初のノードから始まって、対応する実行ターゲットのDAGを識別し得る。実行ターゲットのDAGの最初のノードを利用して、対応する能力のDAGを識別し得る。能力のDAGに従って、能力のそのDAGに関連するタスクを実行してもよく、完了すると、IPプロセス1408は、実行ターゲットのDAGの次のノードを横断して、次の対応する能力のDAGを識別し得る。実行ターゲットのDAGの各ノードを横断してもよく、これらのノードに対応するタスクが完了すると、IPプロセス1408は、連結リスト1400の次のノードを横断して、次のフェーズを識別し得る。リリースの最後のフェーズに関連する実行ターゲットの各々に関連するタスクのすべてが完了するまで、このプロセスを任意の適切な回数繰り返し得る。
【0142】
一例として、イベント番号5において、フェーズの連結リスト1410の最初のノードに到達する。IPプロセス1408は、最初のノードに対応する実行ターゲットのDAGを識別する。
【0143】
イベント番号6において、実行ターゲットのDAG1412の最初のノードに到達する。能力のDAG1414は、実行ターゲットのDAG1412の最初のノードに関連することに少なくとも一部基づいて識別され得る。
【0144】
イベント番号7において、能力のDAG1414を横断することに少なくとも一部基づいて、所与の実行ターゲットについてのタスクを実行する。これらのタスクが完了すると、IPプロセス1408は、実行ターゲットのDAGの次のノードを横断し、対応する能力のDAGを判断し、その能力のDAGの横断に従ってタスクを実行し得る。実行ターゲットのDAG1412の最後のノードに関連するタスクが実行されるまで、このプロセスは続行し得る。その後、IPプロセス1408は、フェーズの連結リスト1410の次のノードを横断し得る。フェーズの連結リスト1410の最後のノードに関連する実行ターゲットのすべてに関連するタスクのすべてが実行されるまで、イベント番号5~7の操作を任意の適切な回数繰り返し得る。タスク、実行ターゲット、および/またはフェーズが完了すると、IPプロセス1408は、
図5のUI500を更新するまたは更新させてタスク、実行ターゲット、および/またはフェーズの現在の状態を表示させ得る。
【0145】
イベント番号8において、IPプロセス1408は、リリースの横断が完了したことを示す信号をスケジューラー1402に送信する。スケジューラー1402は、IPプロセス1408から信号を受信してもよく、コンピューティングシステムが使える用意が整ったことを示す通知をブロードキャストし得る。
【0146】
図15は、少なくとも1つの実施の形態に係る、CIOSにあるDAGを使用してコンピューティングシステムをデプロイするための処理1500のフローチャートである。ブロック1502において、CIOSは、コンピューティングシステムのデプロイに関連する設定データの解析を1回以上行うための命令を実行し得る。設定データは、設定ファイルに含まれてもよく、設定データを1回以上解析する際、CIOSは、コンピューティングシステムをデプロイするために実行する一連のタスクを決定し得る。当該一連のタスクに含まれるタスクには、実行ターゲットにおいてインフラストラクチャリソースをデプロイすること、または、コンピューティングシステムをデプロイするためのその他の適したタスクが含まれ得る。
【0147】
ブロック1504において、CIOSは、設定ファイルに基づいてリソースをデプロイするための第1DAG(たとえば、
図12のDAG1200)を生成させる。第1DAGは、起動またはデプロイされる能力の特定の順序を略述し得る、能力のDAGであってもよい。第1DAGは、能力をデプロイするための任意の適切な数のタスクを含んでもよく、デプロイされる能力間の任意の適切な数の依存関係を含んでもよい。
【0148】
ブロック1506において、CIOSは、設定ファイルに基づいて実行ターゲットデプロイするための実行ターゲット間の依存関係を定める第2DAG(たとえば、
図9のDAG900)を生成する。第2DAGは、実行ターゲットがデプロイされる順序を指定する実行ターゲットのDAGであってもよい。第2DAGは、コンピューティングシステムをデプロイするための任意の適切な数の実行ターゲットを含んでもよく、実行ターゲットをデプロイするための任意の適切な数の依存関係を含んでもよい。
【0149】
ブロック1508において、CIOSは、設定ファイルに基づいてフェーズ間の依存関係を指定する連結リスト(たとえば、
図7の連結リスト700)を生成する。これらのフェーズは、第1DAG、第2DAG、または、それらの組合せを含んでもよく、連結リストは、フェーズが実行される順序を定め得る。連結リストのフェーズは、連続して実行されてもよく、並列して実行されるフェーズを含まなくてもよい。連結リストは、コンピューティングシステムをデプロイするための任意の適切な数のフェーズを含んでもよい。
【0150】
ブロック1510において、CIOSは、第1DAG、第2DAG、および連結リストを横断することによってコンピューティングシステムをデプロイしてもよい。CIOSは、連結リストを横断してもよく、第1DAGおよび第2DAGは、同時に横断され得る(すなわち、第1DAGおよび第2DAGは、連結リストに含まれ得る)。連結リスト、第1DAG、および第2DAGを正常に横断すると、コンピューティングシステムのデプロイメントが正常に行われ得る。
【0151】
システム例
図16~
図18は、様々な実施形態に係る本開示の態様を実現するための例示的な環境の態様を説明する図である。
図16は、本開示の実施形態を実現するための分散システム1600の簡略図である。図示した実施形態では、分散システム1600は、1つ以上のクライアントコンピューティングデバイス1602、1604、1606、および1608を備える。1つ以上のクライアントコンピューティングデバイス1602、1604、1606、および1608は、1つ以上のネットワーク(複数可)1610でウェブブラウザ、プロプライエタリ・クライアント(たとえば、Oracle Forms)などのクライアントアプリケーションを実行および操作するように構成される。サーバ1612は、ネットワーク1610を介して、リモートクライアントコンピューティングデバイス1602、1604、1606、および1608と通信可能に接続され得る。
【0152】
様々な実施形態では、サーバ1612は、ID管理サービスを提供するサービスおよびアプリケーションなど、1つ以上のサービスまたはソフトウェアアプリケーションを実行するようになされ得る。また、特定の実施形態では、サーバ1612は、非仮想環境および仮想環境を含み得る他のサービスまたはソフトウェアアプリケーションを提供し得る。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス1602、1604、1606、および/または1608のユーザに対して、ウェブベースのサービスもしくはクラウドサービスとして提供されてもよく、または、SaaS(Software as a Service)モデル下で提供され得る。そして、クライアントコンピューティングデバイス1602、1604、1606、および/または1608を操作するユーザは、1つ以上のクライアントアプリケーションを利用して、サーバ1612とやり取りして、これらのコンポーネントが提供するサービスを利用できる。
【0153】
図16に示す構成において、システム1600のソフトウェアコンポーネント1618、1620、および1622が、サーバ1612上に実装されたものとして示される。また、他の実施形態では、システム1600のコンポーネントのうちの1つ以上および/またはこれらのコンポーネントが提供するサービスのうちの1つ以上は、クライアントコンピューティングデバイス1602、1604、1606、および/または1608のうちの1つ以上によって実現され得る。次に、クライアントコンピューティングデバイスを操作しているユーザは、1つ以上のクライアントアプリケーションを利用して、これらのコンポーネントが提供するサービスを使用し得る。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現され得る。様々な異なるシステム構成が可能であり、これらは、分散型システム1600とは異なってもよいことを理解されたい。よって、
図16に示す実施形態は、実施形態のシステムを実現するための分散システムの一例であり、限定を意図したものではない。
【0154】
クライアントコンピューティングデバイス1602、1604、1606、および/または1608は、様々な種類のコンピュータシステムを含んでもよい。たとえば、クライアントコンピューティングデバイスは、Microsoft Windows(登録商標) Mobileなどのソフトウェアおよび/またはiOS、Windows Phone(登録商標)、Android、BlackBerry 10、Palm OSなどのいろいろなモバイルオペレーティングシステムを実行する手のひらサイズのポータブルデバイス(たとえば、iPhone(登録商標)、携帯電話、iPad(登録商標)、コンピューティングタブレット、携帯情報端末(PDA))またはウェアラブルデバイス(たとえば、Google Glass(登録商標)ヘッドマウントディスプレイ)を含んでもよい。デバイスは、様々なインターネット関連アプリ、電子メール、SMS(ショートメッセージサービス)アプリケーションなど、様々なアプリケーションをサポートしてもよく、様々な他の通信プロトコルを使用し得る。また、クライアントコンピューティングデバイスは、一例として、様々なバージョンのMicrosoft Windows、Apple Macintosh(登録商標)、および/またはLinux(登録商標)オペレーティングシステムを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む、汎用パーソナルコンピュータを含んでもよい。クライアントコンピューティングデバイスは、これらに限定されないが、たとえば、Google Chrome OSなど、いろいろなGNU/Linux(登録商標)オペレーティングシステムを含む、流通している各種のUNIX(登録商標)またはUNIXに似たオペレーティングシステムを実行するワークステーションコンピュータであり得る。また、クライアントコンピューティングデバイスは、シンクライアントコンピュータ、インターネット対応のゲーミングシステム(たとえば、Kinect(登録商標)ジェスチャ入力装置付きまたは無しのMicrosoft Xboxのゲーミングコンソール)、および/またはパーソナルメッセージングデバイスなど、ネットワーク(複数可)1610で通信可能な電子機器を含んでもよい。
【0155】
図16の分散システム1600は、4つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされ得る。センサ付きデバイスなど、他のデバイスがサーバ1612とやり取りを行ってもよい。
【0156】
分散システム1600におけるネットワーク(複数可)1610は、これらに限定されないが、TCP/IP(Transmission Control Protocol/Internet Protocol)、SNA(Systems Network Architecture)、IPX(Internet packet exchange)、AppleTalkなどを含む、各種の利用可能なプロトコルを使用したデータ通信をサポートできる、当業者にとってなじみの任意の種類のネットワークであってもよい。単に一例として、ネットワーク(複数可)1610は、LAN(Local Area Network)、Ethernet(登録商標)ベースのネットワーク、トークンリング、ワイドエリアネットワーク、インターネット、仮想ネットワーク、VPN(仮想Private Network)、イントラネット、エクストラネット、PSTN(Public Switched Telephone Network)、赤外線ネットワーク、ワイヤレスネットワーク(たとえば、IEEE(Institute Of Electrical And Electronics)1002.16スイートのプロトコル、Bluetooth(登録商標)、および/またはその他のワイヤレスプロトコルのうちのいずれかの下で動作するネットワーク)、および/またはこれらの任意の組合せならびに/もしくは他のネットワークで有り得る。
【0157】
サーバ1612は、1つ以上の汎用コンピュータ、専用サーバコンピュータ(一例として、PC(Personal Computer)サーバ、UNIXサーバ、ミッドレンジ・サーバ、メインフレーム・コンピュータ、ラックマウント式のサーバなどを含む)、サーバファーム、サーバクラスタ、またはその他の適切な配置および/または組合せから構成され得る。サーバ1612は、仮想オペレーティングシステムを実行している1つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。論理記憶装置の1つ以上のフレキシブルプールを仮想化して、サーバ用の仮想記憶装置を維持することができる。仮想ネットワークは、ソフトウェア定義ネットワーキングを使用して、サーバ1612によって制御することができる。様々な実施形態において、サーバ1612は、上記の開示において説明した1つ以上のサービスまたはソフトウェアアプリケーションを実行するようになされ得る。たとえば、サーバ1612は、本開示の実施形態に係る上述した処理を実行するためのサーバに相当し得る。
【0158】
サーバ1612は、上述のオペレーティングシステムのいずれかおよび市販されているサーバオペレーティングシステムのうちのいずれかを含むオペレーティングシステムを実行し得る。また、サーバ1612は、HTTP(ハイパーテキストトランスポートProtocol)サーバ、FTP(File Transfer Protocol)サーバ、CGI(Common Gateway Interface)サーバ、JAVA(登録商標)サーバ、データベースサーバなどを含む、各種の追加のサーバアプリケーションおよび/またはミッドティア・アプリケーションを実行し得る。例示的なデータベースサーバとして、Oracle、Microsoft、Sybase、IBM(International Business Machines)などから市販されているデータベースサーバが挙げられるが、これらに限定されない。
【0159】
いくつかの実装形態では、サーバ1612は、クライアントコンピューティングデバイス1602、1604、1606、および1608のユーザから受信したデータフィードおよび/またはイベント更新を分析および1つにまとめるための1つ以上のアプリケーションを含んでもよい。例として、データフィードおよび/またはイベント更新は、これらに限定されないが、1つ以上のサードパーティ情報ソースおよび連続したデータストリームから受信するTwitter(登録商標)フィード、Facebook(登録商標)更新またはリアルタイム更新を含んでもよく、当該1つ以上のサードパーティ情報ソースおよび連続したデータストリームは、センサーデータアプリケーション、チッカー、ネットワークパフォーマンス測定ツール(たとえば、ネットワーク監視およびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車交通量監視などに関するリアルタイムイベントを含み得る。また、サーバ1612は、クライアントコンピューティングデバイス1602、1604、1606、および1608の1つ以上の表示装置を介してデータフィードおよび/またはリアルタイムイベントを表示するための1つ以上のアプリケーションを含んでもよい。
【0160】
また、分散システム1600は、1つ以上のデータベース1614および1616を含んでもよい。これらのデータベースは、ユーザ識別情報、および本開示の実施形態が用いるその他の情報などの情報を格納するためのメカニズムを提供し得る。データベース1614および1616は、いろいろな場所に存在し得る。一例として、データベース1614および1616のうちの1つ以上は、サーバ1612にローカルな(および/または存在する)非一時的な記憶媒体上に存在し得る。これに代えて、データベース1614および1616は、サーバ1612から遠隔の場所に存在し、ネットワークベースまたは専用の接続を通してサーバ1612と通信していてもよい。一組の実施形態では、データベース1614および1616は、SAN(ストレージエリアネットワーク)に存在し得る。同様に、サーバ1612に起因する機能を実行するための必要なファイルは、いずれも、サーバ1612上のローカルな場所および/またはサーバ1612から遠隔の場所に、適宜、格納され得る。一組の実施形態では、データベース1614および1616は、SQLフォーマットのコマンドに応答してデータを格納、更新、および検索するようになされたOracleが提供するデータベースなど、リレーショナルデータベースを含んでもよい。
【0161】
図17は、本開示の実施形態を実現するために使用され得る例示的なコンピュータシステム1700を示す図である。いくつかの実施形態では、コンピュータシステム1700を使用して、上述の様々なサーバおよびコンピュータシステムのうちのいずれかを実現し得る。
図17に示すように、コンピュータシステム1700は、バスサブシステム1702を介していくつかの周辺サブシステムと通信する処理サブシステム1704を含む、様々なサブシステムを備える。これらの周辺サブシステムは、処理高速化装置1706と、I/Oサブシステム1708と、ストレージサブシステム1718と、通信サブシステム1724とを備え得る。ストレージサブシステム1718は、有形のコンピュータ読み取り可能な記憶媒体1722と、システムメモリ1710とを備え得る。
【0162】
バスサブシステム1702は、コンピュータシステム1700の様々なコンポーネントおよびサブシステムを互いに意図した通りに通信させるための機構を提供する。バスサブシステム1702は、1つのバスとして図示されているが、バスサブシステムの別の実施形態は、複数のバスを利用し得る。バスサブシステム1702は、メモリコントローラのメモリバス、周辺バス、および各種のバスアーキテクチャを使用するローカルバスを含む、いくつかの種類のバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、ISA(Industry Standard Architecture)バス、MCA(Micro Channel Architecture)バス、EISA(Enhanced ISA)バス、VESA(Video Electronics Standards Association)ローカルバス、およびPCI(Peripheral Component Interconnect)バスを含んでもよく、これらは、IEEE P1386.1標準規格に準拠して製造されるMezzanineバスなどとして実現され得る。
【0163】
処理サブシステム1704は、コンピュータシステム1700の動作を制御し、1つ以上の処理装置1732、1734などを備え得る。処理装置は、シングルコア・プロセッサまたはマルチコア・プロセッサを含む1つ以上のプロセッサ、プロセッサの1つ以上のコア、またはそれらの組合せを含んでもよい。いくつかの実施形態では、処理サブシステム1704は、グラフィックスプロセッサ、デジタル・シグナル・プロセッサ(DSP)など、1つ以上の専用コプロセッサを含み得る。いくつかの実施形態では、処理サブシステム1704の処理装置の一部またはすべては、特定用途向け集積回路(ASIC)、またはフィールドプログラマブルゲートアレイ(FPGA)など、カスタム回路を使用して実現され得る。
【0164】
いくつかの実施形態では、処理サブシステム1704に含まれる処理装置は、システムメモリ1710に、または、コンピュータ読み取り可能な記憶媒体1722上に格納された命令を実行できる。様々な実施形態では、処理装置は、いろいろなプログラムまたはコード命令を実行し、複数の同時に実行しているプログラムまたはプロセスを維持できる。いつでも、実行されるプログラムコードの一部またはすべては、システムメモリ1710に、および/または、1つ以上の記憶装置上を潜在的に含む、コンピュータ読み取り可能な記憶媒体1710上に存在し得る。適したプログラミングを通して処理サブシステム1704は、使用パターンに応じてドキュメント(たとえば、ウェブページ)を動的に変更するための上述の様々な機能を提供できる。
【0165】
特定の実施形態では、カスタマイズされた処理を実行するための、または、コンピュータシステム1700によって実行される全体的な処理が高速化するように、処理サブシステム1704によって実行される処理のうちのいくつかの負荷を軽減させるための処理高速化装置1706が提供され得る。
【0166】
I/Oサブシステム1708は、コンピュータシステム1700に情報を入力するためのデバイスおよびメカニズム、および/またはコンピュータシステム1700を介してもしくはコンピュータシステム1700から情報を出力するためのデバイスおよびメカニズムを含んでもよい。一般に、「入力装置」という用語を用いることは、コンピュータシステム1700に情報を入力するためのあらゆる種類のデバイスおよびメカニズムを含む意図がある。ユーザーインターフェース入力装置は、たとえば、キーボード、マウスもしくはトラックボールなどのポインティングデバイス、タッチパッドもしくはディスプレイに組み込まれたタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、ボイスコマンド認識システムを有する音声入力装置、マイクロホン、および他の種類の入力装置を含んでもよい。また、ユーザーインターフェース入力装置は、ユーザが入力装置を制御すること、および入力装置とやり取りすることを可能にするMicrosoft Kinect(登録商標)モーションセンサなどの動き検知デバイスおよび/またはジェスチャ認識デバイス、Microsoft Xbox(登録商標)360ゲームコントローラ、ジェスチャコマンドおよび音声コマンドを用いた入力を受け付けるためのインターフェースを提供するデバイスを含んでもよい。また、ユーザーインターフェース入力装置は、ユーザの目の動作(たとえば、写真を撮影しているおよび/またはメニュー選択を行っている間の「まばたき」)を検出し、目の挙動(eye gesture)を入力装置(たとえば、Google Glass(登録商標))への入力として変形させるGoogle Glass(登録商標)まばたき検出装置などのアイジェスチャ認識デバイスを含んでもよい。これに加えて、ユーザーインターフェース入力装置は、ユーザがボイスコマンドによって音声認識システム(たとえば、Siri(登録商標)ナビゲータ)とやり取りすることを可能にする音声認識検知デバイスを含んでもよい。
【0167】
その他のユーザーインターフェース入力装置として、3次元(3D)マウス、ジョイスティックもしくはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレーヤ、ウェブカム、イメージスキャナ、指紋スキャナ、バーコードリーダ3Dスキャナ、3Dプリンタ、レーザー測距器、および視線追跡装置などのオーディオ/ビジュアル装置などが挙げられるが、これに限定されない。これに加えて、ユーザーインターフェース入力装置は、たとえば、コンピュータ断層撮影法、磁気共鳴画像、陽電子放出断層撮影装置、超音波検査デバイスなど、医用画像入力装置を含んでもよい。また、ユーザーインターフェース入力装置は、たとえば、MIDIキーボード、デジタル楽器などのオーディオ入力装置を含んでもよい。
【0168】
ユーザーインターフェース出力装置は、表示サブシステム、インジケーターライト、または音声出力装置などの非視覚的表示装置などを含んでもよい。表示サブシステムは、ブラウン管(CRT)、液晶ディスプレイ(LCD)またはプラズマディスプレイを使用するものなどのフラットパネル表示装置、投影装置、タッチスクリーンなどであってもよい。一般に、用語「出力装置」の使用は、コンピュータシステム1700からユーザまたは他のコンピュータに情報を出力するためのあらゆる種類のデバイスおよびメカニズムを含むことを意図する。たとえば、ユーザーインターフェース出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車ナビゲーションシステム、作図装置、音声出力装置、およびモデムなど、文字、図形、および音声/映像情報を視覚的に伝えるいろいろな表示装置を含み得るが、これに限定されない。
【0169】
ストレージサブシステム1718は、コンピュータシステム1700が使用する情報を格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム1718は、いくつかの実施形態の機能を提供する基本プログラミング構造およびデータ構造を格納するための有形の非一時的なコンピュータ読み取り可能な記憶媒体を提供する。処理サブシステム1704によって実行されると上述の機能を提供するソフトウェア(プログラム、コードモジュール、命令)がストレージサブシステム1718に格納され得る。ソフトウェアは、処理サブシステム1704の1つ以上の処理装置によって実行され得る。また、ストレージサブシステム1718は、本開示に応じて使用されるデータを格納するためのリポジトリを提供し得る。
【0170】
ストレージサブシステム1718は、揮発性および不揮発性メモリ素子を含む、1つ以上の非一時的なメモリ素子を含んでもよい。
図17に示すように、ストレージサブシステム1718は、システムメモリ1710と、コンピュータ読み取り可能な記憶媒体1722とを備える。システムメモリ1710は、プログラムを実行中に命令およびデータを格納するための揮発性のメインRAM(Random Access Memory)、および、固定の命令が格納される不揮発性ROM(Read Only Memory)またはフラッシュメモリを含む、いくつかのメモリを含んでもよい。いくつかの実装形態では、起動中などで、コンピュータシステム1700内の要素間で情報を転送することを助ける基本ルーチンを含むBIOS(Basic Input/Output システム)は、ROMに格納され得る。RAMは、処理サブシステム1704が現在操作および実行していているデータおよび/またはプログラムモジュールを含んでもよい。いくつかの実装形態では、システムメモリ1710は、SRAM(Static Random Access Memory)またはDRAM(Dynamic Random Access Memory)など、複数の異なる種類のメモリを含んでもよい。
【0171】
一例として、
図17に示すように、システムメモリ1710は、クライアントアプリケーション、ウェブブラウザ、ミッドティア・アプリケーション、リレーショナルデータベース管理システム(RDBMS)などのアプリケーションプログラム1712と、プログラムデータ1714と、オペレーティングシステム1716とを含んでもよいが、これらに限定されない。一例として、オペレーティングシステム1716は、様々なバージョンのMicrosoft Windows(登録商標)、Apple Macintosh(登録商標)、および/もしくはLinuxオペレーティングシステム、いろいろな流通しているUNIX(登録商標)もしくはUNIXに似たオペレーティングシステム(いろいろなGNU/Linuxオペレーティングシステム、Google Chrome(登録商標)OSなどを含むが、これらに限定されない)、ならびに/またはiOS、Windows(登録商標)Phone、Android(登録商標)OS、BlackBerry(登録商標)10OS、およびPalm(登録商標)OSオペレーティングシステムなど、モバイルオペレーティングシステムを含んでもよい。
【0172】
コンピュータ読み取り可能な記憶媒体1722は、いくつかの実施形態の機能を提供するプログラミング構造およびデータ構造を格納し得る。処理サブシステム1704によって実行されると、プロセッサに上述の機能を提供するソフトウェア(プログラム、コードモジュール、命令)がストレージサブシステム1718に格納され得る。一例として、コンピュータ読み取り可能な記憶媒体1722は、ハードディスクドライブなどの不揮発性メモリ、磁気ディスクドライブ、CD ROM、DVD、Blu-Ray(登録商標)ディスクなどの光ディスクドライブまたは他の光学媒体を含んでもよい。コンピュータ読み取り可能な記憶媒体1722は、Zip(登録商標)ドライブ、フラッシュメモリーカード、USB(Universal Serial Bus)フラッシュドライブ、SD(Secure Digital)カード、DVDディスク、デジタルビデオテープなどを含んでもよいが、これらに限定されない。コンピュータ読み取り可能な記憶媒体1722は、フラッシュメモリベースのSSD、エンタープライズフラッシュドライブ、ソリッドステートROMなど、不揮発性メモリに基づくSSD(Solid-State Drives)、ソリッドステートRAM、動的RAM、静的RAMなど、揮発性メモリに基づくSSD、DRAMベースのSSD、磁気抵抗RAM(MRAM)SSD、およびDRAMのSSDとフラッシュメモリベースのSSDとの組合せを使用するハイブリッドSSDを含んでもよい。コンピュータ読み取り可能な媒体1722は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびコンピュータシステム1700用の他のデータのストレージを提供し得る。
【0173】
特定の実施形態では、ストレージサブシステム1700は、コンピュータ読み取り可能な記憶媒体1722にさらに接続され得るコンピュータ読み取り可能な記憶媒体リーダ1720を含んでもよい。システムメモリ1710と合わせて、必要に応じてシステムメモリ1710と組み合わせて、コンピュータ読み取り可能な記憶媒体1722は、遠隔の記憶装置、ローカル記憶装置、固定記憶装置、および/またはリム―バブル記憶装置、ならびにコンピュータ読み取り可能な情報を格納するための記憶媒体を包括的に表し得る。
【0174】
特定の実施形態では、コンピュータシステム1700は、1つ以上の仮想マシンを実行するためのサポートを提供し得る。コンピュータシステム1700は、仮想マシンの構成および管理を容易にするためのハイパーバイザなどのプログラムを実行し得る。各仮想マシンには、メモリ、コンピュータ(たとえば、プロセッサ、コア)、I/O、およびネットワーキングリソースが割り当てられ得る。各仮想マシンは、それ自体のオペレーティングシステムを実行し得る。このオペレーティングシステムは、コンピュータシステム1700が実行する他の仮想マシンによって実行されるオペレーティングシステムと同じまたは異なってもよい。したがって、複数のオペレーティングシステムは、コンピュータシステム1700によって同時に実行される可能性があってもよい。各仮想マシンは、一般に、その他の仮想マシンとは別に実行される。
【0175】
通信サブシステム1724は、他のコンピュータシステムおよびネットワークへのインターフェースを提供する。通信サブシステム1724は、コンピュータシステム1700からデータを受信し、コンピュータシステム1700から他のシステムにデータを送信するためのインターフェースとして機能する。たとえば、通信サブシステム1724は、1つ以上のクライアントコンピューティングデバイスと情報を送受信するためのクライアントコンピューティングデバイスへの通信チャネルを、インターネットを介してコンピュータシステム1700が確立することを可能にし得る。これに加えて、通信サブシステム1724を用いて、ログインに成功したという通知、または特権アカウントの管理者から要求側ユーザに対してパスワードを再入力するよう求める通知を伝達し得る。
【0176】
通信サブシステム1724は、有線通信プロトコルおよび/またはワイヤレス通信プロトコルの両方をサポートし得る。たとえば、特定の実施形態では、通信サブシステム1724、ワイヤレス音声ネットワークもしくは/またはデータネットワークにアクセスするためのRF(Radio Frequency)送信コンポーネント(たとえば、携帯電話技術、3G、4G、もしくはEDGE(Enhanced Data Rates For Global Evolution)などの次世代データネットワークテクノロジー、WiFi(IEEE 802.11ファミリー標準規格)、他の移動オブジェクト通信技術、またはそれらの任意の組合せを使用する)、GPS(Global Positioning システム)受信コンポーネント、および/または他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム1724は、ワイヤレスインタフェースに加えて、またはワイヤレスインタフェースの代わりに、有線ネットワーク接続性(たとえば、Ethernet)を提供できる。
【0177】
通信サブシステム1724は、様々な形でデータを受送信できる。たとえば、いくつかの実施形態では、通信サブシステム1724は、入力通信文を、構造化および/または非構造化データフィード1726、イベントストリーム1728、イベント更新1730などの形で受信し得る。たとえば、通信サブシステム1724は、Twitter(登録商標)フィード、Facebook(登録商標)の更新、RSS(Rich Site Summary)フィードなどのwebフィード、および/または1つ以上のサードパーティ情報ソースからのリアルタイム更新など、ソーシャルメディアネットワークおよび/または他のコミュニケーションサービスのユーザから、データフィード1726をリアルタイムで受信する(または送る)ように構成され得る。
【0178】
特定の実施形態では、通信サブシステム1724は、連続したデータストリームの形でデータを受信するように構成されてもよく、連続したデータストリームは、本質的にはっきりとした終端がない、連続または無限の、リアルタイムイベントおよび/またはイベント更新1730のイベントストリーム1728を含んでもよい。連続データを生成するアプリケーションとして、たとえば、センサーデータアプリケーション、チッカー、ネットワークパフォーマンス測定ツール(たとえば、ネットワーク監視およびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車交通量監視などが挙げられ得る。
【0179】
また、通信サブシステム1724は、コンピュータシステム1700に接続された1つ以上のストリーミングデータソースコンピュータと通信中であり得る1つ以上のデータベースに、構造化および/または非構造化データフィード1726、イベントストリーム1728、イベント更新1730などを出力するように構成され得る。
【0180】
コンピュータシステム1700は、手のひらサイズのポータブルデバイス(たとえば、iPhone(登録商標)携帯電話、IPad(登録商標)コンピューティングタブレット、PDA)、ウェアラブルデバイス(たとえば、Google Glass(登録商標)ヘッドマウントディスプレイ)、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、様々な種類のうちの1つであり得る。
【0181】
変わり続けるというコンピュータおよびネットワークの性質により、
図17に示すコンピュータシステム1700の説明は、具体例にすぎない。
図17に示すシステムよりも多いまたは少ないコンポーネントを有する多くの他の構成が可能である。本明細書に記載の開示および教示に基づいて、当業者は、様々な実施形態を実現するための他のやり方および/または方法が分かるだろう。
【0182】
図面のいくつかに示すシステムは、様々な構成で提供され得る。いくつかの実施形態では、これらのシステムは、システムの1つ以上の構成要素が1つ以上のクラウドインフラストラクチャシステムにおける1つ以上のネットワーク間で分散される分散システムとして構成され得る。
【0183】
クラウドインフラストラクチャシステムは、1つ以上のサーバコンピューティングデバイス、ネットワーク機器、および/または記憶装置の集まりである。これらのリソースは、クラウドサービスプロバイダによって分けられて、その顧客に何らかの方法で割り当てられ得る。たとえば、カリフォルニア州レッドウッドショアーズのオラクル社などのクラウドサービスプロバイダは、SaaS(Software as a Service)分類下で提供される1つ以上のサービス、PaaS(Platform as a Service)分類下で提供されるサービス、IaaS(Infrastructure as a Service)分類下で提供されるサービス、または、混合サービスを含む他の分類のサービスを様々な種類のクラウドサービスを提供し得るが、これらに限定されない。SaaSサービスとして、Oracle Fusionアプリケーションなどのオンデマンドアプリケーション一式を構築および届ける機能が挙げられるが、これらに限定されない。SaaSサービスは、クラウドインフラストラクチャシステム上で実行中のアプリケーションを、顧客がアプリケーション用のソフトウェアを購入する必要なしに利用することを可能にする。PaaSサービスとして、JCS(Oracle Java Cloud Service)、DBCS(Oracle Database Cloud Service)など、組織(Oracleなど)が既存のアプリケーションを共有の共通アーキテクチャ上に1つにまとめることを可能にするサービス、およびプラットフォームが提供する共有サービスを活用する新しいアプリケーションを作る能力などが挙げられるが、これらに限定されない。IaaSサービスは、SaaSプラットフォームおよびPaaSプラットフォームが提供するサービスを利用している顧客のための、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースなど、礎となるコンピューティングリソースの管理および制御を容易にするであろう。
【0184】
図18は、本開示の実施形態に係る、実施形態のシステムの1つ以上の構成要素が提供するサービスがクラウドサービスとして提供され得るシステム環境1800の1つ以上の構成要素の簡略ブロック図である。図示した実施形態では、システム環境1800は、1つ以上のクライアントコンピューティングデバイス1804、1806、および1808を含む。1つ以上のクライアントコンピューティングデバイス1804、1806、および1808は、ユーザによって、クラウドサービスを提供するクラウドインフラストラクチャシステム1802と対話するために使用されもよい。クライアントコンピューティングデバイスは、ウェブブラウザ、プロプライエタリ・クライアントアプリケーション(たとえば、Oracle Forms)、または他のアプリケーションなど、クライアントアプリケーションを操作するように構成され得る。クライアントアプリケーションは、クライアントコンピューティングデバイスのユーザによって、クラウドインフラストラクチャシステム1802と対話を行ってクラウドインフラストラクチャシステム1802が提供するサービスを利用するために使用され得る。
【0185】
図に示したクラウドインフラストラクチャシステム1802が、図示された構成要素以外の構成要素を有し得ることを理解されたい。さらに、図に示す実施形態は、本開示の実施形態を組み込み得るクラウドインフラストラクチャシステムの一例に過ぎない。他のいくつかの実施形態では、クラウドインフラストラクチャシステム1802は、図に示す構成要素よりも多いまたは少ない数の構成要素を有してもよく、2つ以上の構成要素を組み合わせてもよく、または構成要素の構成もしくは配置が異なっていてもよい。
【0186】
クライアントコンピューティングデバイス1804、1806、および1808は、1602、1604、1606、および1608に関して上述したクライアントコンピューティングデバイスと同様のデバイスであってもよい。
【0187】
例示的なシステム環境1800は、3つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされ得る。センサ付きデバイスなど、他のデバイスがクラウドインフラストラクチャシステム1802と対話を行ってもよい。
【0188】
ネットワーク(複数可)1810は、クライアント1804、1806、および1808とクラウドインフラストラクチャシステム1802との間のデータの通信およびやり取りを容易にし得る。各ネットワークは、ネットワーク(複数可)1810に関して上述したプロトコルを含む各種市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者にとってなじみのある任意の種類のネットワークであってもよい。
【0189】
クラウドインフラストラクチャシステム1802は、サーバ1812に関して上述したコンピュータおよびサーバを含み得る1台以上のコンピュータおよび/またはサーバから構成され得る。
【0190】
特定の実施形態では、クラウドインフラストラクチャシステムが提供するサービスは、オンラインのデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされたオフィススイートドキュメント連携サービス、データベース処理、管理されたテクニカルサポートサービスなど、クラウドインフラストラクチャシステムのユーザが要求すれば利用可能になるサービスのホストを含んでもよい。クラウドインフラストラクチャシステムが提供するサービスは、動的にスケール変更してそのユーザのニーズを満たすことができる。クラウドインフラストラクチャシステムが提供するサービスを具体的にインスタンス化したものは、本明細書において、「サービスインスタンス」と称される。一般に、インターネットなどの通信ネットワークを介してユーザが利用できるようになる、クラウドサービスプロバイダのシステムからのいずれのサービスも、「クラウドサービス」と称される。パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客所有のオンプレミス・サーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介して、要求に基づいてアプリケーションを注文および使用すればよい。
【0191】
いくつかの例において、コンピュータネットワークのクラウドインフラストラクチャにおけるサービスは、ストレージ、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェアアプリケーションへの保護されたコンピュータネットワークアクセス、もしくはクラウドベンダーがユーザに提供するその他のサービス、または、当技術分野で周知の上記以外のその他のサービスを含んでもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへのパスワード保護されたアクセスを含み得る。別の例として、サービスは、ネットワークで結ばれた開発者が私的使用するための、ウェブサービスベースのホストされたリレーショナルデータベースおよびスクリプト言語のミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上にホストされた電子メールソフトウェアアプリケーションへのアクセスを含み得る。
【0192】
特定の実施形態では、クラウドインフラストラクチャシステム1802は、顧客にセルフサービス、サブスクリプション方式で、伸縮自在にスケーラブルであり、信頼性があり、かつ高い可用性を有するセキュアな方法で届けられるアプリケーションのスイート、ミドルウェア、およびデータベースサービス提供物を含んでもよい。このようなクラウドインフラストラクチャシステムの例が、本願の譲受人が提供するオラクルパブリッククラウド(Oracle Public Cloud)である。
【0193】
様々な実施形態では、クラウドインフラストラクチャシステム1802は、クラウドインフラストラクチャシステム1802が提供するサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理、および追跡するようになされ得る。クラウドインフラストラクチャシステム1802は、それぞれ異なるデプロイメントモデルを介してクラウドサービスを提供し得る。たとえば、サービスは、パブリッククラウドモデル下で提供され得る。パブリッククラウドモデルでは、クラウドインフラストラクチャシステム1802は、(たとえば、オラクル所有の)クラウドサービスを提供する組織が所有しており、一般大衆またはそれぞれ異なる産業企業でサービスが使用できるようになる。別の例として、サービスは、クラウドインフラストラクチャシステム1802が1つの組織のためだけに動かされるプライベートクラウドモデル下で提供されてもよく、組織内の1つ以上のエンティティのためのサービスを提供し得る。また、クラウドサービスは、コミュニティクラウドモデル下で提供され得る。コミュニティクラウドモデルでは、クラウドインフラストラクチャシステム1802およびクラウドインフラストラクチャシステム1802が提供するサービスが、関連コミュニティ内のいくつかの組織によって共有される。クラウドサービスは、ハイブリッドクラウドモデル下で提供され得る。ハイブリッドクラウドモデルとは、2つ以上の異なるモデルの組合せである。
【0194】
いくつかの実施形態では、クラウドインフラストラクチャシステム1802が提供するサービスは、SaaS(Software as a Service)分類、PaaS(Platform as a Service)分類、IaaS(Infrastructure as a Service)分類、または混合サービスを含む、他の分類下で提供される1つ以上のサービスを含んでもよい。顧客は、サブスクリプションのオーダーによって、クラウドインフラストラクチャシステム1802が提供する1つ以上のサービスをオーダーし得る。次に、クラウドインフラストラクチャシステム1802は、処理を実行して、顧客のサブスクリプションのオーダーにあるサービスを提供する。
【0195】
いくつかの実施形態ではクラウドインフラストラクチャシステム1802が提供するサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを含んでもよいが、これらに限定されない。いくつかの例において、アプリケーションサービスは、SaaSサービスを介してクラウドインフラストラクチャシステムによって提供され得る。SaaSプラットフォームは、SaaS分類に該当するクラウドサービスを提供するように構成され得る。たとえば、SaaSプラットフォームは、オンデマンドアプリケーション一式を構築し、統合開発/デプロイメントプラットフォームに届けるための機能を提供し得る。SaaSプラットフォームは、SaaSサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御し得る。SaaSプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、アプリケーションサービスを、別のライセンスおよびサポートを購入する必要なしに、入手できる。様々な異なるSaaSサービスが提供され得る。例として、大きな組織のための販売実績管理、エンタープライズ統合、およびビジネス上の柔軟性に対するソリューションを提供するサービスなどが挙げられるが、これに限定されない。
【0196】
いくつかの実施形態では、プラットフォームサービスは、PaaSプラットフォームを介してクラウドインフラストラクチャシステムによって提供され得る。PaaSプラットフォームは、PaaS分類に該当するクラウドサービスを提供するように構成され得る。プラットフォームサービスとして、組織(Oracleなど)が既存のアプリケーションを共有の共通アーキテクチャ上に1つにまとめることを可能にするサービス、およびプラットフォームが提供する共有サービスを活用する新しいアプリケーションを作る能力などが挙げられるが、これらに限定されない。PaaSプラットフォームは、PaaSサービスを提供するための、基礎となるソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、PaaS クラウドインフラストラクチャシステムが提供するサービスを、ライセンスおよびサポートを別に購入する必要なしに、取得できる。プラットフォームサービスとして、JCS(Oracle Java Cloud Service)、DBCS(Oracle Database Cloud Service)など、およびその他が挙げられるが、これらに限定されない。
【0197】
PaaSプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムがサポートするプログラミング言語およびツールを採用することができ、また、デブロイされたサービスを管理することができる。いくつかの実施形態において、クラウドインフラストラクチャシステムが提供するプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス(たとえば、Oracle Fusion Middlewareサービス)、およびJavaクラウドサービスを含んでもよい。一実施形態では、データベースクラウドサービスは、共有サービスデプロイメントモデルをサポートし得る。共有サービスデプロイメントモデルは、組織が、データベースリソースをプールし、データベース・クラウドの形のサービスとしてデータベースを顧客に提供することを可能にする。ミドルウェアクラウドサービスは、顧客が様々な業務アプリケーションを開発およびデプロイするためのプラットフォームを提供してもよく、Javaクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてJavaアプリケーションをデプロイするためのプラットフォームを提供し得る。
【0198】
クラウドインフラストラクチャシステムにおいて、IaaSプラットフォームによって、様々な異なるインフラストラクチャサービスが提供され得る。インフラストラクチャサービスは、SaaSプラットフォームおよびPaaSプラットフォームが提供するサービスを利用している顧客のための、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースなど、基礎となるコンピューティングリソースの管理および制御を容易にする。
【0199】
特定の実施形態では、クラウドインフラストラクチャシステム1802は、クラウドインフラストラクチャシステムの顧客に様々なサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース1830を含んでもよい。一実施形態では、インフラストラクチャリソース1830は、PaaSプラットフォームおよびSaaSプラットフォームが提供するサービスを実行するための、サーバなどのハードウェアと、ストレージと、ネットワーキングリソースとの予め統合された最適な組合せ、および他のリソースを含んでもよい。
【0200】
いくつかの実施形態では、クラウドインフラストラクチャシステム1802におけるリソースは、複数のユーザによって共有され、要求に応じて動的に再割り当てされ得る。これに加えて、リソースは、それぞれ異なるタイムゾーンのユーザに割り当てられ得る。たとえば、クラウドインフラストラクチャシステム1830は、第1のタイムゾーンにいる第1セットのユーザが、指定された時間数、クラウドインフラストラクチャシステムのリソースを利用することを可能にした後、同じリソースを、異なるタイムゾーンに位置する別のセットのユーザへ再割り当てすることを可能にし、リソースの利用を最大限に活用することができる。
【0201】
特定の実施形態では、クラウドインフラストラクチャシステム1802のそれぞれ異なるコンポーネントまたはモジュールによって、かつ、クラウドインフラストラクチャシステム1802が提供するサービスによって共有される、いくつかの内部共有サービス1832が提供され得る。これらの内部共有サービスは、セキュリティ/IDサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャン/ホワイトリストサービス、可用性の高いバックアップ/リカバリサービス、クラウドサポート、Eメールサービス、通知サービス、ファイル転送サービスなどを可能にするためのサービスを含み得るが、これらに限定されない。
【0202】
特定の実施形態では、クラウドインフラストラクチャシステム1802は、クラウドインフラストラクチャシステムにおけるクラウドサービス(たとえば、SaaSサービス、Paaサービス、およびIaaSサービス)の包括的な管理を提供し得る。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム1802などが受信した顧客のサブスクリプションをプロビジョニング、管理、および追跡するための機能を含んでもよい。
【0203】
一実施形態では、図に示すように、クラウド管理機能は、オーダー管理モジュール1820、オーダーオーケストレーションモジュール1822、オーダープロビジョニングモジュール1824、オーダー管理/監視モジュール1826、およびID管理モジュール1828など、1つ以上のモジュールによって提供され得る。これらのモジュールは、1つ以上のコンピュータおよび/またはサーバを含んでもよく、または、これらを使用して提供され得る。1つ以上のコンピュータおよび/またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な配置および/または組合せであり得る。
【0204】
例示的な動作1834において、クライアントデバイス1804、1806または1808などのクライアントデバイスを使用している顧客は、クラウドインフラストラクチャシステム1802が提供する1つ以上のサービスを要求し、クラウドインフラストラクチャシステム1802が提供する1つ以上のサービスのサブスクリプションのオーダーをすることによってクラウドインフラストラクチャシステム1802とやり取りし得る。特定の実施形態では、顧客は、クラウドUI1812、クラウドUI1814および/またはクラウドUI1816などのクラウドUI(ユーザインタフェース)にアクセスし、これらのUIを介してサブスクリプションのオーダーを行ってもよい。顧客がオーダーをすることに応答してクラウドインフラストラクチャシステム1802が受信したオーダー情報は、この顧客を特定する情報、および、顧客がサブスクリプションをする予定である、クラウドインフラストラクチャシステム1802が提供する1つ以上のサービスを含んでもよい。
【0205】
顧客によって注文がされた後、クラウドUI1812、1814、および/または1816を介してオーダー情報が受け付けられる。
【0206】
動作1836において、この注文は、オーダーデータベース1818に格納される。オーダーデータベース1818は、クラウドインフラストラクチャシステム1818によって操作され、かつ、他のシステム要素と共に操作されるいくつかのデータベースのうちの1つであり得る。
【0207】
動作1838において、オーダー情報がオーダー管理モジュール1820に転送される。場合によっては、オーダー管理モジュール1820は、注文の確認、確認後の注文の登録など、注文に関する課金機能および会計機能を実行するように構成され得る。
【0208】
動作1840において、注文に関する情報がオーダーオーケストレーションモジュール1822に伝送される。オーダーオーケストレーションモジュール1822は、このオーダー情報を利用して、顧客が行った注文に関するサービスおよびリソースのプロビジョニングをオーケストレーションし得る。場合によっては、オーダーオーケストレーションモジュール1822は、リソースのプロビジョニングをオーケストレーションして、オーダープロビジョニングモジュール1824のサービスを使用してサブスクリプションされているサービスをサポートし得る。
【0209】
特定の実施形態では、オーダーオーケストレーションモジュール1822は、各注文に関連する業務の流れの管理を可能にし、ビジネスロジックを適用して、注文がプロビジョニングに進むべきかどうかを判断する。動作1842において、新しいサブスクリプションの注文を受けると、オーダーオーケストレーションモジュール1822は、サブスクリプションの注文を満たすために必要なリソースを割り当ててこれらのリソースを構成する要求をオーダープロビジョニングモジュール1824に送信する。オーダープロビジョニングモジュール1824は、顧客が申し込んだサービスのためのリソースの割り当てを有効にする。オーダープロビジョニングモジュール1824は、クラウドインフラストラクチャシステム1800が提供するクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理実施層との間に抽象度を設ける。よって、サービスおよびリソースがオンザフライで実際にプロビジョニングされたかどうか、または予めプロビジョニングされて要求された場合にのみ割り当てられたかどうかなどの実装の詳細からオーダーオーケストレーションモジュール1822を切り離すことができる。
【0210】
動作1844において、サービスおよびリソースがプロビジョニングされると、クラウドインフラストラクチャシステム1802のオーダープロビジョニングモジュール1824によって、クライアントデバイス1804、1806、および/または1808上の顧客に、提供されたサービスについての通知が送信され得る。動作1846において、オーダー管理/監視モジュール1826によって顧客のサブスクリプションの注文が管理および追跡され得る。場合によっては、オーダー管理/監視モジュール1826は、サブスクリプションの注文におけるサービスに関する使用統計データ、たとえば、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムの稼働時間およびシステムの休止時間などを収集するように構成され得る。
【0211】
特定の実施形態では、クラウドインフラストラクチャシステム1800は、ID管理モジュール1828を含んでもよい。ID管理モジュール1828は、クラウドインフラストラクチャシステム1800におけるアクセス管理および承認サービスなどのIDサービスを提供するように構成され得る。いくつかの実施形態では、ID管理モジュール1828は、クラウドインフラストラクチャシステム1802が提供するサービスを利用したい顧客についての情報を管理し得る。このような情報は、このような顧客のIDを認証する情報、および、様々なシステムリソース(たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど)に対してそれらの顧客がどのような操作を行うことが承認されているのかを記述する情報を含み得る。また、ID管理モジュール1828は、各顧客についての記述情報、およびその記述情報が誰によってどのようにアクセスおよび変更され得るかについての記述情報の管理を含んでもよい。
【0212】
具体的な本開示の実施形態を説明したが、様々な変更例、代替例、代替的な構成、および均等物も本開示の範囲内に包含される。本開示の実施形態は、特定の具体的なデータ処理環境内の動作に制限されず、複数のデータ処理環境内で自由に動作することができる。これに加えて、特定の一続きのトランザクションおよびステップを使用して本開示の実施形態を説明したが、本開示の範囲は、記載の一続きのトランザクションおよびステップに限られないことは、当業者に明らかであるはずである。上述の実施形態の様々な特徴および態様は、個々に、または共同で使用され得る。
【0213】
さらに、ハードウェアとソフトウェアとの特定の組合せを使用して本開示の実施形態を説明したが、ハードウェアとソフトウェアとの他の組合せも、本開示の範囲内であることを認識されたい。本開示の実施形態は、ハードウェアのみ、もしくは、ソフトウェアのみで実現されてもよく、またはそれらの組合せを使用して実現され得る。本明細書に記載の様々なプロセスは、同じプロセッサまたは任意の組合せのそれぞれ異なるプロセッサ上で実現できる。よって、コンポーネントまたはモジュールが特定の動作を実行するように構成されると説明されている箇所では、このような構成は、たとえば、この動作を実行するように電子回路を設計することによって、この動作を実行するようにプログラム可能な電子回路(マイクロプロセッサなど)をプログラムすることによって、またはそれらの任意の組合せによって達成できる。プロセスは、プロセス間通信のための従来技術を含む、いろいろな技術を使用して通信できるが、これに限定されず、それぞれ異なるペアプロセスは、異なる技術を使用してもよく、プロセスの同じペアは、異なる技術を別々のタイミングで使用し得る。
【0214】
明細書および図面は、厳密ではなく一例にすぎないと適宜みなされるべきである。しかしながら、添付の特許請求の範囲に記載のより広義の趣旨および範囲から逸脱することなく、追加、減算、削除、および他の変更ならびに変形がそれらに対してなされ得るということは明白であろう。したがって、具体的な本開示の実施形態を説明したが、これらは、限定を意図しない。様々な変更例および均等物は、添付の特許請求の範囲内である。
【国際調査報告】