JP2023508729A - クラウドインフラストラクチャ上における自律的テラフォーム化 - Google Patents

クラウドインフラストラクチャ上における自律的テラフォーム化 Download PDF

Info

Publication number
JP2023508729A
JP2023508729A JP2022540590A JP2022540590A JP2023508729A JP 2023508729 A JP2023508729 A JP 2023508729A JP 2022540590 A JP2022540590 A JP 2022540590A JP 2022540590 A JP2022540590 A JP 2022540590A JP 2023508729 A JP2023508729 A JP 2023508729A
Authority
JP
Japan
Prior art keywords
subnets
cloud infrastructure
clusters
availability
provisioned
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022540590A
Other languages
English (en)
Other versions
JPWO2021138224A5 (ja
Inventor
スネハシス，ソウミャ
パリダ，スワヤム・シッダーント
Original Assignee
オラクル・インターナショナル・コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Publication of JP2023508729A publication Critical patent/JP2023508729A/ja
Publication of JPWO2021138224A5 publication Critical patent/JPWO2021138224A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

インフラストラクチャ・アズ・コード（ＩａＣ）ツールにおいてクラウドサービスを定義するためのプロセスは、実行時に、クラスタ、可用性ドメイン、計算ノード、および／またはロードバランサの数を動的に決定するように設計される。これらの値は、次いで、サービスにおいて計算ノードおよびロードバランサノードの各々のためにサブネットを生成するためにクラス無しドメイン間ルーティング（ＣＩＤＲ）スライス操作のために必要とされるサブネットレベルの数を決定するために使用される。ＩａＣ言語はネスト化されたループ制御構造体を提供しないので、サブネットの各々に対するラベルは、ラベル要素のデカルト積を使用して生成および割り当てられ得る。これらのラベルは、ネスト化されたループ構造の効果をシミュレートするためにリソースがスクリプトにおいて複製されるたびにインクリメントされるカウント変数によって変更され得る。

Description

関連出願に対する相互参照
本出願は、２０１９年１２月３０日に出願された、「AUTONOMOUS TERRAFORMING ON CLOUD INFRASTRUCTURES（クラウドインフラストラクチャ上における自律的テラフォーム化）」と題される米国特許出願第１６／７３０，６５６号の利益および優先権を主張し、その出願の全体をここに引用により援用する。
背景
クラウドコンピューティングは、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）およびプラットフォーム・アズ・ア・サービス（ＰａａＳ）の両方を提供して、顧客がミッションクリティカルな企業アプリケーションおよびデータベースワークロードを共有インフラストラクチャ上で安全に実行できるようにすることができる。これらのクラウドコンピューティングインフラストラクチャは、様々なアプリケーションをホストしてもよく、産業は、クラウドベースの技術を提供するためにマイクロサービスベースのフレームワークに急速に向きつつある。例えば、マイクロサービスプロジェクトは、Kubernetes Engine（クバネティスエンジン）などのコンテナ化されたプロジェクトのクラスタでホストされてもよく、それらのすべてはテナント間でデータセキュリティを保証する共有クラウドインフラストラクチャを介してホストされアクセス可能である。
顧客が自分のコンピューティングインフラストラクチャをクラウドに移動するプロセスを開始すると、クラウドインフラストラクチャは、その顧客のために新しいテナンシを作成することができる。テナンシが作成されると、顧客は、コンソールウェブアプリケーションを使用して、クラウド環境内でホストされる任意のマイクロサービスプロジェクトの所望の機能性を達成するために、必要とされる環境構築ブロックを作成してもよい。既存の技術では、新しいテナントは、既存の技術を選択し、それらを彼らのクラウドフットプリントに追加することによって、これらの構築ブロックを手動で作成することができる。代替として、いくつかのシステムは、テナントが、自動化されたスクリプティング技術を使用して、彼らのクラウドフットプリントの構築ブロックを編成することを可能にする。自動化されたスクリプトは、ユーザが高レベル構成言語を使用してデータセンタインフラストラクチャを定義およびプロビジョニングすることを可能にする任意の「コードとしてのインフラストラクチャ」ソフトウェアツールで書かれてもよい。これらの言語で書かれたスクリプトは、クラウドフットプリントのために構築ブロックを生成するよう実行することができ、プロビジョニングプロセスを大幅に簡略化することができる。しかしながら、これらのスクリプト言語は、クラウドハードウェア／ソフトウェアのインスタンスを表すことが意図されるため、典型的には、多くの異なるアプリケーションにわたってロバストで再利用可能なコードを書くために使用できる特徴およびコード構造体を提供しない。
概要
インフラストラクチャ・アズ・コード（ＩａＣ）ツールは、クラウドインフラストラクチャにおいてサービスの一部としてプロビジョニングされるリソースを宣言するのに有用である。しかしながら、ＩａＣツールは、コマンドおよび制御構造のセットを実行する命令型言語ではなく、プロビジョニングされるべきリソースを指定する宣言型言語を使用する。したがって、ＩａＣスクリプトは、特定のサービスのためにプロビジョニングされるべき特定のリソースおよび構造を定義し得、スクリプトは、スクリプトに著しい変更を伴わずに、異なるサービスまたはプロビジョニングタスクのために容易に再使用されない。
本明細書で説明される実施形態は、クラウドサービスをＩａＣツールにおいて定義するためのプロセスを提示し、ＩａＣツールは、実行時に、クラスタ、可用性ドメイン、計算ノード、および／またはロードバランサの数を動的に決定するように設計される。これらの値は、次いで、サービスにおいて計算ノードおよびロードバランサノードの各々のためにサブネットを生成するためにクラス無しドメイン間ルーティング（ＣＩＤＲ）スライス操作のために必要とされるサブネットレベルの数を決定するために使用される。ＩａＣ言語はネスト化されたループ制御構造体を提供しないので、サブネットの各々に対するラベルは、ラベル要素のデカルト積を使用して生成および割り当てられ得る。これらのラベルは、ネスト化されたループ構造の効果をシミュレートするためにリソースがスクリプトにおいて複製されるたびにインクリメントされるカウント変数によって変更され得る。
スクリプトは、プロビジョニングされている各サービスとともに変化してもよいパラメータのベースラインセットを受信または決定することができる。これらのパラメータは、実行時、スクリプトが実行されるときに受信または決定され得、サービスの一部としてプロビジョニングされるべきクラスタの数、各クラスタにおける可用性ドメインの数、各可用性ドメインにおける計算ノードの数、クラスタの各々におけるロードバランサの数などを含んでもよい。次いで、プロビジョニングされるべき計算ノードおよび／またはロードバランサノードのために適切な数のサブネットを保証するＣＩＤＲレベルの数を、スクリプトは、将来の拡張のための余地を提供する余分なサブネットとともに、決定することができる。これらの値を計算し、異なるプロビジョニングタスクごとにスクリプトにハードコーディングする代わりに、これらの値は、スクリプトが変更なしに任意の同様のプロビジョニングタスクのために再使用されることができるように、実行時に提供および計算されることができる。
計算されたサブネットおよびラベルを宣言されたリソースの各々に割り当てることは、通常は、ネスト化されたループ制御構造をそのコード内に必要とするであろう。しかしながら、ＩａＣツールは典型的にはそのような構造を提供しないので、スクリプトは、各サブネットラベルの成分を含むベクトルのデカルト積を計算することによって、ネスト化されたループの動作をシミュレートし得る。たとえば、可用性ドメインおよびクラスタラベルを使用して生成されるサブネットラベルは、これらのラベルベクトルを互いにたすき掛けして可用性ドメインおよびクラスタのすべての組合せのリストを生成することによって、生成されることができる。これらのラベルは、スクリプト内で宣言されたリソースを再生するために使用されるカウンタ値を含むよう、さらに変更される得る。
図面の簡単な説明
種々の実施形態の性質および利点のさらなる理解は、明細書の残りの部分および図面を参照することによって実現され得、同様の参照番号は、いくつかの図面を通して、同様の構成要素を指すよう使用される。場合によっては、下位ラベルが、複数の同様のコンポーネントのうちの１つを示すよう、参照番号に関連付けられる。既存の下位ラベルを指定せずに参照番号に言及する場合、そのような複数の同様のコンポーネントすべてを参照することが意図される。
いくつかの実施形態による、構造テナンシおよびクラウド環境のアーキテクチャ設計を示す図である。 いくつかの実施形態による、単一のネットワークアドレスが複数の異なるネットワークにどのように「スライス」され得るかを示す図である。 いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよいクラスタの数を指定する第１の入力を示す図である。 いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよい可用性ドメインの数を指定する第２の入力を示す図である。 いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよいワーカーサブネットの数を指定する第３の入力を示す図である。 いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよいロードバランササブネットの数を指定する第４の入力を示す図である。 いくつかの実施形態による、デカルト積が、複数の異なる変数からラベルの単一リストを形成するためにどのように使用され得るかを示す図である。 いくつかの実施形態による、モジュラー算術を使用してデカルト積がどのように計算され得るかを示す図である。 いくつかの実施形態による、付随する擬似コードを使用してクラウドインフラストラクチャにおいてサービスをプロビジョニングするための方法のフローチャートの第１の部分を示す図である。 いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングする方法のフローチャートの続きを示す図である。 いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングするための方法のフローチャートの続きを示す図である。 いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングするための方法のフローチャートの続きを示す図である。 いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングするための方法のフローチャートの完了を示す図である。 いくつかの実施形態による、任意のＩａＣ言語で実現されてもよい、可変数のサブネットを実行時に対応するラベルとともにプロビジョニングするための方法のフローチャートである。 実施形態のいくつかを実現するための分散型システムの簡略ブロック図である。 実施形態のシステムの構成要素によって提供されるサービスがクラウドサービスとして提供されてもよいシステム環境の構成要素の簡略化されたブロック図である。 様々な実施形態が実現されてもよい例示的なコンピュータシステムを示す図である。
詳細な説明
クラウドコンピューティング環境は、独自のハードウェアおよび／またはソフトウェア技術を各々が表す多数の個々の構築ブロックを含んでもよい。クラウドコンピューティングインフラストラクチャのテナントは、多数の個々のユーザのために大量のウェブトラフィックを処理し大量の情報を記憶することができる非常に複雑なクラウドベースのアプリケーションを設計することを望む場合がある。これらのクラウドベースのアプリケーションは、異なるクラウド技術間における対話の膨大な複雑さを表し得る。しかしながら、複雑なアプリケーションを設計およびプロビジョニングするプロセスを単純化するために、多くの現代のクラウドベースのアプリケーションが、マイクロサービスアプリケーションとして設計され得る。マイクロサービスアプリケーションは、複雑な技術のための構築ブロックとして個々の単純なマイクロサービスを使用する。大規模アプリケーションを設計するとき、テナントは、多くの個々のマイクロサービス構築ブロックをまとめて、アプリケーションの全体的な機能を形成してもよい。このプロセスは、大きな複雑な設計タスクを、単純な構築ブロックによって組み立てることができるように、単純化することができる。
クラウドベースのアプリケーションが設計されるとき、設計の個々のハードウェア／ソフトウェアコンポーネントは、クラウド環境内でプロビジョニングされてもよく、アプリケーションは、ユーザに利用可能にされてもよい。クラウドプロビジョニングは、クラウドプロバイダのリソースおよびサービスの、特定のテナントへの割り当てである。本開示は、クラウドサービスにおいてアプリケーションを自動的にプロビジョニングするテナントまたはプロバイダの能力に焦点を当てる。例えば、このモデルでは、テナントは、ウェブインターフェイスまたはポータルを介して、自身のクラウドアプリケーションの構築ブロックを選択し、組み立ててもよい。このプロビジョニングモデルは、アプリケーションがクラウド環境内でどのように構築および編成されるかに関する直接制御をユーザに提供する。これは、典型的には、クラウドプロバイダサポートサービスと顧客との間の対話の必要性を軽減する。代わりに、顧客は、自分自身でクラウドアプリケーションをプロビジョニングすることができ、次いで、クラウド環境は、顧客から命令を自動的に受信し、プロセスとの大規模な管理対話を必要とせずに、必要なリソースをプロビジョニングすることができる。
プロビジョニングプロセス中のマイクロサービスおよび簡略化された構築ブロックの使用にもかかわらず、いくつかのアプリケーションの複雑さは、依然として、ユーザにとって非常に困難であり得る。したがって、いくつかの実施形態は、スクリプト言語を使用して、クラウドアプリケーションを管理およびプロビジョニングするために「インフラストラクチャ・アズ・コード」（ＩａＣ）環境を実現してもよい。ＩａＣ言語は、物理的ハードウェア構成もしくは対話型構成ツールの代わりに、またはそれに加えて、機械可読定義ファイルを通してコンピュータデータセンタをプロビジョニングする。ＩａＣ言語は、ベアメタルサーバと、構成リソースに関連付けられた仮想マシンとの両方を管理することができる。これは、ユーザがコードを使用してインフラストラクチャをモデル化することを可能にし、これは、次いで、ソフトウェア最良実践および再利用可能なコーディング技術を使用してアプリケーションインフラストラクチャを設計、実現、および展開する能力をユーザに与える。ＩａＣは、クラウドコンピューティングアーキテクチャによって取り込まれることができ、それは、次いで、コードによって宣言された構築ブロックを組み立て、構築ブロックをコード定義に基づいて接続された態様で配置することができる。
ＩａＣ技術の使用に伴う明らかな利点にもかかわらず、ＩａＣ言語に固有の様々な制限が存在する。ＩａＣ言語は、クラウドインフラストラクチャの実際の部分およびそれらの相互接続性を表すことが意図されるため、典型的には、真のソフトウェアプログラミング言語において共通である制御構造を欠くように設計される。ＩａＣ言語におけるこれらの固有の制限は、単純なスクリプトが複数のインフラストラクチャにわたってスケーリングすることを困難にする。これらの言語は、既存の成長しつつあるインフラストラクチャによって要求され得る新たな変更に適応するように設計されていない。例えば、クラス無しドメイン間ルーティング（ＣＩＤＲ）スライシングは、手動で事前に計算されクラウドインフラストラクチャの構築時にスクリプトにハードコーディングされる値を必要とした。そのような手法は、新たなアプリケーションのためにコードを再利用することができるようになる前に、変更を再計算し、コードを変更し、スクリプトを再実行するための人的介入を必要とした。このプロセスは、時間がかかり、人的介入を必要とし、プロビジョニングプロセスに欠陥を導入する機会を増加させる。本開示で説明される新しいアルゴリズムとは対照的に、ＩａＣ言語をより汎用的かつ再利用可能にするための他の技術は、各々、それらの有効性または再利用性を制限する欠点を有していた。例えば、ほとんどの既存の解決策は、単に冗長コードを書くことによってこの問題を解決する。
本明細書で説明する実施形態は、ＩａＣ言語の既存の制限を克服するために使用され得る新しいコーディング技術を示す。例えば、いかなる手動計算または汎用コードに対する変更も必要としない任意のサイズの完全なインフラストラクチャブループリントを生成することができる複数の反復子を使用して、ＣＩＤＲスライシングのための新しいアルゴリズムが開発されている。入力変数のいかなる変更も、新しいアルゴリズムを使用する再計算を自動的にトリガし、スクリプトは、必要に応じてクラウドインフラストラクチャの再アライメントをトリガしてもよい。このタイプのプログラミングおよび実行は、この技術的問題に対する以前の産業解決策では可能ではなかった。この解決策は、既存のＩａＣ言語機能を新しいコーディング技術とともに使用して、言語機能を元々意図されていたものを超えて増強する。
図１は、いくつかの実施形態による、構造テナンシおよびクラウド環境のアーキテクチャ設計を図示する。アーキテクチャ１００は、ＩａＣ言語を使用して指定されることができるアーキテクチャの例を提供する。ＩａＣ言語で記述されたスクリプトがクラウドインフラストラクチャによって受信され実行されると、アーキテクチャ１００は、ＩａＣ言語スクリプトによって定義されたインフラストラクチャに従ってプロビジョニングされることができる。ＩａＣスクリプトは、容易に解釈され、クラウドインフラストラクチャにおいて構築ブロック技術にマッチすることができる形式言語であるため、アーキテクチャ１００は、著しい人的関与なしにクラウドインフラストラクチャによって自動的にプロビジョニングされることができる。ＩａＣスクリプトは、個々の技術をアーキテクチャとしてレイアウトすることができ、クラウドインフラストラクチャは、ＩａＣスクリプトを、スクリプトにおいて宣言された技術の各々をプロビジョニングするためのブループリントとして扱うことができる。
図１のアーキテクチャ１００は、単に例として提供され、限定することを意図しない。アーキテクチャ１００におけるコンポーネントは、ＩａＣスクリプトによって宣言されることができる技術構築ブロックの例を提供してもよい。離散的な数の各技術が図１に示されているが、以下に記載されるアルゴリズムは、図１の技術の各々が、限定なく、任意の数および任意の組み合わせでスケーリングされることを可能にすることを理解されたい。アーキテクチャ１００は、特定の技術（例えば、可用性ドメイン、ロードバランサ、クラスタ、ワーカーサブネットなど）が本明細書で説明される実施形態によってどのようにスケーリングされ得るかの記述を提供する。
アーキテクチャ１００は、複数の可用性ドメイン１０２を含む。可用性ドメイン１０２の各々は、アプリケーション全体を構築するマイクロサービスの一部を含んでもよい。可用性ドメイン１０２は、可用性ドメイン１０２のうちの１つが利用不可能になった場合に可用性を維持することができるように冗長サービスを含んでもよい。可用性ドメイン１０２は、互いに隔離されてもよく、フォールトトレラントであってもよく、同時に故障する可能性が非常に低くてもよい。加えて、可用性ドメイン１０２は、異なる領域などの異なる地理的ロケーションに位置する物理ハードウェアの異なるアセンブリに対応してもよい。代替として、同じ領域内の可用性ドメインは、高可用性および災害復旧の両方のために複数の領域内に複製されたシステムを構築するために、低レイテンシの高帯域幅ネットワークによって相互に接続されてもよい。
いくつかの異なる技術が、可用性ドメイン１０２の各々の一部であってもよい。たとえば、可用性ドメイン１０２の各々は、１つ以上のサブネット１０４を含んでもよい。サブネット１０４の各々には、特定のサブネットアドレスが割り当てられてもよい。サブネット１０４の正確な数を決定することは、最上位ネットワークアドレスを適切にスライスするために決定されてもよい。ＣＩＤＲスライシングとして知られるこの手順は、以下でより詳細に説明される。サブネット１０４の各々は、サブネット１０４間のインバウンド／アウトバウンドネットワークアクセスおよび通信のために、割り当てられたサブネットアドレスを使用してもよい。
サブネット１０４は、各クラスタにおいて見出されるリソースをホストしてもよい。多くの異なるリソースがサブネット１０４内でホストされてもよいが、２つの特定のリソースが図１に例として示されている。サブネット１０４のいくつかは計算ノード１０８を含んでもよい。計算ノード１０８は、ワーカーノードと呼ばれることもある。計算ノード１０８は、対応するワーカーサブネットに関連付けられるアクションを実行する。たとえば、ワーカーサブネット１０４ａのネットワークアドレスは、計算ノード１０８ａによって実行されるサービスを呼び出すために使用されてもよい。クラスタ内の計算ノード１０８のいくつかは、ノードプール１０６として指定されてもよい。計算ノード１０８を含むサブネット１０４は、ワーカーサブネットと称されてもよい。
計算ノード１０８を保持することに加えて、サブネット１０４は代替的にロードバランサ１１２を含んでもよい。ロードバランサ１１２は、可用性ドメイン１０２の各々における異なるワーカーサブネット間でトラフィックを受信し、分散させてもよい。これらのサブネットは、ロードバランササブネットと呼ばれ得る。
サブネット１０４の各々は、セキュリティノード１１４にも関連付けられてもよい。セキュリティノード１１４は、ワーカーサブネット１０４の各々のセキュリティポリシーを管理してもよい。いくつかの実施形態では、セキュリティノード１１４は、対応するセキュリティノード１１４にアクセスしてもよいシステムおよび／またはユーザを管理するためにアクセスリスト１１０を使用してもよい。
最後に、図１に示されるアーキテクチャ１００は、単一のクラスタに含まれ得る。サービスを高可用性で実現するために、図１に示したクラスタと同じクラスタを複数形成してもよい。
アーキテクチャ１００は、ＩａＣスクリプトをクラウドインフラストラクチャに提供することによってプロビジョニングされてもよい。次いで、構造は、スクリプトに列挙された技術を解釈し、それらの技術を自動的にプロビジョニングしてもよい。Pulumi, Chef, Otter, Puppet SaltStack, CFEngine, DSC, Pacoなどの任意のＩａＣ言語を使用してもよい。一例として、本明細書に説明される実施形態は、Hashicorpによって提供されるTerraformツール１５０を使用してもよい。これらのツールの各々は、宣言型言語を使用して、クラウドインフラストラクチャの一部としてプロビジョニングされるべき様々な技術を定義してもよい。宣言型言語として、これらのＩａＣツールは、概して、他の言語で使用されてもよい高度な制御構造をサポートしない。例えば、Terraformツール１５０は、いかなるタイプのループ化機構もサポートしない。代わりに、あるリソースを、あるリソースのためのカウントメタ引数（count meta-argument）を使用して、定義された回数だけインスタンス化してもよい。これは、ツールが、複数の変数を使用して割り当てまたは計算を行うために有用であってもよい任意の形態のネスト化されたループを使用することを防止する。さらに、Terraformツールは、コードが書かれる時点ではわかっていない可変数のサブネットに対してＣＩＤＲスライシングを実行する簡単な方法を提供しない。
図２は、いくつかの実施形態による、単一のネットワークアドレス２０２が複数の異なるネットワークにどのように「スライス」され得るかを示す。ＣＩＤＲスライシングは、アドレス集約を使用して、単一のネットワークアドレスを複数のアドレス指定可能なネットワークに変える。図１に関連して上述したように、サブネット１０４の各々は、最上位ネットワークアドレス２０２のサブネットとして存在するそれら自体のネットワークアドレスを必要としてもよい。ＣＩＤＲスライシングの概念は、最上位ネットワークアドレス２０２を、必要とされるネットワークの数に基づいて、いくつかのサブネットワークに細分化する。本開示に先立って、最上位ネットワークアドレス２０２から複数のサブネットアドレスを導出することは、静的動作であった。言い換えれば、ユーザは、必要とされるサブネットの数を決定し、次いで、それに応じて最上位ネットワークアドレス２０２を分割するであろう。これらの値は、スクリプトが書かれ、サービスがクラウドインフラストラクチャにおけるプロビジョニングのために設計されたときに、Terraformスクリプトにハードコーディングされた。将来のスクリプトは既存のスクリプトに基づくことができるが、ハードコーディングされた値は、サブネットの数のサイズを拡張または縮小するために、新しいスクリプトにおいて常に変更される必要がある。これは、エラーを起こしやすい人的介入を必要とし、コードの全体的な有用性を低下させた。また、各スクリプトは対応する特定のプロビジョニングプロジェクトにしか使用できないため、保存する必要のあるスクリプトの数も増加させた。
本明細書に説明される実施形態は、ユーザがプロビジョニングされるべき可用性ドメイン、クラスタ、ワーカーサブネット、および／またはロードバランサの数を変更するにつれて動的にサイズアップおよび／またはサイズダウンされることができるバイナリツリーとしてＣＩＤＲスライシングを概念化する新しいアルゴリズムおよび方法を使用することによって、これらおよび他の技術的問題を解決する。図２は、最上位ネットワークアドレス２０２がレベル指定に基づいて可変数のサブネットにどのようにスライスされ得るかを示す。たとえば、プロビジョニングされているサービスが２つのサブネットを必要とする場合、レベル１（２１１）のスライス操作が実行されてもよい。４つまでのサブネットが使用される場合、レベル２（２１２）のスライス操作が実行されてもよい。
必要とされるサブネットの最小数に基づいて、様々なレベルが使用されてもよい。図２に示すレベル２１１、２１２、２１３、２１４は、底２の指数関数に基づく。例えば、レベル３（２１３）は、２３＝８個のサブネットに対応する。同様に、レベル４（２１４）は、２４＝１６個のサブネットに対応する。スライス操作に必要とされるレベル数を決定するために、Terraformスクリプトは、必要とされるサブネットの最小数を決定し、次いで、少なくともその数のサブネットを提供するレベルを選択することができる。たとえば、プロビジョニングされているサービスのために６つのサブネットが必要とされる場合、スクリプトは、最上位ネットワークアドレス２０２上でレベル３（２１３）のスライス操作が行われるべきであることを動的に判断することができる。これは、必要な数のサブネットが、将来の拡張のために使用されてもよい追加のサブネットとともに提供されることを保証する。
本明細書で説明される実施形態は、スクリプトが実行されるときにスクリプトがＣＩＤＲスライス操作のレベルを動的に決定することを可能にする。以下で詳細に説明されるように、これは、いかなるハードコーディングされた値がスクリプトに含まれることも必要としない。むしろ、スクリプトは、所望の数のクラスタ、可用性ドメイン、ワーカーサブネット、ロードバランサなどを使用して、実行時にスライス操作に必要なレベルを計算することができる。加えて、プロジェクトがスケールアップおよびスケールダウンするにつれて、サブネットアドレスは、単に、例えばプロジェクト内の可用性ドメインの数を変更することによって、再計算されることができる。次いで、スクリプトは、スライス操作で使用されるレベルの数を自動的に再計算することができる。
これらの技術は、単一のプロジェクトの寿命にわたってコードをスケーラブルにするだけでなく、任意の規模の将来のプロジェクトのためにコードを再使用することも可能にする。コードは、サービス設計プロセス中にユーザによって指定された値を受け付けてもよい。例えば、ユーザは、ロードバランサの数、またはプロジェクトの一部であるべき可用性ドメインの数を共通に指定する。しかしながら、ユーザは、適切な数のサブネットアドレスを生成するために使用されるべきＣＩＤＲスライス操作のレベルを指定しない。これは、ユーザが理解する可能性が低いであろう低レベルの詳細である。サブネットアドレスは、代わりに、Terraformスクリプトにハードコーディングされなければならず、コードを、同じ特定のアーキテクチャなしで任意のプロジェクトに対して使用不可能にする。本明細書に説明される実施形態は、ユーザがスクリプトへの入力を動的に変更し、それによって、図２に図示される異なるレベル２１１、２１２、２１３、２１４を上下に移動させることを可能にする。要するに、これらの実施形態は、以前は利用できなかった自動ＣＩＤＲスライシングの形態を達成する。
以下の図は、スクリプトによって決定および／または提供されてもよい異なる入力を通過する。次に、本開示は、スライシングレベルを決定し、対応するサブネットを自動的に生成するためのアルゴリズムを説明する。図３Ａは、いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよいクラスタの数３０２を指定する第１の入力を示す。図１において上記で説明したように、各クラスタ３０２は、１つ以上の可用性ドメインから構成されてもよく、可用性ドメインの各々は、任意の数のワーカーサブネットおよび／またはロードバランサを含んでもよい。クラスタの数３０２は、以下で説明される方程式において省略表現として変数ｃを使用して本明細書で言及される場合がある。クラスタの数３０２は、スクリプトへの入力としてユーザによって明示的に指定されてもよい。代替的または追加的に、クラスタの数３０２はまた、ユーザによって提供される他の値および／または動作によって決定されてもよい。例えば、ユーザは、自身のプロジェクトのために利用可能な複数の構成から所定の構成を選択することができる。これらの構成は、所定の数のクラスタに対応してもよく、スクリプトは、ルックアップテーブル、データベースなどを使用して構成をクラスタの数３０２に変換してもよい。
図３Ｂは、いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよい可用性ドメイン３０４の数を指定する第２の入力を示す。図１において上述したように、可用性ドメイン１０２の各々は、プロビジョニングされているサービスについて高い可用性を提供するために提供されてもよい。可用性ドメイン１０２にわたって機能を複製して、１つの可用性ドメイン２０２ｂが利用不可能になった場合にサービスが依然として他の可用性ドメイン２０２ａ、２０２ｃを通して提供されてもよいようにしてもよい。可用性ドメインの数３０４は、以下で説明される方程式において省略表現として変数ａを使用して表されてもよい。可用性ドメインの数３０４は、スクリプトへの入力として、ユーザによって提供されてもよい。例えば、ユーザは、３つの可用性ドメイン１０２を入力として指定してもよい。代替として、ユーザは、サービスについて可用性のレベル（例えば、高、中、低）を選択してもよい。次いで、スクリプトは、その特定のプロジェクトのために選択された可用性のレベルに対応する可用性ドメイン１０２の数を検索または計算してもよい。可用性ドメインの数３０４は、プロジェクト全体における可用性ドメインの総数を指定する必要はないことに留意されたい。代わりに、可用性ドメインの数３０４は、代わりに、クラスタ単位で提供されてもよい。言い換えれば、可用性ドメインの数３０４は、各クラスタ内の可用性ドメインの数を表してもよい。
例えば、ある構成が、複数の事前定義された構成から、ユーザによって選択されてもよい。これらの構成は、値が実行時に入力されてもよいように、Terraformスクリプトの実行時実行の一部としてユーザに提示されてもよい。各構成は、サービスに必要とされる可用性のレベルを指定するサービスレベル合意（ＳＬＡ）に関連付けられてもよい。システムは、ＳＬＡにおいて必要とされる可用性のレベルを満たすために必要とされてもよい可用性ドメインの数を導出してもよい。クラスタの数の決定、計算ノードの数の決定、および／またはロードバランサの数の決定のために、この同じ手順が使用されてもよいことに留意されたい。
いくつかの実施形態では、これらの値は、実行時にスクリプトへの入力として動的に受信されてもよい。これは、異なる数のクラスタ、可用性ドメイン、計算ノード、および／またはロードバランサを必要とするであろう異なる特性を有する異なるサービスを定義するためにスクリプトを再使用することを可能にする。例えば、スクリプトを使用して第１のサービスをプロビジョニングした後、同じスクリプトを使用して第２の異なるサービスをプロビジョニングしてもよい。異なる数のクラスタ、可用性ドメイン、計算ノード、および／またはロードバランサを、実行時にスクリプトへの入力として提供することによって、異なるサブネットレベル、異なる最上位ネットワークアドレス、および／またはそれ以外の異なるトポロジを有する、異なるサービスがプロビジョニングされてもよい。これは、同じスクリプトが、編集されることを必要とすることなく、異なるサービスをプロビジョニングするために再使用されることを可能にする。以前は、これらのパラメータのいずれかが異なる場合、プロビジョニングされている各サービスに対して異なるスクリプトが必要であったであろう。
いくつかの実施形態では、これらの値は、プロビジョニングプロセスが行われた後に動的に変更されてもよい。たとえば、スクリプトは、実行時値を受信することによってサービスをプロビジョニングするよう実行されてもよい。サービス提供後、顧客は、可用性のレベル、クラスタ位置／数、および／または任意の他のパラメータを変更することを望んでもよい。新しいスクリプトを生成する代わりに、同じスクリプトの２回目を実行でき、入力に対する変更を受信して、サブネットレベルの数を再計算し、新たな数の可用性ドメイン、クラスタ、計算ノード、ロードバランサなどに基づいてサブネットを再生成することができる。
図３Ｃは、いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよいワーカーサブネット１０４の数を指定する第３の入力を示す。図１において上述したように、ワーカーサブネット１０４の各々は、図２において説明されたＣＩＤＲスライス操作からサブネットアドレスのうちの１つを割り当てられてもよい。各ワーカーサブネット１０４は、計算ノード１０８を含んでもよい。ワーカーサブネットの数３０６は、以下で説明される方程式において省略表現として変数ｗを使用して表されてもよい。可用性ドメインの数３０４の場合と同様に、ワーカーサブネットの数３０６は、可用性ドメイン単位で提供されてもよい。言い換えれば、ワーカーサブネットの数３０６は、各可用性ドメインにおけるワーカーサブネットの数を表してもよい。例えば、図３Ｃの可用性ドメイン当たりのワーカーサブネットの数３０６は、１つのワーカーサブネットである。ワーカーサブネットの数３０６は、Terraformスクリプトによって受信および／または決定されてもよい。例えば、ユーザは、スクリプトへの入力として可用性ドメイン当たりのワーカーサブネットの数３０６を提供してもよい。代替として、ユーザは、可用性ドメインにおいて実行される機能を選択してもよく、スクリプトは、どのワーカーサブネットが設計に含まれるべきかを自動的に判断してもよく、それによって、ワーカーサブネットの数３０６を決定してもよい。
図３Ｄは、いくつかの実施形態による、アルゴリズムによって決定および／または受信されてもよいロードバランササブネットの数３０８を指定する第４の入力を示す。図１において上述したように、ロードバランササブネットの各々は、トラフィックを管理し、ワーカーサブネットにルーティングするロードバランサ１１２を含んでもよい。ロードバランササブネットの数は、以下で説明される式において省略表現として変数ｂを使用して表されてもよい。この数は、クラスタ当たりのロードバランササブネットの数を指定してもよい。典型的には、ユーザは、ロードバランササブネットを特定の可用性ドメインに編成する必要はなく、代わりに、単に、各クラスタにおいて必要とされるロードバランサの総数を指定することになる。この数は、スクリプトへの入力として指定されてもよい。代替的に、ロードバランササブネットの数３０８は、実行時にスクリプトによって決定されてもよい。たとえば、ユーザは、サービスのために１つ以上の事前定義された構成を指定することができ、スクリプトは、それらの構成から必要なロードバランサの数を導出してもよい。
これらの入力に基づいて、プロビジョニングされているサービスのために使用されるべきサブネットの総数を決定するために、以下のアルゴリズムが使用されてもよい。あるステップでは、アルゴリズムは、プロビジョニングされるべきワーカーサブネットの総数を計算してもよい。ワーカーサブネットの総数は、クラスタの総数３０２、クラスタあたりの可用性ドメインの総数３０４、および可用性ドメインあたりのワーカーサブネットの総数３０６に基づいて計算されてもよい。例えば、ワーカーサブネットの総数は、以下の式を使用して計算されてもよい。
Figure 2023508729000002
式１において、ｗｔは、サービス全体でプロビジョニングされるワーカーサブネットの総数を表す。
別のステップでは、アルゴリズムは、プロビジョニングされるべきロードバランササブネットの総数を計算してもよい。ロードバランササブネットの総数は、クラスタ３０２の総数およびクラスタあたりのロードバランサの総数３０８に基づいて計算されてもよい。たとえば、ロードバランササブネットの総数は、以下の式を使用して計算されてもよい。
Figure 2023508729000003
式２において、ｂｔは、サービス全体でプロビジョニングされるべきロードバランササブネットの総数を表す。
別のステップにおいて、アルゴリズムは、プロジェクトにおいてプロビジョニングされるべきサブネットの総数を計算してもよい。サブネットの総数は、ワーカーサブネットの総数およびロードバランササブネットの総数に基づいて計算されてもよい。例えば、サブネットの総数は、以下の式を使用して算出されてもよい。
Figure 2023508729000004
式３において、ｓは、サービス全体で割り当てられるサブネットの総数を表す。
次に、アルゴリズムは、最上位ネットワークアドレスがスライスされるべきレベルを計算してもよい。図２に関連して上述したように、このレベルは、最上位ネットワークアドレスから導出されるサブネットアドレスの数を決定する底２の指数関数に対応してもよい。いくつかの実施の形態では、底２を、計算されたスライスレベルの数に対応するべき指数で累乗したものは、サービスにおいて割り当てられるべきサブネットの総数（例えば、２^（サブネットレベルの数）：底２および冪指数（サブネットレベルの数）をもつ冪）以上であってもよい。レベルを決定するために、サブネットの総数について底２の対数を計算することができ、次いで底２の対数の結果にシーリング演算（例えば、次に高い整数に丸める）を施してレベルを決定してもよい。例えば、ある特定の実施形態は、レベル数を決定するために以下の式を使用してもよい。
Figure 2023508729000005
ｎ∈Ｎであるので、シーリング演算を式７に適用して、スライス操作のための最終レベルｎを計算することができる。
Figure 2023508729000006
ここで、レベル番号ｎを用いて、最上位ネットワークアドレスに対してスライス操作を実行してもよい。いくつかの実施形態では、アルゴリズムは、ネットワークアドレスを２ｎ個の重複しないサブネットに分割することによって、各サブネットのための適正なＩＰアドレスを手動で計算してもよい。アーキテクチャを定義するために使用される特定のＩａＣツールに応じて、この演算を自動的に実行する事前定義された関数が存在してもよい。例えば、Terraformツールは、各サブネットについてこの数学的演算を実行するために使用されることができるcidrsubnet(prefix, newbits, netnum)関数を提供する。この関数では、以下の入力が使用されてもよい。
・prefixは、最上位ネットワークアドレスから導出される所定の値である。
・netnumは、図２からのｎレベルにおけるサブネットアドレスのうちの１つのサブネットアドレスのインデックスを表す値∈［０，２ｎ－１］である。
・newbitsは、各サブネットに割り当てられるよう充分なＣＩＤＲブロックがあることを保証する最小値を表すｎの動的に計算された値である。
この段階で、利用可能なサブネットは、図１のアーキテクチャにおいて説明されるリソースの各々に割り当てられることができる。Terraformツールでは、これは、あるリソースについて単一のカウントメタ引数を使用して達成することができる。例えば、Terraformコードにおけるそのリソースの宣言の後にcount=num_worker_subnets行を挿入することで、そのリソースをワーカーサブネット毎に１回複製することができる。ＩａＣ言語およびツールは、典型的には、単一レベルのリソースのみが複製されることを可能にする、限定されたループ化機構を提供することが強調されるべきである。
しかしながら、実際には、様々な変数の組み合わせに基づいて、ラベルを生成し、および／またはリソースの各々に割り当てることも有用である。たとえば、いくつかの実施形態は、各サブネットを、そのクラスタおよび可用性ドメインの組合せに従ってラベル付けしてもよい。各リソースについてラベルを生成するために反復される必要がある複数の変数を扱うとき、複数のループ化レベルが必要であってもよい。しかしながら、上述のように、ＩａＣ言語は、そのようなネスト化されたループ化構造制御を、その言語のネイティブな特徴として提供しない。したがって、複数の変数（例えば、クラスタ、可用性ドメインなど）に基づいてラベルを割り当てるためには、そのような各ラベルを手で計算し、スクリプトにハードコーディングしなければならなかった。上述のように、スクリプトへのハードコーディング値は、設計の再利用性およびスケーラビリティを制限し、設計が変更されるときはいつでも人的介入を必要とする。
本明細書に記載される実施形態は、様々なラベル成分をまとめてラベルのベクトルに集め、モジュラー算術を実行してデカルト積を生成することによって、この問題を解決する。デカルト積は、次いで、Terraformツール内のカウントメタ引数によって模倣される単ループ特徴を使用してもよい。
図４は、いくつかの実施形態による、デカルト積が、複数の異なる変数からラベルの単一リストを形成するためにどのように使用され得るかを示す。クラスタラベルのリスト４０２を含む第１のベクトルは、生産、開発、ステージング、品質保証などとして参照されるクラスタを含んでもよい。可用性ドメインのリスト４０４を含む第２のベクトルは、数値識別子（例えば、ＡＤ－１、ＡＤ－２等）によって参照されるドメインを含んでもよい。以前であれば、あるスクリプトが、これらのラベルの２つのベクトルの組み合わせによってハードコーディングされた単一のラベルベクトルに形成されるペアのすべてを静的に定義し、次いで、そのハードコーディングされた単一のラベルベクトルがサブネットの各々に適用されたかもしれない。しかしながら、これはスクリプトの再使用可能性を制限する。これが必要であったのは、従来のプログラミング言語は、クラスタ４０２が外側ループにおいて反復され得、可用性ドメイン４０４が内側ループにおいて反復され得るように、ネスト化されたループを提供するが、ＩａＣツールは、典型的には、そのような制御構造を提供しないからである。
いくつかの実施形態は、図４に示されるようなモジュラー算術を使用することによってネスト化されたループ制御構造を近似する。これは、スクリプトが、任意の数のクラスタ、可用性ドメイン、または他のラベルを入力として受信し、次いで、Terraformツール内のカウントメタ引数を使用して適用され得るラベルの単一ベクトル４０６を動的に生成することを可能にする。以下で説明されるアルゴリズムを使用して、デカルト積が、２つの入力ラベルベクトルの各々ついてすべての順序付けられたペアのセットを含むように生成されてもよい。ラベルの２つのベクトルは、ここでは例としてのみ使用されることが強調されるべきである。他の実施形態は、２つより多いベクトルラベルを使用してもよく、デカルト積は、ラベルの各組み合わせについて計算されて、ネスト化されたループ化なしで適用されてもよい単一のラベルベクトルを形成してもよい。
図４において、デカルト積は、クラスタ４０２および可用性ドメイン４０４からのラベルの一意の対の各々を含むラベルのベクトル４０６を生成した。図５は、いくつかの実施形態による、モジュラー算術を使用してデカルト積がどのように計算され得るかを示す。この例では、デカルト積は、２次元座標を有するグリッドとして表される。２次元座標は、ネスト化されたループで使用されるであろうインデックスを表す。例えば、生産クラスタはインデックス０でループし、開発クラスタはインデックス１でループし、ステージングクラスタはインデックス２でループする等であろう。内側ループの場合、可用性ドメインの各々は、０から２にインクリメントされるインデックスでループするであろう。
しかしながら、このネスト化されたループ化プロセスを使用する代わりに、デカルト積から得られた各ペアは、図４に示すラベルの結果ベクトル４０６内の単一のインデックスを使用してインデックス付けすることができる。単一のインデックスは、モジュラー算術を使用して、ネスト化されたインデックスに関係付けられる。例えば、クラスタラベルを表す外側ループにおけるインデックスは、以下の式によってインデックスに関係付けられる。
Figure 2023508729000007
変数ａは、入力ベクトル内の値の数に対応し、それは、この場合、３であり、indexcはクラスタインデックスに対応する。同様に、可用性ドメインラベルを表す内側ループのインデックスは、以下の式によってインデックスに関係付けられてもよい。
Figure 2023508729000008
indexadは、可用性ドメインインデックスに対応する。
図６Ａ～図６Ｅは、上述のアルゴリズムを実現するTerraformスクリプトの詳細な例を示す。このフローチャートおよび擬似コードは、例として提供され、限定することを意味しない。上記で説明されるアルゴリズムは、本開示を使用して、任意のＩａＣ言語を用いて実現されてもよい。
図６Ａは、いくつかの実施形態による、あるサービスを、クラウドインフラストラクチャにおいて、付随する擬似コードとともにプロビジョニングするための方法のフローチャートの第１の部分を示す。本方法は、状態変数を受信することと、クラウドインフラストラクチャからデータを収集すること（６０２）とを含んでもよい。上記で説明したように、いくつかの実施形態は、プロビジョニングされるべきリソースを定義する変数の各々をスクリプトへの入力として受信してもよい。この例では、これは、可用性ドメインの数、各ドメインにおけるワーカーサブネットの数、各クラスタに関するロードバランササブネットの数などを含む。この例では、可用性ドメイン当たりのワーカーサブネットの数は１であると仮定されてもよく、クラスタ当たりのロードバランササブネットの数は２であると仮定されてもよい。これらの値を受信するための擬似コード６０１は、これらの値の各々を変数に割り当てることを含んでもよい。擬似コード６０１はまた、FastConnectユーティリティも使用し、これは、クラウドインフラストラクチャおよび他のオンラインサービスに接続するために公衆インターネットを使用することの代替となるネットワーク接続である。
擬似コード６０１はまた、ＣＩＤＲレベルの数を規定するために上記で説明したアルゴリズムの実現例も含む。例えば、上記の式８は、擬似コード６０１の最後の行において実現される：
Figure 2023508729000009
この擬似コードの行は、ロードバランサおよびワーカーノードに必要とされるサブネットの総数を計算する。この総計は、底２の対数関数への入力として提供され、その結果は、サービスのためのＣＩＤＲレベルの最小数を決定するためにシーリング関数に提供される。
本方法はまた、サービスのためにゲートウェイをプロビジョニングすること（６０４）を含んでもよい。擬似コード６０３は、サービスゲートウェイ、インターネットゲートウェイ、ＮＡＴゲートウェイなどをどのように定義するかの例を示す。上述のように、擬似コード６０３のシンタックスは、Terraformツールに固有であってもよく、したがって、他のツールと作業するときに変更されてもよい。
図６Ｂは、いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングする方法のフローチャートの続きを示す。本方法は、サービスのためのルーティングテーブルおよびセキュリティルールを構成することをさらに含んでもよい（６０６）。擬似コード６０５は、デフォルトルーティングテーブルおよびロードバランサセキュリティリストを宣言するための例を示す。いくつかの追加のセキュリティおよび／またはルーティングリソースが、実世界プロジェクトにおいて宣言されてもよいことに留意されたい。擬似コード６０５において提供される例は、単に代表的なものであり、サービスの異なる局面のために他のセキュリティルール、セキュリティリスト、およびルーティングテーブルを生成するためのテンプレートとして使用されてもよい。
図６Ｃは、いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングするための方法のフローチャートの続きを示す。本方法は、すべてのワーカーサブネットがプロビジョニングされたかどうかを判断すること（６０８）をさらに含んでもよい。プロビジョニングされるべき残りのワーカーサブネットがある場合、本方法は、上で説明されたＣＩＤＲスライシングアルゴリズムを使用してサブネットアドレスを計算すること（６１０）を含んでもよい。サブネットの各々は、次いで、対応するＣＩＤＲブロックでプロビジョニングされてもよい（６１２）。このサイクルは、ワーカーサブネットの各々について繰り返されてもよい。
疑似コード６１４において明らかなように、フローチャートに示されるループ構造体は、Terraform疑似コードに用いて現することはできない。代わりに、このコードは、規定された回数だけリソースを複製するメタ引数を提供する。例えば、リソース宣言後の擬似コードの第１行は、以下を含む：
Figure 2023508729000010
ワーカーサブネットの数をカウント変数に割り当てることによって、擬似コード６１４は、ワーカーサブネットごとにoci_core_subnetリソースを生成するようTerraformツールに命令することができる。次いで、擬似コード６１４は、上記のcidrsubnet()を、上で計算された指定されたレベルでサブネットの各々をインデックス付けするために使用されるcount.index変数とともに使用する。
擬似コード６１４はまた、クラスタ名と可用性ドメイン名との間でデカルト積を計算することによって上記で説明したネスト化されたループアルゴリズムも実現する。これらは、count.index変数によってインデックス付けされるavailability_domain配列に格納される。たとえば、以下のコマンドは、サブネットの各々についてラベルのアレイを生成する：
Figure 2023508729000011
従来のネスト化されたループを実行する代わりに、このデカルト積はサブネットのためのラベルのリストを生成する。最後に、ラベルは、擬似コード６１４に示され、上で詳細に説明されたモジュラー算術を使用して、対応するサブネットに割り当てられることができる。
図６Ｃに示されるプロセスは、プロジェクトにおいてワーカーサブネットの各々を割り当てるために実行されてもよい。具体的には示されないが、図６Ｃに示されるプロセスは、ロードバランササブネットの各々について繰り返されてもよい。例えば、同様の手順に従って、上で計算されたレベルに基づいて最上位ネットワークアドレスをスライスしてもよく、デカルト積を使用してラベルのリストを生成してもよい。しかしながら、cidrsubnet()関数のためのnetnumパラメータは、ロードバランササブネットがワーカーサブネットの後にＣＩＤＲブロックに割り当てられるようにシフトされてもよい。
図６Ｄは、いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングするための方法のフローチャートの続きを示す。本方法は、充分なクラスタが、上で説明されたクラスタの数に基づいてプロビジョニングされたかどうかを判断すること（６１６）をさらに含んでもよい。クラスタがプロビジョニングされるべく残っている場合、本方法は、どのロードバランササブネットが必要とされるかを判断し（６１８）、クラスタに正しいロードバランサをプロビジョニングしてもよい（６２０）。上述のように、このループ手順は、擬似コード６２２において、カウント変数を使用して、指定された数のクラスタを動的に生成するよう、モデル化されてもよい。擬似コード６２２の第２の部分は、ロードバランササブネットをクラスタの各々に割り当ててもよい。
図６Ｅは、いくつかの実施形態による、クラウドインフラストラクチャにおいてサービスをプロビジョニングするための方法のフローチャートを完了する。本方法は、充分なノードプールがプロビジョニングされたかどうかを判断すること（６２４）も含んでもよい。追加のノードプールがプロビジョニングされる必要がある限り、本方法は、ChunkList演算を使用して、サブネットを割り当てのためにノードプールに分割すること（６２６）を含んでもよい。擬似コード６３０では、TerraformツールからのChunkList関数を使用して、単一のリストを固定サイズのチャンクに分割し、したがってリストのリストを返すことができる。本方法は、次いで、ノードプールを、対応するワーカーサブネットとともにプロビジョニングすること（６２８）を含んでもよい。擬似コード６３０において、各ノードプールは、ファミリーマップに記述されるサブネット当たりの指定された数量のノードを有する。
上記のフローチャートおよび説明はTerraformツールに特有であるが、ＣＩＤＲサブネットを生成および割り当て、ラベルをサブネットに適用するために、ネスト化されたループをシミュレートするためのアルゴリズムは、任意のＩａＣ言語で実現されてもよい。図７は、いくつかの実施形態による、任意のＩａＣ言語で実現されてもよい、可変数のサブネットを、実行時に、対応するラベルとともにプロビジョニングするための方法のフローチャートを示す。本方法は、クラウドインフラストラクチャにおいてサービスの一部としてプロビジョニングされるべきクラスタの数を決定すること（７０２）を含んでもよい。本方法はまた、クラスタの各々における可用性ドメインの数を決定すること（７０４）、可用性ドメインの各々における計算ノードの数を決定すること（７０６）、および／またはクラスタの各々におけるロードバランサの数を決定すること（７０８）を含んでもよい。これらのステップの各々において、これらの値は、スクリプトへの入力として受信されることによって、スクリプト内に定数として記憶されることによって、および／またはスクリプトにおいて計算もしくは関数によって決定されることによって、決定されてもよい。たとえば、各値は、ユーザによって選択された所定の構成に基づいて導出または検索されてもよい。いくつかの実施形態では、これらの値は、図３Ａ～図３Ｂに関連して上記で説明されるように、または図６Ａに示されるように、決定されてもよい。
本方法はまた、クラスタの数、可用性ドメインの数、計算ノードの数、およびロードバランサの数に基づいてサブネットレベルの数を計算すること（７１０）を含んでもよい。計算ノードは、上述のワーカーサブネットに対応してもよい。ロードバランサの各々も、ロードバランササブネットとして説明されてもよい。サブネットレベルの数は、式２～式８に関連しておよび図６Ｃに関連して上で説明されたように計算されてもよい。本方法はさらに、サブネットレベルの数に基づいて複数のサブネットを生成すること（７１２）を含んでもよい。このステップは、上述のcidrsubnet関数を使用して実行されてもよい。代替的または追加的に、このステップは、２ｎの細分化に基づいて最上位ネットワークアドレスを数学的に細分化することによって実行されてもよい。本方法はまた、複数のサブネットをクラウドインフラストラクチャ内の計算ノードおよびロードバランサに割り当てること（７１４）を含んでもよい。上述したように、ワーカーサブネットおよびロードバランササブネットの各々は、上述したデカルト積およびモジュラー算術アルゴリズムに基づいてラベルを割り当てられてもよい。
図７に示される特定のステップは、様々な実施形態に従って、可変数のサブネットを、実行時に、対応するラベルとともにプロビジョニングする特定の方法を提供することを理解されたい。ステップの他のシーケンスも、代替的な実施形態に従って実行されてもよい。例えば、本発明の代替実施形態は、上記で概説されるステップを異なる順序で実行してもよい。さらに、図７に示される個々のステップは、個々のステップに適切な様々なシーケンスで実行されてもよい複数のサブステップを含んでもよい。さらに、特定の用途に応じて追加のステップを追加または除去してもよい。当業者は、多くの変形物、修正物、および代替物を認識するであろう。
本明細書で説明される方法の各々は、コンピュータシステムによって実現されてもよい。これらの方法の各ステップは、コンピュータシステムによって自動的に実行されてもよく、および／またはユーザに関与する入力／出力が提供されてもよい。例えば、ユーザは、ある方法の各ステップに対する入力を提供してもよく、これらの入力の各々は、そのような入力を要求する特定の出力に応答してもよく、その出力は、コンピュータシステムによって生成される。各入力は、対応する要求出力に応答して受信されてもよい。さらに、入力は、ユーザから、別のコンピュータシステムからデータストリームとして受信されてもよく、メモリ位置から取得されてもよく、ネットワークを介して取得されてもよく、ウェブサービスから要求されてもよい。同様に、出力は、ユーザに、データストリームとして別のコンピュータシステムに提供されてもよく、メモリ位置に記憶されてもよく、ネットワークを介して送信されてもよく、ウェブサービスに提供されてもよい。要するに、本明細書に記載される方法の各ステップは、コンピュータシステムによって実施されてもよく、ユーザが関与してもしなくてもよい、コンピュータシステムへの、およびコンピュータシステムからの、任意の数の入力、出力、および／または要求を含んでもよい。ユーザが関与しないステップは、人的介入なしにコンピュータシステムによって自動的に実行されると言ってもよい。したがって、本開示に照らして、本明細書で説明される各方法の各ステップは、ユーザへの入力およびユーザからの出力を含むように変更され得るか、または任意の決定がプロセッサによって行われる場合、人的介入を伴わずにコンピュータシステムによって自動的に行われ得ることが理解されるであろう。さらに、本明細書で説明される方法の各々のいくつかの実施形態は、有形のソフトウェア製品を形成するために、有形の非一時的記憶媒体上に記憶される命令のセットとして実現されてもよい。
図８は、実施形態の１つを実現するための分散型システム８００の簡略図を示す。図示の実施形態では、分散型システム８００は、１つ以上のクライアントコンピューティングデバイス８０２，８０４，８０６，および８０８を含み、これらは、１つ以上のネットワーク８１０を介してウェブブラウザ、所有権付きクライアント（たとえば、Oracle Forms）などのクライアントアプリケーションを実行し動作させるよう構成される。サーバ８１２は、ネットワーク８１０を介してリモートクライアントコンピューティングデバイス８０２，８０４，８０６，および８０８と通信可能に結合されてもよい。
種々の実施形態では、サーバ８１２は、システムのコンポーネントのうちの１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス（ＳａａＳ）モデルの下で、クライアントコンピューティングデバイス８０２、８０４、８０６、および／または８０８のユーザに対して提供されてもよい。クライアントコンピューティングデバイス８０２、８０４、８０６、および／または８０８を動作させるユーザは、次いで、１つ以上のクライアントアプリケーションを利用してサーバ８１２と対話して、これらのコンポーネントによって提供されるサービスを利用してもよい。
図に示される構成では、システム８００のソフトウェアコンポーネント８１８，８２０および８２２は、サーバ８１２上で実現されるものとして示される。他の実施形態では、システム８００のコンポーネントのうちの１つ以上および／またはこれらのコンポーネントによって提供されるサービスは、クライアントコンピューティングデバイス８０２，８０４，８０６および／または８０８のうちの１つ以上によって実現されてもよい。クライアントコンピューティングデバイスを動作させるユーザは、次いで、１つ以上のクライアントアプリケーションを利用して、これらのコンポーネントによって提供されるサービスを用いてもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現されてもよい。分散型システム８００とは異なってもよいさまざまな異なるシステム構成が可能であることが理解されるべきである。図に示される実施形態は、したがって、実施形態のシステムを実現するための分散型システムの一例であり、限定的であるよう意図されるものではない。
クライアントコンピューティングデバイス８０２，８０４，８０６および／または８０８は、携帯可能なハンドヘルドデバイス（たとえば、iPhone（登録商標）、セルラー電話、 iPad（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえばGoogle Glass（登録商標）頭部装着型ディスプレイ）であってもよく、Microsoft Windows Mobile（登録商標）などのソフトウェア、および／もしくは、iOS, Windows Phone, Android, BlackBerry 10, Palm OSなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、Blackberry（登録商標）、または他の有効にされた通信プロトコルである。クライアントコンピューティングデバイスは、汎用パーソナルコンピュータとすることができ、一例として、Microsoft Windows（登録商標）, Apple Macintosh（登録商標）, および／もしくはLinux（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータならびに／またはラップトップコンピュータを含む。クライアントコンピューティングデバイスは、例えばGoogle Chrome OSなどの様々なGNU/Linux（登録商標）オペレーティングシステムを含むがこれに限定されない、様々な市販のUNIX（登録商標）またはUNIXのようなオペレーティングシステムのいずれかを実行するワークステーションコンピュータとすることができる。代替として、または加えて、クライアントコンピューティングデバイス８０２，８０４，８０６，および８０８は、ネットワーク８１０を介して通信することが可能な、シンクライアントコンピュータ、インターネット対応ゲームシステム（例えば、Kinect（登録商標）ジェスチャ入力装置を伴うかまたは伴わないMicrosoft Xboxゲームコンソール）、および／またはパーソナルメッセージングデバイス等の任意の他の電子デバイスであってもよい。
例示の分散型システム８００は、４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなど、他のデバイスがサーバ８１２と対話してもよい。
分散型システム８００内のネットワーク８１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、AppleTalkなどを含むがこれらに限定されない様々な市販のプロトコルのいずれかを使用してデータ通信をサポートすることができる、当業者によく知られている任意のタイプのネットワークであってもよい。単に一例として、ネットワーク８１０は、イーサネット（登録商標）、トークンリングなどに基づくものなどのローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク８１０は、ワイドエリアネットワークおよびインターネットであってもよい。それは、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（例えば、米国電気電子学会（ＩＥＥＥ）８０２．１１プロトコル一式、Bluetooth（登録商標）、および／もしくは任意の他の無線プロトコルのいずれかの下で動作するネットワーク）を含むがこれらに限定されない仮想ネットワーク；ならびに／またはこれらおよび／もしくは他のネットワークの任意の組み合わせを含むことができる。
サーバ８１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（例として、ＰＣ（パーソナルコンピュータ）サーバ、UNIX（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）、サーバファーム、サーバクラスタ、または任意の他の適切な構成および／もしくは組合せから構成されてもよい。種々の実施形態では、サーバ８１２は、前述の開示で説明される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。例えば、サーバ８１２は、本開示のある実施形態に従って上記で説明された処理を実行するためのサーバに対応してもよい。
サーバ８１２は、上述のもののいずれかを含むオペレーティングシステム、および任意の市場で入手可能なサーバオペレーティングシステムを実行してもよい。サーバ８１２はまた、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェイス）サーバ、JAVA（登録商標）サーバ、データベースサーバなどを含むさまざまなさらに他のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行してもよい。例示的なデータベースサーバは、Oracle, Microsoft, Sybase, IBM（登録商標）（インターナショナルビジネスマシンズ）などから市場で入手可能なものを含むが、それらに限定されるものではない。
いくつかの実現例では、サーバ８１２は、クライアントコンピューティングデバイス８０２，８０４，８０６，および８０８のユーザから受信されたデータフィードおよび／またはイベント更新を分析および整理統合するための１つ以上のアプリケーションを含んでもよい。一例として、データフィードおよび／またはイベント更新は、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などに関連するリアルタイムのイベントを含んでもよい、１つ以上の第三者情報源および連続データストリームから受信される、Twitter（登録商標）フィード、Facebook（登録商標）更新またはリアルタイムの更新を含んでもよいが、それらに限定されるものではない。サーバ８１２は、クライアントコンピューティングデバイス８０２，８０４，８０６，および８０８の１つ以上のディスプレイデバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションも含んでもよい。
分散型システム８００は、１つ以上のデータベース８１４および８１６も含んでもよい。データベース８１４および８１６は、様々な場所に存在してもよい。例として、データベース８１４および８１６のうちの１つ以上は、サーバ８１２にローカルな（および／または常駐する）非一時的記憶媒体上に常駐してもよい。代替として、データベース８１４および８１６は、サーバ８１２から遠隔にあり、ネットワークベースの接続または専用の接続を介してサーバ８１２と通信してもよい。一組の実施形態では、データベース８１４および８１６は、ストレージエリアネットワーク（ＳＡＮ）内に常駐してもよい。同様に、サーバ８１２に帰する機能を実行するための任意の必要なファイルが、適宜、サーバ８１２上にローカルに、および／または遠隔で、記憶されてもよい。一組の実施形態では、データベース８１４および８１６は、ＳＱＬフォーマット化されたコマンドに応答してデータを記憶、更新、および検索するように適合される、Oracleによって提供されるデータベース等のリレーショナルデータベースを含んでもよい。
図９は、本開示の一実施形態による、実施形態のシステムの１つ以上のコンポーネントによって提供されるサービスをクラウドサービスとして提供してもよいシステム環境９００の１つ以上のコンポーネントの簡略ブロック図である。図示される実施形態では、システム環境９００は、クラウドサービスを提供するクラウドインフラストラクチャシステム９０２と対話するためにユーザによって使用されてもよい、１つ以上のクライアントコンピューティングデバイス９０４，９０６，および９０８を含む。クライアントコンピューティングデバイスは、クラウドインフラストラクチャシステム９０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム９０２と対話するためにクライアントコンピューティングデバイスのユーザによって使用されてもよい、ウェブブラウザ、知的所有権下にあるクライアントアプリケーション（たとえば、Oracle Forms）、または何らかの他のアプリケーションなどのクライアントアプリケーションを動作させるよう構成されてもよい。
図示のクラウドインフラストラクチャシステム９０２は、図示されるコンポーネント以外のコンポーネントを有していてもよいことを理解されたい。さらに、図に示す実施形態は、本発明の実施形態を組み込んでもよいクラウドインフラストラクチャシステムの一例にすぎない。いくつかの他の実施形態では、クラウドインフラストラクチャシステム９０２は、図に示されるよりも多いまたは少ないコンポーネントを有してもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配列を有してもよい。
クライアントコンピューティングデバイス９０４，９０６，および９０８は、８０２，８０４，８０６，および８０８について上で説明されたものと同様のデバイスであってもよい。
例示的なシステム環境９００は３つのクライアントコンピューティングデバイスとともに示されるが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなどの、他のデバイスが、クラウドインフラストラクチャシステム９０２と対話してもよい。
ネットワーク９１０は、クライアント９０４，９０６，および９０８とクラウドインフラストラクチャシステム９０２との間のデータの通信および交換を容易にしてもよい。各ネットワークは、ネットワーク８１０について上で説明されたものを含む、様々な市販のプロトコルのいずれかを使用してデータ通信をサポートすることができる、当業者によく知られている任意のタイプのネットワークであってもよい。
クラウドインフラストラクチャシステム９０２は、サーバ８１２について上述したものを含んでもよい１つ以上のコンピュータおよび／またはサーバを含んでもよい。
ある実施形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされたオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理された技術サポートサービス等、オンデマンドでクラウドインフラストラクチャシステムのユーザに利用可能にされるサービスのホストを含んでもよい。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリングすることができる。クラウドインフラストラクチャシステムによって提供されるサービスの特定のインスタンス化は、本明細書では「サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザに利用可能にされる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。例えば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネット等の通信ネットワークを介して、オンデマンドで、そのアプリケーションを注文および使用してもよい。
いくつかの例では、コンピュータネットワーククラウドインフラストラクチャ内のサービスは、ストレージ、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供されるかもしくは当技術分野で公知の他のサービスへの、保護されたコンピュータネットワークアクセスを含んでもよい。例えば、サービスは、インターネットを介したクラウド上のリモートストレージへのパスワード保護されたアクセスを含むことができる。別の例として、サービスは、ウェブサービスベースのホストされたリレーショナルデータベースと、ネットワーク化された開発者による私的使用のためのスクリプト言語ミドルウェアエンジンとを含むことができる。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含むことができる。
ある実施形態では、クラウドインフラストラクチャシステム９０２は、セルフサービスであり、サブスクリプションベースであり、弾性的にスケーラブルであり、信頼性があり、高い可用性があり、セキュリティ保護のある態様で顧客に配信される、アプリケーション、ミドルウェア、およびデータベースサービス提供の一式を含んでもよい。そのようなクラウドインフラストラクチャシステムの例は、本譲受人によって提供されるOracle Public Cloudである。
さまざまな実施形態において、クラウドインフラストラクチャシステム９０２は、クラウドインフラストラクチャシステム９０２によって提供されるサービスに対する顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合されてもよい。クラウドインフラストラクチャシステム９０２は、異なる展開モデルを介してクラウドサービスを提供してもよい。例えば、サービスは、クラウドインフラストラクチャシステム９０２が（例えば、Oracleによって所有される）クラウドサービスを販売する組織によって所有され、サービスが一般公衆または異なる業界企業に利用可能にされる、公衆クラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム９０２が単一の組織に対してのみ動作し、その組織内の１つ以上のエンティティにサービスを提供してもよいプライベートクラウドモデルの下で提供してもよい。クラウドサービスはまた、クラウドインフラストラクチャシステム９０２およびクラウドインフラストラクチャシステム９０２によって提供されるサービスが関連するコミュニティ内のいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。クラウドサービスはまた、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。
いくつかの実施形態では、クラウドインフラストラクチャシステム９０２によって提供されるサービスは、サービスとしてのソフトウェア（ＳａａＳ）カテゴリ、サービスとしてのプラットフォーム（ＰａａＳ）カテゴリ、サービスとしてのインフラストラクチャ（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される１つ以上のサービスを含んでもよい。顧客は、クラウドインフラストラクチャシステム９０２によって提供される１つ以上のサービスを、サブスクリプション注文を介して注文してもよい。次いで、クラウドインフラストラクチャシステム９０２は、顧客のサブスクリプション注文におけるサービスを提供するための処理を実行する。
いくつかの実施形態では、クラウドインフラストラクチャシステム９０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを含んでもよいが、それらに限定はされない。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに該当するクラウドサービスを提供するよう構成されてもよい。例えば、ＳａａＳプラットフォームは、統合された開発および展開プラットフォーム上でオンデマンドアプリケーションの一式を構築および配信するための能力を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基底のソフトウェアおよびインフラストラクチャを管理ならびに制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で実行するアプリケーションを利用することができる。顧客は、別途のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。様々な異なるＳａａＳサービスが提供されてもよい。例としては、販売実績管理、企業統合、および大規模組織のための事業柔軟性のためのソリューションを提供するサービスが挙げられるが、それらに限定されない。
いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに該当するクラウドサービスを提供するよう構成されてもよい。プラットフォームサービスの例は、組織（Oracle等）が共有の共通アーキテクチャ上で既存のアプリケーションを統合することを可能にするサービス、およびプラットフォームによって提供される共有サービスを活用する新たなアプリケーションを構築する能力を含んでもよいが、それらに限定されない。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基底のソフトウェアおよびインフラストラクチャを管理ならびに制御してもよい。顧客は、顧客が別途のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得することができる。プラットフォームサービスの例は、Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS)などを含むが、これらに限定されない。
ＰａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを採用することができ、展開されたサービスを制御することもできる。いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（例えば、Oracle Fusion Middlewareサービス）、およびJavaクラウドサービスを含んでもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、顧客にサービスとしてのデータベースをデータベースクラウドの形で提供することを可能にする共有サービス展開モデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客が様々なビジネスアプリケーションを開発および展開するためのプラットフォームを提供してもよく、Javaクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてJavaアプリケーションを展開するためのプラットフォームを提供してもよい。
様々な異なるインフラストラクチャサービスが、クラウドインフラストラクチャシステムにおいてＩａａＳプラットフォームによって提供されてもよい。インフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のためにストレージ、ネットワーク、および他の基本的なコンピューティングリソース等の基底のコンピューティングリソースの管理ならびに制御を促進する。
ある実施形態では、クラウドインフラストラクチャシステム９０２はまた、クラウドインフラストラクチャシステムの顧客に様々なサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース９３０を含んでもよい。一実施形態では、インフラストラクチャリソース９３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するためにサーバ、ストレージ、およびネットワーキングリソースなどのハードウェアの事前統合され最適化された組合せを含んでもよい。
いくつかの実施形態では、クラウドインフラストラクチャシステム９０２におけるリソースは、複数のユーザによって共有され、需要ごとに動的に再割り当てされてもよい。加えて、リソースは、異なる時間帯においてユーザに割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム９３０は、第１の時間帯における第１の組のユーザがクラウドインフラストラクチャシステムのリソースを指定された時間数にわたって利用することを可能にし、次いで、異なる時間帯にいる別の組のユーザに同じリソースを再割り当てることを可能にし、それによってリソースの利用を最大にしてもよい。
ある実施形態では、クラウドインフラストラクチャシステム９０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム９０２によって提供されるサービスによって共有されるいくつかの内部共有サービス９３２が提供されてもよい。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよび回復サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含んでもよいが、これらに限定されない。
特定の実施形態では、クラウドインフラストラクチャシステム９０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（例えば、ＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的な管理を提供してもよい。一実施形態では、クラウド管理機能は、クラウドインフラストラクチャシステム９０２によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含んでもよい。
一実施形態では、図に示すように、クラウド管理機能は、注文管理モジュール９２０、注文オーケストレーションモジュール９２２、注文プロビジョニングモジュール９２４、注文管理および監視モジュール９２６、ならびにアイデンティティ管理モジュール９２８などの１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／もしくは組み合わせであってもよい１つ以上のコンピュータならびに／もしくはサーバを含むか、またはそれらを使用して提供されてもよい。
例示的な動作９３４において、クライアントデバイス９０４、９０６または９０８などのクライアントデバイスを使用する顧客は、クラウドインフラストラクチャシステム９０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム９０２によって提供される１つ以上のサービスのサブスクリプションの注文を出すことによって、クラウドインフラストラクチャシステム９０２と対話してもよい。ある実施形態では、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ９１２、クラウドＵＩ９１４、および／またはクラウドＵＩ９１６にアクセスし、これらのＵＩを介してサブスクリプション注文を行ってもよい。顧客が注文を行うことに応答してクラウドインフラストラクチャシステム９０２によって受信される注文情報は、顧客と、顧客が加入しようとする、クラウドインフラストラクチャシステム９０２によって提供される１つ以上のサービスとを識別する情報を含んでもよい。
顧客によって注文が行われた後、クラウドＵＩ９１２、９１４および／または９１６を介して注文情報が受信される。
動作９３６において、注文は注文データベース９１８に記憶される。注文データベース９１８は、クラウドインフラストラクチャシステム９１８によって操作され他のシステム要素と関連して操作されるいくつかのデータベースのうちの１つであることができる。
動作９３８において、注文情報は注文管理モジュール９２０に転送される。いくつかの例では、注文管理モジュール９２０は、注文を検証し、検証されると注文を記帳するなど、注文に関連する料金請求および経理機能を実行するよう構成されてもよい。
動作９４０において、注文に関する情報は、注文オーケストレーションモジュール９２２に通信される。注文オーケストレーションモジュール９２２は、注文情報を利用して、顧客によって行われた注文に対してサービスおよびリソースのプロビジョニングをオーケストレーションしてもよい。いくつかの例では、注文オーケストレーションモジュール９２２は、注文プロビジョニングモジュール９２４のサービスを使用して、サブスクライブされたサービスをサポートするためにリソースのプロビジョニングをオーケストレーションしてもよい。
特定の実施形態では、注文オーケストレーションモジュール９２２は、各注文に関連付けられるビジネスプロセスの管理を可能にし、ビジネスロジックを適用して、注文がプロビジョニングに進むべきかどうかを判断する。動作９４２において、新たなサブスクリプションの注文を受信すると、注文オーケストレーションモジュール９２２は、リソースを割り当て、サブスクリプション注文を満たすのに必要とされるリソースを構成するよう、要求を注文プロビジョニングモジュール９２４に送信する。注文プロビジョニングモジュール９２４は、顧客によって注文されたサービスに対するリソースの割り当てを可能にする。注文プロビジョニングモジュール９２４は、クラウドインフラストラクチャシステム９００によって提供されるクラウドサービス間の抽象化のレベル、および要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的なインプリメンテーション層を提供する。したがって、注文オーケストレーションモジュール９２２は、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか、または事前にプロビジョニングされ、要求に応じてのみ割り振られる／割り当てられるかどうかなど、実現の詳細から隔離されてもよい。
動作９４４において、サービスおよびリソースがプロビジョニングされると、提供されたサービスの通知が、クラウドインフラストラクチャシステム９０２の注文プロビジョニングモジュール９２４によってクライアントデバイス９０４、９０６および／または９０８上の顧客に送信されてもよい。
動作９４６において、顧客のサブスクリプション注文は、注文管理および監視モジュール９２６によって管理ならびに追跡されてもよい。いくつかの事例では、注文管理および監視モジュール９２６は、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステム起動時間およびシステム停止時間の量など、サブスクリプション注文におけるサービスについて使用統計を収集するよう構成されてもよい。
ある実施形態では、クラウドインフラストラクチャシステム９００は、アイデンティティ管理モジュール９２８を含んでもよい。アイデンティティ管理モジュール９２８は、クラウドインフラストラクチャシステム９００におけるアクセス管理および認可サービスなどのアイデンティティサービスを提供するよう構成されてもよい。いくつかの実施形態では、アイデンティティ管理モジュール９２８は、クラウドインフラストラクチャシステム９０２によって提供されるサービスを利用することを望む顧客に関する情報を制御してもよい。そのような情報は、そのような顧客の素性を認証する情報、およびそれらの顧客が様々なシステムリソース（例えば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してどのアクションを実行することを許可されるかを記述する情報を含むことができる。アイデンティティ管理モジュール９２８はまた、各顧客についての記述情報、ならびにその記述情報にアクセスしそれを変更することができる方法および人についての記述情報の管理も含んでもよい。
図１０は、本発明の様々な実施形態が実現されてもよい例示的なコンピュータシステム１０００を示す。システム１０００は、上記で説明されるコンピュータシステムのうちのいずれかを実現するために使用されてもよい。図に示されるように、コンピュータシステム１０００は、バスサブシステム１００２を介していくつかの周辺サブシステムと通信する処理ユニット１００４を含む。これらの周辺サブシステムは、処理加速ユニット１００６、Ｉ／Ｏサブシステム１００８、ストレージサブシステム１０１８、および通信サブシステム１０２４を含んでもよい。ストレージサブシステム１０１８は、有形のコンピュータ可読記憶媒体１０２２およびシステムメモリ１０１０を含む。
バスサブシステム１００２は、コンピュータシステム１０００のさまざまなコンポーネントおよびサブシステムに、意図されるように互いに通信させるための機構を提供する。バスサブシステム１００２は、単一のバスとして概略的に示されるが、バスサブシステムの代替実施形態は、複数のバスを利用してもよい。バスサブシステム１００２は、さまざまなバスアーキテクチャのうちのいずれかを用いるメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１規格に従って製造される中二階バスとして実現され得る周辺コンポーネントインターコネクト（ＰＣＩ）バスを含んでもよい。
処理ユニット１００４は、１つ以上の集積回路（例えば、従来のマイクロプロセッサまたはマイクロコントローラ）として実現することができ、コンピュータシステム１０００の動作を制御する。１つ以上のプロセッサが処理ユニット１００４に含まれてもよい。これらのプロセッサは、シングルコアプロセッサまたはマルチコアプロセッサを含んでもよい。特定の実施形態では、処理ユニット１００４は、シングルコアプロセッサもしくはマルチコアプロセッサが各処理ユニットに含まれる１つ以上の独立した処理ユニット１０３２および／または１０３４として実現されてもよい。他の実施形態では、処理ユニット１００４はまた、２つのデュアルコアプロセッサを単一のチップに統合することによって形成されるクワッドコア処理ユニットとして実現されてもよい。
様々な実施形態では、処理ユニット１００４は、プログラムコードに応答して様々なプログラムを実行することができ、複数の同時に実行されるプログラムまたはプロセスを維持することができる。任意の所与の時間に、実行されるべきプログラムコードの一部またはすべてが、プロセッサ１００４、および／またはストレージサブシステム１０１８に常駐することができる。好適なプログラミングを通して、プロセッサ１００４は、上記で説明される種々の機能性を提供することができる。コンピュータシステム１０００は、デジタル信号プロセッサ（ＤＳＰ）、特殊目的プロセッサなどを含み得る処理加速ユニット１００６をさらに含んでもよい。
Ｉ／Ｏサブシステム１００８は、ユーザインターフェイス入力デバイスおよびユーザインターフェイス出力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、例えば、ユーザが、ジェスチャおよび発話コマンドを使用して、ナチュラルユーザインターフェイスを通して、Microsoft Xbox（登録商標）３６０ゲームコントローラ等の入力デバイスを制御し、それと相互作用することを可能にする、Microsoft Kinect（登録商標）モーションセンサ等のモーション感知および／またはジェスチャ認識デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き（たとえば、写真を撮っている間および／またはメニュー選択を行なっている間の「まばたき」）を検出し、アイジェスチャを入力デバイス（たとえばGoogle Glass（登録商標））への入力として変換するGoogle Glass（登録商標）瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。加えて、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム（たとえばSiri（登録商標）ナビゲータ）と対話することを可能にする音声認識感知デバイスを含んでもよい。
ユーザインターフェイス入力デバイスは、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚／視覚デバイスも含んでもよいが、それらに限定されるものではない。加えて、ユーザインターフェイス入力デバイスは、例えば、コンピュータ断層撮影、磁気共鳴撮像、ポジトロン断層撮影、医療用超音波検査装置等の医療用撮像入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスはまた、例えば、ＭＩＤＩキーボード、デジタル楽器等の音声入力デバイスを含んでもよい。
ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイス等の非視覚的ディスプレイを含んでもよい。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という語の使用は、コンピュータシステム１０００からユーザまたは他のコンピュータに情報を出力するためのすべての考えられ得るタイプのデバイスおよび機構を含むよう意図される。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスならびに音声／映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されるものではない。
コンピュータシステム１０００は、現在のところシステムメモリ１０１０内に位置しているものとして示されているソフトウェア要素を含むストレージサブシステム１０１８を備えてもよい。システムメモリ１０１０は、処理ユニット１００４上でロード可能および実行可能なプログラム命令、ならびにこれらのプログラムの実行中に生成されるデータを記憶してもよい。
コンピュータシステム１０００の構成およびタイプに応じて、システムメモリ１０１０は、揮発性（ランダムアクセスメモリ（ＲＡＭ）など）および／または不揮発性（読み出し専用メモリ（ＲＯＭ）、フラッシュメモリなど）であってもよい。ＲＡＭは、典型的には、処理ユニット１００４に即座にアクセス可能である、ならびに／もしくは処理ユニット１００４によって現在操作および実行されている、データならびに／またはプログラムモジュールを含む。いくつかの実現例では、システムメモリ１０１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）など、複数の異なるタイプのメモリを含んでもよい。いくつかの実現例では、起動中などにコンピュータシステム１０００内の要素間で情報を転送するのに役立つ基本的なルーチンを含むベーシックインプット／アウトプットシステム（ＢＩＯＳ）が、典型的には、ＲＯＭに記憶されてもよい。限定ではなく例として、システムメモリ１０１０はまた、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含んでもよいアプリケーションプログラム１０１２、プログラムデータ１０１４、およびオペレーティングシステム１０１６も示す。例として、オペレーティングシステム１０１６は、様々なバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／もしくはLinux（登録商標）オペレーティングシステム、様々な市販のUNIX（登録商標）もしくはUNIX様オペレーティングシステム（様々なGNU/Linuxオペレーティングシステム、Google Chrome（登録商標）ＯＳなどを含むが、これらに限定されない）、ならびに／またはiOS, Windows（登録商標）Phone, Android（登録商標）ＯＳ、BlackBerry（登録商標）１０ＯＳ、およびPalm（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含んでもよい。
記憶サブシステム１０１８はまた、いくつかの実施形態の機能性を提供する基本的なプログラミングおよびデータ構造を記憶するための有形のコンピュータ可読記憶媒体も提供してもよい。プロセッサによって実行されると上述の機能を提供するソフトウェア（プログラム、コードモジュール、命令）が、ストレージサブシステム１０１８に格納されてもよい。これらのソフトウェアモジュールまたは命令は、処理ユニット１００４によって実行されてもよい。ストレージサブシステム１０１８はまた、本発明に従って使用されるデータを記憶するためのリポジトリを提供してもよい。
ストレージサブシステム１０００はまた、コンピュータ可読記憶媒体１０２２にさらに接続され得るコンピュータ可読記憶媒体リーダ１０２０を含み得る。システムメモリ１０１０とともに、およびオプションとして、システムメモリ１０１０と組み合わせて、コンピュータ可読記憶媒体１０２２は、コンピュータ可読情報を、一時的および／またはより恒久的に収容、記憶、伝送、および検索するために、遠隔の、ローカルな、固定された、および／またはリムーバブルなストレージデバイスに記憶媒体を加えたものを包括的に表してもよい。
コードまたはコードの一部を含むコンピュータ可読記憶媒体１０２２はまた、限定はしないが、情報の記憶および／または伝送のための任意の方法または技術で実現される揮発性および不揮発性の、リムーバブルおよび非リムーバブル媒体などの、記憶媒体ならびに通信媒体を含む、当技術分野で公知であるかまたは使用される任意の適切な媒体を含むことができる。これは、ＲＡＭ、ＲＯＭ、電子的に消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ可読媒体等の有形のコンピュータ可読記憶媒体を含んでもよい。これはまた、データ信号、データ伝送、または所望の情報を伝送するために使用することができ、コンピューティングシステム１０００によってアクセスすることができる、任意の他の媒体等の非有形のコンピュータ可読媒体を含むことができる。
例として、コンピュータ可読記憶媒体１０２２は、非リムーバブル不揮発性磁気媒体に対して読み書きするハードディスクドライブ、リムーバブル不揮発性磁気ディスクに対して読み書きする磁気ディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤおよびBlu-Ray（登録商標）ディスクなどの、リムーバブル不揮発性光ディスクに対して読み書きする光ディスクドライブ、または他の光学媒体を含んでもよい。コンピュータ可読記憶媒体１０２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、これらに限定されない。コンピュータ可読記憶媒体１０２２はまた、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤも含んでもよい。ディスクドライブおよびそれらに関連付けられるコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性記憶をコンピュータシステム１０００に提供してもよい。
通信サブシステム１０２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム１０２４は、他のシステムとコンピュータシステム１０００との間のデータの送受のためのインターフェイスとして働く。例えば、通信サブシステム１０２４は、コンピュータシステム１０００がインターネットを介して１つ以上のデバイスに接続することを可能にしてもよい。いくつかの実施形態では、通信サブシステム１０２４は、（たとえば、セルラー電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（グローバル進化のための高速データレート）などの先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格、もしくは他のモバイル通信技術、またはそれらのいずれかの組み合わせを用いて）無線音声および／もしくはデータネットワークにアクセスするための無線周波数（ＲＦ）送受信機コンポーネント、グローバルポジショニングシステム（ＧＰＳ）受信機コンポーネント、ならびに／または他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム１０２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続性（例えば、イーサネット（登録商標））を提供することができる。
いくつかの実施形態では、通信サブシステム１０２４はまた、コンピュータシステム１０００を使用してもよい１人以上のユーザの代わりに、構造化されたおよび／または構造化されていないデータフィード１０２６、イベントストリーム１０２８、イベント更新１０３０等の形式で入力通信を受信してもよい。
例として、通信サブシステム１０２４は、Twitter（登録商標）フィード、Facebook（登録商標）更新、Rich Site Summary（ＲＳＳ）フィードなどのウェブフィード、および／もしくは１つ以上の第三者情報源からのリアルタイム更新などの、ソーシャルネットワークならびに／または他の通信サービスのユーザからリアルタイムでデータフィード１０２６を受信するよう構成されてもよい。
加えて、通信サブシステム１０２４はまた、連続データストリームの形式でデータを受信するよう構成されてもよく、これは、明示的な終端を伴わない、本質的に連続的または無限であってもよい、リアルタイムイベントのイベントストリーム１０２８および／またはイベント更新１０３０を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などが含まれてもよい。
通信サブシステム１０２４はまた、構造化されたおよび／または構造化されていないデータフィード１０２６、イベントストリーム１０２８、イベント更新１０３０などを、コンピュータシステム１０００に結合される１つ以上のストリーミングデータソースコンピュータと通信してもよい１つ以上のデータベースに出力するよう構成されてもよい。
コンピュータシステム１０００は、ハンドヘルドポータブルデバイス（例えば、iPhone（登録商標）携帯電話、iPad（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（例えば、Google Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または任意の他のデータ処理システムを含む、種々のタイプの１つとすることができる。
常に変化するコンピュータおよびネットワークの性質のため、図に示されるコンピュータシステム１０００の記載は、単に具体的な例として意図される。図に描写されるシステムより多いまたは少ないコンポーネントを有する、多くの他の構成が可能である。たとえば、カスタマイズされたハードウェアも使用されるかもしれず、および／または、特定の要素が、ハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組み合わせで実現されるかもしれない。さらに、ネットワーク入力／出力デバイス等の他のコンピューティングデバイスへの接続が採用されてもよい。本明細書に提供される開示および教示に基づいて、当業者は、種々の実施形態を実現するための他の態様および／または方法を理解するであろう。
前述の説明では、説明の目的で、本発明の様々な実施形態の完全な理解のために、多数の具体的な詳細を記載した。しかしながら、本発明の実施形態は、これらの具体的な詳細のいくつかがなくても実施されてもよいことが当業者には明らかであろう。他の例では、周知の構造およびデバイスがブロック図形式で示される。
前述の説明は、例示的な実施形態のみを提供し、本開示の範囲、適用性、または構成を限定することを意図しない。むしろ、例示的な実施形態の前述の説明は、例示的な実施形態を実施するための実施可能な説明を当業者に提供するであろう。特許請求の範囲に記載されている本発明の精神および範囲から逸脱することなく、要素の機能および構成にさまざまな変更を加えることができることを理解されたい。
上記の説明では、実施形態の完全な理解を与えるために具体的な詳細が与えられている。しかしながら、当業者には、実施の形態はこれらの具体的な詳細なしに実施されてもよいことが理解される。例えば、回路、システム、ネットワーク、プロセス、および他のコンポーネントは、実施形態を不必要な詳細において不明瞭にしないために、ブロック図の形態でコンポーネントとして示されている場合がある。他の事例では、周知の回路、プロセス、アルゴリズム、構造、および技術は、実施形態を不明瞭にすることを回避するために、不必要な詳細を伴わずに示されている場合がある。
また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として描写されるプロセスとして記載されている場合があることに留意されたい。あるフローチャートは動作を逐次プロセスとして記載している場合があるが、動作の多くは並列または同時に実行され得る。加えて、動作の順序は並べ替えられてもよい。プロセスは、その動作が完了されるときに終結されるが、図に含まれない追加のステップを有し得る。プロセスは、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに対応してもよい。プロセスが関数に対応する場合では、その終結は、その関数が呼出関数または主関数に戻ることに対応し得る。
「コンピュータ可読媒体」という用語は、命令および／またはデータを記憶するか、含むか、または担持することができるポータブルまたは固定された記憶装置、光記憶装置、ワイヤレスチャネルおよびさまざまな他の媒体を含むが、それらに限定はされない。コードセグメントまたは機械実行可能な命令は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、もしくはプログラム文の任意の組合せを表してもよい。コードセグメントは、情報、データ、引数、パラメータ、またはメモリコンテンツを受け渡すおよび／または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージ受渡し、トークン受渡し、ネットワーク伝送などを含む任意の好適な手段を介して渡されるか、転送されるか、または伝送されてもよい。
さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組合せによって実現されてもよい。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実現されるとき、必要なタスクを実行するプログラムコードまたはコードセグメントは、機械可読媒体に記憶されてもよい。必要なタスクはプロセッサが実行してもよい。
前述の明細書においては、本発明の局面が、その特定の実施形態を参照して説明されているが、当業者は、本発明がそれに限定されないことを認識するであろう。上記の発明のさまざまな特徴および局面は、個々に、または一緒に用いられてもよい。さらに、実施形態は、本明細書の、より広い精神および範囲から逸脱することなく、本明細書に説明されるものを超えて、任意の数の環境および用途において利用されることができる。したがって、明細書および図面は、限定的ではなく例示的であると見なされるべきである。
さらに、例示の目的のため、方法が特定の順序で説明された。代替の実施形態では、方法は、説明された順序とは異なる順序で実行されてもよいことを理解されたい。また、上記の方法は、ハードウェアコンポーネントによって実行されてもよいし、マシン実行可能命令であって、用いられると、そのような命令でプログラムされた汎用もしくは専用のプロセッサまたは論理回路などのマシンに上記の方法を実行させるマシン実行可能命令のシーケンスで具体化されてもよいことも理解されたい。これらのマシン実行可能命令は、ＣＤ－ＲＯＭもしくは他のタイプの光ディスク、フロッピー（登録商標）ディスケット、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、フラッシュメモリなど、または電子命令を記憶するために好適な他のタイプの機械可読媒体等の、１つ以上の機械可読媒体上に記憶されてもよい。代替的に、本方法は、ハードウェアとソフトウェアとの組合せによって実行されてもよい。

Claims (20)

  1. １つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を備える非一時的コンピュータ可読媒体であって、前記動作は、
    クラウドインフラストラクチャにおいてサービスの一部としてプロビジョニングされるべきクラスタの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記クラスタの各々の可用性ドメインの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記可用性ドメインの各々の計算ノードの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記クラスタの各々のロードバランサの数を決定することと、
    前記クラスタの数、前記可用性ドメインの数、前記計算ノードの数、および前記ロードバランサの数に基づいてサブネットレベルの数を計算することと、
    前記サブネットレベルの数に基づいて複数のサブネットを生成することと、
    前記複数のサブネットを前記クラウドインフラストラクチャにおいて前記計算ノードおよび前記ロードバランサに割り当てることとを含む、非一時的コンピュータ可読媒体。
  2. 前記動作は、前記計算ノードの各々および前記ロードバランサの各々が、前記クラウドインフラストラクチャにおいて前記複数のサブネットをプロビジョニングされるようにすることをさらに含む、請求項１に記載のコンピュータ可読媒体。
  3. 前記動作は、さらに、
    前記可用性ドメインの数、前記クラスタの数、前記計算ノードの数、または前記ロードバランサの数に対する変更を受信することと、
    前記変更に基づいて前記サブネットレベルの数を再計算することと、
    前記サブネットレベルの数に基づいて前記複数のサブネットを再生成することとを含む、請求項１に記載のコンピュータ可読媒体。
  4. 前記動作は、さらに、
    前記クラウドインフラストラクチャにおいて第２のサービスの一部としてプロビジョニングされるべき第２の数のクラスタと、第２の数の可用性ドメインと、第２の数の計算ノードと、第２の数のロードバランサとを決定することを含み、前記第２のサービスは前記サービスとは異なり、前記動作はさらに、
    前記第２の数のクラスタと、前記第２の数の可用性ドメインと、前記第２の数の計算ノードと、前記第２の数のロードバランサとに基づいて第２の数のサブネットレベルを計算することを含み、前記第２の数のサブネットレベルは、前記サブネットレベルの数とは異なり、前記動作はさらに、
    前記第２の数のサブネットレベルに基づいて第２の複数のサブネットを生成することを含む、請求項１に記載のコンピュータ可読媒体。
  5. 前記複数のサブネットの数は、底２^（サブネットレベルの数）に等しい、請求項１に記載のコンピュータ可読媒体。
  6. 前記可用性ドメインの数を決定することは、
    前記サービスのために、複数の所定の構成からの、ある構成の選択を受信することと、
    前記構成のためにサービスレベル合意（ＳＬＡ）を決定することとを含み、前記ＳＬＡは前記可用性ドメインの数を定義する、請求項１に記載のコンピュータ可読媒体。
  7. 前記可用性ドメインの数を決定することは、
    前記命令が前記１つ以上のプロセッサによって実行されると、実行時入力として前記可用性ドメインの数を受信することを含む、請求項１に記載のコンピュータ可読媒体。
  8. 前記可用性ドメインにおけるある可用性ドメインは、前記計算ノードのうちの少なくとも１つと、前記ロードバランサのうちの少なくとも１つとを含む、請求項１に記載のコンピュータ可読媒体。
  9. 前記サブネットレベルの数に基づいて前記複数のサブネットを生成することは、
    最上位ネットワークアドレスのクラス無しドメイン間ルーティング（ＣＩＤＲ）スライスを実行する関数を実行することを含む、請求項１に記載のコンピュータ可読媒体。
  10. 前記関数は、前記サブネットレベルの数が実行時に計算され得るように、前記サブネットレベルの数をパラメータとして受け付ける、請求項９に記載のコンピュータ可読媒体。
  11. 前記動作は、前記複数のサブネットの各々に複数のラベルを割り当てることをさらに含む、請求項１に記載のコンピュータ可読媒体。
  12. 前記複数のラベルは、前記可用性ドメインと前記クラスタとの組合せに基づく、請求項１１に記載のコンピュータ可読媒体。
  13. 前記動作は、デカルト積を計算することによって前記可用性ドメインと前記クラスタとの前記組合せを生成することをさらに含む、請求項１２に記載のコンピュータ可読媒体。
  14. 前記デカルト積を計算することは、前記可用性ドメインと前記クラスタとの間のベクトル交差積を生成することを含む、請求項１２に記載のコンピュータ可読媒体。
  15. 前記複数のラベルにおけるインデックスは、前記複数のラベルにおける前記インデックスを前記クラスタの数で割ることによって、前記クラスタにおけるインデックスに関係付けられる、請求項１４に記載のコンピュータ可読媒体。
  16. 前記複数のラベルにおけるインデックスは、前記複数のラベルにおける前記インデックスの前記可用性ドメインの数によるモジュラー除算を実行することによって、前記可用性ドメインにおけるインデックスに関係付けられる、請求項１４に記載のコンピュータ可読媒体。
  17. 前記複数のラベルは、計算ノードまたはロードバランサが宣言されるたびにインクリメントされるカウンタによって変更されるインデックスを含む、請求項１２に記載のコンピュータ可読媒体。
  18. 前記複数のラベルは、ネスト化されたループ構造を使用することなく生成される、請求項１２に記載のコンピュータ可読媒体。
  19. システムであって、
    １つ以上のプロセッサと、
    前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含む１つ以上のメモリデバイスとを備え、前記動作は、
    クラウドインフラストラクチャにおいてサービスの一部としてプロビジョニングされるべきクラスタの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記クラスタの各々の可用性ドメインの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記可用性ドメインの各々の計算ノードの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記クラスタの各々のロードバランサの数を決定することと、
    前記クラスタの数、前記可用性ドメインの数、前記計算ノードの数、および前記ロードバランサの数に基づいてサブネットレベルの数を計算することと、
    前記サブネットレベルの数に基づいて複数のサブネットを生成することと、
    前記複数のサブネットを前記クラウドインフラストラクチャにおいて前記計算ノードおよび前記ロードバランサに割り当てることとを含む、システム。
  20. プロビジョニングスクリプトを実行時調整数のリソース宣言とともに実行するための方法であって、
    クラウドインフラストラクチャにおいてサービスの一部としてプロビジョニングされるべきクラスタの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記クラスタの各々の可用性ドメインの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記可用性ドメインの各々の計算ノードの数を決定することと、
    前記クラウドインフラストラクチャにおいてプロビジョニングされるべき、前記クラスタの各々のロードバランサの数を決定することと、
    前記クラスタの数、前記可用性ドメインの数、前記計算ノードの数、および前記ロードバランサの数に基づいてサブネットレベルの数を計算することと、
    前記サブネットレベルの数に基づいて複数のサブネットを生成することと、
    前記複数のサブネットを前記クラウドインフラストラクチャにおいて前記計算ノードおよび前記ロードバランサに割り当てることとを含む、方法。
JP2022540590A 2019-12-30 2020-12-27 クラウドインフラストラクチャ上における自律的テラフォーム化 Pending JP2023508729A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/730,656 2019-12-30
US16/730,656 US11991041B2 (en) 2019-12-30 2019-12-30 Autonomous terraforming on cloud infrastructures
PCT/US2020/067083 WO2021138224A1 (en) 2019-12-30 2020-12-27 Autonomous terraforming on cloud infrastructures

Publications (2)

Publication Number Publication Date
JP2023508729A true JP2023508729A (ja) 2023-03-03
JPWO2021138224A5 JPWO2021138224A5 (ja) 2023-12-07

Family

ID=74236281

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022540590A Pending JP2023508729A (ja) 2019-12-30 2020-12-27 クラウドインフラストラクチャ上における自律的テラフォーム化

Country Status (5)

Country Link
US (2) US11991041B2 (ja)
EP (1) EP4085331A1 (ja)
JP (1) JP2023508729A (ja)
CN (1) CN115039073A (ja)
WO (1) WO2021138224A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114741993B (zh) * 2022-04-18 2023-06-16 山东浪潮科学研究院有限公司 一种基于脚本的数据流图生成方法及装置
US11818055B1 (en) 2022-05-31 2023-11-14 Walmart Apollo, Llc Systems and methods for automating resource deployment
US12118401B1 (en) * 2023-11-28 2024-10-15 Monday.com Ltd. Digital processing systems and methods for facilitating the development and implementation of applications in conjunction with a serverless environment

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140189155A1 (en) * 2012-12-27 2014-07-03 Deep River Ventures, Llc Methods, Systems, and Computer Program Products for Determining a Protocol Address For a Node
US9317410B2 (en) * 2013-03-15 2016-04-19 International Business Machines Corporation Testing functional correctness and idempotence of software automation scripts
US20160081668A1 (en) * 2013-08-27 2016-03-24 The Johns Hopkins University System and Method For Medical Imaging Calibration and Operation
US9621428B1 (en) 2014-04-09 2017-04-11 Cisco Technology, Inc. Multi-tiered cloud application topology modeling tool
US9832078B2 (en) * 2015-01-06 2017-11-28 Netapp, Inc. Stateless resource management
US11223536B2 (en) * 2016-04-04 2022-01-11 At&T Intellectual Property I, L.P. Model driven process for automated deployment of domain 2.0 virtualized services and applications on cloud infrastructure
WO2019033016A1 (en) * 2017-08-11 2019-02-14 Fugue, Inc. SYSTEM AND METHOD FOR PROVIDING VISUALIZATIONS OF COMPUTER INFRASTRUCTURE USING A DOMAIN-SPECIFIC LANGUAGE FOR CLOUD SERVICES INFRASTRUCTURE
KR101987661B1 (ko) * 2018-07-19 2019-06-11 나무기술 주식회사 클라우드 플랫폼에서의 클러스터 리소스 할당 및 관리 방법
US10999163B2 (en) * 2018-08-14 2021-05-04 Juniper Networks, Inc. Multi-cloud virtual computing environment provisioning using a high-level topology description
US11129159B2 (en) * 2019-04-11 2021-09-21 Servicenow, Inc. Programmatic orchestration of cloud-based services

Also Published As

Publication number Publication date
US20210203549A1 (en) 2021-07-01
US20240267290A1 (en) 2024-08-08
CN115039073A (zh) 2022-09-09
US11991041B2 (en) 2024-05-21
EP4085331A1 (en) 2022-11-09
WO2021138224A1 (en) 2021-07-08

Similar Documents

Publication Publication Date Title
JP6967534B2 (ja) データベースプロビジョニングのためのリソース配分
JP6971341B2 (ja) コンピューティングリソースの配置ポリシーベースの割当て
US10778542B2 (en) Rule based subscription cloning
JP6605019B2 (ja) ポリシーベースのリソース管理および割当てシステム
JP6646048B2 (ja) 異種の電子デバイスのためのアプリケーション配信の区分化
US9600342B2 (en) Managing parallel processes for application-level partitions
EP3155576B1 (en) Providing a subscription for a service using an existing subscription
US20240267290A1 (en) Autonomous terraforming on cloud infrastructures
US20150229521A1 (en) Techniques for automated installation, packing, and configuration of cloud storage services
JP7465869B2 (ja) ユニバーサルガバナンス
JP6541694B2 (ja) 既存のサブスクリプションを用いたサービスのサブスクリプションの提供
JP2018513590A (ja) 顧客関係性管理データに基づいて推奨される登録簿
US11836519B2 (en) Decoupled push-down execution generator
JP2023511113A (ja) 宣言型プロビジョニングツールを使用してインフラストラクチャリソースを展開するための技術
JP2023511117A (ja) 分散バージョン制御システムにおけるコードの更新
JP2023511114A (ja) デプロイ命令のために有向非巡回グラフを利用するための技術
JP7553576B2 (ja) デプロイメントオーケストレータにおけるドリフトを検出するための技術
JP2024500770A (ja) 計算インスタンスの局面を修正するための技術
JP2023511535A (ja) インフラストラクチャオーケストレーションサービスのためのユーザインターフェイス技術

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231129

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20231129