次の方法で共有

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

  • [アーティクル]

重要

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

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

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

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

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

Front Door は、外部のお客様だけでなく、Microsoft 全体の複数のプロパティにも最大限の回復性と可用性を提供するように設計されています。 Front Door の機能の詳細については、「Azure Front Door を使用して Web アプリケーションを高速化し、セキュリティで保護する」をご覧ください。

Front Door の機能はほとんどのビジネスの要件を十分に満たすことができますが、分散システムでは障害が予想されます。 ビジネス要件で、より高い複合 SLO または停止時のゼロダウン タイムが求められる場合は、代替のトラフィック イングレス パスに依存する必要があります。 ただし、より高い SLO の追求には膨大なコストと運用上のオーバーヘッドが伴い、全体的な信頼性が低下する可能性があります。 代替パスによってクリティカル パス上の他のコンポーネントに発生する可能性があるトレードオフと潜在的な問題を慎重に考慮します。 非可用性による影響が大きい場合でも、複雑さがメリットを上回る可能性があります。

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

もう一つのアプローチは、グローバル ルーティングにサードパーティ製のテクノロジを使用することです。 このアプローチでは、2 つ以上のクラウド プロバイダー間でホストされるスタンプを使用したマルチクラウドのアクティブアクティブ デプロイが必要です。 Azure は他のクラウド プラットフォームと効果的に統合できますが、さまざまなクラウド プラットフォーム間で運用が複雑になるため、この方法は推奨されません。

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

アプローチ

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

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

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

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

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

    重要

    このソリューションは、Azure Front Door の停止に関連するリスクを軽減しますが、グローバル障害点として Azure Traffic Manager の停止の影響を受けやすくなります。

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

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

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

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

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

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

トレードオフ

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

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

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

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

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

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

警告

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

Azure Traffic Manager の可用性

Azure Traffic Manager は信頼性の高いサービスですが、サービス レベル アグリーメントでは 100% の可用性は保証されていません。 Traffic Manager が使用できない場合、Azure Front Door と代替サービスの両方を使用できる場合でも、ユーザーがアプリケーションにアクセスできない可能性があります。 このような状況でソリューションが動作し続ける方法を計画することが重要です。

Traffic Manager は、キャッシュ可能な DNS 応答を返します。 DNS レコードの有効期限 (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 が含まれている場合でも、攻撃者がアプリケーションへの保護されていないセカンダリ トラフィック パスを見つけた場合、セカンダリ パスを介して悪意のあるトラフィックを送信する可能性があります。

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

ドメイン名と DNS

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

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

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

CNAME チェーン

Traffic Manager、Azure Front Door、およびその他のサービスを組み合わせたソリューションでは、多層 DNS CNAME 解決プロセス (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 証明書や、有効期限や拇印が異なる 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 がトラフィックを代替パスを経由して配信元サーバーに転送するのにかかる時間が短くなります。

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 は、これらのソリューションで使用される重要なセキュリティ制御です。

警告

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

次の手順

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