Confluence Data Center を AWS で実行する
Confluence Data Center は AWS (Amazon Web Services) 環境でも最適に利用できます。AWS では、追加のノードのリサイズおよび素早い起動によってデプロイメントを柔軟にスケーリングできるだけでなく、Confluence Data Center ですぐに使用できる多数の管理されたサービスを利用し、それらすべての設定とメンテナンスを自動的に処理できます。
Data Center のメリットの詳細について興味をお持ちの方は、Confluence Data Center の概要をご確認ください。
On this page:
AWS Quick Start を使用した Confluence Data Center のデプロイ
AWS に Data Center クラスタ全体をデプロイする最も単純な方法は、Quick Start を使用することです。Quick Start は、AWS のセキュリティと可用性のためのベスト プラクティスを使用して、AWS 上に特定のワークロードをデプロイするのに必要な AWS コンピュータ、ネットワーク、ストレージ、およびその他のサービスを、起動、設定、および実行します。
The Quick Start provides two deployment options, each with its own template. The first option deploys the Atlassian Standard Infrastructure (ASI) and then provisions Confluence Data Center into this ASI. The second option only provisions Confluence Data Center on an existing ASI.
Atlassian Standard Infrastructure (ASI)
The ASI is a virtual private cloud (VPC) that contains the components required by all Atlassian Data Center applications. For more information, see Atlassian Standard Infrastructure (ASI) on AWS.
以下は、Confluence Data Center の Quick Start のアーキテクチャの概要です。
デプロイメントは、以下のコンポーネントで構成されています。
- 1 つ以上の Amazon Elastic Compute Cloud (EC2) インスタンス: 1 つのオート スケーリング グループに含まれ、Confluence を実行するクラスタ ノード
- 1 つ以上の Amazon Elastic Compute Cloud (EC2) インスタンス: 1 つのオート スケーリング グループに含まれ、共同編集に必要な Synchrony を実行するクラスタ ノード
- Amazon Application Load Balancer (ALB): ロード バランサおよび SSL ターミネートを行うリバース プロキシ
- Amazon Elastic File System (EFS): すべての Confluence ノードからアクセス可能な添付ファイルとその他のファイルを含む共有ホーム ディレクトリ
- Amazon Relational Database (RDS) の PostgreSQL インスタンス: 共有データベース
アーキテクチャ、コンポーネント、およびデプロイメント プロセスの詳細については、「Quick Start ガイド」を参照してください。
Confluence では、EC2 インスタンスにインストールされている Java Runtime Engine (JRE) (/usr/lib/jvm/jre/) ではなく、Confluence にバンドルされている JRE (/opt/atlassian/confluence/jre/) が使用されます。
Quick Start をそのまま使用する、または要件に合わせて変更する
迅速な実装のため、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 ドキュメントのリージョンごとの製品サービス テーブルを確認して、希望するリージョンがサポートされているかどうかを確認することをおすすめします。
自身の DNS サーバーで内部向けサイトをセットアップする
自身の DNS サーバーを使用して内部向けの Confluence サイトをデプロイする場合、Amazon Route 53 を使用してパブリック DNS と内部 DNS 間のリンクを作成することができます。
- Route 53 で、プライベート ホステッド ゾーンを作成します。VPC については、既存の Atlassian Services VPC を使用できます。ドメイン名はお好みのドメインに設定します。
- すでに Confluence をセットアップしている場合、AWS コンソールで [サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします (Confluence を初めてセットアップする場合、以降の Quick Start テンプレートに従います)。
- [その他のパラメータ] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。
- 任意のサブドメインを入力します。または [ホステッド ゾーンのサブドメイン] フィールドを空のままにしておくと、スタック名がサブドメインとして使用されます。
- プロンプトに従ってスタックを更新します。ロード バランサおよび EFS URL が生成され、Route 53 にそれぞれのレコードが作成されます。
- Confluence で、
> [一般設定] に移動し、Confluence のベース URL を Route 53 のドメインに更新します。 - ご利用のオンプレミス ネットワークとプライベート ホステッド ゾーンに紐付いた VPC との間に DNS 解決をセットアップします。これを行うには、次の製品を使用します。
- Active Directory (Amazon Directory Service または Microsoft Active Directory)
- bind9 または Unbound を使用する、EC2 の DNS フォワーダ
- 最後に、Confluence と Synchrony の各ノードを終了して再度プロビジョニングし、変更を有効にします。
スケーリング (拡張および縮小)
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 の移行には推奨されません。