इंटरनेट विनंत्यांची गती वाढवा आणि शांतपणे झोपा

नेटफ्लिक्स ही इंटरनेट टेलिव्हिजन मार्केटमध्ये आघाडीवर आहे - ही कंपनी ज्याने हा विभाग तयार केला आणि सक्रियपणे विकसित केला आहे. नेटफ्लिक्स केवळ ग्रहाच्या जवळजवळ प्रत्येक कोपऱ्यातून उपलब्ध असलेल्या चित्रपट आणि टीव्ही मालिकांच्या विस्तृत कॅटलॉगसाठी आणि डिस्प्लेसह कोणत्याही डिव्हाइससाठीच नव्हे तर त्याच्या विश्वसनीय पायाभूत सुविधा आणि अद्वितीय अभियांत्रिकी संस्कृतीसाठी देखील ओळखले जाते.

डेव्हओप्स 2019 मध्ये जटिल प्रणाली विकसित आणि समर्थन करण्यासाठी Netflix दृष्टिकोनाचे स्पष्ट उदाहरण सादर केले गेले. सेर्गेई फेडोरोव्ह - नेटफ्लिक्सचे विकास संचालक. निझनी नोव्हगोरोड स्टेट युनिव्हर्सिटीच्या कॉम्प्युटेशनल मॅथेमॅटिक्स आणि मॅथेमॅटिक्स फॅकल्टीचे पदवीधर. लोबाचेव्स्की, नेटफ्लिक्समधील ओपन कनेक्ट - सीडीएन टीममधील पहिल्या अभियंत्यांपैकी एक सेर्गे. त्यांनी व्हिडिओ डेटाचे निरीक्षण आणि विश्लेषण करण्यासाठी प्रणाली तयार केली, इंटरनेट कनेक्शन गतीचे मूल्यांकन करण्यासाठी FAST.com ही लोकप्रिय सेवा सुरू केली आणि गेल्या काही वर्षांपासून इंटरनेट विनंत्या ऑप्टिमाइझ करण्यावर काम करत आहे जेणेकरून Netflix ऍप्लिकेशन वापरकर्त्यांसाठी शक्य तितक्या लवकर काम करेल.

अहवालाला कॉन्फरन्सच्या सहभागींकडून सर्वोत्तम पुनरावलोकने मिळाली आणि आम्ही तुमच्यासाठी मजकूर आवृत्ती तयार केली आहे.

त्याच्या अहवालात, सर्गेईने तपशीलवार सांगितले

• क्लायंट आणि सर्व्हरमधील इंटरनेट विनंत्यांच्या विलंबावर काय परिणाम होतो याबद्दल;
• हा विलंब कसा कमी करायचा;
• त्रुटी-सहिष्णु प्रणालीची रचना, देखभाल आणि देखरेख कशी करावी;
• कमी वेळेत आणि व्यवसायासाठी कमीत कमी जोखीम घेऊन परिणाम कसे मिळवायचे;
• परिणामांचे विश्लेषण कसे करावे आणि चुकांमधून शिकावे.

या प्रश्नांची उत्तरे फक्त मोठ्या कंपन्यांमध्ये काम करणाऱ्यांनाच हवी आहेत.

सादर केलेली तत्त्वे आणि तंत्रे इंटरनेट उत्पादनांचा विकास आणि समर्थन करणाऱ्या प्रत्येकाने ओळखली पाहिजेत आणि त्यांचा सराव केला पाहिजे.

पुढे स्पीकरच्या दृष्टीकोनातून वर्णन आहे.

इंटरनेट स्पीडचे महत्त्व

इंटरनेट विनंत्यांची गती थेट व्यवसायाशी संबंधित आहे. खरेदी उद्योगाचा विचार करा: 2009 मध्ये Amazon बोललेकी 100ms विलंबामुळे 1% विक्रीचे नुकसान होते.

अधिक आणि अधिक मोबाइल डिव्हाइस आहेत, त्यानंतर मोबाइल साइट्स आणि ॲप्लिकेशन्स आहेत. तुमचे पृष्ठ लोड होण्यासाठी 3 सेकंदांपेक्षा जास्त वेळ घेत असल्यास, तुम्ही तुमचे निम्मे वापरकर्ते गमावत आहात. सह जुलै 2018 Google शोध परिणामांमध्ये तुमच्या पृष्ठाची लोडिंग गती विचारात घेते: पृष्ठ जितके वेगवान असेल तितके Google मध्ये त्याचे स्थान अधिक असेल.

वित्तीय संस्थांमध्ये कनेक्शन गती देखील महत्वाची आहे जिथे विलंब गंभीर आहे. 2015 मध्ये, हायबरनिया नेटवर्क्स पूर्ण शहरांमधील विलंब 400ms ने कमी करण्यासाठी न्यूयॉर्क आणि लंडन दरम्यान $6 दशलक्ष केबल. 66 एमएस विलंब कमी करण्यासाठी $1 दशलक्ष कल्पना करा!

मते संशोधन, 5 Mbit/s वरील कनेक्शन गती यापुढे विशिष्ट वेबसाइटच्या लोडिंग गतीवर थेट परिणाम करत नाही. तथापि, कनेक्शन विलंबता आणि पृष्ठ लोडिंग गती यांच्यात एक रेषीय संबंध आहे:

तथापि, Netflix हे ठराविक उत्पादन नाही. वापरकर्त्यावर विलंब आणि गतीचा प्रभाव हे विश्लेषण आणि विकासाचे सक्रिय क्षेत्र आहे. ॲप्लिकेशन लोडिंग आणि सामग्रीची निवड आहे जी विलंबतेवर अवलंबून असते, परंतु स्थिर घटक लोड करणे आणि स्ट्रीमिंग देखील कनेक्शन गतीवर अवलंबून असते. वापरकर्त्याच्या अनुभवावर प्रभाव टाकणाऱ्या प्रमुख घटकांचे विश्लेषण आणि ऑप्टिमाइझ करणे हे नेटफ्लिक्समधील अनेक संघांसाठी विकासाचे सक्रिय क्षेत्र आहे. नेटफ्लिक्स उपकरणे आणि क्लाउड इन्फ्रास्ट्रक्चरमधील विनंत्या कमी करणे हे एक उद्दिष्ट आहे.

अहवालात आम्ही नेटफ्लिक्स इन्फ्रास्ट्रक्चरचे उदाहरण वापरून विलंब कमी करण्यावर विशेष लक्ष केंद्रित करू. जटिल वितरण प्रणालीच्या डिझाइन, विकास आणि ऑपरेशनच्या प्रक्रियेकडे कसे जायचे आणि ऑपरेशनल समस्या आणि ब्रेकडाउनचे निदान करण्याऐवजी नवकल्पना आणि परिणामांवर वेळ कसा घालवायचा याचा व्यावहारिक दृष्टिकोनातून विचार करूया.

नेटफ्लिक्सच्या आत

हजारो भिन्न उपकरणे Netflix ॲप्सना समर्थन देतात. ते चार वेगवेगळ्या संघांद्वारे विकसित केले जातात, जे Android, iOS, TV आणि वेब ब्राउझरसाठी क्लायंटच्या स्वतंत्र आवृत्त्या बनवतात. आणि आम्ही वापरकर्ता अनुभव सुधारण्यासाठी आणि वैयक्तिकृत करण्यासाठी खूप प्रयत्न करतो. हे करण्यासाठी, आम्ही शेकडो A/B चाचण्या समांतर चालवतो.

वैयक्तिकरणास AWS क्लाउडमधील शेकडो मायक्रोसर्व्हिसेसद्वारे समर्थित आहे, वैयक्तिकृत वापरकर्ता डेटा, क्वेरी डिस्पॅच, टेलिमेट्री, बिग डेटा आणि एन्कोडिंग प्रदान करते. ट्रॅफिक व्हिज्युअलायझेशन असे दिसते:

प्रात्यक्षिकासह व्हिडिओची लिंक (६:०४-६:२३)

डावीकडे एंट्री पॉईंट आहे, आणि नंतर रहदारी विविध बॅकएंड टीमद्वारे समर्थित असलेल्या शेकडो मायक्रो सर्व्हिसेसमध्ये वितरीत केली जाते.

आमच्या पायाभूत सुविधांचा आणखी एक महत्त्वाचा घटक म्हणजे ओपन कनेक्ट सीडीएन, जे अंतिम वापरकर्त्याला स्थिर सामग्री - व्हिडिओ, प्रतिमा, क्लायंट कोड इ. CDN कस्टम सर्व्हरवर स्थित आहे (OCA - ओपन कनेक्ट उपकरण). आत SSD आणि HDD ड्राइव्हचे ॲरे आहेत जे ऑप्टिमाइझ केलेले FreeBSD चालवतात, NGINX आणि सेवांचा संच. आम्ही हार्डवेअर आणि सॉफ्टवेअर घटक डिझाइन आणि ऑप्टिमाइझ करतो जेणेकरून असा CDN सर्व्हर वापरकर्त्यांना जास्तीत जास्त डेटा पाठवू शकेल.

इंटरनेट ट्रॅफिक एक्सचेंज पॉइंट (इंटरनेट एक्सचेंज - IX) वर या सर्व्हरची “भिंत” यासारखी दिसते:

इंटरनेट एक्सचेंज इंटरनेट सेवा प्रदाते आणि सामग्री प्रदात्यांना इंटरनेटवरील डेटाची अधिक थेट देवाणघेवाण करण्यासाठी एकमेकांशी "कनेक्ट" करण्याची क्षमता प्रदान करते. जगभरात अंदाजे 70-80 इंटरनेट एक्सचेंज पॉइंट आहेत जिथे आमचे सर्व्हर स्थापित केले आहेत आणि आम्ही ते स्वतंत्रपणे स्थापित आणि देखरेख करतो:

याव्यतिरिक्त, आम्ही इंटरनेट प्रदात्यांना थेट सर्व्हर देखील प्रदान करतो, जे ते त्यांच्या नेटवर्कमध्ये स्थापित करतात, Netflix रहदारीचे स्थानिकीकरण आणि वापरकर्त्यांसाठी प्रवाहाची गुणवत्ता सुधारतात:

AWS सेवांचा संच क्लायंटकडून CDN सर्व्हरवर व्हिडिओ विनंत्या पाठवण्यासाठी, तसेच सर्व्हर स्वतः कॉन्फिगर करण्यासाठी - सामग्री, प्रोग्राम कोड, सेटिंग्ज इ. अपडेट करण्यासाठी जबाबदार आहे. नंतरच्यासाठी, आम्ही एक बॅकबोन नेटवर्क देखील तयार केले जे इंटरनेट एक्सचेंज पॉइंट्समधील सर्व्हरला AWS सह जोडते. बॅकबोन नेटवर्क हे फायबर ऑप्टिक केबल्स आणि राउटरचे जागतिक नेटवर्क आहे जे आम्ही आमच्या गरजेनुसार डिझाइन आणि कॉन्फिगर करू शकतो.

द्वारा वाळूचा अंदाज, आमची CDN इन्फ्रास्ट्रक्चर जगातील इंटरनेट ट्रॅफिकचा अंदाजे ⅛ पीक अवर्स दरम्यान आणि ⅓ उत्तर अमेरिकेतील ट्रॅफिक प्रदान करते, जिथे Netflix सर्वात जास्त काळ आहे. प्रभावी संख्या, परंतु माझ्यासाठी सर्वात आश्चर्यकारक यशांपैकी एक म्हणजे संपूर्ण CDN प्रणाली 150 पेक्षा कमी लोकांच्या टीमद्वारे विकसित आणि देखरेख केली जाते.

सुरुवातीला, CDN इन्फ्रास्ट्रक्चर व्हिडिओ डेटा वितरीत करण्यासाठी डिझाइन केले होते. तथापि, कालांतराने आम्हाला समजले की आम्ही AWS क्लाउडमधील क्लायंटच्या डायनॅमिक विनंत्या ऑप्टिमाइझ करण्यासाठी देखील वापरू शकतो.

इंटरनेट प्रवेग बद्दल

आज, Netflix कडे 3 AWS क्षेत्र आहेत आणि क्लाउडला विनंत्यांची विलंबता ग्राहक जवळच्या प्रदेशापासून किती दूर आहे यावर अवलंबून असेल. त्याच वेळी, आमच्याकडे अनेक CDN सर्व्हर आहेत जे स्थिर सामग्री वितरीत करण्यासाठी वापरले जातात. डायनॅमिक क्वेरींना गती देण्यासाठी हे फ्रेमवर्क वापरण्याचा कोणताही मार्ग आहे का? तथापि, दुर्दैवाने, या विनंत्या कॅशे करणे अशक्य आहे - API वैयक्तिकृत आहेत आणि प्रत्येक परिणाम अद्वितीय आहे.

चला CDN सर्व्हरवर एक प्रॉक्सी बनवू आणि त्याद्वारे रहदारी पाठवणे सुरू करू. ते जलद होईल का?

साहित्य

नेटवर्क प्रोटोकॉल कसे कार्य करतात ते लक्षात ठेवूया. आज, इंटरनेटवरील बहुतेक रहदारी HTTPs वापरते, जे खालच्या स्तरावरील प्रोटोकॉल TCP आणि TLS वर अवलंबून असते. क्लायंटला सर्व्हरशी कनेक्ट होण्यासाठी, तो हँडशेक करतो आणि सुरक्षित कनेक्शन स्थापित करण्यासाठी, क्लायंटला सर्व्हरशी तीन वेळा संदेशांची देवाणघेवाण करणे आणि डेटा हस्तांतरित करण्यासाठी किमान एक वेळ आवश्यक आहे. प्रति राउंड ट्रिप (RTT) 100 ms च्या लेटन्सीसह, डेटाचा पहिला बिट प्राप्त करण्यासाठी आम्हाला 400 ms लागतील:

आम्ही प्रमाणपत्रे CDN सर्व्हरवर ठेवल्यास, CDN जवळ असल्यास क्लायंट आणि सर्व्हरमधील हँडशेक वेळ लक्षणीयरीत्या कमी होऊ शकतो. CDN सर्व्हरची विलंबता 30ms आहे असे गृहीत धरू. मग पहिला बिट प्राप्त करण्यासाठी 220 ms लागतील:

पण फायदे तिथेच संपत नाहीत. एकदा कनेक्शन स्थापित झाल्यानंतर, TCP गर्दीची विंडो वाढवते (समांतरपणे त्या कनेक्शनवर प्रसारित करू शकणारी माहिती). डेटा पॅकेट हरवल्यास, TCP प्रोटोकॉलची क्लासिक अंमलबजावणी (TCP New Reno सारखी) उघडलेली “विंडो” अर्ध्याने कमी करते. गर्दीच्या खिडकीची वाढ आणि तोट्यातून पुन्हा पुनर्प्राप्तीचा वेग सर्व्हरला होणाऱ्या विलंबावर (RTT) अवलंबून असतो. जर हे कनेक्शन फक्त CDN सर्व्हरपर्यंत जाते, तर ही पुनर्प्राप्ती जलद होईल. त्याच वेळी, पॅकेट गमावणे ही एक मानक घटना आहे, विशेषत: वायरलेस नेटवर्कसाठी.

इंटरनेट बँडविड्थ कमी होऊ शकते, विशेषत: पीक अवर्समध्ये, वापरकर्त्यांच्या रहदारीमुळे, ज्यामुळे ट्रॅफिक जाम होऊ शकते. तथापि, इंटरनेटवर काही विनंत्यांना इतरांपेक्षा प्राधान्य देण्याचा कोणताही मार्ग नाही. उदाहरणार्थ, नेटवर्क लोड करणाऱ्या "भारी" डेटा प्रवाहांवर लहान आणि विलंब-संवेदनशील विनंत्यांना प्राधान्य द्या. तथापि, आमच्या बाबतीत, आमचे स्वतःचे पाठीचा कणा असलेले नेटवर्क आम्हाला विनंती मार्गाच्या भागावर - CDN आणि क्लाउड दरम्यान हे करण्याची परवानगी देते आणि आम्ही ते पूर्णपणे कॉन्फिगर करू शकतो. लहान आणि विलंब-संवेदनशील पॅकेट्सना प्राधान्य दिले आहे आणि मोठ्या डेटाचा प्रवाह थोड्या वेळाने जातो याची तुम्ही खात्री करू शकता. CDN क्लायंटच्या जितके जवळ असेल तितकी कार्यक्षमता जास्त.

ऍप्लिकेशन लेव्हल प्रोटोकॉल (OSI लेव्हल 7) चा देखील विलंबतेवर परिणाम होतो. नवीन प्रोटोकॉल जसे की HTTP/2 समांतर विनंत्यांचे कार्यप्रदर्शन ऑप्टिमाइझ करतात. तथापि, आमच्याकडे जुन्या उपकरणांसह Netflix क्लायंट आहेत जे नवीन प्रोटोकॉलला समर्थन देत नाहीत. सर्व क्लायंट अद्ययावत किंवा चांगल्या प्रकारे कॉन्फिगर केले जाऊ शकत नाहीत. त्याच वेळी, CDN प्रॉक्सी आणि क्लाउड दरम्यान संपूर्ण नियंत्रण आणि नवीन, इष्टतम प्रोटोकॉल आणि सेटिंग्ज वापरण्याची क्षमता आहे. जुन्या प्रोटोकॉलसह कुचकामी भाग केवळ क्लायंट आणि CDN सर्व्हर दरम्यान कार्य करेल. शिवाय, आम्ही CDN आणि क्लाउड दरम्यान आधीच स्थापित कनेक्शनवर मल्टीप्लेक्स विनंत्या करू शकतो, TCP स्तरावर कनेक्शनचा वापर सुधारतो:

आम्ही मोजतो

सिद्धांतामध्ये सुधारणांचे आश्वासन दिले आहे हे असूनही, आम्ही उत्पादनामध्ये सिस्टम लॉन्च करण्यासाठी त्वरित घाई करत नाही. त्याऐवजी, आपण प्रथम सिद्ध केले पाहिजे की कल्पना व्यवहारात कार्य करेल. हे करण्यासाठी, आपल्याला अनेक प्रश्नांची उत्तरे देणे आवश्यक आहे:

• गती: प्रॉक्सी जलद होईल का?
• विश्वसनीयता: तो अधिक वेळा खंडित होईल?
• अडचण: ऍप्लिकेशन्ससह कसे समाकलित करावे?
• खर्च: अतिरिक्त पायाभूत सुविधा तैनात करण्यासाठी किती खर्च येतो?

पहिल्या मुद्द्याचे मूल्यांकन करण्याच्या आमच्या दृष्टिकोनाचा तपशीलवार विचार करूया. बाकीचेही अशाच पद्धतीने हाताळले जातात.

विनंत्यांच्या गतीचे विश्लेषण करण्यासाठी, आम्ही विकासावर बराच वेळ न घालवता आणि उत्पादन खंडित न करता सर्व वापरकर्त्यांसाठी डेटा प्राप्त करू इच्छितो. यासाठी अनेक पद्धती आहेत:

1. RUM, किंवा निष्क्रिय विनंती मापन. आम्ही वापरकर्त्यांच्या सध्याच्या विनंत्यांच्या अंमलबजावणीची वेळ मोजतो आणि पूर्ण वापरकर्ता कव्हरेज सुनिश्चित करतो. गैरसोय असा आहे की अनेक घटकांमुळे सिग्नल खूप स्थिर नाही, उदाहरणार्थ, भिन्न विनंती आकारांमुळे, सर्व्हरवर प्रक्रिया वेळ आणि क्लायंट. याव्यतिरिक्त, आपण उत्पादनात परिणाम न करता नवीन कॉन्फिगरेशनची चाचणी करू शकत नाही.
2. प्रयोगशाळा चाचण्या. विशेष सर्व्हर आणि पायाभूत सुविधा जे क्लायंटचे अनुकरण करतात. त्यांच्या मदतीने आम्ही आवश्यक चाचण्या करतो. अशा प्रकारे आम्हाला मापन परिणाम आणि स्पष्ट सिग्नलवर पूर्ण नियंत्रण मिळते. परंतु डिव्हाइसेस आणि वापरकर्ता स्थानांचे कोणतेही संपूर्ण कव्हरेज नाही (विशेषत: जगभरातील सेवा आणि हजारो डिव्हाइस मॉडेलसाठी समर्थन).

आपण दोन्ही पद्धतींचे फायदे कसे एकत्र करू शकता?

आमच्या टीमने यावर उपाय शोधला आहे. आम्ही कोडचा एक छोटा तुकडा - एक नमुना - जो आम्ही आमच्या अनुप्रयोगात तयार केला आहे. प्रोब्स आम्हाला आमच्या उपकरणांमधून पूर्णपणे नियंत्रित नेटवर्क चाचण्या करण्याची परवानगी देतात. हे असे कार्य करते:

1. ऍप्लिकेशन लोड केल्यानंतर आणि प्रारंभिक क्रियाकलाप पूर्ण केल्यानंतर, आम्ही आमचे प्रोब चालवतो.
2. क्लायंट सर्व्हरला विनंती करतो आणि चाचणीसाठी "रेसिपी" प्राप्त करतो. रेसिपी ही URL ची सूची आहे ज्यावर HTTP(s) विनंती करणे आवश्यक आहे. याव्यतिरिक्त, रेसिपी विनंती पॅरामीटर्स कॉन्फिगर करते: विनंत्यांमधील विलंब, विनंती केलेल्या डेटाचे प्रमाण, HTTP(चे) शीर्षलेख इ. त्याच वेळी, आम्ही समांतरपणे अनेक भिन्न पाककृती तपासू शकतो - कॉन्फिगरेशनची विनंती करताना, आम्ही यादृच्छिकपणे कोणती पाककृती जारी करायची हे निर्धारित करतो.
3. क्लायंटवरील नेटवर्क संसाधनांच्या सक्रिय वापराशी विरोध होऊ नये म्हणून प्रोब लॉन्च वेळ निवडला जातो. मूलत:, क्लायंट सक्रिय नसताना वेळ निवडला जातो.
4. रेसिपी मिळाल्यानंतर, क्लायंट प्रत्येक URL ला समांतरपणे विनंती करतो. प्रत्येक पत्त्यावरील विनंतीची पुनरावृत्ती केली जाऊ शकते - तथाकथित. "डाळी". पहिल्या पल्सवर, कनेक्शन स्थापित करण्यासाठी आणि डेटा डाउनलोड करण्यासाठी किती वेळ लागला हे आम्ही मोजतो. दुसऱ्या नाडीवर, आम्ही आधीच स्थापित केलेल्या कनेक्शनवर डेटा लोड करण्यासाठी लागणारा वेळ मोजतो. तिसऱ्यापूर्वी, आम्ही विलंब सेट करू शकतो आणि पुन्हा कनेक्शन स्थापित करण्याची गती मोजू शकतो.

   चाचणी दरम्यान, आम्ही डिव्हाइस प्राप्त करू शकणारे सर्व पॅरामीटर्स मोजतो:

   • DNS विनंती वेळ;
   • TCP कनेक्शन सेटअप वेळ;
   • TLS कनेक्शन सेटअप वेळ;
   • डेटाचा पहिला बाइट प्राप्त होण्याची वेळ;
   • एकूण लोडिंग वेळ;
   • स्थिती परिणाम कोड.
5. सर्व डाळी पूर्ण झाल्यानंतर, नमुना विश्लेषणासाठी सर्व मोजमाप लोड करतो.

क्लायंटवरील तर्कशास्त्रावर किमान अवलंबित्व, सर्व्हरवरील डेटा प्रोसेसिंग आणि समांतर विनंत्यांचे मोजमाप हे महत्त्वाचे मुद्दे आहेत. अशाप्रकारे, आम्ही क्वेरी कार्यप्रदर्शन प्रभावित करणाऱ्या विविध घटकांच्या प्रभावाचे पृथक्करण आणि चाचणी करण्यास सक्षम आहोत, त्यांना एकाच रेसिपीमध्ये बदलू शकतो आणि वास्तविक ग्राहकांकडून परिणाम प्राप्त करू शकतो.

ही पायाभूत सुविधा केवळ क्वेरी कार्यप्रदर्शन विश्लेषणापेक्षा अधिक उपयुक्त ठरली आहे. सध्या आमच्याकडे 14 सक्रिय पाककृती आहेत, प्रति सेकंद 6000 पेक्षा जास्त नमुने, पृथ्वीच्या सर्व कोपऱ्यांमधून डेटा आणि संपूर्ण डिव्हाइस कव्हरेज प्राप्त करतात. Netflix ने त्रयस्थ पक्षाकडून अशीच सेवा विकत घेतल्यास, अधिक वाईट कव्हरेजसह वर्षाला लाखो डॉलर्स खर्च होतील.

सराव मध्ये चाचणी सिद्धांत: प्रोटोटाइप

अशा प्रणालीसह, आम्ही विनंती विलंबतेवर CDN प्रॉक्सीच्या प्रभावीतेचे मूल्यांकन करण्यास सक्षम होतो. आता आपल्याला आवश्यक आहे:

• प्रॉक्सी प्रोटोटाइप तयार करा;
• प्रोटोटाइप सीडीएनवर ठेवा;
• विशिष्ट CDN सर्व्हरवर क्लायंटला प्रॉक्सीकडे कसे निर्देशित करायचे ते निर्धारित करा;
• प्रॉक्सीशिवाय AWS मधील विनंत्यांच्या कामगिरीची तुलना करा.

प्रस्तावित समाधानाच्या प्रभावीतेचे शक्य तितक्या लवकर मूल्यांकन करणे हे कार्य आहे. चांगल्या नेटवर्किंग लायब्ररींच्या उपलब्धतेमुळे आम्ही प्रोटोटाइप लागू करण्यासाठी गो निवडले. प्रत्येक CDN सर्व्हरवर, अवलंबित्व कमी करण्यासाठी आणि एकत्रीकरण सुलभ करण्यासाठी आम्ही प्रोटोटाइप प्रॉक्सी स्थिर बायनरी म्हणून स्थापित केला आहे. सुरुवातीच्या अंमलबजावणीमध्ये, आम्ही HTTP/2 कनेक्शन पूलिंगसाठी आणि मल्टीप्लेक्सिंगची विनंती करण्यासाठी शक्य तितके मानक घटक वापरले आणि किरकोळ बदल केले.

AWS क्षेत्रांमध्ये संतुलन राखण्यासाठी, आम्ही भौगोलिक DNS डेटाबेस वापरला, तोच क्लायंट संतुलित करण्यासाठी वापरला जातो. क्लायंटसाठी CDN सर्व्हर निवडण्यासाठी, आम्ही इंटरनेट एक्सचेंज (IX) मधील सर्व्हरसाठी TCP Anycast वापरतो. या पर्यायामध्ये, आम्ही सर्व CDN सर्व्हरसाठी एक IP पत्ता वापरतो आणि क्लायंटला कमीतकमी IP हॉप्ससह CDN सर्व्हरकडे निर्देशित केले जाईल. इंटरनेट प्रदात्यांद्वारे (ISPs) स्थापित केलेल्या CDN सर्व्हरमध्ये, TCP Anycast कॉन्फिगर करण्यासाठी आमच्याकडे राउटरवर नियंत्रण नाही, म्हणून आम्ही वापरतो समान तर्क, जे ग्राहकांना व्हिडिओ स्ट्रीमिंगसाठी इंटरनेट प्रदात्यांकडे निर्देशित करते.

तर, आमच्याकडे तीन प्रकारचे विनंती मार्ग आहेत: खुल्या इंटरनेटद्वारे क्लाउडवर, IX मधील CDN सर्व्हरद्वारे किंवा इंटरनेट प्रदात्यावर असलेल्या CDN सर्व्हरद्वारे. उत्पादनासाठी विनंत्या कशा पाठवल्या जातात याच्या तुलनेत कोणता मार्ग चांगला आहे आणि प्रॉक्सीचा फायदा काय आहे हे समजून घेणे हे आमचे ध्येय आहे. हे करण्यासाठी, आम्ही खालीलप्रमाणे नमुना प्रणाली वापरतो:

प्रत्येक मार्ग स्वतंत्र लक्ष्य बनतो आणि आपण मिळालेल्या वेळेकडे पाहतो. विश्लेषणासाठी, आम्ही प्रॉक्सी परिणाम एका गटामध्ये एकत्र करतो (IX आणि ISP प्रॉक्सीमधील सर्वोत्तम वेळ निवडा), आणि प्रॉक्सीशिवाय क्लाउडला विनंती करण्याच्या वेळेशी त्यांची तुलना करा:

जसे आपण पाहू शकता, परिणाम मिश्रित होते - बहुतेक प्रकरणांमध्ये प्रॉक्सी चांगली गती देते, परंतु तेथे पुरेसे ग्राहक देखील आहेत ज्यांच्यासाठी परिस्थिती लक्षणीयरीत्या खराब होईल.

परिणामी, आम्ही अनेक महत्त्वाच्या गोष्टी केल्या:

1. आम्ही क्लायंटकडून क्लाउडला CDN प्रॉक्सीद्वारे केलेल्या विनंत्यांच्या अपेक्षित कामगिरीचे मूल्यांकन केले.
2. आम्हाला सर्व प्रकारच्या डिव्हाइसेसवरून वास्तविक क्लायंटकडून डेटा प्राप्त झाला.
3. आम्हाला समजले की सिद्धांताची 100% पुष्टी झाली नाही आणि CDN प्रॉक्सीसह प्रारंभिक ऑफर आमच्यासाठी कार्य करणार नाही.
4. आम्ही जोखीम घेतली नाही - आम्ही क्लायंटसाठी उत्पादन कॉन्फिगरेशन बदलले नाही.
5. काहीही तुटलेले नव्हते.

प्रोटोटाइप 2.0

म्हणून, ड्रॉईंग बोर्डवर परत जा आणि प्रक्रिया पुन्हा पुन्हा करा.

कल्पना अशी आहे की 100% प्रॉक्सी वापरण्याऐवजी, आम्ही प्रत्येक क्लायंटसाठी सर्वात वेगवान मार्ग निश्चित करू आणि आम्ही तेथे विनंत्या पाठवू - म्हणजे, आम्ही ते करू ज्याला क्लायंट स्टीयरिंग म्हणतात.

याची अंमलबजावणी कशी करायची? आम्ही सर्व्हरच्या बाजूने तर्क वापरू शकत नाही, कारण... या सर्व्हरशी कनेक्ट करण्याचे उद्दिष्ट आहे. क्लायंटवर हे करण्यासाठी काही मार्ग असणे आवश्यक आहे. आणि आदर्शपणे, क्लायंट प्लॅटफॉर्मच्या मोठ्या संख्येसह एकत्रीकरणाचा प्रश्न सोडवू नये म्हणून हे कमीतकमी जटिल तर्कशास्त्राने करा.

उत्तर म्हणजे DNS वापरणे. आमच्या बाबतीत, आमच्याकडे आमची स्वतःची DNS इन्फ्रास्ट्रक्चर आहे आणि आम्ही एक डोमेन झोन सेट करू शकतो ज्यासाठी आमचे सर्व्हर हुकूमशाही असतील. हे असे कार्य करते:

1. क्लायंट होस्ट वापरून DNS सर्व्हरला विनंती करतो, उदाहरणार्थ api.netflix.xom.
2. विनंती आमच्या DNS सर्व्हरवर येते
3. या क्लायंटसाठी कोणता मार्ग सर्वात वेगवान आहे हे DNS सर्व्हरला माहित आहे आणि संबंधित IP पत्ता जारी करतो.

सोल्यूशनमध्ये अतिरिक्त जटिलता आहे: हुकूमशाही DNS प्रदाते क्लायंटचा IP पत्ता पाहत नाहीत आणि क्लायंट वापरत असलेल्या रिकर्सिव रिझोल्व्हरचा फक्त IP पत्ता वाचू शकतात.

परिणामी, आमच्या हुकूमशाही रिझोल्व्हरने वैयक्तिक क्लायंटसाठी नाही तर रिकर्सिव्ह रिझोल्व्हरवर आधारित क्लायंटच्या गटासाठी निर्णय घेणे आवश्यक आहे.

सोडवण्यासाठी, आम्ही तेच नमुने वापरतो, प्रत्येक पुनरावृत्ती रिझोल्व्हरसाठी क्लायंटचे मोजमाप परिणाम एकत्रित करतो आणि त्यांचा हा गट कुठे पाठवायचा ते ठरवतो - TCP Anycast वापरून IX द्वारे प्रॉक्सी, ISP प्रॉक्सीद्वारे किंवा थेट क्लाउडवर.

आम्हाला खालील प्रणाली मिळते:

परिणामी DNS स्टीयरिंग मॉडेल तुम्हाला क्लायंटपासून क्लाउडपर्यंतच्या कनेक्शनच्या गतीच्या ऐतिहासिक निरीक्षणांवर आधारित क्लायंटला निर्देशित करण्यास अनुमती देते.

हा दृष्टीकोन कितपत प्रभावीपणे कार्य करेल हा प्रश्न पुन्हा एकदा उपस्थित होतो. उत्तर देण्यासाठी, आम्ही पुन्हा आमची प्रोब सिस्टम वापरतो. म्हणून, आम्ही प्रेझेंटर कॉन्फिगरेशन कॉन्फिगर करतो, जेथे लक्ष्यांपैकी एक DNS स्टीयरिंगच्या दिशेने जाते, दुसरे थेट क्लाउड (वर्तमान उत्पादन) वर जाते.

परिणामी, आम्ही परिणामांची तुलना करतो आणि परिणामकारकतेचे मूल्यांकन करतो:

परिणामी, आम्ही अनेक महत्त्वाच्या गोष्टी शिकलो:

1. आम्ही DNS स्टीयरिंग वापरून क्लायंटकडून क्लाउडला केलेल्या विनंतीच्या अपेक्षित कामगिरीचे मूल्यांकन केले.
2. आम्हाला सर्व प्रकारच्या डिव्हाइसेसवरून वास्तविक क्लायंटकडून डेटा प्राप्त झाला.
3. प्रस्तावित कल्पनेची प्रभावीता सिद्ध झाली आहे.
4. आम्ही जोखीम घेतली नाही - आम्ही क्लायंटसाठी उत्पादन कॉन्फिगरेशन बदलले नाही.
5. काहीही तुटलेले नव्हते.

आता कठीण भागाबद्दल - आम्ही ते उत्पादनात लॉन्च करतो

सोपा भाग आता संपला आहे - एक कार्यरत प्रोटोटाइप आहे. आता नेटफ्लिक्सच्या सर्व ट्रॅफिकसाठी 150 दशलक्ष वापरकर्ते, हजारो उपकरणे, शेकडो मायक्रोसर्व्हिसेस आणि सतत बदलणारे उत्पादन आणि पायाभूत सुविधांसाठी उपयोजित करून एक कठीण भाग आहे. Netflix सर्व्हरला प्रति सेकंद लाखो विनंत्या मिळतात आणि निष्काळजी कृतीने सेवा खंडित करणे सोपे आहे. त्याच वेळी, आम्हाला इंटरनेटवरील हजारो CDN सर्व्हरद्वारे रहदारी गतिमानपणे मार्गी लावायची आहे, जिथे काहीतरी सतत बदलते आणि खंडित होते आणि सर्वात अयोग्य क्षणी.

आणि या सर्वांसह, टीमकडे 3 अभियंते आहेत जे सिस्टमच्या विकासासाठी, तैनातीसाठी आणि संपूर्ण समर्थनासाठी जबाबदार आहेत.

म्हणूनच, आम्ही शांत आणि निरोगी झोपेबद्दल बोलत राहू.

विकास कसा चालू ठेवायचा आणि आपला सर्व वेळ समर्थनावर खर्च न करता? आमचा दृष्टिकोन 3 तत्त्वांवर आधारित आहे:

1. आम्ही ब्रेकडाउनचे संभाव्य प्रमाण कमी करतो (स्फोट त्रिज्या).
2. आम्ही आश्चर्यांसाठी तयार आहोत - चाचणी आणि वैयक्तिक अनुभव असूनही काहीतरी खंडित होईल अशी आम्हाला अपेक्षा आहे.
3. ग्रेसफुल डिग्रेडेशन - जर एखादी गोष्ट बरोबर काम करत नसेल, तर ती आपोआप निश्चित केली जावी, जरी सर्वात कार्यक्षम मार्गाने नाही.

असे दिसून आले की आमच्या बाबतीत, समस्येकडे या दृष्टिकोनासह, आम्ही एक सोपा आणि प्रभावी उपाय शोधू शकतो आणि सिस्टम समर्थन लक्षणीयरीत्या सुलभ करू शकतो. आम्हाला समजले की आम्ही क्लायंटमध्ये कोडचा एक छोटा तुकडा जोडू शकतो आणि कनेक्शन समस्यांमुळे नेटवर्क विनंती त्रुटींसाठी मॉनिटर करू शकतो. नेटवर्क एररच्या बाबतीत, आम्ही थेट क्लाउडवर फॉलबॅक करतो. या सोल्यूशनला क्लायंट टीमसाठी महत्त्वपूर्ण प्रयत्नांची आवश्यकता नाही, परंतु आमच्यासाठी अनपेक्षित ब्रेकडाउन आणि आश्चर्याचा धोका मोठ्या प्रमाणात कमी होतो.

अर्थात, फॉलबॅक असूनही, आम्ही विकासादरम्यान स्पष्ट शिस्त पाळतो:

1. नमुना चाचणी.
2. A/B चाचणी किंवा कॅनरी.
3. प्रगतीशील रोलआउट.

नमुन्यांसह, दृष्टिकोनाचे वर्णन केले आहे - बदल प्रथम सानुकूलित कृती वापरून तपासले जातात.

कॅनरी चाचणीसाठी, आम्हाला सर्व्हरच्या तुलनात्मक जोड्या मिळणे आवश्यक आहे ज्यावर आम्ही बदलांपूर्वी आणि नंतर प्रणाली कशी कार्य करते याची तुलना करू शकतो. हे करण्यासाठी, आमच्या बऱ्याच CDN साइट्सवरून, आम्ही तुलनात्मक रहदारी प्राप्त करणाऱ्या सर्व्हरच्या जोड्या निवडतो:

मग आम्ही कॅनरी सर्व्हरवरील बदलांसह बिल्ड स्थापित करतो. परिणामांचे मूल्यमापन करण्यासाठी, आम्ही नियंत्रण सर्व्हरच्या नमुन्यासह अंदाजे 100-150 मेट्रिक्सची तुलना करणारी प्रणाली चालवतो:

जर कॅनरी चाचणी यशस्वी झाली, तर आम्ही ते हळूहळू लाटांमध्ये सोडतो. आम्ही एकाच वेळी प्रत्येक साइटवर सर्व्हर अद्यतनित करत नाही - समस्यांमुळे संपूर्ण साइट गमावणे याचा वापरकर्त्यांच्या सेवेवर वेगवेगळ्या ठिकाणी समान संख्येने सर्व्हर गमावण्यापेक्षा अधिक लक्षणीय परिणाम होतो.

सर्वसाधारणपणे, या दृष्टिकोनाची प्रभावीता आणि सुरक्षितता एकत्रित मेट्रिक्सचे प्रमाण आणि गुणवत्ता यावर अवलंबून असते. आमच्या क्वेरी प्रवेग प्रणालीसाठी, आम्ही सर्व संभाव्य घटकांमधून मेट्रिक्स गोळा करतो:

• क्लायंटकडून - सत्रांची संख्या आणि विनंत्या, फॉलबॅक दर;
• प्रॉक्सी - विनंत्यांची संख्या आणि वेळेची आकडेवारी;
• DNS - विनंत्यांची संख्या आणि परिणाम;
• क्लाउड एज - क्लाउडमध्ये विनंतीवर प्रक्रिया करण्यासाठी क्रमांक आणि वेळ.

हे सर्व एकाच पाइपलाइनमध्ये एकत्रित केले जाते, आणि गरजांनुसार, अधिक तपशीलवार निदानासाठी कोणते मेट्रिक्स रिअल-टाइम ॲनालिटिक्सला पाठवायचे आणि कोणते इलास्टिकसर्च किंवा बिग डेटाला पाठवायचे हे आम्ही ठरवतो.

आम्ही निरीक्षण करतो

आमच्या बाबतीत, आम्ही क्लायंट आणि सर्व्हरमधील विनंत्यांच्या गंभीर मार्गावर बदल करत आहोत. त्याच वेळी, क्लायंटवर, सर्व्हरवर आणि इंटरनेटच्या मार्गावर वेगवेगळ्या घटकांची संख्या प्रचंड आहे. क्लायंट आणि सर्व्हरवरील बदल सतत घडतात - डझनभर संघांच्या कार्यादरम्यान आणि इकोसिस्टममधील नैसर्गिक बदल. आम्ही मध्यभागी आहोत - समस्यांचे निदान करताना, आम्ही सहभागी होण्याची चांगली संधी आहे. म्हणून, समस्यांना द्रुतपणे वेगळे करण्यासाठी मेट्रिक्सची व्याख्या, संकलन आणि विश्लेषण कसे करावे हे आम्हाला स्पष्टपणे समजून घेणे आवश्यक आहे.

आदर्शपणे, रिअल टाइममध्ये सर्व प्रकारच्या मेट्रिक्स आणि फिल्टरमध्ये पूर्ण प्रवेश. परंतु तेथे बरेच मेट्रिक्स आहेत, म्हणून खर्चाचा प्रश्न उद्भवतो. आमच्या बाबतीत, आम्ही खालीलप्रमाणे मेट्रिक्स आणि विकास साधने विभक्त करतो:

समस्या शोधण्यासाठी आणि ट्रायज करण्यासाठी आम्ही आमची स्वतःची ओपन-सोर्स रिअल-टाइम सिस्टम वापरतो नकाशांचे पुस्तक и लुमेन - व्हिज्युअलायझेशनसाठी. हे मेमरीमध्ये एकत्रित मेट्रिक्स संचयित करते, विश्वसनीय आहे आणि अलर्टिंग सिस्टमसह समाकलित होते. स्थानिकीकरण आणि निदानासाठी, आम्हाला इलास्टिकसर्च आणि किबाना मधील लॉगमध्ये प्रवेश आहे. सांख्यिकीय विश्लेषण आणि मॉडेलिंगसाठी, आम्ही टेब्लाऊमध्ये मोठा डेटा आणि व्हिज्युअलायझेशन वापरतो.

असे दिसते की या दृष्टिकोनासह कार्य करणे खूप कठीण आहे. तथापि, पदानुक्रमानुसार मेट्रिक्स आणि साधने आयोजित करून, आम्ही त्वरीत समस्येचे विश्लेषण करू शकतो, समस्येचा प्रकार निर्धारित करू शकतो आणि नंतर तपशीलवार मेट्रिक्समध्ये ड्रिल करू शकतो. सर्वसाधारणपणे, आम्ही ब्रेकडाउनचे स्त्रोत ओळखण्यासाठी सुमारे 1-2 मिनिटे घालवतो. यानंतर, आम्ही डायग्नोस्टिक्सवर विशिष्ट कार्यसंघासह कार्य करतो - दहा मिनिटांपासून कित्येक तासांपर्यंत.

निदान त्वरीत झाले असले तरी, असे वारंवार घडू नये असे आम्हाला वाटते. आदर्शपणे, जेव्हा सेवेवर लक्षणीय परिणाम होईल तेव्हाच आम्हाला एक गंभीर सूचना मिळेल. आमच्या क्वेरी प्रवेग प्रणालीसाठी, आमच्याकडे फक्त 2 सूचना आहेत ज्या सूचित करतील:

• क्लायंट फॉलबॅक टक्केवारी - ग्राहकांच्या वर्तनाचे मूल्यांकन;
• टक्केवारी प्रोब त्रुटी - नेटवर्क घटकांचा स्थिरता डेटा.

या गंभीर सूचना प्रणाली बहुसंख्य वापरकर्त्यांसाठी कार्य करत आहे की नाही यावर लक्ष ठेवतात. विनंती प्रवेग प्राप्त करण्यात अक्षम असल्यास किती क्लायंटने फॉलबॅक वापरले ते आम्ही पाहतो. सिस्टममध्ये बरेच बदल होत असले तरीही आम्ही दर आठवड्याला सरासरी 1 पेक्षा कमी गंभीर इशारा देतो. हे आमच्यासाठी पुरेसे का आहे?

1. आमची प्रॉक्सी काम करत नसल्यास क्लायंट फॉलबॅक आहे.
2. एक स्वयंचलित स्टीयरिंग सिस्टम आहे जी समस्यांना प्रतिसाद देते.

नंतरचे अधिक तपशील. आमची चाचणी प्रणाली आणि क्लायंटकडून क्लाउडकडे येणाऱ्या विनंत्यांसाठी इष्टतम मार्ग स्वयंचलितपणे निर्धारित करणारी प्रणाली, आम्हाला काही समस्यांना आपोआप सामोरे जाण्याची परवानगी देते.

चला आमच्या नमुना कॉन्फिगरेशन आणि 3 पथ श्रेणींवर परत येऊ. लोडिंग वेळेव्यतिरिक्त, आम्ही वितरणाची वस्तुस्थिती देखील पाहू शकतो. डेटा लोड करणे शक्य नसल्यास, वेगवेगळ्या मार्गांवरील परिणाम पाहून आम्ही कुठे आणि काय खंडित झाले हे ठरवू शकतो आणि विनंती मार्ग बदलून आम्ही स्वयंचलितपणे त्याचे निराकरण करू शकतो की नाही.

उदाहरणे:

ही प्रक्रिया स्वयंचलित केली जाऊ शकते. स्टीयरिंग सिस्टममध्ये ते समाविष्ट करा. आणि कार्यप्रदर्शन आणि विश्वासार्हतेच्या समस्यांना प्रतिसाद देण्यास शिकवा. जर एखादी गोष्ट तुटायला लागली, तर चांगला पर्याय असल्यास प्रतिक्रिया द्या. त्याच वेळी, क्लायंटच्या फॉलबॅकबद्दल धन्यवाद, त्वरित प्रतिक्रिया गंभीर नाही.

अशा प्रकारे, सिस्टम समर्थनाची तत्त्वे खालीलप्रमाणे तयार केली जाऊ शकतात:

• ब्रेकडाउनचे प्रमाण कमी करणे;
• मेट्रिक्स गोळा करणे;
• आम्ही शक्य असल्यास आपोआप ब्रेकडाउन दुरुस्त करतो;
• हे शक्य नसल्यास, आम्ही तुम्हाला सूचित करतो;
• द्रुत प्रतिसादासाठी आम्ही डॅशबोर्ड आणि ट्रायज टूलसेटवर काम करत आहोत.

शिकलेले धडे

प्रोटोटाइप लिहायला जास्त वेळ लागत नाही. आमच्या बाबतीत, ते 4 महिन्यांनंतर तयार होते. त्याच्यासह आम्हाला नवीन मेट्रिक्स प्राप्त झाले आणि विकासाच्या सुरुवातीच्या 10 महिन्यांनंतर आम्हाला प्रथम उत्पादन वाहतूक प्राप्त झाली. मग कंटाळवाणे आणि अतिशय कठीण काम सुरू झाले: हळूहळू सिस्टीमचे उत्पादन आणि स्केल करा, मुख्य रहदारी स्थलांतरित करा आणि चुकांमधून शिका. तथापि, ही प्रभावी प्रक्रिया रेखीय होणार नाही - सर्व प्रयत्न करूनही, सर्वकाही अंदाज लावता येत नाही. त्वरीत पुनरावृत्ती करणे आणि नवीन डेटाला प्रतिसाद देणे अधिक प्रभावी आहे.

आमच्या अनुभवावर आधारित, आम्ही खालील शिफारस करू शकतो:

1. आपल्या अंतर्ज्ञानावर विश्वास ठेवू नका.

   आमच्या कार्यसंघ सदस्यांचा प्रचंड अनुभव असूनही आमची अंतर्ज्ञान आम्हाला सतत अपयशी ठरली. उदाहरणार्थ, आम्ही CDN प्रॉक्सी किंवा TCP Anycast च्या वर्तनातून अपेक्षित गतीचा अंदाज चुकीचा वर्तवला आहे.

2. उत्पादनातून डेटा मिळवा.

   कमीतकमी थोड्या प्रमाणात उत्पादन डेटामध्ये शक्य तितक्या लवकर प्रवेश मिळवणे महत्वाचे आहे. प्रयोगशाळेच्या परिस्थितीत अद्वितीय केस, कॉन्फिगरेशन आणि सेटिंग्जची संख्या प्राप्त करणे जवळजवळ अशक्य आहे. परिणामांमध्ये द्रुत प्रवेश आपल्याला संभाव्य समस्यांबद्दल द्रुतपणे जाणून घेण्यास आणि सिस्टम आर्किटेक्चरमध्ये त्यांना विचारात घेण्यास अनुमती देईल.

3. इतर लोकांच्या सल्ल्या आणि परिणामांचे अनुसरण करू नका - तुमचा स्वतःचा डेटा गोळा करा.

   डेटा संकलित आणि विश्लेषणासाठी तत्त्वे पाळा, परंतु इतर लोकांचे निकाल आणि विधाने आंधळेपणाने स्वीकारू नका. तुमच्या वापरकर्त्यांसाठी नेमके काय काम करते हे फक्त तुम्हीच जाणून घेऊ शकता. तुमची प्रणाली आणि तुमचे ग्राहक इतर कंपन्यांपेक्षा लक्षणीय भिन्न असू शकतात. सुदैवाने, विश्लेषण साधने आता उपलब्ध आहेत आणि वापरण्यास सोपी आहेत. तुम्हाला मिळणारे परिणाम Netflix, Facebook, Akamai आणि इतर कंपन्या दावा करतात तसे नसतील. आमच्या बाबतीत, TLS, HTTP2 चे कार्यप्रदर्शन किंवा DNS विनंत्यांवरील आकडेवारी फेसबुक, Uber, Akamai च्या परिणामांपेक्षा भिन्न आहे - कारण आमच्याकडे भिन्न उपकरणे, क्लायंट आणि डेटा प्रवाह आहेत.

4. फॅशन ट्रेंडचे अनावश्यकपणे अनुसरण करू नका आणि परिणामकारकतेचे मूल्यांकन करा.

   सोपी सुरुवात करा. आपल्याला आवश्यक नसलेले घटक विकसित करण्यात बराच वेळ घालवण्यापेक्षा कमी वेळात एक साधी कार्यप्रणाली बनवणे चांगले आहे. तुमची मोजमाप आणि परिणामांवर आधारित कार्ये आणि समस्या सोडवा.

5. नवीन अनुप्रयोगांसाठी सज्ज व्हा.

   ज्याप्रमाणे सर्व समस्यांचा अंदाज लावणे कठीण आहे, त्याचप्रमाणे फायदे आणि अनुप्रयोगांचा आगाऊ अंदाज लावणे कठीण आहे. स्टार्टअप्सकडून एक संकेत घ्या - ग्राहकांच्या परिस्थितीशी जुळवून घेण्याची त्यांची क्षमता. तुमच्या बाबतीत, तुम्हाला नवीन समस्या आणि त्यांचे निराकरण सापडेल. आमच्या प्रकल्पामध्ये, आम्ही विनंतीची विलंबता कमी करण्याचे ध्येय ठेवले आहे. तथापि, विश्लेषण आणि चर्चा दरम्यान, आम्हाला समजले की आम्ही प्रॉक्सी सर्व्हर देखील वापरू शकतो:

   • AWS क्षेत्रांमध्ये रहदारी संतुलित करण्यासाठी आणि खर्च कमी करण्यासाठी;
   • CDN स्थिरता मॉडेल करण्यासाठी;
   • DNS कॉन्फिगर करण्यासाठी;
   • TLS/TCP कॉन्फिगर करण्यासाठी.

निष्कर्ष

अहवालात, मी नेटफ्लिक्स क्लायंट आणि क्लाउडमधील इंटरनेट विनंत्या वेगवान करण्याच्या समस्येचे निराकरण कसे करते याचे वर्णन केले आहे. क्लायंटवरील सॅम्पलिंग सिस्टीमचा वापर करून आम्ही डेटा कसा संकलित करतो आणि क्लायंटच्या उत्पादन विनंत्या इंटरनेटवरील सर्वात वेगवान मार्गाने मार्गस्थ करण्यासाठी गोळा केलेला ऐतिहासिक डेटा कसा वापरतो. हे कार्य साध्य करण्यासाठी आम्ही नेटवर्क प्रोटोकॉल, आमची CDN इन्फ्रास्ट्रक्चर, बॅकबोन नेटवर्क आणि DNS सर्व्हरची तत्त्वे कशी वापरतो.

तथापि, आमचे समाधान हे फक्त नेटफ्लिक्सवर अशी प्रणाली कशी लागू केली याचे उदाहरण आहे. आमच्यासाठी काय काम केले. तुमच्यासाठी माझ्या अहवालाचा लागू केलेला भाग म्हणजे विकास आणि समर्थनाची तत्त्वे ज्यांचे आम्ही पालन करतो आणि चांगले परिणाम साध्य करतो.

समस्येचे आमचे निराकरण कदाचित तुम्हाला अनुकूल नसेल. तथापि, तुमची स्वतःची CDN इन्फ्रास्ट्रक्चर नसली तरीही किंवा ती आमच्यापेक्षा लक्षणीयरीत्या वेगळी असली तरीही सिद्धांत आणि डिझाइन तत्त्वे कायम आहेत.

व्यवसाय विनंत्यांच्या गतीचे महत्त्व देखील महत्त्वाचे आहे. आणि अगदी साध्या सेवेसाठीही तुम्हाला निवड करणे आवश्यक आहे: क्लाउड प्रदाते, सर्व्हरचे स्थान, CDN आणि DNS प्रदाते. तुमची निवड तुमच्या ग्राहकांसाठी इंटरनेट क्वेरीच्या परिणामकारकतेवर परिणाम करेल. आणि हा प्रभाव मोजणे आणि समजून घेणे आपल्यासाठी महत्वाचे आहे.

सोप्या उपायांसह प्रारंभ करा, आपण उत्पादन कसे बदलता याची काळजी घ्या. तुम्ही जाता जाता शिका आणि तुमच्या ग्राहकांकडील डेटा, तुमच्या पायाभूत सुविधा आणि तुमच्या व्यवसायाच्या आधारे सिस्टम सुधारा. डिझाइन प्रक्रियेदरम्यान अनपेक्षित ब्रेकडाउनच्या शक्यतेबद्दल विचार करा. आणि मग तुम्ही तुमची विकास प्रक्रिया वेगवान करू शकता, समाधानाची कार्यक्षमता सुधारू शकता, अनावश्यक समर्थन ओझे टाळू शकता आणि शांतपणे झोपू शकता.

या वर्षी ही परिषद 6 ते 10 जुलै दरम्यान होणार आहे ऑनलाइन स्वरूपात. तुम्ही DevOps च्या वडिलांपैकी एकाला, जॉन विलिस यांना प्रश्न विचारू शकता!

स्त्रोत: www.habr.com