HAProxy: UbuntuでWebプロダクションの負荷分散を徹底解説 (レイヤー7)

Ubuntu tutorial - IT technology blog
Ubuntu tutorial - IT technology blog

5分でできるHAProxyクイックインストール

テスト用にすぐに動作するトラフィック管理ツールが必要な場合、これが最短のルートです。複雑な設定に踏み込む前に、疎通確認を行うためによくこの方法を使います。

1. インストール

sudo apt update
sudo apt install haproxy -y

2. 基本的なロードバランシング設定

次のコマンドで設定ファイルを開きます:

sudo nano /etc/haproxy/haproxy.cfg

ファイルの末尾に以下のコードを貼り付けます。192.168.1.10192.168.1.11 は、実際のバックエンドノードのIPアドレスに置き換えてください:

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

3. サービスの有効化

sudo systemctl restart haproxy

完了です!HAProxyサーバーのIPにアクセスしてみてください。トラフィックが背後の2つのサーバーに交互に振り分けられるのが確認できるはずです。

なぜレイヤー7にHAProxyを選ぶのか?

以前、「Nginxでもロードバランサーができるのに、なぜHAProxyをわざわざ入れるのか?」と疑問に思っていました。答えは「特化」にあります。HAProxyは「振り分け」のためだけに設計されており、極めて少ないCPUリソースで数万件の同時接続を処理できます。

レイヤー7(アプリケーション層)の威力

HAProxyをインテリジェントなディスパッチャーだと考えてください。レイヤー4ではIPとポートしか分かりませんが、レイヤー7ではHTTPパケットの中身を深く「覗き見」して、クライアントが何を要求しているかを判断できます。

実例として、画像リクエスト(.jpg, .png)はストレージ専門のサーバー群へ、計算負荷の高いAPIリクエストは高スペックなCPUを持つサーバー群へ振り分けるといったことが可能です。これはレイヤー4では不可能な芸当です。

設定における3つの柱

  • Frontend: 受付窓口. IP、ポート、SSL証明書などを定義します。
  • Backend: サービス部隊。実際にアプリケーションロジックを処理するサーバーグループです。
  • ACL (Access Control List): 条件フィルタ。これに基づいて、どのクライアントをどのバックエンドに送るかを決定します。

プロダクション環境向けの実戦設定

実際の運用環境に投入する場合、上記の「クイックスタート」設定だけでは不十分です。夜中に障害対応で叩き起こされないよう、監視ツールが必要です。

1. 監視ダッシュボード (Stats)

HAProxyには直感的なダッシュボードが組み込まれています。どのサーバーが健全か、過負荷か、あるいはハングアップしているかを一目で確認できます。設定ファイルに以下を追加してください:

listen stats
    bind *:8080
    stats enable
    stats uri /stats
    stats refresh 30s
    stats auth admin:password_cuc_kho  # パスワードはすぐに変更してください

http://あなたのIP:8080/stats にアクセスして、リアルタイムのグラフを確認しましょう。

2. ヘルスチェック:クリーンなバックエンドの維持

単にポート80が開いているか確認するだけでは不十分です。Webサーバーは動作していても、中のアプリケーションがフリーズしている(500エラーなど)場合があるからです。私は通常、HAProxyが実際のHTTPリクエストを送信して確認するように設定します:

backend web_servers
    balance leastconn # 接続数が最も少ないサーバーに振り分ける
    option httpchk GET /health_check.php
    http-check expect status 200
    server web1 192.168.1.10:80 check inter 2s fall 3 rise 2
    server web2 192.168.1.11:80 check inter 2s fall 3 rise 2

inter 2s は2秒ごとにチェックすることを意味します。3回失敗(fall 3)すると、HAProxyはそのサーバーをサービスリストから除外し、ユーザーがエラーに遭遇するのを防ぎます。

よくある問題と解決策

ここでは、HAProxyを初めて導入する際に陥りやすい2つの典型的なミスを紹介します。

クライアントの実際のIPが失われる問題

デフォルトでは、バックエンドのWebサーバーはHAProxyのIPしか認識できません。これではアクセス統計やスパム対策が意味をなさなくなります。これを修正するには、option forwardfor を追加します。

backend web_servers
    option forwardfor
    # バックエンドのNginx/Apache側でもreal_ipの設定を忘れずに

スティッキーセッション:ユーザーの固定

アプリケーションが(Redisなどを使わずに)サーバー上でセッションを保持している場合、サーバー1でログインしたユーザーがサーバー2に飛ばされると、即座にログアウトされてしまいます。最も簡単な解決策は、識別用のCookieを使用することです:

backend web_servers
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server web1 192.168.1.10:80 check cookie s1
    server web2 192.168.1.11:80 check cookie s2

HAProxyはブラウザに小さなCookieを付与し、次回アクセス時にも同じサーバーに繋がるように制御します。

終わりに

HAProxyの導入自体は難しくありませんが、高負荷に耐え、安定して稼働させる設定が重要です。ヒント:再起動する前に、必ず haproxy -c -f /etc/haproxy/haproxy.cfg を実行して構文エラーをチェックしてください。カンマ一つ打ち間違えただけで、システム全体がダウンすることもありますから!

Share: