こんにちは！SREとして日夜クラウドとコンテナの海を泳ぎ回っているインフラエンジニアです。AWSやGCPといったメガクラウドの世界へようこそ！
インフラの世界に足を踏み入れると、必ずと言っていいほど直面するのが「ロードバランサー（負荷分散装置）」という心強い味方です。その中でもAWSの代表選手であるALB（Application Load Balancer）は、Webアプリを支えるなくてはならない存在ですよね。
今回は、このALBの機能の一つである「クロスゾーン負荷分散」をテーマに、なぜそれが重要なのか、そして実務で避けて通れない「コスト」とのトレードオフについて、身近な例えを交えながら優しく紐解いていきたいと思います。
難しい用語が出てきても「一歩ずつ理解していきましょう！」の精神で進めますので、どうぞリラックスして読んでくださいね。
—
1. 郵便配達で例える「AZ（アベイラビリティゾーン）」と「ロードバランサー」
まずは、クラウドの仕組みを現実世界に置き換えて考えてみましょう。
AWSなどのクラウドには、「AZ（アベイラビリティゾーン）」という概念があります。これは簡単に言うと、地理的に少し離れた場所にある「独立したデータセンター（建物のイメージ）」のことです。災害や電源トラブルが起きても片方が無事なように、通常は複数のAZに同じシステムを分散して配置します。
ここで、世田谷区（AZ-A）と杉並区（AZ-C）の2つの大きな倉庫に、全く同じ「荷物（Webサーバー）」を置いていると想像してください。
インターネットからやってくるたくさんの注文（リクエスト）を、入り口でさばくのがALB（ロードバランサー）です。
クロスゾーン負荷分散がない世界（デフォルトの意地悪なルール）
もし、このクロスゾーン負荷分散が「オフ（無効）」になっていると、ALBは次のような頑固なルールで動き始めます。
- 世田谷区の郵便局（AZ-AのALB）に届いた荷物は、絶対に世田谷区の倉庫（AZ-Aのサーバー）にしか届けない。
- 杉並区の郵便局（AZ-CのALB）に届いた荷物は、絶対に杉並区の倉庫（AZ-Cのサーバー）にしか届けない。
「えっ、それの何が駄目なの？」と思いますよね。
もし、世田谷区の倉庫宛ての注文が突然ドッと増えてパンクしかけているのに、隣の杉並区の倉庫はヒマを持て余して昼寝をしている状態だったらどうでしょう？
「いやいや、隣の倉庫に手伝ってもらいなよ！」と言いたくなりますよね。この「隣のエリアへの助け合い」を禁じられているのが、クロスゾーン負荷分散オフの状態なんです。
クロスゾーン負荷分散がある世界（チームワーク抜群の状態）
これを「オン（有効）」にすると、世田谷区の郵便局に届いた荷物であっても、「あ、世田谷の倉庫が今ちょっと混んでるから、空いてる杉並区の倉庫にトラックで運んで処理してもらおう！」というエリアを跨いだ柔軟なチームワーク（負荷分散）ができるようになります。これが、クロスゾーン負荷分散の正体です。
—
2. クロスゾーン負荷分散を有効にするメリット
この機能をオンにすると、私たちのシステムには次のような素晴らしいメリットが生まれます。
1. サーバーの偏った疲れを解消できる（均等な負荷分散）
ユーザーからのアクセスが特定のAZに偏ってしまっても、背後にあるすべてのサーバー（ターゲット）へ綺麗に仕事を振り分けられます。一部のサーバーだけが残業でボロボロになるのを防げるわけです。
2. 片方のエリアがピンチでも耐えられる（耐障害性の向上）
例えば、AZ-Aにあるサーバー群で急な障害が発生して動かなくなったとします。クロスゾーン負荷分散が有効であれば、AZ-A宛てに来たリクエストを、生き残っているAZ-Cのサーバーへ自動的にパスすることができます。結果として、ユーザーにはエラーを見せずにシステムを継続できるのです。
AWSの最新世代のALBでは、このクロスゾーン負荷分散はデフォルトで「有効」になっています。それだけメリットが大きい機能だからですね。
—
3. ここがインフラの泥臭いところ！「コスト」とのトレードオフ
「じゃあ、ずっとオンにしておけば万事解決だね！」と言いたいところですが、世の中そんなに甘くありません。インフラエンジニアの腕の見せ所であり、頭の痛いところは「コスト（お金）」の存在です。
クラウドの世界では、データを別の建物（AZ）に運ぶときに「クロスAZデータ転送量」というネットワークの通行料が発生します。
- 同じAZ内の通信： 通行料は基本無料（または非常に安い）
- 別のAZへ跨ぐ通信（クロスAZ）： 通行料が有料（GB単位で課金される）
クロスゾーン負荷分散を有効にしていると、ALBから別のAZにあるサーバーへデータを送る機会が増えるため、この「ネットワークの通行料」がジワジワと増えていくことになります。
特に、動画の配信や大きな画像をやり取りするWebサービスなどでは、このクロスAZのデータ転送費用が、月末の請求書を見て「うわっ！」と声を上げてしまう原因になることが少なくありません。
—
4. 実務での設定例と向き合い方
それでは、この機能の設定や確認をAWS CLIで行う場合のサンプルを見てみましょう。実務では次のようなコマンドや、TerraformなどのIaC（Infrastructure as Code）ツールを使ってコントロールします。
ALBの属性を確認・変更するAWS CLIの例
現在、構築しているALBでクロスゾーン負荷分散がどうなっているかを確認し、必要に応じて変更するコマンドです。
# 1. 現在のロードバランサーの属性（クロスゾーン負荷分散の設定含む）を確認する
aws elbv2 describe-load-balancer-attributes \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:load-balancer/app/my-web-alb/abcdef1234567890 \
--query "Attributes[?Key=='routing.http.drop_invalid_header_fields.enabled' || Key=='load_balancing.cross_zone.enabled']"
# 2. クロスゾーン負荷分散を明示的に「有効 (true)」に設定する
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:load-balancer/app/my-web-alb/abcdef1234567890 \
--attributes Key=load_balancing.cross_zone.enabled,Value=true
# 3. コスト削減のために「無効 (false)」に切り替えたい場合の設定例
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:load-balancer/app/my-web-alb/abcdef1234567890 \
--attributes Key=load_balancing.cross_zone.enabled,Value=false現場のSREはどう判断すべき？
「じゃあ、お金をケチるために常にオフにすべき？」という疑問が湧きますよね。ここがSREとしての判断の分かれ道です。
- 基本方針：基本は「有効（オン）」がおすすめ
現代のWebシステムでは、予期せぬアクセスの偏りやサーバーの増減（Auto Scaling）が頻繁に起こります。トラフィックの偏りで一部のサーバーがダウンするリスクや、運用トラブルシュートの手間を考えると、多少のデータ転送コストよりも可用性（システムが止まらないこと）を優先する方が安上がりであることが多いです。
- 例外的なケース：超大容量データ通信を行うシステム
例えば、毎日テラバイト級の動画やログファイルをさばくようなシステムでは、クロスAZの通行料がバカになりません。この場合は、DNSラウンドロビンや各AZ内で完結するようなアーキテクチャへの見直しをセットで行った上で、あえてクロスゾーン負荷分散をオフにすることを検討します。
—
まとめ
今回は、ALBのクロスゾーン負荷分散について、AZ間の郵便配達に例えながら解説しました。
- メリット： エリアを越えたチームワークで、負荷を綺麗に分散し、片方の障害にも強くなる！
- トレードオフ： エリアを跨ぐ通信が増えるため、ネットワークのデータ転送コスト（通信料）に注意が必要！
インフラやネットワークの世界は、こうした「便利さとコストのバランス」をパズルのように組み立てていく、とても奥深くてエキサイティングな世界です。
「難しそう…」と思っていたクラウドのネットワークも、身近な仕組みに置き換えて一歩ずつ紐解いていけば、必ず自分の手でコントロールできるようになりますよ。
それでは、また次回のSREブログでお会いしましょう！快適なクラウドライフを！
コメント