Facebookのダウンタイムなしリリース方法に関する論文
(dropbox.com)Zero Downtime Release: Disruption-free Load Balancing of a Multi-Billion User Website
要約説明
-
サーバーはしばしば再起動される: アップグレード、バグ修正、セキュリティパッチ
-
Continuous Release の導入により
→ Facebookの場合、2007年には週1回だったものが、週100回以上のデプロイを実施
→ 毎日数百万台のサーバーが再起動
→ AWS、Atlassian、Yelp、eBay、Uberも同様
→ ヘルスチェックが断続的に失敗するようになる
- 従来のデプロイ方法
- Blue/Greenデプロイ (AWS CodeDeploy, Kubernetes): 2つのマシングループに分け、ロードバランサーが更新後に先に片側へトラフィックを移行
→ コストが高い。多数のマシンがあるEdgeには不向き
- Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS): 1台ずつ段階的に更新しながら、ロードバランサーがトラフィックを調整
→ 更新期間中はCPU使用量が低下し、イテレーションが遅い。
- Hot Restart (HAProxy, Envoy): 1台のマシン内で新しいバージョンのプロセスを起動し、既存プロセスのトラフィックが徐々に終了すると新プロセスがトラフィックを受け取る (SO_REUSEPORT, CMSG, SCM_RIGHTS)
→ TCPでのみ可能で、UDPでは誤ルーティングが発生する可能性
"リリース更新をダウンタイムなしで、高速なイテレーションで、中断なく進めるにはどうすればよいか?"
- FacebookのTraffic Infrastructure
- Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)
→ ティアごとに再起動して中断を防止
→ EdgeとData Centerのマシンはそれぞれ新しいProxyGenを起動して "Socket TakeOver"
→ EdgeとData Center間の "Downstream Connection Reuse"
→ Data CenterとApp Server間の接続は "Partial Post Replay"
- Socket Takeover: 新しいプロセスを起動し、SCM_RIGHTS と CMSGでTCP Listening、UDP VIPソケットを引き継ぐ
→ SCM_RIGHTS: 他のプロセスのFile Descriptorを受け渡せるようにするソケットタイプ
→ CMSG: sendmsg() 機能でローカルプロセス間に制御メッセージを送信できるようにする
→ UDPベース接続であるQUICのため、既存接続については新プロセスが旧プロセスにQUIC ConnectionIDを問い合わせ、該当パケットを旧プロセスへフォワード
- Partial Post Replay (Appサーバー再起動)
→ Appサーバーには2種類のワークロードが存在: 短いAPI呼び出し、長いHTTP POST呼び出し (Upload)
→ このAppサーバーには利用可能なリソースがないため、Socket Takeoverのように新しいインスタンスを起動してソケットを渡すことは不可能で、長いアップロード時間も問題
→ 長いアップロードの途中でAppサーバーが更新されると、プロキシはその内容をすべて保持していないため、そのPOSTを中断しつつ379コードとともにそれまで受信したデータをプロキシへ返す
→ プロキシは既存のAppサーバーから受け取ったデータと残りのデータを結合し、新しいマシンへ再送を試みる
- Zero Downtime Releaseの利点
→ Rolling Update比で約20%高いCPU使用量
→ Hot RestartがQUICパケットを20Kまで誤ルーティングしていたのに比べ、ほぼ誤ルーティングがない
→ Facebook内ではSocket TakeOverは2013年から、その他は2015年から使用中
1件のコメント
上記の内容は、この20分の解説動画をもとに要約したものです https://dl.acm.org/action/downloadSupplement/…
ProxyGen : FacebookのC++ HTTPライブラリ https://github.com/facebook/proxygen