etcd સાથે એશિયા પેસિફિક વિડિયો ટ્રાફિકનું રાઉટિંગ
આઠ એશિયા-પેસિફિક બજારોમાં સેવા આપતા એક વિડિયો-સ્ટ્રીમિંગ પ્લેટફોર્મે પ્રાદેશિક-વિશિષ્ટ (region-specific) કોન્ફિગરેશનને etcd માં ખસેડીને વારંવાર થતી રાઉટિંગ ભૂલને રોકી દીધી. રાઉટિંગ ફેરફારો માટેનો પ્રોપેગેશન સમય ઘટીને લગભગ એક સેકન્ડ થઈ ગયો. એડિટર્સ હવે કોડને અડક્યા વગર થોડા કલાકો માટે મ્યુઝિક પૂલને બૂસ્ટ કરી શકતા હતા, અને પ્લેટફોર્મે દક્ષિણ-કોરિયન દર્શકોને ટોક્યો ફીડ મોકલવાનું બંધ કરી દીધું.
જૂની પદ્ધતિ કેમ નિષ્ફળ ગઈ
દરેક રાઉટર દરેક વિનંતી (request) માટે ત્રણ કિંમતો વાંચતું હતું: ટ્રેન્ડિંગ પૂલ, લેંગ્વેજ-સ્પેસિફિક ટોકનાઇઝર, અને ફોલબેક ચેઇન. બિઝનેસ નિર્ણયો—જેમ કે નવા કલાકારને પ્રમોટ કરવા, પ્રાદેશિક અવરોધ (outage) સામે પ્રતિક્રિયા આપવી, અથવા રેકમેન્ડેશન અલ્ગોરિધમનું પરીક્ષણ કરવું—તે કિંમતો નક્કી કરતા હતા, કોડના ફેરફારો નહીં.
શરૂઆતમાં દરેક ડિપ્લોયમેન્ટમાં રાઉટિંગ ટેબલ સાથે એક JSON ફાઇલ સાથે રાખવામાં આવતી હતી. કોઈ ઘટના દરમિયાન, ઓન-કોલ એન્જિનિયરે ટ્રાફિકને બેકઅપ પૂલ પર મોકલવા માટે એક નોડ પર ફાઇલ એડિટ કરી, પરંતુ અન્ય સાત નોડ્સને ક્યારેય અપડેટ કર્યા નહીં. આનાથી 'કોન્ફિગ ડ્રિફ્ટ' (Config drift) ઊભું થયું: આઠ દેશો અલગ-અલગ ટેબલ ચલાવતા હતા, અને કોઈ એક સિંગલ સોર્સ "સત્ય" (truth) ની ચકાસણી કરી શકતો નહોતો. સિઓલના દર્શકોને ટોક્યોમાં મોકલતી બગ (bug) સમસ્યા ચાલુ રહી કારણ કે કોડ સમાન રહ્યો હતો; માત્ર છુપાયેલું કોન્ફિગરેશન અલગ હતું.
સિંગલ સોર્સ ઓફ ટ્રુથ તરીકે etcd ની પસંદગી
ટીમે ત્રણ વિકલ્પોની સરખામણી કરી:
- SQLite/MySQL – દરેક રાઉટરને ડેટાબેઝને પોલ (poll) કરવા માટે મજબૂર કરત, જેનાથી લેટન્સી વધત અથવા ક્વેરીઝનો ભરાવો થત.
- Consul – એક મજબૂત સર્વિસ-ડિસ્કવરી ટૂલ, પરંતુ પ્લેટફોર્મને તેની સંપૂર્ણ મેશ (mesh) સુવિધાઓની જરૂર નહોતી.
- etcd – એક સ્ટ્રોંગલી ક consistant key-value સ્ટોર, જેમાં watch પ્રિમીટિવ છે જે કી (key) બદલાતા જ ક્લાયન્ટ્સને નોટિફાય કરે છે.
'watch' ફીચરે પલડા ભારે કર્યા. દરેક રાઉટર વારંવાર "શું કંઈ બદલાયું છે?" એમ પૂછવાને બદલે, etcd અપડેટ પુશ કરે ત્યાં સુધી રાઉટર્સ નિષ્ક્રિય (idle) રહેતા. બિનજરૂરી નેટવર્ક ટ્રાફિક નાબૂદ થયો અને દરેક ઇન્સ્ટન્સ એકસાથે ફેરફાર વિશે જાણી શક્યા.
સિસ્ટમને સુરક્ષિત રાખતા પેટર્ન્સ
માત્ર etcd એ તમામ જોખમો ઉકેલ્યા નથી. એન્જિનિયરોએ ત્રણ પૂરક પેટર્ન્સ ઉમેર્યા:
- Leases – એડિટર કામચલાઉ બૂસ્ટ સેટ કરી શકે છે (દા.ત., છ કલાક માટે કોરિયન-પોપ પૂલનું વજન વધારવું). લીઝ આપમેળે સમાપ્ત થઈ જાય છે, તેથી મેન્યુઅલ રોલબેક વગર બૂસ્ટ દૂર થઈ જાય છે.
- Compare-and-swap (CAS) – જ્યારે બે વ્યક્તિઓ એકસાથે સમાન સેટિંગ એડિટ કરે છે, ત્યારે CAS એક વ્યક્તિ માટે નિષ્ફળ જાય છે, જે સાયલન્ટ ઓવરરાઈટિંગને અટકાવે છે.
- Sidecar process – PHP લાંબા સમય સુધી ચાલતા કનેક્શન સાથે સંઘર્ષ કરે છે. દરેક બોક્સ પર એક નાનકડો Go sidecar etcd પર નજર રાખે છે અને રાઉટિંગ ટેબલનો સ્નેપશોટ શેરડ-મેમરી ફાઇલમાં (
/dev/shm) લખે છે. PHP તે લોકલ ફાઇલ વાંચે છે, જેથી રિક્વેસ્ટ હેન્ડલિંગ દરમિયાન કોઈ નેટવર્ક રાઉન્ડ-ટ્રિપની જરૂર પડતી નથી.
આર્કિટેક્ચરમાં બિલ્ટ-ઇન રેઝિલિયન્સ
નવું ડિઝાઇનણ કેટલાક સેફ્ટી નેટ્સ ઉમેરે છે:
- Zero-latency reads – PHP હોટ પાથ લોકલ મેમરીમાંથી વાંચે છે, જેથી રિક્વેસ્ટ રિમોટ સ્ટોરની રાહ જોતા અટકી પડતી નથી.
- Graceful degradation – જો etcd ડાઉન થઈ જાય, તો રાઉટર્સ છેલ્લી જાણીતી સારી કોન્ફિગરેશન સર્વ કરવાનું ચાલુ રાખે છે, જે અચાનક આઉટેજ અટકાવે છે.
- Reliable updates – સાઇડકાર રીકનેક્શન લોજિક સંભાળે છે અને ખાતરી આપે છે કે જો etcd કનેક્શન કામચલાઉ ધોરણે તૂટી જાય તો પણ કોઈ ફેરફાર ચૂકી ન જાય.
વાસ્તવિક પરિસ્થિતિમાં શું બદલાયું
માઈગ્રેશન પછી, ટીમે જૂના અથવા ખોટા રાઉટિંગ ડેટાને કારણે થતી ઘટનાઓમાં મોટો ઘટાડો જોયો. હવે એક સિંગલ કન્સોલ વર્તમાન કોન્ફિગરેશન બતાવે છે, અને કોઈપણ એડિટ એક સેકન્ડની અંદર તમામ આઠ પ્રદેશોમાં ફેલાઈ જાય છે. કામચલાઉ બૂસ્ટ્સ તેમની લીઝ સમાપ્ત થાય ત્યારે આપમેળે સાફ થઈ જાય છે, જેનાથી મેન્યુઅલ ક્લીન-અપ સ્ટેપ્સ દૂર થાય છે જે અગાઉ માનવીય ભૂલ તરફ દોરી જતા હતા.
વિરોધ પક્ષ: સાઇડકારની કિંમત
સાઇડકાર ઉમેરવાનો અર્થ છે દરેક સર્વર દીઠ બીજી પ્રોસેસ અને PHP-કેન્દ્રીત સ્ટેકમાં Go રનટાઇમ. કેટલાક ઓપરેટરો વધારાના મેમરી વપરાશ અને અન્ય બાઈનરીનું મોનિટર કરવાની જરૂરિયાત વિશે ચિંતિત હોય છે. વ્યવહારમાં સાઇડકારનો વપરાશ (footprint) મર્યાદિત રહે છે, અને વિશ્વસનીયતાના ફાયદાઓ—ખાસ કરીને એ ખાતરી કે PHP ક્યારેય નેટવર્ક કોલ પર બ્લોક થતું નથી—ઓપરેશનલ ઓવરહેડ કરતા વધુ છે.
આગળ શું ધ્યાન રાખવું
મલ્ટી-રીજન સેવાઓનું સંચાલન કરતી ટીમોએ આ બાબતોનું મોનિટર કરવું જોઈએ:
- etcd health metrics – રાઉટિંગ લેયર સિંગલ સ્ટોર પર આધારિત છે; ક્વોરમ સ્ટેટસ અને લેટન્સી પર નજર રાખો.
- Lease expiration handling – લીઝના સમયને બિઝનેસ વિન્ડો સાથે મેચ કરો; ખૂબ લાંબી લીઝ જૂના બૂસ્ટ્સને ચાલુ રાખી શકે છે.
- Scaling the watch load – જેમ રાઉટર્સ વધે છે, તેમ watch કનેક્શન વધે છે; તે મુજબ etcd સર્વર્સ માટે ક્ષમતાનું આયોજન કરો.
મુખ્ય વાત (Takeaway)
કોઈપણ એવી સેવા માટે જેને અનેક રિજિયન્સમાં ઝડપી અને સંકલિત કોન્ફિગરેશન ફેરફારોની જરૂર હોય છે, etcd ના watch, lease, અને transaction primitives, ફાઇલ-આધારિત કોન્ફિગ્સ અથવા હેવીવેઇટ મેશ (heavyweight meshes) ના વિકલ્પ તરીકે એક લાઇટવેઇટ અને સ્ટ્રોંગલી ક consistant (strongly consistent) વિકલ્પ પ્રદાન કરે છે. કોન્ફિગરેશનને પુશ-ડ્રિવન (push-driven) અને સેલ્ફ-ક્લીનિંગ (self-cleaning) સ્ટોરમાં રૂપાંતરિત કરવાથી, ઘટનાઓનો (incidents) એક આખો પ્રકાર નાબૂદ થયો અને પ્લેટફોર્મને તેના રાઉટિંગ લોજિક (routing logic) પર રીઅલ-ટાઇમ નિયંત્રણ આપ્યું.