記事の要約
- Azure Front Doorは、サービスを提供するためのエントリポイントを一元管理してくれる便利な機能
- 裏のシステムの有効無効切り替えもダウンタイムなしで即時反映！
- ... と公式ドキュメントには書いてあるが、実際は10分〜かけて徐々に反映されている
なので、即時反映されない前提での利用方法を検討する必要がある
Azure Front Doorとは
Azure Front Door は、Microsoft グローバル エッジ ネットワークを使用して、セキュリティで保護された高速でスケーラビリティの高い Web アプリを作成するためのスケーラブルなグローバル エントリ ポイントです。 Front Door を使用すると、グローバルなコンシューマー アプリケーションやエンタープライズ アプリケーションを、Azure を介して世界中のユーザーに発信するコンテンツを備えた、堅牢で高パフォーマンスのパーソナライズされた最新のアプリケーションに変えることができます。
ざっくりいうと、Azureのリソースへのアクセスを集約し、様々な運用に必要な用途を1箇所でまとめようという機能です。
- Firewallのようなセキュリティ機能
- CDN機能
- ロードバランサー
- 死活監視・冗長性の担保
etcの機能を有している便利なやつです
やりたかったこと
アイディア
リリース時にお客様への影響なく、かつrollbackも簡単にできるように以下構成を作りたい
通常時:
- Frontend contentsをAzure Storage Account AとBにリリースしておく
- Azure Front DoorはStorage A, B両方を有効にする
リリース時:
- Storage AのFrontend contentsを更新する
- Azure Front Doorのキャッシュが効いているのでまだ古いcontentsのまま
- Azure Front DoorのStorage B設定を無効にし、キャッシュを消す
- 設定が即時反映され、キャッシュが消えるのでここから新しいFrontend contentsになるはず
- テスト
- 問題なければStorage Bも更新し有効化
- 問題あればStorage Bを更新せず有効化、Storage Aを無効化した上で前のcontentsに戻す
Microsoftのよくある質問より、Azure Front Door のデプロイにはどのくらい時間がかかりますか? Front Door は更新中に動作しますか?の回答
ルートやバックエンド プールなどに対する更新はシームレスであり、ダウンタイムは発生しません (新しい構成が正しい場合)。
即時反映されそうな感じするんだけど、これは意味が違いました。
実際に公式に問い合わせたところ、これは設定変更中に通信が切れたりすることはないという意味であり、反映の即時性の話ではないとのことでした。
実際はどうだったか？
Microsoftの回答
Microsoftサポートからの返信ももらえたので、先に結論を記載します
問合せでの回答も、反映に10分程度かかる という回答でした。
試してみた
設定手順
- Azure PortalからAzure Storage Accountを作成
- コンテナーを追加し、ファイルをアップロード
- 上記を2つ用意する
- Azure Front Door を作成
- ドメインを設定
- バックエンド プールを追加し、バックエンドを追加→3で作ったStorage Accountを指定する
- 他はデフォルトのまま追加
- ルーティング規則で、上記バックエンド プールを指定
- 作成
*Azure Front DoorはStandard/Premiumと書いていない方での手順です。Standardの方もほぼ同じ流れ
切り替え手順
- 有効無効の切り替え
- →バックエンド プール内のバックエンドの設定からできます。
- キャッシュの削除
- Front Door デザイナーの消去からできます
結果
何度やってもすぐには有効無効が反映されませんでした。
- キャッシュ削除後のアクセスでバックエンドへリクエストが行っていることは確認
- Azure Front Doorの概要や、Storage Accountの概要→監視でアクセスが確認できます
- curlで10秒毎にアクセスを繰り返してみると、大体10分前後で有効無効が切り替わっていました
似たような事例
30分以上反映にかかることがあるという話
こちらも20-30分かかっているという話をあげていました
現状はAzure Front Doorの設定変更は時間がかかるものとして扱うしかなさそうです
単純に反映に時間がかかるだけ、その間昔のcontentsにアクセスできるので大きな問題にならないだろうと考えれば、まあいいかって感じなのかな。。。
代替策
Traffic ManagerとAzure CDNの組み合わせで対応するという案が公式ドキュメントで提示されています(未実証)。
私自身実現はできていないのですが、公式で記載されているものなので実現は可能なはずです
メリット
Traffic ManagerはDNS設定の切り替えだけなので、Azure CDNも自前で立てたものを使うため、Azure Front Doorと比べて裏側の構成が把握できます。
また、Traffic Managerの切り替えはDNSでの切り替えになるため、設定対象が少ない分より早い設定反映が期待されます
(Azure Front Doorも内部的にTraffic Managerを使っているようなので、Azure Front Doorの構成を一部切り出して自分で作ってるような状態だと思います)
デメリット
一番のデメリットは、自分で構成を構築しない点です (私もこれが詰まってAzure Front Doorを試していました)
- 自前でAzure CDN, Traffic Manager, Custom DomainとDNS設定を行わないといけない
- アクセス元がTraffic Managerになるため、うまく使われる証明書を設定しないとHTTPSアクセスできない
特に2番目が今解決できていないです。何も考えず構成を組んでいくと、名前解決はできるんですがHTTPSアクセス時に以下のようなエラーが出ます。
SSL: no alternative certificate subject name matches target host name
利用される証明書がどれかを把握して、対象の証明書に対して自前で正しくCN名を設定してあげないといけないと予想しています
また、それ以外にも以下のデメリットがあります。
- Azure CDNのcustom domainやAzure DNSの設定が反映されるのに時間がかかる
- 私が試した時は証明書がポータル上で有効になるまでに1日以上かかった
- さらに
openssl s_client -connectで接続が確認できるまでに1日前後かかった
設定わからん、詰んだ
→次の日に相談会を設定
→これができなくて、、あれ？なんかできるようになってますね
を何度か繰り返して、やっと名前解決できるようになり、Azure CDNも単独でCustom DomainでHTTPS通信できるようになり、
といつ反映されるのかわからない設定を繰り返した上で証明書問題にぶち当たり、と単純に反映までにも数日を要することがあるのがきついです