Oracle Cloud Infrastructure Services and Platformの回復性と継続性のFAQ

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

自己回復性および継続的な可用性を実現するには、クラウドスケール・システム内の非可用性(パフォーマンスおよび未処理の失敗)のすべての原因を理解し、処理する必要があります。そのような原因は多数あるので、基本的な性質に従ってカテゴリにグループ化します。

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

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

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

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

前述の各カテゴリについて、オラクルは実証済の設計戦略を使用して、問題に対応します。最も重要なものを、次に示します。

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

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

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

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

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

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

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

問題の影響の最小化

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

デザインの原則からなる建築コンセプト

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

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

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

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

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

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

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

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

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

サービス・セル

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

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

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

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

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

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

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

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

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

サービス設計手順

クラウド・システムの信頼性にはテストとオペレーショナル・パフォーマンスの両方が不可欠であるため、当社は数多くの設計手順を持っています。次に、前の項で説明する概念を活用する重要な手順の一部を示します。

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

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

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

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

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

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

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

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

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

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

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

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

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

建築原理

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

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

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

依存関係

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

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

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

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

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

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

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

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

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

はい。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コンピュート・インスタンスは、コンピュート、ブロック・ストレージ、VCNまたはアイデンティティおよびアクセス管理のコントロール・プレーン機能からデータ・センターが分離されている場合でも、アタッチされたブロック・ボリュームおよび関連付けられた仮想ネットワーク機能とともに引き続き機能します。

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