Confluence Data Center の技術的概要
このページは、利用頻度の高いミッションクリティカルな Confluence サイトのニーズを満たすように作られた、Confluence Data Center についての情報を提供します。
動作の仕組み
On this page
基本
Confluence Data Center では、以下の画像のように、Confluence をクラスタでセットアップできます。
- Confluence アプリケーションやその他の必須コンポーネントを実行する複数のサーバー ノード。
- 添付ファイルやその他の共有ファイルを保存する共有ファイル システム。
- すべてのノードが読み取るおよび書き込むデータベース
- リクエストを各ノードに均等に送るロード バランサ
すべての Confluence ノードがアクティブ状態にあり、リクエストを処理します。 ユーザーは、セッションのタイム アウト、ログアウト、またはクラスタからノードが削除されるまで、すべてのリクエストについて同じ Confluence ノードにアクセスします。
ライセンス
Data Center ライセンスは、ノードの数ではなく、クラスタのユーザー数に基づいています。ライセンス ページで利用可能なライセンス数を確認することができます。
このプロセスを自動化する（たとえば、割り当て限界に近づいた場合にアラートを送信する）場合は、REST API を使用することができます。
利用可能な機能やインフラストラクチャは、Confluence ライセンスによって決定されます。Server ライセンスと Data Center ライセンスの違いの完全な一覧については、「Confluence Server と Data Center の機能の比較」を参照してください。
ホーム ディレクトリ
Confluence にはローカル ホームと共有ホームの概念があります。
各 Confluence ノードには、ログ、キャッシュ、Lucene インデックス、および設定ファイルを含むローカル ホームがあります。他のすべてのデータは共有ホームに格納され、クラスタ内の各 Confluence ノードからアクセスすることができます。Marketplace アプリについては、アプリのニーズに応じて、データをローカル ホームに格納するか共有ホームに格納するかを選択することができます。
ローカル ホームと共有ホームの内容の概要は次のとおりです。
| ローカル ホーム | 共有ホーム |
|---|---|
|
|
現在添付ファイルをデータベースに保存している場合、そのまま保存し続けることができますが、新しいインストールでは利用できません。
キャッシング
Confluence は Hazelcast を使用して管理される分散キャッシュを使用します。データは各ノードにレプリケートされるのではなく、クラスタ内のすべての Confluence ノード全体で均等に分割されます。これによって、水平拡張性が向上し、必要なストレージと処理能力は完全にレプリケートされたキャッシュよりも少なくなります。
このキャッシュ ソリューションのため、遅延を最小化するには、ノードが同じ物理ロケーションにある必要があります。
インデックス
Confluence インデックスの完全なコピーは各 Confluence ノードに個別に格納されます。ジャーナル サービスは同期で各インデックスを保持します。
初めてクラスタをセットアップする場合、インデックスを含むローカル ホーム ディレクトリを1つ目のノードから新しい各ノードにコピーします。
既存のクラスタに新しいConfluenceのノードを追加するときは、新しいノードに既存のノードのローカルホームディレクトリをコピーします。新しいノードを起動すると、Confluenceは、インデックスが最新のものかチェックします。そうでない場合、共有ホームディレクトリから、あるいはを実行しているノード（マッチングビルド番号付き）からインデックスの回復スナップショットを要求し、起動プロセスを続行する前にインデックスディレクトリに展開します。スナップショットを生成することができないか、時間内に新しいノードによって受信されない場合は、既存のインデックスファイルが削除され、Confluenceは完全な再インデックスを実行します。
Confluence ノードが短時間（数時間）クラスタから切断された場合、クラスタに再接続した際に、ジャーナル サービスを使用して、最新のインデックスのコピーを取得することができます。ノードが長時間（数日）ダウンした場合、Lucene インデックスは失効してしまい、既存のノードからノードの起動プロセスの一部として、スナップショットの復旧をリクエストします。
すべてのノードのインデックスに問題がある疑いがある場合は、一時的に残りの各ノードに新しいインデックスをコピーし、そのノード上のインデックスを再構築し、1ノード上のインデックスの回復を無効にすることができます。
クラスタの安全なメカニズム
ClusterSafetyJob は、Confluence でタスクを30秒ごとに実行するようにスケジュールされています。クラスタでは、このジョブは1つの Confluence ノードでのみ実行されます。スケジュールされたタスクは安全番号で動作します。安全番号はクラスタ全体で使用されるデータベースと分散キャッシュの両方に格納されているランダムに生成された番号です。ClusterSafetyJob はデータベースの値とキャッシュの値を比較し、値が異なる場合は、Confluence はノードをシャット ダウンします。これはクラスタ スプリット ブレインと呼ばれています。この安全性のメカニズムは、クラスタ ノードが矛盾した状態にならないようにするために使用されます。
クラスタ スプリット ブレインが発生した場合、クラスタ化されているノード間の適切なネットワーク接続を確認する必要があります。ほとんどのマルチキャスト トラフィックはブロックされているか、正しくルーティングされません。
このメカニズムはスタンドアロンの Confluence にも存在しています。
稼働時間とデータの整合性のバランス
クラスタ セーフティなスケジュールされたジョブが実行される頻度と Hazelcast ハートビートの期間を変更する（クラスタからノードが削除されるまでのノードの通信不能期間を制御）ことで、クラスタの稼働時間とデータ整合性のバランスを微調整することができます。ほとんどの場合、デフォルト値が適切ですが、場合によっては、たとえば、稼働時間の増加のためにデータ整合性をトレード オフするように決定することができます。
クラスタ ロックとイベント ハンドリング
アクションが1つのノードでだけ実行される場合、たとえば、スケジュールされたジョブまたは日次のメール通知の送信の場合、Confluence はクラスタ ロックを使用して、アクションが1つのノードでだけ実行されることを保証します。
同様に、一部のアクションは 1 つのノードで実行してから、他のノードに発行する必要があります。イベント ハンドリングは、現在のトランザクションがコミットおよび完了されたときにのみ、Confluence がクラスタ イベントを発行することを保証します。これにより、イベントが受信および処理されたときに、データベースに格納された任意のデータをクラスタ内の他のインスタンスから利用できるようになります。イベント ブロードキャストはアプリの有効化や無効化などの特定のイベントに対してのみ実行されます。
クラスタ ノード検出
クラスタ ノードを設定する場合、各クラスタノードの IP アドレスかマルチキャスト アドレスのいずれかを指定します。
マルチキャストを使用する場合：
Confluence はマルチキャスト ネットワーク アドレスにジョイン リクエストをブロードキャストします。Confluence はマルチキャスト アドレスの UDP ポートを開くことができる必要があり、それができない場合、他のクラスタノードを検出できません。ノードが検出されたら、それぞれキャッシュ更新のために接続できるユニキャスト（通常の） IP アドレスとポートで応答します。Confluence は他のノードとの通常の通信のために、UDP ポートを開くことができる必要があります。
マルチキャスト アドレスはクラスタ名から自動生成されるか、最初のノードのセットアップ時に自分で入力することができます。
インフラストラクチャとハードウェアの要件
ハードウェアやインフラの選択はあなた次第です。以下はハードウェアおよびインフラストラクチャ要件を計画するときに考える必要がある領域です。
AWSクイック・スタート・デプロイメントオプション
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 (JRE) (/usr/lib/jvm/jre/) ではなく、Confluence にバンドルされている JRE (/opt/atlassian/confluence/jre/) が使用されている点にご注意ください。
サーバー要件
Confluence と同じサーバーで他のアプリケーション (コア オペレーティング システム サービスを除く) を実行しないでください。アトラシアン ソフトウェアの専用サーバーでの Confluence、Jira、および Bamboo の実行は、小規模なインストールではうまく動作しますが、大規模に実行する場合はうまくいきません。
Confluence Data Center は仮想マシンで正常に実行できます。マルチキャストを使用する予定がある場合、Amazon Web Service （AWS）はマルチキャスト トラフィックをサポートしていないため、AWS で Confluence Data Center を実行することはできません。
クラスタノード
Data Center ライセンスでは、クラスタのノード数は制限されません。最大4ノードによるパフォーマンスと安定性をテストしています。
各ノードは完全に同一である必要はありませんが、一貫性のあるパフォーマンスのために、可能な限り近づけることをおすすめします。すべてのクラスタ ノードは以下を満たす必要があります。
- 同じデータ センターにある
- （Confluence ノードの場合）同じ Confluence バージョン、または（Synchrony ノードの場合）同じ Synchrony バージョンを実行する
- 同じ OS、Java、およびアプリケーション サーバー バージョン
- 同じメモリ設定（JVM と物理メモリの両方）（推奨）
- 同じタイムゾーンで設定されている（および現在の同期された時間を維持する）。これを保証するには ntpd または同様なサービスを使用することをお勧めします。
クラスタでさまざまな問題が発生する可能性があるため、ノードのクロックが逸脱していないことを確認する必要があります。
メモリ要件
Confluence ノード
各 Confluence ノードの RAM は、最小 10 GB にすることをお勧めします。同時接続ユーザー数が増えると、大量の RAM が消費されます。
ここでは、メモリを異なるサイズのマシンに割り当てる方法の例をいくつか紹介します。
| RAM | 各 Confluence ノードの内訳 |
|---|---|
| 10 GB |
|
| 16 GB |
|
Confluence アプリケーションの最大ヒープ (-Xmx) は、setenv.sh または setenv.bat ファイルで設定されます。Data Center の場合、既定値を増やす必要があります。最小ヒープ (Xms) と最大 (Xmx) ヒープを同じ値にすることをお勧めします。
外部プロセス プールは、個々の Confluence ノードの影響を最小化するためにメモリ集約タスクを外部化するのに使用されます。プロセスは Confluence で管理されます。各プロセス (サンドボックス) の最大ヒープ (-Xmx) とサンドボックスの数はシステム プロパティを使用して設定されます。多くの場合、既定の設定が適切であり、変更は不要です。
スタンドアロンの Synchrony クラスタ ノード
Synchrony は共同編集に必要です。Synchrony は既定では Confluence によって管理されていますが、独自のクラスタで Synchrony を実行するようにすることもできます。利用可能な選択肢の詳細については、「Confluence および Synchrony で利用可能な設定」を参照してください。
独自の Synchrony クラスタを実行する場合、スタンドアロン Synchrony に対して 2 GB のメモリを割り当てることをお勧めします。ここでは、専用の Synchrony ノードへのメモリ割り当ての例を示します。
| 物理 RAM | 各 Synchrony ノードの内訳 |
|---|---|
4 GB |
|
データベース
クラスタ データベースについてもっとも重要な要件は、そのノード数をサポートするのに十分なコネクションが利用可能であることです。
例:
- 各 Confluence ノードの最大プールサイズは20コネクションです。
- 各 Synchrony ノードの最大プール サイズは15コネクションです（デフォルト）。
- 3 Confluence ノードおよび 3 Synchrony ノードの実行を計画しています。
データベース サーバーは Confluence データベースに対して最低105コネクションを許可する必要があります。実際には、デバックや管理目的で最大以上のコネクションが必要な場合があります。
目的のデータベースが現在「サポートされているプラットフォーム」に記載されていることも確認する必要があります。平均的なクラスタ ソリューションの負荷はスタンドアロン インストールよりも高くなるため、サポートされているデータベースを使用することが重要です。
また、サポートされているデータベース ドライバを使用する必要があります。サポートされていないドライバやカスタム JDBC ドライバ (または JNDI データソース コネクションで driverClassName を使用している場合)、共同編集でエラーが発生し、失敗します。サポートされているドライバの一覧については、「データベース JDBC ドライバ」を参照してください。
共有ホーム ディレクトリおよびストレージ要件
すべての Confluence クラスタは同じパスの共有ディレクトリへのアクセス権限を持っている必要があります。NFS および SMB/CIFS 共有が共有ディレクトリの場所としてサポートされています。このディレクトリには大量のデータ（添付ファイルやバックアップを含む）が格納されるため、十分なサイズにし、必要に応じて利用可能なディスク領域を増やす方法を計画する必要があります。
ロード バランサ
最も慣れ親しんだロード バランサを使用することをお勧めします。ロード バランサは「セッション アフィニティ」と WebSockets をサポートしている必要があります。これは Confluence と Synchrony の両方で必要です。AWS上で展開している場合は、アプリケーションのロードバランサ（ALB）を使用する必要があります。
ロードバランサを設定するときの推奨事項は、次のとおりです。
- キューは、ロード バランサでリクエストします。ノードへの要求の最大数が Tomcat で受け入れ可能な HTTP スレッドの合計数を超えていないことを確認することで、処理可能な数を超える要求がノードに送信されるのを避けることができます。
<install-directory>/conf/server.xmlで maxThreads を確認することができます。 - 非常に迅速に、すべてのノード間での問題を伝播できるため、他のノードに失敗した、べき等の要求を再生しないでください。
- 最小接続 の使用で、ラウンドロビンとしてではなく、 負荷バランスを行う方法はノードがクラスタに参加または削除された後に再結合する際に、よりよい負荷のバランスをとることができます。
多くのロード バランサでは、自動的にプールからバックエンドを削除するため、バックエンドの正常性を常に確認するための URL が必要です。これには安定しており高速であるが不要なリソースを消費しない程度に十分軽量な URL を使用することが重要です。以下の URL は Confluence のステータスを返し、この目的に使用することができます。
URL | 期待される内容 | 予想 HTTP ステータス |
|---|---|---|
| http://<confluenceurl>/status | {"state":"RUNNING"} | 200 OK |
ノードが長いGCの一時停止などの小さな問題を、生き残ることができるよう監視を設定するときは、いくつかの推奨事項は、以下のとおりです。
- ノードを削除する前に2回連続して失敗を待ちます。
- ノードがプールから削除される前に30秒と言うならば、ノードへの既存の接続が終了するのを許可します。
ネットワークアダプタ
サーバー間の通信に個別のネットワーク アダプタを使用します。クラスタ ノードはサーバー間通信用の個別の物理ネットワーク（個別の NIC など）を持っている必要があります。これはクラスタの実行を高速および信頼性を高くするのに最適な方法です。その他のデータ ストリーミングを多数持つネットワークを介してクラスタ ノードに接続する場合、パフォーマンスの問題が発生する可能性があります。
共同編集の追加要件
Confluence 6.0 以降の共同編集は、別のプロセスとして実行される Synchrony で実行されています。
Confluence Data Center ライセンスをお持ちの場合、Synchrony を実行するには 2 つのメソッドを使用できます。
- Confluence で管理 (推奨)
Confluence は同じノードで自動的に Synchrony プロセスを起動して管理します。手動による操作は不要です。 - スタンドアロンの Synchrony クラスタ (ユーザーによる管理)
ユーザーはスタンドアロンな Synchrony を必要なノード数で、独自のクラスタでデプロイおよび管理します。大規模なセットアップが必要です。
シンプルなセットアップを実現してメンテナンスの労力を極力減らしたい場合、Synchrony を Confluence で管理することをおすすめします。完全な制御を実現したい場合や、エディタの高い可用性の確保が必須である場合、独自のクラスタで Synchrony を管理することが、組織に最適なソリューションである可能性があります。
高可用性の追加要件
Confluence Data Center では、アプリケーション サーバーは単一障害点となりません。ロード バランサ、データベース、および共有ファイルの可用性も高くすることで、さらに単一障害点を最小化することができます。
ユーザー管理
You can manage users in Confluence's internal directory, in an external LDAP directory, or in Atlassian Crowd or JIRA.
またConfluence Data Center は、認証とシングルサインオン（Confluence Data Center にのみ利用可能）のために SAML 2.0 IDプロバイダに接続することができます。
Marketplace アプリ
Confluence Data Center への Marketplace アプリのインストールのプロセスは、Confluence のスタンドアロン インスタンスと同じです。アプリのインストールまたは更新の際に、クラスタを停止したり、ノードをダウンさせたりする必要はありません。
Atlassian Marketplace では、各アプリの Confluence Data Center との互換性が表示されます。
独自の Confluence プラグイン (アプリ) を開発している場合、アプリがクラスタ互換であるかどうかを確認する方法について、「アプリがクラスタで適切に動作するかを確認するにはどうしたらよいですか?」の開発者ドキュメントをご参照ください。
準備はよろしいですか?
Confluence Data Center の詳細を確認し、今すぐ始めましょう。
インストールのヘルプについては、 Confluence Data Centerのインストール を参照してください。