冗長性のための設計に関する推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:05 | 異なるレベルで冗長性を追加します (特に、重要なフローの場合)。 特定された信頼性目標に従って、コンピューティング、データ、ネットワーク、その他のインフラストラクチャ層に冗長性を適用します。 |
|---|
関連ガイド: 高可用性マルチリージョン設計 | 可用性ゾーンとリージョンの使用
このガイドでは、回復性を最適化するさまざまなワークロード レイヤーで重要なフロー全体に冗長性を追加するための推奨事項について説明します。 コンピューティング、データ、ネットワーク、その他のインフラストラクチャ層に適切なレベルの冗長性を適用することで、定義済みの信頼性の目標の要件を満たします。 この冗長性を適用して、ワークロードを構築するための強力で信頼性の高い基盤を提供します。 インフラストラクチャの冗長性なしでワークロードを構築すると、潜在的な障害によるダウンタイムが長引くリスクが高くなります。
定義
| 相談 | 定義 |
|---|---|
| 冗長性 | ワークロード コンポーネントの同一のインスタンスを複数実装すること。 |
| ポリグロットな永続化 | 同じアプリケーションまたはソリューションで異なるストレージ テクノロジを使用して、各コンポーネントの最適な機能を活用するという概念。 |
| データの整合性 | 特定のデータセットが複数のストア間でどのように同期済みか、または非同期かを示す測定値。 |
| パーティション分割 | データを個別のデータ ストアに物理的に分割するプロセス。 |
| シャード | 共通スキーマを持つ複数のストレージ インスタンスをサポートする水平方向のデータベース パーティション分割戦略。 すべてのインスタンスでデータがレプリケートされるわけではありません。 |
主要な設計戦略
信頼性の観点から、冗長性を使用して、1 つのリソースに影響する問題を封じ込め、それらの問題がシステム全体の信頼性に影響しないようにします。 重要なフローと信頼性の目標について特定した情報を使用して、各フローの冗長性に必要な情報に基づいた上で決断を下します。
たとえば、複数の Web サーバー ノードが一度に実行されている場合があります。 それらがサポートするフローの重要性によっては、地域的な停電のような、プール全体に影響する問題が発生した場合にトラフィックを受け入れる準備ができているレプリカがすべてのノードに必要になる場合があります。 または、大規模な問題はまれであり、レプリカのセット全体をデプロイするとコストがかかるため、少数のレプリカをデプロイして、問題を解決するまでフローが低下状態で動作するようにすることもできます。
パフォーマンス効率の観点から冗長性を設計する場合は、各ノードが最適に実行されるように、負荷を複数の冗長ノードに分散します。 信頼性の観点では、1 つ以上のノードに影響を与える障害や誤動作を吸収するために予備容量を組み込みます。 予備容量が、影響を受けるノードを回復するために必要な期間、障害を吸収できるようにします。 この違いを念頭に置いて、両方の戦略を連携させる必要があります。 パフォーマンスのために 2 つのノード間でトラフィックを分散し、両方とも 60% の使用率で実行され、1 つのノードが失敗した場合、残りのノードは 120% で動作できないため、過剰な負荷が発生するリスクがあります。 負荷を別のノードに分散して、パフォーマンスと信頼性の目標が確実に維持されるようにします。
トレードオフ:
- ワークロードの冗長性が高まるにつれて、コストもかかります。 冗長性の追加は、慎重に検討し、アーキテクチャを定期的に確認して、コストを管理していることを確認してください (特にオーバープロビジョニングを使用する場合)。 回復性戦略としてオーバープロビジョニングを使用する場合は、コストの非効率性を最小限に抑えるために適切に定義されたスケーリング戦略を使ってバランスを取ります。
- 高度な冗長性を構築する場合、パフォーマンスのトレードオフが発生する可能性があります。 たとえば、可用性ゾーンまたはリージョンに分散されているリソースは、Web サーバーやデータベース インスタンスなどの冗長リソース間の待機時間の長い接続経由でトラフィックを送信する必要があるため、パフォーマンスに影響を与える可能性があります。
- 同じワークロード内でもフローが異なると、信頼性要件が異なる場合があります。 フロー固有の冗長性設計では、設計全体が複雑になる場合があります。
冗長アーキテクチャの設計
冗長アーキテクチャを設計する場合は、アクティブ - アクティブとアクティブ - パッシブの 2 つのアプローチを検討してください。 インフラストラクチャ コンポーネントがサポートするユーザー フローとシステム フローの重要度に応じて、アプローチを選択します。 信頼性の面では、マルチリージョンのアクティブ - アクティブ設計は、可能な限り最高レベルの信頼性を実現するのに役立ちますが、アクティブ - パッシブ設計よりも大幅にコストがかかります。 適切な地理的リージョンを決定することが、次に重要な選択肢になります。 可用性ゾーンを使用して、1 つのリージョンに対してこれらの設計アプローチを使用することもできます。 詳細については、「高可用性マルチリージョン設計に関する推奨事項」を参照してください。
デプロイ スタンプとスケール単位
アクティブ - アクティブまたはアクティブ - パッシブのどちらのモデルでデプロイする場合でも、デプロイ スタンプの設計パターンに従って反復可能でスケーラブルな方法でワークロードをデプロイします。 デプロイ スタンプは、顧客の特定のサブセットにワークロードを配布するために必要なリソースのグループです。 たとえば、サブセットとして、地域的なサブセットや、お使いのワークロードと同じデータ プライバシー要件を持つサブセットなどが考えられます。 各スタンプを、ワークロードを水平方向にスケーリングしたり、ブルーグリーンデプロイを実行したりするために複製できる "スケールのユニット" と考えてください。 デプロイ スタンプを使用してワークロードを設計し、回復性と管理の負担に合わせてアクティブ - アクティブまたはアクティブ - パッシブの実装を最適化します。 複数リージョンのスケールアウトの計画は、リージョン内の潜在的な一時リソース容量の制約を克服するためにも重要です。
Azure リージョン内の可用性ゾーン
アクティブ - アクティブまたはアクティブ - パッシブのどちらの設計をデプロイする場合でも、アクティブ リージョン内の可用性ゾーンを利用して、回復性を完全に最適化します。 多くの Azure リージョンには、リージョン内のデータセンターの分離されたグループである複数の可用性ゾーンが用意されています。 Azure サービスに応じて、ワークロードの要素をゾーン間で冗長にデプロイするか、特定のゾーンに要素をピン留めして、可用性ゾーンを利用できます。 詳細については、「可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。
コンピューティング リソースのゾーン冗長性を実装する
ワークロードに適したコンピューティング サービスを選択します。 設計するワークロードの種類によっては、いくつかのオプションが使用できる場合があります。 使用可能なサービスを調べて、特定のコンピューティング サービスで最適に動作するワークロードの種類を理解します。 たとえば、SAP ワークロードは通常、サービスとしてのインフラストラクチャ (IaaS) コンピューティング サービスに最適です。 コンテナ化されたアプリケーションの場合は、Azure Kubernetes Service (AKS) ソリューションとサービスとしてのプラットフォーム (PaaS) ソリューションのどちらを使用するかを決定するために制御する必要がある特定の機能を決定します。 クラウド プラットフォームは PaaS サービスを完全に管理します。
要件で許可されている場合は、PaaS コンピューティング オプションを使用します。 Azure は、PaaS サービスを完全に管理し、これにより、管理の負担が軽減されます。また、文書化されている冗長性が組み込まれています。
仮想マシン (VM) をデプロイする必要がある場合は、Azure Virtual Machine Scale Sets を使用します。 Virtual Machine Scale Sets を使用すると、コンピューティングを可用性ゾーン間で自動的に均等に分散できます。
要求を処理する個々のノードは、いつでも削除または置換されたり、障害が発生したりする可能性があるため、コンピューティング層は "クリーンな状態" を保ってください。
可能な限りゾーン冗長サービスを使用すると、運用上の負担を増やさずに、より高い回復性が提供されます。
自動スケーリング操作が開始される前であっても、重要なリソースをオーバープロビジョニングして冗長インスタンスの障害を軽減し、コンポーネントに障害が発生した後もシステムが動作を継続できるようにします。 冗長性設計にオーバープロビジョニングを組み込む場合の、障害の許容される影響を計算します。 冗長性の意思決定プロセスと同様に、信頼性目標と財務トレードオフの決定によって、オーバープロビジョニングで予備容量を追加する範囲が決まります。 オーバープロビジョニングとは、特に "スケール アウト" を意味します。つまり、あらゆる単一のインスタンスのコンピューティング機能を増やすのではなく、特定のコンピューティング リソースの種類のインスタンスを追加するということです。 たとえば、VM を下位レベルの SKU から上位レベルの SKU に変更する場合などです。
ソリューションを実装する予定の各可用性ゾーンまたはリージョンで、IaaS サービスを手動で、または自動化を使用してデプロイします。 一部の PaaS サービスには、可用性ゾーンとリージョン間で自動的にレプリケートされる組み込み機能があります。
データ リソースのゾーン冗長を実装する
お使いのワークロードの機能に同期または非同期データ レプリケーションが必要かどうかを判断します。 この決定に役立つ情報については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。
データの増加率を考慮します。 容量計画の場合は、データの増加、データ保持、アーカイブを計画して、ソリューション内のデータ量が増加した場合に信頼性要件が満たされるようにします。
地理的に局所的な障害の影響を最小化するために、サービスのサポートに従ってデータを地理的に分散させます。
リージョンの停止や致命的な障害に対する回復性を提供するために、地理的リージョン間でデータをレプリケートします。
データベース インスタンスの障害後にフェールオーバーを自動化します。 複数の Azure PaaS データ サービスで自動フェールオーバーを構成できます。 Azure Cosmos DB などのマルチリージョンの書き込みをサポートするデータ ストアでは、自動フェールオーバーは必要ありません。 詳細については、「ディザスター リカバリー戦略を設計するための推奨事項」を参照してください。
データに最適なデータ ストアを使用します。 ポリグロットな永続化、つまりさまざまなデータ ストア テクノロジを組み合わせて使用するソリューションを使用しましょう。 データには、永続化されたアプリケーション データ以外のものも含まれます。 アプリケーション ログ、イベント、メッセージ、およびキャッシュも含まれています。
データ整合性の要件を考慮し、要件で許可されている場合は最終的な整合性を使用します。 データが分散している場合は、適切な調整を使用して厳密な整合性保証を強制します。 調整によってスループットが低下し、システムが密に結合され、システムがより脆弱になるおそれがあります。 たとえば、1 つの操作で 2 つのデータベースを更新する場合、1 つのトランザクション スコープに配置するのではなく、システムが最終的な整合性に対応できる方が適しています。
可用性のためにデータをパーティション分割します。 データベースのパーティション分割によりスケーラビリティが向上し、可用性も向上します。 あるシャードがダウンしても、それ以外のシャードには引き続きアクセスできます。 あるシャードで発生した障害によって中断されるのは、トランザクション全体のサブセットのみです。
シャーディングがオプションでない場合は、コマンド クエリ責務分離 (CQRS) パターンを使用して読み取り/書き込みデータ モデルと読み取り専用データ モデルを分離できます。 より多くの回復性を提供するために、冗長な読み取り専用データベース インスタンスをさらに追加します。
使用するステートフル プラットフォーム サービスの組み込みのレプリケーションと冗長機能について理解します。 ステートフル データ サービスの具体的な冗長機能については、関連リンクを参照してください。
ネットワーク リソースのゾーン冗長を実装する
信頼性が高くスケーラブルなネットワーク トポロジを決定します。 ハブアンドスポーク モデルまたは Azure Virtual WAN モデルを使用して、クラウド インフラストラクチャを論理的なパターンで整理すると、冗長設計の構築と拡張が容易になります。
適切なネットワーク サービスを選択してリージョン内またはリージョン間で要求のバランスを取り、リダイレクトします。 信頼性目標を達成するために、可能な場合はグローバルまたはゾーン冗長の負荷分散サービスを使用します。
スケールアウト要件を含め、計画的な使用を考慮するために、仮想ネットワークとサブネットに十分な IP アドレス空間が割り当てられていることを確認します。
選択したアプリケーション ホスティング プラットフォームのポート制限内で、アプリケーションをスケーリングできることを確認します。 アプリケーションが複数の送信 TCP または UDP 接続を開始すると、使用可能なすべてのポートが使い果たされ、アプリケーションのパフォーマンスが低下する場合があります。
SKU を選択し、帯域幅と可用性の要件を満たすことができるネットワーク サービスを構成します。 VPN ゲートウェイのスループットは、SKU によって異なります。 ゾーン冗長のサポートは、一部のロード バランサー SKU でのみ使用できます。
DNS を処理するための設計が回復性に重点を置いて構築され、冗長インフラストラクチャをサポートしていることを確認します。
Azure ファシリテーション
Azure プラットフォームは、ワークロードの回復性を最適化し、次の方法で冗長性を追加するのに役立ちます。
一部が構成可能である多くの PaaS およびサービスとしてのソフトウェア (SaaS) ソリューションで、組み込みの冗長性を提供する。
可用性ゾーンとリージョン間の冗長性を使用して、リージョン内の冗長性の設計および実装を可能にする。
Azure Application Gateway、Azure Front Door、Azure Load Balancer などのレプリカ対応負荷分散サービスを提供する。
Azure SQL Database のアクティブ geo レプリケーションなどの簡単に導入できる geo レプリケーション ソリューションを提供する。 Azure Cosmos DB を使用してグローバル分散と透過的なレプリケーションを実装します。 Azure Cosmos DB には、競合する書き込みを処理するための 2 つのオプションがあります。 ワークロードに最適なオプションを選択してください。
多くの PaaS データ サービスにポイントインタイム リストア機能を提供する。
Azure NAT Gateway または Azure Firewall を使用してポート不足を軽減する。
DNS 固有の Azure ファシリテーション
内部の名前解決シナリオでは、ゾーン冗長と geo 冗長性が組み込まれている Azure DNS Private Zones を使用します。 詳細については、「Azure DNS プライベート ゾーンの回復性」を参照してください。
外部の名前解決シナリオでは、ゾーン冗長と geo 冗長性が組み込まれている Azure DNS パブリック ゾーンを使用します。
パブリックおよびプライベートの Azure DNS サービスはグローバル サービスであり、ゾーン データはグローバルに利用できるため、リージョンの障害に対して回復性があります。
オンプレミスおよびクラウド環境間のハイブリッド名前解決シナリオでは、Azure DNS Private Resolver を使用します。 ワークロードが可用性ゾーンをサポートするリージョンにある場合、このサービスはゾーン冗長をサポートします。 ゾーン全体が停止した場合、ゾーンの復旧中に操作は必要ありません。 サービスは自動的に自己修復と再調整を行って、正常なゾーンを利用します。 詳細については、「Azure DNS Private Resolver の回復性」を参照してください。
単一障害点を排除し、リージョン間でより回復性の高いハイブリッド名前解決を実現するには、複数の Azure DNS プライベート リゾルバーを異なるリージョンにデプロイします。 条件付き転送シナリオでは、DNS フェールオーバーは、リゾルバーをプライマリ DNS サーバーとして割り当てることで実現されます。 別のリージョンの他のリゾルバーをセカンダリ DNS サーバーとして割り当てます。 詳細については、「プライベート リゾルバーを使用して DNS フェールオーバーを設定する」を参照してください。
例
複数リージョンの冗長デプロイの例については、「ベースラインの高可用性ゾーン冗長 Web アプリケーション」を参照してください。
次の図に別の例を示します。
関連リンク
冗長性の詳細については、次のリソースを参照してください。
- Azure リージョン ガイド
- Azure Storage の冗長性
- ゾーン冗長ストレージ
- Azure SQL Database のアクティブ geo レプリケーション
- 2 つのマネージド インスタンス間でのレプリケーションの構成
信頼性チェックリスト
レコメンデーションの完全なセットを参照してください。