Jira Data Center の拡張
Jira Data Center はお使いのアプリケーションに高い可用性を提供します。また、ノードを追加することでクラスターを水平方向に拡張し、同時ユーザー数が増加した際にアプリケーションのパフォーマンスを確保することもできます。パフォーマンスは環境に応じて異なりますが、ここでは Atlassian でのテスト デプロイメントで測定した Jira Data Center パフォーマンスの改善について紹介します。ノードをクラスターに追加する際には、ニーズに合わせて Jira Data Center を適切に拡張できるように、実装の詳細について認識しておくことが重要です。この記事では、アプリケーションを拡張する際に考慮すべき事項の概要をいくつか提供します。
追加コンポーネント
Data Center デプロイメントには次を含める必要があります。
Load balancer
ロード バランサは Data Center アプリケーションの主要なコンポーネントであり、アプリケーションの可用性と拡張性の向上を促進します。ロード バランサの最も重要な構成設定は、スティッキー セッションを確実にサポートすることです。ロード バランサの構成に関する詳細は以下から確認できます。
共有データベース
共有データベースを設定する場合、データベースがすべての Jira Data Center ノードの最大接続数に対応可能であることを確認してください。たとえば、Jira Data Center ノードが 3 つあり、それぞれが最大で 80 接続をサポートする場合、共有データベースは 240 接続以上をサポートする必要があります。多くの場合、管理やその他の目的のために、追加接続を構成する必要があります。また、Jira Data Center がサポートしているデータベースをデプロイしていることを確認する必要あります。
共有ストレージ
すべての Data Center デプロイメントにはリモート共有ファイル システムが必要です。一例として、NFS などの、ファイル システム プロトコルを経由したネットワーク接続ストレージがあります。クラスタ内のすべてのノードは、同じパスで共有ディレクトリにアクセスできる必要があります。共有ファイル システムは、プラグイン、Lucene インデックスのコピー、添付ファイル、アバター、および Jira アプリケーションで使用されるその他のデータを保存します。
ノードの通信
各 Jira Data Center ノードは他のノードと通信し、ローカルの Lucene インデックスやローカルのメモリ キャッシュを同期します。たとえば、ユーザーが 1 つの Jira ノードで Jira チケットを更新すると、そのノードはローカル キャッシュと共有データベースの両方で Lucene インデックスを更新してから、他のノードに対し、インデックスを更新したことを伝えます。その後、他のノードはデータベースを確認して、変更後のデータをそれぞれのローカルの Lucene インデックスにコピーします。
Lucene インデックスは除々に統一されます。つまり、すべてのノードのインデックスの更新にはある程度の遅延があります。
さらに、Jira Data Cener 内の各ノードは、特別に設定された Ehcache および RMI を使用して、他のすべてのノードにわたってメモリ キャッシュを複製します。ユーザーとグループの権限は他のデータ アイテムとともに各ノードのメモリ内でキャッシュされます。そのため、グループの権限が変更されると、クラスターはそのクラスター内のすべてのノードでそれを複製します。
ネットワークの遅延
ノードの通信量を考えると、クラスターは高速ネットワークで実行し、低遅延のために可能な限り最適化しておくことをお勧めします。遅延が長くなると、ノードが互いに同期されなくなったり、オンライン/オフラインにが不規則に切り替わったりすることがあります。クラスター ノードを物理的に同じ場所、同じサブネット上に配置するのは、遅延を減らす方法の一つです。
現在、Data Center はジオクラスタリングをサポートしていません。
ノードを追加する
各ノードは互いに通信を行うため、クラスターにノードを追加するとネットワークのトラフィックも増加します。ノード間やデータベース/共有ファイル システムへのトラフィック増加にクラスターが対応できていることを確認するために、ネットワーク監視ツールを使用することが重要です。お使いの環境が問題なく処理できるノードの合計数を把握するために、パフォーマンス テスト ツールを使用して、お使いのアプリケーションでネットワーク監視/パフォーマンス テストを実行します。Atlassian の内部テスターは、Jira Data Center に対して最大 4 つのアプリケーション ノードでテストを実行しました。クラスター内の最大ノード数に到達した場合、既存のノードをアップグレード (垂直方向に拡張) して、容量やパフォーマンスを改善することを検討する必要がある場合があります。
セキュリティ
アプリケーションを保護するために、許可されているノードのみを Jira Data Center の Ehcache RMI のポートに接続するよう、ファイアウォールやネットワーク分離 (またはその両方) を使用します。ファイアウォールを使用する場合、ノードとキャッシュの間のファイアウォールではポートを開く必要があります。これを行わない場合は、キャッシュ複製の問題が発生する場合があります。Jira バージョン 7.3 以降の場合、既定の 2 つの Ehcache RMI ポートは 40001 と 40011 です。Jira バージョン 7.2 以前の場合、既定の 1 つめのポートは 40001 で、2 つ目のポートは広範囲のポートを開く必要がある TCP エフェメラル ポートです。この範囲はオペレーティング システムに固有であり、通常はレジストリ設定 (Windows) またはカーネル パラメーター (UNIX/Linux) で調整可能です。
ノード検出
クラスター ノードが相互に通信するには、互いについて認識させる必要があります。ノードは起動されると、実行中の他のノードの検出を試みます。発見した場合、新しいノードは既存のクラスターに参加しようとします。他のノードが見つからない場合は、独自のクラスターを開始します。Jira Data Center は、2 タイプのノード検出をサポートします。
- データベース検出 (既定)
- マルチキャスト
データベース検出のため、Jira Data Center データベースには、すべてのアクティブ ノードとそれらに割り当てられた IP アドレスを一覧化した clusternode テーブルがあります。各ノードは定期的にチェックインして関連する clusternodeheartbeat テーブルを更新する必要があります。この表の更新が 5 分間行われない場合、そのノードはダウンしているとみなされます。データベース検出は非常に効率が良く、また、マルチキャストの使用では安定性の問題が確認されているため、マルチキャストよりもデータベース検出を使用することを強くお勧めします。また、Jira Data Center を AWS にデプロイする場合、AWS ではマルチキャストがサポートされません。
ノード検出の構成に関する詳細は、Jira Data Center でインストールする際の cluster.properties ファイル パラメーターの構成方法をお読みください。