Yandex.Market खोज कसरी काम गर्दछ र यदि कुनै सर्भर असफल भयो भने के हुन्छ

नमस्ते, मेरो नाम Evgeniy हो। म Yandex.Market खोज पूर्वाधारमा काम गर्छु। म हब्र समुदायलाई बजारको भित्री भान्साको बारेमा बताउन चाहन्छु - र मसँग धेरै कुराहरू छन्। सबै भन्दा पहिले, कसरी बजार खोज काम गर्दछ, प्रक्रियाहरू र वास्तुकला। हामी आपतकालीन अवस्थाहरूसँग कसरी व्यवहार गर्छौं: यदि एउटा सर्भर डाउन भयो भने के हुन्छ? यदि त्यहाँ 100 वटा सर्भर छन् भने के हुन्छ?

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

हाम्रो बारेमा थोरै: हामी कुन समस्या समाधान गर्छौं

जब तपाइँ पाठ प्रविष्ट गर्नुहुन्छ, प्यारामिटरहरू द्वारा उत्पादन खोज्नुहोस्, वा विभिन्न स्टोरहरूमा मूल्यहरू तुलना गर्नुहोस्, सबै अनुरोधहरू खोज सेवामा पठाइन्छ। खोज बजार मा सबै भन्दा ठूलो सेवा हो।

हामी सबै खोज अनुरोधहरू प्रशोधन गर्छौं: साइटहरू market.yandex.ru, beru.ru, Supercheck सेवा, Yandex.Advisor, मोबाइल अनुप्रयोगहरूबाट। हामीले yandex.ru मा खोज परिणामहरूमा उत्पादन प्रस्तावहरू पनि समावेश गर्दछौं।

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

के हो: बजार वास्तुकला

म बजारको हालको वास्तुकलाको संक्षिप्त वर्णन गर्नेछु। यो तलको रेखाचित्र द्वारा लगभग वर्णन गर्न सकिन्छ:

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

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

नतिजाको रूपमा, एक squeaker संग एक क्रोधित बिरालो डाटाबेसमा देखा पर्दछ, र बिरालोको अनुक्रमणिका सर्भरमा देखा पर्दछ।

म तपाईलाई बताउनेछु कि हामी कसरी खोजी वास्तुकलाको बारेमा भागमा बिरालो खोज्छौं।

बजार खोज वास्तुकला

हामी माइक्रो सेवाहरूको संसारमा बस्छौं: प्रत्येक आगमन अनुरोध market.yandex.ru धेरै सबक्वेरीहरू निम्त्याउँछ, र दर्जनौं सेवाहरू तिनीहरूको प्रशोधनमा संलग्न छन्। रेखाचित्रले केही मात्र देखाउँछ:

सरलीकृत अनुरोध प्रशोधन योजना

प्रत्येक सेवाको एक अद्भुत चीज छ - यसको आफ्नै ब्यालेन्सर एक अद्वितीय नामको साथ:

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

ब्यालेन्सरको अद्वितीय नाम डाटा केन्द्रमा निर्भर गर्दैन। जब सेवा A ले B लाई अनुरोध गर्दछ, तब पूर्वनिर्धारित ब्यालेन्सर B द्वारा हालको डाटा केन्द्रमा अनुरोध रिडिरेक्ट गर्दछ। यदि सेवा अनुपलब्ध छ वा हालको डाटा केन्द्रमा अवस्थित छैन भने, त्यसपछि अनुरोध अन्य डाटा केन्द्रहरूमा पुन: निर्देशित गरिन्छ।

सबै डेटा केन्द्रहरूको लागि एकल FQDN ले सेवा A लाई स्थानहरूबाट पूर्ण रूपमा सार गर्न अनुमति दिन्छ। सेवा B लाई उहाँको अनुरोध सधैं प्रशोधन गरिनेछ। अपवादको मामला हो जब सेवा सबै डाटा केन्द्रहरूमा अवस्थित छ।

तर यो ब्यालेन्सरको साथ सबै कुरा यति गुलाबी छैन: हामीसँग अतिरिक्त मध्यवर्ती घटक छ। ब्यालेन्सर अस्थिर हुन सक्छ, र यो समस्या अनावश्यक सर्भरहरू द्वारा हल गरिएको छ। त्यहाँ सेवाहरू A र B बीच थप ढिलाइ पनि छ। तर व्यवहारमा यो 1 ms भन्दा कम छ र धेरै सेवाहरूको लागि यो महत्वपूर्ण छैन।

अप्रत्याशितसँग व्यवहार गर्दै: खोज सेवा सन्तुलन र लचिलोपन

कल्पना गर्नुहोस् कि त्यहाँ एक पतन छ: तपाईंले squeaker संग बिरालो खोज्न आवश्यक छ, तर सर्भर क्र्यास। वा 100 सर्भरहरू। कसरी निस्कने ? के हामी साँच्चै बिरालो बिना प्रयोगकर्ता छोड्न जाँदैछौं?

स्थिति डरलाग्दो छ, तर हामी यसको लागि तयार छौं। म तपाईंलाई क्रम मा बताउछु।

खोजी पूर्वाधार धेरै डाटा केन्द्रहरूमा अवस्थित छ:

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

एकल डाटा सेन्टरलाई विचार गरौं। प्रत्येक डाटा केन्द्रमा समान ब्यालेन्सर सञ्चालन योजना छ:

एउटा ब्यालेन्सर कम्तिमा तीन भौतिक सर्भरहरू हुन्। यो रिडन्डन्सी विश्वसनीयताको लागि बनाइएको हो। ब्यालेन्सरहरू HAProx मा चल्छन्।

हामीले यसको उच्च प्रदर्शन, कम स्रोत आवश्यकताहरू र व्यापक कार्यक्षमताको कारणले HAProx रोज्यौं। हाम्रो खोज सफ्टवेयर प्रत्येक सर्भर भित्र चल्छ।

एउटा सर्भर असफल हुने सम्भावना कम छ। तर यदि तपाईंसँग धेरै सर्भरहरू छन् भने, कम्तिमा एउटा तल जाने सम्भावना बढ्छ।

यो वास्तविकतामा के हुन्छ: सर्भर क्र्यास। तसर्थ, सबै सर्भरहरूको स्थितिलाई निरन्तर निगरानी गर्न आवश्यक छ। यदि सर्भरले प्रतिक्रिया दिन रोक्छ भने, यो स्वचालित रूपमा ट्राफिकबाट विच्छेद हुन्छ। यस उद्देश्यको लागि, HAProxy मा निर्मित स्वास्थ्य जाँच छ। यो HTTP अनुरोध "/ping" को साथ एक सेकेन्ड एक पटक सबै सर्भरहरूमा जान्छ।

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

अब बिरालो खोज्ने बारे। खोज परिणामहरू जस्तै अनुरोधहरूमा: /search?text=angry+cat। खोज छिटो हुनको लागि, सम्पूर्ण बिरालो सूचकांक RAM मा फिट हुनुपर्छ। SSD बाट पढ्न पनि पर्याप्त छिटो छैन।

एक पटक, प्रस्ताव डाटाबेस सानो थियो, र एक सर्भर को RAM यसको लागि पर्याप्त थियो। प्रस्ताव आधार बढ्दै जाँदा, सबै कुरा अब यो RAM मा फिट हुँदैन, र डेटा दुई भागमा विभाजित भयो: शार्ड १ र शार्ड २।

तर यो सधैं हुन्छ: कुनै पनि समाधान, एक राम्रो पनि, अन्य समस्याहरू जन्म दिन्छ।

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

ब्यालेन्सरले समान रूपमा अनुरोधहरू वितरण गरेको हुनाले, सबै सर्भरहरू पुन: श्रेणीकरणमा संलग्न थिए, र डाटा पठाउन मात्र होइन।

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

हाल, आठ शार्डहरूको कन्फिगरेसन प्रयोग गरिन्छ। थप रूपमा, अझ बढी मेमोरी बचत गर्न, अनुक्रमणिकालाई खोजी भाग (जुन खोजीका लागि प्रयोग गरिन्छ) र स्निपेट भाग (जुन खोजमा संलग्न छैन) मा विभाजित गरिएको थियो।

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

सर्भरहरू क्लस्टरहरूमा समूहबद्ध छन्। प्रत्येक क्लस्टरमा आठ खोज इन्जिन र एउटा स्निपेट सर्भर हुन्छ।

स्निपेट सर्भरले स्थिर डाटाको साथ कुञ्जी-मान डाटाबेस चलाउँछ। तिनीहरू कागजातहरू जारी गर्न आवश्यक छन्, उदाहरणका लागि, एक squeaker संग बिरालोको विवरण। डाटा विशेष रूपमा छुट्टै सर्भरमा स्थानान्तरण गरिएको छ ताकि खोज सर्भरहरूको मेमोरी लोड नगर्नुहोस्।

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

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

आवश्यक जानकारी सङ्कलन गरेपछि, प्रस्ताव डाटाबेसमा खोज सुरु हुन्छ। यो गर्नका लागि, क्लस्टरका सबै आठ सर्भरहरूमा सबक्वेरीहरू बनाइन्छ।

प्रतिक्रियाहरू प्राप्त भएपछि, परिणामहरू संयुक्त हुन्छन्। अन्तमा, परिणामहरू उत्पन्न गर्न स्निपेट सर्भरमा धेरै थप सबक्वेरीहरू आवश्यक हुन सक्छ।

क्लस्टर भित्र खोज क्वेरीहरू यस्तो देखिन्छ: /shard1?text=angry+cat। थप रूपमा, फारमको सबक्वेरीहरू एक सेकेन्डमा एक पटक क्लस्टर भित्रका सबै सर्भरहरू बीच लगातार बनाइन्छ: /स्थिति.

अनुरोध /स्थिति सर्भर उपलब्ध नभएको अवस्था पत्ता लगाउँछ।

यसले यो पनि नियन्त्रण गर्दछ कि खोज इन्जिन संस्करण र अनुक्रमणिका संस्करण सबै सर्भरहरूमा समान छन्, अन्यथा त्यहाँ क्लस्टर भित्र असंगत डेटा हुनेछ।

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

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

तर अर्को वास्तुकलामा संक्रमण अझै पूरा भएको छैन। अब हामी समर्पित स्निपेट सर्भरबाट छुटकारा पाउन चाहन्छौं। र त्यसपछि क्लस्टर संरचनाबाट पूर्ण रूपमा टाढा जानुहोस्। यसले हामीलाई सजिलै मापन गर्न जारी राख्न अनुमति दिनेछ। एक अतिरिक्त बोनस महत्वपूर्ण फलाम बचत हो।

र अब सुखद अन्त्यका साथ डरलाग्दो कथाहरूमा। सर्भर अनुपलब्धताका धेरै केसहरू विचार गरौं।

केहि भयानक भयो: एउटा सर्भर उपलब्ध छैन

मानौं एउटा सर्भर उपलब्ध छैन। त्यसपछि क्लस्टरका बाँकी सर्भरहरूले प्रतिक्रिया दिन जारी राख्न सक्छन्, तर खोज परिणामहरू अपूर्ण हुनेछन्।

स्थिति जाँच मार्फत /स्थिति छिमेकी सर्भरहरूले बुझ्छन् कि एउटा अनुपलब्ध छ। त्यसकारण, पूर्णता कायम राख्न, प्रति अनुरोध क्लस्टरमा सबै सर्भरहरू /ping तिनीहरूले ब्यालेन्सरलाई प्रतिक्रिया दिन थाल्छन् कि तिनीहरू पनि उपलब्ध छैनन्। यो बाहिर जान्छ कि क्लस्टर मा सबै सर्भरहरु मरे (जुन सत्य छैन)। यो हाम्रो क्लस्टर योजनाको मुख्य कमजोरी हो - त्यसैले हामी यसबाट टाढा हुन चाहन्छौं।

त्रुटिको साथ असफल भएका अनुरोधहरू अन्य सर्भरहरूमा ब्यालेन्सरद्वारा पुन: पठाइन्छ।
ब्यालेन्सरले मृत सर्भरहरूमा प्रयोगकर्ता ट्राफिक पठाउन पनि रोक्छ, तर तिनीहरूको स्थिति जाँच गर्न जारी राख्छ।

जब सर्भर उपलब्ध हुन्छ, यसले प्रतिक्रिया दिन थाल्छ /ping। मृत सर्भरहरूबाट पिंगहरूमा सामान्य प्रतिक्रियाहरू आउन सुरु हुने बित्तिकै, ब्यालेन्सरहरूले त्यहाँ प्रयोगकर्ता ट्राफिक पठाउन थाल्छन्। क्लस्टर सञ्चालन पुनर्स्थापित भयो, हुर्रे।

अझ खराब: धेरै सर्भरहरू उपलब्ध छैनन्

डाटा सेन्टरमा सर्भरहरूको एक महत्त्वपूर्ण भाग काटिएको छ। के गर्ने, कहाँ भाग्ने ? ब्यालेन्सर फेरि उद्धारमा आउँछ। प्रत्येक ब्यालेन्सर निरन्तर मेमोरीमा लाइभ सर्भरहरूको हालको संख्या भण्डार गर्दछ। यसले हालको डाटा सेन्टरले प्रशोधन गर्न सक्ने अधिकतम ट्राफिकको निरन्तर गणना गर्छ।

जब डाटा सेन्टरमा धेरै सर्भरहरू तल जान्छन्, ब्यालेन्सरले यो डाटा सेन्टरले सबै ट्राफिकलाई प्रशोधन गर्न सक्दैन भन्ने महसुस गर्छ।

त्यसपछि अतिरिक्त ट्राफिक अनियमित रूपमा अन्य डाटा केन्द्रहरूमा वितरण गर्न सुरु हुन्छ। सबै काम गर्छ, सबै खुसी छन्।

हामी यो कसरी गर्छौं: प्रकाशन विज्ञप्ति

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

त्यसपछि सेवा परीक्षणको लागि रोल आउट गरिएको छ, जहाँ सञ्चालनको स्थिरता जाँच गरिन्छ।

एकै समयमा, स्वचालित प्रदर्शन परीक्षण सुरु गरिएको छ। यो एक विशेष सेवा द्वारा ह्यान्डल गरिएको छ। म अब यसको बारेमा कुरा गर्दिन - यसको विवरण छुट्टै लेखको योग्य छ।

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

Prestable मा, प्रतिक्रिया समय मापन गरिन्छ र उत्पादन मा अघिल्लो रिलीज संग तुलना गरिन्छ। यदि सबै ठीक छ भने, त्यसपछि एक व्यक्ति जडान हुन्छ: ग्राफ र लोड परीक्षणको नतिजाहरू जाँच गर्दछ र त्यसपछि उत्पादनमा रोल आउट सुरु हुन्छ।

सबै राम्रो प्रयोगकर्तालाई जान्छ: A/B परीक्षण

यो सधैं स्पष्ट छैन कि सेवामा परिवर्तनहरूले वास्तविक लाभहरू ल्याउनेछ। परिवर्तनहरूको उपयोगिता मापन गर्न, मानिसहरू A/B परीक्षणको साथ आए। म तपाईंलाई यो कसरी Yandex.Market खोजमा काम गर्छ भन्ने बारे थोरै बताउनेछु।

यो सबै नयाँ कार्यक्षमता सक्षम गर्ने नयाँ CGI प्यारामिटर थपेर सुरु हुन्छ। हाम्रो प्यारामिटर हुन दिनुहोस्: बजार_नयाँ_कार्यक्षमता = १। त्यसपछि कोडमा हामी यो कार्यक्षमता सक्षम गर्छौं यदि झण्डा अवस्थित छ:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

नयाँ कार्यक्षमता उत्पादनमा रोल आउट भइरहेको छ।

A/B परीक्षण स्वचालित गर्न, त्यहाँ एक समर्पित सेवा छ जसले विस्तृत जानकारी प्रदान गर्दछ यहाँ वर्णन गरिएको छ। सेवामा एक प्रयोग सिर्जना गरिएको छ। ट्राफिक सेयर सेट गरिएको छ, उदाहरणका लागि, 15%। प्रतिशत प्रश्नहरूको लागि होइन, तर प्रयोगकर्ताहरूको लागि सेट गरिएको छ। प्रयोगको अवधि पनि संकेत गरिएको छ, उदाहरणका लागि, एक हप्ता।

धेरै प्रयोगहरू एकैसाथ चलाउन सकिन्छ। सेटिङहरूमा तपाईँले अन्य प्रयोगहरूसँग प्रतिच्छेदन सम्भव छ कि भनेर निर्दिष्ट गर्न सक्नुहुन्छ।

नतिजाको रूपमा, सेवाले स्वचालित रूपमा तर्क थप्छ बजार_नयाँ_कार्यक्षमता = १ प्रयोगकर्ताहरूको 15% सम्म। यसले स्वचालित रूपमा चयन गरिएका मेट्रिक्सहरू पनि गणना गर्दछ। प्रयोग पूरा भएपछि, विश्लेषकहरूले नतिजा हेर्छन् र निष्कर्ष निकाल्छन्। निष्कर्षहरूको आधारमा, उत्पादन वा परिष्करणमा रोल आउट गर्ने निर्णय गरिन्छ।

बजारको कुशल हात: उत्पादनमा परीक्षण

यो अक्सर हुन्छ कि तपाइँ उत्पादन मा एक नयाँ कार्यक्षमता को अपरेशन को परीक्षण गर्न आवश्यक छ, तर तपाई निश्चित हुनुहुन्न कि यो "लडाई" मा भारी भार अन्तर्गत कसरी व्यवहार गर्नेछ।

त्यहाँ एक समाधान छ: CGI मापदण्डहरूमा झण्डाहरू A/B परीक्षणको लागि मात्र होइन, नयाँ कार्यक्षमता परीक्षण गर्न पनि प्रयोग गर्न सकिन्छ।

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

सेवा प्रवाह रेखाचित्र तल प्रस्तुत गरिएको छ:

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

स्टप ट्यापमा तपाईले दुई प्रकारका मानहरू सेट गर्न सक्नुहुन्छ:

1) सशर्त अभिव्यक्ति। लागू गर्नुहोस् जब मान मध्ये एक सत्य छ। उदाहरणका लागि:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

स्थान DC3 मा अनुरोध प्रशोधन हुँदा मान "1" लागू हुनेछ। र beru.ru साइटको लागि दोस्रो क्लस्टरमा अनुरोध प्रशोधन गर्दा मान "4" हुन्छ।

2) बिना शर्त मानहरू। यदि कुनै पनि सर्तहरू पूरा भएन भने पूर्वनिर्धारित रूपमा लागू गर्नुहोस्। उदाहरणका लागि:

मूल्य, मूल्य!

यदि कुनै मान विस्मयादिबोधक बिन्दुसँग समाप्त हुन्छ भने, यसलाई उच्च प्राथमिकता दिइन्छ।

CGI प्यारामिटर पार्सरले URL लाई पार्स गर्दछ। त्यसपछि स्टप ट्यापबाट मानहरू लागू हुन्छ।

निम्न प्राथमिकताहरू भएका मानहरू लागू हुन्छन्:

1. रोक्नुहोस् ट्याप (विस्मयादिबोधक चिन्ह) बाट बढेको प्राथमिकताको साथ।
2. अनुरोधको मूल्य।
3. स्टप ट्यापबाट पूर्वनिर्धारित मान।
4. कोडमा पूर्वनिर्धारित मान।

त्यहाँ धेरै झण्डाहरू छन् जुन सशर्त मानहरूमा संकेत गरिएको छ - तिनीहरू हामीलाई ज्ञात सबै परिदृश्यहरूको लागि पर्याप्त छन्:

• डाटा सेन्टर।
• वातावरण: उत्पादन, परीक्षण, छाया।
• स्थान: बजार, बेरु।
• क्लस्टर नम्बर।

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

यदि तपाईंले समस्या देख्नुभयो भने, तपाईंले झण्डालाई यसको अघिल्लो मानमा तुरुन्तै फर्काउन सक्नुहुन्छ र परिवर्तनहरू फिर्ता हुनेछन्।

यस सेवाको पनि नकारात्मक पक्षहरू छन्: विकासकर्ताहरूले यसलाई धेरै मन पराउँछन् र प्रायः सबै परिवर्तनहरूलाई स्टप ट्यापमा पुश गर्ने प्रयास गर्छन्। हामी दुरुपयोग रोक्न प्रयास गरिरहेका छौं।

स्टप ट्याप दृष्टिकोणले राम्रोसँग काम गर्छ जब तपाईंसँग उत्पादनमा रोल आउट गर्नको लागि स्थिर कोड तयार हुन्छ। एकै समयमा, तपाईं अझै पनि शंका छ, र तपाईं "लडाई" अवस्थामा कोड जाँच गर्न चाहनुहुन्छ।

यद्यपि, स्टप ट्याप विकासको क्रममा परीक्षणको लागि उपयुक्त छैन। विकासकर्ताहरूको लागि "छाया क्लस्टर" भनिने छुट्टै क्लस्टर छ।

गोप्य परीक्षण: छाया क्लस्टर

क्लस्टरहरू मध्ये एकबाट अनुरोधहरू छाया क्लस्टरमा नक्कल गरिएका छन्। तर ब्यालेन्सरले यस क्लस्टरबाट प्रतिक्रियाहरूलाई पूर्ण रूपमा बेवास्ता गर्दछ। यसको सञ्चालनको रेखाचित्र तल प्रस्तुत गरिएको छ।

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

र ब्यालेन्सरले प्रतिक्रियाहरूलाई पूर्ण रूपमा बेवास्ता गरेकोले, अन्तिम प्रयोगकर्ताहरूले छाया क्लस्टरबाट प्रतिक्रियाहरू देख्ने छैनन्। त्यसैले, गल्ती गर्न डरलाग्दो छैन।

निष्कर्ष

त्यसोभए, हामीले बजार खोज कसरी बनायौं?

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

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

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

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

स्रोत: www.habr.com