Azureで負荷分散を実現する三つのサービスを取り上げる。「Azure Load Balancer Basic/Standard」「Azure Application Gateway」「Azure Traffic Manager」だ。
このうちAzure Load Balancer Standardは2017年9月にプレビュー提供が始まった新しいサービス。選択肢が増えたので、正しく理解して適切に選択する必要がある。
そこで本稿では、新しいAzure Load Balancer Standardを含むロードバランサーのサービスを解説したうえで、検証として、Azure Load Balancer Standardによる仮想マシンの可用性ゾーン（Azure Availability Zones）を横断した冗長構成、サイジングが必要なApplication Gatewayの性能測定を行う。可用性ゾーンについては後述する。
Azure Load Balancer
仮想マシンのSLAが99.99％に
まずは、Azure Load Balancer、Application Gateway、Traffic Managerという三つのサービスを説明する（図1）。
三つのサービスのうち、Azureのロードバランサーとして基本となるのはAzure Load Balancerだ。BasicとStandardという二つのグレードがあり、前者は無料。そのためまずはAzure Load Balancer Basicで事足りるかどうかを考え、機能が不足する場合にStandardやApplication Gateway、Traffic Managerの利用を検討する。
Azure Load Balancer Basicは無料、Standardは有料（プレビュー期間は無料）という決定的な違いがあるが、機能の大部分は共通である。
Azure Load Balancer Basic/Standardはともに、L4（トランスポート層）の負荷分散サービスである。振り分け対象は、Azure仮想マシンとCloud Servicesに限られるが、ネットワークアドレス変換（NAT）、配下の仮想マシンなどの異常を検知して振り分け先から除外するヘルスチェック機能といったロードバランサーの基本機能を一通り備える。
トラフィックの処理性能はBasicとStandardで同じ。Application GatewayやTraffic Managerと同じく性能が高く、一般的な用途ではキャパシティーを考える必要は無い。
では、BasicとStandardの違いは何か。有料のStandardは、無料のBasicにない機能を提供する。
その一つが、可用性ゾーンを横断した冗長構成だ。可用性ゾーンとは、耐障害性の面で独立性の高いAzureのデータセンター群のこと。各リージョンに複数存在する。
Azure仮想マシンは従来、「可用性セット」と呼ばれる、サーバーラックレベルの冗長構成が可能であり、稼働率のSLAは99.95％。これに対して、可用性ゾーンを横断した冗長構成では99.99％に高まる。可用性の要求レベルが高い場合はStandardを選ぶべきだ。
さらにStandardは、最大1000台の仮想マシンの登録、SYNパケットの数（簡単に言うとTCP接続数）、SNAT接続数、処理したバイト数、処理されたパケット数といった監視データの取得、セキュリティ製品などへの全通信のフォワード（高可用性ポート）といった機能を備える。
Application Gateway
WAFやSSLオフロードが可能
Application Gatewayは、有料のL7ロードバランサー。振り分け対象には、仮想マシンとCloud Servicesはもちろん、プライベート/パブリックIPアドレスによってその他のリソースも指定できる。
NATやヘルスチェック機能などAzure Load Balancerが備える基本機能に加え、SSL処理の代行（SSLオフロード）、リクエストに含まれるURLのパスによって振り分け先を変えるパスベースのルーティング、Webアプリケーションファイアウォール（WAF）、Cookieベースのセッションアフィニティー（スティッキーセッション）などレイヤー7の負荷分散機能を備える。
半面、多機能であるがゆえに処理負荷が掛かり、サイジングが必要だ。Mサイズのインスタンスでどれだけの処理が可能かは、検証2で確かめる。
Traffic Manager
リージョン間で振り分け
Traffic Managerは他二つのサービスと違い、リージョンを横断したトラフィックの振り分けを行う有料のロードバランサーだ。
振り分けにはドメインネームシステム（DNS）を使用。送信元IPアドレスを基に、振り分け先のリージョンを変えたり、障害発生時に別リージョンに切り替えたりできる。振り分け先として、Azure以外のリソースも指定可能だ。
トラフィックを分散するルールは、優先順位（フェイルオーバー）、重み付け（重み付けラウンドロビン）、パフォーマンス（応答時間が短いところ）、地理的（送信元IPアドレスに近いリージョン）の四つがある。
これらは1層目は地理的、2層目は優先順位という具合に、組み合わせて使うことができる。この組み合わせの場合、1層目で送信元IPアドレスに近いリージョンに振り分けたうえで、2層目で日本の中だけは東日本リージョンと西日本リージョンで冗長構成にしてフェイルオーバーする、といった構成が可能だ（図2）。
このほか、地理的分散を行う際にクライアントごとの実際の応答時間を用いる「Real User Measurements」という機能、ユーザーの所在エリア（送信元IPアドレスによる推定）、所在エリアから送信されたトラフィック量、ユーザーが経験した応答時間をビジュアル化する「Traffic View」といった機能が提供されている。Real User MeasurementsとTraffic Viewはどちらも2017年11月10日時点でプレビューだ。
Traffic Managerはリージョン内での負荷分散機能を提供しない。リージョン間だけでなくリージョン内でも負荷分散をする場合は、Azure Load BalancerやApplication Gatewayを併用する。
