#準備作業

クラスターアプリケーションをデプロイする前に、以下の準備作業を完了する必要があります。

#商用プラグインライセンス

NocoBaseアプリケーションをクラスターモードで実行するには、以下のプラグインのサポートが必要です。

まず、上記のプラグインのライセンスを取得していることを確認してください（対応するプラグインライセンスは、商用プラグインサービスプラットフォームから購入できます）。

#システムコンポーネント

アプリケーションインスタンス自体を除く他のシステムコンポーネントは、各チームの運用要件に応じて、運用担当者が自由に選択できます。

#データベース

現在のクラスターモードはアプリケーションインスタンスのみを対象としているため、データベースは一時的にシングルノードのみをサポートしています。もしマスター・スレーブなどのデータベースアーキテクチャをお持ちの場合は、ミドルウェアを介してご自身で実装し、NocoBaseアプリケーションに対して透過的であることを保証する必要があります。

#ミドルウェア

NocoBaseのクラスターモードは、クラスター間の通信と連携を実現するために、いくつかのミドルウェアに依存しています。これには以下が含まれます。

• キャッシュ：Redisベースの分散キャッシュミドルウェアを使用し、データアクセス速度を向上させます。
• 同期シグナル：RedisのStream機能を利用して、クラスター間の同期シグナル伝達を実現します。
• メッセージキュー：RedisまたはRabbitMQベースのメッセージキューミドルウェアを使用し、非同期メッセージ処理を実現します。
• 分散ロック：Redisベースの分散ロックを使用し、クラスター内の共有リソースへの安全なアクセスを保証します。

すべてのミドルウェアでRedisを使用する場合、クラスターの内部ネットワーク（またはKubernetes）内で単一のRedisサービスを起動できます。また、機能ごと（キャッシュ、同期シグナル、メッセージキュー、分散ロック）に個別のRedisサービスを有効にすることも可能です。

推奨バージョン

• Redis：8.0以上、またはBloom Filter機能を含むredis-stackバージョン。
• RabbitMQ：4.0以上。

#共有ストレージ

NocoBaseは、システム関連ファイルをstorageディレクトリに保存する必要があります。マルチノードモードでは、複数のノード間で共有アクセスをサポートするために、クラウドディスク（またはNFS）をマウントする必要があります。そうしないと、ローカルストレージは自動的に同期されず、正常に機能しません。

Kubernetesでデプロイする場合は、Kubernetesデプロイ：共有ストレージの章を参照してください。

#ロードバランシング

クラスターモードでは、リクエストの分散、アプリケーションインスタンスのヘルスチェック、およびフェイルオーバーを実現するために、ロードバランサーが必要です。この部分は、チームの運用要件に応じてご自身で選択・設定してください。

セルフホスト型Nginxを例にとると、設定ファイルに以下の内容を追加します。

upstream myapp {
    # ip_hash; # セッション維持に使用できます。有効にすると、同じクライアントからのリクエストは常に同じバックエンドサーバーに送信されます。
    server 172.31.0.1:13000; # 内部ノード1
    server 172.31.0.2:13000; # 内部ノード2
    server 172.31.0.3:13000; # 内部ノード3
}

server {
    listen 80;

    location / {
        # 定義されたupstreamを使用してロードバランシングを行います
        proxy_pass http://myapp;
        # ... その他の設定
    }
}

これは、リクエストをリバースプロキシし、異なるサーバーノードに分散して処理することを意味します。

他のクラウドサービスプロバイダーが提供するロードバランシングミドルウェアについては、各プロバイダーが提供する設定ドキュメントを参照してください。

#環境変数設定

クラスター内のすべてのノードは、同じ環境変数設定を使用する必要があります。NocoBaseの基本的な環境変数に加えて、以下のミドルウェア関連の環境変数も設定する必要があります。

#マルチコアモード

アプリケーションがマルチコアノードで実行される場合、ノードのマルチコアモードを有効にできます。

# PM2マルチコアモードを有効にする
# CLUSTER_MODE=max # デフォルトでは無効になっています。手動で設定する必要があります。

KubernetesでアプリケーションPodをデプロイする場合は、この設定を無視し、Podのレプリカ数によってアプリケーションインスタンスの数を制御できます。

#キャッシュ

# キャッシュアダプター。クラスターモードではredisと設定する必要があります（未設定の場合、デフォルトはインメモリです）。
CACHE_DEFAULT_STORE=redis

# Redisキャッシュアダプターの接続URL。必ず入力してください。
CACHE_REDIS_URL=

#同期シグナル

# Redis同期アダプターの接続URL。未設定の場合、デフォルトはredis://localhost:6379/0です。
PUBSUB_ADAPTER_REDIS_URL=

#分散ロック

# ロックアダプター。クラスターモードではredisと設定する必要があります（未設定の場合、デフォルトはインメモリローカルロックです）。
LOCK_ADAPTER_DEFAULT=redis

# Redisロックアダプターの接続URL。未設定の場合、デフォルトはredis://localhost:6379/0です。
LOCK_ADAPTER_REDIS_URL=

#メッセージキュー

# Redisをメッセージキューアダプターとして有効にします（未設定の場合、デフォルトはインメモリアダプターです）。
QUEUE_ADAPTER=redis
# Redisメッセージキューアダプターの接続URL。未設定の場合、デフォルトはredis://localhost:6379/0です。
QUEUE_ADAPTER_REDIS_URL=

#Worker ID アロケーター

NocoBaseの一部のシステムコレクションでは、主キーとしてグローバルユニークIDを使用しています。このため、クラスター全体で主キーの競合を防ぐために、Worker IDアロケーターを介して各アプリケーションインスタンスに一意のWorker IDが割り当てられるようにする必要があります。現在のWorker IDの範囲は0〜31であり、これは同じアプリケーションが最大32ノードで同時に実行できることを意味します。グローバルユニークIDの設計については、@nocobase/snowflake-idを参照してください。

# Worker IDアロケーターのRedis接続URL。省略した場合、Worker IDはランダムに割り当てられます。
REDIS_URL=

CACHE_REDIS_URL=redis://localhost:6379/0
PUBSUB_ADAPTER_REDIS_URL=redis://localhost:6379/1
LOCK_ADAPTER_REDIS_URL=redis://localhost:6379/2
QUEUE_ADAPTER_REDIS_URL=redis://localhost:6379/3
REDIS_URL=redis://localhost:6379/4

Kubernetesを使用してクラスターを管理する場合、上記の環境変数をConfigMapまたはSecretに設定できます。詳細については、Kubernetesデプロイを参照してください。

上記のすべての準備作業が完了したら、運用プロセスに進み、アプリケーションインスタンスの管理を続行できます。