ロードバランス(Load Balance)徹底解説:F5とも呼ばれ、実案件の紹介も
運用やセキュリティの仕事をしていると、ほぼ必ず出てくる言葉がある——ロードバランスだ。ロードバランスといえば、多くの人が真っ先に思い浮かべる機器が「F5」だ。面白いのは、F5が実は会社名(F5 Networks)だということ。しかし製品があまりに有名なため、次第にロードバランサーの代名詞になった。「百度一下(Baiduで調べる)」が検索の代名詞になったのと同じだ。

今回はこれを徹底解説する:F5とは何か、L4とL7はどこが違うか、実際のシナリオでどう設定するか。
一、ロードバランスは何を解決しているのか
ロードバランス(Load Balance)とは、本質的に仕事のタスクを複数の操作ユニットに分散して実行させることだ——たとえばWebサーバー、FTPサーバー、企業の基幹アプリケーションサーバーなどに分散させ、共同で作業を遂行させる。
技術的な観点から見ると、対外的には1つの仮想サーバーアドレスを見せる。ユーザーが接続してくると、双方向NAT(ネットワークアドレス変換)で最も適した実サーバーへ接続を振り向ける。ユーザーに見えるのは常に同じ入口で、その裏では一群のマシンが支えている。
解決すべきは3つのこと:落ちるのが怖い(単一障害点)、耐えきれないのが怖い(性能ボトルネック)、拡張できないのが怖い(スケールアウトできないこと)。
二、L4 vs L7:最も混同しやすい部分
違いの核心は一言だけ:アプリケーション層プロトコルを解析するかどうか。この差が能力の限界と性能表現を直接決める。
L4ロードバランス(トランスポート層)
- 動作階層:OSI第4層、TCP/UDPプロトコル
- 転送基準:送信元IP、宛先IP、ポート番号——アプリケーションデータには触れない
- 中核能力:ポート転送、TCP接続再利用、L4ヘルスチェック(TCPハンドシェイク)、基本的なDDoS防御
- 性能:転送効率が極めて高く、ハードウェアの限界に近い。マイクロ秒級の遅延
- 典型的シナリオ:データベース(MySQL/Redis)、TCPサービス(ゲームサーバー、Nettyサービス)、データセンター間リンクの負荷分散
- 代表製品:LVS、F5(L4モード)、HAProxy(L4モード)、Nginx(streamモジュール)
L7ロードバランス(アプリケーション層)
- 動作階層:OSI第7層、HTTP/HTTPS、DNS、FTPなどのアプリケーションプロトコル
- 転送基準:URL、Cookie、HTTPヘッダー、リクエストパラメータ、JSON内容
- 中核能力:コンテンツベースルーティング、SSLオフロード、キャッシュ、レート制限・サーキットブレーカー、WAF統合、セッション維持、カナリアリリース
- 性能:機能は豊富だが、アプリケーションプロトコルの解析が必要なため遅延はやや大きい(ミリ秒級)。クラスタ拡張で補う
- 典型的シナリオ:Webアプリケーション、マイクロサービスAPI、HTTPSサービス、カナリアリリース、APIゲートウェイ
- 代表製品:Nginx、HAProxy(L7モード)、F5(L7モジュール)、Kong、Spring Cloud Gateway
一言まとめ:L4は「道標」(IPとポート)を見て転送し、L7は「荷を開けて」(内容を見て)から送り先を決める。性能ならL4、多機能ならL7。
三、F5 BIG-IPは何がすごいのか
F5の主力製品であるBIG-IP LTMの正式名称はローカルトラフィックマネージャーで、L4〜L7のロードバランスが可能だ。単なる転送器ではなく、機能リストは相当長い:アプリケーションスイッチング、セッションスイッチング、ステータス監視、スマートNAT、汎用パーシスタンス、レスポンスエラー処理、IPv6ゲートウェイ、高度なルーティング、SSLアクセラレーション、スマートHTTP圧縮、TCP最適化、コンテンツバッファリング、Cookie暗号化、アプリケーション攻撃フィルタリング、DoSとSYN Flood防御、ファイアウォールパケットフィルタリング……
最も実用的ないくつかを挙げる:
1. マルチリンクロードバランスと冗長化
基幹業務では、品質を確保し単一障害点を排除するために、複数のISP回線を引くことが多い。ここには2つの方向がある:
- OUTBOUNDトラフィック(内網から外網へ):BIG-IP LCがトラフィックを異なるInternetインターフェースにインテリジェントに割り振り、送信元アドレスNATも行う
- INBOUNDトラフィック(外網から内網へ):2つのISPの公網アドレスをバインドし、両ISPのDNSリクエストを解決し、サーバーの健全性とRTT時間に基づいてインテリジェントに応答する
2. サーバーロードバランス
VIP(仮想IP。IPアドレスとTCP/UDPポートで構成される)で外部にサービスを提供し、対象サーバーに対してL4からL7まで継続的にヘルスチェックを行う。障害サーバーが見つかれば、ロードバランスグループから外す。さらにiRulesと組み合わせてTCP/UDPパケットを開き、内容の特徴に応じてルール処理ができる——たとえばURLごとに異なるサーバーへトラフィックを振り向ける。
3. システム高可用性
これはF5が最も誇れる点だ。双機冗長モードではミリ秒級切替(最速200ms以内)で、99.999%の可用性をうたう。仕組みはこうだ:すべてのセッションはActive機器を通る際、同期データラインでセッション情報がBackup機器に同期される——だから切替時もユーザーのアクセスは中断しない。機器内のwatchdogチップがハートビートラインで相手の電位を監視し、Activeが落ちると直ちにBackupへShared IPとVIPの引き継ぎを通知する。
4. セキュリティ
BIG-IPはファイアウォールの設計原理を採用し、デフォルト拒否。アイドル接続を切断してDoSを防ぎ、送信元ルート追跡でIPスプーフィングを防ぎ、ACKなしのSYNを拒否してSYN攻撃を防ぐ。Dynamic Reaping機能はDoS攻撃時のアイドル接続を効率的に削除でき、しかも攻撃量が増えるほど接続切断レートが速くなる——これはなかなか強烈だ。Delay Binding技術はバックエンドサーバーに全面的なSYN Flood保護を提供する。
5. SSLアクセラレーション
各BIG-IPにはSSLハードウェアアクセラレーターチップが搭載され、100 TPSのLicenseが付属しており、別途支払う必要はない。後で拡張したくなったら、Licenseをアップグレードすればよい。

四、F5かNginxか?選定比較
実務で最もよく聞かれる質問だ。両者は競合関係ではなく、むしろ補完関係にある。
F5 BIG-IP(ハードウェア)
- デプロイ形態:専用ハードウェア機器(カスタムチップ含む)
- 性能:百万級TCP接続、マイクロ秒級転送遅延
- 機能:オールマイティ——L4+L7、SSLオフロード、DDoS防御、WAF、VPN、リンク負荷分散
- 信頼性:ハードウェア冗長(双機ホットスタンバイ)、99.999%可用性
- コスト:高額(数十万〜百万超え)、専任エンジニアによる保守が必要
- 拡張性:ハードウェアアップグレードに依存、柔軟性は低い
- 運用:複雑。専用の設定画面とCLIに習熟が必要
Nginx(ソフトウェア)
- デプロイ形態:ソフトウェア。汎用サーバーやクラウドホスト上で動作
- 性能:十万級TCP接続、ミリ秒級遅延、クラスタ拡張可能
- 機能:軽量かつ高効率——L7が中心。L4、SSLオフロード、キャッシュ、レート制限、リバースプロキシに対応
- 信頼性:双機ホットスタンバイ(Keepalived)は手動設定が必要。サーバーハードウェアの安定性に依存
- コスト:オープンソースで無料。Nginx Plusも料金は比較的低い
- 拡張性:クラスタデプロイ対応。クラウド環境では弾力的に拡張可能
- 運用:簡単。設定ファイルは読みやすく、バックエンドエンジニアがすぐ習得できる
選定の分かれ道、これに従えばよい:
- 高同時接続TCPサービス(ゲーム、証券)+極限の可用性 → F5 L4
- 基幹業務の入口+セキュリティ要件(WAF/DDoS) → F5 L7
- マイクロサービスAPIゲートウェイ+クラウド環境 → Nginx L7
- データベース/Redis負荷+コスパ重視 → Nginx L4
- 中小規模業務+高速イテレーション → Nginx(L4/L7)
- エンタープライズデータセンター+マルチリンク → 入口はF5、内部サービスの負荷分散はNginx
最後の組み合わせは、実務で大手によく見られる——F5が外門を守り、Nginxが内部を管理する。
五、実戦事例:F5の設定はいかに回りくどいか
多くの人がF5を手にして最初に抱く反応は:スイッチとは発想がまったく違い、まったく手の出しようがない。設定ロジックは別の体系なのだ。
シナリオ:2台のWebサーバーが外部にサービスを提供。IPは192.168.192.10-20/24で、外部アドレス192.168.27.100の80ポート経由でロードバランスを行う要件。
最もシンプルなロードバランスに必要なパラメータは3つだけで、関係は階層的に連動している:
- Node(ノード):最も基本的な定義。各サーバーが1つのNode
- Pool(リソースプール):トラフィックを受け処理するNodeのグループ。たとえばWebサーバークラスタ
- Virtual Server(仮想サーバー):外部への入口。Poolに紐づく
データフロー:クライアントリクエスト → Virtual Server → Pool → Node。
実操作手順(BIG-IP管理画面):
- ステップ1:機器のアクティベーション。F5を手にしたらまずアクティベーション。ウィザードは簡単だが、覚えておきたいのは必ずネットに接続すること。できればラック設置前に済ませる——これは落とし穴を踏んだ経験談だ
- ステップ2:ログイン。ブラウザでhttps://管理IPを開く。デフォルトのユーザー名・パスワードはともにadmin
- ステップ3:VLANの作成。Network → VLANsでVLANを作成し、インターフェースを追加(Untaggedで選択)
- ステップ4:IPの設定。Networks → Self IPsで各VLANにアドレスを定義
- ステップ5:ルーティングの設定。Networks → Routesでデフォルトゲートウェイまたはスタティックルートを設定
- ステップ6:Poolの設定。Local Traffic → Virtual Servers → Poolsで、名前、ヘルスチェック(TCPなど)、負荷分散アルゴリズム(observed-member観察法など)、実サーバーのIPとポートを設定
- ステップ7:Virtual Serverの設定。Local Traffic → Virtual Serversで上記のPoolを紐づけ、振り分け方式を選択(RoundRobinがよく使われる)
- ステップ8:Monitorの設定。Local Traffic → Monitorsでサーバーの健全性状態をチェックしPoolに紐づける
- ステップ9:Redundantの設定で双機冗長化を行う
六、Virtual Serverの重要パラメータ
F5の核心はVirtual Serverであり、いくつかのパラメータに注意しないと問題が起きる。
VS Type(タイプ)。よく使われる3種類:
- Performance L4:純L4転送。TMMは接続の割り当てのみを担当し、TCPパラメータを変更しない。クライアントとサーバーの接続は1:1。転送速度が速く、企業でよく使われる。アプリケーションへの影響を減らすため、選べるならこれを優先
- Standard VS:クライアントとサーバーのTCP接続は完全に独立。L7機能が必要な場合に使う(Cookieセッション維持、Session ID維持、Header維持、トランザクション単位の長接続分割、SYN攻撃防御)。1つの特徴に注意:そのポートは常に外部に開放されている——バックエンドのNodeが全てdownしても、VIPの80ポートはtelnetでつながる。ただページが開けないだけだ。このタイプで障害を切り分ける際に覚えておくこと
- Forwarding IP:内外網の接続に使用。Pool Memberはなく、転送はローカルルーティングに依存する。デフォルトではF5にルーティング機能がなく、全0のVSを作成してルーティング機能を有効化する必要がある
Timeoutの整合(これは本当に落とし穴)。VSにTCP Profileを設定すると、UDP接続が受け付けられなくなる。さらにtcp内のIdle Timeout値には要注意——サーバー側と整合させる必要がある。F5で150秒、IISサーバーで300秒という設定だと、大量のエラーが発生する。両側の時間は必ず相談して合わせること。
Address/Port Translation:デフォルトはいずれもenabled。VSのIPと実機のIPが異なる場合はAddress Translationを有効に、VSの8080ポートが実アドレスの80ポートに対応する場合はPort Translationを有効にする。
SNAT AutoMap:リクエストがどのVLANから出ていくと、SNATの送信元アドレスはそのVLAN上のSelf IPになる。1つのVLANに複数のSelf IPがある場合は、ローテーションで使用される。
七、なぜ「セッション維持」を理解しなければならないのか
これはロードバランスの中で最も見落とされ、最も事故につながりやすい概念だ。
ECサイトやオンライン認証のようなシステムでは、1件の取引が完了するまでに顧客は何度もやり取りを重ねる。これらのやり取りは密接に関連している——サーバーがステップ2を処理する際、ステップ1の結果を知る必要があることが多い。これはすべてのやり取りが同一のサーバーによって完了されなければならないことを意味し、ロードバランサーによって別々のマシンに振り分けられてはならない。
これがセッション維持(Persistence)が存在する意義だ。F5はConnectivityでこれを実現しており、選択可能なモードには以下がある:
- 送信元アドレス維持:クライアントの送信元IPでバインド
- Cookie維持:F5が自動でセッションCookieを挿入。L7で最もよく使われる
- SSL Session ID維持:SSLセッションを再利用
- セッション維持テーブル:複数のタイムアウトとマッチングルールに対応
設定を間違えるとどうなるか?ユーザーがカートに商品を入れても、更新したら消える——リクエストが別のサーバーに振り分けられたからだ。この種の本番障害は切り分けが非常に大変だ。
八、避けて通れない実戦の細部
最後に、他人が踏んだ落とし穴からいくつか選び、結論だけ示す:
- ヘルスチェックは階層を正しく選ぶ:TCPハンドシェイクだけ見ていると、サーバーのポートは生きていてもアプリが落ちていても転送されてしまう。アプリ層をチェックするには、HTTPタイプのMonitorで/actuator/healthのようなエンドポイントを叩く
- ファイアウォールは「サンドイッチ」にする:単体のファイアウォールは往々にして線速の30%程度のスループットしか出ず、向上させるには複数台を積むしかない。しかしファイアウォールはデータが同じ経路で出入りすることを要求し、そうでないと接続が拒否される——F5のファイアウォールロードバランスソリューションはこの問題を解決し、透過的機器の継続性を実現する
- SSLオフロードはCPU節約の主力:HTTPSのハンドシェイクと暗号・復号をF5に任せ、バックエンドのJavaアプリはHTTPのみ処理すればよい。性能向上は顕著だ
- 本番投入前に負荷テストを実施:L4は速いが、L4のVSでセッション維持を有効にすると状態が導入されることになり、性能の予測は計算し直す必要がある
- 監視指標は3つを見る:プール状態、仮想サーバーのスループット、ノードの健全性状態
- 障害切り分けコマンド:tmsh show ltm pool <pool-name> でプール状態、tmsh show ltm virtual <vs-name> で仮想サーバーの状態を確認

最後に
ロードバランスは「転送機器」に見えるが、実際にはアーキテクチャ全体で最も重要な位置に立っている——すべてのトラフィックがここを通るからだ。うまく設定されていれば、ユーザーはその存在を感じない。設定が下手だと、深夜の電話が自分を探しに来る。
クラウドネイティブの波の下で、LVS、Nginx、HAProxyといったソフトウェアソリューションは中小規模のシナリオで十分通用し、コスト面の優位性も明らかだ。しかし金融、証券、大手ECといった中核入口に関しては、ハードウェアロードバランサーの安定性、ミリ秒級切替、ワンストップのセキュリティ能力という価値は、当面代替できない。
「F5」という名前が、会社からカテゴリーになる過程自体が物語っている——ある製品が動詞として使われるようになったとき、その製品はすでにこの市場を勝ち取っているのだ。
L4は道標を見て、L7は荷を開ける。性能ならL4、多機能ならL7。
参考:F5 BIG-IP LTM公式資料、『ネットワーク運用と管理』F5ロードバランス事例、L4/L7ロードバランス技術比較