ロードバランサーの構成オプション

ロードバランシングは Data Center アプリケーションの主要コンポーネントであり、アプリケーションの可用性と拡張性の向上を促進します。Data Center にはロードバランシングソリューションは含まれていないため、環境に最適なソリューションを選択して構成する必要があります。この記事では、Data Center アプリケーション用にロードバランサーを使用する場合のオプションについて説明します。

テクノロジーの概要

ロードバランサーとプロキシサーバーの違いはわかりにくいため、ここで各テクノロジーについて簡単に説明します。 

ロードバランサー

ロードバランサーは受信したユーザーリクエストをクラスター全体に分散し、応答時間を最小限に抑えて、単一のノードが過負荷にならないようにします。また、選択したサーバーからユーザーに応答を返します。Data Center アプリケーション用のロードバランサーは次の 3 つの重要な役割を担います。

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

トラフィックのタイプに基づいてトラフィックを分散する場合のロードバランサーの使用方法については、「Atlassian Data Center によるトラフィック分散」を参照してください。

リバース プロキシ

リバースプロキシは、外部ネットワークからバックエンドサーバーへの直接アクセスを防ぐための中継サーバーです。ユーザーリクエストを受け付けて、処理を担当するアプリケーションサーバーに転送し、サーバーからの応答をユーザーに返します。リバースプロキシはキャッシュ機能も備えているため、サーバーからの共通の応答や重複する応答を自動的に返すことによってパフォーマンスを潜在的に向上させることができます。

1 つのコンポーネント (Nginx など) でロードバランサーとリバースプロキシの両方の機能を実行することも、機能ごとに異なるコンポーネントを使用することも可能です (リバースプロキシとして Nginx を使用し、ロードバランサーとして HAProxy を使用するなど)。環境に最適な構成を判断するためには、製品のドキュメントを参照する必要があります。

フォワードプロキシ

フォワードプロキシ (送信プロキシとも呼ばれる) を使用すると、内部ネットワーク上のサーバーからネットワーク外部で稼働している公開ホストサーバーにアクセスできます。たとえば、アトラシアンのアプリケーションからフォワードプロキシ経由で Atlassian Marketplace にアクセスすることができます。

バランシングアルゴリズム

ロードバランサーは、選択または設定したアルゴリズムに基づいて、クラスター内の特定のノードにトラフィックを分散します。Data Center アプリケーションでは特定のタイプのバランシングアルゴリズムは必要ありませんが、以下で説明するようにスティッキーセッションを使用します。これは、新しいユーザーセッションが開始された後、そのセッション内の後続の各リクエストが Data Center クラスター内の同じノードに送信されることを意味します。アプリケーションを本番環境にデプロイする前にテストを実施して、選択したアルゴリズムが環境内で期待どおりに動作することを確認する必要があります。

ここでは、一般的な 3 つのロードバランシングアルゴリズムを紹介します。

ラウンドロビン

ロードバランサーは、リクエストごとに新しいセッションをクラスター内の次のノードに順番に送信します。前のリクエストがノード 1 に送信された場合、次のリクエストはノード 2 に送信されます。ロードバランサーがクラスター内のすべてのノードに新しいセッションを送信すると、その後は再びノード 1 に送信します。ラウンドロビンは最も広く使用されているバランシングアルゴリズムで、簡単に実装することができます。

最小接続

ロードバランサーは、既存の接続の数が最小のクラスター内のノードに新しいセッションを送信します。このアルゴリズムでは、新しいノードをクラスターに追加する際の負荷のバランスを適切にとることができますが、新しいノードがすぐに過負荷にならないように対策を講じる必要があります。

IP ハッシュ

ロードバランサーはクライアントの IP アドレスに基づいてハッシュ値を計算し、そのハッシュ値を使用してノードを新しいセッションに割り当てます。このアルゴリズムでは、同じ IP アドレスから送信されたリクエストが同じノードに送信されます (ただし、そのノードが使用できる場合に限ります)。

設定

ロードバランサーのタイプ

Data Center はハードウェアベースとソフトウェアベースの両方のロードバランサーをサポートしています。ソフトウェアロードバランサーは専用のマシンで実行する必要があります。ソフトウェアとハードウェアのどちらのソリューションでも、高速 LAN 接続を使用してロードバランサーをアプリケーションクラスターに接続し、広帯域幅と低レイテンシを確保する必要があります。

人気のあるソフトウェア ロードバランサーの例として、HAProxy、Apache、および Nginx などがあります。

人気のあるハードウェアロードバランサーベンダーの例として、F5、Citrix、Cisco、VMware、Brocade などがあります。


スティッキーセッション

As mentioned above, Data Center applications assume that each user's request will go to the same node during a session. If requests go to different nodes, users may be unexpectedly logged out and may lose information stored in their session. Therefore, it is required to bind a session to the same node by enabling cookie-based "sticky sessions" (or session affinity) on the load balancer. When using cookie-based sticky sessions, you can use the cookie issued by the Atlassian application, or you can use a cookie generated by the load balancer. Most Atlassian applications issue the JSESSIONID cookie. Bitbucket versions 5 and later issue BITBUCKETSESSIONID by default. Check the product documentation to verify which cookie the product uses.

JSESSIONID と cookie ベースのスティッキー セッションの詳細については、Jira Data Center のロード バランサの例を参照してください。 

管理アクセス

ロードバランサーの構成方法にかかわらず、バックグラウンドで各ノードに管理アクセスできるようにする必要があります。管理アクセスの主な用途は保守です。たとえば、ノードで Jira のインデックスを再構築する必要がある場合、ノードに直接アクセスしてクラスターからインデックスを取得し、プロセスの完了後にクラスターに追加し直すことが必要になる場合があります。

ヘルスチェックのステータス

The load balancer should be configured to frequently monitor the status of each node, and ensure that it is sending traffic to normally operating nodes. You can find out the node's status by checking HTTP://<node_IP_address>:<port>/status. The node will respond with an HTTP response and a JSON payload describing the state of the node. The load balancer can use either response to determine where to send live traffic. For example, response codes for Confluence are:

HTTP レスポンス JSON レスポンス 操作
200 {"state":"RUNNING"} ノードが正常に稼働しています。ライブトラフィックを送信できます。
503

{"state":"STARTING"}

ノードが起動中です。ライブトラフィックを送信しないでください。
503

{"state":"STOPPING"}

ノードが停止中です。ライブトラフィックを送信しないでください。
500 {"state":"ERROR"} ノードがエラー状態になっています。ライブトラフィックを送信しないでください。
200 {"state":"FIRST_RUN"} ノードを初めて設定しています。ライブトラフィックを送信しないでください。

7.2.9 以前のバージョンの Jira を搭載した AWS Elastic ロードバランサーでは、エラーが発生していない場合は必ず HTTP レスポンス 200 を返します。また、AWS Elastic ロードバランサーは HTTP レスポンスのみをチェックします。そのため、カスタムのヘルスチェックスクリプトを使用する必要があります。

ノードの削除

ロードバランサーは、保守の目的でノードを削除する場合、それらのノードを "正常に" シャットダウンできる必要があります。このように設定することで、ロードバランサーがノードに新しい接続を送信しないようにすることができます。ただし、現在の接続は自動終了するまでアクティブなままになります。たとえば HAProxy では、ノードが "ドレイン" モードに設定されているか、または重みが 0 に設定されている場合、このようにすることができます。すべてのセッションが終了すると、ノードをクラスターから削除できるようになります。ノードを急に削除すると、クラスターでトランザクションがドロップされる可能性があるため、ユーザー接続に関する問題が発生することがあります。この機能の設定方法の詳細については、ロードバランサーのガイドを確認してください。

SSL 終端処理

ユーザーが HTTPS でアプリケーションにアクセスし、アプリケーションがセキュアなネットワーク上で実行されている場合、ロードバランサー (リバースプロキシを使用している場合はリバースプロキシ) で SSL (または TLS) を終端することをお勧めしますSSL 復号化/暗号化は CPU を大量に消費するプロセスです。この機能をロードバランサーにオフロードすることで、アプリケーションノードの通常の処理を行うためのリソースを増やすことができます。この構成では、ポート 443 (HTTPS) をアプリケーションの HTTP ポートに転送するようにロードバランサーを構成する必要もあります。正しいポート番号については、各アプリケーションの製品ドキュメントを確認してください。



ロードバランサーの構成に関するその他の情報 (SSL 終端処理の要件など) については、次のリンクを参照してください。

高可用性ロードバランサー

ロードバランサーが環境内で単一障害点にならないようにするには、ロードバランシングソリューションに冗長性を加えます。そのためには、アクティブ/パッシブ構成内に 2 つのロードバランサーを設定します (両方のロードバランサーで 1 つの仮想 IP アドレスを使用)。アクティブ側のロードバランサーで障害が発生すると、パッシブ側のロードバランサーにフェイルオーバーします。Keepalived は、高可用性ロードバランシングソリューションの作成に使用される一般的なツールです。

詳細については、次の HAProxy と Keepalived の構成例を参照してください。



最終更新日 2019 年 1 月 24 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.