Azure Traffic Manager は、グローバルに分散されたバックエンド間でトラフィックを最適に分散する DNS ベースのトラフィック ロード バランサーです。 Traffic Manager は、DNS を使用して、トラフィック ルーティング方法とエンドポイントの正常性監視に基づいてクライアント要求を適切なサービス エンドポイントに転送することで、公開アプリケーションの高可用性と迅速な応答性を提供します。
Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害やリージョン全体の障害など、さまざまな潜在的な障害に対応するAzure Traffic Managerの信頼性機能について説明します。 また、回復性を維持し、復旧の準備を行う際の重要な考慮事項と、Azure Traffic Managerサービス レベル アグリーメント (SLA) の概要についても説明します。
Note
この記事では、Traffic Manager サービスの回復性、またはさまざまな問題に対する回復性を高める方法について説明します。 Traffic Manager を使用してアプリケーションまたはリージョン間のフェールオーバーを実行する方法については説明しません。 フェールオーバー アーキテクチャの例については、 高可用性とディザスター リカバリー用に構築された多層 Web アプリケーションに関するページを参照してください。
運用環境のデプロイに関する推奨事項
Azure Well-Architected Framework には、信頼性、パフォーマンス、セキュリティ、コスト、運用に関する推奨事項が用意されています。 これらの領域が相互にどのように影響し、信頼性の高い Traffic Manager ソリューションに貢献するかについては、Well-Architected Framework のAzure Traffic Managerに関する
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
Traffic Manager を使用する場合は、アプリケーションのバックエンド エンドポイントを指定し、Traffic Manager がそれらのエンドポイントに要求をルーティングする方法を構成する プロファイルをデプロイします。 詳細については、「 Traffic Manager エンドポイント と Traffic Manager ルーティング方法」を参照してください。
Traffic Manager プロファイルは、DNS CNAME レコードとして表示されます。 クライアントまたは DNS リゾルバーから解決要求を受信すると、Traffic Manager はプロファイルで指定した規則に基づいて IP アドレスを動的に解決します。 Traffic Manager の責任は、サービスに到達するためのエンドポイントの IP アドレスをクライアントに提供することです。 名前解決後、アプリケーションのトラフィックは Traffic Manager を通過しません。 詳細については、「 Traffic Manager のしくみ」を参照してください。
Traffic Manager は、エンドポイントの正常性を監視し、異常なエンドポイントを回避しながら、受信要求を正常なエンドポイントにルーティングします。 詳細については、「 Traffic Manager エンドポイントの監視」を参照してください。
Important
ソリューション全体の信頼性は、Traffic Manager がトラフィックをルーティングするエンドポイントの構成によって異なります。
この記事ではエンドポイントについては説明しませんが、それらの可用性構成はアプリケーションの回復性に直接影響します。 ソリューション内の Azure サービスの信頼性ガイド を確認して、各サービスが信頼性要件をどのようにサポートしているかを確認します。
物理アーキテクチャ
Traffic Manager は、非リージョン サービスとして動作し、世界中の複数のAzure リージョンの複数の可用性ゾーンにインフラストラクチャをデプロイします。 この設計により、別のゾーンまたはリージョン内のインフラストラクチャが解決要求に引き続き応答するため、可用性ゾーンまたはリージョンの停止時に Traffic Manager の回復性を維持できます。
Anycast、DNS、BGP などのグローバル インターネット プロトコルでは、受信 DNS 解決要求が最も正常な Traffic Manager インフラストラクチャに自動的にルーティングされます。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Traffic Manager は DNS レベルで動作し、正常性プローブを使用してエンドポイントの可用性を監視します。 このサービスは、グローバル DNS インフラストラクチャとエンドポイント監視機能を使用して一時的な障害を処理します。
Traffic Manager を使用する場合は、次の種類の一時的な障害を個別に検討してください。
DNS 解決中の一時的な障害: DNS 解決中に一時的なエラーが発生した場合は、クライアントまたは中間リゾルバーを再試行する必要があります。
バックエンド エンドポイントに影響する一時的な障害:Traffic Manager エンドポイント監視 は、エンドポイントの正常性を定期的にチェックします。 エンドポイント内またはエンドポイントへのネットワーク パス内の一時的な障害は、異常なエンドポイントとして検出される可能性があります。 一定期間の連続する問題を検索するようにエンドポイント監視を構成します。
DNS レコードの有効期間 (TTL) によって、ソリューションによる障害の処理方法が決まります。 TTL が非常に低い場合、クライアントは Traffic Manager に対してより多くの要求を行う必要があり、一時的な障害が発生する可能性が高くなります。 TTL が非常に高い場合、エンドポイントで真の障害が発生した場合、クライアントは TTL の有効期限が切れるまでフェールオーバーの遅延が発生する可能性があります。 可用性、待機時間、応答性のバランスを取るために、TTL を慎重に構成します。 Azure DNSを使用すると、プロファイルの TTL 値 (既定では 60 秒) と一致するようにレコードの TTL を自動的に構成できます。 詳細については、「Traffic Manager のパフォーマンスに関する考慮事項参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Traffic Manager は、非リージョン サービスとして動作し、世界中の複数のAzure リージョンの複数の可用性ゾーンにインフラストラクチャをデプロイします。 これらのゾーンとリージョン間でプロファイルへの変更が同期的にレプリケートされます。 この設計により、別のゾーンまたはリージョンのインフラストラクチャは解決要求に引き続き応答するため、可用性ゾーンの停止中も Traffic Manager の回復性を維持できます。
リージョン全体の障害に対する回復性
Traffic Manager は、非リージョン サービスとして動作し、世界中の複数のAzure リージョンの複数の可用性ゾーンにインフラストラクチャをデプロイします。 この設計により、別のゾーンまたはリージョン内のインフラストラクチャは解決要求に引き続き応答するため、リージョンの停止時に Traffic Manager の回復性を維持できます。
ポータルと管理ツールの停止に対する回復性
Azure ポータルで Traffic Manager プロファイルを管理する場合は、特にプラットフォームの停止中にプロファイルを再構成する必要がある場合に、アクセスできないシナリオに備えます。
他のAzure サービスと同様に、Traffic Manager では、さまざまなツールを使用したデプロイと管理がサポートされています。 Azure CLI または Azure PowerShell を使用してプロファイルを管理する方法を理解することをお勧めします。 または、Bicep や Terraform などのインフラストラクチャをコードとして扱う技術を使用して、プロファイルをデプロイして構成します。 Azure ポータルが機能低下した場合でも、これらのツールは引き続き動作します。
バックアップと復元
Traffic Manager はステートレス DNS サービスです。 データは保持されません。また、バックアップや復元の機能もありません。
リソース構成を保護するには、コードとしてのインフラストラクチャ (Bicep や ARM テンプレートなど) を使用して Traffic Manager プロファイルやその他のリソースを定義し、それらの定義をソース管理に格納します。 リソースを再作成する必要がある場合は、格納されている構成からリソースを再デプロイします。
サービス メンテナンスに対する回復性
Microsoft は定期的にサービス更新プログラムを適用し、その他のメンテナンスを実行します。 Azure プラットフォームは、これらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
Azure Traffic Managerは、クライアントが失敗した要求を繰り返し再試行する限り、DNS クエリ応答に対して 100% 可用性 SLA を提供します。