クラウドは、多くの場合、グローバルに分散されたユビキタス システムと考えています。 ただし、実際には、クラウドはデータセンターで実行されているハードウェアで構成されています。 回復性では、クラウドでホストされるコンポーネントが実行される物理的な場所に関連するいくつかのリスクを考慮する必要があります。
この記事では、冗長性、レプリケーション、バックアップの一般的な概要について説明します。これは、サービスの中断、停止、またはデータ損失を引き起こす物理的なリスクに対する回復性があるワークロードを作成するために使用される方法です。
冗長性 とは、サービス コンポーネントの複数の同一のコピーを保持し、1 つのコンポーネントが単一障害点になることを防ぐ方法でそれらのコピーを使用する機能です。
レプリケーションまたはデータ冗長性 は、レプリカと呼ばれるデータの複数のコピーを保持する機能です。
バックアップ は、失われたデータを復元するために使用できるデータのタイムスタンプ付きコピーを保持する機能です。
信頼性の観点から、多くのリスクを軽減する重要な方法は、何らかの形式の冗長性、レプリケーション、またはバックアップを ビジネス継続性計画に含める方法です。
注
この記事では、個々の Azure サービスに関する設計ガイダンスや詳細情報は提供しません。 信頼性の観点から特定の Azure サービスがどのように機能するかについては、 各サービスの信頼性ガイドを参照してください。
冗長性
冗長性は、コンポーネントの複数の インスタンスを デプロイすることで構成 されます。 冗長性は簡単に理解できますが、状況によっては、実装が複雑になる場合があります。
冗長性を理解し始めるときは、ステートレス コンポーネント (データを格納しないコンポーネント) に関連して冗長性を検討するのが最も簡単です。 ほとんどの実際のソリューションでは状態の管理が必要ですが、このセクションでは、ステートレス アプリケーション プログラミング インターフェイス (API) の例の観点から冗長性について説明します。 この例の API は入力を受け入れ、その入力に対して機能し、データを格納せずに出力を返します。 後続のセクション「 レプリケーション: データの冗長性」では、ステートフル冗長性に関する考慮事項を追加します。
シナリオ: ステートレスな冗長性
この例では、ステートレス API コンポーネントが仮想マシンにデプロイされます。 物理ホストでハードウェア障害が発生した場合に API コンポーネントのダウンタイムを回避するために、この例では次の冗長ソリューションを実装しています。
- API インスタンスの複数のコピーをデプロイします。
- API インスタンス間で要求を分散する ロード バランサー を実装します。
ロード バランサーは、正常なインスタンスにのみ要求を送信するように各インスタンスの正常性を監視します。
冗長性に関する考慮事項
上記のシナリオのような冗長ソリューションを実装する場合は、次の点を考慮することが重要です。
リソース コスト。 定義上、冗長性には複数のコピーが含まれるため、ソリューションをホストするための総コストが増加します。
性能 モノのコピーを配布する地理的領域が広いほど、軽減に役立つリスクが高くなります。 ただし、クライアントからの要求は、より多くのネットワーク インフラストラクチャを経由する必要があるため、より長い距離を移動するのに時間がかかります。これにより、 ネットワーク待機時間が長くなります。
ほとんどの実際の状況では、データセンター内や都市全体のデータセンター間など、短い距離ではネットワーク待ち時間は重要ではありません。 ただし、コピーを長距離に分散すると、ネットワーク待ち時間が大幅に長くなる可能性があります。
インスタンスの一貫性。 インスタンス間で誤って違いが生じる可能性があるため、インスタンスの一貫性を維持し、インスタンスを個別に構成しないようにすることが重要です。 インスタンス間に違いがある場合は、要求を処理するインスタンスに応じて異なる方法で要求が処理される可能性があります。 これにより、バグや動作の診断が困難になることがあります。
作業の分布。 コンポーネントの複数のインスタンスがある場合は、それらの間で作業を分散する必要があります。 すべてのインスタンスに均等に作業を分散させたり、1 つのプライマリ インスタンスに要求を送信したり、 プライマリ インスタンスが使用できない場合にのみセカンダリ インスタンスを使用したりできます。
受信要求を受信するコンポーネントの場合、ロード バランサーは多くの場合、それらの要求をインスタンスに送信するために使用されます。 ただし、コンポーネントが独立して動作し、クライアントから要求を受け取らない場合があるため、このような状況では、インスタンスが互いに作業を調整する必要がある場合があります。
健康状態の監視 各インスタンスの正常性によって、そのインスタンスがその処理を実行できるかどうかが決まります。正常性の監視は、問題が発生した場合に高速復旧を有効にするために重要です。
ロードバランサーは通常、ヘルスモニタリング機能を実行します。 ロード バランサーを含まないコンポーネントの場合、すべてのインスタンスの正常性を監視する外部コンポーネントがある場合や、各インスタンスが他のインスタンスの正常性を監視する場合があります。
クラウド内の物理的な場所
クラウド環境であっても、インスタンスまたはデータの一部が特定の物理的な場所に格納されることを理解すると、冗長性の必要性が明確になります。
例えば次が挙げられます。
- 仮想マシンは、一度に 1 つの物理的な場所で実行されます。
- データは、ソリッド ステート ドライブ (SSD) やサーバーに接続されているハード ディスクなど、特定の物理的な場所に格納されます。
1 つのデータまたはコンポーネントのインスタンスのコピーが複数存在する場合でも、各コピーは、格納されている物理ハードウェアに関連付けられます。
クラウド環境の物理的な場所全体を物理的なスコープに編成できます。 物理スコープごとに、そのスコープ内のコンポーネントまたはデータを侵害する可能性がある潜在的なリスクがあります。 以下は、物理的なスコープの観点から定義できる、無限ではないリスクのリストです。
| 物理的な範囲 | 考えられるリスク |
|---|---|
| ディスクやサーバーなどの特定のハードウェア | ハードウェア障害 |
| データセンター内のラック | ラック上部ネットワークスイッチの障害 |
| データセンター | 建物の冷却システムに関する問題 |
| Azure では可用性ゾーンと呼ばれるデータセンターのグループ | 都市全体の電気嵐 |
| データセンターが存在するより広い地理的領域 (Azure リージョンである市区町村など) | 広範囲にわたる自然災害 |
信頼性の観点から見ると、物理スコープに関連するリスクを軽減する重要な方法は、コンポーネントのインスタンスをさまざまな物理スコープに分散することです。 冗長性が組み込まれた Azure サービスでは、冗長インスタンスをデプロイする次の 3 つの方法のうち 1 つ以上が提供される場合があります。
ローカル冗長性により、 インスタンスは 1 つの Azure データセンターの複数の部分に配置され、1 つのインスタンスに影響する可能性のあるハードウェア障害から保護されます。 通常、ローカル冗長性により、コストと待機時間が最も低くなります。 ただし、データセンターの障害は、すべてのインスタンスが使用できないことを意味する可能性があります。
ゾーンの冗長性により、 1 つの Azure リージョン内の複数の可用性ゾーンにインスタンスが分散されます。 ゾーン冗長性は、ハードウェア障害に加えて、データセンターの障害から保護します。
geo 冗長性により、 複数の Azure リージョンにインスタンスが配置され、大規模なリージョンの停止に対する保護が提供されます。 geo 冗長性はコストが高く、より広範なソリューション設計と、各リージョンのコンポーネントのインスタンスを切り替える方法を考慮する必要があります。 また、 同期レプリケーションと非同期レプリケーションで説明されている待機時間も考慮する必要があります。
Azure での冗長性のしくみ: コンピューティング サービス
冗長性は、Azure のほぼすべての部分で使用されます。 Azure で冗長性を実装する方法の例として、コンピューティング ワークロードを実行するサービスを検討してください。
Azure では、個々の仮想マシン (VM) は、Azure データセンター内の 1 つの物理ホスト上で実行されます。 リージョンや可用性ゾーンなど、想定した場所で VM が確実に実行されるようにする手順を Azure に提供できます。場合によっては、専用 のホストに配置することもできます。
仮想マシンの複数のインスタンスを実行するのが一般的です。 そのシナリオでは、個別に管理するか、 仮想マシン スケール セットを使用するかを選択できます。 スケール セットを使用する場合でも、それを支える個々の VM を確認できますが、スケール セットには冗長 VM の管理に役立つさまざまな機能が用意されています。 これらの機能には、リージョンまたは可用性ゾーン内の 障害ドメイン に分散するなど、指定したルールに基づいて VM を自動配置する機能が含まれます。
仮想マシンに依存してコンピューティング タスクを実行する Azure コンピューティング サービスは、他にも多数あります。 コンピューティング サービスには、通常、仮想マシンの分散方法を決定するさまざまな冗長性設定が用意されています。 たとえば、サービスによってゾーン冗長設定が提供される場合があります。この設定を使用すると、仮想マシンを可用性ゾーン間で自動的に分散し、負荷分散を構成できます。
レプリケーション: データの冗長性
冗長性は、状態 (データ) に適用される場合、レプリケーションと呼ばれます。 レプリケーションを使用すると、 レプリカと呼ばれるライブ データの複数のリアルタイムまたはほぼリアルタイムのコピーを保持できます。 リスクに対する回復性を向上させるために、レプリカをさまざまな場所に分散できます。 あるレプリカが使用できなくなった場合、システムは フェールオーバー して、別のレプリカがその機能を引き継ぐ可能性があります。
レプリケーションにはさまざまな種類があり、データの整合性、パフォーマンス、コストに関して優先順位が異なります。 各レプリケーションの種類は、ビジネス継続性の説明で使用される 2 つの主要なメトリックに影響します。 目標復旧時間 (RTO) (ディザスター シナリオで許容できるダウンタイムの最大量) と、障害シナリオで許容できる最大データ損失量である 目標復旧ポイント (RPO) です。 これらのメトリックとビジネス継続性との関係の詳細については、「 ビジネス継続性、高可用性、ディザスター リカバリーとは」を参照してください。
機能とパフォーマンスの要件を満たす上でレプリケーションが重要であるため、ほとんどのデータベース システムおよびその他のデータ ストレージ製品およびサービスには、緊密に統合された機能として何らかの種類のレプリケーションが含まれています。 提供されるレプリケーションの種類は、通常、アーキテクチャと、それらが使用される方法に基づいています。 Azure サービスでサポートされるレプリケーションの種類については、Azure サービスの信頼性ガイドを参照してください。
Von Bedeutung
レプリケーションはバックアップと同じではありません。 レプリケーションでは、複数のレプリカ間ですべての変更が同期され、データの古いコピーは保持されません。
データを誤って削除したとします。 削除操作は各レプリカにレプリケートされ、データはどこでも削除されます。 このような状況では、おそらくバックアップから削除されたデータを復元する必要があります。 バックアップについては、この記事の後半で説明します。
同期レプリケーションと非同期レプリケーション
データをレプリケートするときは、そのデータに対する変更をレプリカ間で同期する必要があります。 データが変更されたときに整合性を維持しようとすると、主な課題がいくつかあります。
Latency。 レプリカの更新には時間がかかり、レプリカが離れるほど、レプリカ間の距離を越えてデータを送信し、受信確認を受け取るまでにかかる時間が長くなります。
変更管理。 レプリカの同期中にデータが変更される可能性があるため、データの一貫性の管理が複雑になる可能性があります。
これらの課題に対処するために、データ変更をレプリケートしてデータの整合性を管理する主な方法は 2 つあります。
同期レプリケーション では、更新が完了したと見なされる前に、複数のレプリカで更新を実行する必要があります。 次の図は、同期レプリケーションのしくみを示しています。
この例では、次の一連の手順が実行されます。
- クライアントがデータを変更すると、要求がレプリカ 1 に送信され、要求が処理され、変更されたデータが格納されます。
- レプリカ 1 はレプリカ 2 に変更を送信します。レプリカ 2 は要求を処理し、変更されたデータを格納します。
- レプリカ 2 は、レプリカ 1 への変更を確認します。
- レプリカ 1 は、変更をクライアントに返します。
同期レプリケーションは一貫性を保証できます。つまり、RPO を 0 にサポートできます。 ただし、これはパフォーマンスの犠牲になります。 レプリカが地理的に離れ、走査する必要があるネットワーク ホップが多いほど、レプリケーション プロセスによってより多くの待機時間が発生します。
非同期レプリケーション はバックグラウンドで行われます。 次の図は、非同期レプリケーションのしくみを示しています。
この例では、次の一連の手順が実行されます。
- クライアントによってデータが変更され、要求がレプリカ 1 に送信されます。
- レプリカ 1 は要求を処理し、変更されたデータを格納し、変更をすぐに確認してクライアントに戻します。
- ある時点で、レプリカ 1 は変更をレプリカ 2 に同期します。
非同期レプリケーションはトランザクション フローの外部で行われるため、アプリケーションのパフォーマンスの制約としてレプリケーションが削除されます。 ただし、別のレプリカにフェールオーバーする必要がある場合は、最新のデータがない可能性があるため、RPO が 0 より大きい必要があります。 非同期レプリケーションでサポートできる正確な RPO は、レプリケーションの頻度によって異なります。
レプリカの役割
多くのレプリケーション システムでは、レプリカが異なる役割を果たすことができます。これにより、データの変更を調整し、競合の可能性を減らすことができます。 ロールには、 アクティブ と パッシブの 2 種類があります。 これらのロールを使用してレプリカを分散する一般的な方法は 2 つあります。
アクティブ/パッシブ レプリケーションとは、信頼できるソースとして機能する 1 つの アクティブ レプリカがあることを意味します。 データに加えられた変更は、そのレプリカに適用する必要があります。 その他のレプリカは パッシブ ロールで動作します。つまり、アクティブ レプリカからデータの更新を受け取りますが、クライアントから直接変更を処理することはありません。 パッシブ レプリカは、 フェールオーバー が発生し、レプリカのロールが変更されない限り、ライブ トラフィックには使用されません。 次の図は、1 つのパッシブ レプリカを持つアクティブ/パッシブ システムを示しています。
アクティブ/パッシブ システムでは、フェールオーバーにかかる時間の長さが RTO を決定します。 一般に、アクティブ/パッシブ システムの RTO は数分で測定されます。
一部のレプリケーション ソリューションでは 読み取り専用レプリカもサポートされています。これにより、パッシブ レプリカからデータを読み取る (書き込まない) ことが可能になります。 この方法は、アプリケーションのトランザクション処理に使用しているプライマリ レプリカに影響を与えずに分析やデータのレポートを実行する必要がある場合など、レプリカからより多くの使用率を得るために役立ちます。 いくつかの Azure サービスでは、読み取りアクセス付き GRS (RA-GRS) レプリケーションの種類を持つ Azure Storage、Azure SQL Database のアクティブジオレプリケーションなど、読み取り専用レプリカが対応しています。
アクティブ/アクティブ レプリケーションでは、ライブ トラフィックに対して複数のアクティブ レプリカを同時に使用でき、どのレプリカでも要求を処理できます。
アクティブ/アクティブ レプリケーションでは、システムがすべてのレプリカでリソースを使用できるため、高レベルのパフォーマンスが実現します。 アクティブ/アクティブ レプリケーションでは、状況によっては 0 の RTO をサポートできます。 ただし、複数のレプリカで同時に競合する変更を非同期的に調整する必要があるため、これらの利点はデータの整合性を複雑にする必要があります。
複雑なデータ サービスでは、アクティブ/アクティブレプリケーションとアクティブ/パッシブ レプリケーションの両方を組み合わせることができます。 たとえば、1 つのレプリカ セットを 1 つの Azure リージョンに、もう 1 つのレプリカセットを別のリージョンにデプロイできます。 各リージョン内では、1 つのアクティブ レプリカが要求を処理し、1 つ以上のパッシブ レプリカがフェールオーバーのためにスタンバイします。 一方、両方のリージョンはアクティブ/アクティブ モデルで動作し、トラフィックをそれらの間で分散できます。
Azure データ サービスでのレプリケーションのしくみ
データを格納する各 Azure サービスには、何らかの形式のレプリケーションが用意されています。 ただし、各サービスでは、サービスのアーキテクチャと意図された用途に固有の異なるアプローチが使用される場合があります。
たとえば、Azure Storage では、一連の機能を使用して同期レプリケーションと非同期レプリケーションの両方を提供できます。
- データの複数のコピーは、プライマリ リージョン内で同期的にレプリケートされます。 レプリカをローカル冗長ストレージ (LRS) 内の 1 つのデータセンター内の異なる物理ハードウェアに配置するか、ゾーン冗長ストレージ (ZRS) の複数の可用性ゾーンに分散するかを選択できます。
- プライマリ リージョンがペアになっている場合、geo 冗長ストレージ (GRS) を有効にすると、データもペアになっているリージョンにレプリケートされます。 ペアになっているリージョンは地理的に離れているため、このレプリケーションは非同期的に実行され、アプリケーションのスループットへの影響を軽減します。
- geoゾーン冗長ストレージ層 (GZRS) を使用することで、ゾーン冗長ストレージとgeo冗長ストレージを同時に利用する選択が可能です。 リージョン内のデータは同期的にレプリケートされ、リージョン間のデータは非同期的にレプリケートされます。
詳細については、「Azure Storage の冗長性」を参照してください。
もう 1 つの例は、レプリケーションも提供する Azure Cosmos DB です。 すべての Azure Cosmos DB データベースには複数のレプリカがあります。 レプリカをグローバルに分散すると、複数リージョンの書き込みがサポートされます。クライアントは、使用する任意のリージョンのレプリカに書き込むことができます。 これらの書き込み操作は、リージョン内で同期的にレプリケートされた後、他のリージョン間で非同期的にレプリケートされます。 Azure Cosmos DB では、異なるレプリカ間で書き込みの競合が発生した場合に備えて、競合解決メカニズムが提供されます。 詳細については、 Azure Cosmos DB を使用したグローバル データ分散に関するページを参照してください。
仮想マシンを使用する場合は、 Azure Site Recovery を使用して、可用性ゾーン間または別の Azure リージョンに仮想マシンとそのディスクをレプリケートできます。
Azure ソリューションを設計する場合は、 各サービスの信頼性ガイド を参照して、そのサービスがさまざまな場所を含む冗長性とレプリケーションを提供する方法を理解してください。
バックアップ
バックアップでは、特定の時点でデータのコピーが取得されます。 問題が発生した場合は、後でバックアップを 復元 できます。 ただし、バックアップの作成後に発生したデータに対する変更はバックアップに含まれず、失われる可能性があります。
バックアップを使用すると、Microsoft Azure クラウド内または Microsoft Azure クラウドにデータをバックアップおよび回復するためのソリューションを提供できます。 バックアップでは、次のようなさまざまなリスクから保護できます。
- ハードウェアまたはその他のインフラストラクチャの致命的な損失。
- データの破損と削除。
- ランサムウェアなどのサイバー攻撃。
Von Bedeutung
バックアップと復元のプロセスを他の復旧手順と共に定期的にテストして検証することが重要です。 テストにより、バックアップが包括的でエラーなく、プロセスによって正しく復元されることが保証されます。 テストは、チームが従うプロセスを確実に理解するためにも重要です。 詳細については、「 テストと訓練」を参照してください。
バックアップが要件に与える影響
ディザスター リカバリー戦略の一部として使用する場合、バックアップでは通常、数時間で測定される RTO と RPO がサポートされます。
RTO は、バックアップの復元や復元が正常に完了したことを検証するなど、復旧プロセスの開始と完了にかかる時間の影響を受けます。 バックアップのサイズと、読み取る必要があるバックアップ ファイルの数によっては、バックアップを完全に復元するのに数時間以上かかるのが一般的です。
RPO は、バックアップ プロセスの頻度の影響を受けます。 バックアップを頻繁に実行する場合は、バックアップから復元する必要がある場合に失われるデータが少なくなります。 ただし、バックアップにはストレージが必要であり、場合によっては、バックアップの実行中にサービスのパフォーマンスに影響する可能性があります。 このため、バックアップの頻度を考慮し、組織の要件に適したバランスを見つける必要があります。 バックアップ頻度は、ビジネス継続性の計画で考慮する必要があります。
一部のバックアップ システムでは、保持期間が異なる複数のバックアップ層や、保存と消費が少ないストレージをより高速に行う差分バックアップまたは増分バックアップなど、より複雑なバックアップ要件がサポートされています。
Azure サービスでのバックアップ
多くの Azure サービスでは、データのバックアップ機能が提供されています。
Azure Backup は、仮想マシン、Azure Storage、Azure Kubernetes Service (AKS) など、いくつかの主要な Azure サービス用の専用バックアップ ソリューションです。
また、多くのマネージド データベースでは、次のような独自のバックアップ機能がサービスの一部として提供されています。
- Azure SQL Database では、自動バックアップが提供されます。
- Azure Cosmos DB には、継続的バックアップ機能と定期的バックアップ機能の両方が用意されています。
- Azure Key Vault を使用すると、コンテナー内のデータのバックアップをダウンロードできます。
- Azure App Service では、Web アプリケーションの自動バックアップとカスタム バックアップの両方が提供され、データベースをバックアップすることもできます。
バックアップとレプリケーション
バックアップとレプリケーションはそれぞれ異なるリスクから保護され、2 つのアプローチは相互に補完的です。
レプリケーションは日々の回復性をサポートし、一般的に高可用性戦略で使用されます。 一部のレプリケーションアプローチでは、ダウンタイムやデータ損失はほとんど必要なく、低い RTO と RPO をサポートします。 ただし、レプリケーションでは、データの損失や破損につながるリスクから保護されません。
対照的に、バックアップは、多くの場合、致命的なリスクに対する最後の防御線です。 多くの場合、バックアップには比較的高い RTO と RPO が必要ですが、バックアップの構成方法は高さに影響します。 バックアップからの合計復元は、多くの場合、ディザスター リカバリー計画の一部です。
冗長性のためのコンポーネントの準備
アーキテクチャの一部として冗長性を使用するシステムを設計するときは、次の方法も考慮することが重要です。
- 一貫性のためにリソース構成を複製します。
- インスタンス障害時には、余裕を持ったプロビジョニングで容量を管理します。
重複するリソース構成
クラウド環境では、各リソースの構成が重要です。 たとえば、ネットワーク ロード バランサーを作成するときは、その動作に影響するさまざまな設定を構成します。Azure Functions を使用して関数をデプロイする場合は、セキュリティ、パフォーマンス、アプリケーションの構成設定に関連する設定を構成します。 Azure 内のすべてのリソースには、その動作を促進する何らかの構成があります。
さまざまな場所でリソースの冗長コピーを管理する場合は、それらの構成を制御することが重要です。 リソースが同じように動作するように、多くの設定を各コピーで同じ方法で設定する必要があります。 ただし、特定のリージョンの仮想ネットワークへの参照など、一部の設定はコピーごとに異なる場合があります。
リソースの一貫性を維持するための一般的なアプローチは、Bicep や Terraform などのコードとしてのインフラストラクチャ (IaC) を使用することです。 これらのツールを使用すると、リソースを定義するファイルを作成でき、リソースのインスタンスごとにそれらの定義を再利用できます。 IaC を使用すると、回復性のためにリソースの複数のインスタンスを作成および管理する負担を軽減でき、その他にも多くの利点があります。 詳細については、「 コードとしてのインフラストラクチャ (IaC)とは」 および「 コードとしてインフラストラクチャを使用するための推奨事項」を参照してください。
過剰プロビジョニングで容量を管理する
インスタンスが失敗した場合、システムの全体的な容量が、正常な操作中に必要な容量と異なる場合があります。 たとえば、通常、受信 Web トラフィックを処理する Web サーバーのインスタンスが 6 つあり、それらのインスタンスがリージョン内の 3 つの Azure 可用性ゾーンに均等に分散されているとします。
可用性ゾーンで障害が発生した場合、一時的に 2 つのインスタンスが失われ、Web サーバー インスタンスが 4 つだけ残される可能性があります。 通常、アプリケーションがビジー状態で、6 つのインスタンスすべてが通常のトラフィックに対応する必要がある場合は、容量を減らして実行すると、ソリューションのパフォーマンスに影響する可能性があります。
障害に備えるために、サービスの容量を 過剰にプロビジョニング できます。 オーバープロビジョニングにより、ソリューションは、ある程度の容量損失を許容でき、パフォーマンスが低下することなく引き続き機能できます。
1 つの可用性ゾーンの障害を考慮して Web サーバーのインスタンスを過剰プロビジョニングするには、次の手順に従います。
- ピーク時のワークロードに必要なインスタンスの数を決定します。
- ピーク時のワークロード インスタンス数に係数 [(ゾーン数/(ゾーン数-1)] を乗算して、オーバープロビジョニングするインスタンスを取得します。
- 結果を最も近い整数に切り上げる。
注
次の表は、3 つの可用性ゾーンを使用しており、それらのゾーンの 1 つの容量の損失を考慮することを前提としています。 要件が異なる場合は、それに応じて数式を調整します。
| ピーク時のワークロード インスタンス数 | 係数 [(ゾーン数/(ゾーン数-1)] | 式 | プロビジョニングするインスタンス (丸め) |
|---|---|---|---|
| 3 | 3/2 または 1.5 | (3 x 1.5 = 4.5) | 5 個のインスタンス |
| 4 | 3/2 または 1.5 | (4 x 1.5 = 6) | 6 インスタンス |
| 5 | 3/2 または 1.5 | (5 x 1.5 = 7.5) | 8 個のインスタンス |
| 6 | 3/2 または 1.5 | (6 x 1.5 = 9) | 9 個の例 |
| 7 | 3/2 または 1.5 | (7 x 1.5 = 10.5) | 11 事例 |
| 8 | 3/2 または 1.5 | (8 x 1.5 = 12) | 12 個のインスタンス |
| 9 | 3/2 または 1.5 | (9 x 1.5 = 13.5) | 14 個のインスタンス |
| 10 | 3/2 または 1.5 | (10 x 1.5 = 15) | 15 個のインスタンス |
前の例では、ピーク時のワークロードには Web サーバーのインスタンスが 6 つ必要であるため、オーバープロビジョニングには合計 9 つのインスタンスが必要です。
次のステップ
フェールオーバーとフェールバックについて説明します。