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

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

テクノロジーの概要

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

Load balancer

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

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

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

リバース プロキシ

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

フォワードプロキシ

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

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

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

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

ラウンドロビン

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

最小接続

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

IP ハッシュ

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

構成

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

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

スティッキーセッション

前述したように、Data Center アプリケーションは、セッションの間、各ユーザーのリクエストが同じノードに送信されることを想定しています。リクエストが別のノードに送信されると、ユーザーが予期せずログアウトされたり、セッション内で保存された情報が失われたりする場合があります。そのため、ロード バランサでは Cookie ベースの「スティッキー セッション」(セッション アフィニティ) を有効にして、セッションを同一ノードにバインドする必要があります。Cookie ベースのスティッキー セッションを使用すると、アトラシアン アプリケーションによって発行された Cookieやロード バランサで生成された Cookie を使用できます。アトラシアンのほとんどのアプリケーションは JSESSIONID Cookie を発行します。ただし、Confluence がクラスター化されている際に JSESSIONID は seraph.confluence によって上書きされて、初期設定で Bitbucket バージョン 5 以降は BITBUCKETSESSIONID を発行します。製品で使用されている Cookie を確認するには、製品のドキュメントをご参照ください。

JSESSIONID と Cookie ベースのスティッキー セッションに関する詳細については、次をご参照ください。 

• Jira Data Center ロード バランサの例
• Confluence Data Center でのクラスタ化

管理アクセス

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

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

ロード バランサは各ノードのステータスを頻繁に監視するように構成し、正常に稼働しているノードにトラフィックを送信するようにする必要があります。ノードのステータスを確認するには、HTTP://<node_IP_address>:<port>/status を確認します。ノードは、HTTP レスポンスと、ノードのステータスを説明する JSON ペイロードで応答します。ロード バランサはライブ トラフィックの送信先を判断するためにいずれかのレスポンスを使用します。たとえば、Confluence でのレスポンス コードは次のようになります。

ノードの削除

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

SSL 終端処理

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

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

• Confluence Data Center 用のロードバランサーの構成
• Hipchat Data Center のネットワーク構成の要件
• Bitbucket Data Center 用のロードバランサーの構成

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

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

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