OpenClawスケーリング設計ガイド｜小規模→中規模→大規模の段階的拡張

OpenClawスケーリング 3つの成長段階とインフラ設計

OpenClawのインフラ設計は、利用規模によって最適な構成が異なります。利用ユーザー数とトラフィックに応じて、3つの成長段階に分類して考えるのが実践的です。

重要なのは、最初から大規模構成を用意しないことです。過剰なインフラはコストの無駄遣いになります。現在の規模に合った構成を選び、成長に合わせて段階的に拡張してください。

OpenClawスケーリング 小規模構成（VPS単体）の設計

〜100ユーザー規模では、1台のVPSにWebサーバー・データベース・Redisをすべて同居させる構成が最もコスト効率に優れています。管理するサーバーが1台のみのため、運用負担も最小限に抑えられます。

推奨スペック

• CPU：4コア以上（vCPU 4〜8）
• メモリ：8GB以上（DB用に4GB、Web/Redis用に4GBの配分が目安）
• ストレージ：SSD 100GB以上（ログ・バックアップ込みで余裕を持たせる）
• 帯域：1Gbps以上の共有帯域

構成上の注意点

1台構成では、リソースの競合が最大のリスクです。以下の設定で各プロセスのリソース上限を明示的に管理してください。

• MySQL/PostgreSQL：innodb_buffer_pool_size をメモリの40〜50%に設定
• Redis：maxmemory を512MB〜1GBに制限し、eviction policyを allkeys-lru に設定
• Nginx + PHP-FPM：pm.max_children をCPUコア数の2〜4倍に設定

モニタリングの開始

小規模段階からモニタリングを始めることで、拡張タイミングを正確に把握できます。最低限、以下の3項目を計測してください。

• CPU使用率（継続的に70%を超えたらスケールアップ検討）
• メモリ使用率（80%を超えたら危険水域）
• HTTP応答時間（P95で3秒を超えたらユーザー体験に影響）

OpenClawスケーリング 中規模構成（Web+DB分離）の設計

100〜1,000ユーザー規模になると、WebサーバーとDBサーバーを分離するタイミングです。DBのCPU・メモリ使用率がWebサーバーのパフォーマンスを圧迫し始めたら、分離を検討してください。

Web/DB分離の効果

• リソース競合の解消：DBの重いクエリがWebリクエスト処理を遅延させなくなる
• スペックの最適化：WebサーバーはCPU重視、DBサーバーはメモリ重視の構成を選べる
• 独立したスケールアップ：ボトルネックになった側だけをスケールアップできる

リードレプリカの導入

読み取りが多いワークロード（OpenClawのダッシュボード表示・レポート生成など）では、リードレプリカを追加することでDBの負荷を分散できます。

• 書き込み（INSERT/UPDATE/DELETE）はプライマリDBへ
• 読み取り（SELECT）はレプリカへルーティング
• MySQL Group ReplicationまたはPostgreSQL Streaming Replicationで構成

セッション管理のRedis移行

Web/DB分離と同時に、セッション管理をファイルベースからRedisに移行してください。将来的にWebサーバーを複数台に増やす際、セッションの共有が必要になります。今のうちにRedis（専用サーバーまたはElastiCache等のマネージドサービス）に移行しておくと、次の拡張がスムーズになります。

OpenClawスケーリング 大規模構成（クラスタ・ロードバランサー）の設計

1,000ユーザーを超えると、単一のWebサーバーでは処理しきれなくなります。ロードバランサーでWebサーバーを複数台に分散し、DBもクラスタ化することで、高可用性と水平スケーリングを実現します。

ロードバランサー（Nginx / HAProxy）の設定

Nginxをリバースプロキシ兼ロードバランサーとして使用する場合、upstreamブロックで複数のWebサーバーを定義します。

• 負荷分散アルゴリズム：least_conn（最小接続数）が安定動作しやすい
• ヘルスチェック：Nginx PlusまたはHAProxyでアクティブヘルスチェックを設定
• スティッキーセッション：セッションをRedisに移行済みであれば不要（推奨）
• SSL終端：ロードバランサーでSSL終端し、バックエンドへはHTTPで転送

Webサーバー複数台構成

Webサーバーはステートレス（セッション情報をRedisに持つ）に設計することで、台数を自由に増減できます。デプロイはBlue/Greenまたはローリングアップデートで無停止リリースを実現してください。

DBクラスタ（MySQL Group Replication）

大規模構成ではDB単体障害が致命的になります。MySQL Group Replication（または Galera Cluster）で複数台のDB間でデータを同期し、1台が落ちても自動フェイルオーバーで継続稼働できる構成を整備してください。

• 最小構成：プライマリ1台 + レプリカ2台（計3台でクォーラム確保）
• 書き込み：プライマリのみ（シングルプライマリモード推奨）
• 読み取り：レプリカ2台に分散

OpenClawスケーリング クラウドでのオートスケーリング設定

クラウド（AWS・GCP・Azure）を利用している場合、アクセス量に応じてWebサーバーの台数を自動的に増減するオートスケーリングを設定できます。これにより、ピーク時のみコストが増加し、閑散時は最小台数に抑えられます。

AWS Auto Scaling Group

EC2インスタンスをAuto Scaling Groupに組み込み、CloudWatchメトリクスをトリガーにスケーリングポリシーを設定します。

• スケールアウト条件：CPU使用率が60%以上を5分間継続
• スケールイン条件：CPU使用率が30%以下を10分間継続
• クールダウン期間：スケールアウト後300秒（起動完了前の誤トリガー防止）
• 最小/最大台数：min=2（冗長性確保）、max=10（コスト上限）

GCE Managed Instance Group（MIG）

Google Cloud Computeでは、Managed Instance GroupとAutoScalerを組み合わせます。

• トリガー：CPU使用率ベースまたはカスタムメトリクス（Pub/Sub積滞など）
• スケーリングポリシー：ターゲット使用率60%を維持するよう台数を自動調整
• プリエンプティブルVM：コスト削減に有効だが、突然停止するリスクがあるため本番では注意

オートスケーリングの前提条件

オートスケーリングを正しく機能させるためには、以下の前提を満たしている必要があります。

• ステートレスWebサーバー：セッションをRedisに移行済みであること
• 起動スクリプト：インスタンス起動時にアプリが自動でセットアップされること（ユーザーデータまたはcloud-init）
• ヘルスチェック：ロードバランサーのヘルスチェックが正常に機能していること
• DBの接続上限：スケールアウト時にDB接続数が上限を超えないよう、接続プーラー（PgBouncer/ProxySQL）を導入する

まとめ

OpenClawのスケーリングは、利用規模に応じた段階的な拡張が最もコスト効率に優れています。最初から大規模構成を用意すると、運用コストが過大になり、小規模フェーズでの収益化が困難になります。

成長ステージごとの基本方針をまとめます。

• 小規模（〜100ユーザー）：VPS 1台に全て同居。モニタリングを導入して成長を把握する
• 中規模（100〜1,000ユーザー）：Web/DB分離＋リードレプリカ＋Redis移行。ボトルネックを解消しながら拡張
• 大規模（1,000ユーザー以上）：ロードバランサー＋複数WebサーバーでWeb層を水平拡張。DBはクラスタで高可用性を確保

運用中のコスト管理についてはコスト完全分解ガイドを、インフラ全体のセキュリティ設計についてはセキュリティ設計ガイドをあわせて参照してください。