Jira Data Center をクラスタで実行する
Jira Data Center では複数の Jira ノードのクラスタを実行して、高可用性、拡張のためのキャパシティ、および大規模環境でのパフォーマンスを実現できます。このガイドでは、クラスタ化のメリットについて説明し、クラスタ化された環境で Jira を実行するために必要な情報の概要を提供します。
準備はよろしいですか? 「Jira Data Center クラスタのセットアップ」をご覧ください。
クラスタ化のメリット
クラスタリングは、連続アップタイム、すぐに利用できる拡張性、および高負荷下でのパフォーマンスを必要とする、大規模およびミッションクリティカルな Data Center デプロイメントを使用しているエンタープライズ向けに設計されています。
メリットの一部をご紹介します。
- 高可用性とフェイルオーバー
クラスタのいずれかのノードがダウンした場合、他のノードが負荷を引き受け、ユーザーは中断されることなく Jira にアクセスできます。 - 大規模環境でのパフォーマンス
クラスタにノードを追加すると、許容される同時ユーザー接続数が増え、ユーザーのアクティビティが増えた場合の応答時間が改善されます。 - 即時に拡張可能
ダウンタイムや追加のライセンス料金なしでクラスタに新しいノードを追加できます。インデックスとアプリは自動的に同期されます。
アーキテクチャ
次の画像は、一般的な構成を示しています。
Jira Data Center クラスタは以下で構成されます。
JIra Data Center を実行する複数の同一のアプリケーション ノード。
トラフィックをすべてのアプリケーション ノードに分散するロード バランサ。
添付ファイルやその他の共有ファイルを保存する共有ファイル システム。
すべてのノードが読み取るおよび書き込むデータベース
すべてのアプリケーション ノードがアクティブ状態にあり、リクエストを処理します。ユーザーは、セッションのタイム アウト、ログアウト、またはクラスタからノードが削除されるまで、すべてのリクエストで同じ Jira ノードにアクセスします。
詳細
インフラストラクチャと要件
ハードウェアやインフラの選択はあなた次第です。以下はハードウェアおよびインフラストラクチャ要件を計画するときに考える必要がある領域です。
Kubernetes で Jira Data Center を実行する
Kubernetes で Jira Data Center で実行する予定がある場合は、Helm チャートをご利用ください。詳細については「Kubernetes クラスタで Jira Data Center を実行する」をご確認ください。
AWS および Azure に Jira Data Center をデプロイする
AWS または Azure で Jira Data Center を実行する予定がある場合、アトラシアンのテンプレートを使用してインフラストラクチャ全体をデプロイできます。Jira Data Center ノード、データベース、およびストレージのすべてが数分で構成され、使用できるようになります。詳しくは、次のリソースをご覧ください。
サーバー要件
Jira と同じサーバーで他のアプリケーション (コア オペレーティング システム サービスを除く) を実行しないでください。アトラシアン ソフトウェアの専用サーバーでの Jira、Confluence、および Bamboo の実行は、小規模なインストールではうまく動作しますが、大規模に実行する場合はうまくいきません。
Jira Data Center は仮想マシンで正常に実行できます。
クラスタ ノードの要件
各ノードはまったく同じである必要はありませんが、一貫性のあるパフォーマンスのために、可能な限り同質になるようにします。すべてのクラスタ ノードは以下を満たす必要があります。
- 同じデータ センターまたはリージョン内にあること (AWS と Azure の場合)
- 同じ Jira バージョンを実行していること
- 同じ OS、Java、およびアプリケーション サーバー バージョン
- 同じメモリ設定（JVM と物理メモリの両方）（推奨）
- 同じタイムゾーンで設定されている（および現在の同期された時間を維持する）。これを保証するには ntpd または同様なサービスを使用することをお勧めします。
クラスタで発生するさまざまな問題を回避するため、ノードのクロックが正常であることを確認する必要があります。
いくつのノードが必要ですか?
Data Center ライセンスでは、クラスタのノード数は制限されません。ノードの適切な数は、Jira インスタンスのサイズや特徴、およびノードのサイズによって異なります。インスタンスのサイズの検討については、「Jira Data Center のサイズ プロファイル」を参照してください。小さく開始し、必要に応じて拡張することをおすすめします。
メモリ要件
各 Jira ノードの RAM は、最小 8 GB にすることをおすすめします。これは、少数のプロジェクト (最大 100)、1,000 ～ 5,000 件の課題、約 100 ~ 200 ユーザーを持つ単一の Server インスタンスに十分です。
自身の Jira インスタンスの大きさと複雑さを判断するには、「Jira Data Center のサイズ プロファイル」を参照してください。
Jira アプリケーションの最大ヒープ (-Xmx) は、setenv.sh または setenv.bat ファイルで設定されます。Data Center の場合、既定値を増やす必要があります。最小ヒープ (Xms) と最大 (Xmx) ヒープを同じ値に維持することをおすすめします。
また、アトラシアンの公開 Jira Data Center インスタンスの詳細を確認することもできます。「Jira Data Center のサンプル デプロイメント」を参照してください。
データベース
使用する予定のデータベースが現在のサポート対象プラットフォームの一覧に記載されていることを確認する必要があります。平均的なクラスタ ソリューションの負荷はスタンドアロン インストールよりも高くなるため、サポート対象のデータベースを使用することは非常に重要です。
サポート対象のデータベース ドライバを使用する必要もあります。これらのドライバは、上述のサポート対象プラットフォームに記載されています。Jira をデータベースに接続する方法の詳細な手順については、「Jira アプリケーションのデータベースへの接続」を参照してください。
データベースの高可用性のための追加要件
Jira Data Center をクラスタで実行する場合、アプリケーション サーバーは単一障害点になりません。これは、サポートされている次の構成を使用して、データベースでも実現できます。
Amazon RDS Multi-AZ: このデータベース セットアップは、別のアベイラビリティ ゾーンのスタンバイにレプリケートするプライマリ データベースを備えています。プライマリが停止した場合、スタンバイが代わりになります。
Amazon PostgreSQL 互換 Aurora: 1 つ以上のリーダー (別のアベイラビリティ ゾーンを推奨) にレプリケートするデータベース ノードを備えたクラスタです。ライターが停止した場合、Aurora はライターの 1 つをプロモートして代わりにします。
AWS クイック スタート デプロイ オプションを使用するといずれかの方法で Jira Data Center を最初からデプロイできます。既存の Jira Data Center インスタンスで Amazon Aurora クラスタをセットアップする場合、｢Amazon Aurora を使用するために Jira Data Center を構成する｣をご参照ください。
共有ホームおよびストレージの要件
すべての Jira クラスタは同じパスで共有ディレクトリへのアクセス権限を持っている必要があります。NFS および SMB/CIFS 共有が共有ディレクトリの場所としてサポートされています。このディレクトリには大量のデータ (添付ファイルやバックアップを含む) が格納されるため、十分なサイズを用意し、必要に応じて利用可能なディスク領域を増やす方法を計画しておく必要があります。
ロード バランサ
もっとも慣れ親しんだロード バランサを使用することをおすすめします。ロード バランサは "セッション アフィニティ" をサポートしている必要があります。AWS でデプロイしている場合、Application Load Balancer (ALB) を使用する必要があります。
ロードバランサを設定するときの推奨事項は、次のとおりです。
キューは、ロード バランサでリクエストします。ノードに渡されるリクエストの最大数が、Tomcat が受け入れ可能な HTTP スレッドの合計数を超えないようにします。これにより、処理可能な量を超えたリクエストがノードに転送されるのを避けることができます。<install-directory>/conf/server.xml の maxThreads をご確認ください。
非常に迅速に、すべてのノード間での問題を伝播できるため、他のノードに失敗した、べき等の要求を再生しないでください。
最小接続 の使用で、ラウンドロビンとしてではなく、 負荷バランスを行う方法はノードがクラスタに参加または削除された後に再結合する際に、よりよい負荷のバランスをとることができます。
多くのロード バランサでは、プールから URL を自動的に削除するために、バックエンドの正常性を常に確認するための URL が必要です。これには、安定していて高速であるが、不要なリソースを消費しない程度に軽量な URL を使用することが重要です。次の URL は Jira のステータスを返し、この目的に使用することができます。
| URL | 期待される内容 | 予想 HTTP ステータス |
|---|---|---|
http://<jiraurl>/status | {"state":"RUNNING"} | 200 OK |
ノードが長いGCの一時停止などの小さな問題を、生き残ることができるよう監視を設定するときは、いくつかの推奨事項は、以下のとおりです。
- ノードを削除する前に2回連続して失敗を待ちます。
- ノードへの既存の接続の終了を 30 秒程度許可してから、ノードをプールから削除します。
詳細については、「ロード バランサの構成オプション」よび「ロード バランサの例」を参照してください。
ネットワークアダプタ
サーバー間の通信に個別のネットワーク アダプタを使用します。クラスタ ノードはサーバー間通信用の個別の物理ネットワーク（個別の NIC など）を持っている必要があります。これはクラスタの実行を高速および信頼性を高くするのに最適な方法です。その他のデータ ストリーミングを多数持つネットワークを介してクラスタ ノードに接続する場合、パフォーマンスの問題が発生する可能性があります。
アプリの互換性
Jira クラスタにおける Marketplace アプリ (アドオン、プラグイン) のインストール プロセスは、Jira のスタンドアロン インスタンスと同じです。アプリのインストールまたは更新の際に、クラスタを停止したり、ノードをダウンさせたりする必要はありません。
Atlassian Marketplace では、アプリが Jira Data Center との互換性を持っているかどうかを確認できます。Data Center 認証アプリの詳細をご覧ください。
準備はよろしいですか?
クラスタを有効化および構成するためのステップ バイ ステップ ガイドについては、「Jira Data Center クラスタのセットアップ」をご参照ください。