Azure Load Balancer Basic vs Standard について
Azure Load Balancer、一般的にはALBと略されているものですが、Skuの１つであるBasic Load Balancerが今から約３年後に廃止される計画にある、っといった通知を受け取っている方もいるでしょう。
既にStandard Load BalancerがGA(General Available)されていますので、そちらを今後はメインで使うよう切り替えてくださいね、という意図でしょうかね。
また、そもそもBasicもStandardもInternal LBとして内部ロードバランサ（Public IP addressを持たない）とした用途で使うパターンと、External LBとして外部ロードバランサ（Public IPを持つ）用途の２パターンありますが、今回のアナウンスではBasic LBの廃止アナウンスとなるので、ILBだろうがELBだろうがBasic Load BalancerのSkuを利用している場合は影響を受ける、となります。
とはいえ３年後までに対応すればよいので、そこまで焦る必要はありませんが、BasicとStandardとではいくつか違いもありますし、ただコストが上がるだけのデメリットなのか、というとそうではない、という点を、おさらいも兼ねて解説しましょう。
まずみなさん１番気にされる点は費用ですよね、きっと。
●費用
【Basic LB】
Basic LBは基本料金無料でInboundのデータ転送料も無料、Outboundのデータ転送料がかかる、というものです。
※LBに限らずAzureはAzureから外に出ていくOutbound転送料は一律でかかります。
（最初の100GBは無料ですが、それを超えると日本リージョンの場合は約15円-16円/GBがかかります。転送料が100GB-10TBの間の場合）
【Standard LB】
Standard LBは基本料金(最初の5ルールまで）がかかりますので、約2,500円-2700円が月額でかかります。
価格—Load Balancer | Microsoft Azure
ほぼ無料で利用できていたものが有償Skuに変えないといけない、という意味ではちょっと懐が痛いところではありますね。
では、有償に見合うメリットはそもそも何か、という点に着目してみましょう。
●機能/スペック
以下にBasicとStandardとの機能比較表がありますので、そちらを参考にしてください。
Azure Load Balancer の SKU | Microsoft Learn
割とインパクトあるかな、という点をピックアップすると、正常性プローブにHTTPSが利用できるというのがStandard LBの良い点でもありますね。SSLオフロードが必要なケースはHTTP/HTTPSに特化したApplication Gatewayの利用を推奨しますが、SSL証明書を使った構成は今や一般的ですので、バックエンド側のVM群に対してHTTPSの通信が正常に200OKのレスポンスを返すかどうかでVMの生死を判定できる、というのは、よりサービスの稼働監視として正確に実装できるかと思います。
あとはSLAが99.99としてついている点や、Azure Monitorの多次元メトリックに対応している点（LB内部の効果測定が可能）なども運用管理の面ではStandardの方が優れているのがわかります。他にも可用性ゾーン(Availability Zone)に対応している点もよいですね。（後述で詳しく記載します）
ただし外部通信においてはSNATするためNAT GatewayやVMに付けたPublic IPなどの構成と併用した際にOutboundのルーティングにおいてどちらが優先されるかなど、ちょっと考慮すべき点はあります。
全体的にBasicよりもStandardの方が機能面でもスケール面でも優れているのがわかるかと思います。
では次は、扱いやすさ、設計のしやすさという点ではどうでしょうか。
●扱いやすさ、設計しやすさ
以下は、東日本リージョンと西日本リージョンで行った複数の冗長・可用性構成に対してStandard LBを適用したパターンのメッシュテスト結果です。
noavailvmというのが可用性セットも可用性ゾーンも適用していないシングルVMです。
availvmは可用性セットを付与したVMです。
azdc1/azdc2は可用性ゾーンを適用しゾーンナンバーを１と２にしているVMです。
つまり全ての線が青色線ですので、VM側は可用性セットがあろうがなかろうが、可用性ゾーンを適用してようがしてまいが、どのような可用性構成であってもちゃんとStanadard LBからの通信および振り分け対象にすることができる、ということがわかります。
LBを使う上で裏側の可用性構成を意識しなくても利用できるのは非常に扱いやすく、設計においても変な罠にはまらない点はとてもよいですね。
一方でBasic LBはどうでしょうか。
パッと見た感じ赤色線（設定不可 or 通信負荷）が目立つことがわかります。
可用性セットが付与されたVMであればシングルでも複数VMでも適用できますが、そうではない可用性構成の場合は設定できるケースとできないケースが複雑になっており、とても扱いづらそうです。当然アーキテクチャを考慮する上でも、バックエンド側の可用性構成に応じてBasicでも稼働可能か否か、といった注意ポイントが発生します。いかにStandard LBが扱いやすく設計しやすいロードバランサーになっているかが一目瞭然でしょう。
最後に。
Standard LBのほうが、より標準的に利用でき、今後の開発にも注力されていくことが機能面、スペック面、扱いやすさなどがわかったかと思います。2500円/月支払う価値があるかどうかはお客様の価値観の差になりますね。
また、本記事では詳しく記載しませんが、Basicを使っている環境からStandardへ切り替える際はいくつか考慮すべき点があります。以下にPowerShellから変更するやり方が記載されていますので、こちらをまずご参考ください。
Basic Public から Standard Public へのロードバランサーのアップグレード - Azure Load Balancer | Microsoft Learn
また、手動で行う場合およびPublic IP addressを変更したくない場合は、まず仮のパブリックIP（Basic)を新規で作成しておき、既存のBasic LBのFront IP構成に設定されている既存のPublic IPを新規で作成したPublic IP basicに変更しておきます。（この時点で既存Public IPはBasic LBとの関連付けから削除されます）次に取り外したPublic IPリソースをBasicのSkuからStandardのSkuへアップグレードします。最後に、手動でStandard LBを作成する際にFront IP構成を設定する箇所があるため、そこで取り外したPublic IPを指定してあげれば、既存のBasic LBで使っていたPubilc IP addressをそのままStandard LBでも使うことができます。ただしこちらはサービスからのアクセスを一時的に停止して行う手順となるため、リアルタイムで切り替えたい場合は新規で作成したPublic IPからの受付を一時的に許可するよう振り分けしているDNS側の振り分け先として登録する必要があるでしょうね。（ちなみにbasic Public IPも廃止予定ですので今後はStandard Public IPを使うようにしましょう）
まぁ廃止が３年後なのでこれからゆっくりと検討・検証して頂ければと思います。
