Confluence Data Center の技術的概要
このページでは、Confluence Data Center について説明します。Confluence Data Center は、クラスター化されたソリューションで、大規模環境で最適なパフォーマンスと高可用性を実現できます。ご使用の Confluence インスタンスがミッションクリティカルである場合や、非常に高い負荷を受ける場合には、これは不可欠です。
動作の仕組み
On this page
基本
Confluence Data Center では、以下の画像と同様なクラスタを構成することができます。
- 以下を格納する複数の Confluence 用サーバー ノード
- logs
- caches
- Lucene インデックス
- 設定ファイル
- plugins
- Synchrony を実行する複数のサーバー ノード（共同編集に必要です）
- 以下を格納する共有ファイル システム
- attachments
- アバター / プロフィール写真
- アイコン
- エクスポート ファイル
- インポート ファイル
- plugins
- すべてのノードが読み取るおよび書き込むデータベース
- リクエストを各ノードに均等に送るロード バランサ
すべての Confluence ノードがアクティブ状態にあり、リクエストを処理します。 ユーザーは、セッションのタイム アウト、ログアウト、またはクラスタからノードが削除されるまで、すべてのリクエストについて同じ Confluence ノードにアクセスします。
ライセンス
Data Center ライセンスは、ノードの数ではなく、クラスタのユーザー数に基づいています。ライセンス ページで利用可能なライセンス数を確認することができます。
このプロセスを自動化する（たとえば、割り当て限界に近づいた場合にアラートを送信する）場合は、REST API を使用することができます。
ホーム ディレクトリ
Confluence には、ローカル ホームと共有ホームという概念があります。各 Confluence ノードには、ログ、キャッシュ、Lucene インデックス、および設定ファイルを含むローカルホームがあります。他の全ては共有ホームに格納され、クラスタ内の各 Confluence ノードからアクセスすることができます。添付ファイル、アイコン、およびアバターはエクスポートおよびインポート ファイルとして共有ホームに格納されます。
アドオンはアドオンのニーズに応じて、データをローカル ホームに格納するか共有ホームに格納するかを選択することができます。
現在添付ファイルをデータベースに保存している場合、そのまま保存し続けることができますが、新しいインストールでは利用できません。
キャッシング
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 は、最小 6 GB にすることをお勧めします。同時接続ユーザー数が増えると、大量の RAM が消費されます。
ここでは、メモリを異なるサイズのマシンに割り当てる方法の例をいくつか紹介します。
| RAM | 各 Confluence ノードの内訳 |
|---|---|
| 8 GB |
|
| 16 GB |
|
Confluence アプリケーションの最大ヒープ (-Xmx) は、setenv.sh または setenv.bat ファイルで設定されます。Data Center の場合、既定値を増やす必要があります。最小ヒープ (Xms) と最大 (Xmx) ヒープを同じ値にすることをお勧めします。
サンドボックスは、個々の Confluence ノードの影響を最小化するためにメモリ集約タスクを外部化するのに使用されます。サンドボックスは Confluence で管理されます。各サンドボックスの最大ヒープ (-Xmx) とサンドボックスの数はシステム プロパティを使用して設定されます。多くの場合、既定の設定が適切であり、変更は不要です。
Synchrony
共同編集に必要となる Synchrony には、2 GB のメモリを割り当てることをお勧めします。ここでは、専用の Synchrony ノードへのメモリの割り当て方の例を示します。
| 物理 RAM | 各 Synchrony ノードの内訳 |
|---|---|
4 GB |
|
Confluence と同じノードで Synchrony を実行する場合、Confluence のメモリ要件に加えて、さらに 2 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 として Synchrony を配置したり、必要な数のノードと共に独自のクラスター内に配置することができます。
Confluence と同じノードで Synchrony を実行することを選択する場合、少なくとも2 GB の追加メモリが必要です（Synchrony のデフォルトの最大ヒープ サイズは1 GB です）。
ご利用のロード バランサ（およびその他のプロキシ）が WebSocket コネクションとセッション アフィニティをサポートしている必要があります。
高可用性の追加要件
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プロバイダに接続することができます。
プラグインとアドオン
Confluence Data Center へのアドオンのインストールのプロセスは、Confluence のスタンドアロン インスタンスと同じです。アドオンのインストールまたは更新の際に、クラスタを停止させたり、ノードをダウンさせたりする必要はありません。
The Atlassian Marketplace indicates add-ons that are compatible with Confluence Data Center.
Confluence の独自のプラグイン開発した場合、「アドオンがクラスタで正しく動作するかを確認するにはどうしたらよいですか？」の開発者ドキュメントを参照し、プラグインがクラスタ互換であることを確認する方法を確認する必要があります。
準備はよろしいですか?
Confluence Data Center の詳細を確認し、今すぐ始めましょう。
インストールのヘルプについては、「Confluence Data Centerのインストール」を参照してください。