Azure Traffic Manager の Well-Architected Framework の観点
Azure Traffic Manager は、複数の Azure リージョン、1 つのリージョン内のゾーン、またはそれらのゾーン内のデータセンターにトラフィックを分散できるグローバル ロード バランサーです。 ドメイン ネーム システム (DNS) プロトコルを使用して、クライアントとワークロードのエンドポイント間の通信パスを確立します。 接続が確立された後、クライアントは Traffic Manager の助けを借りずにエンドポイントに直接接続できます。
この記事では、アーキテクトとして、Azure の 負荷分散オプションを確認し、ワークロードに対して Azure Traffic Manager を選択したことを前提としています。これは、アクティブ/アクティブまたはアクティブ/パッシブ モデルの複数のリージョンにデプロイされます。 この記事のガイダンスでは、Well-Architected Framework の柱の原則にマップされるアーキテクチャに関する推奨事項を示します。
重要
このガイドの使用方法
各セクションには、設計チェックリスト があり、テクノロジ スコープにローカライズされた設計戦略と共に、関心のあるアーキテクチャ領域が示されています。
また、これらの戦略の具体化に役立つテクノロジ機能の推奨事項も含まれています。 推奨事項は、Traffic Manager とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。
主要な推奨事項を示す基本的なアーキテクチャ: Traffic Manager、Azure Firewall、Application Gateway を使用したマルチリージョン負荷分散の。
テクノロジーの範囲
このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。
- トラフィックマネージャー
手記
HTTP アプリケーションをホストするワークロードの場合、Azure Front Door は、コンテンツ配信ネットワーク、トランスポート層セキュリティ (TLS) 終了、統合ファイアウォールなどの機能があるため、自然な選択肢です。
Azure Front Door と比較して、Traffic Manager はセットアップ、構成、保守が簡単です。 Traffic Manager には、直接制御できるエンドポイントがありません。 クライアント要求を処理する Front Door とは異なり、Traffic Manager はクライアントをワークロードのエンドポイントにのみ接続します。
しかし、このシンプルさは、アーキテクチャに複雑さを導入できるトレードオフが伴います。 たとえば、Open Worldwide Application Security Project (OWASP) 攻撃の種類をブロックするために、追加のセキュリティ対策を実装する必要がある場合があります。 この機能は、Azure Front Door または Azure Application Gateway の Web アプリケーション ファイアウォール (WAF) によって提供されます。 または、キャッシュを追加すると、コンテンツ配信を高速化できますが、データ ストアを管理する必要があるため、複雑さが増します。
詳細については、Azure Front Door に関するWell-Architected Framework の観点を参照してください。
確実
信頼性の柱の目的は、十分な回復性と障害から迅速に回復する機能を構築 、継続的な機能を提供することです。
信頼性設計の原則、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。
設計チェックリスト
信頼性 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 アプリケーションの性質とそのコンポーネントの重要度を念頭に置いて、ビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
潜在的な障害を考慮します。 Traffic Manager は回復力を持つように設計されています。 ただし、それでもワークロードの単一障害点になる可能性があります。 このリスクを軽減するには、Traffic Manager が使用できない場合にアクティブになる代替サービスへのセカンダリ パスを定義します。 ルーティングの問題を回避するには、Traffic Manager と代替サービスを一緒に使用しないでください。
サービス レベル アグリーメント (SLA) の対象範囲について十分に理解してください。 Traffic Manager SLAを評価する場合、公開されたパーセンタイルに関連するカバレッジを理解している必要があります。 たとえば、DNS 参照が複数回失敗する場合があります。 これらのエラーは、1 分間の連続 DNS 参照エラーが発生するまで、ダウンタイムとは見なされません。
ワークロード アーキテクチャに冗長性を組み込みます。 サービスがパブリック IP アドレスを介して公開されている場合は、Traffic Manager を使用して、Azure リージョン、オンプレミス、およびその他のクラウド全体に冗長性を実装します。 たとえば、クラウドにセカンダリ インスタンスがあるオンプレミス アプリケーションがあるとします。 オンプレミス システムで障害が発生した場合、クラウド インスタンスはアクティブになり、継続性を確保するのに役立ちます。
冗長性をサポートするには、信頼性の高いデプロイ アーキテクチャを使用します。 Traffic Manager は、ロード バランサーとして、ルーティング方法の構成方法に基づいて、ワークロード エンドポイント間でトラフィックを分散します。 この構成は、Traffic Manager プロファイルで定義します。 プロファイルは、デプロイ戦略の中核となるコンポーネントです。 適切なプロファイル構成を使用して、アクティブ/アクティブ モデルまたはウォーム スペアを備えるアクティブ/パッシブ モデルを実装できます。
各プロファイルは、1 つのトラフィック ルーティング方法を指定します。 一部のシナリオでは、より高度なトラフィック ルーティングが必要です。 Traffic Manager プロファイルを組み合わせて、複数のトラフィック ルーティング方法を利用できます。
詳細については、「Traffic Manager ルーティング方法」を参照してください。
DNS 応答のキャッシュ期間を評価します。 Traffic Manager の DNS 参照の Time to Live (TTL) 設定によって、ダウンストリーム DNS リゾルバーが DNS 応答をキャッシュする期間が決まります。 既定の TTL では、キャッシュ時間が必要以上に長くなり、エンドポイントが失敗した場合にダウンタイムが発生する可能性があります。 TTL を減らして、キャッシュ更新の頻度を増やします。 この方法は、ダウンタイムを軽減するのに役立ちますが、DNS 参照の頻度が増加します。
異常なインスタンスや侵害されたインスタンスにトラフィックを送信しないようにします。 Traffic Manager の組み込みの正常性プローブ機能を確認します。
HTTPS および HTTP アプリケーションの場合は、正常性エンドポイント監視パターンを実装して、アプリケーション内にカスタム ページを提供します。 特定のチェックに基づいて、ページは適切な HTTPS 状態コードを返します。 正常性チェックでは、エンドポイントの可用性に加えて、アプリケーションのすべての依存関係を監視する必要があります。
他のアプリケーションの場合、Traffic Manager は伝送制御プロトコル (TCP) を使用してエンドポイントの可用性を判断します。
詳細については、「正常性エンドポイント監視パターンの」および「Traffic Manager プローブを理解する」を参照してください。
停止の許容度を決定します。 バックエンドが使用できなくなった場合、Traffic Manager が障害を認識し、使用できないエンドポイントへのトラフィックの送信を停止するまでに時間が経過する可能性があります。 クライアント要求を処理できない期間があります。 この許容値を使用してプローブの設定を構成します。これにより、ビジネス継続性の運用をどの程度迅速に開始するかを決定できます。
回復性テストの一部としてエンドポイントを含めます。 使用できないエンドポイントをシミュレートして、Traffic Manager でエラーがどのように処理されるかを確認します。 ワークロードで、プライベート仮想ネットワークで Application Gateway などのロード バランサーを使用するとします。 Azure Chaos Studio でネットワーク セキュリティ グループ (NSG) 規則を使用して、エンドポイントの障害をシミュレートできます。 Application Gateway が存在するサブネットへのアクセスをブロックできます。
推奨 事項
| 勧告 | 特長 |
|---|---|
| Traffic Manager プロファイルに複数のエンドポイント をデプロイし、有効にします。 エンドポイントが有効化されていない場合、正常性チェックは実施されず、トラフィックルーティングのローテーションには含まれません。 これらのエンドポイントを異なるリージョンに配置します。 | 冗長インスタンスは、1 つのエンドポイントが失敗した場合に可用性を確保するのに役立ちます。 |
| さまざまなトラフィック ルーティング方法 を評価します。 デプロイ戦略に合わせて 1 つまたは複数の方法を構成します。 Traffic Manager は、選択したメソッドを各 DNS クエリに適用し、そのメソッドを使用して、DNS 応答で返されるエンドポイントを決定します。 - 重み付け方法、構成された重み係数に基づいてトラフィックを分散します。 このメソッドはアクティブ/アクティブ モデルをサポートします。 - 優先度ベースの方法、トラフィックを受信してセカンダリ リージョンにバックアップとして送信するようにプライマリ リージョンを構成します。 このメソッドは、アクティブ/パッシブ モデルをサポートします。 - 地理的な方法 は、DNS クエリの地理的な発信元に基づいてトラフィックをルーティングします。 すべてのリージョンを対象にするには、All (World) プロパティを使用して少なくとも 1 つのエンドポイントを構成します。 |
最適化されたルーティング方法は、エンドポイント間でトラフィックを効率的に分散するのに役立ちます。 アクティブ/アクティブまたはアクティブ/パッシブのデプロイ モデルの目標をサポートできます。 効率的なルーティング方法は、セカンダリ リージョンがトラフィックを処理したり、バックアップとして機能したりするのに役立ちます。 地理的ルーティングは、ユーザーの場所に基づいて最も近いエンドポイントにユーザーを誘導するのに役立ちます。 これは、トラフィックが効率的に管理され、失われないようにするのに役立ちます。 |
| DNS TTL 間隔 期間を低い値 (できれば 60 秒未満) に設定します。 パフォーマンスを最適化するには、正常性プローブのタイミングと DNS レコードの TTL を調整します。 | TTL 期間を短くすると、ダウンストリーム DNS リゾルバーのキャッシュ更新の頻度が高くなり、フェールオーバーが迅速になります。 また、ダウンタイムを最小限に抑え、アプリケーションの全体的な応答性を向上させます。 |
| エンドポイント を監視するために、正常性プローブを設定します。 - エンドポイントの監視を無効にし、正常性状態に関係なくエンドポイントに要求を送信する AlwaysServeを有効にしないでください。 - probing interval 値を設定します。 障害を検出できる速度とエンドポイントへの要求の数のトレードオフを検討してください。 Traffic Manager はさまざまな場所から同時に ping を実行するグローバル サービスであるため、要求の数が多い場合があります。 - probe timeout 値を設定します。 エンドポイントの異常を宣言するまでの待機時間を検討してください。 エラーの数に擬陽性を含めます。 |
正常性プローブは、正常なインスタンスのみがユーザー要求を処理することを確認します。 また、障害が一時的でないかどうか、およびフェールオーバー操作の実行速度を判断するのにも役立ちます。 |
安全
セキュリティの柱の目的は、ワークロードに対して機密性、整合性、可用性を保証することです。
セキュリティ設計の原則、Traffic Manager の技術設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
セキュリティ ベースラインを確認します。 セキュリティ体制を強化するには、Traffic Manager のセキュリティ ベースラインを確認します。
トラフィック ルーティングの未承認の変更を防止します。 Traffic Manager プロファイルには、トラフィックをルーティングするための構成設定が含まれているため、重要なワークロード リソースとして扱います。 これらのプロファイルにアクセスできるのは、承認された ID のみです。 コントロール プレーン ロールベースのアクセス制御 (RBAC) を実装して、リソースの作成、削除、変更などのタスクを制限します。 承認された ID にのみ、エンドポイントを有効または無効にする権限が必要です。 未承認のアクセスにより、構成が変更され、トラフィックが悪意のある実装に再ルーティングされる可能性があります。
ネットワーク エッジの脅威からアプリケーションを保護します。 Traffic Manager には、WAF などの組み込みのセキュリティ機能は用意されていません。 HTTP アプリケーションをセキュリティで保護するには、エンドポイント レベルでトラフィック検査を実装する必要があります。
一般的なアーキテクチャには、Traffic Manager と複数のエンドポイントが含まれる場合があります。 エンドポイントごとに、TLS 終了やその他のセキュリティ機能を処理するアプリケーション ゲートウェイが保護を提供します。 そのパターンを示す参照アーキテクチャについては、「Traffic Manager、Azure Firewall、および Application Gatewayを使用したマルチリージョン負荷分散」を参照してください。
DNS エントリを強化します。 Traffic Manager は、DNS データを操作する攻撃の影響を受けやすくなります。これにより、トラフィックが悪意のあるサイトにリダイレクトされ、セキュリティの問題が発生する可能性があります。 一般的な脅威は、DNS レコードがプロビジョニング解除された Azure リソースを指すサブドメインの引き継ぎです。 サブドメインの引き継ぎを防ぐには、Azure DNS エイリアス レコードを使用し、DNS レコードのライフサイクルを Azure リソースと結合します。
詳細については、「未解決の DNS エントリを防止する」を参照してください。
推奨 事項
| 勧告 | 特長 |
|---|---|
| ワークロード エンドポイントにアプリケーション ゲートウェイを追加します。 HTTP アプリケーションのファイアウォールを使用してセキュリティ検査を実装するには、アプリケーション ゲートウェイをワークロード エンドポイントに追加します。 |
受信 HTTP トラフィックを検査して、一般的な攻撃からアプリケーションを保護できます。 |
| Traffic Manager プロファイルを参照するワークロードの頂点ドメイン名のエイリアス レコード を Azure DNS に作成します。 | エイリアス レコードは、DNS レコードのライフサイクルと Azure リソースを密に結合します。 この構成は、ワークロードが使用停止になった場合に未解決の参照を防ぐのに役立ちます。 Traffic Manager プロファイルが削除されると、DNS エイリアス レコードは空のレコード セットになります。 削除されたリソースは参照されなくなりました。 |
コストの最適化
コストの最適化では、支出パターンの検出 、重要な領域への投資の優先順位付け、ビジネス要件を満たしながら組織の予算を満たすために他の での最適化に重点を置いています。
コスト最適化の設計原則、Traffic Manager とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェックリスト
投資のコスト最適化 の 設計レビュー チェックリストに基づいて、設計戦略を開始します。 ワークロードに割り当てられた予算に合わせて設計を微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
特徴のコストを評価します。 トラフィック ビュー ダッシュボード機能には、クライアントの接続先と関連する待機時間が表示されます。 この情報は、パフォーマンスを最適化し、設計を改良するのに役立ちます。これにより、オペレーショナル エクセレンスとシステム効率に貢献します。 ただし、追加コストが発生します。 詳細については、トラフック ビューの課金を参照してください。
また、正常性プローブに関連するコストも考慮してください。 Traffic Manager は、さまざまな場所から定義されたエンドポイントに ping を実行して、その可用性を確認します。 低速 ping と高速 ping を選択できます。 高速 ping を使用すると、エラーが迅速に検出されますが、コストは高くなります。 正常性チェックがより頻繁になるため、ワークロードの負荷も増えます。
ルーティング戦略のコストを評価します。 たとえば、ほとんどのクライアントが待機時間の長いリージョンからエンドポイントにアクセスする場合は、それらのユーザーの近くに別のエンドポイントを作成し、Traffic Manager でルーティング方法を調整できます。 この方法では、待機時間が短縮され、容量が少ないより多くの要求を処理できるため、コスト削減につながります。
推奨 事項
| 勧告 | 特長 |
|---|---|
| 料金計算ツールの を使用して、Traffic Manager 機能のコストを見積もります。 | 必要に応じて、より正確なコスト モデルを作成し、リソースに関するガバナンスを設定できます。 |
| 最適化作業中に トラフィック ビュー ダッシュボード を有効にします。 | この機能は、使用パターンをより深く理解するのに役立ちます。 このデータは、ワークロードのターゲットを満たすのに役立つパフォーマンス チューニングに使用します。 適切なタイミングで機能を有効にし、適切なレベルを適用してリソースの過少使用を回避します。 |
| 復旧メトリックに応じて、正常性プローブの高速または低速の ping を選択します。 高速 ping を使用すると、エラーが迅速に検出されますが、コストは高くなります。 遅い ping は遅くなりますが、コストは安くなります。 ping を無効にしないでください。 |
Ping の頻度を減らしてコストを最適化し、ワークロード エンドポイントの負荷を軽減します。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは主に、開発プラクティス、可観測性、リリース管理の手順に重点を置いています。
オペレーショナル エクセレンス設計原則、ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
ワークロードの監視の一環として、運用データを収集して分析します。 関連する Traffic Manager のログとメトリックをキャプチャします。 このデータを使用して、トラブルシューティングを行い、トラフィックの動作を理解し、ルーティング ロジックを微調整します。
プロファイルのトラフィック データを表示します。 このデータは、待機時間の長いリージョンでの Azure プレゼンスの拡大など、改善のための領域を特定するのに役立ちます。 また、さまざまなリージョン間のトラフィック パターンも強調表示され、投資を増減する場所を決定するのに役立ちます。
ディザスター リカバリー操作を実装します。 ディザスター リカバリーの実装は、メイン サイトからバックアップ サイトにネットワーク/Web トラフィックを再ルーティングするように設計できます。 このディザスター リカバリー方法は、Azure DNS と Azure Traffic Manager (DNS) を使用して実装できます。 障害が発生した場合、プライマリ エンドポイントが低下した場合、Traffic Manager はトラフィックを正常なセカンダリ エンドポイントにリダイレクトします。 既定では、Traffic Manager はプライマリ エンドポイントを優先しますが、追加のフェールオーバー エンドポイントまたはロード バランサーを使用して設定してトラフィックの負荷を分散することもできます。 詳細については、「ディザスター リカバリーと障害検出の設定」を参照してください。
自動フェールバック操作は避けてください。 フェールバックを行う場合は、自動フェールバックを使用しないでください。このフェールバックは、使用可能になるとすぐにプライマリの元のエンドポイントに切り替わります。 代わりに、元のエンドポイントを無効にし、切り替えるまでセカンダリ エンドポイントを使用します。 この方法では、安定化のための時間が提供されます。 即時フェールバックにより、追加の負荷と遅延が発生する可能性があります。
構成設定をテストします。 構成の誤りは、ワークロードのすべての側面 、特に信頼性に影響を与える可能性があります。 さまざまな場所で複数のクライアントで構成をテストします。 詳細については、「Traffic Manager の設定の確認を参照してください。
推奨 事項
| 勧告 | 特長 |
|---|---|
| Traffic Manager プロファイルの診断ログ を有効にします。 ツール を使用してログを再生し、正常性チェック データを分析します。 |
診断ログは、Traffic Manager プロファイルの動作に関する分析情報を提供します。 たとえば、エンドポイントに対する個々のプローブ タイムアウトの理由を特定できます。 |
| トラフィック ビュー ダッシュボードのを有効にします。 クライアントの接続先と関連する待機時間に関する分析情報を取得します。 | この情報は、設計を調整できるため、パフォーマンスとコストを最適化するのに役立ちます。 |
| クライアントの場所と待機時間に関するデータを提供する ヒート マップ REST APIを利用します。 | この方法では、特定の期間を設定するなど、柔軟性が提供されます。 カスタム ツールまたはダッシュボードにデータを追加できます。 この API を使用して、外部ツールと統合することもできます。 |
| 操作アクティビティのエンドポイントを無効にします。 たとえば、フェールオーバー後にフェールバックを無効にして、メンテナンスやテストを行うことができます。 | ライブ トラフィックを停止できないため、ロード バランサーからエンドポイントを無効にすると、運用タスクに役立ちます。 メンテナンス中に、エンドポイントを無効にした場合、インスタンスはトラフィックを受信しません。 この方法により、自動フェールバックが防止されます。 |
パフォーマンス効率
パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計の原則、予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
パフォーマンス効率 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 Traffic Manager の主要業績評価指標に基づくベースラインを定義します。
構成のパフォーマンスへの影響を測定します。 Traffic Manager は、クライアントとエンドポイント間の直接接続に干渉しません。 パフォーマンスへの主な影響は、初期 DNS 参照です。 TTL 設定は、この検索が実行される頻度に影響します。 TTL が低いほど、DNS 解決の頻度が高くなり、パフォーマンスに若干の影響を与える可能性があります。 TTL を 0 に設定すると、すべての要求に DNS 参照が必要になります。これによって、エンドポイントにアクセスする前に少し遅延が発生します。
Traffic Manager は DNS レベルで動作するため、セッション アフィニティはサポートされません。 Traffic Manager は、呼び出しごとに異なるエンドポイントにユーザーを誘導する場合があります。 セッション アフィニティが必要な場合は、状態を別のデータ ストアに保持する必要があります。
詳細については、「Traffic Manager のパフォーマンスに関する考慮事項参照してください。
トラフィック ルーティングの動作を調整してパフォーマンスを最適化します。 1 つのプロファイルに複数のエンドポイントを設定できますが、一度に適用できるルーティング方法は 1 つだけです。
より複雑なシナリオでは、プロファイルの階層を作成して、さまざまなルーティング方法を組み合わせることを検討してください。 たとえば、リージョンに優先順位を付けてから、リージョン内でパフォーマンスベースのルーティングを使用できます。
推奨 事項
| 勧告 | 特長 |
|---|---|
| 異なる地理的な場所にエンドポイントがある場合は、パフォーマンス ルーティング方法 を使用します。 | この方法では、待機時間が最も短いエンドポイントへのトラフィックの送信に優先順位を付けます。 この方法は、ユーザーの高速なサービスを確保するのに役立ちます。 |
| 特殊なツールを使用してパフォーマンスを最適化します。 DNS ルックアップのパフォーマンスを測定します。 トラフィックのパフォーマンスを分析するには、トラフィック ビュー ダッシュボード または ヒート マップ REST APIを使用します。 | DNS 待機時間測定ツールは、完全な DNS 参照を実行し、パフォーマンス データを提供します。 このデータを使用して TTL 期間を設定し、パフォーマンスを最適化できます。 |
| あなたのワークロードの要件に従って最適なパフォーマンスを得るために、トラフィック方法を入れ子になったプロファイル と組み合わせます。 | 最適化されたルーティング方法は、トラフィックが最も応答性の高い最も近いエンドポイントに送信されるようにするのに役立ちます。 このアプローチは、アプリケーションのパフォーマンスとユーザー エクスペリエンスの向上に役立ちます。 |
| Azure リージョンへのネットワーク待機時間の測定値を表示するには、実際のユーザー測定機能 を使用します。 この機能は追加料金なしで利用できます。 | 待機時間が最も短い Azure リージョンにクエリを送信するために、データドリブン ルーティングの決定を行うことができます。 |
| DNS TTL 間隔 より大きい値に設定します。 | クライアントは、結果を長期間キャッシュできるため、DNS を毎回解決する必要が減ります。 |
Azure ポリシー
Azure には、Traffic Manager とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 上記の推奨事項の一部は、Azure Policy を使用して監査できます。 たとえば、次のことを確認できます。
- リソース ログは、アクティビティを追跡するために有効になっています。
- Traffic Manager プロファイルのログは、Azure Event Hubs に送信されます。
包括的なガバナンスについては、Azure ネットワーク サービス の Azure Policy 組み込み定義を確認してください。
Azure Advisor の推奨事項
Azure Advisor は、Azure デプロイを最適化するためのベスト プラクティスに従うのに役立つ、パーソナライズされたクラウド コンサルタントです。 ここでは、Web アプリケーション インスタンスの信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項をいくつか示します。
トレードオフ
柱のチェックリストのアプローチを使用する場合は、設計のトレードオフを行う必要がある場合があります。 利点と欠点の例をいくつか次に示します。
信頼性とパフォーマンス効率
DNS 参照の TTL 設定。 既定の TTL 設定では、キャッシュ時間が長くなる可能性があります。 長いキャッシュ時間は、アプリケーションが TTL 期間のために失敗したエンドポイントへの接続を試み続けるので、エンドポイントが失敗した場合にダウンタイムを引き起こす可能性があります。
この問題の軽減に役立つ TTL を減らします。 TTL が低いほど、更新の頻度が高くなり、フェールオーバーが速くなりますが、DNS 参照の頻度が増加します。 この方法は、パフォーマンスに影響を与え、DNS サーバーの負荷を高める可能性があります。
信頼性とコストの最適化
- 正常性プローブ。 Traffic Manager では、正常性プローブを使用して、さまざまな場所からエンドポイントに ping を実行し、その可用性を確認します。 低速 ping または高速 ping を選択できます。 高速 ping を使用すると、エラーが迅速に検出されますが、コストが追加されます。 失敗を検出するのに ping の速度が遅いと時間がかかりますが、コストは低くなります。 障害検出と復旧の速度と関連するコストのバランスを取ります。
次の手順
この記事の推奨事項を示す次のリソースを検討してください。
この記事のガイダンスをワークロードに適用する方法の例として、次の参照アーキテクチャを使用します。
実装の専門知識を向上させるには、次の製品ドキュメントを使用します。