【入門編】ロードバランサーにおけるパフォーマンスとコスト最適化戦略 – クラウド＆コンテナネットワーク実践ガイド

【保存版】ロードバランサーのコストが劇的に下がる！？ALB・NLB・GLBの賢い使い分けとパフォーマンス最適化術

みなさん、こんにちは！クラウドやインフラの世界へようこそ。

Webサイトやアプリを作っていると、必ずと言っていいほど出会うのが「ロードバランサー（Load Balancer）」という存在です。AWSなどのクラウドサービスを使っていると、ALB や NLB、さらには GLB といったアルファベット3文字のサービス名が並んでいて、「一体どれを使えばいいの？」「毎月の請求書を見たら、ロードバランサーの費用が思ったより高くてビックリした…」と悩んでしまうこともありますよね。

今回は、インフラやネットワークに初めて触れる初学者のみなさんに向けて、小難しいパケットやヘッダーの話は一切抜きで！郵便配達やお店の受付などの身近な仕組みに例えながら、ロードバランサーの選び方とコスト最適化のコツを、一歩ずつ一緒に紐解いていきましょう！

—

そもそもロードバランサーって何をしているの？

ロードバランサー（Load Balancer）を直訳すると「負荷（Load）を均衡に保つもの（Balancer）」です。

例えば、超人気の大行列ができるラーメン屋さんを想像してみてください。入口に案内係（ロードバランサー）が一人立っていて、やってきたお客さん（アクセス）を、空いているカウンター席（サーバー）へ順番に誘導してあげるイメージです。

もし案内係がいないと、1つの席だけに客が集中して店員さんがパンクしてしまったり（サーバーダウン）、他の席がガラガラなのに「満席です！」と断ってしまうことになりますよね。

【アクセス集中時】
[大量のお客さん] 
       │
       ▼
[案内係 (ロードバランサー)]  ←「あっちの席へどうぞ！次はこっちへ！」
 ┌─────┼─────┐
 ▼     ▼     ▼
[厨房1][厨房2][厨房3]  (サーバー群)

クラウドの世界では、この「案内係」を担当するのが ALB や NLB、GLB といった各種ロードバランサーなのです。

—

3種類のロードバランサー（ALB / NLB / GLB）を整理しよう！

AWSには主に3つのロードバランサーがあります。それぞれ得意分野が全く違いますので、身近な例えで比較してみましょう。

一歩ずつ、それぞれの特徴を見ていきましょう！

1. ALB（手紙の中身を見る丁寧なコンシェルジュ）

ALB は、Webサイトのやり取り（HTTP や HTTPS）に特化したロードバランサーです。
やってきた手紙（リクエスト）の「中身（URLやヘッダー情報）」を読んでから振り分けることができます。

例えば、「/api/ というURLで来たらAPI専用サーバーへ」「スマホからのアクセス（User-Agent）ならスマホ用サーバーへ」といった高度な交通整理が得意です。Webサイトを作るとき、迷ったらまずは ALB を選ぶのが王道になります。

2. NLB（住所だけを見て爆速で捌くトラック）

NLB は、中身（HTTP の内容など）を見ません。手紙の表に書いてある「宛先住所とポート番号（TCP / UDP）」だけを見て、機械的に超高速で裏方のサーバーへ転送します。

中身を吟味しないぶん、処理がめちゃくちゃ速く、数百万件もの同時アクセスが突発的に来てもビクともしません。「オンラインゲームの通信」や「動画配信」、「とにかくミリ秒単位の速度にこだわりたいAPI」などで大活躍します。

3. GLB（荷物の検疫を行う専門ステーション）

GLB は少し特殊で、届いた通信を一度「サードパーティ製のセキュリティ装置（検査場）」に丸投げして、危険なウイルスや攻撃が入っていないかをチェックさせるためのロードバランサーです。

社内ネットワークの出口や、厳重なセキュリティルールを守らなければならない企業のシステムで使われます。

—

ロードバランサーの料金の仕組み：「LCU」ってなに？

さて、ここからが本題の「コスト最適化」です！

AWSで ALB や NLB を使うと、毎月「基本料金（1時間ごとに数円）」に加えて、「使った分だけの従量課金」が発生します。この従量課金の単位を、AWSでは LCU（Load Balancer Capacity Unit） と呼びます。

「 LCU ってなに？難しい…」と身構えなくても大丈夫です！要するに「ロードバランサーのメーター（電気代や水道代のメーターのようなもの）」だと思ってください。

ALB の場合、以下の4つのメーターのうち、「その時間で一番使ったメーター」の数値で料金が決まるルールになっています。

【ALBの料金メーター（4つの指標）】

 1. [新規接続数]     ─ 一日または一秒間に何人の新しいお客さんが来たか？
 2. [アクティブ接続数] ─ 同時に何人のお客さんがお店の中に留まっているか？
 3. [処理量 (GB)]    ─ どれくらい大きな画像やデータをやり取りしたか？
 4. [ルール評価数]   ─ 「URLが〇〇なら〜」という仕分けルールを何回実行したか？

一番使用量が高かったメーターの分だけお金が請求されるため、どのメーターが跳ね上がっているかを知ることがコスト削減の鍵になります！

—

パフォーマンスとコストを両立する3つの実践アプローチ

「料金のメーターが上がる原因」が分かれば、対策はカンタンです！ここからは、現場のSRE（信頼性エンジニア）も実践しているコスト最適化のアプローチをご紹介します。

アプローチ1：前にCDN（CloudFront）を置いて「処理量」を減らす

一番手軽で効果絶大なのが、ロードバランサーの前に CloudFront（CDN：コンテンツ配信ネットワーク） という「自動キャッシュ機能」を置く方法です。

身近な例でいうと、お店の前に「よくある質問（FAQ）のチラシ置き場」を作るようなものです。

【仕組みの変更】

 [変更前] ユーザー ───────────────> [ALB] ──> [Webサーバー] 
                                    （毎回画像の転送で処理量が爆発！）

 [変更後] ユーザー ──> [CloudFront] ──> [ALB] ──> [Webサーバー]
                        │ (画像のキャッシュを即返却！)
                        └──> ALBまで通信が届かないからLCUが劇的に安くなる！

画像やCSSファイルなどの「毎回変わらないファイル」を CloudFront が代わりに返してくれるため、ALB に届くデータ量（処理量GB）が激減し、LCU のメーターが一気に下がります！

アプローチ2：毎回挨拶するのをやめる（Keep-Alive の活用）

Webブラウザとサーバーが通信するとき、毎回「初めまして！（接続確立）」→「さようなら！（切断）」を繰り返していると、LCU の「新規接続数」メーターが跳ね上がります。

そこで、「一度繋がったら、しばらく接続を繋ぎっぱなしにして会話を続ける（Keep-Alive）」 設定にします。

身近な例で言えば、電話で「もしもし」と「じゃあね」を1分間に10回繰り返すのではなく、1回の通話で10個の質問をまとめて聞くようなイメージですね。

アプローチ3：仕分けルール（Rule）を増やしすぎない

ALB は「/images/* へのアクセスならこのサーバー」「/api/* ならこのサーバー」といった仕分けルールを細かく設定できます。

しかし、ルールを50個も100個も作ってしまうと、手紙が来るたびに100個のルールを上から順にチェックすることになり、「ルール評価数」のメーターが上がってしまいます。

複雑すぎる仕分けは ALB にやらせず、後ろのアプリケーション（Webサーバー側）で処理させるか、ルールをシンプルにまとめるのがコスト抑止のコツです。

—

実際に試してみよう！IaC（Terraform）で構築する最適化設定

最後に、実際の現場でよく使われる設定例を見てみましょう！今回は、コストパフォーマンスに優れた ALB と CloudFront の構成を、クラウドの構成図をコードで書くツール Terraform（テラフォーム） のサンプルコードでご紹介します。

コピペして使えるように、分かりやすい日本語コメントを添えていますので、眺めて雰囲気を掴んでみてくださいね。

# =========================================================
# 1. コスト効率の高い ALB（ロードバランサー）の定義
# =========================================================
resource "aws_lb" "my_app_alb" {
  name               = "my-cost-optimized-alb"
  internal           = false # インターネットからのアクセスを受け付ける
  load_balancer_type = "application" # Webサイト向けなので ALB を選択
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = [aws_subnet.public_a.id, aws_subnet.public_b.id]

  # 【削除保護】うっかり消してしまうのを防ぐ設定
  enable_deletion_protection = false

  tags = {
    Environment = "production"
    ManagedBy   = "Terraform"
  }
}

# =========================================================
# 2. ターゲットグループ（後ろ控えるWebサーバー群）の設定
# =========================================================
resource "aws_lb_target_group" "my_app_tg" {
  name     = "my-app-target-group"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  # ヘルスチェック（サーバーが元気かどうか監視する仕組み）
  health_check {
    path                = "/health" # チェック用のURL
    interval            = 30        # 30秒ごとに確認
    timeout             = 5         # 5秒返事がなければタイムアウト
    healthy_threshold   = 2         # 2回連続成功で「正常」とみなす
    unhealthy_threshold = 2         # 2回連続失敗で「異常」とみなす
  }
}

# =========================================================
# 3. HTTPからのアクセスを強制的に HTTPS（安全な通信）へリダイレクト
# =========================================================
resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.my_app_alb.arn
  port              = "80"
  protocol          = "HTTP"

  # ここで無駄な処理をせず、即座に HTTPS（443番ポート）へ案内する
  default_action {
    type = "redirect"

    redirect {
      port        = "443"
      protocol    = "HTTPS"
      status_code = "HTTP_301" # 永久転送
    }
  }
}

このように、コードで管理することで、「どのロードバランサーにどんな設定が入っているか」をチーム全員で確認できるようになり、無駄なリソースの消し忘れも防ぐことができます！

—

まとめ：一歩ずつマスターしていこう！

今回は、ロードバランサーの基礎から使い分け、そして料金の仕組み（LCU）とコスト削減のアプローチについて解説しました。

最後に大事なポイントを振り返ってみましょう！

1. 用途で選ぶ！

Webサイトやアプリの振り分けなら ALB
爆速・大量アクセス・ゲーム通信なら NLB
厳格なセキュリティ検査なら GLB

2. LCU のメーターを意識する！

データ処理量、接続数、ルールの数で料金が変わる。

3. CloudFront（CDN）を前に置いてコストカット！

キャッシュを活用すれば、ロードバランサーの負荷も費用も劇的に下がる。

インフラやネットワークの世界は、一見すると英語や略称ばかりで難しく見えますが、今回のように「現実世界のお店や郵便局」に置き換えて考えてみると、とってもシンプルで面白い仕組みで動いていることが分かりますよね。

焦らず一つずつ知識を積み重ねて、コストに優しく頼もしいインフラアーキテクトを目指していきましょう！応援しています！