クラスターデプロイメント

GPT-Load高可用性クラスターデプロイメントソリューション、マスタースレーブアーキテクチャと水平スケーリングをサポート

クラスターアーキテクチャ概要

分散マスタースレーブアーキテクチャ

ワンマスターマルチスレーブの分散アーキテクチャを採用。マスターノードは管理機能を担当し、スレーブノードはプロキシサービスに専念し、高可用性と負荷分散を実現

マスターノード

Web管理インターフェース、設定管理、統計分析

スレーブノード

APIプロキシサービスに専念、水平スケーリングをサポート

共有ストレージ

統一されたMySQLとRedisクラスター

デプロイメント要件

重要なお知らせ

クラスターデプロイメント時、データベースとRedisは必須です。分散協調と状態同期に使用されます

インフラストラクチャ要件

データベースクラスター

  • • MySQL 8.2+高可用性クラスター
  • • マスタースレーブレプリケーションまたはGaleraクラスターをサポート
  • • 読み書き分離の設定を推奨
  • • 定期的なバックアップと障害復旧メカニズム

キャッシュクラスター

  • • Redisクラスターまたはセンチネルモード
  • • 分散ロックと状態同期に使用
  • • 永続化とフェイルオーバーを設定
  • • メモリ使用量とパフォーマンスを監視

デプロイメント手順

1

共有インフラストラクチャの準備

MySQLクラスター（またはPostgreSQL）のデプロイ

クラウドデータベースクラスターサービスの使用、または独立したMySQL/PostgreSQLクラスターの自己デプロイを推奨します。

Redisクラスターのデプロイ

Redis Sentinelまたはクラスターモードの使用を推奨し、高可用性とデータ一貫性を確保します。

2

ノードdocker-compose.yml内容参考（マスタースレーブノード共通）

services:
  gpt-load:
    image: ghcr.io/tbphp/gpt-load:latest
    container_name: gpt-load
    ports:
      - "${PORT:-3001}:${PORT:-3001}"
    env_file:
      - .env
    restart: always
    volumes:
      - ./data:/app/data
    stop_grace_period: ${SERVER_GRACEFUL_SHUTDOWN_TIMEOUT:-10}s
    healthcheck:
      test: wget -q --spider -T 10 -O /dev/null http://localhost:${PORT:-3001}/health
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

設定を使用してマスタースレーブノードを区別

IS_SLAVE=true

マスターノード：設定なしまたはIS_SLAVE=falseに設定。スレーブノード：IS_SLAVE=trueに設定。

クラスター全体でマスターノードが1つだけであることを確保。

3

ロードバランシング設定

Nginxまたは他のロードバランサーを使用して、リクエストを異なるスレーブノードに分散

Nginx設定例

# nginx.conf
upstream gpt_load_cluster {
    server master-node-ip:3001 weight=3;
    server slave-node1-ip:3001 weight=5;
    server slave-node2-ip:3001 weight=5;
    # 必要に応じてスレーブノードを追加
}

server {
    listen 80;
    server_name your-domain.com;

    location / {
        proxy_pass http://gpt_load_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # CFや他のプロキシサービスを使用する場合、リアルIPを設定
        set_real_ip_from 0.0.0.0/0;
        real_ip_header X-Forwarded-For;
    }
}

設定管理

統一設定要件

AUTH_KEY同一である必要があります（管理キー）
DATABASE_DSN同一である必要があります
REDIS_DSN同一である必要があります
IS_SLAVEスレーブノードはtrueに設定

動的設定同期

  • • システム設定はMySQLに保存され自動同期
  • • グループ設定はすべてのノードにリアルタイム配信
  • • キー状態はRedisを通じてリアルタイム共有
  • • 設定変更時にサービス再起動は不要

監視と運用

ヘルスチェック

ノード健康状態

# ノード状態確認
curl http://node:3001/health

# レスポンス例
{
  "status": "healthy",
  "timestamp": "2025-07-15T12:56:00Z",
  "uptime": "11.822967ms"
}

クラスター状態監視

  • • 各ノードのリクエスト量とレスポンス時間を監視
  • • データベースとRedis接続状態を確認

スケーリングと容量管理

水平スケーリング

  • • 必要に応じてスレーブノード数を増加
  • • ロードバランサー設定を更新
  • • 新しいノードが自動的に設定を同期
  • • 既存サービスにシームレスに統合

グレースフルシャットダウン

  • • ロードバランサーからノードを削除
  • • 既存リクエストの処理完了を待機
  • • コンテナに停止信号を送信
  • • 関連リソースとログをクリーンアップ

ベストプラクティス

✅ 推奨事項

  • • コンテナオーケストレーションツールの使用（Docker Swarm/K8s）
  • • データベースとRedisの高可用性設定
  • • 包括的な監視とアラートシステムの設定
  • • 設定とデータの定期的なバックアップ
  • • 統一デプロイメント用の設定管理ツールの使用
  • • ブルーグリーンデプロイメントまたはローリングアップデートの実装

❌ 避けるべき事項

  • • データベースまたはキャッシュの単一障害点
  • • ノード間の設定不整合
  • • ネットワーク遅延と分割問題の無視
  • • 監視とログ収集の不足
  • • 大量のノード設定の手動管理
  • • 本番環境設定の直接変更