システム設計面接でロードバランサーの話題が出ると、「ラウンドロビンで振り分けます」と反射的に答えてしまうエンジニアは少なくありません。もちろんラウンドロビンは有効なアルゴリズムですが、それだけでは面接官を満足させることはできないでしょう。ロードバランサーの設計には、トラフィックの特性やサービスのアーキテクチャ、障害時の挙動など、考慮すべきポイントが数多くあります。
ところで、ロードバランサーは「単にリクエストを振り分ける装置」だと思われがちですが、その役割は想像以上に広範です。SSL終端、セッション維持、ヘルスチェック、レート制限、さらにはDDoS対策まで、ロードバランサーが担う機能は多岐にわたります。面接官がロードバランサーの設計を問うのは、候補者がシステムアーキテクチャ全体を見渡す力を持っているかどうかを確認したいからなのです。
この記事では、ロードバランサー設計面接で問われるポイントを網羅的に解説します。L4とL7の違い、アルゴリズムの選定基準、ヘルスチェックの設計、そして面接で使える回答フレームワークまで、実践的な知識をお伝えしていきます。
L4とL7ロードバランサーの本質的な違い
ロードバランサー設計面接で最初に問われることが多いのが、L4（レイヤー4）とL7（レイヤー7）の違いです。OSI参照モデルの層に基づいた分類ですが、面接ではモデルの暗記よりも「それぞれ何ができて、何ができないのか」を実践的に説明できることが重要です。
L4ロードバランサーはトランスポート層で動作し、IPアドレスとポート番号に基づいてトラフィックを振り分けます。パケットの中身を解析しないため、処理が軽量で高いスループットを実現できます。TCPやUDPレベルでの負荷分散を行うため、HTTPに限らずデータベース接続やメールサーバーなど、あらゆるプロトコルに対応できる汎用性の高さが特徴です。
L7ロードバランサーはアプリケーション層で動作し、HTTPヘッダー、URLパス、Cookieなどの情報に基づいて高度なルーティング判断ができます。たとえば「/api/で始まるリクエストはAPIサーバーに、/images/で始まるリクエストは画像配信サーバーに振り分ける」といったコンテンツベースのルーティングが可能です。面接では「マイクロサービスアーキテクチャではL7ロードバランサーが不可欠です。各サービスへのルーティングをURLパスやホストヘッダーに基づいて行えるためです」と説明できると、アーキテクチャへの理解をアピールできます。
使い分けの判断基準
面接で「L4とL7のどちらを選びますか」と聞かれた場合、ユースケースに応じた判断基準を示すことが大切です。パフォーマンスが最優先で、HTTPの内容に基づいたルーティングが不要な場合はL4が適しています。逆に、リクエストの内容に応じて異なるバックエンドにルーティングする必要がある場合はL7が必須です。
実際のプロダクション環境では、L4とL7を組み合わせて使うケースが多いことも面接で触れておくと良いでしょう。たとえば、入り口にL4ロードバランサー（AWS NLBなど）を配置して大量のTCPコネクションを捌き、その背後にL7ロードバランサー（AWS ALBやNginxなど）を配置してアプリケーションレベルのルーティングを行うという階層構成です。
この構成には、SSL終端をL7ロードバランサーで行うことで、バックエンドサーバーの暗号化・復号化の負荷を軽減できるというメリットもあります。面接で「SSL終端をどこで行いますか」と聞かれたら、「L7ロードバランサーでSSLを終端し、バックエンドとの通信はプレーンHTTPで行います。ただし、セキュリティ要件が厳しい場合はエンドツーエンドの暗号化を検討します」という回答で、セキュリティとパフォーマンスのバランスを考慮していることを示しましょう。
負荷分散アルゴリズムの選定
負荷分散アルゴリズムは、ロードバランサー設計面接の中核となるテーマです。面接官は、各アルゴリズムの特性を理解したうえで、サービスの要件に応じた選択ができるかどうかを見ています。「どのアルゴリズムが最良ですか」という問いに対する正しい答えは「状況による」であり、その「状況」を具体的に説明できることが評価のポイントです。
ラウンドロビンは最もシンプルなアルゴリズムで、リクエストをバックエンドサーバーに順番に振り分けます。すべてのサーバーが同等のスペックで、リクエストの処理コストが均一な場合には非常に効果的です。ところが、実際のサービスではリクエストごとに処理時間が大きく異なることがほとんどです。あるリクエストは10msで完了するのに、別のリクエストは5秒かかるといった状況では、ラウンドロビンだと一部のサーバーに重い処理が集中してしまう可能性があります。
重み付きラウンドロビンは、サーバーのスペックが異なる環境で有用です。高性能なサーバーには多くのリクエストを振り分け、低スペックなサーバーには少なめにするという調整が可能です。面接では「ローリングアップデート中に新旧のサーバーが混在する場合、重み付きラウンドロビンで新しいサーバーへの振り分けを徐々に増やすカナリアデプロイメントにも活用できます」と説明すると、運用面の知識もアピールできます。
高度なアルゴリズムの理解
Least Connections（最小接続数）アルゴリズムは、現在のアクティブな接続数が最も少ないサーバーにリクエストを振り分けます。処理時間が不均一なワークロードに適しており、WebSocketのような長時間接続が多い環境で特に効果を発揮します。
Consistent Hashing（一貫性ハッシュ）は、キャッシュサーバーやセッション管理と組み合わせて使われることが多いアルゴリズムです。同じキー（たとえばユーザーID）を持つリクエストを常に同じサーバーに振り分けるため、サーバーローカルのキャッシュヒット率が向上します。面接で「ユーザーごとのセッション状態を保持するサービスでは、一貫性ハッシュを使ってスティッキーセッションを実現します」と答えられると、アルゴリズムとユースケースの結びつきを理解していることが伝わります。
IP Hashアルゴリズムは、クライアントのIPアドレスに基づいて振り分け先を決定します。同じIPからのリクエストが常に同じサーバーに到達するため、セッション維持に使えます。ただし、大規模なNATの背後にいるユーザー（企業のプロキシ経由のアクセスなど）が特定のサーバーに集中するリスクがある点を面接で指摘できると、実運用の知見を示せるでしょう。
ヘルスチェックと障害検知の設計
ロードバランサー設計面接で見落としがちですが、面接官が高く評価するのがヘルスチェックの設計です。ロードバランサーがどれだけ優れたアルゴリズムでリクエストを振り分けても、障害が発生したサーバーにリクエストを送り続けてしまっては意味がありません。ヘルスチェックの設計は、システムの可用性を保証する要の仕組みです。
ヘルスチェックには大きく分けてアクティブ方式とパッシブ方式があります。アクティブ方式は、ロードバランサーが定期的にバックエンドサーバーにヘルスチェックリクエストを送信し、レスポンスを確認する方法です。HTTPの場合は特定のエンドポイント（/health や /ready）に対してGETリクエストを送り、200番台のステータスコードが返ってくるかどうかで判断します。
パッシブ方式は、実際のトラフィックに対するレスポンスを監視して、異常を検知する方法です。たとえば、特定のサーバーからのエラーレスポンスの割合が一定のしきい値を超えた場合に、そのサーバーを振り分け対象から外すという仕組みです。面接では「アクティブとパッシブの両方を組み合わせるのが理想的です。アクティブヘルスチェックは完全なダウンを検知し、パッシブヘルスチェックはパフォーマンス劣化を検知します」とハイブリッドアプローチを提案しましょう。
ヘルスチェックエンドポイントの設計
面接で掘り下げられやすいのが、ヘルスチェックエンドポイントの設計内容です。単に「200 OKを返す」だけのエンドポイントでは、アプリケーションプロセスは生きているがデータベース接続が切れている、といった部分的な障害を検知できません。
理想的なヘルスチェックエンドポイントは、依存するコンポーネント（データベース、キャッシュ、外部API）への接続状態も確認したうえでレスポンスを返す「ディープヘルスチェック」です。ただし、すべての依存コンポーネントを毎回チェックすると、ヘルスチェック自体が重い処理になってしまう場合があります。
面接では「軽量なLivenessチェックとディープなReadinessチェックを分けて設計します。Livenessはプロセスの生存確認のみを行い、Readinessはデータベース接続やキャッシュ接続を含めた総合的な確認を行います」というKubernetesのProbeパターンに沿った回答が効果的です。この設計により、プロセスはハングしていないがサービス提供が不可能な状態を適切に検知できます。
グローバルロードバランシングとDNS戦略
面接の題材が大規模サービスの場合、データセンターをまたいだグローバルロードバランシングの話題になることがあります。これは単一のロードバランサーでは対応できない課題であり、DNSベースの負荷分散やGeoDNSの活用が必要になります。
GeoDNSは、クライアントの地理的な位置に基づいて最寄りのデータセンターにトラフィックを誘導する仕組みです。ユーザーのリクエストを物理的に近いサーバーで処理することで、ネットワークレイテンシを最小化できます。面接では「日本のユーザーは東京リージョンに、北米のユーザーはバージニアリージョンに振り分けます」という具体例を示しつつ、「DNSのTTLを適切に設定して、データセンター障害時のフェイルオーバー時間を最小化します」という運用面の考慮も添えましょう。
AWSやGCPなどのクラウドプロバイダーは、グローバルロードバランシングの機能を提供しています。AWS Global Acceleratorは、AWSのグローバルネットワークを活用して最寄りのエッジロケーションからトラフィックをルーティングする機能です。面接では具体的なサービス名を出しつつ、「クラウドのマネージドサービスを活用して運用コストを下げる選択肢もありますが、マルチクラウド戦略を取る場合はクラウド非依存のソリューションを検討します」とトレードオフを示すことが大切です。
フェイルオーバーとディザスタリカバリ
グローバルロードバランシングと密接に関わるのが、フェイルオーバー戦略です。プライマリのデータセンターが丸ごとダウンした場合に、どのようにトラフィックを別のデータセンターに切り替えるかという問題は、面接でよく深掘りされるテーマです。
アクティブ-パッシブ構成では、通常時はプライマリサイトがすべてのトラフィックを処理し、障害時にセカンダリサイトに切り替えます。一方、アクティブ-アクティブ構成では、複数のサイトが常にトラフィックを処理しており、一つのサイトが障害を起こしても他のサイトが自動的に引き継ぎます。面接では「コストを優先するならアクティブ-パッシブ、可用性を優先するならアクティブ-アクティブを選択します。ただし、アクティブ-アクティブにはデータの同期とコンフリクト解決の複雑さが伴います」という判断基準を示しましょう。
フェイルオーバーの切り替え時間も重要な議論ポイントです。DNSベースのフェイルオーバーではDNSのTTL分の遅延が発生するため、即座の切り替えは困難です。面接では「DNSのTTLを短く設定（60秒程度）しつつ、クライアント側でもリトライロジックを実装することで、実質的なダウンタイムを最小化します」という現実的な対策を提案できると、実務経験の深さが伝わります。
まとめ
ロードバランサー設計面接では、L4とL7の使い分け、アルゴリズムの選定、ヘルスチェックの設計、そしてグローバルスケールでの負荷分散まで、幅広い知識が問われます。面接官が見ているのは、個々の技術を暗記しているかではなく、サービスの要件に応じて適切な判断ができるかどうかです。
面接で高い評価を得るコツは、設計判断の根拠を明確にすることです。「ラウンドロビンを選びます」ではなく「リクエストの処理コストが均一なこのサービスでは、シンプルなラウンドロビンが最も運用しやすいため選択します」というように、なぜその選択をしたのかを常に説明する姿勢が大切です。
ロードバランサーはシステム設計の要となるコンポーネントです。この記事で紹介した知識をベースに、実際のサービスでの利用シーンを想像しながら面接準備を進めてください。自分が過去に関わったプロジェクトでのロードバランサーの設計を振り返り、その判断理由を言語化しておくことも、面接で自信を持って回答するための有効な準備方法です。