AWS で Jira Data Center の使用を開始する

Jira Data Center は AWS (Amazon Web Services) 環境に最適です。AWS では、追加のノードをリサイズおよびすばやく起動することでデプロイメントを柔軟にスケーリングできるだけでなく、Jira Data Center ですぐに動作する多数のマネージド サービスを利用し、あらゆる設定やメンテナンスを自動で処理できます。

Jira Data Center で利用できる機能に興味をお持ちの場合、こちらをクリックして概要をご確認ください。

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

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

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

Atlassian Standard Infrastructure (ASI)

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


以下は、Jira Data Center の Quick Start アーキテクチャの概要です。

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

  • インスタンス / ノード: Jira を実行している、クラスタ ノードとしての 1 つ以上の Amazon Elastic Cloud (EC2) インスタンス。
  • ロード バランサ: ロード バランサおよび SSL ターミネート リバース プロキシの両方として機能する Application Load Balancer (ALB)。
  • Amazon EFS ホスト: 複数の Jira ノードにアクセス可能な共通の場所にアーティファクトを保存する、共有ファイル システム。Quick Start アーキテクチャでは、高可用性構成の Amazon Elastic File System (Amazon EFS) サービスを使用して、共有ファイル システムを実装します。
  • データベース。共有データベースとしての Amazon Relational Database (RDS) インスタンス。
  • Amazon CloudWatch: Amazon のネイティブ CloudWatch サービスによる基本的なモニタリングおよび中央ログ。
  • コードおよびリポジトリ検索用の Amazon Elasticsearch Service ドメイン。

詳細は、「AWS での Jira 製品」を参照してください。

高度なカスタマイズ

迅速な実装のため、クイック スタートでは手動インストールと同じレベルのカスタマイズは提供していません。ただし、アトラシアンで使用している Ansible プレイブックの変数を通じてデプロイメントをさらにカスタマイズできます。

アトラシアンが提供しているすべての AWS クイック スタートでは、Ansible プレイブックを使用してデプロイメントの特定のコンポーネントを構成しています。これらのプレイブックは次のリポジトリで公開されています。

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

Ansible 変数を使用してこれらの構成をオーバーライドできます。詳細は、リポジトリの README ファイルを参照してください。

自身の S3 バケットからのクイック スタートのデプロイ (推奨)

クイック スタートをもっとも素早く起動する方法は、AWS S3 バケットから直接起動することです。だだしこれを行った場合、アトラシアンでクイック スタート テンプレートに加えているすべての更新がデプロイメントに直接伝播されます。これらの更新には、テンプレートからのパラメーターの追加や削除が含まれる場合があります。これにより、デプロイメントに予期しない (および大幅な) 変更が発生する可能性があります。

本番環境の場合、クイック スタート テンプレートを自身の S3 バケットにコピーすることをおすすめします。次に、それらをそこから直接起動します。これにより、クイック スタートの更新をデプロイメントに伝播するタイミングを制御できるようになります。

  1. クイック スタート テンプレート (すべてのサブモジュールを含む) をローカル マシンにクローンします。コマンド ラインから、以下を実行します。

    git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-jira.git
  2. (オプション) Quick Start templates リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。

    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
  3. AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。

  4. 自身のリージョンで 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 にデプロイする際に使用します。

  1. 選択したテンプレートで、QSS3BucketName の既定値は aws-quickstart に設定されています。この既定値を、作成済みのバケットの名前に置き換えます。
  2. クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。そこから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。

    aws s3 cp quickstart-atlassian-jira s3://<bucket-name> --recursive --acl public-read
  3. すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。

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

クイックスタートによって、(RDS の代わりに) Amazon Aurora クラスタ データベースを使用して Jira Data Center をデプロイすることもできます。 

クラスタは PostgreSQL 互換で、2 つのデータベース リーダーをレプリケートする、プライマリ データベース ライターを備えています。冗長性を向上させるため、異なるアベイラビリティ ゾーンにライターとリーダーをセットアップすることもできます。

ライターが失敗した場合、Aurora はリーダーの 1 つを自動的にプロモートしてライターにします。詳細は「Amazon Aurora の特徴: PostgreSQL 互換エディション」 を参照してください。

新しい Amazon Aurora クラスタ データベースを手動でセットアップし、それを Jira Data Center に接続する手順については、「Jira Data Center を Amazon Aurora に接続する」を参照してください。Amzon Aurora は Jira Software 8.4Jira Service Desk 4.4、およびそれ以降のバージョンでサポートされています。

Amazon CloudWatch による基本的なモニタリングおよび中央ログ

クイック スタートは、デプロイ内の各ノードを監視するように Amazon CloudWatch をインストールして構成します。これにより、各ノードの CPU、ディスク、およびネットワーク アクティビティのすべてを、事前設定した CloudWatch ダッシュボードから監視できます。既定では、Amazon CloudWatch は各ノードからログを収集し、単一の中央ソースに保存します。この中央ログにより、デプロイのログ データをより簡単かつ効果的に検索および分析できます。詳細については、「CloudWatch Logs Insights を使用したログ データの分析」および「フィルター パターンを使用したログ データ検索」を参照してください。

Amazon CloudWatch は基本的なロギングとモニタリングを提供しますが、コストもかかります。デプロイのコストを削減するために、ログを無効にするか、Amazon CloudWatch 連携を一緒にオフにすることができます。

tip/resting Created with Sketch.

ログ データをダウンロードするには (AWS 以外の場所でアーカイブおよび分析する場合など)、データを最初に S3 にエクスポートする必要があります。そこからダウンロードできます。詳しくは、「Amazon S3 へのログ データのエクスポート」を参照してください。

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

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

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

組織の負荷の傾向を調査するには、 デプロイのパフォーマンスを監視する必要があります。実施方法のヒントについては、「Jira Data Center のサンプル デプロイメントおよび監視戦略」を参照してください。 

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

Jira の実行に必要なサービスが提供されていないリージョンもあります。Amazon Elastic File System (EFS) をサポートするリージョンを選択する必要があります。対象となるリージョンは次のとおりです。

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

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

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

関連ページ:

最終更新日 2019 年 7 月 28 日

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

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