OfferBoxの適性診断を比較｜AnalyzeU＋と360度の違い
ロードバランサーを面接で説明するには？仕組み・L4/L7と設計の注意点
tennis0709closs@gmail.com
記事内に商品プロモーションを含む場合があります
ロードバランサーは、複数のサーバーへ通信を振り分ける仕組みです。面接で説明するなら、何を見て送り先を選び、異常時に何が起きるのかまで整理しましょう。
「アクセスを均等に分ける装置」と覚えるだけでは、接続の扱いやログイン状態について聞かれたときに説明が止まりがちです。入口・転送先・応答の流れを押さえると、L4とL7の違いや設計上の注意もつながります。
本記事では、HTTPとサーバーの基礎を学んだ就活生に向けて、ロードバランサーの通信の流れ、L4・L7の違い、異常時やセッション、TLSの考え方と面接での説明方法を解説します。
【Contents】
ロードバランサーとは？何のために使う？
ロードバランサーは、利用者からの通信を設定した規則に従って複数の処理先へ振り分ける仕組みです。処理先のサーバーはバックエンドとも呼びます。入口で通信を受ける役割と、実際に画面の生成やデータの取得を行う役割を分けて考えると理解しやすくなります。
例えば、同じWebサービスを提供するサーバーを2台用意し、その前にロードバランサーを置く構成です。利用者は共通の入口へアクセスし、ロードバランサーが選んだサーバーが要求を処理します。1つの要求を自動で2つに分割して、両方のサーバーに同時に計算させるという意味ではありません。
複数台へ処理を分けると、1台への集中を避ける構成を作れます。ただし、サーバーを増設する機能そのものではなく、要求の数が同じでも処理の重さによって負荷は変わります。残ったサーバーの容量や、ロードバランサー自身・共通のデータベースの障害も考える必要があります。
「置けば速くなる、止まらなくなる」と説明するより、どの負荷を分け、どの障害に備える構成かを示しましょう。役割と前提をそろえることが、具体的な仕組みを説明する出発点です。
応募先に合わせて学習経験の説明を準備したい人は、IT就活に対応するエージェントの面接支援も比較してみましょう。
ロードバランサーを通る通信の流れ
ここでは、同じWebサービスを提供する複数のサーバーの前に、リバースプロキシ型のロードバランサーを置く例で考えます。接続を入口で受け、選んだサーバーへ要求を渡し、応答を返す流れです。
- STEP1：入口でクライアントの接続を受ける
- STEP2：規則に沿って転送先を選ぶ
- STEP3：応答をクライアントへ返す
STEP1：入口でクライアントの接続を受ける
利用者のブラウザなどのクライアントは、公開された入口のアドレスへ接続します。このプロキシ型の例では、クライアントからの接続をロードバランサーで受け、バックエンド側には別の接続を使います。
ロードバランサーには、どのプロトコルとポートで通信を受けるかを設定します。AWSでは、この受け口の設定をリスナーと呼びます。入口で受け取った要求を、アプリケーションの処理を担当するバックエンドへ渡すという役割分担です。
面接では、まず「誰が接続を受け、誰が処理をするのか」を分けて話しましょう。利用者が全サーバーの状態を見比べて送り先を決める説明や、ロードバランサーが業務処理をすべて行う説明とは異なります。
STEP2：規則に沿って転送先を選ぶ
ロードバランサーは、登録した転送先と振り分け規則・方式を基に、要求を送る先を選びます。正常性の確認を使う構成なら、その判定も候補選びに関わります。
例えば、ラウンドロビンは順に配分する考え方で、最小接続数は有効な接続が少ない先を選ぶ考え方です。順に配っても要求ごとの処理時間は異なり、接続数が少ない先が必ずCPU負荷も低いとは限りません。
製品によって選べる方式や判断単位は違います。AWS ALBの「最少未処理リクエスト」は、接続数ではなく処理中のリクエスト数を扱います。方式名だけでなく、何を数えて判断するかを説明しましょう。通信のたびに必ず2台へ交互に届くとは決めつけないことも大切です。
STEP3：応答をクライアントへ返す
選ばれたバックエンドが要求を処理すると、この構成では応答をロードバランサーへ返し、ロードバランサーがクライアントへ返します。アプリケーションは処理を担当し、ロードバランサーは通信を仲介します。
入口側とバックエンド側が別接続でも、HTTPリクエストのたびに必ずTCP接続を新しく作るという意味ではありません。接続の再利用などもあるため、要求の数と接続の数は分けて考えます。
一方、パススルー型にはバックエンドから直接応答を返す方式もあります。図や面接の説明では「プロキシ型のWeb構成を例にしています」と前提を添えましょう。往復経路を示すことは有効ですが、すべてのロードバランサーで同じ経路になるとは限りません。
L4とL7のロードバランサーはどう違う？
L4とL7の違いは、主に振り分けの判断で扱う情報です。数字が大きいほど高速・安全という順位ではなく、どの情報を使って送り先を分けたいかで考えます。
L4はIPアドレスやポートを基に扱う
L4の負荷分散では、IPアドレスやポート、プロトコルなどの接続に関する情報を扱います。IPアドレス自体はL3の情報ですが、L4の負荷分散でも判断材料に含まれます。HTTPのページ内容を読むこととは分けて捉えましょう。
例えば、AWS NLBはフローハッシュを使って転送先を選び、同じTCP接続は存続中、同じ転送先へ送ります。これは製品の具体例であり、すべての方式が同じ計算をするわけではありません。
L4を説明するときは、まず接続単位の扱いに注目しましょう。また、L4系のAWS NLBにもTLSを終端するリスナーがあります。「L4は暗号化通信を終端できない」と、層の分類だけで製品機能を断定しないことが大切です。
L7はHTTPの情報を使って振り分ける
L7の負荷分散では、HTTPのHostやURLのパスなど、アプリケーション層の情報を使って振り分けられます。
例えば、画像を求めるパスは画像用のサーバー群へ、APIへの要求はAPI用のサーバー群へ送るという考え方です。
HTTPSの要求内容を基に判断する構成では、ロードバランサーがTLSを終端するなど、HTTPの情報を扱える前提が必要です。暗号化したまま通過させる場合と区別します。
L4とL7は「どちらが上か」ではなく、送り先を選ぶために必要な情報から比較しましょう。パスで処理先を分けたいのか、接続単位の配分をしたいのかを示すと、選んだ方式の理由まで話せます。実際に使える条件は製品の仕様で確認します。
| 区分 | 振り分けで扱う情報の例 |
|---|---|
| L4 | IPアドレス・ポートなど接続に関する情報 |
| L7 | HTTPのHost・URLパスなどアプリケーションの情報 |
負荷分散を設計するときに確認すること
通信を複数台へ分けるだけで設計が終わるわけではありません。異常をどう判定するか、処理に必要な状態をどこへ置くか、通信のどの区間を暗号化するかを確認します。
- ヘルスチェックと異常時の動きを決める
- セッションの状態を共有する方法を考える
- TLSを終端する場所と暗号化区間を分ける
ヘルスチェックと異常時の動きを決める
ヘルスチェックは、転送先を利用できるか判断するための確認です。能動的な確認では確認先、間隔、タイムアウト、連続失敗のしきい値などを設定します。実通信を観察する受動的な方式もあり、検知が必ず瞬時に終わるわけではありません。
TCP接続の成功と、アプリの業務処理の成功は別の確認です。また、新しい通信の送り先を変えることは、処理中の要求を別サーバーでそのまま続けられることを意味しません。
全転送先が異常な場合も製品で異なります。例えばAWS ALBは、全ターゲットが異常だと、異常判定の対象にも振り分けるfail-openの動作を取ります。
「故障したら自動で全部救える」とせず、何を検査し、どの通信に作用するかを説明しましょう。残存容量や入口側の冗長性も、別に確かめる必要があります。
セッションの状態を共有する方法を考える
同じ利用者の要求が別のサーバーへ届くときは、アプリケーションの状態をどこへ保存しているかが重要です。状態を1台のメモリだけに持つ設計では、別のサーバーがその状態を参照できない場合があります。
例えば、ログイン後の状態をサーバーAだけに保存すると、次の要求がBに届いた際に同じ状態を使えないことがあります。セッション情報を共有ストアへ置く設計なら、複数台から参照できます。ただし、共有ストアにも可用性の検討が必要です。
スティッキーセッションは送り先を固定する方法であり、状態を複製する機能ではありません。固定すれば安心と考える前に、固定先が故障したときに状態が残るかを確認しましょう。Cookieで運ぶIDとサーバー側の状態の関係は、認証の仕組みと合わせると整理できます。
あわせて読みたい
認証の仕組みを面接で説明するには？認可・セッション・OAuthの違い
TLSを終端する場所と暗号化区間を分ける
TLSをロードバランサーで終端する場合は、クライアントから入口までと、入口からバックエンドまでの2区間を分けて考えます。利用者側がHTTPSでも、その先の通信が自動でHTTPSになるわけではありません。
例えばAWS ALBでは、バックエンドへHTTPまたはHTTPSで転送する設定を選びます。TLSを終端せず暗号化したまま渡す方式とは、復号する場所が異なります。L4・L7という分類だけでなく、実際のリスナーと転送先の設定を確認する必要があります。
面接では、どこで復号し、どこから再び暗号化するのかを区間ごとに説明しましょう。再暗号化とバックエンドの証明書検証も別の論点で、製品・設定によって扱いは違います。TLSが守る範囲を整理すると、終端後のデータの扱いまで考えやすくなります。
あわせて読みたい
暗号化の仕組みを面接で説明するには？共通鍵・公開鍵とHTTPSの役割
ロードバランサーの知識を面接で伝える方法
技術用語を列挙するより、目的と通信の流れをつなげて答えることが大切です。そのうえで、自分が設定・検証したことと、仕組みとして学んだことを分けて伝えましょう。
通信の流れと採用理由を答える
最初の回答では、負荷を分ける目的と、入口が送り先を選ぶ流れを短く示します。プロキシ型のWeb構成という前提を置けば、クライアント・ロードバランサー・バックエンドの役割を順番に説明できます。
詳しく聞かれたら、どの情報を見て振り分けるか、なぜその方式を使うかへ進みます。URLのパスで処理先を分けたいならL7の機能、接続単位で扱う構成ならL4の判断材料というように、要件と仕組みを結び付けます。
回答例を丸暗記するのではなく、自分が理解した構成に置き換えて練習しましょう。触れたことのない製品設定や、測っていない性能の数値まで加える必要はありません。相手の質問に合わせて、基本の流れから条件を一つずつ説明すると伝わりやすくなります。
自分の理解・経験に合わせる回答例
同じWebサービスを提供する複数のサーバーの前で、要求の送り先を選ぶ仕組みです。プロキシ型なら入口で接続を受け、選んだサーバーへ要求を渡して応答を返します。パスで処理先を分けたい場合はL7の機能を使うなど、判断に必要な情報から構成を考えます。
設定・検証した範囲と未経験を区別する
学習用に設定した経験があるなら、設定した規則、確認した応答、検証した条件を分けて整理します。正常時に2台へ届いたことと、障害時にもサービスを継続できることは、同じ検証ではありません。
例えば、パスごとの転送先だけを確認したなら、その結果を話し、障害時の切替や高負荷時の性能は未検証だと区別します。触れていない場合は、図で流れを説明できることと、今後確かめたい項目を伝える方法があります。
実務経験のように広げるより、何を確認して次に何を試すかを具体化しましょう。その整理は、応募先に合わせて学習経験を伝える準備にも使えます。自分の経験に合う選考対策を相談したい人は、IT就活エージェントの支援内容を比較してみてください。
自分の理解・経験に合わせる回答例
学習用の構成では、パスごとに転送先が変わることを応答で確認しました。障害時の切替と負荷を増やした場合の性能は未検証なので、次は確認条件を決めて試したいと考えています。
参考資料
ABOUT ME
IT就活のWebマーケティング領域を支援してきました。
よくあるプログラミングスクールをはじめたら「月収100万円」みたいな嘘のマーケティング活動をしている会社に嫌気が指す思いでいたので、当ブログを設立。
未来を担う学生が、大人に食い物にされないように、「IT就活における社会の真理」をお伝えするブログです。
よくあるプログラミングスクールをはじめたら「月収100万円」みたいな嘘のマーケティング活動をしている会社に嫌気が指す思いでいたので、当ブログを設立。
未来を担う学生が、大人に食い物にされないように、「IT就活における社会の真理」をお伝えするブログです。
