サーバ負荷対応で出てきたように、サーバの負荷を軽減するには複数のサーバを連結してユーザ（来客者）をサーバそれぞれに振り分ける操作が有効です。
もちろん、どのサーバに振り分けられたユーザーも見えるサイトは同じです。
サーバロードバランスは、クライアント（ユーザーが使っている端末）とサーバの間にロードバランサー（負荷分散装置）を設置し、自動的に分散処理を行う方法です。
で、ロードバランシング（負荷分散）を行うシステムをロードバランサと呼びます。
バランシングする方法は様々で、ユーザーを単純に各サーバに順番・均等に割り当てるラウンドロビン方式や、現在の接続数が最も少ない（空いている）サーバを選択する最小コネクション（最小接続）方式、リクエストして最初に応答のあったサーバに割り当てる方式などがあります。
サーバにはすべてIPアドレスが振られていますが、外部から見た場合はロードバランサ（以下LB）は仮想的な1台のサーバに見えるので、IPアドレスは 構築しているサーバ群ではなく仮想的にLBが持つ仮想IPだけが見える事になります。
ポート番号、システムの持っている機能も外から見ればLB一つが受け持っているように動作します。
ユーザーによるリクエストは仮想的サーバ（実際にはサーバ群を取りまとめるLB）に要求を送るわけで、LBがサーバを 選んでリクエストをそのサーバに転送します。
すると問題となるのは、ユーザーがサーバ群の一つにいたとして、別のサーバに移った場合にログイン情報を何かしらの方法で持っていかないとサービス（例えばFacebookとか）からログアウトしてしまいます。
この点は持続性を設定できる機種が多く、最初にサーバを選択したら、そのクライアントからの要求は同じサーバに転送されるよう設定 するものもあります。パーシステンスなどと呼ばれ、例えばセッション開始時にユーザーの端末（PCやスマートフォン）にCookieを送り込み、そのCookieを消化するまでは単一のサーバで引き受けます。
ただこの場合、そのサーバが壊れたら結局サービス停止しているのと同義であり、冗長化を保っていないとも言えます。
他の方法としては、ユーザーのログイン情報は全てのサーバが参照できる別のサーバ（DB）に保存しておき、ユーザーのIPアドレスやCookieを利用してユーザー情報とクライアントを結びつけるような事になります。
LBは配下にあるサーバが正常に稼働しているか否かを常にチェックするヘルスチェック機能があり、異常のあるサーバには処理を割り振らず、別の正常なサーバに割り振ります。こうすると、サーバ群でいずれかがダウンしたとしてもサービスそのものには影響がありません。
LBの機能を利用してDDoS攻撃を防御する事もできます。
いわいるF5アタックの事ですが、この場合は攻撃元のIPを選別して、遮断あるいはサービスと関係ない専用のサーバや、もっと関係ない他人のWebサービスに飛ばしてシステムダウンを回避する事ができます。
また、あえなくサーバダウンしてしまった時も、メンテナンスページなどにアクセスを向けるのもLBの仕事です。
（ダウンしたサーバにメンテナンスページがあると、サーバが無い以上表示されないので別サーバである必要がある）
こんな感じで、現在大型のWebサイトではLBの導入がほぼ必須という事になっています。
