ロードバランサー

たとえ話: レストランの案内係

入口に立つ案内係(=ロードバランサー)が、来店客(=リクエスト)を空いているテーブル(=サーバー)に振り分けます。1つのテーブルに全員を詰め込まず、均等に配ることで、待ち時間を減らし、どこかが満席でも他に回せます。さらに『あのテーブルは片付け中(=故障)』を察知して、そこには案内しません。

図を描画中...

L4 と L7 の違い(一番のポイント)

ここが頻出のつまずき所。どこまで中身を覗いて振り分けるかの違いです。

Layer 4(トランスポート層)

封筒の『宛先IPとポート番号』だけ見て振り分けます。中の手紙(データの中身)は読みません。だから速くて軽い。でも『この内容は動画だから動画サーバーへ』のような賢い判断はできません。

Layer 7(アプリケーション層)

封筒を開けて中身(URL、ヘッダー、Cookie)まで読んでから振り分けます。たとえば /video で始まるリクエストは動画専用サーバーへ、決済リクエストは高性能サーバーへ、といった賢い振り分けができます。その代わり中身を解析する分、リソースを食います。

図を描画中...

便利な追加機能

• SSL termination: HTTPSの暗号化・復号という重い処理をLBが肩代わり。これで各サーバーに証明書を置かなくて済み、サーバーは中身の処理に集中できる。
• Session persistence(スティッキーセッション): 同じユーザーを毎回同じサーバーへ送る。サーバーがログイン状態を覚えている場合に便利。ただし水平スケールしづらくなる副作用あり。

水平スケールの前提: ステートレス

ロードバランサーで台数を増やす(水平スケール = scale out)には、どのサーバーに振られても同じように動く必要があります。サーバーがログインセッションを自分のメモリに抱えていると、次のリクエストが別サーバーに行ったときログインが切れてしまう。だからセッションは**外部の共有ストア(Redisなど)に逃がして、サーバー自体は何も状態を持たない(ステートレス)**設計にします。

振り分けアルゴリズム(代表例)

方式	内容
ラウンドロビン	順番に1台ずつ均等に
重み付きラウンドロビン	能力の高いサーバーに多めに
Least loaded	一番空いているサーバーへ
Session/Cookie	同じユーザーは同じサーバーへ

つまずきポイント

• 水平スケール(台数を増やす)と垂直スケール(1台を強化)は別。LBは水平スケールの要。
• LBを置いただけだとLB自体が単一障害点。LBも2台以上で冗長化する(active-active等)のが定石。
• 『同じユーザーは同じサーバーへ』(persistence)は便利だが、特定サーバーに偏ったり、スケールしづらくなる原因にもなる。