Confluence Data Center を AWS で実行する

Confluence Data Center は AWS (Amazon Web Services) 環境でも最適に利用できます。AWS では、追加のノードのリサイズおよび素早い起動によってデプロイメントを柔軟にスケーリングできるだけでなく、Confluence Data Center ですぐに使用できる多数の管理されたサービスを利用し、それらすべての設定とメンテナンスを自動的に処理できます。

Data Center のメリットの詳細について興味をお持ちの方は、Confluence Data Center の概要をご確認ください。

このページの内容:


AWS Quick Start を使用した Confluence Data Center のデプロイ

AWS に Data Center クラスタ全体をデプロイする最も単純な方法は、Quick Start を使用することです。Quick Start は、AWS のセキュリティと可用性のためのベスト プラクティスを使用して、AWS 上に特定のワークロードをデプロイするのに必要な AWS コンピュータ、ネットワーク、ストレージ、およびその他のサービスを、起動、設定、および実行します。

Quickstart では 2 つのデプロイメント オプションが提供され、それぞれが独自のテンプレートを持ちます。1 つめのオプションは、Atlassian Standard Infrastructure (ASI) をデプロイし、この ASI に Confluence Data Center をプロビジョニングします。2 つめのオプションは、既存の ASI への Confluence Data Center のデプロイのみを行います。

Atlassian Standard Infrastructure (ASI)

ASI は、アトラシアンのすべての Data Center 製品で必要なコンポーネントを含む仮想プライベート クラウド (VPC) です。詳細については、「AWS の Atlassian Standard Infrastructure (ASI)」をご参照ください。


以下は、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 (/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 ドキュメントのリージョンごとの製品サービス テーブルを確認して、希望するリージョンがサポートされているかどうかを確認することをおすすめします。 


Confluence 6.3.1 以前をデプロイする場合....

6.3.2 より前の Confluence バージョンには、追加の依存関係があります。Synchrony (共同編集に必須) は、Amazon API の操作にサードパーティ ライブラリを使用しますが、リージョンによっては適切なエンドポイントを使用できない場合があります。これにより、次のリージョンで Synchrony を実行することができません。

  • 米国東部 (オハイオ)
  • EU (ロンドン)1
  • アジア パシフィック (ムンバイ)1
  • アジア パシフィック (ソウル)1
  • カナダ (中部)1

1 本記事の作成時点で、これらのリージョンは EFS に未対応です。このため、これらのリージョンを Confluence の実行に使用することはできません。


自身の DNS サーバーで内部向けサイトをセットアップする

自身の DNS サーバーを使用して内部向けの Confluence サイトをデプロイする場合、Amazon Route 53 を使用してパブリック DNS と内部 DNS 間のリンクを作成することができます。 

  1. Route 53 で、プライベート ホステッド ゾーンを作成します。VPC については、既存の Atlassian Services VPC を使用できます。ドメイン名はお好みのドメインに設定します。
  2. すでに Confluence をセットアップしている場合、AWS コンソールで [サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします (Confluence を初めてセットアップする場合、以降の Quick Start テンプレートに従います)。 
  3. [その他のパラメータ] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。 
  4. 任意のサブドメインを入力します。または [ホステッド ゾーンのサブドメイン] フィールドを空のままにしておくと、スタック名がサブドメインとして使用されます。 
  5. プロンプトに従ってスタックを更新します。ロード バランサおよび EFS URL が生成され、Route 53 にそれぞれのレコードが作成されます。 
  6. Confluence で、 > [一般設定] に移動し、Confluence のベース URL を Route 53 のドメインに更新します。 
  7. ご利用のオンプレミス ネットワークとプライベート ホステッド ゾーンに紐付いた VPC との間に DNS 解決をセットアップします。これを行うには、次の製品を使用します。
    1. Active Directory (Amazon Directory Service または Microsoft Active Directory)
    2. bind9 または Unbound を使用する、EC2 の DNS フォワーダ
  8. 最後に、Confluence と Synchrony の各ノードを終了して再度プロビジョニングし、変更を有効にします。

スケーリング (拡張および縮小)

Confluence または Synchrony クラスタ ノードの数を増減させるには、次の手順を実行します。

  1. AWS コンソールで [サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします。
  2. クラスター ノードの最小数クラスター ノードの最大数パラメーターを、希望に応じて変更します。

オート スケーリング グループでこれを検出してパラメーターに変更を適用するには、数分かかる場合があります。

クラスタ ノードの最小最大に同じ数を指定した場合を除き、オート スケーリング グループは、これら 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 インスタンスをアップグレードするには、次の手順を実行します。

  1. AWS コンソールで、スタックを更新します。
  2. Confluence および Synchrony のオート スケーリング グループのサイズ (最大と最小) を 0 に変更します。これによって、実行中のすべてのノードが終了されます。 
  3. 更新が完了したら、すべての EC2 ノードが終了していることを確認します。 
  4. AWS コンソールでスタックを更新します。
  5. Confluence バージョンをアップグレード先のバージョンに変更します。
  6. Confluence および Synchrony のオート スケーリング グループのサイズ (最大と最小) を 1 に変更します。アップグレードが完了するまでは 2 つ以上のノードを追加しないでください。
  7. ブラウザで Confluence にアクセスします。この時点ですべてのアップグレード タスクが実行されます。 
  8. Confluence と Synchrony の両方が正常に実行されていることと、新しいバージョンが実行されていること (フッターをご確認ください) を確認します。 
  9. AWS コンソールでスタックを更新します。
  10. 最大 Confluence ノードおよび最大 Synchrony ノードをオート スケーリング グループの通常のサイズに変更します。 
  11. 新しいノードがクラスタにジョインしていることを確認します。 

AWS の Confluence Data Center では現在、古いバージョンの最後のクラスタ ノードのシャットダウンと新しいバージョンの最初のクラスタ ノードの起動の間のダウンタイムが必須であり、インスタンスをダウンタイムなしでアップグレードすることはできません。  

新しいノードが新しいバージョンで起動する前に、既存のすべてのノードが終了していることを確認する必要があります。 

バックアップ

AWS のネイティブ バックアップ機能を使用することをおすすめします。これは Confluence Data Center のバックアップにスナップショットを使用します。

AWS への既存の Confluence サイトの移行

既存の Confluence インスタンスを AWS に移行するには、次の手順を実行します。

  1. 既存のサイトを、AWS にデプロイしたバージョン (Confluence 6.1 以降) にアップグレードします。
  2. (PostgreSQL を使用していない場合) データベースを PostgreSQL に移行します。「別のデータベースへの移行」を参照してください。 
  3. PostgreSQL データベースと既存の <shared-home>/attachments ディレクトリをバックアップします。
  4. バックアップ ファイルを EC2 インスタンスの /media/atl/confluence/shared-home にコピーします。  
  5. 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 の移行には推奨されません。
最終更新日 2019 年 5 月 31 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.