【図解】ロードバランサ(L7)の仕組み~セッション維持方式、SSL証明書やリバースプロキシ等の構成例~

スポンサーリンク
スポンサーリンク

ロードバランサとは

ロードバランサとは、サーバの負荷分散を行いつつ、冗長化を実現するアプライアンス機器です。http(s)サーバを負荷分散するイメージが強いですが、DNSやIMAP、RDP(リモートデスクトップ)等の様々なプロトコルに対応しているものが多いです。また、サーバの信頼性を上げる機器でもありますので、大抵、このロードバランサ自体もVRRPのような自動切り替わり可能な冗長化機能を持っています。

仕組みとしては、ロードバランサ上の1つのVIP(Virtual IP: 仮想IPアドレス)に、負荷分散させたいサーバ群の実IPアドレスたちを紐付けます。そして、VIPへのアクセスがあった際に、設定された負荷分散ルール(負荷分散方式、および、パーシステンス方式)を元に、実IPアドレスに変換させます。この動作は、実質リバースプロキシと同じ動作になるため、ロードバランサをリバースプロキシとして構成することも稀にあります。(Windowsサーバを直接DMZに晒したくない時等)

スポンサーリンク

補足ですが、L4レベル(TCP/UDP送信元宛先ポート)の情報を使ってNextHopを決める機器L4スイッチhttpやRDP等のアプリケーションの中身を見てNextHopを決める機器L7スイッチと呼びます。なのでロードバランサのことをL7スイッチと呼ぶこともあります

製品の種類

製品としてはCitrixのNetscaler、F5のBIG-IP等が有名です。安価なものだと、セイコーソリューションズのNetwiserが挙がります。

また、Windowsサーバの場合はハードウェアを追加購入しなくても、NLB(Network Load Balancing)という機能が無料で使えます。

負荷分散方式

負荷分散方式の代表的な例を以下に挙げます。

  1. ラウンドロビン・・・最初に来た通信をWebサーバ#1へ、次に来た通信をWebサーバ#2へ、と順番に割り当てていく
  2. 最小レスポンス時間・・・死活監視を行った際のレスポンス時間が一番短いサーバを使う
  3. 最小コネクション数・・・一番接続数の少ないサーバを使う
  4. 最小利用帯域・・・一番トラフィック流量の少ないサーバを使う

パーシステンス方式

ロードバランサは通信を割り振りますが、サーバ間の同期までは面倒を見てくれません。また、サーバ側も『1つのWebサーバでのセッション情報を他のサーバに同期する』ということは出来ません。なので、ロードバランサ側で、『あるユーザが色々なWebサーバを行ったり来たりせず、1台のWebサーバを見続けさせる機能』を用意しています。それが、パーシステンス機能です。

スポンサーリンク

パーシステンス方式の代表的な例を以下に示します。

  1. クッキー・・・httpのクッキー情報をロードバランサが挿入し、ユーザを識別する。同じクッキを持つ通信は必ず同じWebサーバを使わせる
  2. 資格情報・・・RDPのユーザID情報を識別する。同じユーザ情報わ持つ通信は必ず同じTerminal Server(TS)を使わせる
  3. 送信元IP・・・同一IPの通信を同一ユーザと見なす。同じ送信元IPの通信は必ず同じサーバを使わせる

ロードバランサでのhttps通信対応(TLS/SSL暗号化および復号化)

https等の暗号化された通信でも、このL7のスイッチングを実現したい、という需要が多くあります。これを実現するためには、暗号化されているhttps通信等を復号化させてhttpの中身を見る必要があります。その関係で、ロードバランサにはSSLアクセラレータ(通常CPUに処理させるTLS暗号化・復号化を、専用ASICによりハードウェア処理させる)機能を持っていることが多いです。

実装としては、本来サーバに配置すべきデジタル証明書および秘密鍵をロードバランサに配置し、PCとロードバランサ間は、そのデジタル証明書および秘密鍵を使ってhttps通信を行い、ロードバランサはそれをhttpに復号化し、httpのクッキー情報を挿入・閲覧し、クッキーに応じたWebサーバへhttp通信を送ります。

スポンサーリンク

ロードバランサとWebサーバの間はセキュリティが下がりますが、2つの機器の間が距離的に近くにあり、その間であれば盗聴(パケットキャプチャ)はされない、という前提であれば問題はありません。

ですので、Webサーバにはデジタル証明書を配置する必要はありません。ただ、有っても害は無いので、デジタル証明書のライセンス的に問題ないのであれば(昔は配置する機器1台につき1ライセンスでしたが、最近は同じ証明書であればOKのものも多い)配置しておいたほうが万が一の対応としてロードバランサを経由させず直接Webサーバにhttps通信させることができるので良いかもしれません。

ロードバランサの通信イメージ

ロードバランサの通信イメージを以下に示します。

スポンサーリンク

ロードバランサとDNSラウンドロビンの決定的な違い 〜負荷分散と冗長化はイコールではない〜

冒頭で、『負荷分散と冗長化を実現する』と書きました。もしかしたら「負荷分散出来ているなら、冗長化は自然と出来ているでしょ」と思ったかもしれませんが、厳密には異なります。その一番分かり易い例は、DNSラウンドロビンです。これは負荷分散は出来ますが、冗長化は出来ませんDNSラウンドロビンでは、ロードバランサと違い、死活監視を行わないためです。

スポンサーリンク

ロードバランサの構成パターン

ロードバランサの構成パターンは大きく分けて2つあります。

1つが Destination-NAT(DstNAT)構成、もう1つが Source & Destination NAT(Src&DstNAT)構成です。

DstNAT構成

VIPをサーバの実IPにDstNAT変換します。

この構成のメリットは、送信元IPが変換されないため、サーバ側で送信元IPのログが残せることです。

一方、デメリットは、戻りの通信がロードバランサを経由するようにしっかりと設計する必要がある点です。

構成例として一番素直なのは2アーム構成と呼ばれ(インライン方式とも呼ばれます)、ロードバランサの背後にサーバ専用のセグメントを作ることです。ロードバランサから2本の足(アームだから腕?!)が出ます。

また、ちょっとトリッキーな構成にはなりますが、Linuxサーバであれば、IPROUTE2によるPBRを行うことで、ロードバランスするプロトコルだけNextHopをロードバランサに向ける、というやり方もあります。この構成は1アーム構成と呼ばれます。

スポンサーリンク

また、このIPROUTE2を使った実装ではさらにトリッキーな構成として、ロードバランサのVIPでもWebサーバの実IPでも両方https通信できる状態にすることができます。

これにより、高価なロードバランサの購入を1台に抑えつつ、ロードバランサ障害時にはDNSのレコード変更(もしくはクライアントのhostsファイル追記)のみの簡易な手動切り替えで暫定対応ができる構成を組めます。

さらに発展させ、証明書のエイリアス(サブジェクトの別名、サブジェクト代替名)を使えば、ロードバランサ障害時はクライアント側でURLを変えるだけで対応できます。

スポンサーリンク

Src&DstNAT構成

VIPから実IPにDestination NATするタイミングで、一緒にSource NATすれば戻りの通信は必ずロードバランサ経由になるので、ネットワークの考慮は不要になります。

ただし、デメリットとしてサーバ側から見たらアクセス元のIPが全て同じになってしまいます

ですがWebサーバへのアクセスログについては、http の X-Forwarded-For(XFF)属性を使うことでこの問題は解決できます。

ロードバランサにて http の中身に X-Forwarded-For の属性を追加し、その属性値として Source NAT変換前のIPアドレス(つまりクライアントのIPアドレス)を記載します。

Webサーバ側では、アクセスログの送信元IPとして「X-Forwarded-For属性がある場合はこちらをログに残す」という設定を入れておきます。構成例を下記に示します。

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
スポンサーリンク