Skip to content

Commit

Permalink
Merge pull request #415 from kazuma911/master
Browse files Browse the repository at this point in the history
タイポの修正と Note の追加
  • Loading branch information
kazuma911 authored Feb 1, 2024
2 parents 8c4b275 + 4d9bacb commit b54ffbf
Showing 1 changed file with 13 additions and 2 deletions.
15 changes: 13 additions & 2 deletions articles/network/afd-connection-issue.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ tags:
- AzureCDN
---

こんにちは。Azure テクニカル サポート チームです
こんにちは。Azure テクニカル サポート チームの石原です

本ブログでは、Azure Front Door 及び Microsoft Standard SKU の Azure CDN (以降は AFD と記載致します) において起こりうる接続の問題やお客様で対策可能な内容などについてご案内致します。

Expand All @@ -23,12 +23,14 @@ AFD のサービスは世界中のエッジ サーバーに分散配置されて
なお、この仕組みによって、断続的に数分から数十分程度の間、クライアントから AFD への接続に影響を及ぼす可能性があります。



## 接続の問題を受けるクライアント
TCP RST パケットを受信したクライアントが TCP レイヤー レベルで接続をリトライしない場合は、トラフィックの流量の調整が機能している間は、クライアントから AFD への接続に影響が発生してしまいます。
例えば、アプリケーション システムのフロントとして AFD を使用しており、一般ユーザーが PC 端末やスマートフォンの WEB ブラウザを用いて直接 AFD にアクセスする場合は、一時的に接続エラーになっても、WEB ブラウザにて画面を更新することによって正常に接続できる可能性があります。
一方で、API を処理するようなシステムのフロントとして AFD を使用しており、API を送信するクライアント側で TCP レイヤー レベルで再送処理を考慮していない場合は、RST パケットを受信したあとで AFD への TCP レイヤーでの再接続が実行されずに通信が失敗します。他には、Zabbix などの監視システムにおいて curl コマンドを AFD に送信している場合も同様のことが発生する可能性があります。



## リトライ ロジックの実装
一時的な接続の問題をクライアントが処理できるようにするために、AFD に接続を行うクライアント サイドの動作にてリトライ ロジックやサーキット ブレークの実装をご検討ください。これにより、アプリケーション システム上の通信の安定性を向上させることに繋がります。
リトライ ロジックやサーキット ブレークの必要性や実装の概要について記載されている公開ドキュメントやブログ (英語) につきましては、下記の URL に記載がございますので、ご参考になれば幸いです。
Expand All @@ -38,11 +40,13 @@ TCP RST パケットを受信したクライアントが TCP レイヤー レベ
[Using the Retry pattern to make your cloud application more resilient](https://azure.microsoft.com/en-us/blog/using-the-retry-pattern-to-make-your-cloud-application-more-resilient/)



## 詳細な調査が必要なケース
リトライ ロジックやサーキット ブレークを実装しているにもかかわらず、AFD への接続で遅延やタイムアウトなどの問題が、数分程度ではなく長時間にわたって事象が継続している場合は、詳細に調査を行う必要がございますので、サポート窓口までお問い合わせください。
なお、お問い合わせをいただく際には、AFD へ接続を実施している通信状況が分かるネットワーク パケットのキャプチャー ファイルとカスタム ドメインを nslookup コマンドなどで名前解決した結果をサポートまで提供いただくことにより、お客様とサポートとの間でのヒアリングをスムーズに進めることができます。
お手数をおかけいたしますが、下記の手順を参考にネットワーク パケット キャプチャー ファイルの採取及びカスタム ドメインの名前解決結果にご協力いただけますと幸いです。


#### ■ ネットワーク パケット キャプチャー ファイルの採取
【クライアントが Windows OS の場合】
1. 管理者権限を持つアカウントでコマンド プロンプトを開きます (UAC が有効の場合には、"管理者として実行" します)。
Expand All @@ -57,6 +61,7 @@ netsh trace stop
```
トレース ファイルの収集処理が完了しましたら、コマンド プロンプト上で "ファイルの場所" として表示されている NetTrace.etl ファイル、及び同じフォルダ内の NetTrace.cab の 2 つのファイルを取得します。


【クライアントが Linux OS の場合】
1. sudo 権限を持っているユーザーとしてログインし、次のコマンドを実行し、キャプチャを開始します。
```Bash
Expand All @@ -66,6 +71,7 @@ sudo tcpdump -s0 -i any -n -w outfile.pcap
3. Ctrl + C でパケットキャプチャを停止します。
4. コマンドを実行した場所にある outfile.pcap を取得します。


#### ■ カスタム ドメインの名前解決結果
お手元の端末においてコマンド プロンプトなどを開き、以下のコマンドを実行します。
```Bash
Expand All @@ -79,6 +85,7 @@ dig <カスタム ドメイン名>
また、お問い合わせをいただいた後に、担当のサポート エンジニアよりヒアリング シートへの記入をお願いする可能性もございます。その際はご協力の程よろしくお願い致します。



## AFD の接続の問題によって大きなサービス インパクトが発生するシステムの場合
AFD はマネージド サービスになるため、場合によっては短期間で完全な対策を講じることができない可能性もあります。
AFD の接続の問題が長時間にわたって継続することによって、お客様のシステムに大きなサービス インパクトが懸念される場合は、お客様にて影響範囲や時間、発生パターンなどに応じてシステムを継続するための代替構成の導入をご検討をお願いする場合があります。
Expand All @@ -88,12 +95,16 @@ AFD の接続の問題が長時間にわたって継続することによって
AFD に登録しているカスタム ドメインの名前解決先を AFD のエンドポイントではなく、オリジンのパブリック IP アドレスや FQDN になるように DNS レコードを更新して、AFD を経由せずに直接オリジンにアクセスします。

#### パターン 2 : Traffic Manager と Application Gateway を組み合わせた構成
AFD と同じように L7 のリバース プロキシグとして動作するサービスに Application Gateway がありますが、リージョン レベルでの冗長性を確保するために AFD をご利用いただいているお客様も多いかと存じます。
AFD と同じように L7 のリバース プロキシとして動作するサービスに Application Gateway がありますが、リージョン レベルでの冗長性を確保するために AFD をご利用いただいているお客様も多いかと存じます。
複数の Application Gateway を異なるリージョンにデプロイして、Traffic Manager のエンドポイントに Application Gateway パブリック IP アドレスや FQDN を登録し、AFD に登録しているカスタム ドメインの名前解決先を Traffic Manager の FQDN に変更することで、リージョン レベルでの冗長性を確保して継続稼働することが可能になります。
Traffic Manager と Application Gateway を組み合わせた構成については、下記の公開ドキュメントに記載がございますので、ご参考になれば幸いです。

[Azure で負荷分散サービスを使用する](https://learn.microsoft.com/ja-jp/azure/traffic-manager/traffic-manager-load-balancing-azure)

> [!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 に切り替えて継続稼働することが可能になります。
Expand Down

0 comments on commit b54ffbf

Please sign in to comment.