etcd மூலம் ஆசிய-பசிபிக் வீடியோ போக்குவரத்தை வழிநடத்துதல்
எட்டு ஆசிய-பசிபிக் சந்தைகளுக்குச் சேவை செய்யும் ஒரு வீடியோ-ஸ்ட்ரீமிங் தளம், பிராந்தியத்திற்குத் தேவையான உள்ளமைவுகளை (configuration) etcd-க்கு மாற்றுவதன் மூலம் மீண்டும் மீண்டும் நிகழும் ரூட்டிங் பிழைகளைத் தடுத்தது. ரூட்டிங் மாற்றங்களுக்கான பரவுதல் நேரம் (propagation time) ஒரு வினாடிக்கும் குறைவாகக் குறைந்தது. எடிட்டர்கள் இப்போது குறியீட்டை (code) மாற்றாமலேயே சில மணிநேரங்களுக்கு ஒரு மியூசிக் பூலை (music pool) மேம்படுத்த முடிந்தது, மேலும் அந்தத் தளம் தென்கொரியப் பார்வையாளர்களுக்கு டோக்கியோ ஃபீடை (Tokyo feed) அனுப்புவதை நிறுத்தியது.
பழைய அணுகுமுறை ஏன் தோல்வியடைந்தது
ஒவ்வொரு ரூட்டரும் ஒவ்வொரு கோரிக்கைக்கும் (request) மூன்று மதிப்புகளைப் படித்தது: டிரெண்டிங் பூல் (trending pool), மொழி சார்ந்த டோக்கனைசர் (language-specific tokenizer) மற்றும் ஒரு ஃபெல்பேக் செயின் (fallback chain). புதிய கலைஞரை ஊக்குவிப்பது, ஒரு பிராந்தியத் தடையில் எதிர்வினையாற்றுவது, பரிந்துரை அல்காரிதத்தைப் (recommendation algorithm) பரிசோதிப்பது போன்ற வணிக முடிவுகள் அந்த மதிப்புகளைத் தீர்மானித்தன, குறியீடு மாற்றங்கள் அல்ல.
ஆரம்பத்தில், ஒவ்வொரு வரிசைப்படுத்தலும் (deployment) ரூட்டிங் அட்டவணையுடன் கூடிய ஒரு JSON கோப்பை உள்ளடக்கியிருந்தது. ஒரு விபத்தின் போது, ஆன்-கால் பொறியாளர் ஒரு நோடில் (node) போக்குவரத்தை ஒரு பேக்கப் பூலுக்குத் திருப்ப கோப்பைத் திருத்தினார், ஆனால் மற்ற ஏழு நோடுகளையும் புதுப்பிக்கவில்லை. இதனால் உள்ளமைவு மாறுபாடு (config drift) உருவானது: எட்டு நாடுகள் மாறுபட்ட அட்டவணைகளை இயக்கின, மேலும் எந்தவொரு ஒற்றை ஆதாரமும் "உண்மையை" சரிபார்க்கவில்லை. சியோல் பார்வையாளர்களை டோக்கியோவிற்கு அனுப்பிய பிழை நீடித்தது, ஏனெனில் குறியீடு மாறாமல் இருந்தது; மறைக்கப்பட்ட உள்ளமைவு மட்டுமே மாறியிருந்தது.
உண்மையான ஒற்றை ஆதாரமாக etcd-யைத் தேர்ந்தெடுத்தல்
குழு மூன்று விருப்பங்களை ஒப்பிட்டது:
- SQLite/MySQL – இது ஒவ்வொரு ரூட்டரும் ஒரு தரவுத்தளத்தை (database) அடிக்கடி சரிபார்க்கத் தூண்டும், இது தாமதத்தை (latency) அதிகரிக்கும் அல்லது அதிகப்படியான வினவல்களை (queries) உருவாக்கும்.
- Consul – இது ஒரு சிறந்த சேவை-கண்டறிதல் கருவி (service-discovery tool), ஆனால் அந்தத் தளத்திற்கு அதன் முழுமையான மெஷ் (mesh) அம்சங்கள் தேவையில்லை.
- etcd – ஒரு கீ-வேல்யூ ஸ்டோர் (key-value store). இதில் ஒரு watch அடிப்படை அம்சம் உள்ளது, இது ஒரு கீ (key) மாறும்போது உடனடியாக கிளையண்டுகளுக்குத் தெரிவிக்கும்.
'watch' அம்சம் முடிவைத் தீர்மானித்தது. ஒவ்வொரு ரூட்டரும் "ஏதேனும் மாறியுள்ளதா?" என்று மீண்டும் மீண்டும் கேட்பதற்குப் பதிலாக, etcd ஒரு புதுப்பிப்பைத் தள்ளும் (push) வரை ரூட்டர்கள் காத்திருந்தன. தேவையற்ற நெட்வொர்க் போக்குவரத்து மறைந்து போனது மற்றும் ஒவ்வொரு இன்ஸ்டன்ஸும் (instance) ஒரே நேரத்தில் மாற்றத்தைக் கற்றுக்கொண்டது.
அமைப்பை பாதுகாப்பாக வைத்திருக்கும் முறைகள்
Etcd மட்டும் அனைத்து அபாயங்களையும் தீர்க்கவில்லை. பொறியாளர்கள் மூன்று கூடுதல் முறைகளைச் சேர்த்தனர்:
- Leases – ஒரு எடிட்டர் தற்காலிகமான ஒரு மேம்பாட்டை அமைக்க முடியும் (உதாரணமாக, ஆறு மணிநேரத்திற்கு கொரியன்-பாப் பூலின் எடையை அதிகரிப்பது). லீஸ் (lease) தானாகவே காலாவதியாகும், எனவே கைமுறையாகத் திரும்பப் பெறத் தேவையில்லை (manual rollback).
- Compare-and-swap (CAS) – இரண்டு பேர் ஒரே நேரத்தில் ஒரே அமைப்பைத் திருத்தும்போது, CAS ஒருவருக்குத் தோல்வியடைந்து எச்சரிக்கும், இதன் மூலம் அமைப்புகள் அமைதியற்ற முறையில் மாற்றப்படுவதைத் தடுக்கலாம்.
- Sidecar process – PHP நீண்ட கால இணைப்புகளுடன் (long-lived connections) போராடுகிறது. ஒவ்வொரு பெட்டியிலும் (box) உள்ள ஒரு சிறிய Go sidecar, etcd-யைக் கண்காணித்து ரூட்டிங் அட்டவணையின் ஸ்னாப்ஷாட்டை ஒரு பகிரப்பட்ட நினைவகக் கோப்பில் (
/dev/shm) எழுதும். PHP அந்த உள்ளூர் கோப்பைப் படிக்கும், இதன் மூலம் கோரிக்கை கையாளுதலின் போது நெட்வொர்க் பயணங்களைத் தவிர்க்கலாம்.
கட்டமைப்பில் உள்ள நெகிழ்வுத்தன்மை
புதிய வடிவமைப்பு பல பாதுகாப்பு வலைகளைச் சேர்க்கிறது:
- Zero-latency reads – PHP உள்ளூர் நினைவகத்திலிருந்து படிப்பதால், கோரிக்கைகள் தொலைதூரச் சேமிப்பிற்காக (remote store) காத்திருக்க வேண்டியதில்லை.
- Graceful degradation – etcd செயலிழந்தால், ரூட்டர்கள் கடைசியாகத் தெரிந்த சரியான உள்ளமைப்பைப் பயன்படுத்துத் தொடங்கும், இது திடீர் முறிவைத் தவிர்க்கும்.
- Reliable updates – சைடேகார் (sidecar) மறுஇணைப்பு தர்க்கத்தைக் (reconnection logic) கையாளுகிறது மற்றும் etcd இணைப்பு தற்காலிகமாகத் துண்டிக்கப்பட்டாலும் எந்த மாற்றமும் விடுபடாமல் இருப்பதை உறுதி செய்கிறது.
களத்தில் என்ன மாறியது
இடமாற்றத்திற்குப் பிறகு, பழைய அல்லது பொருந்தாத ரூட்டிங் தரவுகளால் ஏற்படும் சம்பவங்கள் பெருமளவு குறைந்ததை குழு கண்டறிந்தது. இப்போது ஒரு ஒற்றை கன்சோல் (console) தற்போதைய உள்ளமைவைக் காட்டுகிறது, மேலும் எந்தவொரு மாற்றமும் ஒரு வினாடிக்குள் அனைத்து எட்டு பிராந்தியங்களுக்கும் பரவுகிறது. தற்காலிக மேம்பாடுகள் அவற்றின் லீஸ் காலாவதியாகும் போது தானாகவே நீக்கப்படுகின்றன, இது முன்பு மனிதத் தவறுகளுக்கு வழிவகுத்த கைமுறை சுத்திகரிப்புப் படிகளைத் தவிர்க்கிறது.
எதிர் கருத்து: சைடேகாரின் செலவு
ஒரு சைடேகாரைச் சேர்ப்பது என்பது ஒவ்வொரு சேவையகத்திற்கும் (server) ஒரு இரண்டாவது செயல்முறை மற்றும் PHP சார்ந்த கட்டமைப்பில் ஒரு Go runtime என்பதைக் குறிக்கிறது. கூடுதல் நினைவகப் பயன்பாடு மற்றும் மற்றொரு பைனரியைக் (binary) கண்காணிக்க வேண்டிய அவசியம் குறித்து சில இயக்குபவர்கள் கவலைப்படுகிறார்கள். நடைமுறையில், சைடேகாரின் பயன்பாடு குறைவாகவே உள்ளது, மேலும் அதன் நம்பகத்தன்மை ஆதாயங்கள்—குறிப்பாக PHP ஒரு நெட்வொர்க் அழைப்பிற்காக ஒருபோதும் காத்திருக்காது என்ற உத்தரவாதம்—செயல்பாட்டுச் சுமையை விட அதிகமாக உள்ளன.
அடுத்து எதைக் கவனிக்க வேண்டும்
பல பிராந்திய சேவைகளை நிர்வகிக்கும் குழுக்கள் இதைக் கண்காணிக்க வேண்டும்:
- etcd health metrics – ரூட்டிங் அடுக்கு ஒரு ஒற்றை சேமிப்பைப் பொறுத்தே உள்ளது; குவோரம் (quorum) நிலை மற்றும் தாமதத்தைக் கண்காணிக்கவும்.
- Lease expiration handling – லீஸ் நேரத்தை வணிக கால அவகாசத்திற்கு ஏற்ப அமைக்கவும்; மிக நீண்ட லீஸ்கள் பழைய மேம்பாடுகளை அப்படியே வைத்திருக்கும்.
- Scaling the watch load – ரூட்டர்கள் அதிகரிக்கும் போது, watch இணைப்புகளும் அதிகரிக்கும்; அதற்கேற்ப etcd சேவையகங்களுக்கான திறனைத் திட்டமிடுங்கள்.
முக்கியக் கருத்து
பல பிராந்தியங்களில் வேகமான மற்றும் ஒருங்கிணைந்த கட்டமைப்பு மாற்றங்கள் தேவைப்படும் எந்தவொரு சேவைக்கும், கோப்பு அடிப்படையிலான கட்டமைப்புகள் அல்லது கனமான மெஷ்களுக்குப் பதிலாக, etcd-ன் watch, lease மற்றும் transaction primitives ஆகியவை ஒரு இலகுவான மற்றும் வலுவான நிலைத்தன்மை கொண்ட மாற்றாக அமைகின்றன. கட்டமைப்பை ஒரு push-driven, தானாகவே சுத்தம் செய்யும் சேமிப்பகமாக மாற்றியதன் மூலம், ஒரு வகை தொழில்நுட்பச் சிக்கல்கள் முழுமையாகத் தவிர்க்கப்பட்டன, மேலும் இது அந்தத் தளத்திற்கு அதன் ரூட்டிங் லாஜிக் மீது நிகழ்நேரக் கட்டுப்பாட்டை வழங்கியது.