Traffic distribution with Atlassian Data Center

In this guide, we'll take you through the basics of traffic handling for Atlassian Data Center products.

概要

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

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

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

Data Center supports any software or hardware load balancer and requires "sticky sessions" to be enabled to bind a user to a single node during an entire session. This article assumes you're monitoring your application cluster.

標準トラフィック分散

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

In a basic configuration, each application node redundantly runs a copy of the application. So if you're running Jira Software 7.3.2, each node runs the same copy of Jira Software 7.3.2. Typically, these nodes don't communicate with each other and all data is stored in the shared database and file system connected to each node. The load balancer acts as the single point of entry into the cluster.

ロード バランサの操作

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

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

The process by which the load balancer selects the target application node is dependent on the algorithm that you decide to use based on the needs of your environment. Algorithms for selecting nodes include, but aren't limited to, round-robin polling, nodes with fewer connections, and nodes with lower CPU utilization. By efficiently balancing traffic across your cluster, the load balancer increases your application's capacity for concurrent users while maintaining its stability.

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

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

Atlassian doesn't recommend any particular load balancer or balancing algorithm, and you're free to choose whichever software or hardware solution best fits your environment. The only configuration requirement for Data Center applications is for sticky sessions, or session affinity, to be enabled on your load balancer. It guarantees that user requests and activities are bound to the same node during a session. In the event of a node failure and failover, users may have to log in to the application again.

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

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

ロード バランサの標準オペレーションは同時容量の増加に役立ちますが、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 を試す