Kuelekeza Trafiki ya Video ya Asia Pacific kwa kutumia etcd

Jukwaa la utiririshaji video linalohudumia masoko nane ya Asia-Pacific liliacha kosa la kila mara la kuelekeza trafiki kwa kuhamisha mipangilio mahususi ya eneo kwenda kwenye etcd. Muda wa kusambaza mabadiliko ya kuelekeza trafiki ulipungua hadi takriban sekunde moja. Wahariri waliweza sasa kuongeza nguvu ya mkusanyiko wa muziki (music pool) kwa saa chache bila kugusa kodi, na jukwaa liliacha kuwatumia watazamaji wa Korea Kusini mtiririko wa Tokyo.

Kwa nini njia ya zamani ilifeli

Kila router ilisoma thamani tatu kwa kila ombi: mkusanyiko wa vitu vinavyovuma (trending pool), tokenizer mahususi ya lugha, na mnyororo wa mbadala (fallback chain). Maamuzi ya kibiashara—kama vile kutangaza msanii mpya, kuitikia hitilafu ya kikanda, au kujaribu algoriti ya mapendekezo—yalichochea thamani hizo, na si mabadiliko ya kodi.

Hapo awali, kila uwekaji (deployment) uliambatisha faili ya JSON yenye jedwali la kuelekeza (routing table). Wakati wa tukio fulani, mhandisi aliye kwenye zamu alihariri faili hiyo kwenye node moja ili kuelekeza trafiki kwenye mkusanyiko wa akiba, lakini hakuiwasasisha node nyingine saba. Mabadiliko ya mipangilio yasiyolingana (config drift) yalianza kutokea: nchi nane zilikuwa zinatumia majedwali tofauti, na hakukuwa na chanzo kimoja kinachothibitisha "ukweli". Hitilafu iliyowatuma watazamaji wa Seoul kwenda Tokyo iliendelea kwa sababu kodi ilibaki vilevile; ni mipangilio iliyofichwa tu iliyotofautiana.

Kuchagua etcd kama chanzo kimoja cha ukweli

Timu ililinganisha chaguzi tatu:

  • SQLite/MySQL – ingelazimisha kila router kuuliza hifadhidata mara kwa mara, jambo ambalo lingesababisha ucheleweshaji (latency) au kutoa maswali mengi kupita kiasi.
  • Consul – zana thabiti ya kutambua huduma (service-discovery), lakini jukwaa halikuhitaji vipengele vyake vyote vya mesh.
  • etcd – hifadhi ya funguo-na-thamani (key-value store) yenye uthabiti mkubwa ikiwa na kipengele cha watch ambacho kinawajulisha wateja mara tu funguo inapobadilika.

Kipengele cha watch kilileta uamuzi. Badala ya kila router kuuliza mara kwa mara "je, kuna kitu kimebadilika?", router zilikaa bila kufanya kazi hadi etcd ilipotuma sasisho. Trafiki isiyo ya lazima ya mtandao ilitoweka na kila nakala (instance) ilijifunza kuhusu mabadiliko kwa wakati mmoja.

Mifumo inayofanya mfumo uwe salama

Etcd pekee haikutatua hatari zote. Wahandisi waliongeza mifumo mitatu ya ziada:

  1. Leases – mhariri anaweza kuweka ongezeko la muda (kwa mfano, kuongeza uzito wa mkusanyiko wa Korean-pop kwa saa sita). Lease huisha yenyewe, hivyo ongezeko hilo huondoka bila kuhitaji kurudisha hali ya awali kwa mkono.
  2. Compare-and-swap (CAS) – watu wawili wanapohariri mipangilio ileile kwa wakati mmoja, CAS inashindwa kwa kutoa taarifa wazi kwa mmoja wao, hivyo kuzuia kufuta data bila taarifa.
  3. Sidecar process – PHP inapata shida na miunganisho ya muda mrefu. Sidecar ndogo ya Go kwenye kila kifaa inafuatilia etcd na kuandika nakala ya papo hapo (snapshot) ya jedwali la kuelekeza kwenye faili la kumbukumbu-mshiriki (/dev/shm). PHP inasoma faili hiyo ya ndani, hivyo kuepuka mzunguko wowote wa mtandao wakati wa kushughulikia ombi.

Ustahimilivu ulioundwa kwenye usanifu

Muundo mpya unaongeza mifumo kadhaa ya usalama:

  • Usomaji usio na ucheleweshaji (Zero-latency reads) – njia kuu ya PHP (hot path) inasoma kutoka kwenye kumbukumbu ya ndani, hivyo maombi hayajawahi kukwama kusubiri hifadhi ya mbali.
  • Kupungua kwa utendaji kwa utaratibu (Graceful degradation) – ikiwa etcd itazimika, router zinaendelea kutoa mipangilio ya mwisho iliyojulikana kuwa nzuri, hivyo kuzuia hitilafu ya ghafla.
  • Sasisho za kuaminika – sidecar inashughulikia mantiki ya kuunganisha tena na kuhakikisha hakuna mabadiliko yanayopotea, hata kama muunganisho wa etcd unakatika kwa muda.

Nini kilibadilika kiutendaji

Baada ya uhamiaji, timu iliona anguko kubwa la matukio yaliyosababishwa na data za kuelekeza zilizopitwa na wakati au zisizolingana. Konsoli moja sasa inaonyesha mipangilio ya sasa, na mabadiliko yoyote yanasambaa katika maeneo yote nane ndani ya sekunde moja. Ongezeko za muda hujisafisha zenyewe wakati lease yake inapofika kikomo, hivyo kuondoa hatua za usafi wa mkono ambazo hapo awali zilisababisha makosa ya kibinadamu.

Upande wa pili: gharama ya sidecar

Kuongeza sidecar inamaanisha mchakato wa pili kwa kila seva na mfumo wa Go kwenye mfululizo wa PHP. Baadhi ya waendeshaji wanahofia matumizi ya ziada ya kumbukumbu na hitaji la kufuatilia faili lingine la binary. Kiutendaji, matumizi ya sidecar ni madogo, na faida za uaminifu—hasa uhakika kwamba PHP haitawahi kukwama kwa ajili ya wito wa mtandao—zinazidi mzigo wa kiutendaji.

Nini cha kufuatilia baadaye

Timu zinazosimamia huduma za maeneo mengi zinapaswa kufuatilia:

  • Vipimo vya afya ya etcd – tabaka la kuelekeza linategemea hifadhi moja; weka jicho kwenye hali ya quorum na ucheleweshaji (latency).
  • Kushughulikia kumalizika kwa lease –linganisha muda wa lease na muda wa kibiashara; lease ndefu sana huacha ongezeko zilizopitwa na wakati.
  • Kupanua mzigo wa watch – kadiri router zinavyoongezeka, miunganisho ya watch huongezeka; panga uwezo wa seva za etcd kulingana na hilo.

Hitimisho

Kwa huduma yoyote inayohitaji mabadiliko ya haraka na yaliyoratibiwa ya usanidi katika maeneo mengi, primitives za etcd za watch, lease, na transaction zinatoa mbadala mwepesi na wenye uthabiti mkali kuliko usanidi unaotegemea faili au mesh nzito. Kubadilisha usanidi kuwa hifadhi inayochochewa na mfumo wa kusukuma (push-driven) na inayojisafisha yenyewe iliondoa aina nzima ya hitilafu na kuipa jukwaa udhibiti wa wakati halisi juu ya mantiki yake ya uelekezaji.