よくあるご質問

ロードバランサーは、常に利用可能なアプリケーションサービスを保証するために、複数のバックエンドサーバーに着信するネットワークトラフィックを効果的に分散する役割を担うネットワークアプライアンスです。 ロードバランサーは、ソフトウェアアプライアンス、ハードウェアアプライアンス、あるいはサービスとして導入することができる。 ロードバランサーは、サーバーの利用を最適化し、アプリケーション配信における単一障害点を取り除くことで、以下のことを保証します：

弾力性– ロードバランサーを使えば、同じ役割を果たす複数のアプリケーションサーバーを稼働させることができる。 サーバーに障害が発生した場合、ロードバランサーはこれを検知し、トラフィックを残りのオンラインかつ健全なサーバーにリダイレクトする。 これにより、アプリケーションの高い可用性と信頼性が保証される。

スケーラビリティ– ロードバランサーは、パフォーマンスに影響を与えることなく、サービスをシームレスに拡張することができます。 ロードバランサーの後ろに分散用のサーバーを追加するだけで、負荷の増加に適応する能力を導入できる。

キャパシティ– キャパシティを増やすには、ロードバランサーの後ろにサーバーを追加するだけです。 (データベースや他のアプリサーバーも考慮しなければならないので、通常はそれほど簡単ではありませんが、おわかりになるでしょう）。

ロードバランサは、多くの異なるロードバランシング戦略、またはロードバランシングポリシーと呼ばれるものに基づいて、アプリケーショントラフィックを分散します。 バックエンドサーバーがオンラインかどうか、健全かどうかを把握するために、ロードバランサーはバックエンドサーバーモニタリングとサーバーヘルスチェックを使用する。 ロードバランシングの原理は何年も前から存在しているが、これらのデバイスは基本的なレイヤー4デバイスから、ガートナー社が言うところのADC（Application Delivery Controller）であるレイヤー7のより洗練されたデバイスへと大きく進化している。 ADCは、セキュリティやトラフィック管理など、さらに多くの主要機能を提供する。

ロードバランシング戦略やポリシーは、ロードバランサーに次の着信リクエストをどこに送るかを指示します。 特定のソリューションによって利用可能なロードバランシング戦略は数多くあるが、一般的なものをいくつか以下に挙げる：

ラウンドロビン：最も単純な負荷分散方法で、各サーバーが順番にリクエストを受け取る。

最小接続数：ロードバランサはサーバが持っているコネクション数を記録し、 最もコネクション数の少ないサーバに次のリクエストを送ります。注意: 古い、レイヤ4のみのロードバランサはこれをサポートしない傾向があります。 なぜなら、ロードバランサは通常DSR (Direct Server Return)を実行しており、 バックエンドサーバに現在いくつのコネクションがあるかを知らないからです。

重み付け：通常、あるサーバーが別のサーバーの2倍の能力を持つように、サーバーはパーセンテージで能力が割り当てられる。 重み付け方式は、ロードバランサーがサーバーの実際のパフォーマンスを知らない場合に有効である。

最速のレスポンスタイム：このロードバランシング方式は通常、より高度な製品でのみ利用可能です。 リクエストは最も速く応答するサーバーに送られる。

ロードバランサーはウェブサーバーに対してサーバーの健全性チェックを実行し、サーバーが生きているか、健全か、サービスを提供しているかを判断する。 サーバーの健全性監視は、回復力のあるアプリケーションを提供するための鍵であり、選択したソリューションによっては、問題の検出においてより高度なレイヤー7の健全性チェックを使用できるロードバランサーもある。 以下は、サーバーの健全性チェックのさまざまな方法の概要である。

Ping:これはサーバーの健康状態をチェックする最も簡単な方法ですが、ロードバランサーがサーバーが稼働していると報告しても、ウェブサービスがダウンしている可能性があるため、あまり信頼できません。

TCPコネクト：これは、サービスが稼働しているかどうかをチェックする、より洗練された健全性チェック方法である。 この例としては、ウェブ用のポート80のサービスがある。

単純なHTTP GET：サーバーの健全性をチェックするこの方法は、ウェブ・サーバーにHTTP GETリクエストを行い、通常、200 OKなどのヘッダー・レスポンスをチェックします。

完全なHTTP GET：このサーバー・ヘルス・チェックは、HTTP GETを行い、実際のコンテンツ・ボディをチェックして正しいレスポンスを返します。 この機能は、より高度なロードバランシング・ソリューションの一部でしか利用できないが、実際のアプリケーションが利用可能かどうかをチェックするため、ウェブアプリケーションにとっては優れた方法である。

カスタマイズ可能なサーバーヘルスチェック：ロードバランシング・ソリューションの中には、TCP/IPアプリケーションのカスタム・モニターに対応し、特定のアプリケーション・サービスをよりよくコントロールできるものもある。

永続性は、多くのWebアプリケーションやWebサイトで必要とされる機能です。 一度ユーザーが特定のサーバーとやりとりすると、それ以降のリクエストはすべて同じサーバーに送信されるため、その特定のサーバーに「永続化」される。 セッションの永続性は、サービスの継続性とシームレスなエンドユーザーエクスペリエンスを保証し、セッションの状態が共有データベースとは対照的にローカルWebサーバに保存されるeコマースアプリケーションの要件であることが多い。 粘り強さにはさまざまな形がある。

ロードバランサーのクッキー：ロードバランサはクライアントにクッキーを設定し、このユーザに使われるバックエンドサーバを特定するためにこれを使います。

アプリケーション・セッション・クッキー：多くのアプリケーションサーバーは、jspセッションクッキーやAsp.net.Cookieのような独自のセッションIDをすでに設定しています。 ロードバランサがこれらを使うように設定できます。

IPベース：クライアント IP アドレスを使用します。 この方法はレイヤー4とレイヤー7に有効である。

SSLセッション：SSLセッションIDを使用します。 セッションIDが変更される可能性があり、永続性が失われるので、これはあまり一般的ではありません。

RDPセッションクッキー：RDP接続に使用されます。

これは、高度なロードバランサーを表すのに使われる言葉だ。 現在、ほとんどのロードバランサーはレイヤー7のアプライアンスで、アプリケーションとクライアントの間の特権的な位置にある。 すべてのトラフィックを可視化することで、ロードバランサーは、単純なロードバランシングやサーバーの冗長化以上の多くの機能を実行することができる。 ロードバランシングは、以下のようなADCの機能のひとつである：

• レイヤー7のトラフィック管理
• アプリケーション・アクセラレーション
• コンテンツ・キャッシング
• アプリケーション・ファイアウォール
• 接続のプールと制限
• 事前認証とシングルサインオン
• プロキシ

レイヤー4とレイヤー7という用語は、OSIネットワークモデルの中でロードバランサーが動作するプロトコル層を指す。 レイヤー4のロードバランサーはトランスポートレイヤーで動作し、レイヤー7のロードバランサーはアプリケーションプロトコルレベルで動作する。 これにより、インテリジェントなトラフィック管理、コンテンツ・キャッシング、セキュリティ、圧縮などの高度な機能と最適化機能が可能になります。アクセラレーション機能レイヤー4のロードバランサーはまだ利用可能だが、レイヤー7のアドバンスト・ロードバランサーやADCがより強力で費用対効果が高くなったため、その市場シェアは大幅に減少している。

SSL（Secure Sockets Layer）は、通常プライベート証明書を使用して接続を暗号化するプロセスを表すために使用されます。 HTTPSは、暗号化されたSSL接続を介して実行されるHTTPである。 SSLはCPUに非常に負荷がかかるため、ウェブサーバーの速度と容量を低下させます。 SSLターミネーションをロードバランサーにオフロードすることで、証明書を一元管理することができ、サーバーはSSLの復号化よりもアプリケーションの配信に集中することができます。

WAF（ウェブ・アプリケーション・ファイアウォール）は、アプリケーション・レイヤー（レイヤー7）での脅威を軽減するために特別に設計されたセキュリティ・デバイスである。 具体的には、ウェブ・アプリケーション・ファイアウォールはHTTPとHTTPSプロトコルで動作するように設計されている。 通常、ポートをブロックする標準的なネットワーク・ファイアウォールと連動して動作する。 アプリケーションがパブリック・サービスを提供するためには、特定のポート（典型的なHTTP/HTTPSウェブ・アプリケーションの80や443など）を開いておく必要がある。 ハッカーはこれらのオープンポートを悪用し、新たな保護レイヤーの必要性を露呈させる。 そこで、アプリケーション・ファイアウォールやWAFの出番となる。 ウェブ・アプリケーション・ファイアウォールは、HTTPリクエストとレスポンスを見て、それらが有効かどうかを判断する。 リクエストの中には、あるサイト/ページでは有効でも、別のサイト/ページでは有効でないものもあるため、多くの場合、アプリケーション・ファイアウォールはより多くの設定を必要とするかもしれません。 PCI DSS は、OWASP が公表した脅威トップ 10 に従い、アプリケーション・ファイアウォールがいくつかの標準的な脅威をブロックすることを要求しています。