Oracle Cloud Infrastructureサービスおよびプラットフォームのレジリエンスと継続的な可用性に関するFAQ

オラクルでは、クリティカル・サービス、継続的に利用可能なサービス、単一ロケーション・サービスなど、様々なサービス・クラスを区別していますか。

オラクルでは、このような区別はしていません。かわりに、依存性レベル、可用性スコープおよびデータ・プレーンとコントロール・プレーンでサービスを分類しています。これらのカテゴリは、可用性、永続性、パフォーマンス、利便性の間で、有用なトレードオフを様々に行えるよう設計されています。

依存性レベル

次に示す各レベルは、アーキテクチャ・ブロック図でレイヤーまたは層とみなされる場合があります。各レイヤーが依存するのは、その下のレイヤーのみです。

下から順に、次のとおりです。

• コア・サービス: これらのサービスは、Oracle Cloud Infrastructureの基盤を形成します。これには、Identity and Access Management (IAM)、Key Management、Networking、Compute、Block Volumes、Object Storage、Telemetryおよびいくつかの共有内部サービスがあります。これらは、サービス同士の間でも、依存関係が最小限になるように設計されています。(依存関係の詳細は、このドキュメントの後半を参照してください)。
• IaaS: このレイヤーは、よりインフラレベルの機能を提供するもので、コアの上に構築されます。このレイヤーのサービスには、File Storage、DatabaseおよびContainer Engine for Kubernetesがあります。
• SaaS: このレイヤーは、リッチなSoftware as a Serviceであり、下位レイヤーに基づいて構築されます。

可用性スコープ

サービスの可用性と耐久性の目標を達成するため、各サービスには、次のいずれかの可用性スコープが選択されています。

• 可用性ドメイン・ローカル: 可用性ドメインごとに、サービスの1つの独立したインスタンスが含まれます。このサービスが、同じ可用性ドメイン内のレプリカ間で同期レプリケーションを行うことで、格納されたデータの耐久性を高めています(詳細は、このドキュメントで後述するフォルト・ドメインの項を参照してください)。これらのサービスは、各サービスの性質にもよりますが、可用性ドメイン内の1/3以上のインフラの停止に耐えることができます。可用性ドメイン・ローカルのサービスは、可用性ドメイン内の2種類の論理データ・センター(障害分離とパフォーマンス分離の論理グループ)を使用することで、このレベルのフォルト・トレランスを実現しています。詳細は、このドキュメントで後述するフォルト・ドメインとサービス・セルの項を参照してください。また、これらのサービスは、可用性ドメインが他のどの可用性ドメインとも通信できない場合でも、通常どおり機能し続けることが可能です。そのため、他の可用性ドメインと通信できない状況や、リージョン内のワイド・エリア・ネットワークが完全に機能しない状況にも耐えられます。
• 可用性ドメインが複数あるリージョン: 複数の可用性ドメインがある各リージョンにはサービスの独立したインスタンスが1つ含まれており、そのリージョン内の各可用性ドメインにコンポーネントが置かれています。これらのサービスは、同じリージョン内の複数の可用性ドメインと同期レプリケーションを行うことで、格納されたデータの非常に高い耐久性を実現しています。これらのサービスは、リージョン内の1つの可用性ドメインが停止したり、通信不能になったりしても耐えることができます。
• 可用性ドメインが1つのリージョン: リージョンの可用性ドメインが1つのみの場合、リージョン別サービスに見られる特性は、前述した可用性ドメイン・ローカルのサービスの特性と一致します。可用性ドメイン・ローカルのサービスと可用性ドメインが1つのリージョン別サービスの違いが関係してくるのは、可用性ドメインが1つのみのリージョンに、1つ以上の可用性ドメインを追加して拡張している場合のみです。この場合、各リージョン別サービスは、新しい可用性ドメインを適切に使用するために自動的に拡張されますが、サービスのインスタンスは1つのままです。たとえば、追加の可用性ドメインを使用して既存データの耐久性を向上させるため、Object Storageデータ・プレーンが拡張されます。一方、可用性ドメイン・ローカルのサービスでは、新しい可用性ドメインのそれぞれが、各可用性ドメイン・ローカルのサービスの独立した専用のインスタンスを新しく受け取ります。
• リージョン間の分散: Oracle Cloud Infrastructureの基礎は、各リージョンの運用が他のリージョンから可能なかぎり独立していることです。可能な限りという条件が表しているのは、リージョンでは、少なくともインフラの一部(リージョン間のバックボーン・ネットワークなど)を共有せざるを得ないという事実です。それ例外の場合、オラクルは、透過的な高可用性やフェイルオーバーなど、複数のリージョンに同時に影響を及ぼす問題を引き起こす可能性がある密結合メカニズムをリージョン間に構築しません。かわりに、リージョン間にサービスを分散する2つのメカニズムを疎結合で提供します。
  • ディザスタ・リカバリ(DR): お客様がDR特性を持つシステムを構築できるようにすることは、クラウドにおけるオラクルのアプローチと投資の基礎です。いくつかのコア・サービスでは、すでにDRメカニズムを提供しています。たとえば、Block Volumesリージョン間のバックアップやObject Storageリージョン間のコピーなどです。オラクルのすべてのサービスで、DR機能は、ロードマップにおける優先度が高い項目になっています。
  • リージョン間サブスクリプション: オラクルでは、現在、IAMデータに対してのみリージョン間サブスクリプションを提供しています。概念的には、IAMデータにはグローバル・スコープがあります。お客様は、リージョンのセットをサブスクライブ(オプトイン)でき、オラクルは関連するIAMデータと後続の更新を、指定されたリージョンに自動的にレプリケートします。密結合を避けるため、レプリケーションは非同期で、最終的には一貫性が保たれます。お客様は、ノミネートする「ホーム」リージョン内のIAMデータを変更します。現在のホーム・リージョンがなんらかの理由で使用できなくなった場合や適さなくなった場合は、別のリージョンをノミネートできます。

コントロール・プレーンとデータ・プレーン

サービスのデータ・プレーン は、データ処理インタフェースおよびコンポーネントのコレクションで、アプリケーションで使用することを目的としたサービスの機能を実装します。たとえば、仮想クラウド・ネットワーク(VCN)のデータ・プレーンには、ネットワーク・パケット処理システム、仮想化ルーター、ゲートウェイが含まれ、Block Volumesのデータ・プレーンには、iSCSIプロトコルの実装とボリューム・データ向けのレプリケートされたフォルト・トレラントなストレージ・システムが含まれます。

サービスのコントロール・プレーンは、次のタスクを担当するAPIおよびコンポーネントのセットです。

• リソースをプロビジョニング、再構成、スケール・アップ/ダウンまたは終了する、顧客リクエストの処理
• 大規模フリートの迅速で安全な自動パッチ適用の実行
• リソースの障害、低下または構成ミスの検出
• 自動修復の実行、またはサポート要員の呼出し
• 他のコントロール・プレーンとのコラボレーション(たとえば、コンピュート、VCN、ブロック・ストレージはLaunchInstance中に結合されます)
• 未使用容量の管理
• 新しい装置が到着する際や、物理的な修理およびメンテナンスを行う際などにおける人間との調整
• 運用の可視性と制御性の提供

オラクルでは、サービスが自己回復性を備え、継続的に使用可能であることをどのようにして保証しますか。

フォルト・トレラントでスケーラブルな分散システムを構築する際の基本的な設計課題は、どのタイプのサービスでも同じであるため、オラクルは、すべてのタイプのサービスに、同じ一連の設計原則を適用して自己回復性と可用性を実現しています。

自己回復性と継続的な可用性を実現するには、クラウドスケール・システム内の非可用性(パフォーマンスの低下と対応されていない障害)のすべての原因を把握し、対応する必要があります。それに類する原因は多数あるので、基本的な性質に従ってカテゴリにグループ化します

従来、エンタープライズITシステムの可用性の分析は、ハードウェア障害のカテゴリに焦点が当てられてきました。一方、クラウド・システムでは、ハードウェア障害は比較的軽度で、理解の進んでいる問題です。現在、ハードウェアのほとんどの単一障害点は、比較的簡単に回避または軽減できます。たとえば、ラックではデュアル電源フィードと関連する配電盤を使用でき、多くのコンポーネントはホットスワップ可能です。自然災害などが原因の大規模なハードウェア障害や喪失の可能性はもちろんあります。しかし、オラクルの経験と、他のクラウド・ベンダーが公開している事後分析のレポートによると、非可用性のその他の原因に比べ、データ・センター全体の障害または喪失はめったに発生しません。それでも、(ディザスタ・リカバリやその他のメカニズムなどで)大規模ハードウェア障害に対応する必要はありますが、決して可用性の主要な問題ではありません。

クラウドスケール・システムの非可用性の主要な原因は次のとおりです。

• ソフトウェアのバグ
• 構成エラー
• 人間のオペレータのミス
  注意: この3つの形式のヒューマン・エラーが、明らかに非可用性の最大の原因であるということが、業界の最も重要な教訓です。ヒューマン・エラーの頻度はツールや自動化、トレーニングによって減らせますが、なくすことはできません。そのため、システムのアーキテクチャ、設計、実装の第一の考慮事項として取り組む必要があります。
• なんらかの理由による、許容できないパフォーマンス(レイテンシまたはスループット)の変動。次に例を示します。
  • マルチテナントのノイジー・ネイバー(QoSメカニズムの障害)
  • 実質的な作業を継続しながら(偶然または悪意による)過剰な負荷を効率よく拒否できない
  • 分散スラッシュ、大量のメッセージ、大量の再試行、その他の負荷がかかる緊急のインタラクション
  • 電源投入後のコールドショック(空のキャッシュ)。特に複数のシステムの同時電源投入
  • システムのスケーリング時のオーバーヘッド(再シャーディングなど)
• これまでに挙げた問題のいずれかが影響する範囲(影響を受ける顧客とシステムの数)の制限の失敗

これらは一般的な課題で、クラウドスケールの分散システムにおける物理法則の一部です。

前述の各カテゴリについて、オラクルは実証されたエンジニアリング戦略で問題に取り組みます。これらのうち、最も重要なのは次のとおりです。

• アーキテクチャおよびシステム設計の原則
• 新しいアーキテクチャの概念(前述の原則を適用することで生じるのが一般的)
• サービス設計手順

アーキテクチャおよびシステム設計の原則

多くの原則が存在しますが、自己回復性と可用性に最も関連するものに焦点を当てます。

リカバリ指向のコンピューティング

比較的影響が局所的なソフトウェア・バグとオペレータのミスに対応するため、オラクルは、リカバリ指向のコンピューティングの原則に従います¹。大まかに言うと、これは問題が1つもないことを保証しようとする(これはテストすることが不可能です)よりも、テスト可能な方法で、問題が表面化しないよう対応することに集中するという意味です。具体的には、平均検出時間、平均診断時間および平均緩和時間の組合せである平均リカバリ時間(MTTR)に重点を置きます。

オラクルの目標は、人間のユーザーが問題によって不便を感じないよう、すばやくリカバリすることです次の点が、この目標の達成に役立っています。

• コードにアサーションを多用して、すべてのレベルでアクティブに監視とアラームを行うことにより、バグやオペレータのミスの兆候をすばやく自動的に検出します。
• 疎結合で独立しており、多数の細かく分離した単位(スレッド、プロセス、ファイバ、ステート・マシンなど)に機能をパッケージ化します。つまり、単位同士は、破損する可能性のあるメモリーを直接共有しません。
• バグまたはオペレータのミスの兆候を検出したら、分離した単位の囲みをできるだけ迅速に自動的に再開します。入念にテストされた状態の再確立により、不変条件の復元が試みられるため、再開は、任意の障害からのリカバリを試行する実用的な方法です。
• 細かく分離した単位でのリカバリが機能しない(たとえば、アサーションがそのレベルで非常に頻繁に起動し続けるためクラッシュが繰り返し引き起こされている)場合は、次に大きい単位(プロセス、ランタイム、ホスト、論理データ・センター、人間のオペレータの呼出し)にエスカレーションします。
• 不正なコミットを迅速に識別して元に戻すために、すべての永続的な状態と構成のバージョニング理も含め、システム全体を元に戻すことが可能なメカニズムを構築しています。

問題の影響の最小化

影響が広範囲に及ぶ可能性があるバグやミスに対応するために、オラクルは、あらゆる問題の影響範囲を最小化するメカニズムを構築しています。つまり、問題の影響を受ける顧客やシステム、リソースの数の最小化に重点を置いているということです。この問題には、マルチテナントのノイジー・ネイバー、過負荷状態の発生、容量の低下、分散スラッシュなど、特に難しい問題も含まれています。これは、様々な分離境界や変更管理プラクティス(次の項を参照)で実現しています。

設計原則から生じるアーキテクチャ概念

多くの概念が存在しますが、影響の範囲を制限する概念に焦点を当てます。

パブリックAPIに規定されている配置概念: リージョン、可用性ドメインおよびフォルト・ドメイン

フォルト・ドメインは比較的新しいため、これについて詳しく説明します。

フォルト・ドメインは、デプロイメント、パッチ適用、ハイパーバイザの再起動、物理メンテナンスなど、システムがアクティブに変更されているときに発生する問題の影響範囲を制限するために使用されます。

特定の可用性ドメインで、最大1つのフォルト・ドメインにあるリソースが任意の時点で変更されることが保証されます。変更プロセスで何かがうまくいかない場合、そのフォルト・ドメイン内のリソースの一部またはすべてをしばらく使用できなくなりますが、その可用性ドメイン内の他のフォルト・ドメインは影響を受けません。各可用性ドメインには少なくとも3つのフォルト・ドメインがあるため、1つの可用性ドメインで、クォーラムベースのレプリケーション・システム(Oracle Data Guardなど)を、高い可用性でホスティングできます。

そのため、可用性の問題(ソフトウェアのバグ、構成エラー、オペレータのミス、変更手順中に発生するパフォーマンスの問題)の主なカテゴリについて、各フォルト・ドメインは、可用性ドメイン内の独立した論理データ・センターとして機能します。

フォルト・ドメインでは、ある種のローカライズされたハードウェア障害からも保護されます。フォルト・ドメインのプロパティは、異なるフォルト・ドメインに配置されているリソースが、可用性ドメイン内の潜在的なハードウェアの単一障害点を共有しないことを可能なかぎり最大限に保証します。たとえば、異なるフォルト・ドメイン内のリソースは、同じトップオブラック・ネットワーク・スイッチを共有しません。このようなスイッチの標準設計には冗長性がないためです。

ただし、ハードウェア内または物理環境内の問題から保護するフォルト・ドメインの機能は、そのローカル・レベルに止まります。可用性ドメインおよびリージョンとは対照的に、フォルト・ドメインはインフラストラクチャの物理的な大規模分離を提供しません。自然災害や可用性ドメイン全体のインフラストラクチャ障害といったまれなケースでは、複数のフォルト・ドメイン内のリソースが同時に影響を受ける可能性があります。

オラクルの内部サービスでは、お客様が使用するのと同じ方法でフォルト・ドメインを使用します。たとえば、Block Volumes、Object StorageおよびFile Storageサービスは、3つの異なるフォルト・ドメインにデータのレプリカを格納します。すべてのコントロール・プレーンおよびデータ・プレーンのすべてのコンポーネントは、3つの障害ドメインすべてにホストされます（または、複数の可用性ドメインからなるリージョン、複数の可用性ドメイン）。

サービス・セル

サービス・セルは、システムがアクティブに変更されていないときでも発生する問題の影響範囲を制限するために使用されます。このような問題が発生する原因は、マルチテナント・クラウド・システムのワークロードが任意の時点で極端に変わる可能性があることや、大規模な分散システムで任意の時点に複雑な部分障害が発生する可能性があることです。これらのシナリオは、隠れた小さなバグまたは突発的なパフォーマンスの問題をトリガーする可能性があります。

また、サービス・セルは、システムがアクティブに変更されているときに、まれではありますが難しいシナリオでの影響範囲も制限します。従来の例は、個々のフォルト・ドメインへのデプロイメントが成功した(エラーやパフォーマンスの変化がない)ように見えても、2番目または最後のフォルト・ドメインが更新された直後に、(本番ワークロードのフル・クラウド・スケールでの)システム内の新しいインタラクションが原因でパフォーマンスの問題が発生することです。

サービス・セルの使用はアーキテクチャ・パターンであり、Oracle Cloud APIまたはSDKで明示的に指定されている概念ではありません。マルチテナント・システムでは、このアーキテクチャ・パターンを使用できます。クラウド・プラットフォームによる特殊なサポートは必要ありません。

サービス・セルは次のように動作します。

• サービスの各インスタンス(たとえば、特定のリージョン内、または可用性ドメイン・ローカル・サービスの特定の可用性ドメイン内)は、サービスのソフトウェア・スタックの複数の独立したデプロイメントから構成されます。個々のデプロイメントはセルと呼ばれます。各セルは、できるかぎり独自のインフラストラクチャにホストされます。少なくとも、セルはホストまたはVMを共有しません。
• サービスは、各可用性ドメインまたはリージョン内のわずかなセルから開始できます。需要の増加に合せてサービスがスケーリングされると、問題の影響範囲のサイズに対する制限を維持するためにセルが追加されます。大規模で普及しているサービスには多くのセルがある可能性があります。つまり、セルは、顧客のワークロードをnからmに多重化して、ホスティング環境(リソース分離のアイランド)を分割しているのです。セルには、フォルト・ドメインに存在するような明白なカーディナリティはありません。(前述のように、クォーラムベースのレプリケーション・システムを単一の可用性ドメイン内に高い可用性でホストするために、フォルト・ドメインのカーディナリティに対する明らかな選択肢は、可用性ドメイン当たり3つです。)
• 顧客ワークロードの各"自然単位"は特定のセルに割り当てられます。"自然単位"の定義は、特定のサービスの性質によって決まります。たとえば、内部共有ワークフロー・サービス(後述)の場合、自然単位は"特定のコントロール・プレーンに対するこの可用性ドメインまたはリージョン内のすべてのワークフロー"になることがあります。
• セルの各グループの前には、ミニマリズム的なルーティング・レイヤーまたはセル・エンドポイントを検出するためのAPIがあります。たとえば、ストリーミング/メッセージング・システムには、特定のトピックに関する現在のデータ・プレーン・エンドポイントを検出するためのAPIがあり、内部メタデータ・ストアにはセルごとに別々のエンドポイントがあります。一方、他のセルベース・サービスには単一のデータ・プレーン・エンドポイントと共有ルーティング・レイヤーがあります。ルーティング・レイヤーは、複数のセルの相関する障害の潜在的な原因ですが、これはルーティング・レイヤーを極めてシンプル、予測可能、かつ高パフォーマンス(コストの高い操作なし)に保ち、大量のヘッドルーム容量と高度なQoSクォータおよびスロットル・メカニズムでプロビジョニングすることで緩和されます。
• サービス所有者は、必要に応じてワークロードをセル間で移動できます。次にシナリオの例を示します。
  • セルの他のユーザーが影響を受けないように大きなワークロードを移動することで、マルチテナント"ノイジー・ネイバー"の問題を避けるため。
  • 分散型サービス拒否攻撃が原因の過負荷または電圧低下からリカバリするため。オラクルには、このような攻撃を防御する割当ておよびスロットル・メカニズムがありますが、場合によってはエッジ・ケースが発生することがあります。エッジ・ケースでは、特定のユース・ケース(API、アクセス・パターン)が、現在システムで認識されている割当てまたはスロットルよりもサービスにとって厄介です。セルは、短期緩和のメカニズムを提供します。
  • クリティカルなワークロードを異なるセルに分離して、相関する障害の確率を大幅に低下させるため。たとえば、コントロール・プレーンの内部共有ワークフローでは、「クリティカル・コア」コントロール・プレーン(たとえば、Platform、Compute、Networking、Block Volumes)はそれぞれ異なるセルに割り当てられるため、セルが使用されていない場合、または同じセルに割り当てられた場合よりも、相関する障害が大幅に減ります。
    注意: セルのこの用途により、自己回復性を備えたアプリケーションをビルドするためにお客様がサービスの内部依存関係を検討する必要性が軽減されます。依存関係グラフの検討は依然として優れたプラクティスですが(このドキュメントで後ほど詳述します)、非相関メカニズムがすでにアクティブな場合にはその必要性が低くなります。

結果として、各サービス・セルはまだ単一の可用性ドメインまたはリージョン内の別の種類の"論理データ・センター"（パフォーマンス分離と障害分離の論理グループ）です。

要約すると、サービス・セルおよびフォルト・ドメインは次の方法で相互に補完します。

• フォルト・ドメインは、システムがアクティブに変更されているときに問題から保護します。
• サービス・セルは、(アクティブに変更されているかどうかにかかわらず)システムで潜在的に重大な問題が発生した場合の影響範囲を制限します。

オラクルでは、デプロイメントとパッチ適用を実行する際に、フォルト・ドメインとサービス・セルのプロパティを統一戦略に結合します。

サービス設計手順

クラウド・システムの信頼性にはテストとオペレーショナル・エクセレンスの両方が不可欠であるため、オラクルには多数の設計手順があります。手順の項で言及した概念を活用する重要な手順の一部を次に示します。

• 手順間で慎重に検証し、突発的な状況が発生した場合に反射的ロールバックを行って、サービスを増分的にデプロイします。具体的には、プロセスは次のとおりです。
  • 各可用性ドメインで、一度に1つのサービス・セルをデプロイします。各セルについて、そのセルのすべてのフォルト・ドメインを完了するまで、一度に1つのフォルト・ドメインをデプロイします。その後、その可用性ドメイン内の次のセルに進みます。
  • デプロイメントの各手順の後(各フォルト・ドメインとセルの後)に、変更が意図したとおりに機能していることを確認します。つまり、内部的にも外部的にも、パフォーマンスの低下がなく、エラーが生じていないことを確認します。何かが間違っているか期待どおりでないように見える場合は、変更を反射的にロールバックします。オラクルでは、永続的な状態またはスキーマに影響する変更など、ロールバック手順の準備とテスト(自動化されたテストを含む)を重視します。
  • この方法で、各リージョンに一度に1つの可用性ドメインの変更をデプロイします。お客様がプライマリ・サイトとディザスタ・リカバリ・サイトに使用できる任意のリージョンのペアを同時に変更しないような方法で、レルム内のすべてのリージョンにデプロイします。
• エラー処理メカニズムとその他の緩和が期待どおりに機能し、問題を大規模に悪化させないことを定期的に検証します。このようなテストがないと、エラー処理メカニズム(再試行、クラッシュリカバリ・アルゴリズム、ステート・マシン再構成アルゴリズムなど)はバグを含んでいること、コストが高すぎること、または突発的な方法で相互作用することが一般的であるため、分散スラッシュやその他の重大なパフォーマンスの問題を引き起こします。
• オラクルでは、前に説明したように、永続的な状態とスキーマなど、最後の既知の良好なソフトウェアおよび構成にすばやく安全にロールバックできることを検証します。

複数の可用性ドメインを含むOracleリージョンでは、すべてのクリティカル・サービスが可用性ドメイン間に分散されますか。

その答えは「はい」です。リージョンごとに、すべての可用性ドメインでは、同じ一連のサービスが提供されています。

オラクルとその顧客は、単一の論理データ・センターに依存するクリティカル・サービスをどのように回避しますか。

単一可用性ドメインのリージョンでは、お客様はフォルト・ドメイン(グループ間で相関していない障害モードを持つ論理グループ)を使用して、独立した「論理データ・センター」のプロパティを最大限に活用できます。お客様は、ディザスタ・リカバリ(DR)に複数のリージョンを使用することもできます。

複数の可用性ドメインからなるリージョンでは、お客様も同様に障害ドメインを使用できます。お客様は、ローカル可用性ドメイン・サービス、可用性ドメイン間フェイルオーバー機能(Data GuardのあるDBaaSなど)およびリージョン別サービス(Object Storage、Streaming)の組合せを使用して、上位レベルの「論理データ・センター」 (可用性ドメイン)全体で完全なHAを実現することもできます。最後に、お客様はDRに複数のリージョンを使用することもできます。

どの場合でも、お客様はサービス・セルの概念を使用して、分散スラッシュなどの最も重大な問題さえも分離できます。

オラクルでは、顧客がクリティカル・サービスを一時的に使用できなくなることなしにどのようにしてメンテナンス・アクティビティを実施しますか。

オラクルでは、フォルト・ドメイン、サービス・セル、および増分デプロイメントと検証の運用手順を使用してこれを実現しています。このドキュメントで前述した説明を参照してください。

サーバーレス・プラットフォーム・サービスは、高可用性を実現するために複数の論理データ・センターにデプロイされますか。

その答えは「はい」です。耐障害性と継続的な可用性のために、サービスのすべてのカテゴリは、複数の論理データ・センター（障害分離とパフォーマンス分離の個別の論理グループ）にデプロイされます。

耐障害性がデフォルト構成ではない場合、顧客には複数の論理データ・センター・デプロイ（たとえば、複数の可用性ドメインからなる構成またはリージョン間構成）の選択肢が提供されますか。

単一可用性ドメイン・リージョンでは、このドキュメントの他の場所で説明しているように、フォルド・ドメインを「複数論理データ・センター」のメカニズムとして提供しています。

複数の可用性ドメインからなるリージョンでは、（リージョン内の可用性ドメイン間の距離による適度なパフォーマンス・コストおよび光の速度で）同期的にレプリケーションされるデータの物理的な持続性をさらに高めるサービスと機能を提供します。

リージョン間に自動的なHAまたはフェイルオーバー・メカニズムは提供しません。これにより、リージョン間に密結合関係が作成され、複数のリージョンで同時に問題が発生するリスクが生じるからです。かわりに、リージョン間で様々な形式の非同期レプリケーションを有効にし、非同期コピーおよびバックアップなど、ますます数が増える機能を提供してリージョン間のディザスタ・リカバリを有効にします。

オラクルでは、様々なインフラストラクチャおよびプラットフォーム・サービス間の内部依存関係が原因のアプリケーションの相関する障害をどのように回避しますか。

これは複雑な質問なので、明確化のために、いくつかの別の方法で言い換えます。

• お客様が2つのOracleサービス(サービスAとサービスB)を使用し、これらのサービスのいずれかに障害が発生した場合に自己回復できるアプリケーションを構築することを希望している場合、お客様はサービスAがサービスBに内部的に依存しているかどうかを知る必要があるでしょうか。内部依存関係はかなりの程度の相関する障害を引き起こすでしょうか。その場合、顧客は、独自の耐障害性機能をアプリケーション・レベルで構築する際に、他のどのユーザーがサービスAとサービスBを使用するか、または追加ケース用の関連のないサービスCをかわりに使用するかどうかを確認するために、このような内部依存関係について知る必要があります。
• お客様は、Oracleサービスの相関する障害をどのようにして最適に防御するでしょうか。

回答は2つの部分に分かれます。

アーキテクチャ理念

オラクルでは、依存サービス間の相関する障害を大幅に削減するアーキテクチャ理念を使用します。場合によっては、この手法により、相関する障害の確率は、可用性サービス・レベル合意(SLA)を満たすという観点からは無視できる程度にまで減ります。

具体的には、このドキュメントで前述したサービス・セルを使用します。内部サービスAが依存関係の1つであるサービスBの問題の影響を受ける場合、サービスBの問題は単一セルに限定される可能性が非常に高いため、セルはこの問題に役立ちます。サービスBを使用する他の上位レベル・サービスおよびお客様固有のアプリケーションは、影響を受けない他のセルを使用する可能性が高くなります。これは、セルの数により変化する確率的な引数で、変化(増加)しない非表示の内部パラメータであるため、サービスAおよびBのスタンドアロン・サービスSLAを超えて定量化や保証は提供されません。ただし、実際には、これはサービス間の障害を大幅に分離できます。

コントロール・プレーンのワークフロー・サービスやメタデータ・サービス、およびストリーミング/メッセージング・サービスなどの共有内部サービスの多くは、サービス・セルを使用して、それらを使用するアップストリーム・サービスの停止を分離します。

依存関係

詳細レベルの実装とサービスの詳細は変更される可能性があるため、次のガイダンスは概要レベルです。しかし、コンピュート、ストレージ、ネットワークおよび認証/認可の主要なディメンションについて、次の依存関係を示します。

コントロール・プレーンの場合、一般的な依存関係は次のとおりです。

• 認証および認可用のIdentity/Platformデータ・プレーン
• 監査追跡サービス
• ワークフロー、メタデータ・ストレージ、ロギングなどを提供する内部サービス
• 様々なタイプのロード・バランサ

一部のコントロール・プレーンには、明らかにサービス固有の依存関係があります。たとえば、Computeコントロール・プレーンは、ベア・メタルまたはVMインスタンスの起動時に次のものに依存します。

• Object Storage (指定されたオペレーティング・システムを取得するため)
• Block Volumesコントロール・プレーン(ブート・ボリュームをプロビジョニングおよびアタッチするため)
• Networkingコントロール・プレーン(VNICをプロビジョニングおよびアタッチするため)

コア・サービス・データ・プレーンの場合、一般原則は、高可用性、迅速な診断および迅速なリカバリを実現するために、各データ・プレーンが意図的に最小限の依存関係を持つように設計されることです。その原則の結果は次のようになります。

• Networkingデータ・プレーンは自己完結型です。
• Block Volumesデータ・プレーンは自己完結型です。
• Computeベア・メタルおよびVMインスタンスはBlock Volumesデータ・プレーン(ブート・ボリュームの場合)およびNetworkingデータ・プレーンに依存します。
• Object Storageデータ・プレーンは、認証および認可のためにIdentity/Platformデータ・プレーンに依存します(業界の期待事項のため)。Object Storageデータ・プレーンは、Block VolumesまたはFile Storageに依存しません。
• バックアップおよびリストアをサポートするすべてのサービスは、その機能についてObject Storageデータ・プレーンに依存します。

IaaSデータ・プレーンの場合、一般原則は、コアまたは下位レベルのデータ・プレーンにのみ依存することです(循環依存関係を回避するため)。

• データベース・マルチノードRACは、Networkingデータ・プレーンとBlock Volumesデータ・プレーンに依存します。
• Container Engine for Kubernetesは、明らかにKubernetesとその推移的依存関係(たとえば、etcd)およびNetworkingデータ・プレーンに依存します。
• バックアップおよびリストアのすべてのサポートはObject Storeデータ・プレーンに依存します。

リージョンのAPIエンドポイントを含むリージョン内のOracle Cloud Infrastructureサービスは、グローバル・コントロール・プレーン機能から切り離されている場合は引き続き動作しますか。

はい。Oracle Cloud Infrastructureサービスはリージョンに依存しない設計であるため、Oracle Cloud Infrastructureリージョン内のサービスは、そのリージョンが他のOracle Cloud Infrastructureリージョンやグローバル・コントロール・プレーンから切り離された場合でも、引き続き運用できます。サービスAPIエンドポイントを含むデータ・プレーン機能とコントロール・プレーン機能は両方とも、リージョンが分離されていても引き続き使用できます。

多くのOracle Cloud Infrastructureサービスは、Oracle Cloud Infrastructure Object Storageで提供されるクロスリージョン・オブジェクト・コピー機能など、リージョン間の機能を提供します。Oracle Cloud Infrastructureのリージョン間の機能は常に、リージョンの分離がリージョン間の機能に影響する場合でもコア・サービスに影響しないように、コア・サービスのレイヤーとして設計されています。例として、Oracle Cloud Infrastructureオブジェクト・ストア・クロスリージョン・コピー機能は、オブジェクト・ストア・サービスの上にレイヤーとして設計されているため、リージョンの分離は、関連するリージョン間コピー機能に影響する可能性がありますが、リージョン内のコア・オブジェクト・ストレージ・サービスには影響しません。

論理データ・センターのOracle Cloud Infrastructureサービスは、リージョン別コントロール・プレーン機能から切り離され、引き続き運用されますか。

はい。Oracle Cloud Infrastructureサービスは、対応するリージョナル・コントロール・プレーンから切り離された場合でも、すべての論理データ・センターのデータ・プレーン機能が動作し続けるように設計されています。たとえば、データ・センター内のOracle Cloud Infrastructureコンピュート・インスタンスは、コンピュート、ブロック・ストレージ、VCNまたはアイデンティティ/アクセス管理のコントロール・プレーン機能からデータ・センターが分離されている場合でも、アタッチされたブロック・ボリュームおよび関連する仮想ネットワーク機能とともに引き続き機能します。

Oracle Cloud Infrastructureリージョンには高可用性のための冗長インターネット接続がありますか。

その答えは「はい」です。Oracle Cloud Infrastructureは、すべての商用リージョンの複数の冗長プロバイダを経由してインターネットに接続されています。これらの接続では、BGP (Border Gateway Protocol)を使用します。