Microsoft Azureで利用できるロードバランサーについて解説

はじめに

システム運用を継続していくうえで負荷を回避する方法、発生した際の対処方法をあらかじめ考えておくことは必要不可欠です。社内で数人しかアクセスしないようなサービスであればまだしも、不特定多数からのアクセスが発生する可能性のあるWebサイトや、多くの従業員を抱える大企業の業務システムであれば尚更です。

負荷分散の仕方は様々あり、その中からシステムとの適性やコスト面を考慮したうえで見合ったものを選定してシステムに導入することとなります。この記事では、Microsoftのクラウドサービスである「Microsoft Azure」で利用できる負荷分散装置「ロードバランサー(Azure LB)」について詳しく紹介していきます。なお、ロードバランサー自体がどのようなものかわからない方に向け、初めにロードバランサー自体についても詳しく解説しています。すでに理解している方は「Microsoft Azureのロードバランサーについて」から読み進めてください。

ロードバランサーとは？

システムに通信の負荷が発生すると、立ち上げているサービスの動作が重くなるだけではなく、最悪の場合は異常終了してしまう可能性があります。普段みなさんが利用しているパソコンでも、多くのアプリを立ち上げ過ぎてサービスが勝手に異常終了してしまった状況に遭遇したことがある人もいるのではないでしょうか。コンピュータが搭載しているCPUやメモリで賄いきれない程の処理が発生すると予期せぬエラーやシステムの停止に繋がり、データの消失・不整合に繋がることがあるため、そのようなリスクを事前に防ぐ必要があります。そのためにはサーバーを複数台構成にしたり、複数台に分けたサーバーにアクセスを分散する仕組みを実装したりして負荷分散を行います。なお、負荷分散のことを「ロードバラシング」と呼ぶ場合もあるのでご注意ください。

ロードバランサーとは、あるアルゴリズムの下で内部・外部からのアクセスを複数台あるサーバーに振り分ける機器やソフトウェア、仕組みのことを指します。インターネットとサーバーを中継するプロキシサーバーの一つ「リバーシプロキシ」として説明されることもあります。これは、ユーザーからのアクセスをロードバランサーが受け、採用されたアルゴリズムに沿って通信を各サーバーに振り分け、それらサーバーからの返答を再びロードバランサーが受け取り、最後にユーザーに返答するという負荷分散の仕組みとなっているためです。

ロードバランサーにはスイッチ機器に横付けする形式を採る「One-Arm」と、通信経路上にロードバランサーを設置する「Two-Arm」があり、前者は、負荷軽減の仕組みやロードバランサー自体によるシステムへの負荷を発生させる原因になりづらい一方で、IP設定の仕組みにより通信経路が把握しづらいというデメリットがあります。後者は、構成がシンプルとなり把握しやすい一方で、拡張性が少なく、ロードバランサー自体の冗長化も必要となるというデメリットがあります。そのため、双方のメリット・デメリットを理解したうえで使い分けることが求められます。

また、ロードバランサーにはプロトコルのレイヤーのうちレイヤー4(トランスポート層)や、レイヤー7(アプリケーション層)を利用するものがあります。レイヤー4の場合はIP、TCP、FTP、UDP、ポートといったレイヤー3(ネットワーク層)とレイヤー4のデータに基づいた負荷分散を行う仕様となっており、レイヤー7の場合はHTTPヘッダやクッキー等の通信データに基づいて負荷分散を行うという違いがあります。なお、プロトコルのレイヤーは「OSI基本参照モデル」として基本情報技術者試験等でも問われる基本的な内容となるため、もし全くピンとこないという場合は、別途勉強しておくことをおすすめします。この記事を読み進めるに当たっては、特に詳しくなくても問題ないのでご安心ください。今回メインで扱う「Azure LB」はこのうち、レイヤー4上で動作するロードバランサーとなります。

負荷分散のアルゴリズム

ロードバランサーでは、あるアルゴリズムの下で負荷分散が行われると前述しましたが、そのアルゴリズムは大きく「ラウンドロビン(Round-robin)」「加重ラウンドロビン(Weighted Round-robin)」「最小接続(Least connections)」「最小レスポンス(Least response time)」の4つに分けられます。ラウンドロビンは仕組みが単純で、あらかじめ登録されたサーバーへ順番にアクセスを振り分ける仕組みです。ラウンドロビンは、名前解決を行うDNSサーバーにも設定が可能で、負荷分散を目的として同じドメインやサブドメインに対して複数のサーバーへ名前解決が行えるようにしておくことを「DNSラウンドロビン」と呼びます。

加重ラウンドロビンは、サーバーの処理能力も加味したうえで処理が多くできる方から順にアクセスを割り当てるラウンドロビン方式の一つです。また、最小接続は、サーバーの負荷状況を見たうえで、接続しているコネクション数が少ない方から動的にアクセスを割り当てる仕組みです。最後の最小レスポンスも、動的にアクセスを割り当てる仕組みですが、その監視対象は応答速度です。応答速度が短いサーバーに優先してアクセスを割り当てます。以上4つの他にも、CPUやメモリといったリソースの使用状況を監視したうえで、使用率が低いサーバーから順にアクセスを割り当てる 「動的比率」がアルゴリズムの一つとして紹介されている場合があります。

ロードバランサーの持つ役割

役割を一言で表すと負荷分散ではありますが、他にも関連した様々な役目を持っているのがロードバランサーです。ロードバランサーによって負荷分散を行うことで、CPUやメモリに負荷がかかりづらくなり、速度の低下を防ぐことができます。常に高速なアクセスが可能なサービスを提供することでユーザーの満足度向上に繋がるだけではなく、SEOにおいても有利となります。

また、障害が発生した場合にも有効です。ロードバランサーの持つ一機能によって、システムダウンしているサーバーへリクエストを送らなくて済むようになります。その結果、たとえシステムの一部で障害が発生していたとしてもユーザー側は普段と何らか変わらずサービスの利用が可能となり、SLA(サービス水準合意)の向上にも繋がることになります。障害ではなく、メンテナンス時に一部サーバーを停止する必要が発生したという場合にもこの仕組みは有効です。

ロードバランサーでは、あるユーザーからのアクセスを意図的に毎回同じサーバーに割り振るということも可能です。これはサービスにおいて、セッションやそれまでの処理状況を維持させておきたいという場合に有効です。この仕組みのことを「パーシステンス」と言います。

このように、ロードバランサーは多数の人がアクセスする大規模システムや、Webサービス等で特に重要な役割を持つ仕組みということがわかっていただけたことでしょう。これまではロードバランサー全体について紹介しましたが、次からは今回メインとなるMicrosoft AzureのAzure LBに焦点を当てて説明を続けます。

Microsoft Azureのロードバランサーについて

Microsoft Azureで提供されているロードバランサーは「Azure Load Balancer」と言い、「Azure LB」と縮めて表記されることもあります。ロードバランサー全体の紹介の際にも述べましたが、レイヤー 4で動作するのでIP アドレスやポート番号の情報により負荷分散を行い、Azure Virtual Machinesという仮想マシンや、Virtual Machine Scale Sets内にある複数のインスタンスへの通信を分散することができます。

負荷分散を行う対象はパブリックロードバランサーとプライベートロードバランサーに分けられ、前者はインターネット上からAzureに対する通信、後者はAzure内部のネットワーク内で発生する通信に対する負荷分散を行います。インターネット上からの通信とは、例えばグローバルIPアドレスを利用して一般に公開されているWebサイトやECサイトへのアクセスを想像するとわかりやすいでしょう。対する内部のネットワークは、企業内だけで利用される業務システム等でプライベートIPアドレスでの通信が基本となります。プライベートロードバランサーは、Azure内、あるいはオンプレミス環境からロードバランサーのフロントエンドへとアクセスする構成になります。

Azure LBでできること

パブリックロードバランサー、プライベートロードバランサーのいずれかで負荷分散ができることはもちろんですが、Azure LBでは「正常性プローブ」によるリソースの監視やポートフォワーディングも可能です。負荷分散した先のサーバーが停止していては元も子もないので、ロードバランサー自身でもTCP、HTTP、HTTPSといったプロトコルを利用して死活監視(システム内のサーバーが動作しているかの確認)をします。正常性プローブとは、リソース状況が問題ないかを精査するという意味になります。Azure LBでは、この監視を実施するためにトラフィックの分散先として「バックエンドアドレスプール」というものを定義したうえで、正常性プルーブにおいてプロトコル、ポート番号、試行間隔、異常の閾値を設定することとなります。プルーブの設定が適切でないと異常が発生していても気づくのが遅くなる可能性があるので様々な状況を考慮して設定し、稼働状況が変化したり設定が妥当ではないことに気付いたりしたのであればチューニングを行う必要も出てきます。

次にポートフォワーディングですが、これはインターネットを経由してあるポートに届いたパケットを事前に設定しているLAN側の機器に転送する仕組みです。外部からの通信を無闇にいくつも受け入れてしまうと不正アクセスの機会を広げてしまいセキュリティ上問題となりますが、ポートフォワーディングを利用すると一つのIPアドレスに付与されたポートをそれぞれ別のサーバーに振り分けることが可能となり、外部との通信を最小限に止めることができます。また、SSLでの暗号化通信が行える他、外部からの直接のアクセスを防ぎたい仮想マシンを隠すことができます。Azure LBでは、パブリックIPアドレスとポート番号を設定しておくことによってポートフォワーディングが可能となります。

Azure LBのプラン

Azure LBにはBasicとStandardの2プランがありますが、Basicは無料で利用可能です。対するStandardは、使った分だけ料金が発生する従量課金制(内部の負荷分散は無料)となっています。Standardにおける料金発生の対象は、ルールの設定数、NAT(ネットワークアドレス変換)、データの処理量等ですが、具体的な料金については変動する可能性があるため、Microsoft Azureの公式サイト内にある「Load Balancer の価格」で確認してください。

両者は無料と有料というだけあり、できること、使える機能に違いがあります。例えば直前に紹介したポートフォワーディングは、Standardプランでのみ利用可能であり、HTTPSを利用した正常性プローブもStandardプランでのみ可能となっています。また、バックエンドアドレスプールに登録できるインスタンス数はBasicで300、Standardで1,000という違いもあります。SLAの保証にも違いがあり、Standardの場合は99.99%が保証されているものの、Basicでは特にこのSLAが適用されていません。

試しに使ってみたいという方は、一度Basicを利用してみて不便に感じることがあったり、利用範囲を拡大したかったりという場合にプラン変更(アップグレード)するのがおすすめです。なお、Basicにおいては2025年9月30日に廃止予定となっていて、それまでにアップグレードが必須となる旨が公式サイト内で公表されていたのでご注意ください。アップグレードを行う際は、IPアドレスを動的→静的に変更し、あらかじめ用意されたPowerShellスクリプトを実行し、アップグレードとトラフィックの移行を行うこととなります。

その他Azureで利用できる負荷分散サービスについて

Azure LB以外に負荷分散が可能なサービスは他に「Front Door」「Application Gateway」「Traffic Manager」の3つがあります。なお、これらを複数組み合わせて負荷分散システムが構成されることもあります。

一つ目のFront Doorは、グローバルロードバランサー、Azure CDN、Azure WAFを統合したサービスとされています。リリース当初はネットワークの入り口で処理を行うだけのエッジサーバーとしての役割に使われる傾向にありましたが、次に紹介するApplication Gatewayと同様にレイヤー7上で動作するだけではなく、同等の機能を有するまでに進化しました。Front Doorはグローバルサービスであるため、クラウド環境とオンプレミス環境間、異なるクラウド環境間での負荷分散設定が可能です。

二つ目のApplication Gatewayは、レイヤー7上でURIパス、ホストヘッダーといったHTTPプロトコルのデータに基づいて負荷分散ができる他、本来Webサーバー側で行われるSSL/TLSによる暗号化通信を肩代わりしてWebサーバーの負荷を軽減する「SSLオフロード」も可能となっています。Azure LBで行える負荷分散はTCP/UDPを対象としたもののみですが、Application Gatewayでは、Webアプリケーションでの通信に対して負荷分散を行うということが可能になります。また、負荷状況によって自動でスケールアップ/スケールダウンする「自動スケーリング機能」があるため、エンジニアがインスタンス数等をあらかじめ設定する必要がなくなります。

三つ目のTraffic Managerは、レイヤー7の中のDNSで動作し、世界各地のAzure環境全体を範囲としてトラフィックを適切に配分しながら高いレベルの可用性、応答性を維持する負荷分散システムです。DNS独自の仕組みがあるためFront Doorのように迅速ではないものの、利用していたサーバーに異常が発生した際は別のサーバーへフェールオーバーしてくれます。トラフィックのルーティングは非常に柔軟な対応が可能で、優先度、パフォーマンス、地理、重み付けラウンドロビン、サブネット、複数値といった要素のいずれか、または複数を考慮してのルーティングが可能です。ジオフェンシングが利用可能なため、アクセス元の地理的リージョンに基づいてユーザーの接続先を意図的にルーティングできることも特徴の一つです。

設定で発生しやすい問題

今回はロードバランサーやAzure LBの概要紹介を主題としているため細かな設定方法については説明を省きますが、最後にAzure LBを利用する際の注意点を紹介しておきます。実際に設定をする際に注意点を抑えているだけでも作業のスムーズさが違ってくるので、ぜひ頭の片隅に入れておいてください。

ロードバランサーのバックエンドプールに仮想マシンの追加が行えない場合があります。仮想マシンはパブリック・プライベートにかかわらず複数のロードバランサーに追加することができないため、誤って同じ仮想マシンを追加しようとした場合にエラーとなります。なお、パブリックとプライベートそれぞれに一つずつ同じ仮想マシンを追加した構成は可能です。また、ロードバランサーと仮想マシンのパブリックIPアドレスの契約プランが異なる場合にも追加ができません。仮想マシンがBasicで、ロードバランサーの方がStandardである場合等が該当しますが、この場合はどちらかの契約に合わせる必要があります。

プライベートのバックエンドプールに追加はできたものの、外部接続不可となるパターンがあります。こういった場合は、追加した仮想マシンにパブリックIPを割り当てるか、外部にあるロードバランサーに同じ仮想マシンを追加する必要があります。

また、バックエンドプール内の仮想マシンからロードバランサーのフロントエンドIPにアクセスできないこともあります。この場合は、プライベートロードバランサー内の仮想マシンからアクセスしていていないかを確認してみてください。このような経路でのアクセスが発生すると送信パケットと受信パケットの不一致が発生するため、プライベートロードバランサーではアクセスができない仕様となっています。解決方法としては、プロキシサーバーを経由させるということが考えられます。

まとめ

ロードバランサーは負荷分散に欠かせない仕組みの一つであること、Microsoft AzureにはAzure LBというロードバランサーがあり、負荷分散の他、ポートフォワーディングやリソース監視等も可能であること、Microsoft Azureには、Azure LB以外にも3つの負荷分散機能があることがわかっていただけたことでしょう。なお、Microsoft Azureの公式サイト内には「負荷分散のオプション」というページがあり、その中に開発予定のシステムにおいてどのような負荷分散サービスが適しているかの判断をサポートしてくれるフローチャートが掲載されています。初めて負荷分散を行うに際して利用するサービスに迷った場合はぜひ参照してみてください。

今回取り上げたAzure LB自体は独自の仕様や設定もありますが、ロードバランサー自体の知識はAzureにかかわらずその他のクラウドサービス、オンプレミス環境でも共通して必要となるため、Azureを使わないプロジェクトに携わることとなったとしてもクラウドエンジニア・インフラエンジニアの方には特に役立つ内容となる可能性が高いです。ぜひ今回の記事をきっかけにAzure LBを使いこなせるエンジニアとなり、そのうえで様々な分野のプロジェクトで役立つ総合的なロードバランサーの知識も深めてみてはいかがでしょうか。