5分でできるHAProxyクイックインストール
テスト用にすぐに動作するトラフィック管理ツールが必要な場合、これが最短のルートです。複雑な設定に踏み込む前に、疎通確認を行うためによくこの方法を使います。
1. インストール
sudo apt update
sudo apt install haproxy -y
2. 基本的なロードバランシング設定
次のコマンドで設定ファイルを開きます:
sudo nano /etc/haproxy/haproxy.cfg
ファイルの末尾に以下のコードを貼り付けます。192.168.1.10 と 192.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 を実行して構文エラーをチェックしてください。カンマ一つ打ち間違えただけで、システム全体がダウンすることもありますから!

