Building A Billion User Load Balancer¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Facebook の Traffic チームが、13億人以上のユーザーを支えるグローバルロードバランシングをどのように扱っているかを紹介する SREcon15 Europe の発表ページ。
取得できた本文は概要中心で、詳細なスライド本文や録画の完全な文字起こしは確認できていないため partial として保存する。
DNS load balancer、software load balancer、content delivery、パフォーマンス、キャパシティ、信頼性の観点がテーマ。
本文¶
この発表は、Facebook の Traffic チームが担当するグローバルなトラフィック制御について扱っている。 対象規模は 13 億人以上のユーザー。 ユーザーリクエストをどのデータセンター、どの経路、どのサーバー群へ流すかを決める仕組みは、単なるロードバランサではなく、サイト全体の性能、容量、可用性を左右する基盤になる。
Traffic チームの役割¶
発表概要によると、Traffic チームは Facebook の site traffic を管理し、バランスさせる。 主な領域は DNS load balancer と software load balancer。
DNS load balancer は、ユーザーがアクセスする入口の名前解決段階で、どのエッジやデータセンターへ向けるかを決める。 地理的距離、ネットワーク状態、データセンターの負荷、障害状況を見て、返す IP や経路を変える。
software load balancer は、データセンター内またはエッジ側で、リクエストを実際のサービスインスタンスへ配る。 ハードウェア専用機器ではなくソフトウェアで制御することで、Facebook 規模の要求に合わせて柔軟に拡張できる。
グローバルロードバランシングの論点¶
十億ユーザー規模では、ロードバランシングは単に「空いているサーバーへ流す」だけでは済まない。
パフォーマンス面では、ユーザーから近い場所へ流すだけでなく、その時点でのネットワーク品質やデータセンターの状態を見る必要がある。 近いデータセンターが混雑していれば、少し遠くても安定した場所へ流す方がよい場合がある。
キャパシティ面では、データセンターごとの余力、メンテナンス、障害時の退避先を考える必要がある。 通常時にすべての拠点を限界まで使っていると、障害時に逃がす場所がない。
信頼性面では、DNS やロードバランサ自体が落ちないこと、誤ったルーティングでトラフィックを一箇所へ集中させないこと、障害時に素早く切り替えられることが重要になる。
DNS と software load balancer の分担¶
DNS は、インターネット上のユーザーを大きな単位でどこへ向けるかを決めるのに向いている。 ただし、DNS にはキャッシュがあるため、切り替えの反映には時間がかかる。 TTL を短くすれば反応は速くなるが、DNS クエリ量やキャッシュ効率に影響する。
software load balancer は、より細かい粒度でリクエストを分配できる。 データセンター内でサービスごとの健康状態や負荷を見て、バックエンドへ流す。 DNS よりもリアルタイムに近い制御ができるが、各拠点内で高可用に運用する必要がある。
Facebook 規模では、この二つを組み合わせ、グローバルな入口制御とローカルなリクエスト分配を分担させると考えられる。
Content Delivery との関係¶
発表概要では content delivery も扱うとされている。 画像、動画、静的アセット、動的リクエストでは、最適な配送経路が異なる。
静的コンテンツはエッジにキャッシュしやすい。 一方、動的リクエストはユーザー状態やデータの所在を考える必要がある。 ロードバランサは、単にリクエストを配るだけでなく、コンテンツ種別やキャッシュ戦略とも関係する。
読み替え¶
詳細な講演本文は取得できていないが、SRE 的には次の観点で読む価値がある。
大規模ロードバランシングは、L4/L7 の技術だけではなく、DNS、ネットワーク、容量計画、障害時オペレーション、キャッシュ、データセンター設計を横断する。 ユーザー数が巨大になるほど、局所的な最適化よりも、システム全体としての制御と失敗時の振る舞いが重要になる。
要点¶
- Facebook Traffic チームは DNS load balancer と software load balancer を使ってグローバル traffic を管理する。
- 十億ユーザー規模では、性能、容量、信頼性、障害退避を同時に考える必要がある。
- DNS は大きな経路制御に向くが、キャッシュと TTL の制約がある。
- software load balancer は細かい分配に向くが、それ自体の可用性が重要。
- Content Delivery とロードバランシングは切り離せない。
- 取得できた情報は概要中心のため、詳細な設計や実装は未確認。