AWS でエンタープライズ規模の Jira をデプロイする: ステップバイステップ ガイド
デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりました。テンプレートは今後も利用できますが、保守や更新は行われません。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。
AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。
Jira Data Center は、高可用性と柔軟なスケーラビリティを実現するマルチノード クラスタリングをサポートしています。また、マルチノード クラスタリングにより、ゼロダウンタイム アップグレードが可能となり、予定されるダウンタイムを最小化できます。Jira Data Center を適切なインフラストラクチャにデプロイすることで、これらの機能を活用できます。
Jira Data Center には AWS クイック スタートが用意されています。このデプロイ方法は引き続き使用可能ですが、アトラシアンによるサポートと保守は終了しています。代わりに、より効率的で堅牢なセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることを強くお勧めします。
AWS クイック スタートでは、推奨される既定のプリセットでインフラストラクチャをデプロイするためのフレームワークが提供されていました。このフレームワークを使用すると、インフラストラクチャの各部分をゼロから構築する必要がなくなるため、デプロイを加速させることができました。クイック スタートで自身のインフラストラクチャを設計して、AWS ですばやくデプロイすることもできました。
このレガシー ドキュメントでは、AWS クイック スタートを使用したデプロイを効率化するために必要なナレッジ リソースのほとんどを 1 か所で確認できます。ここでは、Jira Data Center のエンドツーエンドのデプロイについて順を追って説明します。ここで説明する手順は、Jira Software Data Center と Jira Service Desk Data Center の両方で使用できます。
非クラスタ インフラストラクチャとクラスタ インフラストラクチャ
1. 留意すべきこと
Jira Data Center 用 AWS クイックスタートは必要なインフラストラクチャを適切に用意し、設定に必要なすべてのコンポーネントを準備します。このドキュメントで Jira Data Center インスタンスをデプロイするために使用できるテンプレートを提供します。
1.1 このドキュメントはクイック スタートのデプロイメント ガイドとは異なりますか?
はい。このドキュメントでは、エンタープライズ規模の組織に適した、リファレンス デプロイメントを示します。その後、デプロイメント プロセス全体を順を追って説明します (これには、Jira Data Center 用 AWS クイック スタートの使用を含みます)。また、大規模な Jira Data Center を管理してきた当社の知識と経験に基づいた推奨事項を提供しています。
Jira Data Center 用 AWS クイック スタートには独自のデプロイメント ガイドが付属しています。このガイドは、クイック スタートを使用して AWS で Jira Data Center をデプロイする方法を示しています。ただし、ガイドはあらゆるサイズの組織向けに設計されており、特定のリファレンス デプロイメントの推奨設定は提供していません。
1.2 サードパーティのクラウド プラットフォームを使用する理由
Jira Data Center をホストする際は、物理サーバーを使用するよりも、AWS などのサードパーティのクラウド プラットフォームを使用するほうが、多くのメリットが得られます。一例として、組織は物理ハードウェアのデプロイ、管理、拡張という負荷のかかる作業の大部分から解放されます。
アトラシアンでは AWS と協力してこのクイックスタートを開発し、ほとんどのタイプの組織で高度な構成を行えるようにしました。弊社では、Kubernetes に移行するまでの間、このクイックスタートを使用し、社内の異なるチーム向けに Jira Data Center のデプロイおよび管理を行っていました。このクイックスタートを作成する際に使用された多数の設計原則は、社内の AWS デプロイから学んだ内容によるものです。
1.3 "エンタープライズ規模" の定義
本ドキュメントは、エンタープライズ規模の組織が Jira Data Center をデプロイし、ニーズに合わせて調節するための方法に焦点を当てています。アトラシアンでは、Large または XLarge インスタンス (弊社の「Jira Data Center の負荷プロファイル」に基づく) の組織をエンタープライズ規模の組織として定義しています。
1.4 これらの推奨設定が自社に適しているかどうかをどのように確認できますか?
本ドキュメントにおける推奨設定の大部分は、以下に基づいています。
- ベンチマーク: 「Jira Data Center: AWS でのエンタープライズ インスタンスの推奨インフラストラクチャ」で、エンタープライズ規模でアーキテクチャを設計する方法についてのガイダンスを確認できます。このガイダンスは広範なテストに基づいており、その方法についても記事内でご確認いただけます。このドキュメントでは複数の箇所で、同じ推奨設定を使用しています。
- エクスペリエンス: アトラシアンの本番環境で、最大規模の Jira Data Center のデプロイメントをいくつか実行しています。これは、何千人ものアトラシアン社員にとって Jira が不可欠なためです。またこれにより、エンタープライズ規模で Jira Data Center を実行する方法を直接確認しています。弊社ではこのようなプロセスで実際の状況を多く確認しており、推奨設定の多くはこれに基づいています。
- 顧客調査: アトラシアンは多数のお客様やパートナーを支援しており、その過程で製品の使用方法についても学んでいます。これにより、インフラストラクチャのデプロイや保持についてお客様が直面している問題を確認しています。推奨設定は、このような問題の解決に役立つように設計されています。
これらの推奨設定は、大多数のエンタープライズ規模の組織に最適であると弊社で考え、推奨しているものであることにご注意ください。要件や発生する事象は組織ごとに異なり、それらに応じて別の戦略が必要になる可能性があります。これらの推奨設定は、要件をうまく解決するために調整するためのベースラインとして使用してください。
1.5 前提条件となるスキル
このドキュメントでは、AWS での Jira Data Center のデプロイについて説明します。インストールするアプリケーション (Jira Software または Jira Service Desk) に慣れている管理者を対象としています。
- Linux サーバーの管理方法
- AWS の UI を通じた AWS リソースのナビゲート方法
1.6 デプロイメントの内容
弊社でほとんどのエンタープライズ規模の組織の基盤として使用している、リファレンス アーキテクチャを提供します。このリファレンス アーキテクチャには各コンポーネントの短い説明が含まれているため、期待される内容を確認できます。
次に、組織のサイズ (または負荷プロファイル) を評価し、適切な構成を選択して、それを要件に合わせて調整する方法について説明します。そこから、アトラシアンの完全なサポート対象である AWS クイック スタートを使用して、これらの設定を AWS デプロイメントに適用する方法について説明します。クイック スタートではほかのパラメータもカスタマイズできますが、ここでは詳しく網羅しません。
2. リファレンス アーキテクチャ
以下の図は、クイック スタートを通じてデプロイする基本アーキテクチャを示します。
2.1 Bastion ホスト
このホストにより、Jira Data Center をインターネットに公開することなく、そこに安全にアクセスできるようになります。詳しくは、「Bastion ホスト」を参照してください。
2.2 Amazon Application Load Balancer
AWS に Jira をデプロイする際は、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 には Jira Data Center に必要な基本ネットワーク コンポーネントが含まれており、共有インフラストラクチャでの複数の Atlassian Data Center 製品の連携を簡単に行えるようにします。以下の図は、ASI によってセットアップされるさまざまなコンポーネントを示しています。
2.4 クラスタ化されたアプリケーション デプロイメント
Jira Data Center インフラストラクチャの主要なコンポーネントの 1 つは、クラスタ化されたアプリケーション デプロイメントです。クラスタ化により、Jira アプリケーションに優れたパフォーマンスや高可用性が提供されます。
「Jira Data Center のインストール」では、Jira のあらゆるクラスタリング要件について説明しています。Jira Data Center 用の AWS クイック スタートではクラスタの構成を簡素化しています。これにより、管理者は使用するノードを選択するだけで、クイック スタートが残りを必要に応じてセットアップします。
2.5 高可用性を実現するデータベース
このクイック スタートでは、2 つのサポート対象データベース (Amazon RDS for PostgreSQL (既定) または Amazon Aurora の特徴: PostgreSQL 互換エディション) のいずれかを使用して Jira Data Center をデプロイできます。いずれかを構成し、独自の組み込みのフェイルオーバー機能を使用して、高可用性を実現できます。
2.6 Amazon Elastic File System (EFS)
Jira Data Center は共有ファイル システムを使用し、添付ファイル、アバター、アイコン、インポート / エクスポート ファイル、プラグインなどのアーティファクトを、すべての Jira ノードでアクセス可能な共通の場所に保存します。クイック スタート アーキテクチャでは、高可用性構成の Amazon Elastic File System (Amazon EFS) サービスを使用して共有ファイル システムを実装します。
2.7 Amazon CloudWatch
既定では、Amazon CloudWatch は各ノードからログを収集し、単一の中央ソースに保存します。この中央ログにより、デプロイのログ データをより簡単かつ効果的に検索および分析できます。詳細については、「CloudWatch Logs Insights を使用したログ データの分析」および「フィルター パターンを使用したログ データ検索」を参照してください。
Amazon CloudWatch は基本的なロギングとモニタリングを提供しますが、コストもかかります。デプロイのコストを削減するために、デプロイ中にはログを無効にするか、Amazon CloudWatch 連携をオフにすることができます。
ログ データをダウンロードするには (AWS 以外の場所でアーカイブおよび分析する場合など)、データを最初に S3 にエクスポートする必要があります。そこからダウンロードできます。詳しくは、「Amazon S3 へのログ データのエクスポート」を参照してください。
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 アプリケーション ノードとデータベース ノード
「Jira Data Center: AWS でのエンタープライズ インスタンスの推奨インフラストラクチャ」では、アプリとデータベースで使用する、推奨されるノード構成 (インスタンスのタイプおよび数) について説明しています。これらの推奨設定は、異なる Jira Data Center 負荷プロファイルで実行した堅牢なパフォーマンス テストに基づいています。
エンタープライズ規模の組織の Jira Data Center デプロイメントは通常、"Large" または "XLarge" です。次の表の値で、お客様の組織に適したデプロイメントをご確認ください。
メトリック | 大 | XLarge (特別データ セット) |
|---|---|---|
| 課題 | 600,000 ~ 2,000,000 | 7,206, 140 |
| プロジェクト | 800 ～ 2,500 | 3,001 |
| ユーザー | 10,000 ～ 100,000 | 80,002 |
| カスタム フィールド | 800 ～ 1,800 | 1,513 |
| ワークフロー | 200 ～ 600 | 601 |
| グループ | 10,000 ～ 50,000 | 6,525 |
| コメント | 1,000,000 ～ 4,000,000 | 55,089, 850 |
| 権限スキーム | 100 ～ 400 | 100 |
| 課題セキュリティ スキーム | 200 ～ 800 | 4 |
XLarge 特別データ セット
現在、Jira Data Center の負荷プロファイルには、公式の XLarge 範囲はありません。弊社では XLarge の代わりとして、「Jira Data Center: AWS でのエンタープライズ インスタンスの推奨インフラストラクチャ」の特別なデータ セットを使用しました。このデータ セットは、弊社がこれまでに確認した XLarge 規模のほとんどのお客様やテスト インスタンスを表しています。
Large と XLarge のどちらに該当するかを確認したら、インフラストラクチャに必要なノード構成のタイプを記録します。それぞれのノード構成には異なるメリットがあり、弊社の内部テストではすべてが Apdex 0.7 以上を示しています。これは、社内での Jira Data Center デプロイメントのパフォーマンスを評価および管理する際に使用するターゲット Apdex と同じものです。
テストベースの推奨事項
ここで提供している推奨設定のいくつかはテスト結果に基づいたものであり、ご自身で必要なノード構成のベースラインに便利です。ご自身の環境でのパフォーマンスの結果は、サードパーティ製アプリ、データ、トラフィック、インスタンス タイプなどの多くの要因によって異なります。このため、弊社で使用しているターゲット Apdex をご利用の環境では再現できない可能性があります。これらの推奨設定の基本を理解するには、「テスト手法」をご確認ください。
3.2.1 Large
| ノード構成 | Application nodes | データベース ノード | |
|---|---|---|---|
| RDS | Aurora | ||
| パフォーマンス / 安定性 | c4.8xlarge x 3 | db.m5.4xlarge | db.r5.4xlarge |
| 低コスト | c4.8xlarge x 2 | ||
Jira Data Center 8.5 のテストは、少ないノード数で強力なハードウェアを使用すると最適なパフォーマンスを実現できることを示しています。使用されているインスタンス タイプ (c4.8xlarge) は 36 CPU および 60 GB RAM を持ちます。このタイプを 2 または 3 ノード使用することで、最適なパフォーマンスを適切なコストで実現できます。これらの主な違いは、フォールト トレランスとコストです。
3.2.2 XLarge
| ノード構成 | Application nodes | データベース ノード | |
|---|---|---|---|
| RDS | Aurora | ||
| パフォーマンス / 安定性 | c5.9xlarge x 6 | db.m5.4xlarge | db.r5.4xlarge |
| 低コスト | c5.4xlarge x 6 | ||
XLarge では、ここで使用されているアプリケーション ノード タイプの違いを考慮して慎重に選択する必要があります。パフォーマンス / 安定性構成では、低コスト構成よりもパフォーマンスがおよそ 11% 向上します。ただし、低コスト構成ではコストを 57% 抑えられます。
3.3 HTTPS のセットアップ
セキュリティを強化するため、HTTPS を有効化することを強くおすすめします。クイック スタートではこのプロセスを簡素化し、有効な証明書のみを要求します。証明書の取得方法には 2 つのオプションがあります。
オプション 2: 信頼できる認証局が発行した有効な証明書を取得できます。証明書を入手したら、それを AWS Certificate Manager にインポートする必要があります。
3.4 アプリの互換性の確認
既定では、クイック スタートは Jira Data Center 8.5 (最新の長期サポート リリース バージョン) をデプロイします。選択したバージョンに対して、インストールしたいアプリの互換性を確認する必要があります。
4. Jira Data Center 用 AWS クイック スタートの使用
このセクションでは、エンドツーエンドのデプロイメントについて順を追って説明します。ここでは、新しい ASI をデプロイしてから、そこに Jira Data Center をデプロイします。この ASI をその他すべてのアトラシアン Data Center 製品のデプロイ先として選択 (および Confluence と連携) して、基本的なネットワーク スタックとして機能させることができます。
クイック スタート ガイド
次の手順は、「AWS Cloud での Jira 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-jira.git - (オプション) クイックスタート テンプレート リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。
quickstart-atlassian-jira├─ submodules│ └─ quickstart-atlassian-services│ └─ templates│ └── quickstart-vpc-for-atlassian-services.yaml└─ templates├── quickstart-jira-dc-with-vpc.template.yaml└── quickstart-jira-dc.template.yaml AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。
自身のリージョンで S3 バケットを作成します。
aws s3 mb s3://<bucket-name> --region <AWS_REGION>
この時点で、クイック スタート テンプレートを自身の S3 バケットにアップロードできるようになりました。これを行う前に、使用するクイック スタート テンプレートを選択する必要があります。
quickstart-jira-dc-with-vpc.template.yaml: 新しい ASI へのデプロイ (エンドツーエンドのデプロイメント) に使用します。quickstart-jira-dc.template.yaml: 既存の ASI にデプロイする際に使用します。
- 選択したテンプレートで、
QSS3BucketNameの既定値はaws-quickstartに設定されています。この既定値を、S3 バケットの名前に置き換えます。 クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。ここから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。
aws s3 cp quickstart-atlassian-jira s3://<bucket-name> --recursive --acl public-read
- すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。
ステップ 5: デプロイメントをカスタマイズする
[Specify Details] ページで、必要に応じてスタック名を変更します。テンプレートのパラメーターを確認し、デプロイメントをカスタマイズします。
[Jira Product] ドロップダウンを使用して、インストール対象を選択します。
- Jira Core (Core)
- Jira Software (Software)
- Jira Service Desk (ServiceDesk)
設定する最初のパラメーターは、使用する製品バージョン (JiraVersion) です。
ただし、既存のデプロイメントからデータを移行する予定がある場合、代わりにそのデプロイメントのバージョンを使用してください。これにより、不一致やデータ消失などにつながるリスクを回避することができます。移行プロセスを完了した後で、いつでもアップグレードすることができます。
既定のバージョンは Jira Core と Jira Software の長期サポート リリースです。Jira Service Desk は異なるバージョン番号を使用します。適切な Jira Service Desk バージョンについては、Jira アプリケーションの互換性マトリクスを参照してください。
次の表では、「デプロイメントに適した設定の選択」でこれまでにおこなった選択を実装できる、その他のオプションを説明しています。
| Cluster Nodes | ||
|---|---|---|
| パラメーターのラベル (名前) | 既定 | 説明 |
Enable CloudWatch integration (CloudWatchIntegration) | Metrics and Logs | Amazon CloudWatch で必要な監視レベルを設定します。既定では、Amazon CloudWatch は基本的なモニタリングおよび中央ログを実行します。コストが問題になる場合、[Metrics Only] (中央ログを無効化) または [Off] (Amazon CloudWatch をまとめて無効化) を選択します。 |
| Cluster node instance type ( ClusterNodeInstanceType) | t3.medium | 自社の規模に適したアプリケーション ノードのタイプと希望するノード構成を「アプリケーションおよびデータベース ノード」で選択します。たとえば、Large のパフォーマンスを想定する場合、c4.8xlarge. を選択します。 |
| Maximum number of cluster nodes ( ClusterNodeMax) | 1 | これらの両方のパラメーターの既定値は 1 です。「アプリケーションおよびデータベース ノード」で特定のノード数が推奨しているかどうかにかかわらず、この既定値は変更しないでください。1 つのアプリケーション ノードでデプロイを行い、Jira Data Center を構成したあとに拡張を行う必要があります。 |
| Minimum number of cluster nodes ( ClusterNodeMin) | ||
| データベース | ||
| パラメーターのラベル (名前) | 既定 | 説明 |
Database engine (DBEngine) | PostgreSQL | 既定の Amazon RDS データベースか Amazon Aurora を選択できます。 |
Database instance class (DBInstanceClass) | db.t2.medium | 自社の規模に適したデータベース ノードのタイプと希望するノード構成を「アプリケーションおよびデータベース ノード」で選択します。たとえば、Large のパフォーマンス / 安定性を想定する場合は、 db.m4.4xlarge (Amazon RDS) または db.r4.4xlarge (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) を入力します。これにより、デプロイメントで SSL が有効化され、証明書を使用して接続が保護されます。 |
Availability Zones (AvailabilityZones) | N/A | ASI のサブネットに使用するアベイラビリティ ゾーンの一覧。クイック スタートでは、一覧から 2 つのアベイラビリティ ゾーンを選択し、ユーザーが指定した論理的な順序を保持します。 |
Permitted IP range (CidrBlock) | N/A | アトラシアン サービスへのアクセスを許可する CIDR IP 範囲を入力します。この値を、信頼できる IP の範囲に設定することをおすすめします。たとえば、ソフトウェアへのアクセスを会社ネットワークにのみ付与できます。 |
SSH キー ペア名 (KeyPairName) | N/A | |
| DNS (オプション) | ||
| パラメーターのラベル (名前) | 既定 | 説明 |
Existing DNS Name (CustomDnsName) | N/A | 公開されている Jira デプロイメントの場合、適切なドメイン名を使用します。このドメイン名をサードパーティ サービスを通じて登録する必要があります。 |
| Application tuning | ||
| パラメーターのラベル (名前) | 既定 | 説明 |
| JVM 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: Jira Data Center を構成する
クイック スタートは、1 つのアプリケーション ノード (min=1 および max=1 の Auto Scaling グループ) で Jira Data Center をデプロイします。
- AWS CloudFormation スタックの [Outputs] タブに表示された URL を選択して、Jira のセットアップ画面に移動します。URL にアクセスしたときに HTTP Error 503 レスポンスが表示される場合は、Jira Data Center がまだ読み込み中です。これは通常の挙動です。2 ～ 3 分待ってから再試行してください。
- [Setup application properties] ページで Jira アプリケーション デプロイメントのタイトルを入力し、必要なモードを選択します。ベース URL には、[Existing DNS Name] で以前に使用したドメイン名が表示されます。[Next] を選択します。
- [Specify your license key] ページで、有効な Jira Software または Service Desk Data Center のライセンス キーを入力します。Jira アプリケーションの有効なライセンスがない場合は、Jira のトライアル ライセンスを生成 し、評価用 Data Center ライセンスにサインアップします。
- Jira Data Center アプリケーションをセットアップするには、管理者アカウントとパスワードを作成する必要があります。管理者アカウントは Jira のすべてのデータへの完全なアクセス権を持つため、このアカウントには強力なパスワードを選択することを強くおすすめします。管理者のユーザー詳細を入力してから、[Next] を選択します。
- [Set up email notifications] ページで [Later] を選択し、[Finish] を選択します。
- 最初の [Welcome to Jira] ページで言語を選択し、[Continue] を選択します。
- 2 番目の [Jira にようこそ] ページで、必要に応じてプロフィールのアバターを選択し、[次へ] を選択します。
- [ようこそ] ページで [サンプル プロジェクトの作成] を選択し、プロジェクトの名前を入力します。
- [設定] (右上の歯車アイコン) > [システム] の順に選択します。
- [クラスタ ノード] セクションにスクロールすると、
Active状態の現在のノードが表示されます。
お客様の Jira デプロイで、ノードを追加し、既存のノードと自動的にクラスタ化する準備が整いました。
Jira Data Center 用 AWS クイック スタートの使用に戻る
5. デプロイの拡張
Jira Data Center を完全にデプロイしたら、これをスケール アップできます。この手順では、アプリケーション クラスタが使用するノードの数を増やします。現時点ではノードは 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
- クリックしてスタックを更新します。
スタックの更新が完了すると、クラスタ ノードの静的な数が表示されます。Jira のシステム情報ページの [クラスタ ノード] セクションを表示して、追加ノードがクラスタを形成していることを確認してください。
Auto Scaling の無効化について
クラスタの最小ノード数と最大ノード数が同じであるため、Auto Scaling が事実上無効化されています。
クラスタ ノードの最小数と最大数に異なる値を設定すると、Auto Scaling が有効になります。これにより、システム負荷に基づいてクラスタのサイズが動的にスケーリングされます。
ただし、Auto Scaling は無効化したままにすることをおすすめします。現時点では、Auto Scaling はご利用のデプロイメントのシステム負荷の急激な変化に効果的に対処できません。つまり、負荷に応じてクラスタを手動で再スケーリングする必要があります。
6. デプロイの強化と保護
デプロイメントを適切なサイズに拡張したら、Jira の機能を拡張するために必要な任意のアプリをインストールできます。また、ユーザー アクセスの開始直前は、デプロイメントをさらに保護するためのよいタイミングです。
6.1 アプリのインストール
アプリをインストールする別の方法については、「Marketplace アプリケーションのインストール」を参照してください。詳細情報については、「Universal Plugin Manager の使用」を参照してください。
6.2 セキュリティの強化
SSL 証明書をインポートして SSL を有効化することで、デプロイへの接続の保護の第一歩を踏み出すことになります。デプロイのセキュリティの強化の詳細については、「セキュリティのベスト プラクティスのための Jira サーバー アプリケーション構成」を参照してください。
セキュリティ リソースの詳細な一覧については、「サーバーの最適化」を参照してください。特に、以下を読んで理解しておくことをおすすめします。
また、Crowd 経由のシングル サインオン (SSO) を有効化することをおすすめします。SSO は、セキュリティ、管理性、利便性の優れたバランスを実現します。
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 秘密鍵には、「Jira Data Center 用 AWS クイック スタートの使用」の「ステップ 2: AWS アカウントを準備する」で作成したものを使用する必要があります。
7.2 バックアップと復元
「データのバックアップ」および「データの復元」ページでは、バックアップと復元のプロセス、およびそれぞれの推奨事項について説明します。
7.3 既存の Jira デプロイメントからの移行
AWS に既存のインスタンスを移行するには:
- データベースを PostgreSQL に移行します。
- 既存のホーム ディレクトリとデータベースのバックアップを作成します。
- バックアップ ファイルをファイル サーバー EC2 インスタンスにコピーします。
- ファイル サーバーの
/media/atl/jira/sharedでバックアップ ファイルを展開します。 pg_restoreを使用して、バックアップ ファイルに含まれる PostgreSQL データベースのダンプを RDS インスタンスにリストアします。
7.4 アップグレード
デプロイメントのアップグレードについて、次の点をご確認ください。
- Jira Data Center の最新バージョンにアップグレードする前に、アプリにそのバージョンとの互換性があるかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。
- アップグレード中もユーザーに Jira Data Center を提供する必要がある場合、ゼロ ダウンタイムで Jira Data Center をアップグレードすることをご検討ください。この方法ではノードを 1 つずつアップグレードしながら異なる Jira バージョンで動作させるため、アップグレード中もユーザーが Jira を利用できます。
- 本番サイトをアップグレードする前に、ステージング環境でアップグレードを実施することを強くおすすめします。「Jira のテスト環境を作成する」には、これを行うための便利なヒントが記載されています。
詳細な手順 (ゼロ ダウンタイムで Jira Data Center をアップグレードする方法を含む) については、「AWS での Jira Data Center のアップグレード」を参照してください。ゼロダウンタイム アップグレード (AWS 外) の詳細については「Jira Data Center をゼロ ダウンタイムでアップグレードする」を参照してください。
7.5 監視
デプロイメントの整合性と継続的な最適化を確保するには、監視は必須です。健全性の追跡は、使用率の増加や再構成への準備に役立ちます。「Jira Data Center のサンプル デプロイメントおよび監視戦略」では、アトラシアンの本番デプロイメントの 1 つの監視方法について説明しています。
Amazon CloudWatch を有効化している場合、中央ログと基本ノード監視はすでに行われています。中央ログにより、デプロイメントのログ データをより簡単かつ効果的に検索および分析できます。
Jira 8.4 では、ボトルネックを分析してアラートを表示するために使用できる、多数のモニターを導入しました。詳細については、「Jira Data Center の監視」を参照してください。
7.6 インフラストラクチャの再拡張
新しいデプロイメントのアプリケーション ノード クラスタは Auto Scaling グループを使用しますが、これはクラスタ ノード数の静的制御のみを目的としています。Auto Scaling を使用してクラスタのサイズを動的に拡張することは推奨されません。アプリケーション ノードのクラスタへの追加には通常 20 分以上かかりますが、この速度では突然の負荷のスパイクに対処できません。それよりも、デプロイメントのパフォーマンスを定期的に監視し、必要に応じてアプリケーション ノード クラスタのサイズを手動で再拡張することをおすすめします。
高負荷および低負荷の期間を特定できる場合、それに応じてアプリケーション ノード クラスタのスケールをスケジュールできます。詳細については、「Amazon EC2 Auto Scaling のスケジュールに基づくスケーリング」を参照してください。
8. アトラシアンによるエンタープライズ サポート
推奨設定は、新しいテスト、知見、または Confluence Data Center の改善によって、時間の経過とともに変更されることがあります。Data Center デプロイメントに最適な構成を選択する際にさらなる支援が必要な場合は、アトラシアン Advisory Service にお問い合わせください。
アトラシアンのプレミア サポート チームは、お客様のデプロイメントとログを細かく分析してヘルス チェックを行い、お客様のインフラストラクチャ構成がお使いの Data Center アプリケーションに最適であることを確認します。ヘルス チェックでギャップや改善が必要な領域が判明した場合、プレミア サポートは実施可能な変更を提案いたします。
前述のデプロイ手順で使用した AWS クイックスタート テンプレートに対するアトラシアンのサポートや保守はすでに終了しています。より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることを強くお勧めします。