डम्प सम्मेलन | grep 'backend|devops'

गत हप्ता म येकातेरिनबर्गको DUMP IT सम्मेलन (https://dump-ekb.ru/) मा गएको थिएँ र ब्याकएन्ड र डेभप्स सेक्सनहरूमा के छलफल गरिएको थियो, र क्षेत्रीय IT सम्मेलनहरू ध्यान लायक छन् कि छैनन् भनेर म तपाईंलाई बताउन चाहन्छु।

Serverless को बारे मा Evil Martians बाट निकोले Sverchkov

जे भए पनि त्यहाँ के थियो?

कुलमा, सम्मेलनमा 8 खण्डहरू थिए: ब्याकएन्ड, फ्रन्टएन्ड, मोबाइल, परीक्षण र QA, Devops, डिजाइन, विज्ञान र व्यवस्थापन।

ठूला हलहरू, वैसे, विज्ञान र व्यवस्थापनमा छन्)) ~ 350 जना प्रत्येकको लागि। ब्याकएन्ड र फ्रन्टएन्ड धेरै सानो छैनन्। Devops कोठा सबैभन्दा सानो, तर सक्रिय थियो।

मैले डेभप्स र ब्याकएन्ड सेक्सनहरूमा रिपोर्टहरू सुने र स्पिकरहरूसँग थोरै कुरा गरें। म सम्मेलनमा कभर गरिएका विषयहरूको बारेमा कुरा गर्न र यी खण्डहरूको समीक्षा गर्न चाहन्छु।

SKB-Kontur, DataArt, Evil Martians, Ekaterinburg वेब स्टुडियो फ्ल्याग, Miro (RealTimeBoard) का प्रतिनिधिहरूले Devops र Backend खण्डहरूमा बोलेका थिए। CI/CD लाई कभर गर्ने विषयहरू, लाम सेवाहरूसँग काम गर्ने, लगिङ गर्ने; सर्भरलेस विषयहरू र Go मा PostgreSQL सँग काम गर्ने विषयहरू राम्रोसँग समेटिएका थिए।

त्यहाँ Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank द्वारा रिपोर्टहरू पनि थिए, तर मसँग तिनीहरूमा शारीरिक रूपमा उपस्थित हुने समय थिएन (भिडियो रेकर्डिङ र रिपोर्टहरूको स्लाइडहरू अझै उपलब्ध छैनन्, तिनीहरूले तिनीहरूलाई 2 हप्ता भित्र पोस्ट गर्ने वाचा गर्छन्। dump-ekb.ru मा)।

डेभप्स खण्ड

अचम्मको कुरा के थियो भने त्यो खण्ड सबैभन्दा सानो हलमा लगभग ५० सिट राखिएको थियो । मानिसहरू गलियाराहरूमा पनि उभिरहेका थिए :) म तपाईंलाई सुन्न व्यवस्थित गरेको रिपोर्टहरूको बारेमा बताउनेछु।

पेटाबाइट तौलको लोच

खण्ड कोन्टुर मा इलास्टिकसर्च को बारे मा भ्लादिमिर लिल (SKB-Kontur) द्वारा एक रिपोर्ट संग शुरू भयो। तिनीहरूसँग एकदम ठूलो र लोड गरिएको लोचदार छ (डेटाको ~ 800 TB, ~ 1.3 पेटाबाइटहरू रिडन्डन्सीलाई ध्यानमा राख्दै)। सबै Kontur सेवाहरूको लागि Elasticsearch एकल छ, 2 क्लस्टरहरू (7 र 9 सर्भरहरू) समावेश गर्दछ, र यति महत्त्वपूर्ण छ कि Kontur एक विशेष Elasticsearch इन्जिनियर (वास्तवमा, भ्लादिमिर आफै) छ।

भ्लादिमिरले Elasticsearch को फाइदाहरू र यसले ल्याउने समस्याहरूमा पनि आफ्ना विचारहरू साझा गरे।

लाभ:

• सबै लगहरू एकै ठाउँमा छन्, तिनीहरूमा सजिलो पहुँच
• एक वर्षको लागि लगहरू भण्डारण गर्दै र तिनीहरूलाई सजिलै विश्लेषण गर्दै
• लग संग काम को उच्च गति
• बक्स बाहिर कूल डाटा भिजुअलाइजेशन

समस्याहरू:

• सन्देश ब्रोकर हुनुपर्छ (कन्टुरको लागि यसको भूमिका काफ्काले खेलेको छ)
• Elasticsearch क्युरेटरसँग काम गर्ने सुविधाहरू (क्युरेटरमा नियमित कार्यहरूबाट आवधिक रूपमा उच्च लोड सिर्जना गरिएको)
• कुनै बिल्ट-इन प्राधिकरण छैन (केवल अलग, धेरै ठूलो पैसाको लागि, वा उत्पादनको लागि तत्परताको विभिन्न डिग्रीको खुला स्रोत प्लगइनहरूको रूपमा)

Elasticsearch को लागि खुला डिस्ट्रो को बारे मा केवल सकारात्मक समीक्षाहरु थिए :) प्राधिकरण को समान मुद्दा त्यहाँ हल गरिएको छ।

पेटाबाइट कहाँबाट आउँछ?तिनीहरूको नोडहरूमा 12*8 Tb SATA + 2*2 Tb SSD भएका सर्भरहरू हुन्छन्। SATA मा कोल्ड भण्डारण, तातो क्यास (तातो भण्डारण) को लागि मात्र SSD।
7+9 सर्भरहरू, (7 + 9) * 12 * 8 = 1536 Tb।
ठाउँको केही भाग रिजर्वमा छ, रिडन्डन्सीको लागि छुट्याइएको छ, आदि।
कोन्टुर, एल्बा, इत्यादिका सबै रिपोर्टिङ सेवाहरू सहित लगभग ९० आवेदनहरूबाट लगहरू Elasticsearch मा पठाइन्छ।

सर्भरलेस मा विकास को विशेषताहरु

अर्को Serverless को बारे मा DataArt बाट Ruslan Serkin द्वारा एक रिपोर्ट छ।

रुस्लानले सर्भरलेस दृष्टिकोणको विकासको बारेमा सामान्य रूपमा के हो, र यसका सुविधाहरू के हुन् भनेर कुरा गरे।

सर्भरलेस विकासको लागि एक दृष्टिकोण हो जसमा विकासकर्ताहरूले कुनै पनि रूपमा पूर्वाधारलाई छुँदैनन्। उदाहरण - AWS Lambda Serverless, Kubeless.io (Kubernetes भित्र सर्भरलेस), Google क्लाउड प्रकार्यहरू।

एक आदर्श सर्भरलेस अनुप्रयोग केवल एक प्रकार्य हो जसले विशेष API गेटवे मार्फत सर्भरलेस प्रदायकलाई अनुरोध पठाउँछ। एक आदर्श माइक्रोसेवा, जबकि AWS Lambda ले आधुनिक प्रोग्रामिङ भाषाहरूको ठूलो संख्यालाई समर्थन गर्दछ। क्लाउड प्रदायकहरूको मामलामा पूर्वाधारको मर्मत र परिचालनको लागत शून्य हुन्छ, साना अनुप्रयोगहरूलाई समर्थन गर्ने पनि धेरै सस्तो हुनेछ (AWS Lambda - $0.2 / 1 मिलियन साधारण अनुरोधहरू)।

यस्तो प्रणालीको स्केलेबिलिटी लगभग आदर्श छ - क्लाउड प्रदायकले यसको ख्याल राख्छ, कुबेलेस कुबेरनेट क्लस्टर भित्र स्वचालित रूपमा मापन गर्दछ।

त्यहाँ बेफाइदाहरू छन्:

• ठूला एप्लिकेसनहरू विकास गर्न अझ गाह्रो हुँदै गइरहेको छ
• प्रोफाइलिङ एप्लिकेसनहरूमा कठिनाइ छ (केवल लगहरू तपाईका लागि उपलब्ध छन्, तर सामान्य अर्थमा प्रोफाइलिङ छैन)
• कुनै संस्करण छैन

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

CI गरिबहरूको लागि हो, वा वेब स्टुडियोको लागि तपाईंको आफ्नै CI लेख्न लायक छ?

येकातेरिनबर्गको फ्ल्याग वेब स्टुडियोका प्रमुख मिखाइल रेडियोनोभले स्व-लिखित CI/CD को बारेमा कुरा गरे।

उसको स्टुडियो "म्यानुअल CI/CD" (SSH मार्फत सर्भरमा लग इन गर्नुहोस्, एक git पुल गर्नुहोस्, दिनमा 100 पटक दोहोर्याउनुहोस्) बाट जेनकिन्स र एउटा स्व-लिखित उपकरणमा गएको छ जसले तपाईंलाई कोड मोनिटर गर्न र पुलकिन्स भनिने रिलीजहरू प्रदर्शन गर्न अनुमति दिन्छ। ।

जेनकिन्सले किन काम गरेन? यसले पूर्वनिर्धारित रूपमा पर्याप्त लचिलोपन प्रदान गर्दैन र अनुकूलन गर्न धेरै गाह्रो थियो।

"झण्डा" Laravel (PHP फ्रेमवर्क) मा विकसित हुन्छ। CI/CD सर्भर विकास गर्दा, मिखाइल र उनका सहकर्मीहरूले टेलिस्कोप र दूत भनिने Laravel को निर्मित संयन्त्र प्रयोग गरे। परिणाम PHP मा सर्भर हो (कृपया ध्यान दिनुहोस्) जसले आगमन वेबहुक अनुरोधहरू प्रशोधन गर्दछ, फ्रन्टएन्ड र ब्याकइन्ड निर्माण गर्न सक्छ, विभिन्न सर्भरहरूमा डिप्लोय गर्न सक्छ, र स्ल्याकमा रिपोर्ट गर्दछ।

त्यसपछि, नीलो/हरियो डिप्लोइ प्रदर्शन गर्न र dev-stage-prod वातावरणमा समान सेटिङहरू गर्न सक्षम हुन, तिनीहरूले डकरमा स्विच गरे। फाइदाहरू उस्तै रह्यो, वातावरण र सिमलेस डिप्लोइमेन्टको सम्भाव्यताहरू थपियो, र डकरलाई सही रूपमा काम गर्न सिक्नु पर्ने आवश्यकता थपियो।

परियोजना Github मा छ

हामीले कसरी सर्भर रिलिज रोलब्याकहरूको संख्या 99% घटायौं

Devops खण्डमा अन्तिम रिपोर्ट Viktor Eremchenko, Miro.com (पहिले RealTimeBoard) मा लीड डेभोप्स इन्जिनियरबाट आएको थियो।

RealTimeBoard, Miro टोलीको प्रमुख उत्पादन, एक मोनोलिथिक Java अनुप्रयोगमा आधारित छ। सङ्कलन, परीक्षण र डाउनटाइम बिना यसलाई तैनात गर्न गाह्रो काम हो। यस अवस्थामा, कोडको यस्तो संस्करण डिप्लोय गर्न महत्त्वपूर्ण छ ताकि यसलाई रोल ब्याक गर्नुपर्दैन (यो एक भारी मोनोलिथ हो)।

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

बाटो कठिन र काँडादार बन्यो, र भिक्टरले संचित पीडा र आशावाद साझा गरे जुन त्यहाँ समाप्त भएन।

प्रश्न सोधेर किताब जिते

ब्याकइन्ड खण्ड

मैले 2 रिपोर्टहरू उपस्थित गर्न व्यवस्थित गरें - निकोले स्वेर्चकोभ (इभिल मार्टियन्स), सर्भरलेसको बारेमा, र ग्रिगोरी कोशेलेभ (कन्टुर कम्पनी) बाट टेलिमेट्रीको बारेमा।

केवल नश्वरहरूको लागि सर्भरलेस

यदि रुस्लान सिर्किनले सर्भरलेस भनेको के हो भनेर कुरा गरे भने, निकोलेले सर्भरलेस प्रयोग गरेर सरल अनुप्रयोगहरू देखाए, र AWS Lambda मा अनुप्रयोगहरूको लागत र गतिलाई असर गर्ने विवरणहरूको बारेमा कुरा गरे।

एउटा रोचक विवरण: न्यूनतम भुक्तान गरिएको तत्व 128 Mb मेमोरी र 100 ms CPU हो, यसको लागत $0,000000208 छ। यसबाहेक, प्रति महिना 1 मिलियन त्यस्ता अनुरोधहरू निःशुल्क छन्।

निकोलाईका केही कार्यहरूले प्रायः १०० ms सीमा नाघ्यो (मुख्य अनुप्रयोग रुबीमा लेखिएको थियो), त्यसैले तिनीहरूलाई Go मा पुन: लेख्दा उत्कृष्ट बचतहरू प्रदान गरियो।

Vostok Hercules — टेलिमेट्रीलाई फेरि उत्कृष्ट बनाउनुहोस्!

टेलीमेट्रीको बारेमा ग्रिगोरी कोशेलेभ (कन्टुर कम्पनी) बाट ब्याकएन्ड खण्डको पछिल्लो रिपोर्ट। टेलिमेट्री भनेको लग, मेट्रिक्स, एप्लिकेसन ट्रेस हो।

यस उद्देश्यको लागि, कन्टूरले Github मा पोस्ट गरिएको स्व-लिखित उपकरणहरू प्रयोग गर्दछ। रिपोर्टबाट उपकरण - हर्कुलस, github.com/vostok/hercules, टेलिमेट्री डाटा डेलिभर गर्न प्रयोग गरिन्छ।

Devops खण्डमा भ्लादिमिर लिलाको रिपोर्टले Elasticsearch मा लगहरू भण्डारण र प्रशोधन गर्ने बारे छलफल गर्‍यो, तर त्यहाँ अझै हजारौं उपकरणहरू र अनुप्रयोगहरूबाट लगहरू डेलिभर गर्ने कार्य छ, र भोस्टोक हर्कुलस जस्ता उपकरणहरूले तिनीहरूलाई समाधान गर्छन्।

सर्किटले धेरैलाई थाहा भएको बाटो पछ्यायो - RabbitMQ देखि Apache Kafka सम्म, तर सबै कुरा त्यति सरल छैन)) उनीहरूले सर्किटमा Zookeeper, Cassandra र Graphite थप्नुपर्‍यो। म यस रिपोर्टमा जानकारी पूर्ण रूपमा खुलासा गर्ने छैन (मेरो प्रोफाइल होइन), यदि तपाइँ इच्छुक हुनुहुन्छ भने, तपाइँ सम्मेलन वेबसाइटमा स्लाइड र भिडियोहरूको लागि पर्खन सक्नुहुन्छ।

यो अन्य सम्मेलनहरूसँग कसरी तुलना गर्छ?

म यसलाई मस्को र सेन्ट पीटर्सबर्गका सम्मेलनहरूसँग तुलना गर्न सक्दिन, म यसलाई युरालका अन्य कार्यक्रमहरू र समारामा 404 फेस्टसँग तुलना गर्न सक्छु।

DAMP 8 खण्डहरूमा आयोजित छ, यो उरल सम्मेलनहरूको लागि रेकर्ड हो। धेरै ठूलो विज्ञान र व्यवस्थापन खण्ड, यो पनि असामान्य छ। येकातेरिनबर्गमा दर्शकहरू धेरै संरचित छन् - शहरमा Yandex, Kontur, Tinkoff को लागि ठूलो विकास विभागहरू छन्, र यसले रिपोर्टहरूमा यसको छाप छोड्छ।

अर्को चाखलाग्दो बिन्दु यो हो कि धेरै कम्पनीहरूसँग सम्मेलनमा एकै पटकमा 3-4 स्पिकरहरू छन् (यो कन्टुर, एभिल मार्टियन्स, टिन्कोफको मामला थियो)। तिनीहरूमध्ये धेरै प्रायोजकहरू थिए, तर रिपोर्टहरू अरूसँग बराबर छन्, यी विज्ञापन रिपोर्टहरू होइनन्।

जाने कि नजाने ? यदि तपाईं Urals वा नजिकै बस्नुहुन्छ भने, तपाईंसँग अवसर छ र विषयहरूमा रुचि छ - हो, पक्कै पनि। यदि तपाईं लामो यात्राको बारेमा सोच्दै हुनुहुन्छ भने, म अघिल्लो वर्षका रिपोर्टहरू र भिडियो रिपोर्टहरूको शीर्षकहरू हेर्नेछु। www.youtube.com/user/videoitpeople/videos र निर्णय गरे।
क्षेत्रहरूमा सम्मेलनहरूको अर्को फाइदा, एक नियमको रूपमा, यो रिपोर्टहरू पछि स्पिकरसँग कुराकानी गर्न सजिलो छ; त्यहाँ त्यस्ता सञ्चारका लागि कम आवेदकहरू छन्।

डम्प र एकटेरिनबर्गलाई धन्यवाद! )

स्रोत: www.habr.com