AzureマルチリージョンでのDR構成をAzure Front Doorにアップグレードしてみる。

どーも。seiです。久々の技術系ネタｗｗｗ

以前の投稿では、Azure Traffic Managerを使ってマルチリージョンのDR（ディザスターリカバリー）構成を構築しました。

コスパ重視でTraffic Managerをかませていましたが、今回はその構成をAzure Front Doorに置き換える手順を提示していきたいと思います。

Azure Front Doorとはなんぞや？という方は以下のサイトでご確認ください。

今回のゴール&前提条件

今回のゴールは以下の構成図のような感じです。前回のDR構成を構築したところとの違いはTraffic ManagerがAzure Front Door(以降AFD)に置き換わるだけですので、それ以外の部分は今回は割愛させていただきます。前回の投稿を元に構築ください。

また、Azure Static Web Appsをフロントエンドとして追加しています。これはプライマリーリージョンにリソース作成していますが、グローバルに展開されるリソースなため既定でリージョン障害に対応しているので、リソースをプライマリーリージョンに1つだけデプロイします。

今回デプロイするAzure Functionsも自身のリソース名を返すだけの単純なものにして実行させます。ご自由に振る舞いを実装していただければと思います。

簡単に説明すると、クライアントからのリクエストをまずAFDが受けてトラフィックを振り分けます。サイトへのアクセス（/*）の場合はフロントエンドに振り分けます。フロントエンドはバックエンドに対してリクエストを投げますが、AFDを介してバックエンドのAzure Functionsにリクエスト(/api/*)が送信される感じになります。その時、プライマリーリージョンで障害が発生している場合は、フェールオーバーを行い、セカンダリーリージョンのAzure Functionsにリクエストが自動的に送信される構成を実現していきたいと思います。

【前提条件】

• フロントエンドリソース（Azure Static Web Appsとか）がデプロイ済み
• バックエンドAzure Functionsが2つのリージョンにデプロイ済み
• （Azure Functionsの認証方法＝Functionの場合）2つのリージョンにデプロイしたAzure Functionsの関数キー（ホストキー）が共通化されている。
• DNSレコード編集可能なカスタムドメインを保持している

上記のような前提条件のもと進めていきたいと思います。

Azure Front Doorの構築手順

AFDリソースの作成

まずはAzure Front Doorリソースをデプロイしていきます。マーケットプレイスから「Front Door」あたりで検索してもらえば出てくるはずの「Front Door and CDN profiles」を選択します。

Front Door and CDN profilesの「作成」ボタンをクリックします。

以下の画面が表示されます。本当は空っぽのところにいろいろ追加していこうと思ったのですが、なんかうまくできなかったので、上段の「Azure Front Door」を選択（これはマストですね）し、下段は「カスタム作成」を選択後、「フロント ドアの作成を続行する」をクリックします。

以下の画面で、サブスクリプション、リソースグループなどを選択したら名前を入力し課金レベルを選択します。今回は「Standard」ティアを選択します。「次へ：シークレット」ボタンをクリックします。ちなみにStandardとPremiumの違いは、ボット対策やプライベートリンクなど追加のセキュリティ機能があるかないかとかですかね。

以下の画面では、持ち込みのSSL/TLS証明書を追加することができますが、Azure Front Doorが用意して自動で更新してくれる無料のマネージド証明書が利用できますので今回はパス。「次へ：エンドポイント」をクリックします。

エンドポイントの作成

ここからがAFD設定の本番です。AFDの設定は「エンドポイント」、「ルート」、「配信元グループ」がキモとなってきます。

今回はリソース作成時に設定していこうと思いますが、あとで設定することも可能です。まずはエンドポイントを作成していきますので、「エンドポイントの追加」ボタンをクリックします。

「エンドポイントの追加」パネルが表示されるので、エンドポイント名を入力します。今回は「dr-demo」というエンドポイント名にします。すると自動的にエンドポイントのホスト名が生成されます。よろしければ「追加」をクリックしましょう。

ルートの作成

エンドポイントが作成されると以下の画面になります。作成されたエンドポイントのホスト名は赤下線で示す場所に表示されます。エンドポイントの配下にルートを追加していきましょう。「ルートの追加」をクリックします。

カスタムドメインの割り当て

ルートの追加ブレードが表示されます。まずはAFDにカスタムドメインを追加したいと思うので、「新しいドメインの追加」をクリックします。ここでカスタムドメインを追加する必要はなく、もちろん後から設定可能です。

ドメインの追加ブレードが表示されるので、以下の表のとおり設定して「追加」をクリックしましょう。ちなみに今回はエックスサーバーで管理している当サイトのドメインにサブドメインを追加してAFDのカスタムドメインとして利用するテイで進めます。

設定項目	設定値
ドメインの種類	Azure以外の検証済みドメイン
DNSの管理	その他すべてのDNSサービス
カスタムドメイン	（自身で管理しているAFDに割り当てるドメインを入力）
証明書の種類	AFDマネージド（推奨）
TLSポリシー	よしなに。最新でいいと思う。。。

カスタムドメインの追加が完了すると、ルートの追加ブレードに戻ってくるので、ルート名を入力し、先ほど追加したカスタムドメインにチェックを付け、デフォルトのドメインは利用しないのでチェックを外しましょう。カスタムドメインはあとの手順で検証作業が必要になります。次に配信元グループを追加するので、「新しい配信元グループを追加する」をクリックします。

配信元グループの作成

［配信元グループの追加］パネルが表示されるので、適当な名前を入力しましょう。今回はフロントエンドの配信元とするので、「drdemo-frontend-group」としました。次に「配信元の追加」をクリックします。

［配信元の追加］パネルが表示されます。フロントエンドのアプリを配信元として設定していくので、［配信元の種類］を「静的WEBアプリ」、［ホスト名］にフロントエンドアプリとして利用するSWAリソースを指定し、「追加」ボタンをクリックしましょう。

［配信元グループの追加］パネルに戻り、配信元のホスト名としてフロントエンドアプリが表示されて有効になっていればOKです。「追加」をクリックしていきましょう。

［ルートの追加］ブレードに戻ってきます。配信元グループとして先ほど作成した配信元グループ名がセットされていることを確認します。あ、「一致するパターン」ですが、フロントエンドアプリとしてすべてSWAに流すので、ここでは「/*」のままでOKです。ご自身の環境に合わせてご対応ください。また、CDNとしてキャッシュを利用する方も「キャッシュを有効にする」をよしなに。「追加」ボタンをクリックします。

［Front Doorプロファイルの作成］画面まで戻ってきました。作成したルート、配信元グループ、ドメインが表示されているのが確認できます。フロントエンドとしての設定は完了したので、あとはバックエンドのルートを追加しようと思ったのですが、なぜか更なる「ルートの追加」が出来んかった・・・(。´･ω･)?なぜ？ちょっとわからないので、バックエンド用のルートはリソース作成後の画面から行っていきたいと思います。あ、あと今回はWAF機能は利用しませんので割愛します。「確認および作成」ボタンをクリックしましょう。

「作成」をクリックすればリソースの作成が始まります。

無事AFDリソースのデプロイが完了しました。それではリソース作成時にはできなかったバックエンド用のルート作成を追加で行っていきましょう。「フロントドアマネージャー」を選択します。

フロントドアマネージャーからのルート追加

［フロントドアマネージャー］ブレードが開きます。基本的な操作はフロントエンド用ルートを作成したリソース作成時の操作と一緒です。エンドポイントに対して「ルートの追加」を行っていきます。

ルートを追加していきます。バックエンド用ルートということがわかるような名前を付けましょう。あ、ルートのスペル間違ってますね。正しくはrouteですね。お気になさらずｗ

ドメインはリソース作成時に追加したカスタムドメインを選択します。

以下のエラーが表示されます。要するに「どっちのルートに行くかの判断ができない同じURLパターンが設定されているよ」とのことですので、フロントエンド用ルートで設定済みの「/*」を削除して、Azure Functionsのエンドポイントとなる「/api/*」を追加しましょう。（直接「/*」を「/api/*」に変更してももちろんOK）

次にバックエンド用の配信元グループをこのルートに追加します。「新しい配信元グループを追加する」をクリックします。

名前を入力して「配信元の追加」をクリック。

［配信元の追加］パネルが表示されるので、バックエンドAzure Functionsを設定するので、［配信元の種類］を「App Services」、［ホスト名］にまずはプライマリーリージョンのAzure Functionsリソースを指定し、「追加」ボタンをクリックしましょう。

プライマリーリージョンのAzure Functionsが配信元として追加されました。同様に「配信元の追加」を行い、今度はセカンダリーリージョンのAzure Functionsを配信元として追加しましょう。

［配信元の種類］を「App Services」、［ホスト名］にセカンダリーリージョンのAzure Functionsリソースを指定します。また、優先順位をプライマリーリージョンで設定されている優先順位より大きな値（今回は「2」）に変更後、「追加」ボタンをクリックします。

配信元グループとして２つのリージョンにあるAzure Functionsが追加されました。優先順位値が小さいホストに優先的にトラフィックが割り当てられる形で負荷分散が行われます。

ルートの追加ブレードに戻ってきました。バックエンド用の配信元グループが設定されているのを確認し、「追加」をクリックしましょう。

フロントドアマネージャーに戻ってきました。エンドポイントにフロントエンド用とバックエンド用の２つのルートが存在するようになっていればOKですね。最後に追加したカスタムドメイン追加に関する手順を行っていきたいと思います。「ドメイン」をクリックしてください。

カスタムドメインの所有権確認＆エンドポイントのリダイレクト設定

カスタムドメインは追加しただけではそのまま利用できません。ご自身が所有するドメインであるかどうかの検証と、カスタムドメインでアクセスされたときにAFDエンドポイントへリダイレクトされるようにDNSレコードにCNAMEレコードの追加が必要です。

カスタムドメインの所有権確認

［ドメイン］ブレードで［検証の状態］を確認すると、所有権の検証が済んでいないと「保留中」となっていると思います。「保留中」をクリックします。

以下のパネルが表示されるので、「レコード名」、「レコードの値」を、ドメインを管理しているDNSプロバイダーのDNSレコード管理画面で追加してください。自分はエックスサーバーですので、エックスサーバーサーバーパネルの［ドメイン］－［DNSレコード設定］よりTXTレコードとして追加しました。

DNSレコードを追加した後、しばらく（結構待つと思う・・・）すると検証の状態が「承認済み」になればカスタムドメインの所有権の確認はOKです。ですがまだ「DNSの状態」が「CNAMEまたはエイリアスレコードが検出されていません」となっているのでこれを解決してAFDの導入が完了します。

カスタム ドメインとAzure Front Doorエンドポイントとの関連付け

最後の手順です。カスタムドメインでアクセスされたときにAFDにリダイレクトされるように設定していきたいと思います。

まずはAFDのフロントドアマネージャーにアクセスし、AFDのエンドポイントをコピーします。

次にドメインのDNSプロバイダーの管理画面よりCNAMEレコードとしてコピーしたAFDのエンドポイントを登録してください。自分はエックスサーバーですので、こんな感じ。

こちらもそこそこ結構な時間かかると思いますが、DNSの状態が「トラフィックは安全に配信されます」になれば無事Azure Front Doorのセットアップ完了です。お疲れさまでした！！

Azure Front Doorのセットアップが完了しました。これが今回の最終形態です。

Azure Front DoorでのDR構成が機能しているか確認

それでは最後に稼働確認を行っていくのですが、まずはバックエンドAzure FunctionsのCORS設定をカスタムドメインを受け入れるように忘れずに変更しておきましょう。プライマリー、セカンダリー、両方ともね。また、プライマリーとセカンダリーのAzure Functionsの認証がFunctionsの場合はアプリキーの共通化も忘れずに行っておいてください。

では、まずは通常パターン。プライマリーリージョンがピンピンしている場合。ちゃんと「primary」が返ってきているのでプライマリーリージョンのAzure Functionsが呼び出されているのが確認できます。

それでは次にリージョン障害が発生したシチュエーションを。プライマリーリージョンのAzure Functionsを停止させます。

プライマリーリージョンのバックエンドが停止しました。

この状態でフロントエンドStatic Web Appsを起動してリクエストをバックエンドに送信してみます。おお！「secondary」が返ってきているのでちゃんとセカンダリーリージョンのバックエンドにフェールオーバーされたことが確認できました！素晴らしい(*^^)v

最後に停止させていたプライマリーリージョンのAzure Functionsを再開させてもう一度フロントエンドを実行します。OK！！ちゃんとプライマリーリージョンのバックエンドにフェールバックされました。いいね～～～～。

さいごに

Azure Front Doorの構築は、一見複雑に見えるかもしれませんが、エンドポイント・ルート・配信元グループの関係性をしっかり把握していれば、実は非常にシンプルかつ論理的です。今回の投稿ではCDNやWAFなどのセキュリティ・高速化機能には触れていませんが、AFDはそれらを必要に応じて柔軟に組み合わせられる点が大きな魅力です。

価格面ではTraffic Managerより大分お高めですが、WAFによるセキュリティ強化、CDNによる高速配信、Private Linkによる安全なバックエンド接続など、トラフィック分散だけにとどまらない多機能性がAFDの強みです。さらに、AFD経由以外のアクセスを遮断する制御も可能で、

バックエンドをパブリックに晒すことなく、安全な構成を実現できる！すごくいいっ！！

おまけに、Cookieを扱っているのならサードパーティCookieとして最近のブラウザーのCookie規制強化の影響も受けることなくバックエンドとフロントエンドのカスタムドメインを統一する手間も省ける！！ディ・モールト、ディ・モールト、良いぞッ！！

グローバルな可用性、セキュリティ、パフォーマンスを一手に担えるこのサービスは、モダンなWebアーキテクチャの中核として非常に優秀だと感じています。

以上、DR構成時におススメのAzure Front Doorに変えてみた編でした！！

システムエンジニアランキング

にほんブログ村