इन्टरनेट अनुरोधहरूको गति बढाउनुहोस् र शान्तिपूर्वक सुत्नुहोस्

नेटफ्लिक्स इन्टरनेट टेलिभिजन बजारमा अग्रणी हो - यो खण्ड सिर्जना गर्ने र सक्रिय रूपमा विकास गर्ने कम्पनी। नेटफ्लिक्स ग्रहको लगभग हरेक कुनाबाट उपलब्ध चलचित्र र टिभी शृङ्खलाहरूको विस्तृत सूची र डिस्प्ले भएको कुनै पनि उपकरणका लागि मात्र नभई यसको भरपर्दो पूर्वाधार र अद्वितीय इन्जिनियरिङ संस्कृतिका लागि पनि परिचित छ।

जटिल प्रणालीहरूको विकास र समर्थन गर्न नेटफ्लिक्स दृष्टिकोणको स्पष्ट उदाहरण DevOops 2019 मा प्रस्तुत गरिएको थियो। सर्गेई फेदोरोव - Netflix मा विकास निर्देशक। निजनी नोभगोरोड स्टेट युनिभर्सिटीको कम्प्युटेशनल गणित र गणित संकायको स्नातक। Lobachevsky, Sergey Open Connect मा पहिलो इन्जिनियरहरू मध्ये एक - Netflix मा CDN टोली। उनले भिडियो डेटाको निगरानी र विश्लेषणका लागि प्रणालीहरू निर्माण गरे, इन्टरनेट जडान गति FAST.com मापन गर्न लोकप्रिय सेवा सुरु गरे, र नेटफ्लिक्स अनुप्रयोगले प्रयोगकर्ताहरूका लागि सकेसम्म चाँडो काम गर्न इन्टरनेट अनुरोधहरू अनुकूलन गर्ने काममा विगत केही वर्षदेखि काम गरिरहेको छ।

रिपोर्टले सम्मेलनका सहभागीहरूबाट उत्कृष्ट समीक्षाहरू प्राप्त गर्यो, र हामीले तपाईंको लागि पाठ संस्करण तयार गरेका छौं।

आफ्नो रिपोर्ट मा, सर्गेई विस्तृत कुरा गरे

• ग्राहक र सर्भर बीचको इन्टरनेट अनुरोधको ढिलाइलाई के असर गर्छ भन्ने बारे;
• यो ढिलाइ कसरी कम गर्ने;
• त्रुटि-सहनशील प्रणालीहरू कसरी डिजाइन, मर्मत र निगरानी गर्ने;
• कसरी छोटो समयमा परिणाम प्राप्त गर्न, र व्यापार को लागी न्यूनतम जोखिम संग;
• कसरी परिणामहरू विश्लेषण गर्ने र गल्तीहरूबाट सिक्ने।

यी प्रश्नहरूको जवाफ ठूला निगमहरूमा काम गर्नेहरूले मात्र होइन।

प्रस्तुत सिद्धान्तहरू र प्रविधिहरू इन्टरनेट उत्पादनहरू विकास र समर्थन गर्ने सबैले जान्नु पर्छ र अभ्यास गर्नुपर्छ।

अर्को वक्ताको दृष्टिकोणबाट कथन हो।

इन्टरनेट गति को महत्व

इन्टरनेट अनुरोध को गति सीधा व्यापार संग सम्बन्धित छ। किनमेल उद्योगलाई विचार गर्नुहोस्: 2009 मा Amazon बोल्योकि 100ms ढिलाइले बिक्रीको 1% हानिमा परिणाम दिन्छ।

त्यहाँ धेरै र अधिक मोबाइल उपकरणहरू छन्, पछि मोबाइल साइटहरू र अनुप्रयोगहरू। यदि तपाईंको पृष्ठले लोड हुन ३ सेकेन्डभन्दा बढी समय लिन्छ भने, तपाईंले आफ्ना आधा प्रयोगकर्ताहरू गुमाउँदै हुनुहुन्छ। साथ जुलाई २०२१ Google ले खोज परिणामहरूमा तपाईंको पृष्ठको लोडिङ गतिलाई ध्यानमा राख्छ: पृष्ठ जति छिटो हुन्छ, Google मा यसको स्थान उति नै उच्च हुन्छ।

वित्तीय संस्थाहरूमा जडान गति पनि महत्त्वपूर्ण छ जहाँ विलम्बता महत्त्वपूर्ण छ। 2015 मा, Hibernia Networks समाप्त न्यूयोर्क र लन्डन बीच $ 400 मिलियन केबल सहरहरू बीचको विलम्बता 6ms ले कम गर्न। 66 एमएस विलम्बता घटाउनको लागि $1 मिलियन कल्पना गर्नुहोस्!

अनुसार अनुसन्धान, 5 Mbit/s भन्दा माथिको जडान गतिले अब सामान्य वेबसाइटको लोडिङ गतिलाई प्रत्यक्ष असर गर्दैन। यद्यपि, त्यहाँ जडान विलम्बता र पृष्ठ लोड गति बीच एक रैखिक सम्बन्ध छ:

यद्यपि, नेटफ्लिक्स सामान्य उत्पादन होइन। प्रयोगकर्ता मा विलम्बता र गति को प्रभाव विश्लेषण र विकास को एक सक्रिय क्षेत्र हो। त्यहाँ अनुप्रयोग लोड र सामग्री चयन छ जुन विलम्बतामा निर्भर गर्दछ, तर स्थिर तत्वहरू लोड गर्दै र स्ट्रिमिङ पनि जडान गतिमा निर्भर गर्दछ। प्रयोगकर्ता अनुभवलाई प्रभाव पार्ने मुख्य कारकहरूको विश्लेषण र अनुकूलन नेटफ्लिक्समा धेरै टोलीहरूको लागि विकासको सक्रिय क्षेत्र हो। एउटा लक्ष्य भनेको Netflix उपकरणहरू र क्लाउड पूर्वाधारहरू बीचको अनुरोधहरूको विलम्बता कम गर्नु हो।

प्रतिवेदनमा हामी नेटफ्लिक्स पूर्वाधारको उदाहरण प्रयोग गरेर विलम्बता कम गर्नमा विशेष ध्यान केन्द्रित गर्नेछौं। जटिल वितरण प्रणालीहरूको डिजाइन, विकास र सञ्चालनका प्रक्रियाहरू कसरी पुग्ने र परिचालन समस्याहरू र ब्रेकडाउनहरूको निदान गर्नुको सट्टा नवाचार र परिणामहरूमा समय खर्च गर्ने व्यावहारिक दृष्टिकोणबाट विचार गरौं।

Netflix भित्र

हजारौं विभिन्न यन्त्रहरूले Netflix एपहरूलाई समर्थन गर्छन्। तिनीहरू एन्ड्रोइड, आईओएस, टिभी र वेब ब्राउजरहरूको लागि ग्राहकको अलग-अलग संस्करणहरू बनाउने चार फरक टोलीहरूद्वारा विकसित गरिएका छन्। र हामी प्रयोगकर्ता अनुभव सुधार गर्न र निजीकृत गर्न धेरै प्रयास खर्च गर्छौं। यो गर्नको लागि, हामी समानान्तर रूपमा सयौं A/B परीक्षणहरू चलाउँछौं।

निजीकरण AWS क्लाउडमा सयौं माइक्रो सेवाहरूद्वारा समर्थित छ, व्यक्तिगत प्रयोगकर्ता डेटा, क्वेरी प्रेषण, टेलिमेट्री, बिग डाटा र एन्कोडिङ प्रदान गर्दै। ट्राफिक भिजुअलाइजेशन यस्तो देखिन्छ:

प्रदर्शनको साथ भिडियोको लिङ्क (6:04-6:23)

बाँयामा प्रवेश बिन्दु हो, र त्यसपछि ट्राफिक धेरै सय माइक्रो सेवाहरू बीच वितरण गरिन्छ जुन विभिन्न ब्याकएन्ड टोलीहरू द्वारा समर्थित छन्।

हाम्रो पूर्वाधारको अर्को महत्त्वपूर्ण भाग ओपन कनेक्ट CDN हो, जसले अन्तिम प्रयोगकर्तालाई स्थिर सामग्री प्रदान गर्दछ - भिडियोहरू, छविहरू, क्लाइन्ट कोड, आदि। CDN अनुकूलन सर्भरहरूमा अवस्थित छ (OCA - Open Connect Appliance)। भित्र NGINX र सेवाहरूको सेटको साथ, अनुकूलित FreeBSD चलिरहेको SSD र HDD ड्राइभहरूको एरेहरू छन्। हामी हार्डवेयर र सफ्टवेयर कम्पोनेन्टहरू डिजाइन र अप्टिमाइज गर्छौं ताकि यस्तो CDN सर्भरले प्रयोगकर्ताहरूलाई सकेसम्म धेरै डेटा पठाउन सक्छ।

इन्टरनेट ट्राफिक एक्सचेन्ज पोइन्ट (इन्टरनेट एक्सचेन्ज - IX) मा यी सर्भरहरूको "पर्खाल" यस्तो देखिन्छ:

इन्टरनेट एक्सचेन्जले इन्टरनेट सेवा प्रदायकहरू र सामग्री प्रदायकहरूलाई एकअर्कासँग "जडान" गर्न सक्ने क्षमता प्रदान गर्दछ जसले इन्टरनेटमा डाटा आदान प्रदान गर्दछ। त्यहाँ संसारभरि लगभग 70-80 इन्टरनेट एक्सचेन्ज पोइन्टहरू छन् जहाँ हाम्रा सर्भरहरू स्थापना गरिएका छन्, र हामी तिनीहरूलाई स्वतन्त्र रूपमा स्थापना र मर्मत गर्छौं:

थप रूपमा, हामी इन्टरनेट प्रदायकहरूलाई सीधा सर्भरहरू पनि प्रदान गर्दछौं, जुन तिनीहरूले आफ्नो नेटवर्कमा स्थापना गर्छन्, Netflix ट्राफिकको स्थानीयकरण र प्रयोगकर्ताहरूको लागि स्ट्रिमिङको गुणस्तर सुधार गर्दै:

AWS सेवाहरूको सेट ग्राहकहरूबाट CDN सर्भरहरूमा भिडियो अनुरोधहरू पठाउन, साथै सर्भरहरू आफैं कन्फिगर गर्ने - सामग्री, कार्यक्रम कोड, सेटिङहरू, आदि अपडेट गर्न जिम्मेवार छ। पछिल्लोका लागि, हामीले इन्टरनेट एक्सचेन्ज पोइन्टहरूमा AWS सँग सर्भरहरू जडान गर्ने ब्याकबोन नेटवर्क पनि निर्माण गरेका छौं। ब्याकबोन नेटवर्क फाइबर अप्टिक केबल र राउटरहरूको विश्वव्यापी नेटवर्क हो जसलाई हामीले हाम्रो आवश्यकताको आधारमा डिजाइन र कन्फिगर गर्न सक्छौं।

द्वारा Sandvine अनुमान, हाम्रो CDN पूर्वाधारले विश्वको इन्टरनेट ट्राफिकको लगभग ⅛ पीक घण्टा र ⅓ उत्तर अमेरिकामा ट्राफिक प्रदान गर्दछ, जहाँ Netflix सबैभन्दा लामो समयदेखि रहेको छ। प्रभावशाली संख्याहरू, तर मेरो लागि सबैभन्दा अचम्मको उपलब्धि भनेको यो हो कि सम्पूर्ण CDN प्रणाली 150 भन्दा कम व्यक्तिहरूको टोलीद्वारा विकसित र मर्मत गरिएको हो।

सुरुमा, CDN पूर्वाधार भिडियो डेटा डेलिभर गर्न डिजाइन गरिएको थियो। यद्यपि, समयको साथ हामीले महसुस गर्यौं कि हामी AWS क्लाउडमा ग्राहकहरूबाट गतिशील अनुरोधहरू अनुकूलन गर्न पनि यसलाई प्रयोग गर्न सक्छौं।

इन्टरनेटको गति बढाउने बारेमा

आज, Netflix सँग 3 AWS क्षेत्रहरू छन्, र क्लाउडमा अनुरोधहरूको विलम्बता ग्राहक नजिकको क्षेत्रबाट कति टाढा छ भन्नेमा निर्भर हुनेछ। एकै समयमा, हामीसँग धेरै CDN सर्भरहरू छन् जुन स्थिर सामग्री डेलिभर गर्न प्रयोग गरिन्छ। के त्यहाँ गतिशील प्रश्नहरूको गति बढाउन यो फ्रेमवर्क प्रयोग गर्ने कुनै तरिका छ? यद्यपि, दुर्भाग्यवश, यी अनुरोधहरूलाई क्यास गर्न असम्भव छ - API हरू निजीकृत छन् र प्रत्येक परिणाम अद्वितीय छ।

CDN सर्भरमा प्रोक्सी बनाउनुहोस् र यसको माध्यमबाट ट्राफिक पठाउन सुरु गर्नुहोस्। यो छिटो हुनेछ?

मटेरियल

सञ्जाल प्रोटोकलहरूले कसरी काम गर्छ भनेर सम्झौं। आज, इन्टरनेटमा धेरैजसो ट्राफिकले HTTPs प्रयोग गर्दछ, जुन तल्लो तह प्रोटोकल TCP र TLS मा निर्भर गर्दछ। क्लाइन्टलाई सर्भरमा जडान गर्नको लागि, यसले ह्यान्डशेक गर्छ, र सुरक्षित जडान स्थापना गर्न, ग्राहकले सर्भरसँग सन्देशहरू तीन पटक र डाटा स्थानान्तरण गर्न कम्तिमा एक पटक आदान प्रदान गर्नुपर्छ। 100 ms को प्रति राउन्ड ट्रिप (RTT) लेटेन्सी संग, यो डेटा को पहिलो बिट प्राप्त गर्न हामीलाई 400 ms लाग्नेछ:

यदि हामीले प्रमाणपत्रहरू CDN सर्भरमा राख्यौं भने, यदि CDN नजिक छ भने ग्राहक र सर्भर बीचको ह्यान्डसेक समयलाई उल्लेखनीय रूपमा कम गर्न सकिन्छ। मानौं CDN सर्भरको विलम्बता 30ms छ। त्यसपछि पहिलो बिट प्राप्त गर्न 220 ms लाग्नेछ:

तर फाइदाहरू त्यहाँ समाप्त हुँदैन। एक पटक जडान स्थापित भएपछि, TCP ले भीडभाड सञ्झ्याल बढाउँछ (समानान्तरमा त्यो जडानमा प्रसारण गर्न सक्ने जानकारीको मात्रा)। यदि डेटा प्याकेट हराएको छ भने, तब TCP प्रोटोकल (जस्तै TCP नयाँ रेनो) को क्लासिक कार्यान्वयनले खुला "विन्डो" आधाले घटाउँछ। भीडभाड सञ्झ्यालको वृद्धि, र क्षतिबाट पुन: प्राप्तिको गति सर्भरमा ढिलाइ (RTT) मा निर्भर गर्दछ। यदि यो जडान CDN सर्भर सम्म मात्र जान्छ भने, यो रिकभरी छिटो हुनेछ। एकै समयमा, प्याकेट हानि एक मानक घटना हो, विशेष गरी ताररहित नेटवर्कहरूको लागि।

इन्टरनेट ब्यान्डविथ कम हुन सक्छ, विशेष गरी पीक घण्टामा, प्रयोगकर्ताहरूको ट्राफिकको कारण, जसले ट्राफिक जाम निम्त्याउन सक्छ। यद्यपि, इन्टरनेटमा केही अनुरोधहरूलाई अरूलाई प्राथमिकता दिने कुनै तरिका छैन। उदाहरणका लागि, नेटवर्क लोड गर्ने "भारी" डेटा स्ट्रिमहरूमा साना र विलम्बता-संवेदनशील अनुरोधहरूलाई प्राथमिकता दिनुहोस्। यद्यपि, हाम्रो मामलामा, हाम्रो आफ्नै ब्याकबोन नेटवर्क भएकोले हामीलाई अनुरोध मार्गको अंशमा यो गर्न अनुमति दिन्छ - CDN र क्लाउड बीच, र हामी यसलाई पूर्ण रूपमा कन्फिगर गर्न सक्छौं। तपाईं साना र विलम्बता-संवेदनशील प्याकेटहरू प्राथमिकतामा छन् भनेर सुनिश्चित गर्न सक्नुहुन्छ, र ठूला डाटा प्रवाहहरू थोरै पछि जान्छन्। CDN ग्राहकसँग जति नजिक छ, दक्षता त्यति नै बढी हुन्छ।

अनुप्रयोग स्तर प्रोटोकलहरू (OSI स्तर 7) ले विलम्बतामा पनि प्रभाव पार्छ। नयाँ प्रोटोकलहरू जस्तै HTTP/2 समानान्तर अनुरोधहरूको प्रदर्शनलाई अनुकूलन गर्दछ। यद्यपि, हामीसँग नेटफ्लिक्स क्लाइन्टहरू छन् जुन नयाँ प्रोटोकलहरूलाई समर्थन गर्दैनन्। सबै ग्राहकहरू अद्यावधिक वा इष्टतम कन्फिगर गर्न सकिँदैन। एकै समयमा, CDN प्रोक्सी र क्लाउड बीचमा पूर्ण नियन्त्रण र नयाँ, इष्टतम प्रोटोकल र सेटिङहरू प्रयोग गर्ने क्षमता छ। पुरानो प्रोटोकलको साथ अप्रभावी भाग ग्राहक र CDN सर्भर बीच मात्र सञ्चालन हुनेछ। यसबाहेक, हामी CDN र क्लाउड बीच पहिले नै स्थापित जडानमा मल्टिप्लेक्स अनुरोधहरू गर्न सक्छौं, TCP स्तरमा जडान उपयोगमा सुधार गर्दै:

हामी नाप्छौं

सिद्धान्तले सुधारको प्रतिज्ञा गरेको तथ्यको बावजुद, हामी तुरुन्तै उत्पादनमा प्रणाली सुरु गर्न हतार गर्दैनौं। बरु, हामीले पहिले यो सिद्ध गर्नुपर्दछ कि विचार व्यवहारमा काम गर्दछ। यो गर्नका लागि तपाईंले धेरै प्रश्नहरूको जवाफ दिन आवश्यक छ:

• गति: प्रोक्सी छिटो हुनेछ?
• विश्वसनीयता: के यो धेरै पटक भाँचिन्छ?
• जटिलता: अनुप्रयोगहरूसँग कसरी एकीकृत गर्ने?
• को लागत: थप पूर्वाधार निर्माण गर्न कति खर्च लाग्छ?

पहिलो बिन्दु मूल्याङ्कन गर्न हाम्रो दृष्टिकोणलाई विस्तारमा विचार गरौं। बाँकीलाई पनि त्यस्तै तरिकाले व्यवहार गरिन्छ।

अनुरोधहरूको गतिको विश्लेषण गर्न, हामी विकासमा धेरै समय खर्च नगरी र उत्पादन तोड्न बिना सबै प्रयोगकर्ताहरूको डेटा प्राप्त गर्न चाहन्छौं। यसको लागि धेरै दृष्टिकोणहरू छन्:

1. RUM, वा निष्क्रिय अनुरोध मापन। हामी प्रयोगकर्ताहरूबाट हालका अनुरोधहरूको कार्यान्वयन समय मापन गर्छौं र पूर्ण प्रयोगकर्ता कभरेज सुनिश्चित गर्छौं। हानि यो हो कि संकेत धेरै कारकहरु को कारण धेरै स्थिर छैन, उदाहरण को लागी, विभिन्न अनुरोध आकार को कारण, सर्भर र ग्राहक मा प्रशोधन समय। थप रूपमा, तपाईंले उत्पादनमा प्रभाव बिना नयाँ कन्फिगरेसन परीक्षण गर्न सक्नुहुन्न।
2. प्रयोगशाला परीक्षणहरू। विशेष सर्भर र पूर्वाधार जसले ग्राहकहरूलाई अनुकरण गर्दछ। तिनीहरूको सहयोगमा हामी आवश्यक परीक्षणहरू गर्छौं। यसरी हामीले मापन नतिजा र स्पष्ट संकेतमा पूर्ण नियन्त्रण पाउँछौं। तर त्यहाँ यन्त्रहरू र प्रयोगकर्ता स्थानहरूको पूर्ण कभरेज छैन (विशेष गरी विश्वव्यापी सेवा र हजारौं उपकरण मोडेलहरूको लागि समर्थन)।

तपाईं कसरी दुवै विधिहरूको फाइदाहरू संयोजन गर्न सक्नुहुन्छ?

हाम्रो टोलीले समाधान फेला पारेको छ। हामीले कोडको एउटा सानो टुक्रा लेख्यौं - एउटा नमूना - जुन हामीले हाम्रो अनुप्रयोगमा निर्माण गर्यौं। प्रोबहरूले हामीलाई हाम्रा यन्त्रहरूबाट पूर्ण रूपमा नियन्त्रित नेटवर्क परीक्षणहरू गर्न अनुमति दिन्छ। यो यस्तो काम गर्छ:

1. एप्लिकेसन लोड गरिसकेपछि र प्रारम्भिक गतिविधि पूरा गरेपछि, हामी हाम्रो प्रोबहरू चलाउँछौं।
2. ग्राहकले सर्भरलाई अनुरोध गर्दछ र परीक्षणको लागि "नुस्खा" प्राप्त गर्दछ। रेसिपी URL को एक सूची हो जसमा HTTP(हरू) अनुरोध गर्न आवश्यक छ। थप रूपमा, रेसिपीले अनुरोध प्यारामिटरहरू कन्फिगर गर्दछ: अनुरोधहरू बीचको ढिलाइ, अनुरोध गरिएको डेटाको मात्रा, HTTP(हरू) हेडरहरू, आदि। एकै समयमा, हामी समानान्तरमा धेरै फरक रेसिपीहरू परीक्षण गर्न सक्छौं - कन्फिगरेसन अनुरोध गर्दा, हामी अनियमित रूपमा कुन नुस्खा जारी गर्ने निर्धारण गर्छौं।
3. क्लाइन्टमा सञ्जाल स्रोतहरूको सक्रिय प्रयोगसँग द्वन्द्व नहोस् भनेर प्रोब प्रक्षेपण समय चयन गरिएको छ। अनिवार्य रूपमा, समय चयन गरिएको छ जब ग्राहक सक्रिय छैन।
4. नुस्खा प्राप्त गरेपछि, ग्राहकले समानान्तर रूपमा प्रत्येक URL लाई अनुरोध गर्दछ। प्रत्येक ठेगानामा अनुरोध दोहोर्याउन सकिन्छ - तथाकथित। "दाल"। पहिलो पल्समा, हामी जडान स्थापना गर्न र डाटा डाउनलोड गर्न कति समय लाग्यो मापन गर्छौं। दोस्रो पल्समा, हामी पहिले नै स्थापित जडानमा डाटा लोड गर्न लाग्ने समय मापन गर्छौं। तेस्रो एक अघि, हामी एक ढिलाइ सेट गर्न सक्छौं र पुन: जडान, आदि स्थापना को गति मापन गर्न सक्छौं।

   परीक्षणको क्रममा, हामी उपकरणले प्राप्त गर्न सक्ने सबै प्यारामिटरहरू मापन गर्छौं:

   • DNS अनुरोध समय;
   • TCP जडान सेटअप समय;
   • TLS जडान सेटअप समय;
   • डाटाको पहिलो बाइट प्राप्त गर्ने समय;
   • कुल लोड समय;
   • स्थिति परिणाम कोड।
5. सबै दालहरू पूरा भएपछि, नमूनाले विश्लेषणको लागि सबै मापनहरू लोड गर्दछ।

मुख्य बुँदाहरू ग्राहकमा तर्कमा न्यूनतम निर्भरता, सर्भरमा डाटा प्रोसेसिङ र समानान्तर अनुरोधहरूको मापन हो। यसरी, हामी क्वेरी कार्यसम्पादनलाई असर गर्ने विभिन्न कारकहरूको प्रभावलाई अलग गर्न र परीक्षण गर्न सक्षम छौं, तिनीहरूलाई एकल नुस्खा भित्र फरक पार्छौं, र वास्तविक ग्राहकहरूबाट परिणामहरू प्राप्त गर्दछौं।

यो पूर्वाधार केवल क्वेरी प्रदर्शन विश्लेषण भन्दा बढीको लागि उपयोगी साबित भएको छ। हाल हामीसँग 14 सक्रिय रेसिपीहरू छन्, प्रति सेकेन्ड 6000 भन्दा बढी नमूनाहरू, पृथ्वीको सबै कुनाहरूबाट डाटा प्राप्त गर्दै र पूर्ण उपकरण कभरेज। यदि नेटफ्लिक्सले तेस्रो पक्षबाट समान सेवा किनेको छ भने, यसले वर्षमा लाखौं डलर खर्च गर्नेछ, धेरै खराब कभरेजको साथ।

अभ्यासमा परीक्षण सिद्धान्त: प्रोटोटाइप

यस्तो प्रणालीको साथ, हामीले अनुरोध विलम्बतामा CDN प्रोक्सीहरूको प्रभावकारिता मूल्याङ्कन गर्न सक्षम भयौं। अब तपाईलाई चाहिन्छ:

• प्रोक्सी प्रोटोटाइप सिर्जना गर्नुहोस्;
• 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. केही बिग्रिएको थिएन।

प्रोटोटाइप २.०

त्यसोभए, रेखाचित्र बोर्डमा फर्कनुहोस् र प्रक्रियालाई फेरि दोहोर्याउनुहोस्।

विचार यो छ कि 100% प्रोक्सी प्रयोग गर्नुको सट्टा, हामी प्रत्येक ग्राहकको लागि द्रुत मार्ग निर्धारण गर्नेछौं, र हामी त्यहाँ अनुरोधहरू पठाउनेछौं - त्यो हो, हामी क्लाइन्ट स्टीयरिङ भनिने काम गर्नेछौं।

यसलाई कसरी कार्यान्वयन गर्ने ? हामी सर्भर साइडमा तर्क प्रयोग गर्न सक्दैनौं, किनभने... यो सर्भरमा जडान गर्ने लक्ष्य हो। ग्राहक मा यो गर्न को लागी केहि तरिका हुन आवश्यक छ। र आदर्श रूपमा, यो जटिल तर्कको न्यूनतम मात्राको साथ गर्नुहोस्, ताकि ठूलो संख्यामा क्लाइन्ट प्लेटफर्महरूसँग एकीकरणको समस्या समाधान नगर्नुहोस्।

जवाफ DNS प्रयोग गर्न हो। हाम्रो अवस्थामा, हामीसँग हाम्रो आफ्नै DNS पूर्वाधार छ, र हामी एक डोमेन क्षेत्र सेट अप गर्न सक्छौं जसको लागि हाम्रा सर्भरहरू अधिनायकवादी हुनेछन्। यो यस्तो काम गर्छ:

1. ग्राहकले होस्ट प्रयोग गरेर DNS सर्भरमा अनुरोध गर्दछ, उदाहरणका लागि api.netflix.xom।
2. अनुरोध हाम्रो DNS सर्भरमा आइपुग्छ
3. DNS सर्भरले यो क्लाइन्टको लागि कुन मार्ग सबैभन्दा छिटो छ भन्ने थाहा छ र सम्बन्धित IP ठेगाना जारी गर्दछ।

समाधानमा थप जटिलता छ: अधिनायकवादी DNS प्रदायकहरूले ग्राहकको आईपी ठेगाना देख्दैनन् र क्लाइन्टले प्रयोग गर्ने पुनरावृत्ति समाधानकर्ताको आईपी ठेगाना मात्र पढ्न सक्छन्।

नतिजाको रूपमा, हाम्रो अधिनायकवादी समाधानकर्ताले व्यक्तिगत ग्राहकको लागि होइन, तर पुनरावर्ती समाधानकर्ताको आधारमा ग्राहकहरूको समूहको लागि निर्णय गर्नुपर्छ।

समाधान गर्न, हामी समान नमूनाहरू प्रयोग गर्छौं, प्रत्येक पुनरावृत्ति समाधानकर्ताहरूको लागि क्लाइन्टहरूबाट मापन परिणामहरू जम्मा गर्छौं र तिनीहरूको यो समूह कहाँ पठाउने निर्णय गर्छौं - TCP Anycast प्रयोग गरेर IX मार्फत प्रोक्सी, ISP प्रोक्सी मार्फत वा सीधा क्लाउडमा।

हामीले निम्न प्रणाली पाउँछौं:

परिणामस्वरूप DNS स्टीयरिङ मोडेलले तपाईंलाई क्लाइन्टहरूबाट क्लाउडमा जडानको गतिको ऐतिहासिक अवलोकनको आधारमा ग्राहकहरूलाई निर्देशन दिन अनुमति दिन्छ।

फेरि, प्रश्न यो छ कि यो दृष्टिकोण कसरी प्रभावकारी काम गर्नेछ? जवाफ दिन, हामी फेरि हाम्रो जाँच प्रणाली प्रयोग गर्छौं। त्यसकारण, हामी प्रस्तुतकर्ता कन्फिगरेसन कन्फिगर गर्छौं, जहाँ एक लक्ष्यले DNS स्टीयरिङबाट दिशा पछ्याउँछ, अर्को सीधा क्लाउडमा जान्छ (हालको उत्पादन)।

नतिजाको रूपमा, हामी परिणामहरू तुलना गर्छौं र प्रभावकारिताको मूल्याङ्कन प्राप्त गर्छौं:

नतिजाको रूपमा, हामीले धेरै महत्त्वपूर्ण कुराहरू सिक्यौं:

1. हामीले DNS स्टीयरिङ प्रयोग गरेर क्लाउडमा क्लाउडमा गरिएका अनुरोधहरूको अपेक्षित कार्यसम्पादन मूल्याङ्कन गर्यौं।
2. हामीले सबै प्रकारका उपकरणहरूबाट वास्तविक ग्राहकहरूबाट डाटा प्राप्त गर्यौं।
3. प्रस्तावित विचारको प्रभावकारिता प्रमाणित भएको छ।
4. हामीले जोखिम उठाएनौं - हामीले ग्राहकहरूको लागि उत्पादन कन्फिगरेसनहरू परिवर्तन गरेका छैनौं।
5. केही बिग्रिएको थिएन।

अब गाह्रो भागको बारेमा - हामी यसलाई उत्पादनमा सुरू गर्छौं

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

र यी सबैसँग, टोलीसँग 3 इन्जिनियरहरू छन् जुन प्रणालीको विकास, तैनाती र पूर्ण समर्थनको लागि जिम्मेवार छन्।

त्यसैले, हामी शान्त र स्वस्थ निद्राको बारेमा कुरा गर्न जारी राख्नेछौं।

कसरी विकास जारी राख्ने र आफ्नो सबै समय समर्थन मा खर्च नगर्ने? हाम्रो दृष्टिकोण 3 सिद्धान्तहरूमा आधारित छ:

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

यो हाम्रो मामला मा, समस्या को लागी यो दृष्टिकोण संग, हामी एक सरल र प्रभावकारी समाधान पाउन सक्छौं र महत्त्वपूर्ण प्रणाली समर्थन सरल बनाउन सक्छ कि बाहिर गए। हामीले क्लाइन्टमा कोडको सानो टुक्रा थप्न सक्छौं र जडान समस्याहरूको कारणले नेटवर्क अनुरोध त्रुटिहरूको लागि निगरानी गर्न सक्छौं भन्ने महसुस गर्यौं। नेटवर्क त्रुटिहरूको अवस्थामा, हामी सीधा क्लाउडमा फलब्याक गर्छौं। यो समाधानले ग्राहक टोलीहरूको लागि महत्त्वपूर्ण प्रयासको आवश्यकता पर्दैन, तर हाम्रो लागि अप्रत्याशित ब्रेकडाउन र आश्चर्यको जोखिमलाई धेरै कम गर्छ।

अवश्य पनि, फलब्याकको बावजुद, हामी तैपनि विकासको क्रममा स्पष्ट अनुशासन पालना गर्छौं:

1. नमूना परीक्षण।
2. A/B परीक्षण वा क्यानरीहरू।
3. प्रगतिशील रोलआउट।

नमूनाहरूको साथ, दृष्टिकोण वर्णन गरिएको छ - परिवर्तनहरू पहिले अनुकूलित नुस्खा प्रयोग गरेर परीक्षण गरिन्छ।

क्यानरी परीक्षणको लागि, हामीले सर्भरहरूको तुलनात्मक जोडीहरू प्राप्त गर्न आवश्यक छ जसमा हामी परिवर्तनहरू अघि र पछि प्रणालीले कसरी काम गर्छ भनेर तुलना गर्न सक्छौं। यो गर्नका लागि, हाम्रा धेरै CDN साइटहरूबाट, हामी तुलनात्मक ट्राफिक प्राप्त गर्ने सर्भरहरूको जोडी चयन गर्छौं:

त्यसपछि हामी क्यानरी सर्भरमा परिवर्तनहरूको साथ निर्माण स्थापना गर्छौं। नतिजाहरू मूल्याङ्कन गर्न, हामी नियन्त्रण सर्भरहरूको नमूनासँग लगभग 100-150 मेट्रिक्स तुलना गर्ने प्रणाली चलाउँछौं:

यदि क्यानरी परीक्षण सफल भयो भने, हामी यसलाई क्रमशः छालहरूमा छोड्छौं। हामी प्रत्येक साइटमा एकै समयमा सर्भरहरू अद्यावधिक गर्दैनौं - समस्याहरूको कारणले गर्दा सम्पूर्ण साइट गुमाउनुले विभिन्न स्थानहरूमा एउटै संख्यामा सर्भरहरू गुमाउनु भन्दा प्रयोगकर्ताहरूको सेवामा बढी महत्त्वपूर्ण प्रभाव पार्छ।

सामान्यतया, यस दृष्टिकोणको प्रभावकारिता र सुरक्षा सङ्कलन मेट्रिक्सको मात्रा र गुणस्तरमा निर्भर गर्दछ। हाम्रो क्वेरी प्रवेग प्रणालीको लागि, हामी सबै सम्भावित घटकहरूबाट मेट्रिक्स सङ्कलन गर्छौं:

• ग्राहकहरूबाट - सत्र र अनुरोधहरूको संख्या, फलब्याक दरहरू;
• proxy - संख्या र अनुरोध को समय मा तथ्याङ्क;
• DNS - अनुरोधहरूको संख्या र परिणामहरू;
• क्लाउड किनारा - क्लाउडमा प्रशोधन अनुरोधहरूको लागि संख्या र समय।

यी सबै एउटै पाइपलाइनमा जम्मा गरिन्छ, र आवश्यकताहरूको आधारमा, हामी कुन मेट्रिकहरू वास्तविक-समय एनालिटिक्समा पठाउने निर्णय गर्छौं, र थप विस्तृत निदानको लागि कुन इलास्टिकसर्च वा बिग डाटामा पठाउने।

हामी निगरानी गर्छौं

हाम्रो मामला मा, हामी ग्राहक र सर्भर बीच अनुरोध को महत्वपूर्ण मार्ग मा परिवर्तन गर्दैछौं। एकै समयमा, ग्राहकमा, सर्भरमा, र इन्टरनेट मार्फत बाटोमा विभिन्न घटकहरूको संख्या ठूलो छ। ग्राहक र सर्भरमा परिवर्तनहरू लगातार हुन्छन् - दर्जनौं टोलीहरूको कामको क्रममा र इकोसिस्टममा प्राकृतिक परिवर्तनहरू। हामी बीचमा छौं - समस्याहरूको निदान गर्दा, हामी संलग्न हुने राम्रो मौका छ। त्यसकारण, हामीले समस्याहरूलाई द्रुत रूपमा अलग गर्न मेट्रिक्सलाई कसरी परिभाषित, सङ्कलन र विश्लेषण गर्ने भनेर स्पष्ट रूपमा बुझ्न आवश्यक छ।

आदर्श रूपमा, वास्तविक समयमा सबै प्रकारका मेट्रिक्स र फिल्टरहरूमा पूर्ण पहुँच। तर त्यहाँ धेरै मेट्रिकहरू छन्, त्यसैले लागतको प्रश्न उठ्छ। हाम्रो अवस्थामा, हामी निम्नानुसार मेट्रिक्स र विकास उपकरणहरू अलग गर्छौं:

समस्याहरू पत्ता लगाउन र ट्राइज गर्न हामी हाम्रो आफ्नै खुला स्रोत वास्तविक-समय प्रणाली प्रयोग गर्छौं एटलस и लुमेन - दृश्य को लागी। यसले मेमोरीमा एकत्रित मेट्रिक्स भण्डारण गर्दछ, विश्वसनीय छ र चेतावनी प्रणालीसँग एकीकृत गर्दछ। स्थानीयकरण र निदानका लागि, हामीसँग Elasticsearch र Kibana बाट लगहरूमा पहुँच छ। सांख्यिकीय विश्लेषण र मोडलिङको लागि, हामी Tableau मा ठूलो डेटा र दृश्य प्रयोग गर्दछौं।

यस्तो देखिन्छ कि यो दृष्टिकोण संग काम गर्न धेरै गाह्रो छ। यद्यपि, मेट्रिक्स र उपकरणहरूलाई क्रमबद्ध रूपमा व्यवस्थित गरेर, हामी द्रुत रूपमा समस्याको विश्लेषण गर्न, समस्याको प्रकार निर्धारण गर्न, र त्यसपछि विस्तृत मेट्रिक्समा ड्रिल गर्न सक्छौं। सामान्यतया, हामी ब्रेकडाउनको स्रोत पहिचान गर्न लगभग 1-2 मिनेट खर्च गर्छौं। यस पछि, हामी निदान मा एक विशेष टोली संग काम गर्छौं - दशौं मिनेट देखि धेरै घण्टा सम्म।

निदान चाँडै गरिए पनि, हामी यो पटक पटक हुन चाहँदैनौं। आदर्श रूपमा, हामीले सेवामा महत्त्वपूर्ण प्रभाव पर्दा मात्र एक महत्वपूर्ण चेतावनी प्राप्त गर्नेछौं। हाम्रो क्वेरी प्रवेग प्रणालीको लागि, हामीसँग केवल 2 अलर्टहरू छन् जसले सूचित गर्नेछ:

• ग्राहक फलब्याक प्रतिशत - ग्राहक व्यवहार को आकलन;
• प्रतिशत प्रोब त्रुटिहरू - नेटवर्क कम्पोनेन्टहरूको स्थिरता डाटा।

यी महत्वपूर्ण अलर्टहरूले प्रणालीले अधिकांश प्रयोगकर्ताहरूको लागि काम गरिरहेको छ कि छैन भनेर निगरानी गर्दछ। हामी हेर्छौं कि कति ग्राहकहरूले फलब्याक प्रयोग गरे यदि तिनीहरू अनुरोध प्रवेग प्राप्त गर्न असमर्थ थिए। प्रणालीमा धेरै परिवर्तनहरू भइरहेका भए तापनि हामी प्रति हप्ता 1 भन्दा कम महत्त्वपूर्ण चेतावनी दिन्छौं। यो हाम्रो लागि किन पर्याप्त छ?

1. यदि हाम्रो प्रोक्सीले काम गर्दैन भने ग्राहक फलब्याक हुन्छ।
2. त्यहाँ एक स्वचालित स्टीयरिंग प्रणाली छ जसले समस्याहरूको जवाफ दिन्छ।

पछिल्लो बारेमा थप विवरण। हाम्रो परीक्षण प्रणाली, र क्लाउडबाट क्लाउडमा अनुरोधहरूको लागि इष्टतम मार्ग स्वचालित रूपमा निर्धारण गर्ने प्रणालीले हामीलाई स्वचालित रूपमा केही समस्याहरूको सामना गर्न अनुमति दिन्छ।

हाम्रो नमूना कन्फिगरेसन र 3 पथ कोटिहरूमा फर्कौं। लोडिङ समयको अतिरिक्त, हामी डेलिभरीको तथ्यलाई हेर्न सक्छौं। यदि डाटा लोड गर्न सम्भव भएन भने, विभिन्न मार्गहरूमा नतिजाहरू हेरेर हामी कहाँ र के ब्रेक भयो भनेर निर्धारण गर्न सक्छौं, र हामीले अनुरोध मार्ग परिवर्तन गरेर यसलाई स्वचालित रूपमा ठीक गर्न सक्छौं।

उदाहरण:

यो प्रक्रिया स्वचालित हुन सक्छ। यसलाई स्टीयरिङ प्रणालीमा समावेश गर्नुहोस्। र प्रदर्शन र विश्वसनीयता समस्याहरूको जवाफ दिन सिकाउनुहोस्। यदि केहि तोड्न थाल्छ भने, प्रतिक्रिया दिनुहोस् यदि त्यहाँ राम्रो विकल्प छ। एकै समयमा, एक तत्काल प्रतिक्रिया महत्वपूर्ण छैन, ग्राहकहरु मा फलब्याक को लागी धन्यवाद।

तसर्थ, प्रणाली समर्थन को सिद्धान्तहरू निम्न रूपमा तयार गर्न सकिन्छ:

• ब्रेकडाउन को स्केल कम गर्दै;
• मेट्रिक्स सङ्कलन;
• यदि हामी सक्छौं भने हामी स्वचालित रूपमा ब्रेकडाउनहरू मर्मत गर्छौं;
• यदि यो सक्दैन भने, हामी तपाईंलाई सूचित गर्छौं;
• हामी द्रुत प्रतिक्रियाको लागि ड्यासबोर्ड र ट्राइएज टूलसेटमा काम गरिरहेका छौं।

सिकेका पाठहरू

प्रोटोटाइप लेख्न धेरै समय लाग्दैन। हाम्रो मामला मा, यो 4 महिना पछि तयार थियो। यसको साथ हामीले नयाँ मेट्रिक्स प्राप्त गर्यौं, र विकास सुरु भएको १० महिना पछि हामीले पहिलो उत्पादन ट्राफिक प्राप्त गर्यौं। त्यसपछि कठिन र धेरै गाह्रो काम सुरु भयो: बिस्तारै उत्पादन गर्नुहोस् र प्रणाली मापन गर्नुहोस्, मुख्य ट्राफिक माइग्रेट गर्नुहोस् र गल्तीहरूबाट सिक्नुहोस्। यद्यपि, यो प्रभावकारी प्रक्रिया रैखिक हुनेछैन - सबै प्रयासहरूको बावजुद, सबै कुरा भविष्यवाणी गर्न सकिँदैन। यो छिटो दोहोर्याउन र नयाँ डेटा प्रतिक्रिया गर्न धेरै प्रभावकारी छ।

हाम्रो अनुभवको आधारमा, हामी निम्न सिफारिस गर्न सक्छौं:

1. आफ्नो अन्तर्ज्ञान मा भरोसा नगर्नुहोस्।

   हाम्रो टोलीका सदस्यहरूको विशाल अनुभवको बाबजुद हाम्रो अन्तर्ज्ञानले हामीलाई निरन्तर असफल बनायो। उदाहरणको लागि, हामीले CDN प्रोक्सी, वा TCP Anycast को व्यवहारबाट अपेक्षित गतिको गलत भविष्यवाणी गर्यौं।

2. उत्पादनबाट डाटा प्राप्त गर्नुहोस्।

   सकेसम्म चाँडो कम्तिमा सानो मात्रामा उत्पादन डेटामा पहुँच प्राप्त गर्न महत्त्वपूर्ण छ। प्रयोगशाला अवस्थाहरूमा अद्वितीय केसहरू, कन्फिगरेसनहरू, र सेटिङहरूको संख्या प्राप्त गर्न यो लगभग असम्भव छ। नतिजाहरूमा द्रुत पहुँचले तपाईंलाई सम्भावित समस्याहरूको बारेमा द्रुत रूपमा जान्न र तिनीहरूलाई प्रणाली वास्तुकलामा खातामा लिन अनुमति दिनेछ।

3. अन्य व्यक्तिको सल्लाह र परिणामहरू पालना नगर्नुहोस् - आफ्नै डेटा सङ्कलन गर्नुहोस्।

   डाटा सङ्कलन र विश्लेषणका लागि सिद्धान्तहरू पालना गर्नुहोस्, तर अन्य व्यक्तिहरूको नतिजा र कथनहरूलाई अन्धाधुन्ध रूपमा स्वीकार नगर्नुहोस्। केवल तपाइँ तपाइँका प्रयोगकर्ताहरूको लागि के काम गर्दछ भनेर थाहा पाउन सक्नुहुन्छ। तपाईंका प्रणालीहरू र तपाईंका ग्राहकहरू अन्य कम्पनीहरू भन्दा धेरै फरक हुन सक्छन्। सौभाग्य देखि, विश्लेषण उपकरणहरू अब उपलब्ध छन् र प्रयोग गर्न सजिलो छ। तपाईंले प्राप्त गर्ने नतिजाहरू Netflix, Facebook, Akamai र अन्य कम्पनीहरूले दावी गरे जस्तो नहुन सक्छ। हाम्रो केसमा, TLS, HTTP2 को प्रदर्शन वा DNS अनुरोधहरूमा तथ्याङ्कहरू Facebook, Uber, Akamai को नतिजाहरू भन्दा फरक छन् - किनभने हामीसँग विभिन्न यन्त्रहरू, ग्राहकहरू र डेटा प्रवाहहरू छन्।

4. अनावश्यक रूपमा फेसन प्रवृतिहरूको पालना नगर्नुहोस् र प्रभावकारिताको मूल्याङ्कन गर्नुहोस्।

   सरल सुरु गर्नुहोस्। तपाईलाई नचाहिने कम्पोनेन्टहरू विकास गर्न धेरै समय खर्च गर्नु भन्दा छोटो समयमा सरल कार्य प्रणाली बनाउनु राम्रो हो। तपाईंको मापन र परिणामहरूमा आधारित कार्यहरू र समस्याहरू समाधान गर्नुहोस्।

5. नयाँ अनुप्रयोगहरूको लागि तयार हुनुहोस्।

   जसरी सबै समस्याहरूको भविष्यवाणी गर्न गाह्रो छ, त्यसैगरी लाभ र अनुप्रयोगहरू अग्रिम भविष्यवाणी गर्न गाह्रो छ। स्टार्टअपहरूबाट एक संकेत लिनुहोस् - ग्राहक अवस्थाहरूमा अनुकूलन गर्ने तिनीहरूको क्षमता। तपाईंको मामलामा, तपाईंले नयाँ समस्याहरू र तिनका समाधानहरू पत्ता लगाउन सक्नुहुन्छ। हाम्रो परियोजनामा, हामीले अनुरोध विलम्बता कम गर्ने लक्ष्य सेट गरेका छौं। यद्यपि, विश्लेषण र छलफलको क्रममा, हामीले महसुस गर्यौं कि हामी प्रोक्सी सर्भरहरू पनि प्रयोग गर्न सक्छौं:

   • AWS क्षेत्रहरूमा ट्राफिक सन्तुलन र लागत कम गर्न;
   • CDN स्थिरता मोडेल गर्न;
   • DNS कन्फिगर गर्न;
   • TLS/TCP कन्फिगर गर्न।

निष्कर्षमा

रिपोर्टमा, मैले नेटफ्लिक्सले क्लाइन्टहरू र क्लाउड बीचको इन्टरनेट अनुरोधहरू बढाउने समस्या कसरी समाधान गर्छ भनेर वर्णन गरेको छु। हामी कसरी ग्राहकहरूमा नमूना प्रणाली प्रयोग गरेर डेटा सङ्कलन गर्छौं, र इन्टरनेटमा द्रुत मार्ग मार्फत ग्राहकहरूबाट उत्पादन अनुरोधहरू रुट गर्न सङ्कलन गरिएको ऐतिहासिक डेटा प्रयोग गर्छौं। हामी कसरी नेटवर्क प्रोटोकलको सिद्धान्तहरू, हाम्रो CDN पूर्वाधार, ब्याकबोन नेटवर्क, र DNS सर्भरहरू यो कार्य हासिल गर्न प्रयोग गर्छौं।

यद्यपि, हाम्रो समाधान हामीले नेटफ्लिक्समा यस्तो प्रणाली कसरी लागू गर्यौं भन्ने एउटा उदाहरण मात्र हो। हाम्रो लागि के काम गर्यो। तपाईंको लागि मेरो प्रतिवेदनको लागू गरिएको अंश विकास र समर्थनका सिद्धान्तहरू हुन् जुन हामीले पालना गर्छौं र राम्रो परिणामहरू प्राप्त गर्दछौं।

हाम्रो समस्याको समाधान तपाईलाई उपयुक्त नहुन सक्छ। यद्यपि, सिद्धान्त र डिजाइन सिद्धान्तहरू रहन्छन्, यदि तपाइँसँग तपाइँको आफ्नै CDN पूर्वाधार छैन भने, वा यदि यो हाम्रो भन्दा धेरै फरक छ।

व्यापार अनुरोधहरूको गतिको महत्त्व पनि महत्त्वपूर्ण रहन्छ। र साधारण सेवाको लागि पनि तपाईंले छनौट गर्न आवश्यक छ: क्लाउड प्रदायकहरू, सर्भर स्थान, CDN र DNS प्रदायकहरू बीच। तपाईंको छनौटले तपाईंको ग्राहकहरूको लागि इन्टरनेट प्रश्नहरूको प्रभावकारितालाई असर गर्नेछ। र यो प्रभाव मापन र बुझ्न तपाईंको लागि महत्त्वपूर्ण छ।

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

यो वर्ष सम्मेलन जुलाई 6 देखि 10 सम्म हुनेछ अनलाइन ढाँचामा। तपाईंले DevOps को बुबा जोन विलिस आफैलाई प्रश्नहरू सोध्न सक्नुहुन्छ!

स्रोत: www.habr.com