Makalah tentang metode rilis tanpa downtime di Facebook

Zero Downtime Release: Disruption-free Load Balancing of a Multi-Billion User Website

Ringkasan

• Server sering kali di-restart: upgrade, perbaikan bug, patch keamanan

• Dengan diperkenalkannya Continuous Release

→ Dalam kasus Facebook, dari 1 kali per minggu pada 2007 menjadi lebih dari 100 deployment per minggu

→ Ratusan ribu server di-restart setiap hari

→ AWS, Atlassian, Yelp, eBay, Uber juga sama

→ Health check menjadi sesekali gagal

• Metode deployment tradisional

1. Deployment Blue/Green (AWS CodeDeploy, Kubernetes): dibagi menjadi dua kelompok mesin dan load balancer lebih dulu memindahkan trafik ke salah satu sisi yang diperbarui

→ Biayanya mahal. Tidak cocok untuk edge yang memiliki sangat banyak mesin

2. Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS): update dilakukan bertahap satu per satu sambil load balancer menyesuaikan trafik

→ Penggunaan CPU menurun selama periode update, iterasinya lambat.

3. Hot Restart (HAProxy, Envoy): dalam satu mesin, proses versi baru dijalankan dan ketika trafik proses lama berangsur selesai, proses baru menerima trafik (SO_REUSEPORT, CMSG, SCM_RIGHTS)

→ Hanya memungkinkan untuk TCP dan pada UDP dapat terjadi routing yang salah

"Bagaimana cara melakukan update rilis tanpa downtime, dengan iterasi cepat, dan tanpa gangguan?"

• Traffic Infrastructure Facebook

• Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)

→ Restart dilakukan per tier untuk mencegah gangguan

→ Mesin di Edge dan Data Center masing-masing menjalankan ProxyGen baru untuk melakukan "Socket TakeOver"

→ "Downstream Connection Reuse" antara Edge dan Data Center

→ Koneksi antara Data Center dan App Server menggunakan "Partial Post Replay"

• Socket Takeover: menjalankan proses baru lalu meneruskan socket TCP Listening dan socket UDP VIP melalui SCM_RIGHTS dan CMSG

→ SCM_RIGHTS: tipe socket yang memungkinkan menerima File Descriptor dari proses lain

→ CMSG: memungkinkan pengiriman control message antarproses lokal melalui fungsi sendmsg()

→ Untuk QUIC, yang merupakan koneksi berbasis UDP, pada koneksi yang sudah ada proses baru menanyakan QUIC ConnectionID ke proses lama lalu meneruskan paket terkait ke proses lama

• Partial Post Replay (restart App server)

→ App server memiliki dua jenis workload: panggilan API pendek, panggilan HTTP POST panjang (upload)

→ Karena app server ini tidak memiliki sumber daya cadangan, tidak memungkinkan menjalankan instance baru dan memindahkan socket seperti pada Socket Takeover, dan lamanya waktu upload juga menjadi masalah

→ Jika app server diperbarui di tengah upload panjang, karena proxy tidak menyimpan seluruh isinya, POST tersebut dihentikan dan bersama kode 379 data yang sudah diterima hingga saat itu dikembalikan ke proxy

→ Proxy menggabungkan data yang diterima dari app server lama dengan sisa data lalu mencoba mengirim ulang ke mesin baru

• Kelebihan Zero Downtime Release

→ Penggunaan CPU sekitar 20% lebih tinggi dibanding Rolling Update

→ Dibanding Hot Restart yang sempat salah merutekan hingga 20K paket QUIC, hampir tidak ada misrouting

→ Di Facebook, Socket TakeOver digunakan sejak 2013, dan sisanya sejak 2015

[xguru]

Konten di atas diringkas berdasarkan video penjelasan berdurasi 20 menit ini https://dl.acm.org/action/downloadSupplement/…

ProxyGen: library HTTP C++ milik Facebook https://github.com/facebook/proxygen