etcd తో ఆసియా పసిఫిక్ వీడియో ట్రాఫిక్ను రూటింగ్ చేయడం
ఎనిమిది ఆసియా-పసిఫిక్ మార్కెట్లకు సేవలు అందించే ఒక వీడియో-స్ట్రీమింగ్ ప్లాట్ఫారమ్, ప్రాంతం ఆధారిత కాన్ఫిగరేషన్ను etcdలోకి మార్చడం ద్వారా పదేపదే జరుగుతున్న రూటింగ్ పొరపాటును నిలిపివేసింది. రూటింగ్ మార్పుల కోసం పట్టే ప్రొపగేషన్ సమయం సుమారు ఒక సెకనుకు తగ్గింది. ఎడిటర్లు ఇప్పుడు కోడ్ను తాకకుండానే కొన్ని గంటల పాటు ఒక మ్యూజిక్ పూల్ను బూస్ట్ చేయగలరు, మరియు ఆ ప్లాట్ఫారమ్ దక్షిణ కొరియా వీక్షకులకు టోక్యో ఫీడ్ను పంపడం ఆపివేసింది.
పాత విధానం ఎందుకు విఫలమైంది
ప్రతి రూటర్ ప్రతి రిక్వెస్ట్ కోసం మూడు విలువలను చదువుతుంది: ట్రెండింగ్ పూల్, లాంగ్వేజ్-స్పెసిఫిక్ టోకనైజర్ మరియు ఫాల్బ్యాక్ చైన్. కోడ్ మార్పుల వల్ల కాకుండా, వ్యాపార నిర్ణయాల వల్ల—అంటే ఒక కొత్త కళాకారుడిని ప్రమోట్ చేయడం, ప్రాంతీయ అంతరాయాలకు స్పందించడం లేదా రికమెండేషన్ అల్గారిథమ్ను పరీక్షించడం వంటి వాటి వల్ల ఈ విలువలు మారుతుంటాయి.
ప్రారంభంలో ప్రతి డిప్లాయ్మెంట్లో రూటింగ్ టేబుల్తో కూడిన ఒక JSON ఫైల్ ఉండేది. ఏదైనా సమస్య వచ్చినప్పుడు, ఆన్-కాల్ ఇంజనీర్ ఒక నోడ్లో ట్రాఫిక్ను బ్యాకప్ పూల్కు మళ్లించడానికి ఫైల్ను ఎడిట్ చేస్తారు, కానీ మిగిలిన ఏడు నోడ్లను అప్డేట్ చేయరు. దీనివల్ల కాన్ఫిగరేషన్ డ్రిఫ్ట్ (Config drift) ఏర్పడింది: ఎనిమిది దేశాలు వేర్వేరు టేబుల్స్ను నడుపుతున్నాయి, మరియు ఏ ఒక్క మూలం కూడా "నిజమైన" (truth) సమాచారాన్ని ధృవీకరించలేకపోయింది. సియోల్ వీక్షకులను టోక్యోకు పంపే బగ్ అలాగే కొనసాగింది ఎందుకంటే కోడ్ మారలేదు; కేవలం దాగి ఉన్న కాన్ఫిగరేషన్ మాత్రమే వేరుగా ఉంది.
సింగిల్ సోర్స్ ఆఫ్ ట్రూత్ (single source of truth) గా etcdని ఎంచుకోవడం
టీమ్ మూడు ఆప్షన్లను పోల్చింది:
- SQLite/MySQL – ఇది ప్రతి రూటర్ డేటాబేస్ను పోల్ (poll) చేయాల్సి వచ్చేలా చేస్తుంది, దీనివల్ల లేటెన్సీ పెరుగుతుంది లేదా క్వెరీల భారం పెరుగుతుంది.
- Consul – ఇది ఒక మంచి సర్వీస్-డిస్కవరీ టూల్, కానీ ప్లాట్ఫారమ్కు దాని పూర్తి మెష్ ఫీచర్లు అవసరం లేదు.
- etcd – ఇది ఒక స్ట్రాంగ్లీ కన్సిస్టెంట్ కీ-వాల్యూ స్టోర్, ఇందులో ఒక కీ మారిన వెంటనే క్లయింట్లకు తెలియజేసే ఒక watch ప్రిమిటివ్ ఉంటుంది.
'watch' ఫీచర్ నిర్ణయాన్ని మార్చింది. ప్రతి రూటర్ "ఏదైనా మారిందా?" అని పదేపదే అడగడానికి బదులుగా, etcd అప్డేట్ను పంపే వరకు రూటర్లు ఖాళీగా (idle) ఉంటాయి. అనవసరమైన నెట్వర్క్ ట్రాఫిక్ తగ్గిపోయింది మరియు ప్రతి ఇన్స్టాన్స్ ఒకేసారి మార్పును తెలుసుకుంటుంది.
సిస్టమ్ను సురక్షితంగా ఉంచే ప్యాటర్న్స్
etcd మాత్రమే అన్ని రిస్క్లను పరిష్కరించలేదు. ఇంజనీర్లు మూడు అనుబంధ ప్యాటర్న్స్ను జోడించారు:
- Leases – ఎడిటర్ తాత్కాలిక బూస్ట్ను సెట్ చేయవచ్చు (ఉదాహరణకు, ఆరు గంటల పాటు కొరియన్-పాప్ పూల్ వెయిట్ను పెంచడం). లీజు ఆటోమేటిక్గా ముగుస్తుంది, కాబట్టి మాన్యువల్ రోల్బ్యాక్ అవసరం లేకుండా బూస్ట్ తొలగిపోతుంది.
- Compare-and-swap (CAS) – ఇద్దరు వ్యక్తులు ఒకే సెట్టింగ్ను ఒకేసారి ఎడిట్ చేసినప్పుడు, CAS ఒకరి కోసం విఫలమై, నిశ్శబ్దంగా ఓవర్రైట్ (silent overwrite) కాకుండా నిరోధిస్తుంది.
- Sidecar process – PHP లాంగ్-లివ్డ్ కనెక్షన్లతో ఇబ్బంది పడుతుంది. ప్రతి బాక్స్లో ఒక చిన్న Go సైడ్కార్ etcdని వాచ్ చేస్తుంది మరియు రూటింగ్ టేబుల్ యొక్క స్నాప్షాట్ను షేర్డ్-మెమరీ ఫైల్ (
/dev/shm)కి రాస్తుంది. PHP ఆ లోకల్ ఫైల్ను చదువుతుంది, దీనివల్ల రిక్వెస్ట్ హ్యాండ్లింగ్ సమయంలో నెట్వర్క్ రౌండ్-ట్రిప్ అవసరం ఉండదు.
ఆర్కిటెక్చర్లో నిర్మించిన రెసిలియన్స్
కొత్త డిజైన్ కొన్ని సేఫ్టీ నెట్లను జోడిస్తుంది:
- Zero-latency reads – PHP హాట్ పాత్ లోకల్ మెమరీ నుండి చదువుతుంది, కాబట్టి రిక్వెస్ట్లు రిమోట్ స్టోర్ కోసం వేచి ఉండాల్సిన అవసరం లేదు.
- Graceful degradation – ఒకవేళ etcd డౌన్ అయితే, రూటర్లు చివరిగా తెలిసిన సరైన కాన్ఫిగరేషన్ను ఉపయోగిస్తాయి, దీనివల్ల అకస్మాత్తుగా సర్వీస్ ఆగిపోదు.
- Reliable updates – సైడ్కార్ రీకనెక్టెషన్ లాజిక్ను నిర్వహిస్తుంది మరియు etcd కనెక్షన్ తాత్కాలికంగా తెగిపోయినా, ఏ మార్పు కూడా మిస్ కాకుండా చూస్తుంది.
క్షేత్రస్థాయిలో ఏమి మారింది
మైగ్రేషన్ తర్వాత, పాత లేదా సరిపోని రూటింగ్ డేటా వల్ల కలిగే సంఘటనలు గణనీయంగా తగ్గాయి. ఇప్పుడు ఒకే కన్సోల్ ప్రస్తుత కాన్ఫిగరేషన్ను చూపుతుంది, మరియు ఏదైనా ఎడిట్ ఒక సెకనులోపు ఎనిమిది ప్రాంతాలకు వ్యాపిస్తుంది. తాత్కాలిక బూస్ట్లు వాటి లీజు ముగిసినప్పుడు తమంతట తామే క్లీన్ అవుతాయి, దీనివల్ల గతంలో మానవ తప్పిదాలకు దారితీసిన మాన్యువల్ క్లీన్-అప్ దశలు తొలగిపోయాయి.
కౌంటర్-పాయింట్: సైడ్కార్ వల్ల కలిగే ఖర్చు
సైడ్కార్ను జోడించడం అంటే ప్రతి సర్వర్కు ఒక రెండవ ప్రాసెస్ మరియు PHP-కేంద్రీకృత స్టాక్లో ఒక Go రన్టైమ్ ఉండటం అని అర్థం. కొంతమంది ఆపరేటర్లు అదనపు మెమరీ వినియోగం మరియు మరొక బైనరీని పర్యవేక్షించాల్సిన అవసరం గురించి ఆందోళన చెందుతారు. వాస్తవానికి సైడ్కార్ యొక్క ఫుట్ప్రింట్ తక్కువగానే ఉంటుంది, మరియు దాని వల్ల కలిగే విశ్వసనీయత—ముఖ్యంగా PHP నెట్వర్క్ కాల్ కోసం ఎప్పుడూ బ్లాక్ అవ్వదు అనే గ్యారెంటీ—ఆపరేషనల్ ఓవర్హెడ్ కంటే ఎక్కువే.
తదుపరి గమనించవలసినవి
మల్టీ-రీజియన్ సర్వీస్లను నిర్వహించే టీమ్లు వీటిని పర్యవేక్షించాలి:
- etcd health metrics – రూటింగ్ లేయర్ ఒకే స్టోర్పై ఆధారపడి ఉంటుంది; క్వోరం (quorum) స్థితి మరియు లేటెన్సీని గమనిస్తూ ఉండండి.
- Lease expiration handling – లీజు సమయాలను వ్యాపార అవసరాలకు అనుగుణంగా సెట్ చేయండి; అతి dài లీజులు పాత బూస్ట్లను అలాగే ఉంచుతాయి.
- Scaling the watch load – రూటర్లు పెరిగే కొద్దీ, వాచ్ కనెక్షన్లు కూడా పెరుగుతాయి; దానికి అనుగుణంగా etcd సర్వర్ల సామర్థ్యాన్ని ప్లాన్ చేయండి.
ముగింపు
అనేక ప్రాంతాలలో వేగవంతమైన, సమన్వయంతో కూడిన కాన్ఫిగరేషన్ మార్పులు అవసరమయ్యే ఏ సేవకైనా, etcd యొక్క watch, lease, మరియు transaction primitives, ఫైల్-ఆధారిత కాన్ఫిగరేషన్లు లేదా హెవీవెయిట్ మెష్ల కంటే తేలికైన మరియు దృఢమైన (strongly consistent) ప్రత్యామ్నాయాన్ని అందిస్తాయి. కాన్ఫిగరేషన్ను push-driven, self-cleaning స్టోర్గా మార్చడం వల్ల ఒక రకమైన సమస్యలు పూర్తిగా తొలగిపోయాయి మరియు ప్లాట్ఫారమ్కు దాని రూటింగ్ లాజిక్ పై రియల్-టైమ్ నియంత్రణను అందించింది.