Confluence Data Center の技術的概要

Confluence Data Center allows you to run a cluster of multiple Confluence nodes, providing high availability, scalable capacity, and performance at scale.

This guide describes the benefits of clustering, and provides you an overview of what you’ll need to run Confluence in a clustered environment, including infrastructure and hardware requirements.

Ready to get started? See Set up a Confluence Data Center cluster


Is clustering right for my organization?

Clustering is designed for enterprises with large or mission-critical Data Center deployments that require continuous uptime, instant scalability, and performance under high load.

There are a number of benefits to running Confluence in a cluster:

  • High availability and failover: If one node in your cluster goes down, the others take on the load, ensuring your users have uninterrupted access to Confluence.
  • Performance at scale: each node added to your cluster increases concurrent user capacity, and improves response time as user activity grows.
  • Instant scalability: add new nodes to your cluster without downtime or additional licensing fees. Indexes and apps are automatically synced.
  • Disaster recovery: deploy an offsite Disaster Recovery system for business continuity, even in the event of a complete system outage. Shared application indexes get you back up and running quickly.

Clustering is only available with a Data Center license. Learn more about upgrading to Data Center.

Clustering architecture


A Confluence Data Center cluster consists of:

  • Multiple identical application nodes running Confluence Data Center.
  • A load balancer to distribute traffic to all of your application nodes.
  • 添付ファイルやその他の共有ファイルを保存する共有ファイル システム。 
  • すべてのノードが読み取るおよび書き込むデータベース

All application nodes are active and process requests. A user will access the same Confluence node for all requests until their session times out, they log out, or a node is removed from the cluster. 

The image below shows a typical configuration:


Your Data Center license is based on the number of users in your cluster, rather than the number of nodes. This means you can scale your environment without additional licensing fees for new servers or CPU.

You can monitor the available license seats in the License Details page in the admin console.

このプロセスを自動化する(たとえば、割り当て限界に近づいた場合にアラートを送信する)場合は、REST API を使用することができます。


以下の GET リクエストは、システム管理者権限で認証されたユーザーが必要です。このリクエストは JSON を返します。


利用可能な機能やインフラストラクチャは、Confluence ライセンスによって決定されます。Server ライセンスと Data Center ライセンスの違いの完全な一覧については、「Confluence Server と Data Center の機能の比較」を参照してください。 

ホーム ディレクトリ

To run Confluence in a cluster, you'll need an additional home directory, known as the shared home.

Each Confluence node has a local home that contains logs, caches, Lucene indexes and configuration files. Everything else is stored in the shared home, which is accessible to each Confluence node in the cluster. Marketplace apps can choose whether to store data in the local or shared home, depending on the needs of the app. 

ローカル ホームと共有ホームの内容の概要は次のとおりです。

ローカル ホーム共有ホーム
  • logs
  • caches 
  • Lucene インデックス
  • 設定ファイル
  • plugins
  • attachments
  • アバター / プロフィール写真
  • アイコン
  • エクスポート ファイル
  • インポート ファイル
  • plugins



When clustered, Confluence uses a distributed cache that is managed using Hazelcast. Data is evenly partitioned across all the Confluence nodes in a cluster, instead of being replicated on each node. This allows for better horizontal scalability, and requires less storage and processing power than a fully replicated cache. 

Because of this caching solution, to minimize latency, your nodes should be located in the same physical location, or region (for AWS and Azure).


Each individual Confluence application node stores its own full copy of the index. A journal service keeps each index in sync.

初めてクラスタをセットアップする場合、インデックスを含むローカル ホーム ディレクトリを1つ目のノードから新しい各ノードにコピーします。


Confluence ノードが短時間(数時間)クラスタから切断された場合、クラスタに再接続した際に、ジャーナル サービスを使用して、最新のインデックスのコピーを取得することができます。ノードが長時間(数日)ダウンした場合、Lucene インデックスは失効してしまい、既存のノードからノードの起動プロセスの一部として、スナップショットの復旧をリクエストします。 



ClusterSafetyJob は、Confluence でタスクを30秒ごとに実行するようにスケジュールされています。クラスタでは、このジョブは1つの Confluence ノードでのみ実行されます。スケジュールされたタスクは安全番号で動作します。安全番号はクラスタ全体で使用されるデータベースと分散キャッシュの両方に格納されているランダムに生成された番号です。ClusterSafetyJob はデータベースの値とキャッシュの値を比較し、値が異なる場合は、Confluence はノードをシャット ダウンします。これはクラスタ スプリット ブレインと呼ばれています。この安全性のメカニズムは、クラスタ ノードが矛盾した状態にならないようにするために使用されます。 

クラスタ スプリット ブレインが発生した場合、クラスタ化されているノード間の適切なネットワーク接続を確認する必要があります。ほとんどのマルチキャスト トラフィックはブロックされているか、正しくルーティングされません。


クラスタ セーフティなスケジュールされたジョブが実行される頻度と Hazelcast ハートビートの期間を変更する(クラスタからノードが削除されるまでのノードの通信不能期間を制御)ことで、クラスタの稼働時間とデータ整合性のバランスを微調整することができます。ほとんどの場合、デフォルト値が適切ですが、場合によっては、たとえば、稼働時間の増加のためにデータ整合性をトレード オフするように決定することができます。



Hazelcast heartbeat効果
1 分1 分クラスタ パニックを発生させずに、最大1分のネットワーク中断またはガベージ コレクションの一時停止を取ることができます。ただし、2つのノードが接続できなくなった場合、競合したデータは最大1分でデータベースに書き込まれ、データ整合性に影響を与える可能性があります。
10 分30秒

クラスタからノードを退去せずに、最大30秒のネットワーク中断またはガベージ コレクションの一時停止を取ることができます。退去されたノードは、クラスタセーフティジョブが稼働し、問題のあるノードをシャットダウンする前に、クラスタに再結合するまでに10分あります。これはサイトで高いアップタイムを引き起こすかもしれませんが、競合したデータは最大10分でデータベースに書き込まれ、データ整合性に影響を与える可能性があります。


Hazelcast heartbeat効果

ネットワークの中断またはガベージ コレクションの一時停止が15秒を超えると、クラスタ パニックが発生します。これによってサイトのダウンタイムは大きくなりますが、ノードが互いに通信できない場合、最大15秒間だけデータベースに書き込むことがことができるため、高いデータ整合性が保証されます。

15秒1 分

クラスタからノードを削除せずに、最大1分のネットワーク中断またはガベージ コレクションの一時停止を取ることができます。ノードが削除されると、最大15秒間だけデータを書き込むことができ、データ整合性への影響を最小化することができます。

クラスタ セーフティなスケジュールされたジョブを変更する方法の詳細については、「スケジュールされたジョブ」を参照してください。 システム プロパティを使用して、Hazelcast ハートビートの既定設定を変更できます。詳細については、「システム プロパティを設定する」を参照してください。

クラスタ ロックとイベント ハンドリング

アクションが1つのノードでだけ実行される場合、たとえば、スケジュールされたジョブまたは日次のメール通知の送信の場合、Confluence はクラスタ ロックを使用して、アクションが1つのノードでだけ実行されることを保証します。  

同様に、一部のアクションは 1 つのノードで実行してから、他のノードに発行する必要があります。イベント ハンドリングは、現在のトランザクションがコミットおよび完了されたときにのみ、Confluence がクラスタ イベントを発行することを保証します。これにより、イベントが受信および処理されたときに、データベースに格納された任意のデータをクラスタ内の他のインスタンスから利用できるようになります。イベント ブロードキャストはアプリの有効化や無効化などの特定のイベントに対してのみ実行されます。

クラスタ ノード検出

クラスタ ノードを設定する場合、各クラスタノードの IP アドレスかマルチキャスト アドレスのいずれかを指定します。


Confluence はマルチキャスト ネットワーク アドレスにジョイン リクエストをブロードキャストします。Confluence はマルチキャスト アドレスの UDP ポートを開くことができる必要があり、それができない場合、他のクラスタノードを検出できません。ノードが検出されたら、それぞれキャッシュ更新のために接続できるユニキャスト(通常の) IP アドレスとポートで応答します。Confluence は他のノードとの通常の通信のために、UDP ポートを開くことができる必要があります。

マルチキャスト アドレスはクラスタ名から自動生成されるか、最初のノードのセットアップ時に自分で入力することができます。 




AWS上でConfluence Data Center を実行する場合は、クイックスタートオプションが、新規または既存の仮想プライベートクラウド(VPC)でのConfluence Data Center の展開を支援するために提供されています。アマゾンRDS PostgreSQLデータベースとアプリケーションのロードバランサは、すべて構成され、数分で使用する準備ができ、ConfluenceとSynchrony のノードを取得します。AWSを初めての場合は、ステップバイステップのクイックスタートガイドが、プロセス全体を通して支援します。

Confluence は、Amazon Elastic File System (EFS) をサポートする地域でのみデプロイできます。詳細は、「AWS で Confluence Data Center を実行する」を参照してください。 

クイック スタートを使用して Confluence をデプロイしている場合、EC2 インスタンスにインストールされている Java Runtime Engine (/usr/lib/jvm/jre/) ではなく、Confluence (/opt/atlassian/confluence/jre/) にバンドルされている JRE が使用されている点に注意してください。 


Confluence と同じサーバーで他のアプリケーション (コア オペレーティング システム サービスを除く) を実行しないでください。アトラシアン ソフトウェアの専用サーバーでの Confluence、Jira、および Bamboo の実行は、小規模なインストールではうまく動作しますが、大規模に実行する場合はうまくいきません。 

Confluence Data Center は仮想マシンで正常に実行できます。マルチキャストを使用する予定がある場合、Amazon Web Service (AWS)はマルチキャスト トラフィックをサポートしていないため、AWS で Confluence Data Center を実行することはできません。


各ノードはまったく同じである必要はありませんが、一貫性のあるパフォーマンスのために、可能な限り同質になるようにします。すべてのクラスタ ノードは以下を満たす必要があります。

  • be located in the same data center, or region (for AWS and Azure)
  • (Confluence ノードの場合)同じ Confluence バージョン、または(Synchrony ノードの場合)同じ Synchrony バージョンを実行する
  • 同じ OS、Java、およびアプリケーション サーバー バージョン
  • 同じメモリ設定(JVM と物理メモリの両方)(推奨)
  • 同じタイムゾーンで設定されている(および現在の同期された時間を維持する)。これを保証するには ntpd または同様なサービスを使用することをお勧めします。 

(warning) クラスタでさまざまな問題が発生する可能性があるため、ノードのクロックが逸脱していないことを確認する必要があります。

How many nodes?

Your Data Center license does not restrict the number of nodes in your cluster. The right number of nodes depends on the size and shape of your Confluence site, and the size of your nodes. See our Confluence Data Center load profiles guide for help sizing your instance. In general, we recommend starting small and growing as you need.


Confluence ノード

各 Confluence ノードの RAM は、最小 10 GB にすることをお勧めします。同時接続ユーザー数が増えると、大量の RAM が消費されます。


RAM各 Confluence ノードの内訳
  • オペレーティング システムとユーティリティ用に 2 GB
  • Confluence JVM 用に 4 GB (-Xmx 3GB)
  • 外部プロセス プール用に 2 GB (-Xmx 512 MB のサンドボックスを 2 つ)
  • Synchrony 用に 2 GB
  • オペレーティング システムとユーティリティ用に 2 GB
  • Confluence JVM 用に 10 GB (-Xmx 8GB)
  • 外部プロセス プール用に 2 GB (-Xmx 512 MB のサンドボックスを 2 つ)
  • Synchrony 用に 2 GB

Confluence アプリケーションの最大ヒープ (-Xmx) は、 または setenv.bat ファイルで設定されます。Data Center の場合、既定値を増やす必要があります。最小ヒープ (Xms) と最大 (Xmx) ヒープを同じ値にすることをお勧めします。 

外部プロセス プールは、個々の Confluence ノードの影響を最小化するためにメモリ集約タスクを外部化するのに使用されます。プロセスは Confluence で管理されます。各プロセス (サンドボックス) の最大ヒープ (-Xmx) とサンドボックスの数はシステム プロパティを使用して設定されます。多くの場合、既定の設定が適切であり、変更は不要です。 

スタンドアロンの Synchrony クラスタ ノード

Synchrony は共同編集に必要です。Synchrony は既定では Confluence によって管理されていますが、独自のクラスタで Synchrony を実行するようにすることもできます。利用可能な選択肢の詳細については、「Confluence および Synchrony で利用可能な設定」を参照してください。 

独自の Synchrony クラスタを実行する場合、スタンドアロン Synchrony に対して 2 GB のメモリを割り当てることをお勧めします。ここでは、専用の Synchrony ノードへのメモリ割り当ての例を示します。 

物理 RAM各 Synchrony ノードの内訳


  • オペレーティング システムとユーティリティ用に 2 GB
  • Synchrony JVM 用に 2GB (-Xmx 1GB)


クラスタ データベースについてもっとも重要な要件は、そのノード数をサポートするのに十分なコネクションが利用可能であることです。


  • 各 Confluence ノードの最大プールサイズは20コネクションです。
  • 各 Synchrony ノードの最大プール サイズは15コネクションです(デフォルト)。
  • 3 Confluence ノードおよび 3 Synchrony ノードの実行を計画しています。 

データベース サーバーは Confluence データベースに対して最低105コネクションを許可する必要があります。実際には、デバックや管理目的で最大以上のコネクションが必要な場合があります。

目的のデータベースが現在「サポートされているプラットフォーム」に記載されていることも確認する必要があります。平均的なクラスタ ソリューションの負荷はスタンドアロン インストールよりも高くなるため、サポートされているデータベースを使用することが重要です。

また、サポートされているデータベース ドライバを使用する必要があります。サポートされていないドライバやカスタム JDBC ドライバ (または JNDI データソース コネクションで driverClassName を使用している場合)、共同編集でエラーが発生し、失敗します。サポートされているドライバの一覧については、「データベース JDBC ドライバ」を参照してください。


Running Confluence Data Center in a cluster removes the application server as a single point of failure. You can also do this for the database through the following supported configurations:

  • Amazon RDS Multi-AZ: このデータベース セットアップは、別のアベイラビリティ ゾーンのスタンバイにレプリケートするプライマリ データベースを備えています。プライマリが停止した場合、スタンバイが代わりになります。

  • Amazon PostgreSQL 互換 Aurora: 1 つ以上のリーダー (別のアベイラビリティ ゾーンを推奨) にレプリケートするデータベース ノードを備えたクラスタです。ライターが停止した場合、Aurora はライターの 1 つをプロモートして代わりにします。

AWSクイックスタート デプロイ オプションを使用するといずれかの方法で Confluence Data Center を最初からデプロイできます。既存の Confluence Data Center インスタンスで Amazon Aurora クラスタをセットアップする場合、「Amazon Aurora を使用するために Confluence Data Center を構成する」をご参照ください。

共有ホーム ディレクトリおよびストレージ要件

すべての Confluence クラスタは同じパスの共有ディレクトリへのアクセス権限を持っている必要があります。NFS および SMB/CIFS 共有が共有ディレクトリの場所としてサポートされています。このディレクトリには大量のデータ(添付ファイルやバックアップを含む)が格納されるため、十分なサイズにし、必要に応じて利用可能なディスク領域を増やす方法を計画する必要があります。

ロード バランサ

最も慣れ親しんだロード バランサを使用することをお勧めします。ロード バランサは「セッション アフィニティ」と WebSockets をサポートしている必要があります。これは Confluence と Synchrony の両方で必要です。AWS上で展開している場合は、アプリケーションのロードバランサ(ALB)を使用する必要があります。


  • キューは、ロード バランサでリクエストします。ノードへの要求の最大数が Tomcat で受け入れ可能な HTTP スレッドの合計数を超えていないことを確認することで、処理可能な数を超える要求がノードに送信されるのを避けることができます。<install-directory>/conf/server.xml で maxThreads を確認することができます。
  • 非常に迅速に、すべてのノード間での問題を伝播できるため、他のノードに失敗した、べき等の要求を再生しないでください。
  • 最小接続 の使用で、ラウンドロビンとしてではなく、 負荷バランスを行う方法はノードがクラスタに参加または削除された後に再結合する際に、よりよい負荷のバランスをとることができます。 

多くのロード バランサでは、自動的にプールからバックエンドを削除するため、バックエンドの正常性を常に確認するための URL が必要です。これには安定しており高速であるが不要なリソースを消費しない程度に十分軽量な URL を使用することが重要です。以下の URL は Confluence のステータスを返し、この目的に使用することができます。 

予想 HTTP ステータス
200 OK
すべてのステータス コードとレスポンスを表示する...

HTTP ステータス コード

レスポンス エンティティ


















アプリケーションが予期しない方法で起動に失敗(web アプリケーションのデプロイが失敗)


  • ノードを削除する前に2回連続して失敗を待ちます。
  • ノードがプールから削除される前に30秒と言うならば、ノードへの既存の接続が終了するのを許可します。  


サーバー間の通信に個別のネットワーク アダプタを使用します。クラスタ ノードはサーバー間通信用の個別の物理ネットワーク(個別の NIC など)を持っている必要があります。これはクラスタの実行を高速および信頼性を高くするのに最適な方法です。その他のデータ ストリーミングを多数持つネットワークを介してクラスタ ノードに接続する場合、パフォーマンスの問題が発生する可能性があります。 


Confluence 6.0 以降の共同編集は、別のプロセスとして実行される Synchrony で実行されています。

Confluence Data Center ライセンスをお持ちの場合、Synchrony を実行するには 2 つのメソッドを使用できます。

  • Confluence で管理 (推奨)
    Confluence は同じノードで自動的に Synchrony プロセスを起動して管理します。手動による操作は不要です。 
  • スタンドアロンの Synchrony クラスタ (ユーザーによる管理)
    ユーザーはスタンドアロンな Synchrony を必要なノード数で、独自のクラスタでデプロイおよび管理します。大規模なセットアップが必要です。 

シンプルなセットアップを実現してメンテナンスの労力を極力減らしたい場合、Synchrony を Confluence で管理することをおすすめします。完全な制御を実現したい場合や、エディタの高い可用性の確保が必須である場合、独自のクラスタで Synchrony を管理することが、組織に最適なソリューションである可能性があります。 

App compatibility

The process for installing Marketplace apps (also known as add-ons or plugins) in a Confluence cluster is the same as for a standalone installation. You will not need to stop the cluster, or bring down any nodes to install or update an app. 

Atlassian Marketplace では、アプリが Confluence Data Center との互換性を持っているかを確認できます。

独自の Confluence プラグイン (アプリ) を開発している場合、アプリがクラスタ互換であるかどうかを確認する方法について、「アプリがクラスタで適切に動作するかを確認するにはどうしたらよいですか?」の開発者ドキュメントをご参照ください。 


Head to Set up a Confluence Data Center cluster for a step-by-step guide to enabling and configuring your cluster.

最終更新日: 2019 年 2 月 21 日




Powered by Confluence and Scroll Viewport.