OpenClawマルチインスタンスデプロイとロードバランシング

はじめに

OpenClaw サービスが大量の並列リクエストを処理する必要がある場合や、ゼロダウンタイムデプロイを実現したい場合、シングルインスタンスデプロイでは不十分です。OpenClaw はマルチインスタンスデプロイモードをサポートしており、複数の Gateway インスタンスとロードバランサーを組み合わせて水平スケーリングと高可用性を実現します。

本記事では、マルチインスタンスデプロイのアーキテクチャ設計、設定方法、運用プラクティスを詳しく解説します。

マルチインスタンスアーキテクチャの概要

                    ┌──────────────┐
                    │  Nginx / LB  │
                    └──────┬───────┘
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
     ┌──────────┐   ┌──────────┐   ┌──────────┐
     │ OpenClaw │   │ OpenClaw │   │ OpenClaw │
     │ インスタンス#1│   │ インスタンス#2│   │ インスタンス#3│
     └────┬─────┘   └────┬─────┘   └────┬─────┘
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                  ┌──────────────┐
                  │ 共有ストレージ層 │
                  │ (Redis/NFS)  │
                  └──────────────┘

マルチインスタンスデプロイのコアとなる課題はセッション状態の共有です。OpenClaw は2つの方式を提供しています：共有ファイルシステムとRedisセッションストレージ。

共有ストレージの設定

方式1：共有ファイルシステム（NFS / マウントボリューム）

最もシンプルな方法は、セッションディレクトリを共有ファイルシステムにマウントすることです。

{
  storage: {
    // すべてのインスタンスが同じ共有ディレクトリを参照
    dataDir: "/mnt/shared/openclaw-data",
    sessions: {
      dir: "/mnt/shared/openclaw-data/sessions"
    }
  }
}

Docker Composeの例：

version: "3.8"

services:
  openclaw-1:
    image: openclaw/gateway:latest
    ports:
      - "3001:3000"
    volumes:
      - shared-data:/data/openclaw
    environment:
      - OPENCLAW_DATA_DIR=/data/openclaw
      - OPENCLAW_INSTANCE_ID=node-1

  openclaw-2:
    image: openclaw/gateway:latest
    ports:
      - "3002:3000"
    volumes:
      - shared-data:/data/openclaw
    environment:
      - OPENCLAW_DATA_DIR=/data/openclaw
      - OPENCLAW_INSTANCE_ID=node-2

  openclaw-3:
    image: openclaw/gateway:latest
    ports:
      - "3003:3000"
    volumes:
      - shared-data:/data/openclaw
    environment:
      - OPENCLAW_DATA_DIR=/data/openclaw
      - OPENCLAW_INSTANCE_ID=node-3

  nginx:
    image: nginx:alpine
    ports:
      - "3000:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - openclaw-1
      - openclaw-2
      - openclaw-3

volumes:
  shared-data:
    driver: local

方式2：Redisセッションストレージ

より高い並列性が必要なシーンでは、Redisをセッションストレージバックエンドとして使用することを推奨します。

{
  storage: {
    backend: "redis",
    redis: {
      url: "redis://redis-host:6379",
      password: "your-redis-password",
      db: 0,
      // セッションデータのKeyプレフィックス
      keyPrefix: "openclaw:",
      // コネクションプールサイズ
      poolSize: 10
    }
  }
}

Redisの利点は、アトミック操作による並列書き込みの安全性保証と、より高速な読み書き速度です。

Nginxロードバランシングの設定

基本的なラウンドロビン戦略

upstream openclaw_backend {
    server openclaw-1:3000;
    server openclaw-2:3000;
    server openclaw-3:3000;
}

server {
    listen 80;
    server_name openclaw.example.com;

    location / {
        proxy_pass http://openclaw_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # SSEストリーミングレスポンスには特別な設定が必要
    location /api/v1/chat/stream {
        proxy_pass http://openclaw_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 300s;
    }
}

IP Hash戦略（セッションアフィニティ）

共有ファイルシステムを使用しファイルロック競合を減らしたい場合は、IP Hashで同一ユーザーのリクエストを同一インスタンスに固定ルーティングできます。

upstream openclaw_backend {
    ip_hash;
    server openclaw-1:3000;
    server openclaw-2:3000;
    server openclaw-3:3000;
}

ヘルスチェック

upstream openclaw_backend {
    server openclaw-1:3000 max_fails=3 fail_timeout=30s;
    server openclaw-2:3000 max_fails=3 fail_timeout=30s;
    server openclaw-3:3000 max_fails=3 fail_timeout=30s;
}

メッセージチャンネルのインスタンスバインディング

Telegram、Discordなど、WebSocketの長時間接続を維持する必要があるチャンネルでは注意が必要です。各チャンネルのBot接続は1つのインスタンスのみが保持できます。OpenClawはインスタンスロックメカニズムでこの問題を解決します。

{
  cluster: {
    enabled: true,
    // 現在のインスタンスID、各インスタンスで一意である必要
    instanceId: "node-1",
    // チャンネル割り当て戦略
    channelBinding: {
      // どのインスタンスがどのチャンネルを担当するか
      "node-1": ["telegram", "discord"],
      "node-2": ["slack", "whatsapp"],
      "node-3": ["webchat"]
    }
  }
}

あるインスタンスがダウンした場合、そのインスタンスが担当するチャンネルは自動的に他のインスタンスにフェイルオーバーされます。

ゼロダウンタイムローリングアップデート

ロードバランサーとヘルスチェックを組み合わせることで、ゼロダウンタイムのローリングアップデートを実現できます。

#!/bin/bash
# rolling-update.sh

INSTANCES=("openclaw-1" "openclaw-2" "openclaw-3")

for instance in "${INSTANCES[@]}"; do
  echo "$instance を更新中..."

  # 1. インスタンスをメンテナンスモードに設定（新しいリクエストの受信を停止）
  docker exec $instance openclaw maintenance on

  # 2. 現在のリクエスト処理の完了を待機
  sleep 10

  # 3. 新しいイメージをプルして再起動
  docker compose pull $instance
  docker compose up -d $instance

  # 4. ヘルスチェックのパスを待機
  until curl -sf http://localhost:3000/api/v1/health; do
    sleep 2
  done

  echo "$instance の更新完了"
done

監視とログ集約

マルチインスタンス環境では、集中化されたログと監視が特に重要です。

統一ログ形式

{
  logging: {
    format: "json",
    // ログにインスタンスIDを含める
    includeInstanceId: true,
    // 標準出力に出力し、ログ収集を容易に
    output: "stdout"
  }
}

Prometheusメトリクス

各インスタンスは /api/v1/metrics エンドポイントを公開し、Prometheusで統一的に収集できます。

# prometheus.yml
scrape_configs:
  - job_name: "openclaw"
    static_configs:
      - targets:
          - "openclaw-1:3000"
          - "openclaw-2:3000"
          - "openclaw-3:3000"

主要な監視指標には、1秒あたりのリクエスト数、レスポンスレイテンシの分位数、Token消費率、アクティブセッション数、MCPツール呼び出し頻度などが含まれます。

キャパシティプランニングのアドバイス

注意すべき点として、OpenClawの主なボトルネックは通常Gateway自体ではなく、下流のAIモデルAPIの並列制限と応答速度にあります。

まとめ

OpenClaw のマルチインスタンスデプロイ能力により、個人アシスタントからエンタープライズ級サービスへのスムーズなスケーリングが可能です。共有ストレージ層による状態の整合性の解決、ロードバランサーによるトラフィック分散、チャンネルバインディングとインスタンスロックによる長時間接続管理、さらにローリングアップデートと集中監視——このソリューションによりAIエージェントゲートウェイに本番レベルの信頼性とスケーラビリティを提供できます。