次の方法で共有


ミッション クリティカルなグローバル コンテンツ配信

コンテンツ配信ネットワーク (CDN) には、グローバル レイヤー 7 の負荷分散や最適化されたネットワーク ルーティングなど、ユーザーのパフォーマンスを最適化するためのさまざまな機能が用意されています。 キャッシュは、さまざまな問題に対するバックエンド サービスとプロバイダーの負荷をさらに軽減する一般的な方法でもあります。 AZURE Front Door を含む CDN は、ネットワーク エッジでキャッシュを提供します。

CDN は一部のソリューション アーキテクチャで不可欠なコンポーネントであるため、ミッション クリティカルなワークロードでは、複数の CDN を使用してより高いレベルのアップタイムを実現することが業界のベスト プラクティスです。 1 つの CDN で障害が発生したり、パフォーマンスが低下したりした場合、トラフィックは自動的に別の CDN に転送されます。

Microsoft では、 Azure Front Door の業界をリードするサービス レベル アグリーメント (SLA) を提供しています。 別のプロバイダーが 100% アップタイム SLA を提供する場合でも、ダウンタイムがゼロになる保証ではなく、停止が発生した場合に SLA によってサービス クレジットが提供されることに注意することが重要です。 このため、Microsoft の競合他社でさえ、ミッション クリティカルなワークロードに複数の CDN を使用することを推奨しており、独自の CDN を管理する多くの企業も他の CDN も利用しています。

複数の CDN を実装する場合は、このアプローチの影響を考慮してください。 各 CDN にはアプリケーション サーバーへの個別のネットワーク パスが用意されており、各 CDN を個別に構成してテストする必要があります。

この記事では、別の CDN で Azure Front Door を使用する方法について説明します。 このアプローチは、静的コンテンツ配信、メディア、および大規模な e コマース アプリケーションの配信にキャッシュに大きく依存するソリューションに適しています。

このユース ケースは、Azure Front Door が使用できない場合の代替アプローチをカバーする全体的な設計戦略の一部です。 コンテキストと考慮事項については、「 ミッション クリティカルなグローバル Web アプリケーション」を参照してください。

方法

サード パーティの CDN を Azure ソリューションに統合して、Microsoft のインフラストラクチャから分離することができます。 この分離により、障害シナリオからの回復性が高くなります。 障害や障害が発生した場合、トラフィックは Azure Front Door と代替 CDN の間で自動的にシフトされます。 Azure Traffic Manager を使用して停止を検出し、トラフィックを代替 CDN にリダイレクトできます。

Microsoft では、配信元のトラフィックを別の CDN にルーティングするための CDN 相互接続サービスを提供しています。データ転送料金は発生しません。 詳細については、 ルーティング設定を参照してください。

次の図は、CDN 間のトラフィックフローを示しています。

Azure Front Door と別の CDN の間の Traffic Manager ルーティングの図。

  • 優先順位ルーティング モードを使用する Traffic Manager には、2 つの エンドポイントがあります。 既定では、Traffic Manager は Azure Front Door を介して要求を送信します。 Azure Front Door が使用できない場合、Traffic Manager は代わりに代替 CDN を介して要求を送信します。

  • Azure Front Door は 、ほとんどのアプリケーション トラフィックを処理してルーティングします。 Azure Front Door は、トラフィックを適切な配信元アプリケーション サーバーにルーティングし、アプリケーションへのプライマリ パスを提供します。 Azure Front Door が使用できない場合、トラフィックはセカンダリ パスを介して自動的にリダイレクトされます。

  • 代替 CDN は、各配信元サーバーにトラフィックを送信するように構成されます。

  • 配信元アプリケーション サーバー は、Azure Front Door と別の CDN の両方からのトラフィックをいつでも受け入れる準備ができている必要があります。

考慮事項

ミッション クリティカルなグローバル Web アプリケーションで説明されている考慮事項は、引き続きこのユース ケースに適用されます。 その他のポイントを次に示します。

CDN の選択

Microsoft では、いくつかの CDN 製品を提供しています。 主要な CDN オファリングは Azure Front Door Standard と Premium であり、その他すべての CDN 製品の提供終了が発表されました。 他の CDN 製品も Azure Front Door と物理インフラストラクチャを共有するため、この記事で説明するアーキテクチャの種類に別の CDN 製品を選択することをお勧めします。 機能機能、アップタイム、コストのニーズを満たす代替 CDN を選択してください。

要件とリスク許容度に応じて、2 つ以上の CDN を使用することを選択できます。

機能の等価性

Azure Front Door には多くの CDN とは異なる機能が用意されており、機能は CDN 製品と同等ではありません。 たとえば、TLS 証明書、Web アプリケーション ファイアウォール (WAF)、および HTTP ルーティング規則の処理に違いがある場合があります。

使用する Azure Front Door の機能と、代替 CDN に同等の機能があるかどうかを慎重に検討してください。 詳細については、「 イングレス パスの整合性」を参照してください。

キャッシュの充填

アクティブ/パッシブ モードで複数の CDN を実行している場合、フェールオーバー中にパッシブ モードで構成された CDN は、フェールオーバー中に配信元から キャッシュ フィル を実行する必要があります。

Azure Front Door と代替 CDN の間のフェールオーバーをテストして、異常やパフォーマンスの問題を検出します。

キャッシュフィル中のパフォーマンスの問題からソリューションが危険にさらされている場合は、リスクを軽減するために次のアプローチを検討してください。

  • より高いトラフィック レベルに対処するため (特にキャッシュ フィル中)、配信元をスケールアウトまたはスケールアップします。

  • 両方の CDN を事前入力します。 フェールオーバー イベントが発生する前でも、パッシブ CDN を通じて最も一般的なコンテンツの割合を提供します。 たとえば、 重み付けトラフィック ルーティング モードの使用を検討できます。

トレードオフ

複数の CDN を使用すると、いくつかのトレードオフが伴います。

  • ソリューションの全体的なコストが増加する可能性があります。 マルチ CDN アーキテクチャをデプロイすると、複数の CDN に対して課金されます。 ソリューション内の各 CDN と、デプロイする他のすべてのコンポーネントに対して課金される方法を理解していることを確認します。

  • ソリューションに追加するコンポーネントを追加するたびに、管理オーバーヘッドが増加します。

  • Azure Front Door と代替 CDN の間のフェールオーバー中にパフォーマンスの問題が発生する可能性があります。

  • DNS トラフィック マネージャーを使用すると、要求に対して選択される CDN をランダム化できます。 CDN 間で一貫したキャッシュ設定を実装するように注意しない場合 ( たとえば、Azure Front Door でのキャッシュ)、配信元のエグレス帯域幅のパフォーマンスが低下し、コストが高くなる可能性があります。

  • 一般的な問題は、CDN がアクティブ/パッシブ モードで実行されている場合の キャッシュリフィル です。 パッシブ モードで構成された CDN は、配信元からのキャッシュを補充する必要があります。 そのプロセス中に、配信元システムがオーバーロードされる可能性があります。

貢献者

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

主要な著者:

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

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