AWS でエンタープライズ規模の Confluence をデプロイする: ステップバイステップ ガイド
デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりました。テンプレートは今後も利用できますが、保守や更新は行われません。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。
AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。
Confluence Data Center はマルチノード クラスタリングをサポートし、高可用性と柔軟なスケーラビリティをもたらします。Confluence Data Center を適切なインフラストラクチャにデプロイすることで、これらの機能を活用できます。
Confluence Data Center には AWS クイック スタートが用意されています。このデプロイ方法は引き続き使用可能ですが、アトラシアンによるサポートと保守は終了しています。代わりに、より効率的で堅牢なセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることを強くお勧めします。
AWS クイック スタートでは、推奨される既定のプリセットでインフラストラクチャをデプロイするためのフレームワークが提供されていました。このフレームワークを使用すると、インフラストラクチャの各部分をゼロから構築する必要がなくなるため、デプロイを加速させることができました。クイック スタートで自身のインフラストラクチャを設計して、AWS ですばやくデプロイすることもできました。
このレガシー ドキュメントでは、デプロイを効率化するために必要なナレッジ リソースのほとんどを 1 か所で確認できます。ここでは、Confluence Data Center のエンドツーエンドのデプロイについて順を追って説明します。
非クラスタ インフラストラクチャとクラスタ インフラストラクチャ
1. 留意すべきこと
Confluence Data Center 用 AWS クイックスタートは必要なインフラストラクチャを適切に用意し、設定に必要なすべてのコンポーネントを準備します。このドキュメントで Confluence Data Center インスタンスをデプロイするために使用できるテンプレートを提供します。
1.1 このドキュメントはクイック スタートのデプロイメント ガイドとは異なりますか?
はい。このドキュメントでは、エンタープライズ規模の組織に適した、リファレンス デプロイメントを示します。その後、デプロイメント プロセス全体を順を追って説明します (これには、Confluence Data Center 用 AWS クイック スタートの使用を含みます)。また、大規模な Confluence Data Center を管理してきた当社の知識と経験に基づいた推奨事項を提供しています。
Confluence Data Center 用 AWS クイック スタートには独自のデプロイメント ガイドが付属しています。このガイドは、クイック スタートを使用して AWS で Confluence Data Center をデプロイする方法を示しています。ただし、ガイドはあらゆるサイズの組織向けに設計されており、特定のリファレンス デプロイメントの推奨設定は提供していません。
1.2 サードパーティのクラウド プラットフォームを使用する理由
Confluence Data Center をホストする際は、物理サーバーを使用するよりも、AWS などのサードパーティのクラウド プラットフォームを使用するほうが、多くのメリットが得られます。一例として、組織は物理ハードウェアのデプロイ、管理、拡張という負荷のかかる作業の大部分から解放されます。
アトラシアンでは AWS と協力してこのクイックスタートを開発し、ほとんどのタイプの組織で高度な構成を行えるようにしました。弊社では、Kubernetes に移行するまでの間、このクイックスタートを使用し、社内の異なるチーム向けに Confluence Data Center のデプロイおよび管理を行っていました。このクイックスタートを作成する際に使用された多数の設計原則は、社内の AWS デプロイから学んだ内容によるものです。
1.3 "エンタープライズ規模" の定義
本ドキュメントは、エンタープライズ規模の組織が Confluence Data Center をデプロイし、ニーズに合わせて調節するための方法に焦点を当てています。アトラシアンでは、Large または XLarge インスタンス (弊社の「Confluence Data Center の負荷プロファイル」に基づく) の組織をエンタープライズ規模の組織として定義しています。
1.4 これらの推奨設定が自社に適しているかどうかをどのように確認できますか?
本ドキュメントにおける推奨設定の大部分は、以下に基づいています。
- ベンチマーク: 「AWS でのエンタープライズ Confluence インスタンスの推奨インフラストラクチャ」で、エンタープライズ規模でアーキテクチャを設計する方法についてのガイダンスを確認できます。このガイダンスは広範なテストに基づいており、その方法についても記事内でご確認いただけます。このドキュメントでは複数の箇所で、同じ推奨設定を使用しています。
- エクスペリエンス: アトラシアンの本番環境で、最大規模の Confluence Data Center のデプロイメントをいくつか実行しています。これは、何千人ものアトラシアン社員にとって Confluence が不可欠なためです。またこれにより、エンタープライズ規模で Confluence Data Center を実行する方法を直接確認しています。弊社ではこのようなプロセスで実際の状況を多く確認しており、推奨設定の多くはこれに基づいています。
- 顧客調査: アトラシアンは多数のお客様やパートナーを支援しており、その過程で製品の使用方法についても学んでいます。これにより、インフラストラクチャのデプロイや保持についてお客様が直面している問題を確認しています。推奨設定は、このような問題の解決に役立つように設計されています。
これらの推奨設定は、大多数のエンタープライズ規模の組織に最適であると弊社で考え、推奨しているものであることにご注意ください。要件や発生する事象は組織ごとに異なり、それらに応じて別の戦略が必要になる可能性があります。これらの推奨設定は、要件をうまく解決するために調整するためのベースラインとして使用してください。
1.5 前提条件となるスキル
このドキュメントでは、AWS での Confluence Data Center のデプロイについて説明します。すでに Confluence に慣れている管理者を対象としています。
- Linux サーバーの管理方法
- AWS の UI を通じた AWS リソースのナビゲート方法
1.6 デプロイメントの内容
弊社でほとんどのエンタープライズ規模の組織の基盤として使用している、リファレンス アーキテクチャを提供します。このリファレンス アーキテクチャには各コンポーネントの短い説明が含まれているため、期待される内容を確認できます。
次に、組織のサイズ (または負荷プロファイル) を評価し、適切な構成を選択して、それを要件に合わせて調整する方法について説明します。そこから、アトラシアンの完全なサポート対象である AWS クイック スタートを使用して、これらの設定を AWS デプロイメントに適用する方法について説明します。クイック スタートではほかのパラメータもカスタマイズできますが、ここでは詳しく網羅しません。
2. リファレンス アーキテクチャ
以下の図は、クイック スタートを通じてデプロイできる基本アーキテクチャを示しています。
2.1 Bastion ホスト
このホストにより、Confluence Data Center をインターネットに公開することなく、そこに安全にアクセスできるようになります。詳しくは、「Bastion ホスト」を参照してください。
2.2 Amazon Application Load Balancer
AWS に Confluence をデプロイする際は、Application Load Balancer (ALB) を使用する必要があります。クイック スタートは ALB をロード バランサーおよび SSL ターミネート リバース プロキシとして構成します。
2.3 Atlassian Standard Infrastructure
Jira、Confluence、および Bitbucket 用の AWS クイック スタートはすべて、Atlassian Standard Infrastructure (ASI) を使用しています。ASI は、高可用性を実現するセキュアな仮想プライベート クラウド (VPC) で、AWS で Atlassian Data Center 製品をホストするためにカスタマイズされています。ASI には Confluence Data Center に必要な基本ネットワーク コンポーネントが含まれており、共有インフラストラクチャでの複数の Atlassian Data Center 製品の連携を簡単に行えるようにします。以下の図は、ASI によってセットアップされるさまざまなコンポーネントを示しています。
2.4 クラスタ化されたアプリケーション デプロイメント
Confluence Data Center インフラストラクチャの主要なコンポーネントの 1 つは、クラスタ化されたアプリケーション デプロイメントです。クラスタ化により、Confluence アプリケーションに優れたパフォーマンスや高可用性が提供されます。
「Confluence Data Center の技術的な概要」では、Confluence のクラスタリングのあらゆるメリットや要件について説明しています。Confluence Data Center 用の AWS クイック スタートではクラスタの構成を簡素化しています。これにより、管理者は使用するノードを選択するだけで、クイック スタートが残りを必要に応じてセットアップします。
2.5 高可用性を実現するデータベース
このクイック スタートでは、2 つのサポート対象データベース (Amazon RDS for PostgreSQL (既定) または Amazon Aurora の特徴: PostgreSQL 互換エディション) のいずれかを使用して Confluence Data Center をデプロイできます。いずれかを構成し、独自の組み込みのフェイルオーバー機能を使用して、高可用性を実現できます。
2.6 Amazon Elastic File System (EFS)
Confluence Data Center は共有ファイル システムを使用し、添付ファイル、アバター、アイコン、インポート / エクスポート ファイル、プラグインなどのアーティファクトを、すべての Confluence ノードでアクセス可能な共通の場所に保存します。クイック スタート アーキテクチャでは、高可用性構成の Amazon Elastic File System (Amazon EFS) サービスを使用して共有ファイル システムを実装します。
2.7 Amazon CloudWatch
既定では、Amazon CloudWatch は各ノードからログを収集し、単一の中央ソースに保存します。この中央ログにより、デプロイのログ データをより簡単かつ効果的に検索および分析できます。詳細については、「CloudWatch Logs Insights を使用したログ データの分析」および「フィルター パターンを使用したログ データ検索」を参照してください。
Amazon CloudWatch は基本的なロギングとモニタリングを提供しますが、コストもかかります。デプロイのコストを削減するために、デプロイ中にはログを無効にするか、Amazon CloudWatch 連携をオフにすることができます。
ログ データをダウンロードするには (AWS 以外の場所でアーカイブおよび分析する場合など)、データを最初に S3 にエクスポートする必要があります。そこからダウンロードできます。詳しくは、「Amazon S3 へのログ データのエクスポート」を参照してください。
2.8 Synchrony
既定では、クイック スタートは Synchrony を Confluence が管理するようにデプロイします。これにより、Synchrony をアプリケーション ノードにインストールし、自身に代わって Confluence に管理させることができます。詳細は、「Confluence および Synchrony で利用可能な設定」を参照してください。
3. デプロイに適した設定の選択
クイック スタートは、ほとんどのインフラストラクチャ コンポーネントに最適な構成を選択することにより、デプロイ プロセスを簡素化します。以降のサブセクションでは、組織の規模に合わせて調整できる設定の構成について説明します。この段階で使用する設定を判断することをおすすめします。これにより、デプロイ プロセスを効率化できます。
3.1 データベース エンジン
クイック スタートでは、次の 2 つのサポート対象データベースから選択できます。どちらのデータベースも高可用性を備えています。
- Amazon RDS for PostgreSQL (デフォルト): 別の AZ でホストされるスタンバイ インスタンスにレプリケートする、プライマリ データベース インスタンスとしてデプロイできます。プライマリ データベース インスタンスが失敗すると、Amazon RDS はレプリカへの自動フェイルオーバーを実行します。Amazon RDSを使用した高可用性の詳細については、「Multi-AZ デプロイメント」を参照してください。
- Amazon Aurora の特徴: PostgreSQL 互換エディション: Amazon RDS と同様に、別の AZ のスタンバイ ("リーダー" ノード) にレプリケートする、プライマリ データベース インスタンス ("ライター" ノード) があります。ただし、リーダー ノードの数を増やしてデータベースの信頼性を向上させることができます。
いずれのデータベースも、アトラシアンの完全なサポート対象の構成を用いてデプロイされます。高可用性を有効化するには、Multi-AZ デプロイメントを有効にする必要があります。
3.2 アプリケーション ノードとデータベース ノード
「AWS でのエンタープライズ Confluence インスタンスの推奨インフラストラクチャ」では、アプリケーションとデータベースで使用する、推奨されるノード構成 (インスタンスのタイプおよび数) について説明しています。これらの推奨設定は、異なる Confluence Data Center 負荷プロファイルで実行した堅牢なパフォーマンス テストに基づいています。
エンタープライズ規模の組織は一般に "Large" または "XLarge" になります。以下の表を使用し、自身の既存のインスタンスのサイズがどこに当てはまるかを、自身のメトリックを基に確認します。
メトリック | 大 | XLarge |
|---|---|---|
| コンテンツ (すべてのバージョン) | 250 万 ～ 1000 万 | 1000 万 ～ 2500 万 |
| 合計スペース数 | 2,500 ～ 5,000 | 5,000 ～ 50,000 |
| ローカル ユーザー | 10,000 ～ 100,000 | 100,000 ～ 250,000 |
| 1 時間あたりの HTTP コール数 | 350,000 ～ 700,000 | 700,000 ~ 1,000,000 |
既存のデプロイメントのメトリックの取得や、全体的なサイズの把握に支援が必要な場合、「Confluence Data Center の負荷プロファイル」をご参照ください。
Large と XLarge のどちらに該当するかを確認したら、インフラストラクチャに必要なノード構成のタイプを記録します。それぞれのノード構成には異なるメリットがあり、弊社の内部テストではすべてが Apdex 0.8 以上を示しています。これは、社内での Confluence デプロイメントのパフォーマンスを評価および管理する際に使用するターゲット Apdex と同じものです。
テストベースの推奨事項
ここで提供している推奨設定のいくつかはテスト結果に基づいたものであり、ご自身で必要なノード構成のベースラインに便利です。ご自身の環境でのパフォーマンスの結果は、サードパーティ製アプリ、データ、トラフィック、インスタンス タイプなどの多くの要因によって異なります。このため、弊社で使用しているターゲット Apdex をご利用の環境では再現できない可能性があります。これらの推奨設定の基本を理解するには、「テスト手法」をご確認ください。
3.2.1 Large
| ノード構成 | Application nodes | データベース ノード | |
|---|---|---|---|
| RDS | Aurora | ||
| パフォーマンス | c5.4xlarge x 2 | db.m5.2xlarge | db.r5.2xlarge |
| 安定性 | c5.2xlarge x 4 | db.m5.xlarge | db.r5.xlarge |
| 低コスト | c5.2xlarge x 3 | db.m5.xlarge | db.r5.xlarge |
パフォーマンス オプションは、テストしたすべての構成の中で最高の Apdex を実現しました。ベンチマークでは、1 つのノードが失われても Apdex 0.8 以上を維持できることを確認しています。
安定性オプションと低コスト オプションは、価格、フォールト トレランス、およびパフォーマンスのバランスが取れたオプションです。これらは両方とも同じ仮想マシン タイプを使用しています。安定性オプションの場合、追加アプリケーション ノードが 1 つだけあります。安定性オプションは多くのノードが失われるまで完全にオフラインにはなりませんが、低コスト オプションはコストを削減できます。これら 2 つのオプションでは、パフォーマンスの差はほとんどありません。
3.2.2 XLarge
| ノード構成 | Application nodes | データベース ノード | |
|---|---|---|---|
| RDS | Aurora | ||
| 安定性 | c5.4xlarge x 4 | db.m5.2xlarge | db.r5.2xlarge |
| 低コスト | c5.4xlarge x 3 | db.m5.2xlarge | db.r5.2xlarge |
アトラシアンのベンチマークでは、安定性構成の場合、1 つのアプリケーション ノードが失われても、許容可能なパフォーマンス (Apdex 0.8) を保持できることを確認しています。アプリケーション ノードが 4 つある場合、全体的なフォールト トレラントを低コスト構成よりも実現できます。
安定性構成と低コスト構成は、ノードの数以外は同じです。これらの Apdex スコアもほとんど変わりません。低コスト構成は、3 つのノードが失われるまでサービスがオフラインにならないため、非常にフォールト トレラントです。ただし、アトラシアンのテストでは、低コスト構成でノードが 1 つ失われると、Apdex が 0.8 を下回ることが確認されています。
3.3 HTTPS のセットアップ
セキュリティを強化するため、HTTPS を有効化することを強くおすすめします。「Confluence 用のプロキシと HTTPS のセットアップ」でこのための要件を示していますが、クイック スタートではこれを簡素化し、有効な証明書を求める手順のみを含めました。証明書の取得方法には 2 つのオプションがあります。
オプション 2: 信頼できる認証局が発行した有効な証明書を取得できます。証明書を入手したら、それを AWS Certificate Manager にインポートする必要があります。
3.4 アプリの互換性の確認
既定では、クイック スタートは Confluence Data Center 6.13 (最新の長期サポート リリース) をデプロイします。選択した Confluence バージョンに対して、インストールしたいアプリの互換性を確認する必要があります。
4. Confluence Data Center 用 AWS クイック スタートの使用
このセクションでは、エンドツーエンドのデプロイメントについて順を追って説明します。ここでは、新しい ASI をデプロイしてから、そこに Confluence Data Center をデプロイします。この ASI をその他すべてのアトラシアン Data Center 製品のデプロイ先として選択 (および Confluence と連携) して、基本的なネットワーク スタックとして機能させることができます。
クイック スタート ガイド
次の手順は、「AWS Cloud での Confluence Data Center のクイック スタートの参照デプロイメント」のものです。手順を効率化し、わかりやすくしました。
ステップ 1. リージョンを選択する
Amazon Elastic File System (EFS) をサポートするリージョンを選択する必要があります。対象となるリージョンは次のとおりです。
- アメリカ
- バージニア北部
- オハイオ
- オレゴン
- 北カリフォルニア
- モントリオール
- ヨーロッパ / 中東 / アフリカ
- アイルランド
- フランクフルト
- ロンドン
- パリ
- アジア太平洋
- シンガポール
- 東京
- シドニー
- ソウル
- ムンバイ
この一覧は に更新されました。
各リージョンで提供されるサービスは随時変更される可能性があります。使用したいリージョンがこの一覧に含まれていない場合、そこが EFS をサポートしているかどうかを AWS ドキュメントの「リージョンごとの製品サービス」の表でご確認ください。
Data Center 製品を AWS GovCloud にデプロイすることはできますが、AWS GovCloud 環境での AWS クイック スタートのテストや検証は実施しておらず、サポートも提供していません。
ステップ 2 AWS アカウントを準備する
デプロイメントの AWS リージョンを選択したら、それに従って AWS を準備する必要があります。
- AWS アカウントを持っていない場合、https://aws.amazon.com で画面の指示に従い、アカウントを作成します。
- ナビゲーション バーのリージョン セレクタで、デプロイしたい AWS リージョンを選択します。
- (オプション) Bastion ホストをプロビジョニングする予定がある場合は、対象のリージョンでキー ペアを作成します。
必要に応じ、EC2 t3.medium インスタンス タイプのサービス上限の追加をリクエストします。このインスタンス タイプを使用する既存のデプロイメントがすでにあり、このリファレンス デプロイメントで既定の上限を超える可能性がある場合、この作業が必要です。
ステップ 3: SSL 証明書をインポートする
信頼できる認証局が発行した有効な証明書を入手したら、AWS マネジメント コンソールを使用してそれをインポートする必要があります。
[AWS Certificate Manager (ACM)] を開きます。
[Import a certificate] を選択します。
次の操作を実行します。
[Certificate body] に、PEM エンコードされた証明書を貼り付けます。
[Certificate private key] に、証明書の公開鍵と一致する、PEM エンコードおよび複合化された秘密鍵を貼り付けます。
重要
現在、AWS Certificate Manager と連携されるサービスでは、
RSA_1024とRSA_2048アルゴリズムのみをサポートしています。(オプション) [Certificate chain] に、PEM エンコードされた証明書チェーンを貼り付けます。
[Review and import] を選択します。
証明書に関する情報を確認したら、[Import] を選択します。
AWS Certificate Manager では、証明書の Amazon Resource Name (ARN) を取得できます。これは、以降の「ステップ 5: デプロイメントをカスタマイズする」で使用します。
ステップ 4: クイック スタートを起動する
このクイック スタート リファレンス デプロイメントを実行する際に使用された AWS サービスのコストの責任は、操作の実行者に帰属します。詳細については、このクイック スタートで使用する各 AWS サービスの価格ページを参照してください。価格は変更される場合があります。
AWS アカウントにログインし、ここをクリックしてクイック スタートを起動します。エンドツーエンドのデプロイメント (新しい ASI でのデプロイ) には約 40 分かかります。
クイック スタートをもっとも素早く起動する方法は、AWS S3 バケットから直接起動することです。だだしこれを行った場合、アトラシアンでクイック スタート テンプレートに加えているすべての更新がデプロイメントに直接伝播されます。これらの更新には、テンプレートからのパラメーターの追加や削除が含まれる場合があります。これにより、デプロイメントに予期しない (および大幅な) 変更が発生する可能性があります。
本番環境の場合、クイック スタート テンプレートを自身の S3 バケットにコピーすることをおすすめします。次に、それらをそこから直接起動します。これにより、クイック スタートの更新をデプロイメントに伝播するタイミングを制御できるようになります。
- クイックスタート テンプレート (すべてのサブモジュールを含む) をローカル マシンにクローンします。コマンド ラインから、以下を実行します。
git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-confluence.git - (オプション) クイックスタート テンプレート リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。
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 AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。
自身のリージョンで S3 バケットを作成します。
aws s3 mb s3://<bucket-name> --region <AWS_REGION>
この時点で、クイック スタート テンプレートを自身の S3 バケットにアップロードできるようになりました。これを行う前に、使用するクイック スタート テンプレートを選択する必要があります。
quickstart-confluence-master-with-vpc.template.yaml: 新しい ASI へのデプロイ (エンドツーエンドのデプロイメント) に使用します。quickstart-confluence-master.template.yaml: 既存の ASI にデプロイする際に使用します。
- 選択したテンプレートで、
QSS3BucketNameの既定値はaws-quickstartに設定されています。この既定値を、S3 バケットの名前に置き換えます。 - クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。ここから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。
aws s3 cp quickstart-atlassian-confluence s3://<bucket-name> --recursive --acl public-read - すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。
ステップ 5: デプロイメントをカスタマイズする
[Specify Details] ページで、必要に応じてスタック名を変更します。テンプレートのパラメーターを確認し、デプロイメントをカスタマイズします。
設定する最初のパラメーターは、使用する製品バージョン (ConfluenceVersion) です。
ただし、既存のデプロイメントからデータを移行する予定がある場合、代わりにそのデプロイメントのバージョンを使用してください。これにより、不一致やデータ消失などにつながるリスクを回避することができます。移行プロセスを完了した後で、いつでもアップグレードすることができます。
次の表では、「デプロイメントに適した設定の選択」でこれまでにおこなった選択を実装できる、その他のオプションを説明しています。
| Cluster Nodes | ||
|---|---|---|
| パラメーターのラベル (名前) | 既定 | 説明 |
| Cluster node instance type ( ClusterNodeInstanceType) | c5.2xlarge | 自社の規模に適したアプリケーション ノードのタイプと希望するノード構成を「アプリケーションおよびデータベース ノード」で選択します。たとえば、Large のパフォーマンスを想定する場合、c5.4xlarge を選択します。 |
| Maximum number of cluster nodes ( ClusterNodeMax) | 1 | これらの両方のパラメーターの既定値は 1 です。「アプリケーションおよびデータベース ノード」で特定のノード数が推奨しているかどうかにかかわらず、この既定値は変更しないでください。1 つのアプリケーション ノードで Confluence Data Center をデプロイしてから、Confluence の構成後に拡張を行う必要があります。 |
| Minimum number of cluster nodes ( ClusterNodeMin) | ||
| データベース | ||
| パラメーターのラベル (名前) | 既定 | 説明 |
Database engine (DBEngine) | PostgreSQL | 既定の Amazon RDS データベースか Amazon Aurora を選択できます。 |
Database instance class (DBInstanceClass) | db.m4.large | 自社の規模に適したデータベース ノードのタイプと希望するノード構成を「アプリケーションおよびデータベース ノード」で選択します。たとえば、Large 用のパフォーマンスを想定する場合は、m4.2xlarge (Amazon RDS) または db.r4.xlarge (Amazon Aurora) を選択します。 |
| Master (admin) password ( DBMasterUserPassword) | N/A | マスター (postgres) アカウントのパスワード。このパスワードは 8 ～ 128 文字の英数字にし、大文字と小文字、数字、および 1 つ以上の記号 (/、@、&、"," 以外) を使用する必要があります。 |
| Enable RDS Multi-AZ deployment ( DBMultiAZ) | True | 既定では、選択したデータベースで高可用性機能が有効化されます。この設定は変更しないでください。 |
| Application user database password ( DBPassword) | N/A | データベース ユーザー アカウントのパスワード。このパスワードは 8 ～ 128 文字の英数字にし、大文字と小文字、数字、および 1 つ以上の記号 (/、@、&、"," 以外) を使用する必要があります。 |
| Bastion ホストのプロビジョニング | ||
| パラメーターのラベル (名前) | 既定 | 説明 |
Use/Deploy Bastion host (BastionHostRequired) | true | 選択したテンプレートに応じて、Bastion ホストをプロビジョニングするか、既存のものを使用するかを制御します。 AWS Systems Manager Sessions Manager 経由でノードにアクセスしたい場合は、これを |
| Networking | ||
| パラメーターのラベル (名前) | 既定 | 説明 |
SSL certificate ARN (SSLCertificateARN) | N/A | 「ステップ 2: SSL 証明書のインポート」から、証明書の Amazon Resource Name (ARN) を入力します。これにより、Confluence Data Center デプロイメントで SSL が有効化され、証明書を使用して接続が保護されます。 |
Availability Zones (AvailabilityZones) | N/A | ASI のサブネットに使用するアベイラビリティ ゾーンの一覧。クイック スタートでは、一覧から 2 つのアベイラビリティ ゾーンを選択し、ユーザーが指定した論理的な順序を保持します。 |
Permitted IP range (CidrBlock) | N/A | アトラシアン サービスへのアクセスを許可する CIDR IP 範囲を入力します。この値を、信頼できる IP の範囲に設定することをおすすめします。たとえば、ソフトウェアへのアクセスを会社ネットワークにのみ付与できます。 |
SSH キー ペア名 (KeyPairName) | N/A | |
| Application tuning | ||
| パラメーターのラベル (名前) | 既定 | 説明 |
| Confluence Heap Size Override ( JvmHeapOverride) | N/A | これを 8g に設定します。これは、これらの推奨事項の基盤となるテストで使用しているヒープ サイズと同じ値です。 |
- [Review] ページで、テンプレートの設定を確認します。[Capabilities] で、次のオプションを選択します。
- I acknowledge that AWS CloudFormation might create IAM resources with custom names.
- I acknowledge that AWS CloudFormation might require the following capability: CAPABILITY_AUTO_EXPAND
- [Create] を選択してスタックをデプロイします。
- スタックのステータスを監視します。ステータスが
CREATE_COMPLETEの場合、デプロイの構成の準備が整っています。 - スタックの [Outputs] タブに表示された URL を使用して、作成されたリソースを表示します。
ステップ 5: Confluence Data Center を構成する
クイック スタートは、1 つのアプリケーション ノード (min=1 および max=1 の Auto Scaling グループ) で Confluence Data Center をデプロイします。
- AWS CloudFormation スタックの [Outputs] タブに表示された URL を選択して、Confluence のセットアップ画面に移動します。URL にアクセスしたときに HTTP Error 503 レスポンスが表示される場合は、Confluence Data Center がまだ読み込み中です。これは通常の挙動です。2 ～ 3 分待ってから再試行してください。
- Confluence セットアップの [Get add-ons] ページで、[Next] を選択します。必要に応じ、セットアップ後にアドオンを有効化できます。
- [ライセンス キー] ページで、有効な Confluence Data Center ライセンスを入力してから、[次へ] を選択します。Confluence Data Center の有効なライセンスがない場合、[Get an evaluation license (評価ライセンスを取得)] を選択します。my.atlassian.com に移動して、そこから評価ライセンスを生成できます。このクイック スタートで Confluence Server ライセンスを使用することはできません。
- [Load Content] ページで、[Example Site] を選択します。
- [Configure User Management] ページで、[Manage Users and Groups within Confluence] を選択します。
- Confluence Data Center をセットアップするには、管理者アカウントとパスワードを作成する必要があります。管理者アカウントは Confluence 内のすべてのデータへの完全なアクセス権を持つため、このアカウントには強力なパスワードを選択することを強くおすすめします。管理者ユーザーの詳細を入力してから、[Next] を選択します。
[Setup Succesful] ページが表示されます。[詳細設定] を選択して Confluence 管理コンソールに直接移動し、これまでの手順で作成した管理者ユーザー アカウントを使用してログインします。
「Confluence Data Center 用 AWS クイック スタートの使用」に戻る
5. デプロイの拡張
Confluence Data Center を完全にデプロイして、必要なアプリケーションをインストールしたら、これをスケール アップできます。この手順では、アプリケーション クラスタが使用するノードの数を増やします (現時点ではノードは 1 つしかありません)。
新しいデプロイメントの [Confluence 管理] ページを開きます。このページにアクセスするには、AWS CloudFormation スタックの [Outputs] タブに表示される URL を使用します。そこから、管理コンソールのサイドバーの [クラスタリング] に移動します。次の画面のようなページが表示され、ノードでクラスタリングの準備が整ったことが示されます。
ステップ 1: アプリケーション ノードの数を拡張する
まず、アプリケーション ノードの数を増やします (アプリケーション データベース ノードで選択内容に応じて推奨された数に設定)。
- AWS マネジメント コンソールにサインインし、ナビゲーション バーのリージョン セレクタを使用してデプロイメントに対応した AWS リージョンを選択し、https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。
- デプロイメントの [Stack name] をクリックします。これにより、デプロイメントのスタック情報が表示されます。ここで、[Update] をクリックします。
- [Select Template] ページで [Use current template] を選択したままにし、[Next] を選択します。
- [Specify Details] ページで、[Parameters] セクションの [Cluster nodes] に移動します。ここで、次のパラメーターに対して希望する数のアプリケーション ノードを設定します。
- Minimum number of cluster nodes
- Maximum number of cluster nodes
- クリックしてスタックを更新します。
スタックの更新が完了すると、クラスタ ノードの静的な数が表示されます。
Auto Scaling の無効化について
クラスタの最小ノード数と最大ノード数が同じであるため、Auto Scaling が事実上無効化されています。
クラスタ ノードの最小数と最大数に異なる値を設定すると、Auto Scaling が有効になります。これにより、システム負荷に基づいてクラスタのサイズが動的にスケーリングされます。
ただし、Auto Scaling は無効化したままにすることをおすすめします。現時点では、Auto Scaling はご利用のデプロイメントのシステム負荷の急激な変化に効果的に対処できません。つまり、負荷に応じてクラスタを手動で再スケーリングする必要があります。
Confluence Data Center で、[管理] 
> [一般設定] > [一般設定] > [クラスタリング] に移動して、追加のノードがクラスタに含まれていることを確認します。
ステップ 2. 共同編集を有効にする (必要な場合)
Confluence Data Center 6.13 では、共同編集が既定で有効です。ただし、古いバージョンの Confluence Data Center では無効化されています。その場合、手動で有効化する必要があります。
- Confluence Data Center で、[管理] > [一般設定] > [一般設定] > [共同編集] に移動し、[オフ] になっていることを確認します。
- [共同編集] ページで [モードの変更] ボタン > [オン] の順に選択してから、[変更] を選択します。
- 共同編集がオンになり、Synchrony のステータスが実行中であることを確認します。
6. デプロイの強化と保護
デプロイメントを適切なサイズに拡張したら、Confluence の機能を拡張するために必要な任意のアプリをインストールできます。また、ユーザー アクセスの開始直前は、デプロイメントをさらに保護するためのよいタイミングです。
6.1 アプリのインストール
アプリをインストールする別の方法については、「Marketplace アプリケーションのインストール」を参照してください。詳細情報については、「Universal Plugin Manager の使用」を参照してください。
6.2 セキュリティの強化
SSL 証明書をインポートして SSL を有効化することで、Confluence Data Center デプロイメントへの接続の保護の第一歩を踏み出すことになります。「Confluence のセキュリティ設定のベストプラクティス」にしたがい、デプロイメントのセキュリティをさらに強化することができます。
セキュリティ リソースの詳細な一覧については、「Confluence セキュリティ設定」を参照してください。特に、以下を読んで理解しておくことをおすすめします。
また、Crowd 経由のシングル サインオン (SSO) を有効化することをおすすめします。SSO は、セキュリティ、管理性、利便性の優れたバランスを実現します。
6.3 既存の Confluence デプロイメントからの移行
既存の Confluence デプロイメントがある場合、これでユーザーとデータを移行できます。移行プロセスの詳細については、「既存の Confluence サイトを AWS に移行する」を参照してください。
7. インフラストラクチャの維持
- AWS マネジメント コンソール: 他のさまざまなサービス コンソールのインターフェイスになります。
- AWS Systems Manager: AWS のインフラストラクチャを閲覧および制御できます。
両方のサービスの詳細については AWS ドキュメントを参照してください。
7.1 SSH 経由でノードに接続する
AWS Systems Manager の Sessions Manager を使用して、デプロイメントでノードレベルの構成または保守タスクを実行できます。このブラウザベースのターミナルでは、SSH キーや Bastion ホストを使用せずにノードにアクセスできます。詳細については、「Session Manager の開始方法」を参照してください。
Bastion ホスト経由でのアクセス
Bastion ホストをデプロイ済みの場合、それを経由してノードにアクセスすることもできます。これを実行するには、SSH 秘密鍵ファイル (Key Name パラメータに指定した PEM ファイル) が必要です。このキーはデプロイ内のすべてのノードにアクセスできるため、安全な場所に保管するようにします。
この Bastian ホストは、デプロイの内部サブネットの任意のインスタンスへの ”踏み台” として機能します。つまり、まず Bastion ホストに接続し、そこからデプロイ内の任意のインスタンスにアクセスします。
Bastion ホストの公開 IP は、デプロイの ATL-BastionStack スタックの BastionPubIp 出力です。このスタックは、デプロイの Atlassian Standard Infrastructure (ASI) にネストされています。Bastion ホストにアクセスするには、次の例のように、ユーザー名として ec2-user を使用します。
ssh -i keyfile.pem ec2-user@<BastionPubIp>
ec2-user は、 sudo アクセスを持ちます。root による SSH アクセスは許可されません。
keyfile.pem 秘密鍵には、「Confluence Data Center 用 AWS クイック スタートの使用」の「ステップ 2: AWS アカウントを準備する」で作成したものを使用する必要があります。
7.2 バックアップと復元
Confluence Data Center のバックアップと復元の詳細については、以下のリソースを参照してください。
組織に他のバックアップ ツールがある場合、まず新しい Confluence Data Center でテストします。一部のツールは、大きなデータセットではうまく機能しない場合があります。
7.3 アップグレード
デプロイメントのアップグレードについて、次の点をご確認ください。
- Confluence Data Center の最新バージョンにアップグレードする前に、アプリにそのバージョンとの互換性があるかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。
- アップグレード中に Confluence Data Center を使用し続ける必要がある場合、サイト メンテナンス用の読み取り専用モードを使用することをおすすめします。ユーザーはページを閲覧することはできますが、作成したり変更したりすることはできません。
- 本番サイトをアップグレードする前に、ステージング環境でアップグレードを実施することを強くおすすめします。「Confluence のアップグレードのためのステージング環境の作成方法」には、これを行うための便利なヒントが記載されています。
デプロイメントを新しい長期サポート リリースにアップグレードする時期が来たら、次の手順を実行します。
ステップ 1: 実行中のすべての Confluence Data Center アプリケーション ノードの終了
Confluence Data Center スタックで使用されるアプリケーション ノードの数を 0 に設定します。その後、スタックを更新します。
デプロイメントでスタンドアロンの Synchrony を使用している場合、同時に Synchrony ノードの数を 0 にスケール ダウンします。
ステップ 2: Confluence Data Center スタックで使用されるバージョンの更新
Confluence Data Center で使用されるアプリケーション ノードの数を 1 に設定します。希望のバージョンを使用できるようにアプリケーション ノードを設定します。その後、スタックを再度更新します。
デプロイメントでスタンドアロンの Synchrony を使用している場合、同時に Synchrony ノードの数を 1 にスケール ダウンします。
ステップ 3: アプリケーション ノードの数の拡張
これで、デプロイメントをスケール アップしてアプリケーション ノードの数を元に戻せます。スタンドアロンの Synchrony がある場合は、Synchrony ノードでも同様に実行します。クラスタで使用されるノードの数の再構成方法の手順については、ステップ 1 を参照してください。
AWS の Confluence Data Center では現在、古いバージョンの最後のクラスタ ノードのシャットダウンと新しいバージョンの最初のクラスタ ノードの起動の間のダウンタイムが必須であり、インスタンスをダウンタイムなしでアップグレードすることはできません。新しいノードが新しいバージョンで起動する前に、既存のすべてのノードが終了していることを確認してください。
7.4 監視
Confluence Data Center の整合性と継続的な最適化を確保するには、監視は必須です。Confluence の健全性の追跡は、使用率の増加や再構成への準備に役立ちます。「Confluence Data Center のサンプル デプロイメントおよび監視戦略」では、アトラシアンの本番デプロイメントの 1 つの監視方法について説明しています。
追跡が必要なすべてのパラメーターを監視できるツールを選ぶことも重要です。傾向を特定できる十分な量のデータを構築することに焦点を当てます。これにより、アプリケーションの長期的な最適化を検討する際に、パフォーマンス スナップショットについて調べるところから開始することを避けられます。アトラシアンでは、Data Center アプリケーションの監視用ツールの一覧を作成しました。
7.5 インフラストラクチャの再拡張
新しいデプロイメントのアプリケーション ノード クラスタは Auto Scaling グループを使用しますが、これはクラスタ ノード数の静的制御のみを目的としています。Auto Scaling を使用してクラスタのサイズを動的に拡張することは推奨されません。アプリケーション ノードのクラスタへの追加には通常 20 分以上かかりますが、この速度では突然の負荷のスパイクに対処できません。それよりも、デプロイメントのパフォーマンスを定期的に監視し、必要に応じてアプリケーション ノード クラスタのサイズを手動で再拡張することをおすすめします。
高負荷および低負荷の期間を特定できる場合、それに応じてアプリケーション ノード クラスタのスケールをスケジュールできます。詳細については、「Amazon EC2 Auto Scaling のスケジュールに基づくスケーリング」を参照してください。
8. アトラシアンによるエンタープライズ サポート
時間の経過とともに、新しいテスト、知見、または Confluence Data Center の改善によって、推奨設定が変更されることがあります。Data Center のデプロイメントに最適な構成を選択する際にさらなる支援が必要な場合は、アトラシアンのテクニカル アカウント マネージャーにお問い合わせください。
アトラシアンのプレミア サポート チームは、お客様のデプロイメントとログを細かく分析してヘルス チェックを行い、お客様のインフラストラクチャ構成がお使いの Data Center アプリケーションに最適であることを確認します。ヘルス チェックでギャップや改善が必要な領域が判明した場合、プレミア サポートは実施可能な変更を提案いたします。
前述のデプロイ手順で使用した AWS クイックスタート テンプレートに対するアトラシアンのサポートや保守はすでに終了しています。より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることを強くお勧めします。