自己紹介
こんにちは。新卒2年目のエンジニアです。
会社では主にGoogle Cloud Platform（GCP）を使用しており、最近「Professional Cloud Architect」という資格を取得しました。
業務内で扱った経験から学んだことを中心に、ロードバランサについて説明できればと思います。
同じようにインフラ学習を始めたばかりの方の参考になれば嬉しいです。
※この記事は自分の体験を基に、Claude Codeを使って執筆しています。
ロードバランサって何？
ロードバランサは、その名前の通り「負荷（Load）を分散（Balance）する」装置です。交通整理の警察官のようなもので、大量のアクセスを複数のサーバーに効率よく振り分けてくれます。
Google Cloud Platform（GCP）では、「Cloud Load Balancing」というサービスが提供されており、設定画面から簡単にロードバランサを構築できます。
ロードバランサの主な役割
1. トラフィックの分散
ユーザー → ロードバランサ → サーバー1
→ サーバー2
→ サーバー3
大量のリクエストを複数のサーバーに分散させることで、1台のサーバーに負荷が集中するのを防ぎます。
GCPでの実装例
GCPでは、サーバーリソースの種類によって分散先の指定方法が異なります：
- Cloud Run：バックエンドサービスに直接Cloud Runサービスを指定
- Compute Engine：インスタンスグループを作成して、そのグループをバックエンドサービスに指定
例えば、Compute Engineの場合は複数のVMインスタンスを「インスタンスグループ」としてまとめ、ロードバランサはそのグループに対してトラフィックを分散します。これにより、個別のサーバーを意識せずに負荷分散が可能になります。
2. 高可用性の実現
もしサーバーが1台だけの場合、そのサーバーが故障するとサービス全体が停止してしまいます。ロードバランサがあれば：
- サーバー1が故障 → サーバー2とサーバー3が処理を継続
- ユーザーは故障に気づかずサービスを利用し続けられる
3. ヘルスチェック
ロードバランサは定期的に各サーバーの状態を監視し、異常があるサーバーには自動的にトラフィックを送らなくなります。
GCPでのヘルスチェック設定
GCPでロードバランサを構築する際も、詳細なヘルスチェックを設定できます：
- 正常閾値：サーバーが正常と判断されるまでの連続成功回数
- 異常閾値：サーバーが異常と判断されるまでの連続失敗回数
- 計測方法：HTTPリクエスト、TCPコネクション確認など、サーバーの状態を確認する方法
例えば、「3回連続でHTTPステータス200が返ってきたら正常」「2回連続で応答がなければ異常」といった具合に、サービスの要件に応じて柔軟に設定できます。
負荷分散の方法
ラウンドロビン方式
リクエストを順番に各サーバーに振り分ける最もシンプルな方法です。
リクエスト1 → サーバー1
リクエスト2 → サーバー2
リクエスト3 → サーバー3
リクエスト4 → サーバー1（また最初から）
重み付きラウンドロビン
サーバーの性能に応じて、処理能力の高いサーバーにより多くのリクエストを送る方法です。
最小接続数方式
現在最も少ないリクエストを処理しているサーバーに新しいリクエストを送る方法です。
GCPでの高度な負荷分散設定
GCPでは、ロードバランサ局所的ポリシー（LocalityLbPolicy）を設定することで、より詳細な負荷分散制御が可能です：
局所的ポリシーの設定
- 分散方式の選択：ラウンドロビン、最小接続数、重み付きなど
- セッション親和性：同じユーザーのリクエストを同じサーバーに送る
- 地理的な分散：ユーザーの地理的位置に基づいて最適なサーバーを選択
使用率に応じた分散
ヘルスチェック機能を活用して、各サーバーの使用率を監視し、リアルタイムでトラフィックを振り分けます：
- CPU使用率：高負荷のサーバーへのトラフィックを制限
- メモリ使用率：メモリ不足のサーバーを一時的に分散対象から除外
- レスポンス時間：応答が遅いサーバーへの新規リクエストを減らす
これにより、常に最適なパフォーマンスを維持できます。
ロードバランサの種類
ロードバランサには、OSI参照モデルの異なる層で動作する2つの主要な種類があります。
Layer 4（L4）ロードバランサ
ネットワーク層（IPアドレス）とトランスポート層（ポート番号）の情報を元に分散を行います。
特徴：
- 高速処理：パケットヘッダーの情報のみを見るため、処理が軽い
- プロトコル非依存：HTTP、TCP、UDPなど様々なプロトコルに対応
- シンプル：設定が比較的簡単
適用例：
- 大量のトラフィックを処理する必要がある場合
- データベースサーバーへの接続分散
- 単純な負荷分散のみで十分な場合
Layer 7（L7）ロードバランサ
アプリケーション層の情報（HTTPヘッダー、URL、コンテンツ）を解析して分散を行います。
特徴：
- 高機能：URLパスやHTTPヘッダーに基づいた詳細な分散ロジック
- 柔軟性：リクエストの内容に応じて異なるサーバーに振り分け可能
- セキュリティ：WAF（Web Application Firewall）機能を持つものもある
適用例：
-
/api/のリクエストはAPIサーバーに、それ以外はWebサーバーに分散 - 特定のHTTPヘッダーを持つリクエストを別のサーバーに転送
- SSL終端処理やコンテンツ圧縮などの高度な機能が必要な場合
実際の導入例
私が実際に構築した導入例を紹介します。
社内アプリケーション（IAP + Cloud Run）
社内ユーザー → ロードバランサ（IAP認証） → Cloud Runサービス
- ロードバランサにIAPをアタッチして、社員のみアクセス可能に設定
- バックエンドサービスにCloud Runのサーバーを指定
- 認証されたユーザーのみがサービスにアクセスできる
社内サイト（VMインスタンスグループ）
社内ユーザー → ロードバランサ → VMインスタンスグループ
- ロードバランサのバックエンドサービスにVMインスタンスグループを作成
- 負荷分散と高可用性を同時に実現
ロードバランサでできること
ロードバランサは単なる負荷分散以外にも、多くの機能を提供します：
基本機能
- パフォーマンス向上：複数サーバーで処理を分散
- 可用性向上：単一障害点を排除
- スケーラビリティ：サーバーを追加することで処理能力を向上
- メンテナンス性：一部のサーバーをメンテナンスしても、サービス継続が可能
高度な機能
アクセス認証（IAP）
GCPのロードバランサでは、Identity-Aware Proxy（IAP）を組み合わせることで、アクセス認証を行うことも可能です。
- 社内システム：Google アカウントでの認証を必須にする
- 特定ユーザー限定：許可されたユーザーのみアクセス可能
- 多要素認証：より強固なセキュリティを実現
これにより、ロードバランサ自体がセキュリティゲートウェイとしての役割も果たせます。
注意点
セッション管理
ユーザーのセッション情報を適切に管理する必要があります。
単一障害点
ロードバランサ自体が故障するとサービス全体に影響するため、冗長化が重要です。
設定の複雑さ
適切な分散ロジックの設定には、システムの理解と経験が必要です。
まとめ
ロードバランサは、現代のWebサービスにおいて欠かせないインフラコンポーネントです。主な役割は：
- トラフィックの分散：複数サーバーに負荷を分散
- 高可用性の実現：サーバー障害時の自動切り替え
- スケーラビリティの向上：サーバー追加による処理能力向上
この記事が、ロードバランサの基本的な理解の助けになれば幸いです。