OllamaをHAProxyでロードバランシングする方法｜複数LinuxサーバーにOllamaを分散して高可用性ローカルLLMクラスターを構築する手順

なぜHAProxyでOllamaを負荷分散するのか

1台のGPUサーバーでOllamaを運用しているうちは、Nginxリバースプロキシで十分です。しかしチーム規模が広がりリクエスト数が増えると、1台構成の限界が見えてきます。

問題は2つあります。ひとつは「単一障害点」。Ollamaサーバーが落ちた瞬間、チーム全員が一斉に使えなくなります。もうひとつは「処理能力の上限」。1枚のGPUが一度に並列処理できるトークン生成量には物理的な天井があります。

HAProxyはL4/L7ロードバランサーとして、HTTPリクエストを複数のバックエンドへ振り分けます。各Ollamaサーバーに対してヘルスチェックを定期実行し、応答しなくなったサーバーを自動的にバランシング対象から外します。サーバーが復帰すれば自動的に戻ります。

OllamaのAPIはOpenAI互換のHTTPエンドポイントなので、HAProxyのHTTPモードで問題なく中継できます。クライアントはHAProxyのIPだけを向ければよく、社内でOllamaサーバーを増設したときもクライアント側の設定変更は不要です。

構成の全体像と前提環境を把握する

今回構築する構成の概要です。

・HAProxyサーバー（1台）: ロードバランサー役。クライアントはこのIPの8080番ポートへリクエストを送る
・Ollamaサーバー（2台以上）: GPU付きまたはCPUサーバー。HAProxyからの転送を受けて推論を実行する

最小構成はHAProxy1台＋Ollama2台の計3台ですが、検証目的であれば同一マシンでOllamaを2プロセス別ポートで起動してHAProxyで分散することも可能です。

前提条件は以下のとおりです。
・Ubuntu Server 22.04または24.04（各サーバー共通）
・各OllamaサーバーにOllamaインストール済み・モデル取得済み
・HAProxyサーバーから各OllamaサーバーへTCP 11434番で疎通あり
・各サーバーのufwまたはiptablesでHA↔Ollamaの通信を許可済み

Ollamaのインストール手順は「Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド」で詳しく解説しています。本記事ではインストール済みを前提に進めます。

各Ollamaサーバーに同じモデルをpullしておく必要があります。同一モデルが全バックエンドに存在しないと、特定サーバーへ振り分けられたリクエストがモデル未取得エラーになります。

OllamaサーバーをLAN側IPへ公開する

デフォルトのOllamaはlocalhost（127.0.0.1:11434）だけで待ち受けます。HAProxyから接続するにはLAN側IPへバインドを変更しなければなりません。

systemdのoverride設定で環境変数を追加します。各Ollamaサーバーで以下を実行してください。

1. override.confでOLLAMA_HOSTを設定する

systemdの上書き設定ファイルを作成してOllamaのバインドアドレスを変更します。

# override用ディレクトリを作成
sudo mkdir -p /etc/systemd/system/ollama.service.d

# OLLAMA_HOSTを設定
sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF'
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
EOF

# 設定を反映してOllamaを再起動
sudo systemctl daemon-reload
sudo systemctl restart ollama

2. バインドアドレスを確認してufwで絞り込む

ssコマンドでLAN公開を確認します。

# バインド確認
ss -tlnp | grep 11434
# 期待出力: LISTEN 0 4096    0.0.0.0:11434    0.0.0.0:*    users:(("ollama",...))

# HAProxyサーバーのIPを192.168.1.200とする場合
sudo ufw allow from 192.168.1.200 to any port 11434
sudo ufw status

0.0.0.0:11434 で待ち受けていればLAN公開成功です。ufwでHAProxyサーバーのIPからのみ11434番を許可することで、不要な公開を最小限に抑えられます。

3. HAProxyサーバーから疎通確認する

# HAProxyサーバー上で実行（IPは実際の各Ollamaサーバーに合わせる）
curl http://192.168.1.101:11434/api/version
curl http://192.168.1.102:11434/api/version

それぞれのサーバーからJSONのバージョン情報が返れば準備完了です。次はHAProxyをインストールします。

HAProxyをインストールして設定ファイルを作成する

1. HAProxyをインストールする

HAProxyをHAProxy用サーバーにインストールします。Ubuntu 22.04/24.04はaptで最新安定版が入ります。

# HAProxyをインストール
sudo apt update
sudo apt install -y haproxy

# バージョン確認
haproxy -v

2. haproxy.cfgを作成する

次に設定ファイルを作成します。HAProxyの設定は /etc/haproxy/haproxy.cfg に書きます。デフォルトファイルをバックアップしてから上書きします。

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

sudo tee /etc/haproxy/haproxy.cfg << 'EOF'
global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000ms
    timeout client  300000ms
    timeout server  300000ms
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend ollama_frontend
    bind *:8080
    default_backend ollama_backend

backend ollama_backend
    balance roundrobin
    option httpchk GET /api/version
    http-check expect status 200
    server ollama1 192.168.1.101:11434 check inter 10s fall 3 rise 2
    server ollama2 192.168.1.102:11434 check inter 10s fall 3 rise 2

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 10s
    stats auth admin:changeme
EOF

設定の要点を説明します。

・balance roundrobin: リクエストを順番に各サーバーへ振り分けます。重み付き（weightオプション）で高スペックサーバーへの割り当てを増やすことも可能
・option httpchk GET /api/version: 10秒ごとに /api/version をGETして200が返るかチェック
・fall 3: 連続3回失敗したサーバーをバランシング対象から外す
・rise 2: 連続2回成功したサーバーを復帰させる
・timeout client/server 300000ms: LLMの推論は長時間かかるため300秒のタイムアウトに設定

タイムアウト値はモデルや質問の長さによって調整が必要です。Llama3.3のような70Bモデルをq4_0量子化で動かすと、長い応答生成に数分かかることがあります。

ヘルスチェックとフェイルオーバーを動作確認する

1. 設定チェックとHAProxy起動

設定ファイルの文法チェックをしてからHAProxyを起動します。

# 設定ファイルの文法チェック
sudo haproxy -c -f /etc/haproxy/haproxy.cfg

# 起動とステータス確認
sudo systemctl restart haproxy
sudo systemctl status haproxy

「active (running)」と表示されれば起動成功です。

2. HAProxy経由でOllamaへ推論リクエストを送る

HAProxy（8080番）を通して実際にリクエストが分散されているか確認します。

# HAProxyのフロントエンド（8080番）経由でAPIバージョン確認
curl http://192.168.1.200:8080/api/version

# 実際に推論リクエストを送る（HAProxy経由）
curl http://192.168.1.200:8080/api/generate \
  -d '{"model":"llama3.3:70b-instruct-q4_0","prompt":"Linuxのinodeとは何ですか？","stream":false}'

3. フェイルオーバーをテストする

フェイルオーバーのテストも行います。ollama1（192.168.1.101）のOllamaサービスを意図的に停止してリクエストが通るか確認します。

# ollama1サーバー上でOllamaを停止
sudo systemctl stop ollama

# HAProxyサーバーから30秒待ってリクエスト（fall 3 × inter 10s = 30秒後に切り離し）
sleep 35
curl http://192.168.1.200:8080/api/version
# → ollama2だけで応答が返れば成功

# HAProxyの統計画面でバックエンド状態を確認
curl -s http://admin:changeme@192.168.1.200:8404/stats | grep ollama

統計ページはブラウザで http://192.168.1.200:8404/stats を開いても確認できます。DOWN状態になったサーバーが赤く表示され、リクエストがollama2だけへ流れているのが見えます。

ollama1を再起動すれば2回の連続ヘルスチェック成功（rise 2）後に自動復帰します。

どのモデルを各サーバーに載せるかについては「ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント」を参考にしてください。全サーバーで同一モデルを使うのが基本ですが、高スペックなollama1にLlama3.3:70b、低スペックのollama2にPhi-4:14bを置いて用途別に分ける運用も実践されています。その場合はHAProxyのフロントエンドをモデルごとに分ける設計が必要です。

本番運用での注意点とよくあるトラブル対処

チームに展開する前に把握しておくべき注意点です。

タイムアウトの調整: LLMの推論はリクエストによって数秒から数分まで応答時間が大きく変わります。デフォルトの短いタイムアウト（1分など）のままでは、長い生成がHAProxy側でタイムアウトして502エラーになることがあります。haproxy.cfgの timeout server を300秒以上に設定することを推奨します。

セッションアフィニティが不要な理由: Ollamaはステートレスなので、同一クライアントを同一バックエンドへ固定するstickinessは原則不要です。ただしOpen WebUIのチャット履歴がサーバーメモリに乗る設定の場合は注意が必要です。

ログの確認方法: HAProxyのログはsyslogへ出力されます。

# HAProxyのアクセスログをリアルタイム確認
sudo journalctl -u haproxy -f

# バックエンドのUP/DOWN履歴を確認
sudo journalctl -u haproxy | grep -E "UP|DOWN"

よくあるエラーと対処:

・502 Bad Gateway: バックエンドのOllamaサーバーが全台DOWN、またはタイムアウト超過。haproxy.cfgのfrontendにlogsを有効化して原因を切り分ける
・Connection refused on check: OllamaがLAN側へ公開されていない（OLLAMA_HOSTが127.0.0.1のまま）。override.confを再確認する
・haproxy -c でExit code 1: 設定ファイルの文法エラー。エラー行番号が表示されるので確認する

社内導入の際に「なぜローカルLLMが必要か」を情シスへ説明する必要がある場合は「社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢」が参考になります。

まとめ

HAProxyを使ったOllamaの負荷分散構成をまとめると以下のとおりです。

HAProxyを導入することで、Ollamaサーバーを増やすたびに backend ブロックへ1行追加するだけでクラスターを拡張できます。GPU購入のたびにクライアント設定を変更する必要がなくなり、障害発生時も自動で生きているサーバーへ切り替わります。

まずは手元の2台でラウンドロビンを試してみてください。「1台が落ちてもOllamaが使い続けられる」という体験が、チームへの導入提案の説得材料になります。

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

無料マニュアルを受け取る

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

• 前のページへ：OllamaをGitLab CI/CDに組み込む方法｜マージリクエストのコードレビューとセキュリティチェックをローカルLLMで自動化する手順
• この記事の属するカテゴリ：ローカルLLMへ戻る