演習 - 設計を複数のリージョンに拡張する
Contoso Shoes には、リージョンの停止に耐えられる方法が必要です。 現在のスタンプをアクティブ/アクティブ、共有状態、およびマルチリージョンのトポロジにデプロイしたいと考えています。 リージョンで障害が発生した場合に備えて、トラフィックを別のリージョンにリダイレクトするようにアーキテクチャを設計する必要があります。
現在の状態と問題
アプリケーションには 1 つのリージョンで十分です。 しかし、エンド ユーザーの観点からすると、ネットワークに影響を与えた最近のリージョンの停止は、システムにオフラインを引き起す問題となりました。 リージョン内で水平方向にスケーリングしたり、そのリージョンに新しいスタンプをデプロイしたりしても、失敗した状態からアプリケーションは回復されませんでした。
DNS は既存の api.contososhoes.com のレジストラーによって保持されます。 DNS レコードは、存続期間 (TTL) が 2 日に設定されたバックエンド App Services エンドポイント (apicontososhoes.azurewebsites.net) に解決されます。 ソリューションが複数のリージョンにデプロイされている場合は、DNS を移行する必要があります。
仕様
- アクティブ/アクティブ、マルチリージョン トポロジで動作するようにアーキテクチャを拡張します。
- 2 つのリージョン間でハードコーディングされたリソースの一覧ではなく、必要に応じてリージョンを動的に追加および削除できるように、デプロイ スタンプ モデルを変更します。
- 1 つのリージョンで障害が発生した場合に、障害が発生していないリージョンに既に存在するクライアントに顕著な影響を与えることなく、トラフィックを障害のないリージョンにルーティングする必要があります。
- クライアントをリージョンにピン留めしないでください。
- クライアントは、API とやり取りするために URL を変更する必要はありません。 DNS はグローバル ルーターに移行する必要があります。
推奨される方法
設計を開始するにあたり、次の手順に従うことをお勧めします。
1 – マルチリージョン トポロジ
リージョンの障害から保護するには、アーキテクチャを 2 つ以上の Azure リージョンに配布する必要があります。 リージョンを選択する場合は、次の要素を考慮してください。
- リージョンは、そのリージョンでのデータ センターの停止に耐えられる必要があります。
- アーキテクチャで使用される Azure サービスと機能は、リージョンでサポートされている必要があります。
- ネットワークの待ち時間を最小限に抑えるには、リージョンとリージョンにデプロイされたリソースが、エンド ユーザーと依存システムに近接している必要があります。
障害のシナリオを考えてみましょう。 リージョン 1 がトラフィックの 75% を使用し、追加したリージョン 2 が残りを使用するとします。 両方とも、その負荷を処理するために適切にスケーリングされています。 リージョン 1 でリージョンの障害が発生し、すべてのトラフィックがリージョン 2 にルーティングされるようになります。 その切り替えをスムーズにすることはできますか。 リージョン 2 では、増加したトラフィックの負荷をサポートできますか。
進捗状況を確認する: グローバル分散
2 – グローバル ルーティング
クライアントがいずれかの作業リージョンに透過的にルーティングされるようにするために、グローバル ロード バランサーを追加します。 前の演習で追加した正常性チェックは、スタンプが正常かどうかを判断するためにロード バランサーによって使用される必要があります。 バックエンドに到達せずに実行できる頻繁かつ類似した要求を処理する方法はあるでしょうか。
- 既存のアーキテクチャと統合され、迅速にフェールオーバーできるネイティブ Azure サービスを選択します。
- ネットワーク イングレス パスで、承認されていないトラフィックを拒否するように設定されていることを確認します。
- エッジ キャッシュからエンド ユーザーにサービスを提供することで、ネットワーク待機時間を最小限に抑えます。
- 既存のクライアントに影響を与えずに既存の DNS を移行します。
- リージョンの障害を示す方法を自動化し、障害が発生したリージョンにトラフィックがルーティングされないようにします。 また、リージョンが再び使用可能になったときに通知を受け取り、ロード バランサーがそのリージョンへのルーティングを再開できるようにします。
進行状況を確認する: グローバル トラフィック ルーティング
3 – デプロイ スタンプの変更
理想的な状態は、手動フェールオーバーを必要としないアクティブ/アクティブ構成で、クライアント要求を任意のリージョンから提供できる状態です。 それがアーキテクチャにとって何を意味するかを考えてください。 たとえば、リージョン スタンプに格納される状態はありますか。
現在のアーキテクチャの特定のサービスには、geo レプリケーション機能があります。 サービスを異なるスタンプに分離することを検討してください。 1 つはグローバル リソースを含むスタンプです。 もう 1 つは、リソースをグローバル スタンプと共有するリージョン スタンプです。 これらを決定する要因の 1 つは、これらのリソースのライフサイクルです。 アーキテクチャの他のリソースと比較して、リソースの予想される有効期間はどれくらいですか。 リソースの有効期間をシステムまたはリージョン全体よりも長くするか、共有する必要はありますか。または一時的にする必要がありますか?
アーキテクチャで使用される Azure サービスの信頼性機能について説明します。 これらの機能から始めて、さらに詳しく調べて信頼性を最大限に高めることができます。
| Azure サービス | 機能 |
|---|---|
| Azure Cosmos DB | マルチリージョン書き込み |
| Azure Container Registry | geo レプリケーション |
| Azure App Service プラン | 可用性ゾーンのサポート |
進行状況を確認する: アプリケーション プラットフォーム | データ プラットフォーム
作業を確認
同様のアーキテクチャのアプリケーションとデータに関する設計のオプションを次に示します。 あなたの設計では、以下の要素すべてが考慮されているでしょうか。
- マルチリージョン トポロジに対してどんな他の Azure リージョンを選択しましたか。その理由は何ですか。
- データセンターの停止から保護するために、各 Azure リージョンで 2 つ以上の Azure Availability Zones を有効にしましたか。
- イングレス トラフィックを制御するための Web Application Firewall を含めましたか。 どのようなルーティング規則を設定しましたか。その理由は何ですか。
- ロード バランサーは既存の DNS レコードをどのようにサポートしていますか。
- 前の演習の正常性チェック API をどのように使用しましたか。
- DDoS 攻撃からアプリケーションを保護していますか。特に、悪意のあるクライアントがロード バランサーをバイパスしてリージョン インスタンスに到達できないようにしていますか。
- DNS 移行はどのようにアプローチしましたか。
- マルチリージョン トポロジをサポートするために、既存のコンポーネントに SKU を変更しましたか。
- どの Azure サービスをシングルトンとして残しましたか。 各サービスの選択が正当であったことを証明しましたか。 構成を変更しましたか。
- リソースをログに記録していますか。 これは、システム全体のログを検査する機能に影響を与えると思いますか。