2019/12/07
AWSのQuick Startを利用してわかったJira Software Data Center 構築の勘所
Author
奥村 和彦Kazuhiko Okumura
Atlassian Data Center は、アプリケーションを複数のノードでの分散稼働が行えるため、高可用性・ディザスターリカバリー・スケーラビリティを実現することができます。
とくにAtlassian製品を大人数で利用する、あるいは高負荷な状態での利用が考えられる場合にその価値も高まります。
これらのメリットを得るために、インフラストラクチャーの構成を冗長になるように設計したり、何度も同じソフトウェアのセットアップを行わなければなりません。
そこで以下のような技術を使うと簡単に実現できます。
- AWSやAzureと言ったIaaSベンダーのサービスを利用して、インフラストラクチャ―の冗長化構成を用意する
- インフラストラクチャーとソフトウェアのセットアップをコードで実行するInfrastructure as Code (IaC) によって、アプリケーションを素早く立ち上げる
AtlassianではAWSおよびAzureを利用したData Centerを立ち上げる、Quick Startを提供しています。
このQuick Startは、Atlassianが作成した大きく以下の2種類の設定コードを実行する事で、Data Centerを自動で立ち上げることができます。
- AWSのCloud Formationによる、インフラストラクチャ―を構築するテンプレート
- Ansibleによる、Jira Software Data Centerのインストールとセットアップを実行するPlaybook
以前、こちらのブログでAWSのQuick Startによる構築手順をご紹介していますので、Data Centerの立ち上げ手順はこちらをご覧いただくとして、今日はJira Software Data CenterをQuick Startで構築したことで得た気づきをお話したいと思います。
尚、AWSや公開されているコードは随時更新されていきます。画面や設定できる内容などもどんどん変わっていきますのでご注意ください。
前準備として知っておくとよいコト
AWS Quick Startで構築するときのポイントを4つ挙げておきます。
東京リージョンで構築できます
- 前述のブログでは、執筆時点の注意点として「東京リージョンでは利用できないかも」とさせて頂いていましたが、今回、東京リージョンでもDataCenterが利用できることを確認しました。
- ただし、AWSのQuick StartページのリンクからCloud Formationに移動した際に、選択中のリージョンがオハイオやオレゴンとなっている場合があります。必ずパラメータを入力する前に東京リージョンに変更してください。
EC2インスタンスのKeyPair（SSH公開鍵）を作成しておく
- Quick Startで構築するEC2インスタンスにアクセスするためのKeyPairを事前に作成してください。
- 作成は [EC2 > KeyPairs] から行えます。
- 作成したKeyPairは、Data Centerを起動するだけであれば、Cloud FormationのパラメータにKeyPair名を入力するだけなのでダウンロードは不要です。
- 後述の踏み台サーバー（Bastion host）へのSSHアクセス、および踏み台サーバーからJira Software Data Centerインスタンス (以下、Jiraノード)にアクセスする際は必要になるので、KeyPairをダウンロードしておいてください。
- 起動するすべてのEC2インスタンスで同じKeyPairを利用します。
ドメインを取得する
- 独自ドメインでData Centerにアクセスする場合は、Cloud Formationのパラメータに設定するので、あらかじめドメインの取得しておいてください。
- IPアドレスは構築後にCloud Formationからエンドポイントとして払い出されるので、その後にドメインとのルーティングを行ってください。
- ドメインを指定しなかった場合は、Cloud Formationから提供されます。
SSL証明書を用意する
- HTTPSでアクセスしたいときには、事前にSSLサーバー証明書を用意しておきます。（必然的に独自ドメインも作成することになります）
- SSLサーバー証明書は、AWS Certificate Management (ACM)にインポートしてください。ここで払い出されたARN (AWS Reource Name)をCloud Formationのパラメータに入力します。
- ACMで作成したサーバー証明書を利用することもできます
注意が必要なCloud Formation のパラメータ
すべてのパラメータの話をすると長くなるので、とくに気を付けておきたいパラメータだけを説明します。
Version (Jira setup)
- インストールするJiraのバージョン番号を指定します。
- リリースされている最新バージョンも指定できます。
- インストーラーファイルの atlassian-jira-software-X.X.X-x64.bin のX.X.Xにこのパラメータの入力値を利用してダウンロードしています。
Cluster nodes (Jira setup)
- T2インスタンスも選択できますが、非推奨となっています。
- 後述のJVMヒープサイズのデフォルト値は、選択したインスタンスタイプによって決定されます。
Maximum / Minimum Numbers of Cluster nodes (Jira setup)
- DataCenterを初回作成する際は、必ずMinもMaxも1としてください。
- 1台目のノード起動後に実際に立ち上げたいノード数を指定します。
- Maximumは、高負荷とみなされたときに起動するノードの上限数です。
※ちなみにQuick Startで立ち上げただけだと、この数値は参照されていません。起動後にAWSのAuto Scalingサービスで設定する必要があります。 - Minimumは、必ず起動するノード数です。負荷に関わらずここで指定したノード数を常に起動します。
Custom Command-line parameters for Ansible (Jira setup)
- PostgreSQLのLocaleをCにするため、`-e atl_jdbc_collation=C -e atl_jdbc_ctype=C -e atl_jdbc_template=template0` を入力してください。
- このパラメータはAnsibleでData Centerアプリケーションのインストールとセットアップの際に参照するパラメータです。
Application user database Password (Database)
- DatabaseのJiraユーザーのパスワードを入力してください。(Cloud Formationのパラメータの説明文が間違っているので気を付けてください。)
- postgresユーザーのパスワードは、[Master (admin) Password] に入力します。
- どちらのパスワードも大文字／小文字／数字／記号が1つ以上無いとエラーになります。
Trusted IP range (Networking)
- 外部からData Centerへのアクセスを許可するIPアドレスを入力します。
- 入力したIPアドレスは、AWS のSecurity GroupのInboundに登録されます。
Availability zones (Networking)
- ノードを作成するAZを2つ以上選択してください。
- 起動するノード数が2つ以上の場合に、ここで指定したAZに振り分けます。
SSH Key Pair Name (Networking)
- 前述した作成済みのKeyPair名を入力します。
- 拡張子[.pem]は入力しないでください。Cloud Formationを起動するときにエラーとなります。
SSL Certificate ARN (Networking)
- SSLサーバー証明書を利用するときに、ACMにインポートした証明書のARNを入力します。
Tomcat Context Path (Application Tuning)
- アクセスURLのコンテキストパスを指定します。
- `/jira` とすると、http(s)://(domain名)/jira でアクセスすることができます。
- 必ず/を入れてください。
JVM Heap Size Override (Application Tuning)
- JVM ヒープサイズを指定したいときに入力してください。
- 未入力の場合は、ノードのインスタンスタイプごとに決まったヒープサイズとなります。
- t3.mediumだと2048m、デフォルトのc5.xlargeなら5120m です。それ以外は、Cloud formationのテンプレートをご覧ください。
Quick Startで構築して気づいたこと
ここからは実際に構築したり、バージョンアップ作業を行ったことで気づいた点を挙げます。
高可用性・ディザスターリカバリー・スケーラビリティは、AWSのサービスで実現している
- Atlassian Data Centerとしては、アプリケーションデータ (e.g. /var/atlassian/application-data) を外部共有ディレクトリで管理することで、クラスタリング化を実現しています。
- ネットワーク構成(VPC/サブネット)、ノード(EC2)に対する負荷分散(ALB) / 監視 (CloudWatch) / スケーリング (Auto Scaling)、そしてDB (RDS)と共有ディレクトリ (EFS)の冗長化は、すべてAWSのサービスによって実現しています。
- つまりAtlassian Data Centerをオンプレミスで構築する場合には、これらのAWSサービスと同等のインフラストラクチャーを構成する必要があります。
Bastionホストとはいわゆる踏み台サーバーのこと
- これはVPCネットワーク上のPublic subnetに配置されて、外部からKeyPairを使ったSSH接続が行える。
- Security Groupの設定によって、Bastion HostからPrivate subnetのEC2インスタンスやサービスにアクセスすることができます。
- 上記の図ではAZごとにBastion hostが作られ、AutoScaling対象になっているように見えますが、実際には一つのAZにしか作成されずAutoScalingも行いません。
最初のノードのインストールとセットアップで行っているコト。2台目以降のノードで行っているコト
- 初回のノード作成時は、外部共有ディレクトリにアプリケーションデータ領域の作成も行っています。
- またこの時に、起動しているJiraのバージョン番号を記録した、jira-software.versionファイルを /jira/shared/ ディレクトリに保存します。
- 2台目以降はAnsibleでインストールを行う際に、このversionファイルを参照して1台目と同じインストーラをダウンロードします。
- このため、初回起動時に立ち上げるノード数を複数にしてしまうと、共有ディレクトリおよびversionファイルの整合性が取れずに、同じクラスタノードとみなされずにData Centerが正常にセットアップされなくなります。
ノード (EC2)を停止させるとそのインスタンスは削除する
- AWSのコンソールで停止したノード (EC2インスタンス)は、停止を感知すると再利用することなく削除します。
- たとえばminimum nodesに2を指定していて、高負荷によりノード数が3台になり、その後に高負荷が解消されてノード数を2台に戻す場合、停止したノードはそのまま削除されます。
- このため再度、高負荷によってノード数を増やすときには新規にEC2インスタンスを作成します。
- これはAWSのAutoScaling機能によるものです。
ゼロダウンタイムアップグレードにおけるバージョンの指定方法
- ゼロダウンタイムアップグレードは、プラットフォームリリースのアップデート(Jira 7.x.x → Jira 8.x.x といった最初の数字が上がるアップデートのこと)には対応していません。
- アップデートしたいバージョンは、前述のversionファイルを書き換えることで行います。
- このためまずはBastionサーバーからNFSにアクセスできるようにマウントを行います。
- versionファイルを書き終えたら、管理者権限でJiraにログインし管理者画面からアップデートモードにします。
- アップデートモードにしたら、AWSのコンソールからEC2インスタンスを1台ずつ落とします。そうするとAutoScalingによって新しいインスタンスが起動されます。
- 新しく起動したインスタンスは、versionファイルを参照して新しいバージョンでJiraをインストールします。
- インストール・セットアップが完了したら2台目・3台目。。。と同じ様にインスタンスを停止 ⇒ AutoScalingで自動起動させます。
- すべてのアップデートが完了したら、アップデートモードのファイナライズを実行します。
プラットフォームリリースの場合、ゼロダウンタイムアップグレードは利用できない。
- この場合は、新規インストールと同じ手順でバージョンアップを実施するため、CloudFormationを利用します。
- まずは、minimumパラメータとmaximumパラメータを両方とも0に更新して実行します。するとすべてのJiraノードインスタンスが停止 ⇒ 削除 となります。
- 次に、パラメータのversionを更新するバージョンに変え、minimumとmaximumを1にして実行します。
するとインスタンスが1台起動し、新しいバージョンのJiraをインストールしますが、すでに共有ディレクトリが作成されているので新規インストールではなく、アップデートインストールとみなして実行されます。 - これによって1台目のバージョンアップ(というより新規Jiraノード作成)が完了したので、再度minimum と maximumを必要な値にして2台目以降のノードを立ち上げていきます。
Quick Startを使ってみると色々分かってくる
Quick StartのIaCによるコードの設定内容と実行結果を通して、Jira Software Data Centerのアーキテクチャが理解できるようになります。
更にコードを自分流にカスタマイズすることで、より理想的な環境を手に入れることも可能です。
今回はJira Softwareでの紹介でしたが、Quick StartではConfluenceやBitbucketを起動することもできます。これらにも固有の特徴があったり。
Data Centerのインフラストラクチャ―、更にはAWSやAzureの活用やIaCについて理解を深めたいといった場合は、Atlassian Data Center のQuick Startを使ってみるのもよいと思いますので、まずは評価版でお試ししてみてください。
デモやご相談などお気軽にご相談ください。
