ロードバランシング
読み: ロードバランシング
ロードバランシングとは負荷分散
ロードバランシングは、複数のサーバーにトラフィックを分散させることでシステム全体の可用性と応答速度を維持する技術である。1台のサーバーに負荷が集中して落ちる事態を防ぎ、AIモデルの推論リクエストを複数のGPUサーバーに振り分ける用途でも採用が広がっている。
かんたんに言うと
高速道路の料金所をイメージしてほしい。1つのゲートに全車が殺到すれば大渋滞になるが、複数のゲートに振り分ければスムーズに流れる。ロードバランサーはこの「振り分け係」にあたる。
ロードバランシングで複数サーバーにトラフィックを分散させる基本的な仕組み
ロードバランサーはクライアントとサーバー群の間に立ち、受け取ったリクエストをバックエンドの各サーバーに振り分ける。振り分けのアルゴリズムにはいくつか種類がある。
最もシンプルなのがラウンドロビンで、リクエストを順番に各サーバーへ回す。次に多いのが最小接続数方式で、接続数が最も少ないサーバーに優先的に振る。重み付きラウンドロビンはサーバーのスペック差を考慮して、高性能な方に多くリクエストを割り当てる。
どれを選ぶかはワークロードの特性による。短時間で完結するリクエストならラウンドロビンで十分だが、処理時間にばらつきがある場合は最小接続数方式のほうが偏りにくい。
L4とL7の違い
ロードバランシングにはレイヤー4とレイヤー7の2種類がある。これはOSI参照モデルの層に対応している。
L4はTCPやUDPのレベルで動作する。パケットの中身は見ずにIPアドレスとポート番号だけで振り分けを決めるため、処理が速い。NginxのStreamモジュールやAWS Network Load Balancerがこの方式にあたる。
L7はHTTPのレベルで動く。URLのパスやヘッダー、Cookieの内容を見て振り分け先を変えられる。「/api/v1はサーバー群A、/api/v2はサーバー群B」といったルーティングが可能になる。AWS Application Load BalancerやCloudflareのロードバランサーはL7で動作する。
柔軟さではL7が上だが、パケットの中身を解析する分だけレイテンシは増える。
AIモデル推論における負荷分散
LLMの推論は1リクエストあたりの処理時間が長く、GPUメモリを大量に消費する。1台のGPUサーバーで捌ける同時リクエスト数には物理的な上限があるため、負荷分散は避けて通れない。
クラウド上でGPUインスタンスを複数台並べ、ロードバランサーで推論リクエストを分散するのが一般的な構成である。vLLMやTriton Inference Serverのように、推論エンジン自体がバッチ処理やリクエストキューイングの機能を持つケースもある。
厄介なのは、LLMの推論時間がプロンプトの長さによって大きく変動することである。短い質問なら1秒で返るが、長文のコンテキストを渡せば30秒かかることもある。この不均一なワークロードに対して、単純なラウンドロビンでは一部のサーバーだけがパンクする。推論キューの深さを見て動的に振り分けるアダプティブな方式が求められる。
クラウドでの実装とオンプレミスの選択肢
AWS、GCP、Azureの3大クラウドはいずれもマネージドのロードバランサーを提供している。設定画面からポチポチ操作するだけでL4やL7の負荷分散が組める手軽さが最大の利点である。
一方、オンプレミスではNginxやHAProxyが定番である。NginxはリバースプロキシとL7ロードバランサーを兼ねる構成が多い。HAProxyは高トラフィック環境での安定性に定評がある。
運用で見落とされがちなのがヘルスチェックの設計である。バックエンドのサーバーが応答しなくなったとき、自動的にそのサーバーをプールから外す仕組みがないと、障害時にリクエストがブラックホールに吸い込まれる。ヘルスチェックの間隔と判定条件は、サービスの可用性要件に合わせて慎重に設定する必要がある。
導入時に見落としがちな落とし穴
ロードバランサーを入れたからといって安心するのは早い。
セッションの永続性が必要なアプリケーションでは、同じユーザーのリクエストを同じサーバーに送り続けるスティッキーセッションの設定が必要になる。これを忘れるとログイン状態が消えたり、カートの中身が吹き飛んだりする。
SSL終端をどこで行うかも検討事項である。ロードバランサーでSSLを終端すれば、バックエンドサーバーの負荷は減る。ただし、ロードバランサーとバックエンド間が平文通信になるため、内部ネットワークのセキュリティポリシー次第ではEnd-to-End暗号化が求められる。
結局のところ、負荷分散は「入れて終わり」の技術ではない。トラフィックパターンの変化に合わせて設定を見直し続ける運用の仕事である。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。