ఇంటర్నెట్ టెలివిజన్ రంగంలో నెట్ఫ్లిక్స్ మార్కెట్ లీడర్. ఈ విభాగాన్ని సృష్టించి, చురుకుగా అభివృద్ధి చేస్తున్న సంస్థ ఇదే. నెట్ఫ్లిక్స్, ప్రపంచంలో దాదాపు ఎక్కడి నుండైనా మరియు ఏ పరికరం నుండైనా అందుబాటులో ఉండే దాని విస్తృతమైన సినిమాలు మరియు సిరీస్ల కేటలాగ్కు మాత్రమే కాకుండా, దాని నమ్మకమైన మౌలిక సదుపాయాలు మరియు విశిష్టమైన ఇంజనీరింగ్ సంస్కృతికి కూడా ప్రసిద్ధి చెందింది.
DevOops 2019లో, సంక్లిష్టమైన సిస్టమ్లను అభివృద్ధి చేయడానికి మరియు వాటికి మద్దతు ఇవ్వడానికి తాను అనుసరించే విధానానికి నెట్ఫ్లిక్స్ ఒక స్పష్టమైన ఉదాహరణను ప్రదర్శించింది. — నెట్ఫ్లిక్స్లో ఇంజనీరింగ్ డైరెక్టర్. నిజ్నీ నొవ్గోరోడ్లోని లోబాచెవ్స్కీ స్టేట్ యూనివర్శిటీలోని కంప్యూటేషనల్ మ్యాథమెటిక్స్ అండ్ సైబర్నెటిక్స్ ఫ్యాకల్టీ నుండి పట్టభద్రుడైన సెర్గీ, నెట్ఫ్లిక్స్ యొక్క CDN బృందమైన ఓపెన్ కనెక్ట్లోని తొలి ఇంజనీర్లలో ఒకరు. ఆయన వీడియో డేటా పర్యవేక్షణ మరియు విశ్లేషణ వ్యవస్థలను నిర్మించారు, జనాదరణ పొందిన ఇంటర్నెట్ వేగ పరీక్ష సేవ FAST.comను ప్రారంభించారు, మరియు వినియోగదారుల కోసం నెట్ఫ్లిక్స్ యాప్ సాధ్యమైనంత వేగంగా పనిచేసేలా చూసేందుకు, గత కొన్ని సంవత్సరాలుగా ఇంటర్నెట్ అభ్యర్థనలను ఆప్టిమైజ్ చేయడంపై పనిచేస్తున్నారు.
సమావేశంలో పాల్గొన్నవారి నుండి ఈ నివేదికకు అద్భుతమైన సమీక్షలు లభించాయి, మరియు మేము మీ కోసం దీని టెక్స్ట్ వెర్షన్ను సిద్ధం చేశాము.
తన నివేదికలో సెర్గీ వివరంగా మాట్లాడాడు
- క్లయింట్ మరియు సర్వర్ మధ్య ఇంటర్నెట్ అభ్యర్థనల ఆలస్యాన్ని ఏది ప్రభావితం చేస్తుంది అనే దాని గురించి;
- ఈ ఆలస్యాన్ని ఎలా తగ్గించాలి;
- లోపాలను తట్టుకోగల వ్యవస్థలను రూపకల్పన చేయడం, నిర్వహించడం మరియు పర్యవేక్షించడం ఎలా;
- తక్కువ సమయంలో మరియు మీ వ్యాపారానికి కనీస నష్టంతో ఫలితాలను ఎలా సాధించాలి;
- ఫలితాలను విశ్లేషించి, తప్పుల నుండి ఎలా నేర్చుకోవాలి.
ఈ ప్రశ్నలకు సమాధానాలు కేవలం పెద్ద సంస్థలలో పనిచేసే వారికి మాత్రమే అవసరం లేదు.
ఇక్కడ అందించిన సూత్రాలు మరియు పద్ధతులు ఇంటర్నెట్ ఉత్పత్తులను అభివృద్ధి చేసే మరియు వాటికి మద్దతు ఇచ్చే ప్రతిఒక్కరూ తెలుసుకొని, ఆచరించాలి.
ఈ క్రిందిది వక్త యొక్క కథనం.
ఇంటర్నెట్ వేగం యొక్క ప్రాముఖ్యత
ఇంటర్నెట్ శోధన వేగం వ్యాపారానికి నేరుగా సంబంధం కలిగి ఉంటుంది. షాపింగ్ పరిశ్రమను పరిగణించండి: 2009లో అమెజాన్ 100ms ఆలస్యం వల్ల అమ్మకాలలో 1% నష్టం వాటిల్లుతుంది.
మొబైల్ పరికరాలు ఎక్కువగా వాడుకలోకి వస్తున్నాయి, మరియు మొబైల్ వెబ్సైట్లు, యాప్లు కూడా అదే బాటలో పయనిస్తున్నాయి. మీ పేజీ లోడ్ అవ్వడానికి 3 సెకన్ల కంటే ఎక్కువ సమయం తీసుకుంటే, మీరు మీ వినియోగదారులలో దాదాపు సగం మందిని కోల్పోతున్నారు. శోధన ఫలితాలలో మీ పేజీ లోడ్ అయ్యే వేగాన్ని గూగుల్ పరిగణనలోకి తీసుకుంటుంది: మీ పేజీ ఎంత వేగంగా లోడ్ అయితే, గూగుల్లో దాని స్థానం అంత ఉన్నతంగా ఉంటుంది.
ఆర్థిక సంస్థలలో కనెక్షన్ వేగం కూడా ముఖ్యమైనది, అక్కడ జాప్యం చాలా కీలకమైనది. 2015లో, హిబెర్నియా నెట్వర్క్స్ న్యూయార్క్ మరియు లండన్ నగరాల మధ్య లాటెన్సీని 6 మిల్లీసెకన్లు తగ్గించడానికి 400 మిలియన్ డాలర్ల కేబుల్ ప్రాజెక్ట్. లాటెన్సీలో ప్రతి మిల్లీసెకను తగ్గింపునకు 66 మిలియన్ డాలర్లు ఖర్చవుతుందని ఊహించండి!
ప్రకారం 5 Mbps కంటే ఎక్కువ కనెక్షన్ వేగం ఇకపై ఒక సాధారణ వెబ్సైట్ లోడింగ్ వేగాన్ని నేరుగా ప్రభావితం చేయదు. అయితే, కనెక్షన్ లేటెన్సీ మరియు పేజీ లోడింగ్ వేగం మధ్య ఒక సరళ సంబంధం ఉంది:
అయితే, నెట్ఫ్లిక్స్ ఒక సాధారణ ఉత్పత్తి కాదు. వినియోగదారుపై లాటెన్సీ మరియు వేగం యొక్క ప్రభావం అనేది విశ్లేషణ మరియు అభివృద్ధికి సంబంధించిన ఒక క్రియాశీలకమైన అంశం. యాప్ లోడింగ్ మరియు కంటెంట్ ఎంపిక లాటెన్సీపై ఆధారపడి ఉండగా, స్టాటిక్ ఎలిమెంట్స్ లోడ్ అవ్వడం మరియు స్ట్రీమింగ్ కూడా కనెక్షన్ వేగంపై ఆధారపడి ఉంటాయి. వినియోగదారు అనుభవాన్ని ప్రభావితం చేసే కీలక అంశాలను విశ్లేషించడం మరియు ఆప్టిమైజ్ చేయడం అనేది నెట్ఫ్లిక్స్లోని అనేక బృందాలకు ఒక క్రియాశీలకమైన అభివృద్ధి రంగం. నెట్ఫ్లిక్స్ పరికరాలు మరియు క్లౌడ్ ఇన్ఫ్రాస్ట్రక్చర్ మధ్య అభ్యర్థనల లాటెన్సీని తగ్గించడం ఈ లక్ష్యాలలో ఒకటి.
ఈ ప్రసంగంలో, నెట్ఫ్లిక్స్ మౌలిక సదుపాయాలను ఉదాహరణగా తీసుకుని, లేటెన్సీని తగ్గించడంపై ప్రత్యేకంగా దృష్టి సారిస్తాము. కార్యాచరణ సమస్యలు మరియు వైఫల్యాలను నిర్ధారించడంపై కాకుండా, ఆవిష్కరణ మరియు ఫలితాలపై దృష్టి సారిస్తూ, సంక్లిష్టమైన డిస్ట్రిబ్యూటెడ్ సిస్టమ్ల రూపకల్పన, అభివృద్ధి మరియు నిర్వహణను ఆచరణాత్మక దృక్కోణం నుండి ఎలా చేపట్టాలో పరిశీలిస్తాము.
నెట్ఫ్లిక్స్ లోపల
వేలాది విభిన్న పరికరాలు నెట్ఫ్లిక్స్ యాప్లకు మద్దతు ఇస్తాయి. వీటిని నాలుగు వేర్వేరు బృందాలు అభివృద్ధి చేశాయి, ప్రతి బృందం ప్రత్యేక క్లయింట్ వెర్షన్లను సృష్టిస్తుంది. Androidమేము iOS, TV మరియు వెబ్ బ్రౌజర్లలో వినియోగదారు అనుభవాన్ని మెరుగుపరచడానికి మరియు వ్యక్తిగతీకరించడానికి కూడా తీవ్రంగా కృషి చేస్తున్నాము. దీనిని సాధించడానికి, మేము వందలాది A/B పరీక్షలను ఏకకాలంలో నిర్వహిస్తాము.
AWS క్లౌడ్లోని వందలాది మైక్రోసర్వీస్ల ద్వారా వ్యక్తిగతీకరణకు మద్దతు లభిస్తుంది, ఇవి వ్యక్తిగతీకరించిన వినియోగదారు డేటా, అభ్యర్థనల పంపకం, టెలిమెట్రీ, బిగ్ డేటా మరియు ఎన్కోడింగ్ను అందిస్తాయి. ట్రాఫిక్ విజువలైజేషన్ ఈ విధంగా కనిపిస్తుంది:
ఎడమ వైపున ప్రవేశ స్థానం ఉంటుంది, ఆ తర్వాత వివిధ బ్యాకెండ్ బృందాల మద్దతుతో నడిచే అనేక వందల మైక్రోసర్వీస్లకు ట్రాఫిక్ పంపిణీ చేయబడుతుంది.
మా మౌలిక సదుపాయాలలో మరొక ముఖ్యమైన భాగం ఓపెన్ కనెక్ట్ CDN, ఇది వీడియో, చిత్రాలు, క్లయింట్-సైడ్ కోడ్ మొదలైన స్టాటిక్ కంటెంట్ను తుది వినియోగదారులకు అందిస్తుంది. ఈ CDN కస్టమ్ సర్వర్లపై (OCA — ఓపెన్ కనెక్ట్ అప్లయెన్స్) హోస్ట్ చేయబడుతుంది. వీటిలో ఆప్టిమైజ్ చేయబడిన FreeBSD, NGINX మరియు అనేక సేవలను నడుపుతున్న SSD మరియు HDD డ్రైవ్ల శ్రేణులు ఉంటాయి. CDN సర్వర్ వినియోగదారులకు సాధ్యమైనంత ఎక్కువ డేటాను అందించగలదని నిర్ధారించుకోవడానికి మేము హార్డ్వేర్ మరియు సాఫ్ట్వేర్ భాగాలను డిజైన్ చేసి, ఆప్టిమైజ్ చేస్తాము.
ఇంటర్నెట్ ఎక్స్ఛేంజ్ (IX) వద్ద ఈ సర్వర్ల "గోడ" ఈ విధంగా కనిపిస్తుంది:
ఇంటర్నెట్ ఎక్స్ఛేంజ్, ఇంటర్నెట్ సర్వీస్ ప్రొవైడర్లు మరియు కంటెంట్ ప్రొవైడర్లు ఇంటర్నెట్ అంతటా మరింత ప్రత్యక్ష డేటా మార్పిడి కోసం ఒకరితో ఒకరు కనెక్ట్ అవ్వడానికి వీలు కల్పిస్తుంది. మా సర్వర్లు ప్రపంచవ్యాప్తంగా సుమారు 70-80 ఇంటర్నెట్ ఎక్స్ఛేంజ్ ప్రదేశాలలో ఇన్స్టాల్ చేయబడ్డాయి, మరియు వాటి ఇన్స్టాలేషన్ మరియు నిర్వహణను మేమే స్వయంగా చూసుకుంటాము:
దీనికి అదనంగా, మేము ఇంటర్నెట్ సర్వీస్ ప్రొవైడర్లకు నేరుగా సర్వర్లను కూడా అందిస్తాము, వారు వాటిని తమ నెట్వర్క్లలో ఇన్స్టాల్ చేసుకుని, వినియోగదారుల కోసం నెట్ఫ్లిక్స్ ట్రాఫిక్ స్థానికీకరణను మరియు స్ట్రీమింగ్ నాణ్యతను మెరుగుపరుస్తారు:
క్లయింట్ల నుండి వచ్చే వీడియో అభ్యర్థనలను CDN సర్వర్లకు పంపడం, అలాగే కంటెంట్, ప్రోగ్రామ్ కోడ్, సెట్టింగ్లు మొదలైనవాటిని అప్డేట్ చేస్తూ సర్వర్లను కాన్ఫిగర్ చేయడం వంటి బాధ్యతలను ఒక AWS సేవల సమితి నిర్వహిస్తుంది. ఈ రెండవ దాని కోసం, మేము ఇంటర్నెట్ ఎక్స్ఛేంజ్ ప్రదేశాలలోని సర్వర్లను AWSకు అనుసంధానించే ఒక బ్యాక్బోన్ నెట్వర్క్ను కూడా నిర్మించాము. ఈ బ్యాక్బోన్ నెట్వర్క్ అనేది ఫైబర్-ఆప్టిక్ కేబుల్స్ మరియు రౌటర్లతో కూడిన ఒక ప్రపంచవ్యాప్త నెట్వర్క్, దీనిని మేము మా అవసరాలకు అనుగుణంగా డిజైన్ చేసి, కాన్ఫిగర్ చేసుకోగలము.
న మా CDN మౌలిక సదుపాయాలు రద్దీ సమయాల్లో ప్రపంచ ఇంటర్నెట్ ట్రాఫిక్లో సుమారు మూడింట ఒక వంతును, మరియు నెట్ఫ్లిక్స్ చాలా కాలంగా ఉన్న ఉత్తర అమెరికాలోని ట్రాఫిక్లో మూడింట ఒక వంతును అందిస్తాయి. ఇవి ఆకట్టుకునే సంఖ్యలు, కానీ నా దృష్టిలో అత్యంత అద్భుతమైన విజయాలలో ఒకటి ఏమిటంటే, ఈ మొత్తం CDN వ్యవస్థను 150 మంది కంటే తక్కువ ఉన్న బృందం అభివృద్ధి చేసి, నిర్వహిస్తోంది.
ప్రారంభంలో, CDN మౌలిక సదుపాయాలు వీడియో డేటాను అందించడం కోసం రూపొందించబడ్డాయి. అయితే, కాలక్రమేణా, AWS క్లౌడ్లోని క్లయింట్ల నుండి వచ్చే డైనమిక్ అభ్యర్థనలను ఆప్టిమైజ్ చేయడానికి కూడా దీనిని ఉపయోగించవచ్చని మేము గ్రహించాము.
ఇంటర్నెట్ వేగాన్ని పెంచడం గురించి
నెట్ఫ్లిక్స్కు ప్రస్తుతం మూడు AWS రీజియన్లు ఉన్నాయి, మరియు క్లౌడ్ రిక్వెస్ట్ లేటెన్సీ అనేది క్లయింట్ సమీప రీజియన్కు ఎంత దూరంలో ఉందనే దానిపై ఆధారపడి ఉంటుంది. స్టాటిక్ కంటెంట్ను అందించడానికి మేము అనేక CDN సర్వర్లను కూడా ఉపయోగిస్తాము. డైనమిక్ రిక్వెస్ట్లను వేగవంతం చేయడానికి ఈ ఇన్ఫ్రాస్ట్రక్చర్ను ఉపయోగించుకోవడానికి ఏదైనా మార్గం ఉందా? దురదృష్టవశాత్తు, ఈ రిక్వెస్ట్లను కాష్ చేయలేము—APIలు వ్యక్తిగతీకరించబడినవి, మరియు ప్రతి ఫలితం ప్రత్యేకమైనది.
CDN సర్వర్లో ఒక ప్రాక్సీని సృష్టించి, దాని ద్వారా ట్రాఫిక్ను మళ్లించడం ప్రారంభిద్దాం. ఇది వేగంగా ఉంటుందా?
హార్డ్వేర్
నెట్వర్క్ ప్రోటోకాల్లు ఎలా పనిచేస్తాయో సమీక్షిద్దాం. ప్రస్తుతం, చాలా ఇంటర్నెట్ ట్రాఫిక్ HTTPSను ఉపయోగిస్తుంది, ఇది TCP మరియు TLS అనే దిగువ-స్థాయి ప్రోటోకాల్లపై ఆధారపడి ఉంటుంది. ఒక క్లయింట్ సర్వర్కు కనెక్ట్ అవ్వడానికి, హ్యాండ్షేక్ చేస్తుంది. సురక్షితమైన కనెక్షన్ను ఏర్పాటు చేయడానికి, క్లయింట్ సర్వర్తో మూడుసార్లు సందేశాలను మార్పిడి చేసుకోవాలి మరియు డేటాను ప్రసారం చేయడానికి కనీసం ఇంకొకసారి అవసరం. 100 ms రౌండ్-ట్రిప్ లేటెన్సీ (RTT)తో, డేటా యొక్క మొదటి బిట్ను స్వీకరించడానికి మనకు 400 ms సమయం పడుతుంది:
మనం సర్టిఫికేట్లను ఒక CDN సర్వర్లో హోస్ట్ చేస్తే, ఆ CDN దగ్గరగా ఉన్నప్పుడు క్లయింట్ మరియు సర్వర్ మధ్య హ్యాండ్షేక్ సమయాన్ని గణనీయంగా తగ్గించవచ్చు. CDN సర్వర్కు లాటెన్సీ 30 ms అని అనుకుందాం. అప్పుడు, మొదటి బిట్ను స్వీకరించడానికి 220 ms పడుతుంది:
కానీ ప్రయోజనాలు అక్కడితో ముగియవు. ఒకసారి కనెక్షన్ ఏర్పడిన తర్వాత, TCP కంజెషన్ విండోను (ఈ కనెక్షన్ ద్వారా సమాంతరంగా ప్రసారం చేయగల సమాచారం యొక్క పరిమాణాన్ని) పెంచుతుంది. ఒకవేళ డేటా ప్యాకెట్ కోల్పోతే, క్లాసిక్ TCP ఇంప్లిమెంటేషన్లు (TCP న్యూ రెనో వంటివి) ఓపెన్ విండోను సగానికి తగ్గిస్తాయి. కంజెషన్ విండోలో పెరుగుదల, మరియు నష్టం నుండి కోలుకునే వేగం, మళ్ళీ సర్వర్కు ఉండే లేటెన్సీ (RTT) మీద ఆధారపడి ఉంటాయి. ఈ కనెక్షన్ కేవలం CDN సర్వర్కు మాత్రమే వెళితే, ఈ రికవరీ వేగంగా ఉంటుంది. ప్యాకెట్ నష్టం అనేది సర్వసాధారణంగా జరిగే విషయం, ముఖ్యంగా వైర్లెస్ నెట్వర్క్లలో.
వినియోగదారుల ట్రాఫిక్ కారణంగా, ముఖ్యంగా పీక్ అవర్స్లో ఇంటర్నెట్ బ్యాండ్విడ్త్ క్షీణించవచ్చు, ఇది రద్దీకి దారితీయవచ్చు. అయితే, కొన్ని అభ్యర్థనల కంటే మరికొన్నింటికి ప్రాధాన్యత ఇవ్వడానికి ఇంటర్నెట్కు మార్గం లేదు. ఉదాహరణకు, నెట్వర్క్ను ఓవర్లోడ్ చేసే భారీ డేటా స్ట్రీమ్ల కంటే, చిన్న, లేటెన్సీ-సెన్సిటివ్ అభ్యర్థనలకు ప్రాధాన్యత ఇవ్వడం. అయితే, మా విషయంలో, మా స్వంత బ్యాక్బోన్ నెట్వర్క్ ఉండటం వలన, CDN మరియు క్లౌడ్ మధ్య ఉన్న అభ్యర్థన మార్గంలో దీన్ని చేయడానికి మాకు వీలు కలుగుతుంది—మరియు ఇది పూర్తిగా కాన్ఫిగర్ చేయదగినది. మేము చిన్న, లేటెన్సీ-సెన్సిటివ్ ప్యాకెట్లకు ప్రాధాన్యత ఇవ్వగలము, అయితే పెద్ద డేటా స్ట్రీమ్లు కొంచెం ఆలస్యంగా వస్తాయి. CDN క్లయింట్కు ఎంత దగ్గరగా ఉంటే, సామర్థ్యం అంత ఎక్కువగా ఉంటుంది.
అప్లికేషన్-స్థాయి ప్రోటోకాల్లు (OSI స్థాయి 7) కూడా లేటెన్సీని ప్రభావితం చేస్తాయి. HTTP/2 వంటి కొత్త ప్రోటోకాల్లు, సమాంతర అభ్యర్థనల పనితీరును ఆప్టిమైజ్ చేస్తాయి. అయితే, నెట్ఫ్లిక్స్ వద్ద కొత్త ప్రోటోకాల్లకు మద్దతు ఇవ్వని పాత పరికరాలు ఉన్న క్లయింట్లు ఉన్నారు. అన్ని క్లయింట్లను అప్డేట్ చేయడం లేదా ఉత్తమంగా కాన్ఫిగర్ చేయడం సాధ్యం కాదు. అదే సమయంలో, CDN ప్రాక్సీ మరియు క్లౌడ్కు పూర్తి నియంత్రణ మరియు కొత్త, ఉత్తమమైన ప్రోటోకాల్లు మరియు సెట్టింగ్లను ఉపయోగించే సామర్థ్యం ఉంటుంది. పాత ప్రోటోకాల్లతో కూడిన అసమర్థమైన భాగం క్లయింట్ మరియు CDN సర్వర్ మధ్య మాత్రమే పనిచేస్తుంది. అంతేకాకుండా, CDN మరియు క్లౌడ్ మధ్య ఇప్పటికే ఉన్న కనెక్షన్పై మనం అభ్యర్థనలను మల్టీప్లెక్స్ చేయవచ్చు, తద్వారా TCP స్థాయిలో కనెక్షన్ వినియోగాన్ని మెరుగుపరచవచ్చు:
మేము కొలుస్తాము
సిద్ధాంతం మెరుగుదలలను వాగ్దానం చేస్తున్నప్పటికీ, మేము వెంటనే ఉత్పత్తిలోకి వెళ్ళడానికి తొందరపడము. దానికి బదులుగా, ఈ ఆలోచన ఆచరణలో పనిచేస్తుందని మనం మొదట నిరూపించాలి. ఇది చేయడానికి, మనం అనేక ప్రశ్నలకు సమాధానం ఇవ్వాలి:
- వేగంప్రాక్సీ వేగంగా ఉంటుందా?
- విశ్వసనీయతఇది మరింత తరచుగా పాడవుతుందా?
- సంక్లిష్టతఅప్లికేషన్లతో ఎలా అనుసంధానించాలి?
- ఖర్చుఅదనపు మౌలిక సదుపాయాలను ఏర్పాటు చేయడానికి ఎంత ఖర్చు అవుతుంది?
మొదటి అంశాన్ని అంచనా వేయడంలో మన విధానాన్ని నిశితంగా పరిశీలిద్దాం. మిగిలినవి కూడా ఇదే పద్ధతిలో విశ్లేషించబడతాయి.
క్వెరీ వేగాన్ని విశ్లేషించడానికి, డెవలప్మెంట్ సమయాన్ని వృధా చేయకుండా లేదా ప్రొడక్షన్కు అంతరాయం కలిగించకుండా, వినియోగదారులందరి డేటాను పొందాలనుకుంటున్నాము. దీనికి అనేక విధానాలు ఉన్నాయి:
- RUM, లేదా పాసివ్ క్వెరీ మెజర్మెంట్, ప్రస్తుత యూజర్ రిక్వెస్ట్ల ఎగ్జిక్యూషన్ సమయాన్ని కొలుస్తుంది మరియు పూర్తి యూజర్ కవరేజీని నిర్ధారిస్తుంది. దీనిలోని ప్రతికూలత ఏమిటంటే, సర్వర్ మరియు క్లయింట్పై వేర్వేరు రిక్వెస్ట్ సైజులు మరియు ప్రాసెసింగ్ సమయాలు వంటి అనేక కారణాల వల్ల సిగ్నల్ అంత స్థిరంగా ఉండదు. అంతేకాకుండా, ప్రొడక్షన్పై ప్రభావం చూపకుండా కొత్త కాన్ఫిగరేషన్ను పరీక్షించడం అసాధ్యం.
- ల్యాబ్ పరీక్షలు. క్లయింట్లను అనుకరించడానికి మేము ప్రత్యేక సర్వర్లు మరియు మౌలిక సదుపాయాలను ఉపయోగిస్తాము. అవసరమైన పరీక్షలను నిర్వహించడానికి మేము వాటిని ఉపయోగిస్తాము. ఇది కొలత ఫలితాలను పూర్తిగా నియంత్రించడానికి మరియు స్పష్టమైన సిగ్నల్ను నిర్ధారించడానికి మాకు వీలు కల్పిస్తుంది. అయితే, ఇది పూర్తి పరికర కవరేజీకి మరియు వినియోగదారు స్థానాలకు హామీ ఇవ్వదు (ముఖ్యంగా వేలాది పరికర నమూనాలకు మద్దతు ఇచ్చే గ్లోబల్ సేవతో).
రెండు పద్ధతుల ప్రయోజనాలను మనం ఎలా ఏకీకృతం చేయగలం?
మా బృందం ఒక పరిష్కారాన్ని కనుగొంది. మేము ఒక చిన్న కోడ్ ముక్కను—ఒక ప్రోబ్ను—వ్రాసి, దానిని మా యాప్లో పొందుపరిచాము. ప్రోబ్లు మా పరికరాల నుండి పూర్తిగా నియంత్రిత నెట్వర్క్ పరీక్షలను నిర్వహించడానికి మాకు వీలు కల్పిస్తాయి. ఇది ఈ విధంగా పనిచేస్తుంది:
- యాప్ను డౌన్లోడ్ చేసి, ప్రారంభ కార్యాచరణను పూర్తి చేసిన కొద్దిసేపటికే, మేము మా ట్రయల్స్ను ప్రారంభిస్తాము.
- క్లయింట్ సర్వర్కు ఒక అభ్యర్థనను పంపి, ఒక పరీక్షా "రెసిపీ"ని అందుకుంటుంది. ఆ రెసిపీ అనేది, HTTP(s) అభ్యర్థన చేయవలసిన URLల జాబితా. ఆ రెసిపీ అభ్యర్థన పారామితులను కూడా కాన్ఫిగర్ చేస్తుంది: అభ్యర్థనల మధ్య ఆలస్యం, అభ్యర్థించిన డేటా పరిమాణం, HTTP(s) హెడర్లు మొదలైనవి. మనం అనేక విభిన్న రెసిపీలను సమాంతరంగా పరీక్షించవచ్చు—ఒక కాన్ఫిగరేషన్ అభ్యర్థన చేసినప్పుడు, ఏ రెసిపీని తిరిగి ఇవ్వాలో మనం యాదృచ్ఛికంగా నిర్ణయిస్తాము.
- క్లయింట్లో చురుకైన నెట్వర్క్ వనరుల వినియోగానికి ఆటంకం కలగకుండా ఉండేలా ప్రోబ్ ప్రయోగ సమయం ఎంపిక చేయబడుతుంది. ముఖ్యంగా, క్లయింట్ నిష్క్రియంగా ఉన్న సమయం ఎంపిక చేయబడుతుంది.
- రెసిపీని స్వీకరించిన తర్వాత, క్లయింట్ ప్రతి URLకి సమాంతరంగా అభ్యర్థనలు చేస్తుంది. ప్రతి URLకి చేసే అభ్యర్థనను పునరావృతం చేయవచ్చు—దీనిని "పల్సెస్" అంటారు. మొదటి పల్స్ సమయంలో, కనెక్షన్ను ఏర్పాటు చేయడానికి మరియు డేటాను డౌన్లోడ్ చేయడానికి ఎంత సమయం పడుతుందో మేము కొలుస్తాము. రెండవ పల్స్ సమయంలో, ఏర్పడిన కనెక్షన్ ద్వారా డేటాను డౌన్లోడ్ చేయడానికి పట్టే సమయాన్ని మేము కొలుస్తాము. మూడవ పల్స్కు ముందు, మేము ఒక ఆలస్యాన్ని ప్రవేశపెట్టి, రెండవ కనెక్షన్ను ఏర్పాటు చేసే వేగాన్ని కొలవవచ్చు, మొదలైనవి.
పరీక్ష సమయంలో, పరికరం సాధించగల అన్ని పారామితులను మేము కొలుస్తాము:
- DNS ప్రశ్న సమయం;
- TCP కనెక్షన్ ఏర్పాటు సమయం;
- TLS కనెక్షన్ ఏర్పాటు సమయం;
- మొదటి బైట్ డేటాను స్వీకరించడానికి పట్టే సమయం;
- మొత్తం లోడింగ్ సమయం;
- స్థితి ఫలిత కోడ్.
- అన్ని పల్స్లు పూర్తయిన తర్వాత, విశ్లేషణ కోసం నమూనా అన్ని కొలతల ఫలితాలను డౌన్లోడ్ చేసుకుంటుంది.
క్లయింట్-సైడ్ లాజిక్, సర్వర్-సైడ్ డేటా ప్రాసెసింగ్ మరియు సమాంతర క్వెరీ కొలతపై కనీస ఆధారపడటం అనేవి కీలకమైన అంశాలు. ఇది క్వెరీ పనితీరును ప్రభావితం చేసే వివిధ కారకాల ప్రభావాన్ని వేరుచేసి పరీక్షించడానికి, వాటిని ఒకే రెసిపీలో మార్చడానికి మరియు నిజమైన క్లయింట్ల నుండి ఫలితాలను పొందడానికి మనకు వీలు కల్పిస్తుంది.
ఈ మౌలిక సదుపాయం కేవలం క్వెరీ పనితీరు విశ్లేషణకే కాకుండా మరెన్నో విషయాలకు ఉపయోగకరంగా ఉందని నిరూపించబడింది. ప్రస్తుతం మా వద్ద 14 యాక్టివ్ రెసిపీలు, సెకనుకు 6000కు పైగా శాంపిల్స్ ఉన్నాయి. మేము ప్రపంచంలోని నలుమూలల నుండి డేటాను స్వీకరిస్తున్నాము మరియు అన్ని పరికరాలకు పూర్తి కవరేజీని కలిగి ఉన్నాము. ఒకవేళ నెట్ఫ్లిక్స్ ఇలాంటి సేవను ఇతర సంస్థల నుండి కొనుగోలు చేస్తే, దానికి సంవత్సరానికి లక్షల డాలర్లు ఖర్చవుతుంది, పైగా కవరేజీ కూడా చాలా తక్కువగా ఉంటుంది.
సిద్ధాంతాన్ని పరీక్షించడం: ఒక నమూనా
ఈ సిస్టమ్తో, మేము అభ్యర్థన జాప్యం పరంగా CDN ప్రాక్సీ యొక్క సమర్థతను అంచనా వేయగలిగాము. ఇప్పుడు మనం చేయవలసింది:
- ప్రాక్సీ ప్రోటోటైప్ను సృష్టించండి;
- ప్రోటోటైప్ను CDNలో హోస్ట్ చేయండి;
- ఒక నిర్దిష్ట CDN సర్వర్లోని ప్రాక్సీలకు క్లయింట్లను ఎలా మళ్లించాలో నిర్ణయించడం;
- ప్రాక్సీ లేకుండా AWS అభ్యర్థనలతో పనితీరును పోల్చండి.
ప్రతిపాదిత పరిష్కారం యొక్క ప్రభావాన్ని వీలైనంత త్వరగా అంచనా వేయడమే లక్ష్యం. దాని మంచి నెట్వర్కింగ్ లైబ్రరీల కారణంగా, మేము ప్రోటోటైప్ అమలు కోసం Go భాషను ఎంచుకున్నాము. డిపెండెన్సీలను తగ్గించడానికి మరియు ఇంటిగ్రేషన్ను సులభతరం చేయడానికి, మేము ప్రతి CDN సర్వర్లో ప్రాక్సీ ప్రోటోటైప్ను స్టాటిక్ బైనరీగా ఇన్స్టాల్ చేసాము. ప్రారంభ అమలులో, మేము HTTP/2 కనెక్షన్ పూలింగ్ మరియు రిక్వెస్ట్ మల్టీప్లెక్సింగ్ కోసం చిన్న మార్పులతో, వీలైనంత వరకు ప్రామాణిక కాంపోనెంట్లను ఉపయోగించాము.
AWS రీజియన్ల మధ్య లోడ్ బ్యాలెన్సింగ్ కోసం, మేము క్లయింట్ లోడ్ బ్యాలెన్సింగ్ కోసం ఉపయోగించే అదే జియోగ్రాఫిక్ DNS డేటాబేస్ను ఉపయోగించాము. క్లయింట్ కోసం ఒక CDN సర్వర్ను ఎంచుకోవడానికి, మేము ఇంటర్నెట్ ఎక్స్ఛేంజ్ (IX)లోని సర్వర్ల కోసం TCP ఎనీకాస్ట్ను ఉపయోగిస్తాము. ఈ సందర్భంలో, మేము అన్ని CDN సర్వర్ల కోసం ఒకే IP చిరునామాను ఉపయోగిస్తాము, మరియు అతి తక్కువ IP హాప్లు ఉన్న CDN సర్వర్కు క్లయింట్ మళ్ళించబడుతుంది. ఇంటర్నెట్ సర్వీస్ ప్రొవైడర్లు (ISPలు) హోస్ట్ చేసే CDN సర్వర్ల కోసం, TCP ఎనీకాస్ట్ను కాన్ఫిగర్ చేయడానికి రౌటర్పై మాకు నియంత్రణ ఉండదు, కాబట్టి మేము ఉపయోగిస్తాము ఇది వీడియో స్ట్రీమింగ్ కోసం క్లయింట్లను ఇంటర్నెట్ సర్వీస్ ప్రొవైడర్ల వద్దకు మళ్లిస్తుంది.
కాబట్టి, మనకు మూడు రకాల అభ్యర్థన మార్గాలు ఉన్నాయి: పబ్లిక్ ఇంటర్నెట్ ద్వారా క్లౌడ్కు, IXలోని CDN సర్వర్ ద్వారా, లేదా ఇంటర్నెట్ ప్రొవైడర్ హోస్ట్ చేసిన CDN సర్వర్ ద్వారా. ఏ మార్గం ఉత్తమమైనదో మరియు ప్రొడక్షన్కు అభ్యర్థనలు ఎలా రూట్ చేయబడతాయో దానితో పోల్చి ప్రాక్సీని ఉపయోగించడం వల్ల కలిగే ప్రయోజనం ఏమిటో అర్థం చేసుకోవడమే మా లక్ష్యం. దీన్ని చేయడానికి, మేము ఈ క్రింది విధంగా ఒక ప్రోబింగ్ సిస్టమ్ను ఉపయోగిస్తాము:
ప్రతి మార్గం ఒక ప్రత్యేక లక్ష్యంగా మారుతుంది, మరియు ఫలితంగా వచ్చే సమయాన్ని మేము విశ్లేషిస్తాము. విశ్లేషణ కోసం, మేము ప్రాక్సీ ఫలితాలను ఒకే సమూహంగా కలుపుతాము (IX మరియు ISP ప్రాక్సీల మధ్య ఉత్తమ సమయాన్ని ఎంచుకుని) మరియు వాటిని ప్రాక్సీ లేని క్లౌడ్ అభ్యర్థనల సమయంతో పోలుస్తాము:
మీరు చూడగలిగినట్లుగా, ఫలితాలు మిశ్రమంగా ఉన్నాయి—చాలా సందర్భాలలో, ప్రాక్సీ మంచి వేగవంతం అందించింది, కానీ అదే సమయంలో, పరిస్థితి గణనీయంగా అధ్వాన్నంగా ఉన్న క్లయింట్లు కూడా చాలా మంది ఉన్నారు.
చివరికి, మేము అనేక ముఖ్యమైన పనులు చేశాము:
- మేము CDN ప్రాక్సీ ద్వారా క్లయింట్ల నుండి క్లౌడ్కు వచ్చే అభ్యర్థనల అంచనా పనితీరును అంచనా వేశాము.
- మేము నిజమైన క్లయింట్ల నుండి, అన్ని రకాల పరికరాల నుండి డేటాను స్వీకరించాము.
- ఆ సిద్ధాంతం 100% ధృవీకరించబడలేదని మరియు CDN ప్రాక్సీతో కూడిన ప్రారంభ ప్రతిపాదన మాకు సరిపోదని మేము గ్రహించాము.
- మేము ఎలాంటి రిస్కులు తీసుకోలేదు - క్లయింట్ల కోసం ప్రొడక్షన్ కాన్ఫిగరేషన్లను మార్చలేదు.
- ఏమీ పగలలేదు.
ప్రోటోటైప్ 2.0
కాబట్టి, మళ్ళీ మొదటి నుండి ప్రారంభించి, ఈ ప్రక్రియను పునరావృతం చేయాలి.
దీని ఉద్దేశ్యం ఏమిటంటే, 100% ప్రాక్సీకి బదులుగా, మనం ప్రతి క్లయింట్ కోసం అత్యంత వేగవంతమైన మార్గాన్ని నిర్ధారించి, అభ్యర్థనలను అటువైపు మళ్లిస్తాము—అంటే, మనం క్లయింట్ స్టీరింగ్ అని పిలవబడే దానిని చేస్తాము.
దీనిని ఎలా అమలు చేయవచ్చు? ఆ సర్వర్కు కనెక్ట్ అవ్వడమే లక్ష్యం కాబట్టి, మనం సర్వర్-సైడ్ లాజిక్ను ఉపయోగించలేము. మనం దీన్ని క్లయింట్లో ఏదో ఒక విధంగా చేయాలి. విస్తృత శ్రేణి క్లయింట్ ప్లాట్ఫారమ్లతో ఇంటిగ్రేషన్ సమస్యను ఎదుర్కోవలసిన అవసరం లేకుండా, వీలైనంత తక్కువ సంక్లిష్టమైన లాజిక్తో దీన్ని చేయడం ఉత్తమం.
దీనికి సమాధానం DNS ను ఉపయోగించడం. మా విషయంలో, మాకు మా స్వంత DNS మౌలిక సదుపాయాలు ఉన్నాయి, మరియు మా సర్వర్లు ప్రామాణికంగా ఉండే ఒక డొమైన్ జోన్ను మేము ఏర్పాటు చేయవచ్చు. ఇది ఈ విధంగా పనిచేస్తుంది:
- క్లయింట్ api.netflix.xom వంటి హోస్ట్ను ఉపయోగించి DNS సర్వర్కు అభ్యర్థనను పంపుతుంది.
- అభ్యర్థన మా DNS సర్వర్కు పంపబడుతుంది.
- ఈ క్లయింట్ కోసం ఏ మార్గం అత్యంత వేగవంతమైనదో DNS సర్వర్కు తెలుసు మరియు అది దానికి అనుగుణమైన IP చిరునామాను జారీ చేస్తుంది.
ఈ పరిష్కారానికి ఒక అదనపు సంక్లిష్టత ఉంది: అధికారిక DNS ప్రొవైడర్లు క్లయింట్ యొక్క IP చిరునామాను చూడలేవు మరియు క్లయింట్ ఉపయోగిస్తున్న రికర్సివ్ రిజాల్వర్ యొక్క IP చిరునామాను మాత్రమే చదవగలవు.
ఫలితంగా, మన అధికారిక పరిష్కారి ఒక వ్యక్తిగత క్లయింట్ కోసం కాకుండా, పునరావృత పరిష్కారి ఆధారంగా క్లయింట్ల సమూహం కోసం నిర్ణయం తీసుకోవాలి.
దీన్ని పరిష్కరించడానికి, మేము అవే ప్రోబ్లను ఉపయోగించి, ప్రతి రికర్సివ్ రిజాల్వర్ కోసం క్లయింట్ల నుండి కొలత ఫలితాలను సమీకరించి, ఈ సమూహాన్ని ఎక్కడికి రూట్ చేయాలో నిర్ణయిస్తాము—TCP ఎనీకాస్ట్ ఉపయోగించి IX ప్రాక్సీ ద్వారా, ISP ప్రాక్సీ ద్వారా, లేదా నేరుగా క్లౌడ్కు.
మనకు ఈ క్రింది వ్యవస్థ లభిస్తుంది:
ఫలితంగా ఏర్పడిన DNS స్టీరింగ్ మోడల్, క్లయింట్ల నుండి క్లౌడ్కు ఉన్న కనెక్షన్ వేగాల చారిత్రక పరిశీలనల ఆధారంగా క్లయింట్ రూటింగ్ను అనుమతిస్తుంది.
మళ్ళీ, ప్రశ్న ఏమిటంటే: ఈ విధానం ఎంత ప్రభావవంతంగా ఉంటుంది? దీనికి సమాధానం ఇవ్వడానికి, మేము మళ్ళీ మా ప్రోబ్ సిస్టమ్ను ఉపయోగిస్తాము. అందువల్ల, మేము ఒక పునఃపరిశీలన కాన్ఫిగరేషన్ను ఏర్పాటు చేస్తాము, దీనిలో ఒక టార్గెట్ DNS స్టీరింగ్ దిశను అనుసరిస్తుంది, మరియు మరొకటి నేరుగా క్లౌడ్కు వెళుతుంది (ప్రస్తుత ఉత్పత్తి).
చివరగా, మేము ఫలితాలను పోల్చి సామర్థ్య అంచనాను పొందుతాము:
చివరికి, మేము కొన్ని ముఖ్యమైన విషయాలు నేర్చుకున్నాము:
- మేము DNS స్టీరింగ్ను ఉపయోగించి క్లయింట్ల నుండి క్లౌడ్కు వచ్చే అభ్యర్థనల అంచనా పనితీరును అంచనా వేశాము.
- మేము నిజమైన క్లయింట్ల నుండి, అన్ని రకాల పరికరాల నుండి డేటాను స్వీకరించాము.
- ప్రతిపాదించిన ఆలోచన యొక్క సమర్థత నిరూపించబడింది.
- మేము ఎలాంటి రిస్కులు తీసుకోలేదు - క్లయింట్ల కోసం ప్రొడక్షన్ కాన్ఫిగరేషన్లను మార్చలేదు.
- ఏమీ పగలలేదు.
ఇప్పుడు అసలైన కష్టమైన పని – ఉత్పత్తిని ప్రారంభించడం.
సులభమైన భాగం ఇప్పుడు పూర్తయింది—మన దగ్గర పనిచేసే ప్రోటోటైప్ ఉంది. ఇప్పుడు కష్టమైన భాగం వస్తుంది: నెట్ఫ్లిక్స్ ట్రాఫిక్ మొత్తానికి ఈ పరిష్కారాన్ని ప్రారంభించడం, దానిని 150 కోట్ల మంది వినియోగదారులకు, వేలాది పరికరాలకు, వందలాది మైక్రోసర్వీస్లకు, మరియు నిరంతరం మారుతున్న ఉత్పత్తి మరియు మౌలిక సదుపాయాలకు విస్తరించడం. నెట్ఫ్లిక్స్ సర్వర్లు సెకనుకు లక్షల కొద్దీ అభ్యర్థనలను స్వీకరిస్తాయి, మరియు ఒక అజాగ్రత్త చర్యతో ఈ సేవను దెబ్బతీయడం చాలా సులభం. అదే సమయంలో, నిరంతరం మరియు అత్యంత అనుచితమైన సమయాల్లో విషయాలు మారుతూ, విచ్ఛిన్నమయ్యే ఇంటర్నెట్లో, మేము వేలాది CDN సర్వర్ల ద్వారా ట్రాఫిక్ను డైనమిక్గా మళ్లించాలనుకుంటున్నాము.
మరియు వీటన్నిటితో పాటు, ఈ బృందంలో సిస్టమ్ యొక్క అభివృద్ధి, అమలు మరియు పూర్తి మద్దతుకు బాధ్యత వహించే ముగ్గురు ఇంజనీర్లు ఉన్నారు.
అందువల్ల, మనం ప్రశాంతమైన, ఆరోగ్యకరమైన నిద్ర గురించి మాట్లాడటం కొనసాగిస్తాము.
సపోర్ట్పై మన సమయాన్నంతా వెచ్చించకుండా అభివృద్ధిని ఎలా కొనసాగించగలం? మా విధానం మూడు సూత్రాలపై ఆధారపడి ఉంటుంది:
- మేము విచ్ఛిన్నాల సంభావ్య స్థాయిని (విస్ఫోటన వ్యాసార్థం) తగ్గిస్తాము.
- మనం ఆశ్చర్యాలకు సిద్ధపడతాము—పరీక్షలు చేసినా, వ్యక్తిగత అనుభవం ఉన్నా కూడా ఏదో ఒకటి పాడవుతుందని ఊహిస్తాము.
- గ్రేస్ఫుల్ డిగ్రేడేషన్ - ఏదైనా పాడైతే, అది అత్యంత సమర్థవంతమైన పద్ధతిలో కాకపోయినా, దానంతట అదే సరిచేయబడాలి.
మా విషయంలో, ఈ విధానం సిస్టమ్ సపోర్ట్ను గణనీయంగా సులభతరం చేసే ఒక సరళమైన మరియు సమర్థవంతమైన పరిష్కారాన్ని అందించింది. కనెక్షన్ సమస్యల వల్ల కలిగే నెట్వర్క్ రిక్వెస్ట్ ఎర్రర్లను పర్యవేక్షించడానికి క్లయింట్కు ఒక చిన్న కోడ్ను జోడించవచ్చని మేము గ్రహించాము. నెట్వర్క్ ఎర్రర్లు సంభవించినప్పుడు, మేము నేరుగా క్లౌడ్కు తిరిగి వెళ్తాము. ఈ పరిష్కారానికి క్లయింట్ బృందాల నుండి కనీస ప్రయత్నం అవసరం, కానీ ఇది మాకు ఊహించని వైఫల్యాలు మరియు ఆశ్చర్యాల ప్రమాదాన్ని గణనీయంగా తగ్గిస్తుంది.
అయితే, ప్రత్యామ్నాయం ఉన్నప్పటికీ, మేము అభివృద్ధి సమయంలో కఠినమైన క్రమశిక్షణను పాటిస్తాము:
- నమూనా పరీక్ష.
- A/B టెస్టింగ్ లేదా కానరీలు.
- దశలవారీగా అమలు.
పరీక్షించే విధానం వివరించబడింది: మార్పులు మొదట అనుకూలీకరించిన రెసిపీని ఉపయోగించి పరీక్షించబడతాయి.
కానరీ టెస్టింగ్ కోసం, మార్పులకు ముందు మరియు తర్వాత సిస్టమ్ ఎలా పనిచేస్తుందో పోల్చడానికి మాకు పోల్చదగిన సర్వర్ల జతలు అవసరం. దీన్ని చేయడానికి, మేము పోల్చదగిన ట్రాఫిక్ను పొందే మా అనేక CDN సైట్ల నుండి సర్వర్ల జతలను ఎంచుకుంటాము:
ఆ తర్వాత మేము మార్పులతో కూడిన బిల్డ్ను కానరీ సర్వర్లకు డిప్లాయ్ చేస్తాము. ఫలితాలను మూల్యాంకనం చేయడానికి, మేము కంట్రోల్ సర్వర్ల నమూనాతో సుమారు 100-150 మెట్రిక్లను పోల్చే ఒక సిస్టమ్ను నడుపుతాము:
కానరీ టెస్టింగ్ విజయవంతమైతే, మేము అప్డేట్ను దశలవారీగా, క్రమంగా విడుదల చేస్తాము. మేము ప్రతి సైట్లోని సర్వర్లను ఒకేసారి అప్డేట్ చేయము—వేర్వేరు ప్రదేశాలలో ఉన్న అంతే సంఖ్యలో సర్వర్లను కోల్పోవడం కంటే, ఒక సమస్య కారణంగా మొత్తం సైట్ను కోల్పోవడం వినియోగదారు సేవపై మరింత గణనీయమైన ప్రభావాన్ని చూపుతుంది.
మొత్తం మీద, ఈ విధానం యొక్క సమర్థత మరియు భద్రత సేకరించిన మెట్రిక్ల పరిమాణం మరియు నాణ్యతపై ఆధారపడి ఉంటుంది. మా క్వెరీ యాక్సిలరేషన్ సిస్టమ్ కోసం, మేము సాధ్యమయ్యే అన్ని కాంపోనెంట్ల నుండి మెట్రిక్లను సేకరిస్తాము:
- క్లయింట్ల నుండి - సెషన్లు మరియు అభ్యర్థనల సంఖ్య, ఫాల్బ్యాక్ రేట్లు;
- ప్రాక్సీ - అభ్యర్థనల సంఖ్య మరియు సమయం గురించిన గణాంకాలు;
- DNS - ప్రశ్నల సంఖ్య మరియు ఫలితాలు;
- క్లౌడ్ ఎడ్జ్ — క్లౌడ్లో అభ్యర్థనలను ప్రాసెస్ చేయడానికి పట్టే సంఖ్య మరియు సమయం.
ఇవన్నీ ఒకే పైప్లైన్లోకి సేకరించబడతాయి, మరియు అవసరాలను బట్టి, ఏ మెట్రిక్లను రియల్-టైమ్ అనలిటిక్స్కు పంపాలి, మరియు మరింత వివరణాత్మక నిర్ధారణల కోసం ఏవి ఎలాస్టిక్సెర్చ్ లేదా బిగ్ డేటాకు పంపాలి అని మేము నిర్ణయిస్తాము.
మేము పర్యవేక్షిస్తున్నాము
మా విషయంలో, మేము క్లయింట్ మరియు సర్వర్ మధ్య ఉన్న కీలకమైన అభ్యర్థన మార్గంలో మార్పులు చేస్తాము. క్లయింట్, సర్వర్ మరియు ఇంటర్నెట్లో ఉండే విభిన్న భాగాల సంఖ్య అపారమైనది. డజన్ల కొద్దీ బృందాల కృషి మరియు పర్యావరణ వ్యవస్థలోని సహజ మార్పుల కారణంగా క్లయింట్ మరియు సర్వర్లలో మార్పులు నిరంతరం జరుగుతూ ఉంటాయి. మేము మధ్యలో ఉంటాము—సమస్యలను నిర్ధారించేటప్పుడు, మేము కూడా పాలుపంచుకునే అవకాశం ఎక్కువగా ఉంటుంది. అందువల్ల, సమస్యలను త్వరగా గుర్తించడానికి, కొలమానాలను ఎలా నిర్వచించాలో, సేకరించాలో మరియు విశ్లేషించాలో మాకు స్పష్టమైన అవగాహన అవసరం.
ఆదర్శవంతంగా, అన్ని రకాల మెట్రిక్లు మరియు ఫిల్టర్లకు నిజ సమయంలో పూర్తి యాక్సెస్ ఉండాలి. కానీ మెట్రిక్లు చాలా ఎక్కువగా ఉండటం వల్ల, ఖర్చు సమస్య తలెత్తుతుంది. మన విషయంలో, మెట్రిక్లను మరియు డెవలప్మెంట్ టూల్స్ను ఈ క్రింది విధంగా వేరు చేస్తాము:
సమస్యలను గుర్తించి, పరిష్కరించడానికి, మేము మా స్వంత రియల్-టైమ్ ఓపెన్-సోర్స్ సిస్టమ్ను ఉపయోగిస్తాము. и — విజువలైజేషన్ కోసం. ఇది సమీకరించిన మెట్రిక్లను మెమరీలో నిల్వ చేస్తుంది, నమ్మదగినది మరియు హెచ్చరిక వ్యవస్థతో అనుసంధానించబడుతుంది. స్థానికీకరణ మరియు నిర్ధారణల కోసం, మాకు ఎలాస్టిక్సెర్చ్ మరియు కిబానా నుండి లాగ్లకు యాక్సెస్ ఉంది. గణాంక విశ్లేషణ మరియు మోడలింగ్ కోసం, మేము టాబ్లోలో బిగ్ డేటా మరియు విజువలైజేషన్ను ఉపయోగిస్తాము.
ఈ విధానం చాలా సంక్లిష్టంగా అనిపిస్తుంది. అయినప్పటికీ, కొలమానాలు మరియు సాధనాలను శ్రేణీకృత పద్ధతిలో వ్యవస్థీకరించడం ద్వారా, మనం ఒక సమస్యను త్వరగా విశ్లేషించి, దాని రకాన్ని నిర్ధారించి, ఆపై వివరణాత్మక కొలమానాలలోకి లోతుగా వెళ్లవచ్చు. ఒక సమస్య యొక్క మూలాన్ని గుర్తించడానికి సాధారణంగా మనకు 1-2 నిమిషాలు పడుతుంది. ఆ తర్వాత, దానిని నిర్ధారించడానికి మేము ఒక నిర్దిష్ట బృందంతో కలిసి పనిచేస్తాము, దీనికి పదుల నిమిషాల నుండి చాలా గంటల వరకు సమయం పట్టవచ్చు.
డయాగ్నొస్టిక్స్ త్వరగా నిర్వహించినప్పటికీ, అవి తరచుగా జరగాలని మేము కోరుకోవడం లేదు. ఆదర్శవంతంగా, సేవపై గణనీయమైన ప్రభావం ఉన్నప్పుడు మాత్రమే మేము క్లిష్టమైన హెచ్చరికను అందుకుంటాము. మా అభ్యర్థన వేగవంతం చేసే వ్యవస్థ కోసం, మాకు కేవలం రెండు హెచ్చరికలు ఉన్నాయి, అవి ఈ క్రింది విధంగా తెలియజేస్తాయి:
- క్లయింట్ ఫాల్బ్యాక్ శాతం – కస్టమర్ ప్రవర్తన యొక్క అంచనా;
- ప్రోబ్ లోపాల శాతం - నెట్వర్క్ కాంపోనెంట్ స్థిరత్వ డేటా.
ఈ కీలక హెచ్చరికలు, సిస్టమ్ అధికశాతం వినియోగదారులకు పని చేస్తుందో లేదో పర్యవేక్షిస్తాయి. అభ్యర్థన వేగవంతం (రిక్వెస్ట్ యాక్సిలరేషన్) పొందలేకపోయినప్పుడు, ఎంత మంది క్లయింట్లు ఫాల్బ్యాక్ ఎంపికను ఉపయోగించారో మేము పర్యవేక్షిస్తాము. సిస్టమ్లో భారీ సంఖ్యలో మార్పులు జరుగుతున్నప్పటికీ, మాకు వారానికి సగటున ఒక కీలక హెచ్చరిక కంటే తక్కువగా వస్తుంది. ఇది ఎందుకు సరిపోతుంది?
- ఒకవేళ మా ప్రాక్సీ పని చేయకపోతే, క్లయింట్ ఫాల్బ్యాక్ ఉంటుంది.
- సమస్యలకు స్పందించే ఆటోమేటిక్ స్టీరింగ్ సిస్టమ్ ఉంది.
రెండవ దాని గురించి మరింత వివరంగా మాట్లాడుకుందాం. మా ప్రోబింగ్ సిస్టమ్ మరియు క్లౌడ్కు క్లయింట్ అభ్యర్థనల కోసం సరైన మార్గాన్ని స్వయంచాలకంగా నిర్ణయించే సిస్టమ్, కొన్ని సమస్యలను స్వయంచాలకంగా పరిష్కరించడానికి మాకు వీలు కల్పిస్తాయి.
మన ప్రోబ్ కాన్ఫిగరేషన్ మరియు మూడు వర్గాల మార్గాల వద్దకు తిరిగి వెళ్దాం. డౌన్లోడ్ సమయంతో పాటు, మనం డెలివరీని కూడా చూడవచ్చు. ఒకవేళ డేటా డౌన్లోడ్ విఫలమైతే, వివిధ మార్గాల ఫలితాలను చూడటం ద్వారా, ఎక్కడ మరియు ఏమి తప్పు జరిగిందో మనం నిర్ధారించవచ్చు మరియు రిక్వెస్ట్ మార్గాన్ని మార్చడం ద్వారా దాన్ని స్వయంచాలకంగా సరిచేయగలమో లేదో కూడా తెలుసుకోవచ్చు.
ఉదాహరణలు:
ఈ ప్రక్రియను స్వయంచాలకం చేయవచ్చు. దీనిని స్టీరింగ్ సిస్టమ్లో పొందుపరచండి. మరియు పనితీరు, విశ్వసనీయత సమస్యలకు ప్రతిస్పందించేలా దీనికి శిక్షణ ఇవ్వండి. ఏదైనా సమస్య మొదలైతే, మెరుగైన ప్రత్యామ్నాయం ఉంటే ప్రతిస్పందించండి. క్లయింట్-సైడ్ ఫాల్బ్యాక్ ఉన్నందున, తక్షణ ప్రతిస్పందన అంత కీలకం కాదు.
అందువల్ల, సిస్టమ్ సపోర్ట్ సూత్రాలను ఈ క్రింది విధంగా రూపొందించవచ్చు:
- మేము వైఫల్యాల స్థాయిని తగ్గిస్తాము;
- మేము కొలమానాలను సేకరిస్తాము;
- మేము చేయగలిగితే, పాడైన వాటిని స్వయంచాలకంగా బాగుచేస్తాము;
- అది చేయలేకపోతే, మేము తెలియజేస్తాము;
- త్వరిత ప్రతిస్పందన కోసం మేము డాష్బోర్డ్లు మరియు ట్రయేజ్ టూల్సెట్పై పని చేస్తున్నాము.
నేర్చుకున్న పాఠాలు
ఒక ప్రోటోటైప్ను రాయడానికి ఎక్కువ సమయం పట్టదు. మా విషయంలో, అది కేవలం నాలుగు నెలల్లోనే సిద్ధమైంది. దానివల్ల మేము కొత్త కొలమానాలను పొందగలిగాము, మరియు అభివృద్ధి ప్రారంభమైన పది నెలల తర్వాత, మా మొదటి ప్రొడక్షన్ ట్రాఫిక్ను అందుకున్నాము. అప్పుడు శ్రమతో కూడుకున్న మరియు చాలా క్లిష్టమైన పని మొదలైంది: క్రమంగా సిస్టమ్ను ఉత్పత్తిగా మార్చడం మరియు స్కేల్ చేయడం, ప్రధాన ట్రాఫిక్ను తరలించడం, మరియు తప్పుల నుండి నేర్చుకోవడం. అయితే, ఈ సమర్థవంతమైన ప్రక్రియ సరళంగా ఉండదు—మీ ప్రయత్నాలన్నీ చేసినప్పటికీ, మీరు ప్రతీదాన్నీ ఊహించలేరు. వేగవంతమైన పునరావృతం మరియు కొత్త డేటాకు ప్రతిస్పందించడం చాలా ఎక్కువ ప్రభావవంతంగా ఉంటాయి.
మా అనుభవం ఆధారంగా, మేము ఈ క్రింది సలహాలను ఇవ్వగలము:
- మీ అంతర్జ్ఞానాన్ని నమ్మవద్దు.
బృందానికి విస్తృతమైన అనుభవం ఉన్నప్పటికీ, మా అంతర్ దృష్టి పదేపదే మమ్మల్ని విఫలం చేసింది. ఉదాహరణకు, CDN ప్రాక్సీని ఉపయోగించడం వల్ల ఆశించిన వేగవృద్ధిని లేదా TCP ఎనీకాస్ట్ ప్రవర్తనను మేము తప్పుగా అంచనా వేశాము.
- ఉత్పత్తి నుండి డేటాను పొందండి.
వీలైనంత త్వరగా కనీసం కొంత ఉత్పత్తి డేటాను పొందడం ముఖ్యం. ఒక ల్యాబ్ వాతావరణంలో పెద్ద సంఖ్యలో ప్రత్యేకమైన కేసులు, కాన్ఫిగరేషన్లు మరియు సెట్టింగ్లను పొందడం దాదాపు అసాధ్యం. ఫలితాలను వేగంగా పొందడం వలన, మీరు సంభావ్య సమస్యలను త్వరగా గుర్తించి, వాటిని సిస్టమ్ ఆర్కిటెక్చర్లో పరిగణనలోకి తీసుకోవడానికి వీలు కలుగుతుంది.
- ఇతరుల సలహాలను, ఫలితాలను అనుసరించవద్దు - మీ స్వంత సమాచారాన్ని సేకరించండి.
డేటా సేకరణ మరియు విశ్లేషణ సూత్రాలను అనుసరించండి, కానీ ఇతర కంపెనీల ఫలితాలను మరియు వాదనలను గుడ్డిగా అంగీకరించవద్దు. మీ వినియోగదారులకు ఏది పని చేస్తుందో మీకు మాత్రమే ఖచ్చితంగా తెలుస్తుంది. మీ సిస్టమ్లు మరియు మీ క్లయింట్లు ఇతర కంపెనీల వాటి కంటే గణనీయంగా భిన్నంగా ఉండవచ్చు. అదృష్టవశాత్తూ, విశ్లేషణ సాధనాలు ఇప్పుడు సులభంగా అందుబాటులో ఉన్నాయి మరియు ఉపయోగించడానికి సులభంగా ఉన్నాయి. మీ ఫలితాలు నెట్ఫ్లిక్స్, ఫేస్బుక్, అకామై మరియు ఇతర కంపెనీల ఫలితాలతో సరిపోలకపోవచ్చు. మా విషయంలో, మా వద్ద వేర్వేరు పరికరాలు, క్లయింట్లు మరియు డేటా స్ట్రీమ్లు ఉన్నందున, TLS, HTTP2 పనితీరు లేదా DNS క్వెరీ గణాంకాలు ఫేస్బుక్, ఉబెర్ మరియు అకామైల వాటి కంటే భిన్నంగా ఉంటాయి.
- అవసరం లేకుండా మరియు వాటి ప్రభావశీలతను అంచనా వేయకుండా ఫ్యాషన్ పోకడలను అనుసరించవద్దు.
సరళంగా ప్రారంభించండి. అనవసరమైన భాగాలను అభివృద్ధి చేయడానికి లెక్కలేనన్ని గంటలు వెచ్చించడం కంటే, తక్కువ సమయంలో సరళమైన, పనిచేసే వ్యవస్థను రూపొందించడం ఉత్తమం. మీ కొలతలు మరియు ఫలితాల ఆధారంగా ముఖ్యమైన పనులు మరియు సమస్యలను పరిష్కరించండి.
- కొత్త దరఖాస్తుల కోసం సిద్ధంగా ఉండండి.
అన్ని సమస్యలను ముందుగా ఊహించడం ఎంత కష్టమో, ప్రయోజనాలను మరియు అనువర్తనాలను ఊహించడం కూడా అంతే కష్టం. వినియోగదారుల అవసరాలకు అనుగుణంగా మారగల స్టార్టప్ల సామర్థ్యాన్ని గమనించండి. మీ విషయంలో, మీరు కొత్త సమస్యలను మరియు పరిష్కారాలను కనుగొనవచ్చు. మా ప్రాజెక్ట్లో, మేము రిక్వెస్ట్ లేటెన్సీని తగ్గించాలని లక్ష్యంగా పెట్టుకున్నాము. అయితే, విశ్లేషణ మరియు చర్చల ద్వారా, ప్రాక్సీ సర్వర్లను కూడా ఉపయోగించవచ్చని మేము గ్రహించాము:
- AWS ప్రాంతాలలో ట్రాఫిక్ను సమతుల్యం చేయడానికి మరియు ఖర్చులను తగ్గించడానికి;
- CDN స్థిరత్వాన్ని నమూనా చేయడానికి;
- DNS ను కాన్ఫిగర్ చేయడానికి;
- TLS/TCPని కాన్ఫిగర్ చేయడానికి.
తీర్మానం
నా ప్రసంగంలో, క్లయింట్లు మరియు క్లౌడ్ మధ్య ఇంటర్నెట్ అభ్యర్థనలను వేగవంతం చేసే సమస్యను నెట్ఫ్లిక్స్ ఎలా పరిష్కరిస్తుందో వివరించాను. క్లయింట్-సైడ్ ప్రోబ్ సిస్టమ్ను ఉపయోగించి మేము డేటాను ఎలా సేకరిస్తామో, మరియు సేకరించిన చారిత్రక డేటాను ఉపయోగించి క్లయింట్ల నుండి వచ్చే ప్రొడక్షన్ అభ్యర్థనలను అత్యంత వేగవంతమైన ఇంటర్నెట్ మార్గం ద్వారా ఎలా మళ్లిస్తామో తెలియజేశాను. దీనిని సాధించడానికి నెట్వర్క్ ప్రోటోకాల్ సూత్రాలు, మా CDN మౌలిక సదుపాయాలు, బ్యాక్బోన్ నెట్వర్క్ మరియు DNS సర్వర్లను మేము ఎలా ఉపయోగించుకుంటామో కూడా వివరించాను.
అయితే, మా పరిష్కారం అనేది నెట్ఫ్లిక్స్లో మేము అటువంటి వ్యవస్థను ఎలా అమలు చేశామో చెప్పడానికి ఒక ఉదాహరణ మాత్రమే. మాకు ఏది బాగా పనిచేసిందో చెప్పడమే దీని ఉద్దేశం. మేము అనుసరించే మరియు మంచి ఫలితాలను సాధించే అభివృద్ధి మరియు మద్దతు సూత్రాలే మీకు నేను అందించే ప్రెజెంటేషన్లో ఆచరణాత్మక భాగంగా ఉంటాయి.
మా పరిష్కారం మీకు సరిపోకపోవచ్చు. అయినప్పటికీ, మీకు సొంత CDN మౌలిక సదుపాయాలు లేకపోయినా, లేదా అవి మా వాటికి గణనీయంగా భిన్నంగా ఉన్నా, సిద్ధాంతం మరియు అభివృద్ధి సూత్రాలు మాత్రం ఒకే విధంగా ఉంటాయి.
వ్యాపారాలకు అభ్యర్థన వేగం చాలా కీలకం. ఒక సాధారణ సేవ కోసం కూడా, మీరు క్లౌడ్ ప్రొవైడర్లు, సర్వర్ స్థానాలు, CDNలు మరియు DNS ప్రొవైడర్ల మధ్య ఎంపికలు చేసుకోవలసి ఉంటుంది. మీ ఎంపిక మీ కస్టమర్ల ఇంటర్నెట్ అభ్యర్థనల పనితీరును ప్రభావితం చేస్తుంది. మరియు ఈ ప్రభావాన్ని మీరు కొలవడం, అర్థం చేసుకోవడం చాలా ముఖ్యం.
సరళమైన పరిష్కారాలతో ప్రారంభించండి మరియు మీరు ఉత్పత్తిని ఎలా మారుస్తున్నారనే దానిపై శ్రద్ధ వహించండి. పని చేస్తూనే నేర్చుకోండి మరియు మీ కస్టమర్లు, మీ మౌలిక సదుపాయాలు, మరియు మీ వ్యాపారం నుండి లభించే డేటా ఆధారంగా సిస్టమ్ను మెరుగుపరచండి. డిజైన్ ప్రక్రియలో ఊహించని వైఫల్యాలు సంభవించే అవకాశాన్ని పరిగణించండి. ఇది మీ అభివృద్ధి ప్రక్రియను వేగవంతం చేస్తుంది, పరిష్కారం యొక్క సామర్థ్యాన్ని మెరుగుపరుస్తుంది, అనవసరమైన సపోర్ట్ భారాన్ని నివారిస్తుంది మరియు మీకు మనశ్శాంతిని ఇస్తుంది.
ఈ సంవత్సరం ఆన్లైన్ పద్ధతిలో, మీరు డెవ్ఆప్స్ పితామహులలో ఒకరైన జాన్ విల్లిస్నే స్వయంగా ప్రశ్నలు అడగగలరు!
మూలం: www.habr.com
