HAProxyとロードバランシングの概念：基本

はじめに

High Availability Proxy (HAProxy)は、人気のオープンソースのプロキシおよびTCP/HTTP ロードバランサーソリューションであり、Solaris, FreeBSD、およびLinux上で動作させることができます。これは、複数のサーバー間でワークロードをバランスよく分散させることで、サーバー環境の信頼性とパフォーマンスを向上させるために最も一般的に使用されます。この種のツールは、Instagram、GitHub、Twitter、Imgurなどの多くの著名な環境で使用されています。

このガイドでは、HAProxyについて紹介し、ロードバランシングの用語を説明し、サーバー環境のパフォーマンスと信頼性の両方を強化するためにどのように活用できるかの例を示します。

重要なHAProxyの用語

詳細に入る前に、ロードバランシングとプロキシについて、よく知っておくべき重要な用語と概念がいくつかあります。まず、以下のセクションでこれらの概念を確認することから始めましょう。

ACL (アクセス制御リスト)

ロードバランシングにおいて、ACLは、特定の条件をテストし、その結果に基づいてアクションを実行するために使用されます。これにより、バックエンドの接続やパターンマッチングなどの要因に基づいて、トラフィックを最適に転送する機能が提供されます。以下は、使用されているACLの例です。

この場合、ユーザーがリクエストしたパスが/blogで始まる場合、ACLが一致します。たとえば、この一致するリクエストはhttp://yourdomain.com/blog/blog-entry-1を指します。HAProxy構成マニュアルには、ACLの使用方法に関する詳細なガイドが含まれています。

バックエンド

転送されたリクエストは、バックエンドと呼ばれるサーバーのセットによって受信されます。リクエストは、HAProxy構成のbackendセクションで定義されます。最も基本的な用語では、バックエンドは、使用するロードバランスアルゴリズムと、ポートおよびサーバーのリストによって定義できます。バックエンドは、単一のサーバーまたは複数のサーバーで構成できます。バックエンドにサーバーが追加されるにつれて、潜在的な負荷容量が増加し、処理が複数のサーバーに分散されます。一部のバックエンドサーバーがオフラインになった場合、他のサーバーがリクエスト処理を処理するためのバックアップとして機能します。

2つのバックエンドの構成例を見てみましょう。この場合、それらはblog-backendとweb-backendです。それぞれに、ポート80でリッスンする2つのWebサーバーがあります。

balance roundrobinの行は、ロードバランシングアルゴリズムを指定するためのものです。詳細は、後述のロードバランシングのアルゴリズムセクションに記載されています。一方、mode httpはレイヤー7プロキシの使用を設定しています。これについては、ロードバランシングの種類セクションで説明します。また、サーバーのディレクティブの後にあるcheckオプションは、それらの特定のバックエンドサーバーでヘルスチェックがトリガーされることを示しています。

フロントエンド

リクエストがバックエンドにどのように転送されるかの定義は、フロントエンドと呼ばれます。リクエストは、HAProxy構成のfrontendセクションで定義されます。これらは、ACL、ポート、IPアドレスのセット、およびどのACL条件が満たされたかに応じて使用するバックエンドを定義するルール（use_backendルールと呼ばれる）で構成されています。さらに、その他のケースに対応するために、default_backendルールも存在します。次のセクションでは、さまざまなネットワークトラフィックタイプに対してフロントエンドをどのように構成できるかを説明します。

ロードバランシングの種類

ロードバランシングに使用される基本的なコンポーネントが確立されたので、次にロードバランシングの基本的なタイプに進むことができます。

ロードバランシングなし

最も初歩的な形として、ロードバランシングがない状態は以下のように図示できます。

このシナリオでは、ユーザーは yourdomain.com にあるウェブサーバーに直接接続します。ロードバランシングは存在しません。データベースサーバーが1つしかないため、それがオフラインになると、そこにある情報へのアクセスは完全に遮断されます。多くのユーザーが同時に単一のウェブサーバーに接続しようとし、その負荷を処理できない場合、すべての接続が遅くなるか、完全に接続できなくなります。

ロードバランシング（レイヤー4）

複数のサーバーへのネットワークトラフィックを分散する最もシンプルで実用的な方法の1つは、トランスポート層またはレイヤー4のバランシング方法を使用することです。この方法のロードバランシングは、接続するユーザーのIPアドレスが属するIP範囲とポートに基づいてユーザーを誘導します。言い換えれば、もし http://yourdomain.com/anything からリクエストが送信された場合、これらのリクエストを処理するように定義されたバックエンドが最終的にそれらを処理します。ポート80で yourdomain.com へのリクエストを転送します。

レイヤー4ロードバランシングの基本的な構成は次のようになります。

ユーザーがロードバランサーにアクセスすると、そのリクエストはウェブバックエンドサーバーグループに転送されます。設定されたバックエンドサーバーがユーザーのリクエストに直接応答します。ユーザーが不整合なデータに遭遇するのを防ぐため、すべてのウェブバックエンドサーバーは同一のコンテンツを提供する必要があります。上の図のように、両方のウェブサーバーは最終的に同じデータベースサーバーにリンクしています。

ロードバランシング（レイヤー7）

ネットワークトラフィックをロードバランシングするための、もう1つのより複雑な方法があります。それは、レベル7（アプリケーション層）のロードバランシングを使用することです。このアプローチでは、ユーザーのリクエストの内容に応じて、異なるバックエンドサーバーにリクエストを転送できます。この方法により、同じポートとドメインを介して複数のウェブアプリケーションサーバー間でロードバランシングを行うことができます。このレイヤーの詳細については、当社の「The Nitty Gritty of Networking: Learn about Terminology, Interfaces, and Protocols」チュートリアルを参照してください。

次の図は、レイヤー7のロードバランシングを示しています。

この場合、ユーザーが yourdomain.com/blog をリクエストすると、そのリクエストはブログバックエンドに転送されます。これは、ブログアプリケーションの実行専用に割り当てられたバックエンドサーバーセットです。その間、他のリクエストはウェブバックエンドに転送されます。ただし、どちらのバックエンドも最終的には同じデータベースサーバーにアクセスすることになります。

レイヤー7ロードバランシングのフロントエンド設定の小さな例は、以下のようなコマンドになります。これらは、ポート80を介して入ってくるトラフィックを処理するようにhttpフロントエンドを設定します。

ユーザーのリクエストのパスが /blog で始まる場合、acl url_blog path_beg /blog がリクエストに一致します。

use_backend blog backend if url_blog は、ACLを利用してトラフィックを blog-backend にプロキシします。

defaut_backen web_backend は、他のすべてのトラフィック転送を web-backend に転送します。

ロードバランシングのアルゴリズム

ロードバランシングが実行される際、この目的のためにどのバックエンドサーバーが選択されるかを定義するのはロードバランシングアルゴリズムです。HAProxyにはいくつかのアルゴリズムオプションが用意されています。さらに、サーバーに重み（weight）パラメータを割り当てて、他のサーバーと比較してそのサーバーが選択される頻度を調整することも可能です。利用可能なアルゴリズムは多すぎてすべてを説明することはできません。そのため、このガイドでは最も一般的なものだけに焦点を当てます。詳細については、HAProxy Documentation Converter を参照して完全なリストを確認してください。最も一般的に使用されるものは次のとおりです。

• roundrobin: サーバーを順番に選択するデフォルトのアルゴリズム。
• leastconn: 接続数が最も少ないサーバーが自動的に選択されます。ただし、同じバックエンド内のサーバーはラウンドロビン方式でローテーションされる必要があります。
• source: ユーザーリクエストの送信元であるIPアドレスに基づいてサーバーを選択するアルゴリズム。これにより、ユーザーが常に同じサーバーに接続されるようになります。

Sticky Sessions

一部のアプリケーションでは、接続するユーザーが常に同じサーバーにリンクすることが要件となります。「スティッキーセッション」を使用し、バックエンドで appsession パラメータを使用することで、このような永続性を実現できます。

Processing Health Checks

HAProxyは、バックエンドサーバーがリクエストを処理できる能力を判断する方法を必要とします。これは、サーバーがオフラインになった場合にバックエンドから削除する処理に代わるものです。デフォルトの「ヘルスチェック」が実行され、TCP接続の確立を試みます。これは、設定されたIPアドレスとポートをリッスンすることによって行われます。

サーバーのヘルスチェックがパスしない場合、そのサーバーは送信されたリクエストを処理できません。その時点で、サーバーはバックエンドで自動的に無効化され、復旧して正常に稼働する（ヘルシーになる）までトラフィックは転送されなくなります。ただし、特定のケースでは、デフォルトのヘルスチェックによるサーバーの健全性の判断だけでは不十分な場合があります。

Alternate Solutions

特定のニーズに対して、HAProxyは高機能すぎる場合があります。その場合、より効率的である可能性のある優れた代替手段がいくつかあります。

• Nginx: ロードバランシングやプロキシの目的で活用できる、信頼性が高く高速なWebサーバーです。実際、NginxはHAProxyと連携して一般的に使用され、その圧縮機能やキャッシュ機能が活用されます。
• Linux Virtual Servers (LVS): 多くのLinuxシステムに含まれている、シンプルなレイヤー4ロードバランサーです。

High Availability

ここまでは、レイヤー4およびレイヤー7のロードバランシングについて説明してきました。どちらもロードバランサーを利用して、多数 of バックエンドサーバーのうちどれがユーザーのリクエストへの応答を担当するかを決定します。しかし、ロードバランサーの制限を念頭に置いておくことが重要です。すなわち、それが単一障害点（SPOF）であるということです。これは、ロードバランサーがダウンしたり、ユーザーリクエストで過負荷になったりすると、それぞれダウンタイムやリクエスト処理の遅延が発生することを意味します。しかし、HA（高可用性）構成は、単一障害点のないインフラストラクチャを提供します。これにより、システムアーキテクチャのあらゆるレベルに冗長性を導入することで、サーバーの障害によるダウンタイムの発生を防ぎます。ロードバランサーはバックエンドの冗長化を促進するのに役立ちますが、ロードバランサー自体も冗長化する必要があります。

次の図は、高可用性構成の基本的な形態を示しています。

このインフラストラクチャには、静的IPアドレスに紐付けられた複数のロードバランサー（1つがアクティブ、残りがパッシブ）があります。このIPアドレスは、状況に応じて別のサーバーに再マッピングできます。ユーザーリクエストは、外部IPアドレスを経由して、現在アクティブなロードバランサーに到達します。その時点でロードバランサーがオフラインの場合、フェイルセーフメカニズムがその状態を検出し、IPアドレスをパッシブサーバーに再割り当てします。

Conclusion

ロードバランシングの基本的な理解と、HAProxyがシステムのロードバランシングのニーズを満たすいくつかの方法に関する知識は、現在のサーバー環境の信頼性とパフォーマンスの最適化を始めるための強固な基盤となるはずです。また、次のチュートリアル「NginxのHTTPプロキシ、ロードバランシング、バッファリング、およびキャッシュ：概要」を参照して、Nginxのロードバランシング機能について詳しく学ぶことができます。

快適なコンピューティングを！