Menghala Trafik Video Asia Pasifik Dengan etcd

Sebuah platform penstriman video yang berkhidmat untuk lapan pasaran Asia-Pasifik telah menghentikan kesilapan penghalaan yang berulang dengan memindahkan konfigurasi khusus wilayah ke dalam etcd. Masa penyebaran untuk perubahan penghalaan menurun kepada kira-kira satu saat. Editor kini boleh meningkatkan (boost) kumpulan muzik untuk beberapa jam tanpa menyentuh kod, dan platform tersebut berhenti menghantar suapan (feed) Tokyo kepada penonton Korea Selatan.

Mengapa pendekatan lama gagal

Setiap penghala membaca tiga nilai bagi setiap permintaan: kumpulan trending, tokenizer khusus bahasa, dan rantaian sandaran (fallback chain). Keputusan perniagaan—mempromosikan artis baharu, bertindak balas terhadap gangguan wilayah, menguji algoritma cadangan—memacu nilai-nilai tersebut, bukannya perubahan kod.

Pada mulanya, setiap deployment menyertakan fail JSON bersama jadual penghalaan. Semasa sesuatu insiden, seorang jurutera bertugas (on-call) telah menyunting fail pada satu nod untuk menghalakan trafik ke kumpulan sandaran tetapi tidak pernah mengemas kini tujuh nod yang lain. "Config drift" (penyimpangan konfigurasi) muncul: lapan negara menjalankan jadual yang berbeza, dan tiada sumber tunggal yang mengesahkan "kebenaran". Pepijat yang menghantar penonton Seoul ke Tokyo berterusan kerana kod kekal sama; hanya konfigurasi tersembunyi yang berbeza.

Memilih etcd sebagai sumber kebenaran tunggal

Pasukan tersebut membandingkan tiga pilihan:

  • SQLite/MySQL – akan memaksa setiap penghala untuk melakukan 'poll' pada pangkalan data, menambah kependaman (latency) atau membanjiri pertanyaan (queries).
  • Consul – alat penemuan perkhidmatan (service-discovery) yang mantap, tetapi platform tersebut tidak memerlukan ciri mesh sepenuhnya.
  • etcd – stor kunci-nilai (key-value store) yang konsisten secara teguh dengan primitif watch yang memaklumkan klien sebaik sahaja sesuatu kunci berubah.

Ciri watch tersebut menjadi penentu. Daripada setiap penghala bertanya berulang kali "adakah sesuatu telah berubah?", penghala akan kekal pegun sehingga etcd menolak (push) kemas kini. Trafik rangkaian yang tidak perlu hilang dan setiap instans mengetahui tentang perubahan secara serentak.

Corak yang memastikan sistem selamat

etcd sahaja tidak menyelesaikan semua risiko. Jurutera menambah tiga corak pelengkap:

  1. Leases – seorang editor boleh menetapkan peningkatan sementara (contohnya, meningkatkan pemberat kumpulan K-pop selama enam jam). Pajakan (lease) tamat secara automatik, jadi peningkatan tersebut hilang tanpa perlu melakukan 'rollback' manual.
  2. Compare-and-swap (CAS) – apabila dua orang menyunting tetapan yang sama secara serentak, CAS akan gagal dengan jelas bagi salah seorang, sekali gus menghalang penindihan (overwrite) secara senyap.
  3. Sidecar process – PHP sukar mengendalikan sambungan jangka panjang. Sebuah sidecar Go yang kecil pada setiap kotak memerhati etcd dan menulis imbasan (snapshot) jadual penghalaan ke fail memori kongsi (/dev/shm). PHP membaca fail tempatan tersebut, mengelakkan sebarang perjalanan balik (round-trip) rangkaian semasa pengendalian permintaan.

Ketahanan yang dibina ke dalam seni bina

Reka bentuk baharu ini menambah beberapa jaring keselamatan:

  • Bacaan kependaman sifar – laluan pantas (hot path) PHP membaca daripada memori tempatan, jadi permintaan tidak pernah terhenti menunggu stor jauh.
  • Degradasi beransur-ansur (Graceful degradation) – jika etcd tergendala, penghala terus menyediakan konfigurasi baik yang terakhir diketahui, menghalang gangguan mengejut.
  • Kemas kini yang boleh dipercayai – sidecar mengendalikan logik penyambungan semula dan menjamin tiada perubahan yang terlepas, walaupun sambungan etcd terputus buat sementara waktu.

Apa yang berubah di lapangan

Selepas migrasi, pasukan tersebut melihat penurunan ketara dalam insiden yang disebabkan oleh data penghalaan yang lapuk atau tidak sepadan. Satu konsol tunggal kini memaparkan konfigurasi semasa, dan sebarang suntingan tersebar ke lapan wilayah dalam masa satu saat. Peningkatan sementara akan dibersihkan sendiri apabila pajakan tamat, menghapuskan langkah pembersihan manual yang sebelum ini membawa kepada ralat manusia.

Hujah balas: kos sidecar

Menambah sidecar bermakna terdapat proses kedua bagi setiap pelayan dan runtime Go dalam timbunan (stack) berpusatkan PHP. Sesetengah pengendali bimbang tentang penggunaan memori tambahan dan keperluan untuk memantau binari lain. Dalam praktiknya, jejak (footprint) sidecar kekal sederhana, dan peningkatan kebolehpercayaan—terutamanya jaminan bahawa PHP tidak akan tersekat pada panggilan rangkaian—melebihi beban operasi tersebut.

Apa yang perlu diperhatikan seterusnya

Pasukan yang menguruskan perkhidmatan pelbagai wilayah harus memantau:

  • metrik kesihatan etcd – lapisan penghalaan bergantung pada stor tunggal; perhatikan status kuorum dan kependaman.
  • Pengendalian tamat pajakan – sesuaikan masa pajakan dengan jendela perniagaan; pajakan yang terlalu lama akan meninggalkan peningkatan yang lapuk.
  • Penskalaan beban watch – apabila penghala bertambah, sambungan watch juga meningkat; rancang kapasiti pelayan etcd sewajarnya.

Rumusan

Bagi mana-mana perkhidmatan yang memerlukan perubahan konfigurasi yang pantas dan terkoordinasi merentasi pelbagai wilayah, primitif watch, lease, dan transaction etcd menawarkan alternatif yang ringan dan konsisten secara teguh berbanding konfigurasi berasaskan fail atau mesh yang berat. Menukarkan konfigurasi kepada stor yang dipacu-tolak dan pembersihan kendiri telah menghapuskan satu kategori insiden secara menyeluruh dan memberikan platform kawalan masa nyata ke atas logik penghalaannya.