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)」をご参照ください。


Here's an overview of the Confluence Data Center Quick Start's architecture:

デプロイメントは、以下のコンポーネントで構成されています。

  • Instances/nodes: One or more Amazon Elastic Cloud (EC2) instances as cluster nodes, running Confluence.
  • Load balancer: An Application Load Balancer (ALB), which works both as load balancer and SSL-terminating reverse proxy.
  • Amazon EFS host: A shared file system for storing artifacts in a common location, accessible to multiple Confluence nodes. The Quick Start architecture implements the shared file system using the highly available Amazon Elastic File System (Amazon EFS) service.
  • Database: Your choice of shared database instance – Amazon RDS or Amazon Aurora.
  • Amazon CloudWatch: Basic monitoring and centralized logging through Amazon's native CloudWatch service.

アーキテクチャ、コンポーネント、およびデプロイメント プロセスの詳細については、「Quick Start ガイド」を参照してください。 

Confluence では、EC2 インスタンスにインストールされている Java Runtime Engine (/usr/lib/jvm/jre/) ではなく、Confluence にバンドルされている JRE (/opt/atlassian/confluence/jre/) が使用されます。 


高度なカスタマイズ

To get you up and running as quickly as possible, the Quick Start doesn't allow the same level of customization as a manual installation. You can, however, further customize your deployment through the variables in the  Ansible playbooks we use.

All of our AWS Quick Starts use Ansible playbooks to configure specific components of your deployment. These playbooks are available publicly on this repository:

https://bitbucket.org/atlassian/dc-deployments-automation

You can override these configurations by using Ansible variables. Refer to the repository’s README file for more information.

Deploying the Quick Start from your own S3 bucket (recommended)

The fastest way to launch the Quick Start is directly from its AWS S3 bucket. However, when you do, any updates we make to the Quick Start templates will propagate directly to your deployment. These updates sometimes involve adding or removing parameters from the templates. This could introduce unexpected (and possibly breaking) changes to your deployment.

For production environments, we recommend that you copy the Quick Start templates into your own S3 bucket. Then, launch them directly from there. Doing this gives you control over when to propagate Quick Start updates to your deployment.

  1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

    git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-confluence.git

  2. (Optional) The Quick Start templates repository uses the directory structure required by the Quick Start interface. If needed (for example, to minimize storage costs), you can remove all other files except the following:


    quickstart-atlassian-confluence 
    ├─ submodules 
    │ └─ quickstart-atlassian-services 
    │ └─ templates 
    │ └── quickstart-vpc-for-atlassian-services.yaml 
    └─ templates 
    ├── quickstart-confluence-master-with-vpc.template.yaml 
    └── quickstart-confluence-master.template.yaml
  3. Install and set up the AWS Command Line Interface. This tool will allow you to create an S3 bucket and upload content to it.

  4. Create an S3 bucket in your region:

    aws s3 mb s3://<bucket-name> --region <AWS_REGION>

At this point, you can now upload the Quick Start templates to your own S3 bucket. Before you do, you'll have to choose which Quick Start template you’ll be using:

    • quickstart-confluence-master-with-vpc.template.yaml: use this for deploying into a new ASI (end-to-end deployment).

    • quickstart-confluence-master.template.yaml: use this for deploying into an existing ASI.


  1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of the bucket you created earlier.
  2. Go into the parent directory of your local clone of the Quick Start templates. From there, upload all the files in local clone to your S3 bucket:

    aws s3 cp quickstart-atlassian-jira s3://<bucket-name> --recursive --acl public-read
  3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation → Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

高可用性のための Amazon Aurora データベース

The Quick Start also allows you to deploy Confluence Data Center with an Amazon Aurora clustered database (instead of RDS). 

This cluster will be PostgreSQL-compatible, featuring a primary database writer that replicates to two database readers. You can also set up the writers and readers in separate availability zones for better resiliency.

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 Configuring Confluence Data Center to work with Amazon Aurora for detailed instructions.

Synchrony setup

Confluence Data Center ライセンスをお持ちの場合、Synchrony を実行するには 2 つのメソッドを使用できます。

  • Confluence で管理 (推奨)
    Confluence は同じノードで自動的に Synchrony プロセスを起動して管理します。手動による操作は不要です。 
  • スタンドアロンの Synchrony クラスタ (ユーザーによる管理)
    ユーザーはスタンドアロンな Synchrony を必要なノード数で、独自のクラスタでデプロイおよび管理します。大規模なセットアップが必要です。 

シンプルなセットアップを実現してメンテナンスの労力を極力減らしたい場合、Synchrony を Confluence で管理することをおすすめします。完全な制御を実現したい場合や、エディタの高い可用性の確保が必須である場合、独自のクラスタで Synchrony を管理することが、組織に最適なソリューションである可能性があります。 

By default, the Quick Start will configure Synchrony to be managed by Confluence. However, you can use the Quick Start to configure standalone Synchrony. When you do, the Quick Start creates an Auto Scaling group containing one or more Amazon EC2 instances as cluster nodes, running Synchrony. 

For more information about Synchrony configuration, see Possible Confluence and Synchrony Configurations.

Managed mode is only available in 6.12 and later

If you plan to deploy a Confluence Data Center version earlier than 6.12, you can only use Standalone mode. In the Quick Start, this means you should set your Collaborative editing mode to synchrony-separate-nodes.

Amazon CloudWatch for basic monitoring and centralized logging

The Quick Start also installs and configures Amazon CloudWatch to monitor each node in your deployment. This will allow you to monitor each node's CPU, disk, and network activity – all from a pre-configured CloudWatch dashboard. By default, Amazon CloudWatch will also collect and store logs from each node into a single, central source. This centralized logging allows you to search and analyze your deployment's log data more easily and effectively. See  Analyzing Log Data with CloudWatch Logs Insights for more details.

Amazon CloudWatch provides basic logging and monitoring, but also costs extra. To help reduce the cost of your deployment, you can disable logging or turn off Amazon CloudWatch altogether.

オート スケーリング グループ

この Quick Start は Auto Scaling グループを使用しますが、これはクラスタ ノード数の静的制御のみを目的としています。Auto Scaling を使用してクラスタのサイズを動的に拡張することは推奨されません。アプリケーション ノードのクラスタへの追加には通常 20 分以上かかりますが、この速度では突然の負荷のスパイクに対処できません。

高負荷および低負荷の期間を特定できる場合、それに応じてアプリケーション ノード クラスターのスケールをスケジュールできます。詳細については、「Amazon EC2 Auto Scalingのための拡張スケジュール」を参照してください。 

To study trends in your organization's load, you'll need to monitor the performance of your deployment. Refer to Confluence Data Center sample deployment and monitoring strategy for tips on how to do so. 

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

For Large or XLarge deployments, check out our AWS infrastructure recommendations for application, Synchrony, and database sizing advice. For smaller deployments, you can use instances that meet Confluence's system requirements.  Smaller instance types (micro, small, medium) are generally not adequate for running Confluence.

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

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

  • アメリカ
    • バージニア北部
    • オハイオ
    • オレゴン
    • 北カリフォルニア
    • モントリオール
  • ヨーロッパ / 中東 / アフリカ
    • アイルランド
    • フランクフルト
    • ロンドン
    • パリ
  • アジア太平洋
    • シンガポール
    • 東京
    • シドニー
    • ソウル
    • ムンバイ

この一覧は に更新されました。

各リージョンで提供されるサービスは随時変更される可能性があります。使用したいリージョンがこの一覧に含まれていない場合、そこが EFS をサポートしているかどうかを AWS ドキュメントの「リージョンごとの製品サービス」の表でご確認ください。 

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. 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 の各ノードを終了して再度プロビジョニングし、変更を有効にします。
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 秘密鍵ファイル (Key Name パラメータに指定した PME ファイル) が必要です。このキーはデプロイ内のすべてのノードにアクセスできるため、安全な場所に保管するようにします。

デプロイへのアクセスを制限するため、アトラシアンのクイック スタートでは Bastion ホストをデプロイしています。SSH を使用してデプロイに接続するには、まず Bastion ホストにアクセスする必要があります。このホストは、デプロイの内部サブネットの任意のインスタンスへの ”踏み台” として機能します。つまり、まず SSH で Bastion ホストに接続し、そこからデプロイ内の任意のインスタンスに接続します。 

Bastion ホストのパブリック IP は、BastionPubIp デプロイの ATL-BastionStack スタックの出力です。このスタックは、デプロイの Atlassian Standard Infrastructure (ASI) にネスト化されています。Bastion ホストにアクセスするには、以下の例のように、ユーザー名に ec2-user を使用します。

ssh -i keyfile.pem ec2-user@<BastionPubIp>

ec2-user は、 sudo アクセスを持ちます。root による SSH アクセスは許可されません。

tip/resting Created with Sketch.

AWS Systems Manager の Session Manager を使用してデプロイ内のインスタンスに直接アクセスすることもできます。この場合、Bastion ホストへの接続はまったく不要となります。

アップグレード

アトラシアンのエンタープライズ リリースをまだ使用していない場合、そちらへのアップグレードもご検討ください。エンタープライズ リリースでは 2 年間のサポート期間を通じて、重要なバグおよびセキュリティの課題に対する修正が適用されます。これにより、セキュリティや安定性を損ねることなく、アップグレードの頻度を減らすことができます。エンタープライズ リリースは、フィーチャー リリースのリリース頻度でのアップグレードが難しい企業に最適です。

デプロイメントのアップグレードについて、次の点をご確認ください。

  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.

AWS での Confluence のアップグレード

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. Reset the Confluence and Synchrony auto scaling groups (maximum and minimum) to their usual auto scaling group size. 
  11. 新しいノードがクラスタにジョインしていることを確認します。 

Confluence Data Center in AWS currently doesn't allow upgrading an instance without some downtime in between the last cluster node of the old version shutting down and the first cluster node on the new version starting up.  Make sure all existing nodes are terminated before launching new nodes on the new version. 

 

バックアップ

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 年 9 月 30 日

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

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