複数のノードを持つCollabora Onlineクラスタをセットアップする方法

Collabora Online クラスターは、単にcoolwsdラウンドロビン ロードバランサーの背後にある複数の正常なサーバーで構成されているわけではありません。共同編集は、同じドキュメントに対するリクエストを同じ Collabora ノードに送信することに依存しています。WOPISrcそのため、Collabora の Kubernetes チャートでは、WOPI ドキュメント識別子によるルーティングが規定されています。このガイドでは、Kubernetes 上で保守されている Collabora Helm チャートを具体的なマルチノード構成として使用し、異なるイングレス コントローラーや Kubernetes 以外のデプロイメントの場合に変更する必要がある点について説明します。

検証済み： Collaboraのチャートは複数のレプリカをサポートし、ドキュメントごとのアフィニティを記述しますWOPISrc。デプロイメント依存：イングレス注釈、TLS終端、リソース要求、セッションコントローラが適切かどうか。想定すべきでない事項：すべてのロードバランサーまたはすべての「スティッキーセッション」設定がドキュメントのアフィニティを維持するとは限りません。ユーザーをクラスタに移動する前に、コントローラ固有の動作を確認し、テストしてください。

クラスターの機能と非機能

標準的なマルチレプリカ構成では、各Collaboraノードがドキュメントを配信できますが、プロキシは各ドキュメントのリクエストを1つのノードに送信します。これにより、個々のドキュメントがプール全体に分散されます。ただし、これはすべてのノードが同じライブ編集プロセスを共有することや、実行中のドキュメントがノードの停止時に常にシームレスに移動できることを意味するものではありません。

Collaboraは、Kubernetes用のCOOLコントローラーについてもドキュメント化しており、これはセッション管理のアプローチが異なります。ルーティングと構成は、スタンドアロンのレプリカプールとは異なります。この記事では、よりシンプルなWOPIソースアフィニティモデルの構成について説明します。ご使用のリリース用にコントローラーをデプロイして構成していない限り、コントローラー固有のルートトークン設定と組み合わせないでください。

対応策：容量とノード冗長性を確保するために、基本的な複製型Collaboraサービスが必要か、セッション認識機能を備えたコントローラー管理型セットアップが必要かを決定してください。後者の場合、追加のコンポーネントとバージョン固有の設定が必要になります。この方法を検討する場合は、 Collaboraオンラインコントローラーの概要を確認してください。

展開する前に

• 動作するKubernetesクラスター、Helm、公開Collaboraホスト名用のDNS、およびTLS対応のイングレスプロキシまたはリバースプロキシ。
• NextcloudなどのWOPI統合では、個々のポッドアドレスではなく、単一のパブリックなCollaboraホスト名を使用するように構成します。
• Collaboraが受け入れを許可されているWOPIホスト（複数可）を、チャートのcollabora.aliasgroups設定で指定します。
• ドキュメント処理に必要なCPUとメモリ容量に加え、ポッドの状態、イングレスログ、リソース使用状況を検査できる機能。
• 初回展開のためのメンテナンス期間と、2つの別々のユーザーアカウントを含むテストドキュメント。

Collabora Online専用サービスは、Nextcloudに組み込まれているCODEサーバーとは異なります。Nextcloudは、組み込みオプションを個人利用または小規模チーム向けとしており、専用サーバーのような高度なスケーラビリティ機能は備えていません。対策：マルチノードのCollaboraプールが必要な場合は、専用サービスを検討し、導入に適したライセンスとサポートモデルを確認してください。Nextcloud Officeのインストールガイドを参照してください。

ステップ1：ルーティングモデルを選択する

文書化されたスタンドアロンモデルではWOPISrc、WOPIリクエストでドキュメントを識別するハッシュ値が使用されます。1つのドキュメントに対するリクエストは同じポッドに到達する必要がありますが、異なるドキュメントに対するリクエストは複数のポッドに分散できます。一般的なラウンドロビンルールではこの要件を満たしません。

対処方法：チャートのドキュメントでサポートされているイングレス実装（ドキュメントに記載されているNGINXまたはHAProxyのイングレス例など）を使用するか、クラスタが適切なイングレスコントローラを許可していない場合は、チャートの名前空間内のリバースプロキシを使用してください。別のプロキシを使用する場合は、通常のHTTPリクエストと長時間のWebSocket接続の両方について、WOPIソースによるリクエストを一貫してルーティングできることを確認してください。

ステップ2：チャートを確認し、バージョンを選択します。

チャートとその値は時間とともに変化します。インストールする前に、古いリリース用に作成された設定をコピーするのではなく、最新の公式チャートREADMEと値を確認してください。以下の例は、2026年10月6日にレビューされた、メンテナンスされているCollaboraチャートのドキュメントに基づいています。インストール日においては、リポジトリの最新のリリースノートと値を正式な情報として扱ってください。

helm repo add collabora https://collaboraonline.github.io/online/
helm repo update
helm search repo collabora/collabora-online --versions
helm show values collabora/collabora-online

アクション：変更管理ポリシーに合致するチャートバージョンを選択し、デプロイされる Collabora イメージバージョンを記録します。再現可能なアップグレードのためにチャートバージョンを固定し、本番環境でレビューされていない浮動バージョンに依存しないようにしてください。チャート自体のセットアップガイドは、Collabora Online for Kubernetes の READMEです。

ステップ3：3つのレプリカの値を用意する

この例では、NGINX Ingress Controller、IngressでのTLS終端、および外部WOPIホストを前提としていますcloud.example.com。ホスト名はご自身のものに置き換えてください。TLS終端が別の場所にある場合、またはHAProxyを使用する場合は、そのコントローラーの対応するドキュメントに記載されている設定を使用してください。

replicaCount: 3

autoscaling:
  enabled: false

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_WOPISrc"
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
  hosts:
    - host: office.example.com
      paths:
        - path: /
          pathType: ImplementationSpecific

collabora:
  aliasgroups:
    - host: "https://cloud.example.com:443"
  extra_params: --o:ssl.enable=false --o:ssl.termination=true

上記のハッシュ注釈とタイムアウト値は、チャートのNGINXの例に示されています。このextra_params行は、リバースプロキシがTLSを終端し、HTTP経由でCollaboraに接続する場合にのみ適切です。TLSトポロジーが異なる場合は、変更せずに適用しないでください。イングレスTLSシークレットとホストは、証明書マネージャとローカルチャートの値に従って設定してください。抜粋では、プロバイダ固有の設定は省略されています。

アクション:これをとして保存しmy_values.yaml、イングレスに必要なTLS構成を追加し、すべてのキーを選択したチャートリリースのと比較しますvalues.yaml。Collaboraのパブリックホスト名は、DNS、TLS、統合のCollabora URL、およびプロキシルーティング全体で一貫してください。

ステップ4：Collaboraリリースをインストールする

専用のネームスペースにインストールしてください。<chart-version>手順2で選択したバージョンに置き換えてください。ここでの山括弧は説明用のプレースホルダーであり、そのまま入力しないでください。

helm install --create-namespace   --namespace collabora   collabora-online collabora/collabora-online   --version <chart-version>   -f my_values.yaml

既存のリリースについては、リリースの移行ノートと変更内容を確認した上で、計画的な Helm アップグレードを実行してください。最初のスケーリング変更と同時にメジャーイメージやチャートの更新をデプロイすることは避けてください。一度に 1 つの変数のみを変更することで、障害の特定が容易になります。

対応策：リリースを検査し、すべてのレプリカが準備完了するまで待機する。

helm status collabora-online -n collabora
kubectl get pods,svc,ingress -n collabora
kubectl get events -n collabora --sort-by=.lastTimestamp

3つのレプリカが要求されたとしても、3つの正常なノードがトラフィックを処理しているとは限りません。準備状況、最近の再起動、スケジューリング、およびイングレスエンドポイントを確認してください。Podが保留状態のままの場合は、利用可能なクラスタ容量、およびチャート値に示されているリソース要求と制限を確認してください。

ステップ5：WOPIアプリケーションを接続する

ファイルプラットフォームのオフィス統合設定で、CollaboraサーバーのURLをパブリックエンドポイント（例：）に設定しますhttps://office.example.com。統合自体がクラスター内で実行され、かつプライベートルーティングが設計で明示的にサポートされている場合を除き、アプリケーションをPod IPやKubernetes専用のサービス名に向けないでください。

ホスト名はaliasgroups、ドキュメントを保存および提供する WOPI ホストを識別するものでなければなりません。Collabora のホスト名ではありません。ホスト名が一致しないと、Collabora のポッドとイングレスが正常に動作している場合でも、WOPI ホストの検証エラーが発生する可能性があります。

対処方法：統合設定に同じCollaboraの公開URLを入力し、保存して、接続または検出チェックが成功することを確認してください。失敗した場合は、レプリカ数を変更する前に、アプリケーションのWOPI許可リスト、Collaboraのエイリアスグループ、DNS、TLS、およびプロキシヘッダーを確認してください。

ステップ6：ドキュメントの親和性とコラボレーションをテストする

テストドキュメントを開き、イングレスログまたはプロキシログを調べて、どのバックエンドがドキュメントを提供しているかを確認します。次に、同じドキュメントを別のユーザーセッションから開き、両方のユーザーが編集でき、互いの変更内容を確認できることを確認します。別のドキュメントを開き、ロードバランサーがそれを別の正常なポッドに送信できることを確認します。このテストは、ランディングページがHTTP 200を返すかどうかだけでなく、ルーティングとコラボレーションに関するものです。

対処方法： WOPIソースハッシュが存在し、WebSocketアップグレードを含む同一ドキュメントに対して生成されたリクエストに一貫して適用されていることを確認してください。ユーザー間で編集内容が表示されない場合は、WOPIホストまたはブラウザのキャッシュを調査する前に、同一ドキュメントのバックエンド選択を比較してください。

ステップ7：ヘルス処理とノード損失のテスト

準備状況チェックにより、異常な状態または起動中のポッドがサービスから除外されるようになります。チャートには起動、準備状況、およびライブネスプローブの設定が含まれていますが、正確な動作とタイミングは、選択したチャートのバージョンとクラスターによって異なります。ポッドが利用不能になると、そのポッドで現在実行中のドキュメントが中断される可能性があります。基本的なアフィニティプールは、ライブセッションレプリケーションとして説明すべきではありません。

対策：テスト環境で、アクティブな編集セッション中にサービスからポッドを1つ削除し、クライアントの動作とプロキシルーティングを観察した後、ドキュメントを再度開き、正常なポッドに到達することを確認します。承認済みの保守計画がない限り、アクティブな本番環境のドキュメントでこのテストを実行しないでください。セッションの継続性をより厳密に確保するには、COOLコントローラーとそのバージョン固有のルートトークン設定を評価してください。

ステップ8：監視、調整、および計画的なアップグレード

ポッドの再起動、CPUとメモリの使用状況、リクエストとWebSocketのエラー、イングレスの遅延、ドキュメントの読み込みや再接続に関するユーザーからの報告などを追跡します。Collaboraのチャートドキュメントには、Kubernetesの監視に関するガイダンスが含まれています。リソースは、サンプル数値をコピーするのではなく、観測されたワークロードに基づいて設定してください。ドキュメントのサイズ、同時セッション数、フォント、編集パターンなど、すべてが容量に影響します。

Collaboraでは、クライアントがバージョン固有の一貫性のあるWebアセットを受け取れるよう、ロードバランシングされたすべてのノードで同じバージョンを実行することを推奨しています。アップグレード中は、チャートでサポートされているロールアウト戦略を使用し、準備状況とログを監視し、変更完了を宣言する前に複数のユーザーから開いているドキュメントをテストしてください。

対策：チャートのバージョン、イメージのバージョン、値ファイル、およびテスト結果をまとめて変更記録に保管してください。アップグレードをスケジュールし、すべてのレプリカが目的のバージョンに収束することを確認し、チャートでサポートされているロールバック動作と互換性のあるロールバック計画を保持してください。

よくある誤解をチェックする

• 「3つのレプリカがあれば、自動的に動作するクラスタが作成されます。」レプリカだけではドキュメントアフィニティは構成されません。WOPIソースのイングレスハッシュが正しく機能しているか、コントローラが意図したセッションルーティングを提供していることを確認してください。
• 「ユーザーのIPアドレスに基づくスティッキーセッションで十分です。」これは、CollaboraのスタンドアロンKubernetesプールに関するチャートに記載されているルールではありません。1つのドキュメントで共同作業を行うユーザーは、異なるデバイスやネットワークからアクセスした場合でも、同じノードに集約される必要があります。ドキュメントベースのアフィニティを設定し、2人のユーザーでテストしてください。
• 「ホームページが正常に動作していれば、クラスターの準備は完了です。」これは、HTTPリクエストが1回正常に返されたことしか証明していません。ドキュメントの開き方や共同編集、WebSocketのアップグレード、Podが利用不能になった場合の動作などをテストしてください。
• 「ノードを追加することで、アクティブなセッションがノードの障害発生後も維持されることが保証されます。」基本的なWOPIソースアフィニティプールは、ドキュメントをノードにルーティングしますが、メモリ内の編集プロセスが複製されることを保証するものではありません。制御されたテストで想定される復旧動作を確認するか、コントローラの個別のセッション管理機能を評価してください。

Kubernetes以外のインストール環境の場合、アーキテクチャの基本原則は同じですが、Kubernetesチャートコマンドとイングレス注釈は適用されません。Collaboraのバージョンとロードバランサーに対応したプロキシ構成を使用し、WebSocket接続が長時間持続するように設定し、WOPIソースを使用してドキュメントごとのルーティングを実装してください。Collabora Online SDKマニュアルには、ロードバランシングとWOPISrcアフィニティ要件について記載されています。ご使用のリリース版のマニュアルで該当箇所をご確認ください。