最近、SREが話題ですね。

tech.mercari.com www.wantedly.com

ということでSREについて調べてたら、SREconなんてものが開催されていたので中を見てたら、「Building a Billion User Load Balancer」というタイトルでFacebookのDNS〜LBまでの話があったので、そのメモです。

Building a Billion User Load Balancer | USENIX

td;lt

• tinydns + IPVS で Facebook規模はいける
• httpsの接続確立はかなり重い(RTTの4倍 = RTT 150msとするとGETまで600ms)ので、太平洋越えとかは厳しい
• httpsを終端させるCDNとかは活用の可能性ありそう (国内だけを考慮するなら影響は軽微かも)

メモ

• L4 LB
  • shiv (IPVS + python-wrapper) を利用 (OSSにはなっていなさそう?)
    • ちなみにIPVSはLinuxカーネルのロードバランサ機能のこと
  • IPIPカプセリングしてDSR(Direct Server Return)
• L7 LB
  • proxygen https://github.com/facebook/proxygen
  • ユーザーからのhttpsを終端
• ルータ 〜 L4 LB
  • BGPによるECMP Hash
• L4 LB 〜 L7 LB
  • Consistent hashingで行なっている
• DNS(tinydns)でロードバランシング
  • DCはUS 4ヶ所、EUに1ヶ所
• POPを世界中にもっている
  • POPにはL4 LBとL7 LBを配置している
  • https接続は重いのでできるだけ近くで終端する必要がある
    • httpはtcpの3way + httpの1往復
    • httpsだとそこにtlsの2往復が加わってさらに厳しくなる
• POP内のL7 LBから(別DC上の)アプリケーションサーバーへのhttpsは事前に張っておく
• 5分に一度DNSのマッピングを生成
  • Cartography https://www.facebook.com/notes/facebook-engineering/internet-cartography/408327833919
  • バランシングはPOPのキャパシティなどを考慮する。下図で綺麗にlimitを越えないように制御されているのが見れる
  • ちなみにfacebook.comのDNS TTLを見てみると5min(以内)に設定されていそう

# dig facebook.com
...
;; ANSWER SECTION:
facebook.com.       113 IN  A   173.252.120.68
...

• このスライドも参考になる http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf