次の方法で共有

ミッション クリティカルな Web アプリケーションのグローバル ルーティング冗長性

重要

ミッション クリティカルなアーキテクチャのグローバル プラットフォームの停止に対処する冗長性実装の設計は、複雑でコストがかかる場合があります。 この設計で発生する可能性のある潜在的な問題のため、トレードオフを慎重に検討 してください。

ほとんどの場合、この記事で説明するアーキテクチャは必要ありません。

ミッション クリティカルなシステムでは、ソリューションに冗長性と自己復旧機能を可能な限り構築することで、単一障害点を最小限に抑えるように努めています。 システムの統合エントリ ポイントは、障害点と見なすことができます。 このコンポーネントで障害が発生した場合、システム全体がユーザーに対してオフラインになります。 ルーティング サービスを選択するときは、サービス自体の信頼性を考慮することが重要です。

ミッション クリティカルなアプリケーションのベースライン アーキテクチャでは、アップタイムの高いサービス レベル アグリーメント (SLA) と豊富な機能セットにより、Azure Front Door が選択されました。

  • アクティブ/アクティブ モデル内の複数のリージョンにトラフィックをルーティングする
  • TCP エニーキャストを使用した透過的なフェールオーバー
  • 統合コンテンツ配信ネットワーク (CDN) を使用してエッジ ノードから静的コンテンツを提供する
  • 統合された Web アプリケーション ファイアウォールを使用して未承認のアクセスをブロックする

Azure Front Door の機能の詳細については、「Azure Front Door を使用した Web アプリケーションの高速化とセキュリティ保護」を参照してください。

Azure Front Door は、外部のお客様だけでなく、Microsoft 全体の複数のプロパティに対して最大限の回復性と可用性を提供するように設計されています。 Azure Front Door の機能は、ほとんどのビジネス要件を満たすのに十分以上ですが、しかし、分散システムでは障害が発生することを想定すべきです。 コンポーネントやシステムは完全ではありません。 Microsoft では、 Azure Front Door の業界をリードするサービス レベル アグリーメント (SLA) を提供しています。 別のプロバイダーが 100% アップタイム SLA を提供する場合でも、ダウンタイムがゼロになる保証ではなく、停止が発生した場合に SLA によってサービス クレジットが提供されることに注意することが重要です。

障害が発生した場合に、ビジネス要件で高い複合 SLO またはダウンタイムゼロが必要な場合は、複数の代替トラフィックイングレス パスに依存する必要があります。 多くの大規模な組織や高プロファイル Web プロパティでは、このアプローチを使用して、可能な限り高い可用性を確保し、配信パフォーマンスを最適化します。 ただし、より高い SLO の追求には、大幅なコスト、運用上のオーバーヘッドが伴い、全体的な信頼性が低下する可能性があります。 代替パスがクリティカル パス上 にある他の コンポーネントで発生する可能性があるトレードオフと潜在的な問題を慎重に検討してください。 使用不能の影響が大きい場合でも、複雑さがメリットを上回る可能性があります。

1 つの方法は、代替サービスを使用してセカンダリ パスを定義することです。これは、Azure Front Door が使用できない場合にのみアクティブになります。 Azure Front Door との機能パリティは、ハード要件として扱うべきではありません。 限られた容量で実行される可能性がある場合でも、ビジネス継続性のために絶対に必要な機能に優先順位を付けます。

この記事では、Azure Front Door が使用できない状況で、代替ルーターとして Azure Traffic Manager を使用してグローバル ルーティングを行う方法について説明します。

方法

このアーキテクチャ図は、複数の冗長トラフィック パスを使用した一般的なアプローチを示しています。

Azure Front Door または別のサービスに要求を転送し、配信元サーバーに送信する Traffic Manager を示す図。

このアプローチでは、いくつかのコンポーネントを紹介し、Web アプリケーションの配信に関連して大きな変更を加えるガイダンスを提供します。

  1. Azure Traffic Manager は 、トラフィックを Azure Front Door または選択した代替サービスに送信します。

    Azure Traffic Manager は、DNS ベースのグローバル ロード バランサーです。 ドメインの CNAME レコードは Traffic Manager を指し、 ルーティング方法の構成方法に基づいて宛先を決定します。 優先順位ルーティングを使用すると、既定で Azure Front Door を通過するトラフィックフローが行われます。 Azure Front Door が使用できない場合、Traffic Manager はトラフィックを代替パスに自動的に切り替えることができます。

    重要

    このソリューションは、Azure Front Door やその他のプロバイダーの停止に関連するリスクを軽減しますが、グローバル障害ポイントとして Azure Traffic Manager の停止の影響を受けやすくなります。 詳細については、「 Azure Traffic Manager の可用性」を参照してください。

    グローバル ロード バランサーなど、別のグローバル トラフィック ルーティング システムの使用を検討することもできます。 ただし、Traffic Manager は多くの状況に適しています。

  2. 次の 2 つのイングレス パスがあります。

    • Azure Front Door は、プライマリ パスとプロセスを提供し、すべてのアプリケーション トラフィックをルーティングします。

    • 別のルーターは、Azure Front Door のバックアップとして使用されます。 Front Door が使用できない場合にのみ、トラフィックはこのセカンダリ パスを通過します。

    セカンダリ ルーターに対して選択する特定のサービスは、多くの要因によって異なります。 Azure ネイティブ サービスまたはサード パーティのサービスを使用することを選択できます。 これらの記事では、ソリューションに運用上の複雑さを追加しないように、可能な場合は Azure ネイティブ オプションを提供します。 サードパーティのサービスを使用する場合は、複数のコントロール プレーンを使用してソリューションを管理する必要があります。

  3. 配信元アプリケーション サーバーは、いずれかのサービスからのトラフィックを受け入れる準備ができている必要があります。 配信元へのトラフィックをセキュリティで保護する方法と、Azure Front Door やその他のアップストリーム サービスが提供する責任について検討します。 アプリケーションで、トラフィックが通過するパスからのトラフィックを処理できることを確認します。

トレードオフ

この軽減戦略により、プラットフォームの停止中にアプリケーションを使用できるようになりますが、いくつかの重要なトレードオフがあります。 潜在的な利点を既知のコストと比較し、そのメリットがそれらのコストに見合うかどうかを十分な情報に基づいて判断する必要があります。

  • 財務コスト: 複数の冗長パスをアプリケーションにデプロイする場合は、リソースをデプロイして実行するコストを考慮する必要があります。 ユース ケースごとに異なるコスト プロファイルを持つ 2 つのシナリオ例を提供します。

  • 運用の複雑さ: ソリューションにコンポーネントを追加するたびに、管理オーバーヘッドが増加します。 1 つのコンポーネントに対する変更は、他のコンポーネントに影響を与える可能性があります。

    Azure Front Door の新機能を使用することにしたとします。 代替トラフィック パスにも同等の機能があるかどうかを確認する必要があります。そうでない場合は、2 つのトラフィック パス間の動作の違いを処理する方法を決定する必要があります。 実際のアプリケーションでは、これらの複雑さが高コストになり、システムの安定性に大きなリスクが生じる可能性があります。

  • パフォーマンス: この設計では、名前解決中に追加の CNAME 参照が必要です。 ほとんどのアプリケーションでは、これは大きな問題ではありませんが、イングレス パスに追加のレイヤーを導入することで、アプリケーションのパフォーマンスが影響を受けるかどうかを評価する必要があります。

  • 機会費用: 冗長なイングレスパスの設計と実装には、エンジニアリングへの多大な投資が必要です。これにより、最終的に機能開発やその他のプラットフォーム改善に対する機会費用が生じます。

警告

複雑な高可用性ソリューションを設計して実装する方法に注意しないと、実際には可用性が低下する可能性があります。 アーキテクチャ内のコンポーネントの数を増やすと、障害ポイントの数が増えます。 また、運用の複雑さのレベルが高いことを意味します。 追加のコンポーネントを追加する場合は、ソリューション全体に与える影響を理解するために、行うすべての変更を慎重に確認する必要があります。

Azure Traffic Manager の可用性

Azure Traffic Manager は 、業界をリードする SLA を備えた信頼性の高いサービスですが、100% の可用性を保証できるトラフィック管理サービスはありません。 Traffic Manager が使用できない場合、Azure Front Door と代替サービスの両方が使用できる場合でも、ユーザーがアプリケーションにアクセスできない可能性があります。 このような状況でソリューションが引き続き動作する方法を計画することが重要です。

Traffic Manager は、キャッシュ可能な DNS 応答を返します。 DNS レコードの Time to Live (TTL) でキャッシュが許可されている場合、Traffic Manager の短時間の停止は問題にならない可能性があります。 これは、ダウンストリーム DNS リゾルバーが以前の応答をキャッシュした可能性があるためです。 長時間の停止を計画する必要があります。 Traffic Manager が使用できない場合は、ユーザーを Azure Front Door に誘導するように DNS サーバーを手動で再構成することもできます。

トラフィック ルーティングの一貫性

別のサービスを使用する場合は、Azure Front Door の機能と特長を理解し、それに依存することが重要です。 代替サービスを選択する場合は、必要な最小限の機能を決定し、ソリューションが機能低下モードの場合は他の機能を省略します。

別のトラフィック パスを計画する際に考慮すべき重要な質問を次に示します。

  • Azure Front Door のキャッシュ機能を使用していますか? キャッシュが使用できない場合、配信元サーバーはトラフィックに追いつくことができますか?
  • Azure Front Door ルール エンジンを使用してカスタム ルーティング ロジックを実行するか、要求を書き換えますか?
  • Azure Front Door Web アプリケーション ファイアウォール (WAF) を使用してアプリケーションをセキュリティで保護しますか?
  • IP アドレスまたは地域に基づいてトラフィックを制限しますか?
  • 誰があなたの TLS 証明書を発行し、管理していますか？
  • 配信元アプリケーション サーバーへのアクセスを制限して、Azure Front Door を経由するようにするにはどうすればよいですか? Private Link を使用するか、サービス タグと識別子ヘッダーを持つパブリック IP アドレスに依存していますか?
  • アプリケーション サーバーは、Azure Front Door 以外の場所からのトラフィックを受け入れますか? その場合、どのプロトコルを受け入れますか?
  • クライアントは Azure Front Door の HTTP/2 サポートを使用していますか?

Web アプリケーション ファイアウォール (WAF)

Azure Front Door の WAF を使用してアプリケーションを保護する場合は、トラフィックが Azure Front Door を通過しない場合の動作を検討してください。

代替パスで WAF も提供される場合は、次の質問を検討してください。

  • Azure Front Door WAF と同じ方法で構成できますか?
  • 誤検知の可能性を減らすために、個別に調整してテストする必要がありますか?

警告

代替イングレス パスに WAF を使用しないことを選択できます。 このアプローチは、アプリケーションの信頼性ターゲットをサポートすると考えることができます。 ただし、これは適切なセキュリティプラクティスではなく、お勧めしません。

チェックなしでインターネットからのトラフィックを受け入れる場合のトレードオフを検討してください。 攻撃者は、保護されていないセカンダリ トラフィック パスをアプリケーションに検出した場合、プライマリ パスに WAF が含まれている場合でも、セカンダリ パスを介して悪意のあるトラフィックを送信する可能性があります。

アプリケーション サーバー へのすべてのパスをセキュリティで保護 することをお勧めします。

高可用性に関するその他の考慮事項

ミッション クリティカルな Web アーキテクチャを設計する場合、アプリケーションの可用性とパフォーマンスに影響を与える可能性のある多くの要因があります。 これらの要因の多くは、Azure Front Door の構成と機能を超え、代わりにエコシステムとソリューションの全体的な設計に関連しています。

ドメイン名と DNS

ミッション クリティカルなアプリケーションでは、カスタム ドメイン名を使用する必要があります。 トラフィックがアプリケーションに流れる方法を制御し、1 つのプロバイダーへの依存関係を減らします。

また、 Azure DNS など、ドメイン名に高品質で回復性の高い DNS サービスを使用することをお勧めします。 ドメイン名の DNS サーバーが使用できない場合、ユーザーはサービスにアクセスできません。

全体的な回復性をさらに高めるために、複数の DNS リゾルバーを使用することをお勧めします。

CNAME チェーン

Traffic Manager、Azure Front Door、およびその他のサービスを組み合わせたソリューションでは、CNAME チェーンとも呼ばれる多層 DNS CNAME 解決プロセスが使用されます。 たとえば、独自のカスタム ドメインを解決すると、IP アドレスが返される前に 5 つ以上の CNAME レコードが表示されることがあります。

CNAME チェーンにリンクを追加すると、DNS 名前解決のパフォーマンスに影響する可能性があります。 ただし、DNS 応答は通常キャッシュされるため、パフォーマンスへの影響が軽減されます。

TLS 証明書

ミッション クリティカルなアプリケーションの場合は、Azure Front Door によって提供されるマネージド証明書ではなく、独自の TLS 証明書をプロビジョニングして使用することをお勧めします。 この複雑なアーキテクチャでは、潜在的な問題の数を減らすことができます。

いくつかの利点を次に示します。

  • マネージド TLS 証明書を発行して更新するために、Azure Front Door はドメインの所有権を検証します。 ドメイン検証プロセスでは、ドメインの CNAME レコードが Azure Front Door を直接指していることを前提としています。 しかし、多くの場合、その前提は正しくありません。 Azure Front Door でマネージド TLS 証明書を発行および更新すると、正常に動作しないことがあり、TLS 証明書の問題による停止のリスクが高まります。

  • 他のサービスがマネージド TLS 証明書を提供している場合でも、ドメインの所有権を確認できない可能性があります。

  • 各サービスが個別に独自のマネージド TLS 証明書を取得する場合は、問題が発生する可能性があります。 たとえば、ユーザーは、異なる機関によって発行されたり、有効期限や拇印が異なる TLS 証明書を目にすることを予期していないかもしれません。

ただし、証明書の有効期限が切れる前に、証明書の更新と更新に関連する追加の操作が発生します。

オリジンセキュリティ

Azure Front Door 経由のトラフィックのみを受け入れるように 配信元を構成 すると、レイヤー 3 とレイヤー 4 の DDoS 攻撃に対する保護が得られます。 Azure Front Door は有効な HTTP トラフィックにのみ応答します。これは、多くのプロトコルベースの脅威にさらされるリスクを軽減するのにも役立ちます。 代替のイングレス パスを許可するようにアーキテクチャを変更する場合は、配信元の脅威への露出を誤って増やしたかどうかを評価する必要があります。

Private Link を使用して Azure Front Door から配信元サーバーに接続する場合、トラフィックは代替パスをどのように通過しますか? プライベート IP アドレスを使用して配信元にアクセスできますか、パブリック IP アドレスを使用する必要がありますか?

配信元が Azure Front Door サービス タグと X-Azure-FDID ヘッダーを使用して、トラフィックが Azure Front Door を通過したことを検証する場合は、トラフィックが有効なパスのいずれかを通過したことを検証するために配信元を再構成する方法を検討してください。 他の顧客の Azure Front Door プロファイルを含め、他のパスを経由するトラフィックに配信元を誤って開いていないことをテストする必要があります。

配信元のセキュリティを計画するときは、代替トラフィック パスが専用パブリック IP アドレスのプロビジョニングに依存しているかどうかを確認します。 バックアップ パスをオンラインにするには、手動でトリガーされるプロセスが必要な場合があります。

専用のパブリック IP アドレスがある場合は、配信元に対するサービス拒否攻撃のリスクを軽減するために Azure DDoS Protection を実装する必要があるかどうかを検討してください。 また、 Azure Firewall またはさまざまなネットワーク脅威から保護できる別のファイアウォールを実装する必要があるかどうかを検討します。 さらに侵入検出戦略が必要になる場合もあります。 これらのコントロールは、より複雑なマルチパス アーキテクチャの重要な要素になる可能性があります。

ヘルスモデリング

ミッション クリティカルな設計手法には、ソリューションとそのコンポーネントの全体的な可観測性を提供するシステム 正常性モデル が必要です。 複数のトラフィック イングレス パスを使用する場合は、各パスの正常性を監視する必要があります。 トラフィックがセカンダリ イングレス パスに再ルーティングされる場合、正常性モデルには、システムがまだ動作しているが、機能低下状態で実行されているという事実が反映されている必要があります。

健康モデルの設計に次の質問を含めます。

  • ソリューションのさまざまなコンポーネントでダウンストリーム コンポーネントの正常性を監視する方法
  • ヘルスモニターは下流のコンポーネントをいつ不健康と見なすべきですか?
  • 停止が検出されるまでにどのくらいの時間がかかりますか?
  • 障害が検出された後、トラフィックが別のパス経由でルーティングされるまでにどのくらいの時間がかかりますか?

Azure Front Door の正常性を監視し、障害が発生した場合にバックアップ プラットフォームへの自動フェールオーバーをトリガーできる複数のグローバル負荷分散ソリューションがあります。 ほとんどの場合、Azure Traffic Manager が適しています。 Traffic Manager では、 エンドポイント監視 を構成して、確認する URL、その URL を確認する頻度、およびプローブ応答に基づいてダウンストリーム サービスの異常を考慮するタイミングを指定することで、ダウンストリーム サービスを監視します。 一般に、チェック間隔が短いほど、Traffic Manager が代替パスを経由して配信元サーバーに到達するまでのトラフィックの転送にかかる時間が短くなります。

Azure Front Door が使用できない場合、障害がトラフィックに影響を与える時間には、次のような複数の要因が影響します。

  • DNS レコードの有効期間 (TTL)。
  • Traffic Manager が正常性チェックを実行する頻度。
  • トラフィックを再ルーティングする前に Traffic Manager が確認するように構成されている失敗したプローブの数。
  • クライアントとアップストリーム DNS サーバーが Traffic Manager の DNS 応答をキャッシュする期間。

また、これらの要因のうち、制御の範囲内にある要素と、制御を超えるアップストリーム サービスがユーザー エクスペリエンスに影響を与える可能性があるかどうかを判断する必要もあります。 たとえば、DNS レコードで TTL が低い場合でも、アップストリーム DNS キャッシュは古い応答を必要以上に長く提供する可能性があります。 この動作は、Traffic Manager が既に代替トラフィック パスへの要求の送信に切り替えた場合でも、停止の影響を悪化させたり、アプリケーションを使用できないように見えたりする可能性があります。

ヒント

ミッション クリティカルなソリューションには、可能な限り自動フェールオーバー アプローチが必要です。 手動フェールオーバー プロセスは、アプリケーションの応答性を維持するために低速と見なされます。

参照先: ミッションクリティカルな設計領域: ヘルスモデリング

ダウンタイムなしのデプロイ

冗長なイングレス パスを使用してソリューションを運用する方法を計画する場合は、サービスが低下したときにサービスをデプロイまたは構成する方法も計画する必要があります。 ほとんどの Azure サービスでは、SLA はサービス自体のアップタイムに適用され、管理操作やデプロイには適用されません。 デプロイと構成のプロセスを、サービスの停止に対する回復性を持たせる必要があるかどうかを検討します。

また、ソリューションを管理するために対話する必要がある独立したコントロール プレーンの数も考慮する必要があります。 Azure サービスを使用する場合、Azure Resource Manager は統一された一貫性のあるコントロール プレーンを提供します。 ただし、サードパーティのサービスを使用してトラフィックをルーティングする場合は、別のコントロール プレーンを使用してサービスを構成する必要があります。これにより、運用の複雑さが増します。

警告

複数のコントロール プレーンを使用すると、ソリューションに複雑さとリスクが生じます。 すべての相違点により、構成設定を誤って見逃したり、冗長コンポーネントに異なる構成を適用したりする可能性が高くなります。 運用手順によってこのリスクが軽減されることを確認します。

参照: ミッション クリティカルな設計領域: ゼロダウンタイムのデプロイ

継続的な検証

ミッション クリティカルなソリューションの場合、テストプラクティスでは、アプリケーション トラフィックが通過するパスに関係なく、ソリューションが要件を満たしていることを確認する必要があります。 ソリューションの各部分と、障害の種類ごとにテストする方法を検討します。

テスト プロセスに次の要素が含まれるようにします。

  • プライマリ パスが使用できない場合、トラフィックが代替パスを介して正しくリダイレクトされることを確認できますか?
  • 両方のパスで、受信する予定の運用トラフィックのレベルをサポートできますか。
  • 低下状態のときに脆弱性を開いたり公開したりしないように、両方のパスが適切にセキュリティ保護されていますか?

参照先: ミッションクリティカルな設計領域: 継続的な検証

一般的なシナリオ

この設計を使用できる一般的なシナリオを次に示します。

  • グローバル コンテンツ配信 は、一般的に静的コンテンツ配信、メディア、および大規模な e コマース アプリケーションに適用されます。 このシナリオでは、キャッシュはソリューション アーキテクチャの重要な部分であり、キャッシュに失敗すると、パフォーマンスや信頼性が大幅に低下する可能性があります。

  • グローバル HTTP イングレス は、一般的にミッション クリティカルな動的アプリケーションと API に適用されます。 このシナリオでは、トラフィックを配信元サーバーに確実かつ効率的にルーティングすることが主な要件です。 多くの場合、WAF は、これらのソリューションで使用される重要なセキュリティ制御です。

警告

複雑なマルチイングレス ソリューションを設計して実装する方法に注意しないと、実際には可用性が低下する可能性があります。 アーキテクチャ内のコンポーネントの数を増やすと、障害ポイントの数が増えます。 また、運用の複雑さのレベルが高いことを意味します。 追加のコンポーネントを追加する場合は、ソリューション全体に与える影響を理解するために、行うすべての変更を慎重に確認する必要があります。

貢献者達

この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。

主要な著者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

グローバル HTTP イングレスとグローバル コンテンツ配信のシナリオを確認して、それらがソリューションに適用されるかどうかを理解します。