sophiagworld द्वारा हरायो

यस लेखमा ईन्जिनियरहरूलाई लाखौं प्रयोगकर्ताहरूद्वारा पहुँच गरिएका ठूला-ठूला सेवाहरूसँग काम गर्न मद्दत गर्न केही सामान्य ढाँचाहरू छन्। 

लेखकको अनुभवमा, यो एक विस्तृत सूची होइन, तर वास्तवमा प्रभावकारी सल्लाह। त्यसैले, सुरु गरौं।

समर्थन संग अनुवाद Mail.ru क्लाउड समाधान.

पहिलो स्तर

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

कोडको रूपमा पूर्वाधार

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

100 भर्चुअल मेसिनहरूको तैनाती

• Ubuntu संग
• 2 GB RAM प्रत्येक
• तिनीहरूसँग निम्न कोड हुनेछ
• यी प्यारामिटरहरूसँग

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

म मा आधुनिकतावादी भन्छन् कि तपाइँ माथिका सबै गर्न Kubernetes/Docker प्रयोग गर्न सक्नुहुन्छ, र उहाँ सही हुनुहुन्छ।

थप रूपमा, तपाईंले शेफ, पपेट वा टेराफार्म प्रयोग गरेर स्वचालन प्रदान गर्न सक्नुहुन्छ।

निरन्तर एकीकरण र वितरण

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

यस चरणमा प्रत्येक पटक तपाईंले प्रश्नको जवाफ दिनुहुन्छ: के मेरो सम्मेलन कम्पाइल र परीक्षा पास हुनेछ, यो मान्य छ? यो कम पट्टी जस्तो लाग्न सक्छ, तर यसले धेरै समस्याहरू समाधान गर्दछ।

यी टिक्सहरू देख्नु भन्दा सुन्दर केहि छैन

यस प्रविधिको लागि तपाईंले Github, CircleCI वा Jenkins को मूल्याङ्कन गर्न सक्नुहुन्छ।

लोड ब्यालेन्सरहरू

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

लोड ब्यालेन्सरले सामान्यतया ट्राफिक वितरणको राम्रो काम गर्छ। उत्तम अभ्यास भनेको ओभरब्यालेन्स गर्नु हो ताकि तपाईसँग असफलताको एक बिन्दु नहोस्।

सामान्यतया, लोड ब्यालेन्सरहरू तपाईंले प्रयोग गर्नुहुने क्लाउडमा कन्फिगर गरिन्छ।

अनुरोधहरूको लागि RayID, सहसंबंध ID वा UUID

के तपाईंले कहिल्यै यस प्रकारको सन्देशको साथ एप्लिकेसन त्रुटिको सामना गर्नुभएको छ: "केहि गलत भयो। यो आईडी सुरक्षित गर्नुहोस् र हाम्रो समर्थन टोलीलाई पठाउनुहोस्"?

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

प्रयोगकर्ताले प्रणाली A लाई अनुरोध गर्दछ, त्यसपछि A सम्पर्क B, जसले C लाई सम्पर्क गर्दछ, यसलाई X मा भण्डार गर्दछ, र त्यसपछि अनुरोध A मा फर्किन्छ।

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

मध्यवर्ती स्तर

यहाँको सल्लाह अघिल्लो भन्दा धेरै जटिल छ, तर सही उपकरणहरूले कार्यलाई सजिलो बनाउँदछ, साना र मध्यम आकारका कम्पनीहरूको लागि पनि लगानीमा प्रतिफल प्रदान गर्दछ।

केन्द्रीकृत लगिङ

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

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

ELK स्ट्याक कार्यक्षमता

निगरानी एजेन्टहरू

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

यस बिन्दुमा तपाइँ यसलाई जाँच गर्नुहोस् चलिरहेको निर्माण राम्रो लाग्छ र राम्रो काम गर्दछ.

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

लोडको आधारमा स्वत: स्केलिङ

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

धेरै क्लाउड सेवाहरूसँग, तपाइँ यसलाई अधिक सर्भर वा अधिक शक्तिशाली सर्भरहरू प्रयोग गरेर स्वत: मापनमा कन्फिगर गर्न सक्नुहुन्छ।

प्रयोग प्रणाली

अपडेटहरू सुरक्षित रूपमा रोल आउट गर्ने राम्रो तरिका भनेको एक घण्टाको लागि 1% प्रयोगकर्ताहरूको लागि केहि परीक्षण गर्न सक्षम हुनु हो। तपाईंले पक्कै पनि त्यस्ता संयन्त्रहरू कार्यमा देख्नुभएको छ। उदाहरणका लागि, फेसबुकले दर्शकहरूको भागलाई फरक रंग देखाउँछ वा प्रयोगकर्ताहरूले परिवर्तनहरू कसरी बुझ्छन् भनेर हेर्नको लागि फन्ट साइज परिवर्तन गर्दछ। यसलाई A/B परीक्षण भनिन्छ।

नयाँ सुविधा रिलिज गर्दा पनि प्रयोगको रूपमा सुरु गर्न सकिन्छ र त्यसपछि यसलाई कसरी रिलिज गर्ने भनेर निर्धारण गर्न सकिन्छ। तपाईंले आफ्नो सेवामा ह्रास ल्याउने प्रकार्यको आधारमा फ्लाईमा "सम्झने" वा कन्फिगरेसन परिवर्तन गर्ने क्षमता पनि प्राप्त गर्नुहुन्छ।

उन्नत स्तर

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

नीलो हरियो परिनियोजन

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

यो चरण लोड ब्यालेन्सर को उपस्थिति मा निर्भर गर्दछ। कल्पना गरौं कि तपाइँसँग तपाइँको सफ्टवेयरको संस्करण N छ, र त्यसपछि तपाइँ संस्करण N+1 प्रयोग गर्न चाहनुहुन्छ। 

तिमी हामी सक्छौं केवल सेवा रोक्नुहोस् र अर्को संस्करण रोल आउट गर्नुहोस् जुन तपाईंको प्रयोगकर्ताहरूको लागि काम गर्दछ र केही डाउनटाइम पाउनुहोस्। तर मानौं तपाईसँग छ वास्तवमा कडा SLA सर्तहरू। त्यसोभए, SLA 99,99% को मतलब तपाईं अफलाइन जान सक्नुहुन्छ मात्र प्रति वर्ष 52 मिनेट द्वारा।

यदि तपाइँ साँच्चै त्यस्ता संकेतकहरू प्राप्त गर्न चाहनुहुन्छ भने, तपाइँलाई एकै समयमा दुई डिप्लोइमेन्टहरू चाहिन्छ: 

• जुन अहिले छ (N);
• अर्को संस्करण (N+1)। 

तपाईंले लोड ब्यालेन्सरलाई ट्राफिकको प्रतिशतलाई नयाँ संस्करण (N+1) मा रिडिरेक्ट गर्न भन्नुहुन्छ जब तपाईं सक्रिय रूपमा प्रतिगमनहरूको लागि निगरानी गर्नुहुन्छ।

यहाँ हामीसँग हरियो एन डिप्लोइमेन्ट छ जुन राम्रोसँग काम गर्दछ। हामी यो परिनियोजनको अर्को संस्करणमा जान प्रयास गर्दैछौं

हाम्रो N+1 डिप्लोयमेन्टले थोरै मात्रामा ट्राफिकसँग काम गर्छ कि गर्दैन भनेर हेर्नको लागि पहिले हामी साँच्चै सानो परीक्षण पठाउँछौं:

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

यदि तपाइँ अझ उन्नत स्तरमा जान चाहनुहुन्छ भने, नीलो-हरियो डिप्लोइमेन्टमा सबै कुरा स्वचालित रूपमा चल्न दिनुहोस्।

विसंगति पत्ता लगाउने र स्वचालित शमन

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

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

यी अन्तर्दृष्टिहरूको साथ, तपाइँ कुनै पनि आयाममा मापन गर्न सक्नुहुन्छ र सक्रिय र प्रतिक्रियात्मक रूपमा मेशिनहरू, डाटाबेसहरू, जडानहरू र अन्य स्रोतहरूको विशेषताहरू परिवर्तन गर्न सक्नुहुन्छ।

यति नै!

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

मूल लेखको लेखकले पाठकहरूलाई उनीहरूको टिप्पणी छोड्न र परिवर्तनहरू गर्न आमन्त्रित गर्दछ। लेख खुला स्रोतको रूपमा वितरित गरिएको छ, लेखक द्वारा अनुरोधहरू Github मा स्वीकार गर्दछ.

यस विषयमा अरू के पढ्ने:

1. जानुहोस् र CPU क्यासहरू
2. कार्यान्वयनको लागि टेम्प्लेटको साथ पाइरेसीको भावनामा Kubernetes
3. Telegram मा Kubernetes को आसपास हाम्रो च्यानल

स्रोत: www.habr.com