毎週Azureのことを紹介しているAzureリレー記事になります。前回は多田さんが「ストレージアカウント間でデータのコピーをしよう(AzureCLI) #Azureリレー」でBlobストレージでデータを同期するコマンドを紹介してくれています。それでは早速ですが本題に入っていきましょう。リージョン間ロードバランサーがプレビューで提供されました。Azure Standard Load Balancerのサポート範囲が増えたようですね。Azure Fridayの「Using Azure Cross-region Load Balancer for high availability scenarios」で紹介されていました。この記事では、リージョン間ロードバランサーが提供されたのでAzureの負荷分散の振返りと新しいロードバンサーをどのように使うかのアイデアを解説していきます。

今までどのような負荷分散サービスが提供されていたか？

今まで負荷分散サービスは、グローバル（リージョン間）ではFrontDoor、TrafficManager、リージョン内ではApplication Gateway、LoadBalancerを用途に応じて利用されていました。この辺の詳細はAzure アーキテクチャーセンターで「Azure 負荷分散を理解する」に丁寧にまとまっています。

アーキテクチャーセンターからの抜粋になりますが、一番シンプルな使い分けは以下の通りです。

こちらのAzure Load Balancerにグローバル（リージョン間）が追加されたことになります。負荷分散を検討するときのポイントは、（１）どの範囲を振分けるのか（グローバル：データセンターごと振り分けを行うのか、リージョン：データセンター内で振り分けを行うのか）と、（２）どういう通信を負荷分散するのか（推奨されるトラフィックの種類：HTTPやHTTPSを振分けるのか、Socket通信を振分けるのか。参考）の２つです。また、それぞれのサービスにより、料金の違いもありますのでコスト面を考慮する、ルーティング方式やWAFの機能を利用するかどうかも考えて決めていきます。詳細は「ディシジョンツリー」をご確認ください。

今回はこのAzure Load Balancerがリージョン内だけでなく、グローバル（リージョン間）にも対応しましたということなのでさっそく中身を見ていってみましょう。

リージョン間ロードバランサーの特徴は？

Azure Fridayで表示されたスライドがわかりやすかったのでこちらをベースに解説していきます。

Layer 7 global load balancerが、Front Door(ほんの一部の機能だけ書いてある気がします)になります、DNS-based Load Balancerが、Traffic Managerになります。Azure Cross-region Load Balancerがこれから紹介するサービスになります。それではプロットに従って見ていきましょう。

・Layer4(TCP/UDP)

レイヤー4のロードバランサーなので、TCP/UDPを通してくれるのでHTTP以外の通信に利用できます。
Front DoorやApplication Gatewayは、レイヤー7のサービスのためHTTP(S)に限定されます。

・High performance routing

安定しており、負荷に強く、処理時間が短いです。ポータルやCLIでは一つのリソースに見えますが、Azureの初期の頃から、しっかりソフトウェアとして開発されてきているので安心して利用できます。ロードバランサー自体の仕組みは「Ananta: Azure を支えるステートフル L4 ロードバランサー」でよくまとめられていたので仕組みに興味があるかたは見てみて下さい。リージョン間ロードバランサーでは、geo 近接の負荷分散アルゴリズムが利用されます。利用者は地理に一番近いリージョンに デプロイされたアプリケーションに接続されます。

・Fast Failover

バックエンドに設定しているサービスが停止した場合の切替が早いということです。ロードバランサーは後ろにあるリージョンのアプリケーションに対して20秒ごとに可用性をチェックし、可用性が0になるとすぐに障害リージョンへの振り分けを停止し、正常なリージョンのみに振り分けます。また、クライアントは同じIPアドレスを参照していればよいだけなので振り分け時の考慮はほとんど不要です。

・Easy IP Management

提供されるIPアドレスは静的アドレスとして固定されるので、動的に変わることはありません。

どういった場合に利用するとメリットがありそうか？

・素早いフェイルオーバー（DNSベースの負荷分散との比較）

今までHTTP(S)以外の通信をグローバルで負荷分散しようとすると、TrafficManagerを利用してきました。TrafficManagerは、DNSベースなのでコストも低く抑えられ、対障害性も高く良いサービスなのですが、DNSベースであることが故に困った自体を引き起こす事があります。

現在のWebやネットワークの仕組みは適切にデータを一時保存（キャッシュ）することで、繰り返し処理を減らして負荷を軽減しています。DNSは基本的にこのキャッシュをベースに処理が動作します。例えばブラウザやアプリケーションは、インターネットへアクセスするときにDNSへアクセスしドメイン名をIPアドレスに変換します。ブラウザやDNSは、この一度解決したIPアドレスをキャッシュして利用します。アプリケーションがサービスと通信する場合TrafficManagerで向き先を変えてもこのキャッシュが邪魔をしてスムーズに切替が行われないケースがあります。クライアント側のアプリケーションがSingle Page Applicationだったり、動画視聴するためのプレイヤーソフトウェアだとこのへんが効いてきます。

この切替（フェイルオーバー）をロードバランサーに任せられれば、クライアントが接続するIPアドレスは変わらずバックエンドにあるサービスへの接続が切り替わるためブラウザやアプリは何も意識することなくサービスのフェイルオーバーが瞬時に行えます。

・コストのメリット（レイヤー7ベースの負荷分散との比較）

レイヤー７ベースの負荷分散は、FrontDoorがリージョン間では利用できます。FrontDoorには、負荷分散だけでなくWAF、CDN、パスベースルーティング、仮想ネットワーク統合など様々なサービスが組み合わされた全部入りネットワークサービスです。非常に便利で部品が少なくることで構成がシンプルになるので使い勝手がいいですが、その分費用はかかります。

Azure Load Balancerは、負荷分散に特化しているのでコストが抑えられます。ただ、この後ろに、DDos対策などセキュリティの機能を負荷していくと費用は変わってきますのでご注意下さい。

※2021年4月13日時点　Azure Front Door は、処理コストにアウトバウンド費用を記載（他にも費用かかります）　Azure Load Balancerは、振り分けルールが増えなければこれ以上コストかかりません。　詳細は、Azure Front Door費用、Azure Load Balancer費用をご確認ください。

リージョン間ロードバランサーの制限事項は？

最後に制限事項を見ていきましょう。一番大きいのはやはりまだプレビューだということです。SLAが無いためなにか問題があってもサポートが受けられません。また、日本で利用する場合は西日本リージョンではまだサポートされておりません。

※2021年4月13日時点のドキュメント上の制約事項
・リージョン間のフロントエンド IP 構成はパブリックのみです。 現在、内部フロントエンドはサポートされていません。
・リージョン間ロード バランサーのバックエンド プールにプライベートまたは内部ロード バランサーを追加することはできません
・リージョン間 IPv6 フロントエンド IP 構成はサポートされていません。
・現在、正常性プローブを構成することはできません。 既定の正常性プローブによって、リージョン ロード バランサーに関する可用性情報が 20 秒ごとに自動的に収集されます。
・Azure Kubernetes Service (AKS) との統合は現在使用できません。 AKS クラスターがバックエンドでデプロイされている Standard ロード バランサーを使用してリージョン間ロード バランサーをデプロイした場合、接続が切断される場合があります。

リージョン間ロード バランサー (プレビュー)

まとめ

今回はリージョン間ロードバランサーについて解説してきました。もともとリージョン内で利用されていたレイヤー４のロードバランサーがリージョン間の通信に対応するようになりました。メリットは、Azure初期から培われてきた負荷耐性と安定性に加えて、TCP/UDPといったレイヤー4の通信をサポートしていること。また、費用を抑えた上で、素早いフェイルオーバーが可能となっていることを説明してきました。ただし、まだこちらのサービスはプレビューのためSLAがなかったり、サポートが受けられなかったり、制限がまだまだあったりしますので本番での利用は一般公開されてからにしましょう。読んで頂きありがとうございました！