フォルト・トレラントでスケーラブルな分散システムを構築する際の基本的な設計課題は、どのタイプのサービスでも同じであるため、オラクルは、どのタイプのサービスでも同じ設計原則のセットを使用して自己回復性と可用性を実現しています。
自己回復性および継続的な可用性を実現するには、クラウドスケール・システム内の非可用性(パフォーマンスおよび未処理の失敗)のすべての原因を理解し、処理する必要があります。そのような原因は多数あるので、基本的な性質に従ってカテゴリにグループ化します。
従来の、エンタープライズITシステムの可用性の分析は、ハードウェア障害のカテゴリに焦点が当てられてきました。一方、クラウド・システムでは、ハードウェア障害は比較的軽度で、理解の進んでいる問題です。現在、ハードウェアの単一点の大部分の障害を回避または軽減することが比較的簡単になりました。たとえば、ラックでは二系電源フィードと関連付けられた電力配分装置を設置し、多くのコンポーネントはホットスワップ可能です。自然な災害などが原因の大規模なハードウェアの障害や損失はもちろん可能です。しかし、オラクルの経験と、他のクラウド・ベンダーが公開している事後分析のレポートによると、非可用性のその他の原因に比べ、データ・センター全体の障害または喪失はまれに発生しません。それでも、(障害回復やその他のメカニズムなどで)大規模なハードウェア障害に対応する必要はありますが、決して可用性の高い主要な問題ではありません。
クラウドスケール・システムの非可用性の主要な原因は次のとおりです。
- ソフトウェアのバグ
- 構成エラー
- ヒューマン・オペレータのミス
ノート: この3つの形式のヒューマン・エラーが、明らかに非可用性の最大の原因であるということが、業界の主な章です。頻度はツールや自動化、トレーニングによって減らせますが、なくすことはできません。そのため、システムのアーキテクチャ、設計、実装の第一の考慮事項として取り組む必要があります。
- なんらかの理由による、許容できないパフォーマンス(レイテンシまたはスループット)の変動。次に例を示します。
- マルチテナントの「うるさい隣人」(QoSメカニズムの障害)
- 実質的な作業を継続しながら(偶然または悪意による)過剰ロードを効率的に拒否できない
- 分散スラッシュ、大量のメッセージ、大量の再試行、その他の負荷がかかる緊急のインタラクション
- 電源投入後のコールドショック(空のキャッシュ)。特に複数のシステムの同時電源投入
- システムのスケーリング時のオーバーヘッド(再シャーディングなど)
- 前述の問題の「blast radius」(影響を受ける顧客とシステム数)の制限の失敗
これらは一般的な課題で、クラウドスケールの分散システムにおける物理法則の一部です。
前述の各カテゴリについて、オラクルは実証済の設計戦略を使用して、問題に対応します。最も重要なものを、次に示します。
- アーキテクチャおよびシステム設計の原則
- 新しいアーキテクチャの概念(前述の原則を適用することで生じます)
- サービス設計手順
アーキテクチャおよびシステム設計の原則
多くの原則がありますが、自己回復性と可用性に最も関連するものに焦点を当てます。
リカバリ指向コンピューティング
比較的影響がローカライズされたソフトウェア・バグとオペレータのミスに対応するため、オラクルは、リカバリ志向のコンピュータの原則に従います1。大まかに言うと、これは問題が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つの可用性ドメインの変更をデプロイします。お客様がプライマリ・サイトと障害時リカバリ・サイトに使用できる任意のリージョンの同時変更を行わないように、レルム内のすべてのリージョンにデプロイします。
- エラー処理メカニズムとその他の緩和が期待どおりに機能し、問題を大規模に悪化させません。このようなテストがないと、エラー処理メカニズム(再試行、クラッシュリカバリ・アルゴリズム、ステート・マシン再構成アルゴリズムなど)は、バグを含んでいること、コストが高すぎること、または突発的な方法で相互作用することが一般的であるため、分散スラッシュやその他の重大なパフォーマンスの問題が発生します。
- オラクルでは、前に説明したように、永続的な状態とスキーマなど、最後の既知の良好なソフトウェアおよび構成にすばやく安全にロールバックできることを検証します。