Atlassian Data Center を使用したトラフィック分布

このガイドでは、Atlassian Data Center 製品のトラフィック処理の基本について説明します。

概要

Data Center を使用してデプロイするロード バランサは、クラスタ全体でトラフィックを管理し、利用率の増加に伴ってアプリケーションの安定性と最適なユーザー体験を確保するための重要なコンポーネントです。ロード バランシングには 3 つの機能があります。

• 複数のノード間でトラフィックを効率的に分散する
• オンラインとなっているノードにのみトラフィックを送信することで、高可用性を確保 (ヘルス チェックの監視が必要)
• 需要に基づいてノードの追加または削除を促す

この記事では 1 つ目のポイントに焦点を当て、標準トラフィック分散屋より高度なトラフィック シェーピングにロード バランサを使用することが、アプリケーションのパフォーマンス管理にどのように役立つかについて説明します。

Data Center はあらゆるソフトウェアやハードウェアのロード バランサーをサポートしており、セッションの最初から最後までユーザーを 1 つのノードにバインドするためには、「スティッキー セッション」を有効にする必要があります。この記事では、アプリ クラスターを監視しているユーザーを想定しています。

標準トラフィック分散

Data Center を使用してデプロイすると、アプリケーションはロードバランサに接続された 2 つ以上のノード、共有データベース、および共有ファイル システムで構成されるクラスタ構成を実行します。

基本構成で、各アプリ ノードはアプリのコピーを冗長的に実行します。そのため、Jira Software 7.3.2 を実行している場合、各ノードは Jira Software 7.3.2 の同じコピーを実行します。一般的に、これらのノードは互いに通信せず、すべてのデータは各ノードに接続されている共有データベースとファイル システムに保存されます。ロード バランサーはクラスター内への単一エントリとして機能します。

ロード バランサの操作

基本的な構成では、ロード バランサはクラスタ ノード全体にトラフィックを分散させ、応答時間を最小限に抑え、1 つのノードの過負荷を防ぎます。一般的なプロセスは次のとおりです:

1. ユーザーのクライアントが、ロード バランサ経由でアプリケーション クラスタへの接続を試みます。
2. 接続を承諾した後、ロード バランサは最適な宛先アプリケーション ノードを選択し、接続をルーティングします。
3. アプリケーション ノードは接続を承認し、ロード バランサ経由でクライアントへ応答します。
4. クライアントは、アプリケーション ノードから応答を受信し、ロード バランサーのスティッキー セッションの構成を経由し、同じノードを使用してすべての要求とアクティビティを続行します。

ロード バランサーがターゲット アプリ ノードを選択するプロセスは、環境のニーズに基づいて使用を決定したアルゴリズムに依存します。ノード選択のアルゴリズムには、ラウンド ロビン ポーリング、接続の少ないノード、CPU 使用率が低いノードなどが含まれますが、これらに制限されません。ロード バランサーはクラスター全体で効果的にトラフィックのバランスをとることで、安定性を維持したまま同時ユーザーに対するアプリの容量を増やします。

ノードの数が増えると、同時使用容量も増加します。例えば、当社の社内負荷テストでは、2 ノードおよび 4 ノード クラスターを使用するでは、同じ応答時間の単一 Jira Software サーバーと比較して同時ユーザーの容量がほぼ直線的に増加することを示しています。

セットアップとスティッキー セッション

アトラシアンでは、特定のロード バランサーやバランシング アルゴリズムを推奨していません。ユーザーは、自分たちの環境に最適なソフトウェアまたはハードウェア ソリューションを自由に選ぶことができます。Data Center アプリの唯一の構成要件は、ロード バランサーでスティッキー セッション (すなわちセッション アフィニティ) が有効化されていることです。これにより、ユーザー リクエストとアクティビティが、セッション中に同じノードにバインドされます。ノード エラーやフェイルオーバーが発生した場合、ユーザーはアプリに再度ログインする必要が出る場合があります。

この記事の最後に、ロード バランシング設定に関する製品固有の提案が記載されています。

トラフィック シェーピング

ロード バランサの標準オペレーションは同時容量の増加に役立ちますが、Data Center ロード バランサを使用すると、トラフィック シェーピングを使用してさらにきめ細かくコントロールすることができます。トラフィック シェーピングを使用すると、特定のタイプのトラフィックを分類して優先順位を付、そのトラフィックをクラスタ内の特定のノードにリダイレクトすることができます。

たとえば、4 ノードのクラスタでトラフィック シェーピングを実現するために、4 番目のノードを特定のタイプのトラフィックの受信専用とし、そのタイプのすべてのトラフィックを 4 番目のノードのみに送信するようロード バランサを構成することができます。ロード バランサは、上記のように、残りのトラフィックをそれ以外の 3 つのノードに分散させます。お客様は、API コールを 1 つのノードに区切り、特定のチームからのトラフィックを特定のノードにダイレクトするなど、さまざまな方法で Data Center を使用してトラフィック シェーピングを行っています。

REST API トラフィック

お客様の間で最近人気が上昇しているトラフィック シェーピング手法は、外部 REST API トラフィックを専用ノードまたはノード セットに送る方法です。

アプリケーションの使用率が増加すると、アプリケーション REST API を使用して独自のサービスを構築するユーザーが増える場合があります。彼らは、定期的にレポートを自動取得するなど、必要なタスクを達成するために、計算集約型のサービスを作成する場合があります。膨大な数になる可能性があるこれらの外部サービスにより、特に、Jira Software チケットの申請や更新など、ユーザーが標準の操作を行う際に、アプリケーションの応答性が低下することがあります。

ユーザーがこの動作を実行しないようブロックするか、それらを受け入れる方法を見つけることを選択できます。後者のシナリオでは、必要な手順を実行して、専用ノードを参照するサービスを開発または再開発することをユーザーに依存するのは困難な場合があります。したがってよりよい解決策は、トラフィック シェーピングを行うようロード バランサーを設定することです。

トラフィック シェーピングを活用するため、外部 REST API トラフィックをすべて特定し、特定されたトラフィックを REST API トラフィックのみを処理する専用ノード (またはノードのセット) に送信するようロード バランサを構成することになります。これによって、クラスタ内の他のアプリケーション ノードが標準ユーザー リクエストにのみ対応し、他のサービスによって低下しないようにします。

現在アトラシアンでは、Jira Software でトラフィック シェーピング テクニックのテストを実施していますが、Bitbucket などの REST コールを使用してアトラシアン アプリケーションに適用できる可能性があります。

構成

まだない場合は、最初に、すべての外部 REST API トラフックを処理する専用ノードを、クラスタ内でプロビジョニングする必要があります。ロード バランサがシェーピングを行うため、ノードで特別な操作を行う必要はありません。

REST API トラフィックを専用ノードへ送信するようロード バランサを構成する際には、外部 REST API トラフィックのみを識別することが重要です。例えば、Jira Software がソフトウェア内で多数の REST コールを使用している場合、すべての REST API トラフィックを識別してリダイレクトすると、アプリケーションの標準の操作が妨げられます。が

さらに、ログイン ページにアクセスする REST API トラフィックは、リダイレクトの対象外にする必要があります。そうでなければ、専用ノード上のユーザー セッションが発生し、次の応答が他のノードへ送られ、ユーザーが最初のセッションを実行できなくなってしまします。REST API トラフィックをリダイレクトする前に、参照元と要求されたパスをチェックする必要があります。

次の条件を満たす REST API トラフィックのみを送るよう、ロード バランサを設定します。

• アプリケーションから外部参照される
• ログイン ページを要求しない

4 ノード クラスタ設定の場合、構成は次のようになります。

If referrer == app.yourdomain.com and the request ~ /rest:
    Direct traffic to Node 1 or Node 2 or Node 3 //normal traffic

If referrer != app.yourdomain.com and the request ~ /rest:
    If the page requested == /login.jsp:
        Direct traffic to Node 1 or Node 2 or Node 3 //normal traffic
    Else:
        Direct to Node 4 //external REST API traffic

トラフィックを形成する構成を適用するには、ロード バランサを再起動する必要があります。期待どおり作動していることを確認するよう、構成をテストします。

結果

あるお客様が Jira Software Data Center で最近、トラフィック シェーピングを実装しました。

• トラフィック量は、アプリケーション ノードよりも REST API ノードの方が 4 倍も多くなりました。
• 彼らのアプリケーション ノードは単一インスタンスの Jira デプロイメントに対して、CPU 利用率が減少しました。

関連リンク

ロード バランサのセットアップ

• Confluence Data Center ロード バランサ構成の提案
• Jira Data Center ロード バランサの例
• NGINX Plus ロード バランサを使用した Jira Data Center 
• Bitbucket Data Center ロード バランサのセットアップ

顧客事例

• Jira Software を 10,000+ ユーザーに拡張する方法

その他

• いますぐ Data Center を試す