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 では手動インストールと同じレベルのカスタマイズは提供していません。テンプレートを現状のまま使用するか、参照用に使用して独自のテンプレートを作成することができます。 

Amazon Aurora database for high availability

The Quick Start also allows you to deploy Confluence Data Center with an Amazon Aurora clustered database. This cluster will be PostgreSQL-compatible, featuring a primary database writer that replicates to two database readers in a different availability zone.


If the writer fails, Aurora automatically promotes one of the readers to take its place. For more information, see Amazon Aurora Features: PostgreSQL-Compatible Edition.

If you want to set up an existing Confluence Data Center instance with Amazon Aurora, you’ll need to perform some extra steps. See

Go to Configuring Confluence Data Center to work with Amazon Aurora for detailed instructions.

EC2 のサイジングに関する推奨事項

Quick Start は Confluence および Synchrony ノードにデフォルトで c33.xlarge インスタンスを使用します。インスタンス タイプはユーザーの要件に合わせて設定しますが、Confluence のシステム要件を満たしている必要があります。小さなインスタンス タイプ (micro、small、medium) は一般に、Confluence の実行には不十分です。

サポート対象の AWS リージョン

Confluence の実行に必要なサービスが提供されていない地域もあります。Amazon Elastic File System (EFS) をサポートするリージョンを選択する必要があります。現在、次のリージョンで Quick Start を使用して Confluence をデプロイできます。  

  • Americas
    • Northern Virginia
    • Ohio
    • Oregon
    • Northern California
    • Montreal
  • Europe/Middle East/Africa
    • Ireland
    • Frankfurt
    • London
    • Paris
  • Asia Pacific
    • Singapore
    • Tokyo
    • シドニー
    • Seoul
    • Mumbai

This list was last updated on .

The services offered in each region change from time to time. If your preferred region isn't on this list, check the Regional Product Services table in the AWS documentation to see if it already supports EFS. 

The Paris region in Europe/Middle East/Africa also supports EFS. However, our Quick Start uses the db.m4 instance class, which isn't available yet in this region. We will be updating our templates soon to support the db.m5 instance class, which will then allow you to use our Quick Start in the Paris region.

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

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

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

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


Route53 プライベート ホステッド ゾーンを使用した内部ドメイン名ルーティング

Confluence サイトが AWS でホストされている場合も、内部のオンプレミス DNS サーバーがある場合はそこに Confluence サイトの DNS をリンクすることができます。これを行うには、Amazon Route53 を通じて、パブリック DNS と内部 DNS の間にリンクを作成します。これにより、わかりやすいドメイン名を使用してインフラストラクチャ リソース (データベース、共有ホームなど) に簡単にアクセスできるようになります。DNS 設定に応じて、これらのドメイン名を外部または内部からアクセスできるようにすることができます。

ステップ 1. 新しいホステッド ゾーンを作成する

[サービス] > [Route 53]プライベート ホステッド ゾーンを作成します。ドメイン名は任意のドメインに設定します。VPC の場合、既存の Atlassian Standard Infrastructure を使用します。

ステップ 2. ホステッド ゾーンを使用するようスタックを設定する

ご利用のデプロイメントのクイック スタート テンプレートを使用して、スタックが手順 1 のホステッド ゾーンをポイントするようにします。Confluence を初めてセットアップする場合、次のようにクイック スタート テンプレートに従います。

  1. [DNS (オプション)] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。

  2. [ホステッド ゾーンのサブドメイン] フィールドに希望するドメインのサブドメインを入力します。空のままにしておくと、スタック名がサブドメインとして使用されます。

  3. プロンプトに従ってスタックをデプロイします。

既存の Confluence サイトが既にある場合は、クイック スタート テンプレートでスタックを構成することもできます。このテンプレートにアクセスするには、次の手順に従います。

  1. AWS コンソールで [サービス] > [CloudFormation] に移動します。

  2. スタックを選択し、[スタックの更新] をクリックします。

  3. [DNS (オプション)] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。

  4. [ホステッド ゾーンのサブドメイン] フィールドに希望するドメインのサブドメインを入力します。空のままにしておくと、スタック名がサブドメインとして使用されます。

  5. プロンプトに従ってスタックを更新します。

いずれの場合も、AWS はロード バランサー、EFS、およびデータベース用の URL と Route 53 レコードを生成します。たとえば、ホステッド ゾーンが my.hostedzone.com でスタックの名前が mystack の場合、URL mystack.db.my.hostedzone.com からデータベースにアクセスできます。

ステップ 3. DNS サーバーを Confluence サイトの VPC にリンクする

AWS 外部の DNS サーバーを使用する場合、それをデプロイメントの VPC (この場合は Atlassian Standard Infrastructure) にリンクする必要があります。つまり、DNS サーバーは Route53 を使用して、ホステッド ゾーンで指定したドメイン (手順 1) へのすべてのクエリを解決する必要があります。

これをセットアップする方法の手順については、「VPC とネットワークとの間の 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. In Confluence, go to  > General Configuration and update the Confluence base URL to your Route 53 domain. 
  7. ご利用のオンプレミス ネットワークとプライベート ホステッド ゾーンに紐付いた VPC との間に DNS 解決をセットアップします。これを行うには、次の製品を使用します。
    1. Active Directory (Amazon Directory Service または Microsoft Active Directory)
    2. bind9 または Unbound を使用する、EC2 の DNS フォワーダ
  8. 最後に、Confluence と Synchrony の各ノードを終了して再度プロビジョニングし、変更を有効にします。
tip/resting Created with Sketch.

Confluence のベース URL の構成に関連する情報については、「サーバー ベース URL の設定」を参照してください。


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

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 アクセスは許可されません。

アップグレード

Consider upgrading to an  Atlassian Enterprise release (if you're not on one already). Enterprise releases get fixes for critical bugs and security issues throughout its two-year support window. This gives you the option to keep a slower upgrade cadence without sacrificing security or stability. Enterprise releases are suitable for companies who can't keep up with the frequency at which we ship feature releases.

Here's some useful advice for upgrading your deployment:

  1. Before upgrading to a later version of Confluence Data Center, check if your apps are compatible with that version. Update your apps if needed. For more information about managing apps, see Using the Universal Plugin Manager.
  2. If you need to keep Confluence Data Center running during your upgrade, we recommend using read-only mode for site maintenance Your users will be able to view pages, but not create or change them. 
  3. We strongly recommend that you perform the upgrade first in a staging environment before upgrading your production instance. Create a staging environment for upgrading Confluence provides helpful tips on doing so.

Upgrading Confluence in AWS

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 バックアップ」を参照してください。 

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

AWS で Confluence をデプロイしたあとに、古いデプロイメントをそこに移行することもできます。この操作を行うには、次の手順を実行します。

  1. 既存のサイトを、AWS にデプロイしたバージョン (Confluence 6.1 以降) にアップグレードします。
  2. (オプション) 古いデータベースが 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 月 10 日

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

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