Confluence Data Center を AWS で実行する
Confluence Data Center は AWS (Amazon Web Services) 環境でも最適に利用できます。AWS では、追加のノードのリサイズおよび素早い起動によってデプロイメントを柔軟にスケーリングできるだけでなく、Confluence Data Center ですぐに使用できる多数の管理されたサービスを利用し、それらすべての設定とメンテナンスを自動的に処理できます。
On this page:
AWS Quick Start を使用した Confluence Data Center のデプロイ
AWS に Data Center クラスタ全体をデプロイする最も単純な方法は、Quick Start を使用することです。Quick Start では、セキュリティと可用性のための AWS ベスト プラクティスを使用して、AWS 上に特定の作業負荷をデプロイするのに必要な AWS コンピュータ、ネットワーク、ストレージ、およびその他のサービスを起動、設定、および実行します。
以下は、Confluence Data Center の Quick Start のアーキテクチャの概要です。
デプロイメントは、以下のコンポーネントで構成されています。
- 1 つ以上の Amazon Elastic Compute Cloud (EC2) インスタンス: 1 つのオート スケーリング グループに含まれ、Confluence を実行するクラスタ ノード
- 自動スケーリング グループ内の、（共同編集に必要な） Synchrony を実行する、クラスタ ノードとしての 1つ以上の Amazon Elastic Compute Cloud （EC2）インスタンス
- Amazon Application Load Balancer (ALB): ロード バランサおよび SSL ターミネートを行うリバース プロキシ
- Amazon Elastic File System (EFS): すべての Confluence ノードからアクセス可能な添付ファイルとその他のファイルを含む共有ホーム ディレクトリ
- Amazon Relational Database (RDS) の PostgreSQL インスタンス: 共有データベース
アーキテクチャ、コンポーネント、およびデプロイメント プロセスの詳細については、「Quick Start ガイド」を参照してください。
EC2 のサイジングに関する推奨事項
Quick Start は Confluence および Synchrony ノードにデフォルトで c33.xlarge インスタンスを使用します。インスタンス タイプはユーザーの要件に合わせて設定しますが、Confluence のシステム要件を満たしている必要があります。小さなインスタンス タイプ (micro、small、medium) は一般に、Confluence の実行には不十分です。
サポート対象の AWS リージョン
Confluence の実行に必要なサービスが提供されていない地域もあります。Amazon Elastic File System (EFS) をサポートするリージョンを選択する必要があります。現在、次のリージョンで Quick Start を使用して Confluence をデプロイできます。
- アジア パシフィック (シドニー)
- EU (フランクフルト)
- EU (アイルランド)
- 米国東部 (バージニア北部)
- 米国西部 (オレゴン)
各リージョンで提供されるサービスは常に変更される可能性があります。そのため、AWS ドキュメントのリージョンごとの製品サービス テーブルを確認して、希望するリージョンがサポートされているかどうかを確認することをおすすめします。
スケーリング (拡張および縮小)
Confluence または Synchrony クラスタ ノードの数を増減させるには、次の手順を実行します。
- AWS コンソールで [サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします。
- クラスター ノードの最小数とクラスター ノードの最大数パラメーターを、希望に応じて変更します。
オート スケーリング グループでこれを検出してパラメーターに変更を適用するには、数分かかる場合があります。
クラスタ ノードの最小と最大に同じ数を指定した場合を除き、オート スケーリング グループは、これら 2 つの制限間で必要なノード数を最適な形で実現するため、新しいクラスタ ノードを起動し、既存のものを自動的に終了させます。デフォルトでは、このターゲット数は以下の CloudWatch メトリックによって決定されます。
- オート スケーリング グループで 5 分間の平均 CPU 使用率が 60 % を上回った場合、ノードのターゲット数を 1 増やします (最大値まで)。
- オート スケーリング グループで 30 分間の平均 CPU 使用率が 40 % を下回った場合、ノードのターゲット数を 1 減らします (最小値まで)。
スケーリング イベント間では、既定で 10 分間の "クールダウン" 期間も適用されます。詳細については、「メトリックに基づいたスケーリング」を参照してください。
注: 特に負荷スパイクに対応する場合、新しいクラスタ ノードを追加することで、クラスタのキャパシティを一時的に増加させることができます。特定のしきい値を超えると、大量のクラスタ ノードの追加による効果は減少します。一般に、特にノード自体が小さい場合、各ノードのサイズを増加させる ("垂直" スケーリング) と、ノード数を増やす("水平" スケーリング) 場合よりも大きな持続的キャパシティを扱うことができます。
オートスケーリング グループの詳細については、AWS のドキュメントを参照してください。
SSH 経由でノードに接続する
クラスタ ノードとファイル サーバーに SSH でアクセスして、設定やメンテナンス タスクを実行できます。SSH の秘密鍵ファイル (Amazon からダウンロードし、Key Name パラメータとして指定した PEM ファイル) を安全な場所に保持しておく必要があります。これはインスタンス内のすべてのノードに対する鍵であり、これをなくした場合はロックアウトされる可能性があります。
注: ConfluenceDataCenter.template は、Internal subnets パラメータで指定したサブネットにすべての EC 2 インスタンスをデプロイします。外部から完全に到達できない内部サブネットを指定した場合、外部サブネットのいずれかからアクセス可能で SSH を実行している EC2 インスタンスを起動し、これを "ジャンプ ボックス" として使用して、内部サブネット内の任意のインスタンスに SSH を実行します。つまり、"ジャンプ ボックス" に SSH を実行し、そこから内部サブネットにデプロイされている任意のインスタンスに SSH を実行します。
SSH 経由でインスタンスに接続する場合、ユーザー名として ec2-user を使用します。例:
ssh -i keyfile.pemec2-user@ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com
ec2-user は、 sudo アクセスを持ちます。root による SSH アクセスは許可されません。
アップグレード
ConfluenceDataCenter.template から起動された Confluence Data Center インスタンスをアップグレードするには、次の手順を実行します。
- AWS コンソールで、スタックを更新します。
- Confluence および Synchrony の自動スケーリング グループのサイズ（最大と最小）を 0 に変更します。これによって、実行中のすべてのノードを終了します。
- 更新が完了したら、すべての EC2 ノードが終了していることを確認します。
- AWS コンソールでスタックを更新します。
- Confluence バージョンをアップグレード先のバージョンに変更します。
- Confluence および Synchrony のオート スケーリング グループのサイズ (最大と最小) を 1 に変更します。アップグレードが完了するまでは 2 つ以上のノードを追加しないでください。
- ブラウザで Confluence にアクセスします。この時点ですべてのアップグレード タスクが実行されます。
- Confluence と Synchrony の両方が正常に実行されていることと、新しいバージョンが実行されていること (フッターをご確認ください) を確認します。
- AWS コンソールでスタックを更新します。
- 最大 Confluence ノードおよび最大 Synchrony ノードをオート スケーリング グループの通常のサイズに変更します。
- 新しいノードがクラスタにジョインしていることを確認します。
AWS の Confluence Data Center では現在、古いバージョンの最後のクラスタ ノードのシャットダウンと新しいバージョンの最初のクラスタ ノードの起動の間のダウンタイムが必須であり、インスタンスをダウンタイムなしでアップグレードすることはできません。
新しいノードが新しいバージョンで起動する前に、既存のすべてのノードが終了していることを確認する必要があります。
バックアップ
AWS のネイティブ バックアップ機能を使用することをおすすめします。これは Confluence Data Center のバックアップにスナップショットを使用します。
AWS への既存の Confluence サイトの移行
既存の Confluence インスタンスを AWS に移行するには、次の手順を実行します。
- 既存のサイトを、AWS にデプロイしたバージョン (Confluence 6.1 以降) にアップグレードします。
- (PostgreSQL を使用していない場合) データベースを PostgreSQL に移行します。「別のデータベースへの移行」を参照してください。
- PostgreSQL データベースと既存の
<shared-home>/attachmentsディレクトリをバックアップします。 - バックアップ ファイルを EC2 インスタンスの
/media/atl/confluence/shared-homeにコピーします。 pg_restoreを使用して PostgreSQL のデータベース ダンプを RDS インスタンスにリストアします。
この方法の詳細については、Amazon のドキュメントの「Importing Data into PostgreSQL on Amazon RDS」を参照してください。
メモ:
- CloudFormation テンプレートを使用してクラスタを作成すると、データベース名は
confluenceになります。リストアする場合はこのデータベース名を保持する必要があります。データベース名が保持されない場合、新しいノードのプロビジョニング時に問題が発生する可能性があります。この場合、新しいデータベースをドロップしてバックアップで置き換える必要があります。 - 既存のローカル ホームまたはインストール ディレクトリからインデックスなどをコピーする必要はありません。既存の共有ホーム ディレクトリからは attachments だけをコピーします。
<shared-home>/config/cache-settings-overrides.propertiesファイルを変更した場合、新しい環境で変更を再適用することをおすすめします。- AWS ページ「Importing Data into PostgreSQL on Amazon RDS」に記載されている
_copyメソッドは、Confluence の移行には推奨されません。