こんにちは。Azure テクニカル サポート チームの石原です。
本ブログでは、Azure Front Door 及び Microsoft Standard SKU の Azure CDN (以降は AFD と記載致します) において起こりうる接続の問題やお客様で対策可能な内容などについてご案内致します。
AFD で発生しうる接続の問題ついて
AFD のプラットフォーム上では、より早くより適切なルートでオリジンへトラフィックをルーティングするために、さまざまな仕組みが用いられています。その仕組みの 1 つとして、AFD のプラットフォーム上にて処理するトラフィックの流量を調整する機能が存在しております。
AFD のサービスは世界中のエッジ サーバーに分散配置されており、複数のお客様でエッジ サーバーを共有して利用するマネージド サービスです。お客様のリクエストが、どのエッジ サーバーへルーティングされるかは、AFD によって動的にコントロールされています。
また、トラフィックの流量を調整する機能が特定のエッジ サーバーで起動した場合は、そのエッジ サーバーにルーティングされた一部のクライアントに対して RST パケットを送信する動作になります。
つまり、お客様の構成した AFD にアクセスを行い、該当のエッジ サーバーにルーティングされてしまった一部のクライアントも RST パケットを受け取る可能性があります。
なお、この仕組みによって、断続的に数分から数十分程度の間、クライアントから AFD への接続に影響を及ぼす可能性があります。
接続の問題を受けるクライアント
TCP RST パケットを受信したクライアントが TCP レイヤー レベルで接続をリトライしない場合は、トラフィックの流量の調整が機能している間は、クライアントから AFD への接続に影響が発生してしまいます。
例えば、アプリケーション システムのフロントとして AFD を使用しており、一般ユーザーが PC 端末やスマートフォンの WEB ブラウザを用いて直接 AFD にアクセスする場合は、一時的に接続エラーになっても、WEB ブラウザにて画面を更新することによって正常に接続できる可能性があります。
一方で、API を処理するようなシステムのフロントとして AFD を使用しており、API を送信するクライアント側で TCP レイヤー レベルで再送処理を考慮していない場合は、RST パケットを受信したあとで AFD への TCP レイヤーでの再接続が実行されずに通信が失敗します。他には、Zabbix などの監視システムにおいて curl コマンドを AFD に送信している場合も同様のことが発生する可能性があります。
リトライ ロジックの実装
一時的な接続の問題をクライアントが処理できるようにするために、AFD に接続を行うクライアント サイドの動作にてリトライ ロジックやサーキット ブレークの実装をご検討ください。これにより、アプリケーション システム上の通信の安定性を向上させることに繋がります。
リトライ ロジックやサーキット ブレークの必要性や実装の概要について記載されている公開ドキュメントやブログ (英語) につきましては、下記の URL に記載がございますので、ご参考になれば幸いです。
Using the Retry pattern to make your cloud application more resilient
詳細な調査が必要なケース
リトライ ロジックやサーキット ブレークを実装しているにもかかわらず、AFD への接続で遅延やタイムアウトなどの問題が、数分程度ではなく長時間にわたって事象が継続している場合は、詳細に調査を行う必要がございますので、サポート窓口までお問い合わせください。
なお、お問い合わせをいただく際には、AFD へ接続を実施している通信状況が分かるネットワーク パケットのキャプチャー ファイルとカスタム ドメインを nslookup コマンドなどで名前解決した結果をサポートまで提供いただくことにより、お客様とサポートとの間でのヒアリングをスムーズに進めることができます。
お手数をおかけいたしますが、下記の手順を参考にネットワーク パケット キャプチャー ファイルの採取及びカスタム ドメインの名前解決結果にご協力いただけますと幸いです。
■ ネットワーク パケット キャプチャー ファイルの採取
【クライアントが Windows OS の場合】
- 管理者権限を持つアカウントでコマンド プロンプトを開きます (UAC が有効の場合には、”管理者として実行” します)。
- コマンド プロンプト上で次のコマンドを実行して、ネットワーク パケットのキャプチャを開始します。
1
netsh trace start capture=yes
- お客様のアプリケーションを配信元として設定している AFD に対し、クライアント上で WEB ブラウザや curl コマンドなどを使用して AFD へリクエストを送って接続問題の事象を再現させます。この操作を 5 秒ほどの間隔をあけて 2 ~ 3 度リクエストを送ってください。
- コマンド プロンプト上で次のコマンドを実行して、ネットワーク パケット キャプチャを停止します。トレース ファイルの収集処理が完了しましたら、コマンド プロンプト上で “ファイルの場所” として表示されている NetTrace.etl ファイル、及び同じフォルダ内の NetTrace.cab の 2 つのファイルを取得します。
1
netsh trace stop
【クライアントが Linux OS の場合】
- sudo 権限を持っているユーザーとしてログインし、次のコマンドを実行し、キャプチャを開始します。
1
sudo tcpdump -s0 -i any -n -w outfile.pcap
- お客様のアプリケーションを配信元として設定している AFD に対し、クライアント上で WEB ブラウザや curl コマンドなどを使用して AFD へリクエストを送って接続問題の事象を再現させます。この操作を 5 秒ほどの間隔をあけて 2 ~ 3 度リクエストを送ってください。
- Ctrl + C でパケットキャプチャを停止します。
- コマンドを実行した場所にある outfile.pcap を取得します。
■ カスタム ドメインの名前解決結果
お手元の端末においてコマンド プロンプトなどを開き、以下のコマンドを実行します。
1 | nslookup <カスタム ドメイン名> |
もしくは
1 | dig <カスタム ドメイン名> |
また、お問い合わせをいただいた後に、担当のサポート エンジニアよりヒアリング シートへの記入をお願いする可能性もございます。その際はご協力の程よろしくお願い致します。
AFD の接続の問題によって大きなサービス インパクトが発生するシステムの場合
AFD はマネージド サービスになるため、場合によっては短期間で完全な対策を講じることができない可能性もあります。
AFD の接続の問題が長時間にわたって継続することによって、お客様のシステムに大きなサービス インパクトが懸念される場合は、お客様にて影響範囲や時間、発生パターンなどに応じてシステムを継続するための代替構成の導入をご検討をお願いする場合があります。
あくまで例としてですが、代替システムの構成例としては、以下のようなパターンがございます。
パターン 1 : AFD を経由しない構成
AFD に登録しているカスタム ドメインの名前解決先を AFD のエンドポイントではなく、オリジンのパブリック IP アドレスや FQDN になるように DNS レコードを更新して、AFD を経由せずに直接オリジンにアクセスします。
パターン 2 : Traffic Manager と Application Gateway を組み合わせた構成
AFD と同じように L7 のリバース プロキシとして動作するサービスに Application Gateway がありますが、リージョン レベルでの冗長性を確保するために AFD をご利用いただいているお客様も多いかと存じます。
複数の Application Gateway を異なるリージョンにデプロイして、Traffic Manager のエンドポイントに Application Gateway パブリック IP アドレスや FQDN を登録し、AFD に登録しているカスタム ドメインの名前解決先を Traffic Manager の FQDN に変更することで、リージョン レベルでの冗長性を確保して継続稼働することが可能になります。
Traffic Manager と Application Gateway を組み合わせた構成については、下記の公開ドキュメントに記載がございますので、ご参考になれば幸いです。
Note
なお AFD とは異なり、Application Gateway ではバックエンドから取得したコンテンツをキャッシュしたり、コンテンツを圧縮してクライアントに配信することはできませんので、その点をご理解いただいたうえで、Application Gateway の使用をご検討ください。
パターン 3 : Edgio SKU の Azure CDN の利用
Azure Front Door と Microsoft Standard SKU の Azure CDN は同じプラットフォーム上で動作しています。一方で、Edgio SKU の Azure CDN は Edgio 社が管理しているプラットフォーム上で動作しているため、AFD にて接続の問題が発生している間、Edgio SKU の Azure CDN にて同一の原因で接続の問題が発生することはありません。
また、AFD で使用しているカスタム ドメインを予め Edgio SKU の Azure CDN に登録いただけますので、予め Edgio SKU の Azure CDN を準備してカスタム ドメインを登録しておくことにより、AFD から Edgio SKU の Azure CDN に切り替えて継続稼働することが可能になります。
なお、Edgio SKU の Azure CDN に固定費用はなくデータ転送量による従量課金制になるため、アクセスが発生しない限りは課金されることはございません。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。