डंप परिषद | grep 'backend|devops'

गेल्या आठवड्यात मी येकातेरिनबर्ग येथे DUMP IT परिषदेत (https://dump-ekb.ru/) गेलो होतो आणि बॅकएंड आणि डेव्हॉप्स विभागांमध्ये काय चर्चा झाली आणि प्रादेशिक आयटी परिषद लक्ष देण्यासारखे आहे की नाही हे मला सांगायचे आहे.

सर्व्हरलेस बद्दल एव्हिल मार्टियन्स कडून निकोले स्वेर्चकोव्ह

तरीही तिथे काय होते?

एकूण, कॉन्फरन्समध्ये 8 विभाग होते: बॅकएंड, फ्रंटएंड, मोबाइल, टेस्टिंग आणि क्यूए, डेव्हॉप्स, डिझाइन, सायन्स आणि मॅनेजमेंट.

तसे, सर्वात मोठे हॉल विज्ञान आणि व्यवस्थापन येथे आहेत)) प्रत्येकी ~350 लोकांसाठी. बॅकएंड आणि फ्रंटएंड फारसे लहान नाहीत. Devops खोली सर्वात लहान होती, पण सक्रिय.

मी Devops आणि Backend विभागातील अहवाल ऐकले आणि स्पीकर्सशी थोडे बोललो. मी परिषदेत समाविष्ट असलेल्या विषयांबद्दल बोलू इच्छितो आणि या विभागांचे पुनरावलोकन करू इच्छितो.

SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) चे प्रतिनिधी डेव्हॉप्स आणि बॅकएंड विभागात बोलले. CI/CD कव्हर केलेले विषय, रांगेतील सेवांसह काम करणे, लॉगिंग करणे; सर्व्हरलेस विषय आणि Go मधील PostgreSQL सह काम करणे हे चांगले कव्हर केले गेले.

Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank द्वारे देखील अहवाल आले होते, परंतु माझ्याकडे त्यांना प्रत्यक्ष उपस्थित राहण्यासाठी वेळ मिळाला नाही (व्हिडिओ रेकॉर्डिंग आणि अहवालांच्या स्लाइड्स अद्याप उपलब्ध नाहीत, ते 2 आठवड्यांच्या आत पोस्ट करण्याचे वचन देतात. dump-ekb.ru वर).

Devops विभाग

आश्चर्याची गोष्ट म्हणजे हा विभाग सर्वात लहान हॉलमध्ये, सुमारे 50 जागांचा होता. लोक अगदी गल्लीत उभे होते :) मी तुम्हाला ऐकण्यासाठी व्यवस्थापित केलेल्या अहवालांबद्दल सांगेन.

पेटाबाइट वजनाचे लवचिक

खंडाची सुरुवात व्लादिमीर लिल (SKB-Kontur) यांनी कोंटूरमधील Elasticsearch बद्दल दिलेल्या अहवालाने झाली. त्यांच्याकडे बऱ्यापैकी मोठे आणि लोड केलेले लवचिक (~800 TB डेटा, ~1.3 पेटाबाइट्स रिडंडंसी लक्षात घेऊन) आहे. सर्व Kontur सेवांसाठी Elasticsearch एकच आहे, त्यात 2 क्लस्टर (7 आणि 9 सर्व्हरचे) असतात आणि हे इतके महत्त्वाचे आहे की कोंटूरकडे विशेष इलास्टिकसर्च अभियंता आहे (खरं तर, व्लादिमीर स्वतः).

व्लादिमीरने इलॅस्टिकसर्चचे फायदे आणि त्यामुळे होणाऱ्या समस्यांबद्दल त्यांचे विचारही शेअर केले.

लाभ:

• सर्व नोंदी एकाच ठिकाणी आहेत, त्यांच्यापर्यंत सहज प्रवेश आहे
• एका वर्षासाठी लॉग संग्रहित करणे आणि त्यांचे सहजपणे विश्लेषण करणे
• लॉगसह काम करण्याची उच्च गती
• बॉक्सच्या बाहेर छान डेटा व्हिज्युअलायझेशन

समस्या:

• संदेश दलाल असणे आवश्यक आहे (कोंटूरसाठी त्याची भूमिका काफ्काने केली आहे)
• इलास्टिकसर्च क्युरेटरसह काम करण्याची वैशिष्ट्ये (क्युरेटरमधील नियमित कार्यांमधून वेळोवेळी उच्च भार तयार केला जातो)
• कोणतेही अंगभूत अधिकृतता नाही (केवळ स्वतंत्र, मोठ्या पैशासाठी किंवा उत्पादनासाठी वेगवेगळ्या तत्परतेचे मुक्त स्त्रोत प्लगइन म्हणून)

Elasticsearch साठी ओपन डिस्ट्रोबद्दल फक्त सकारात्मक पुनरावलोकने होती :) अधिकृततेची समान समस्या तिथे सोडवली गेली आहे.

पेटाबाइट कुठून येते?त्यांच्या नोड्समध्ये 12*8 Tb SATA + 2*2 Tb SSD सह सर्व्हर असतात. SATA वर कोल्ड स्टोरेज, SSD फक्त हॉट कॅशेसाठी (हॉट स्टोरेज).
7+9 सर्व्हर, (7 + 9) * 12 * 8 = 1536 Tb.
जागेचा काही भाग राखीव आहे, रिडंडंसीसाठी बाजूला ठेवा, इ.
कोंटूर, एल्बा इ.च्या सर्व रिपोर्टिंग सेवांसह सुमारे 90 अर्जांचे लॉग इलास्टिकसर्चला पाठवले जातात.

सर्व्हरलेसवर विकासाची वैशिष्ट्ये

पुढे सर्व्हरलेस बद्दल डेटाआर्ट मधील रुस्लान सेर्किनचा अहवाल आहे.

सर्वसाधारणपणे सर्व्हरलेस पध्दतीचा विकास काय आहे आणि त्याची वैशिष्ट्ये काय आहेत याबद्दल रुस्लान बोलले.

सर्व्हरलेस हा विकासाचा दृष्टीकोन आहे ज्यामध्ये विकासक कोणत्याही प्रकारे पायाभूत सुविधांना स्पर्श करत नाहीत. उदाहरण - AWS Lambda Serverless, Kubeless.io (Kubernetes मध्ये सर्व्हरलेस), Google क्लाउड फंक्शन्स.

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

अशा प्रणालीची स्केलेबिलिटी जवळजवळ आदर्श आहे - क्लाउड प्रदाता स्वतः याची काळजी घेतो, कुबेलेस कुबर्नेट्स क्लस्टरमध्ये आपोआप स्केल करतो.

तोटे आहेत:

• मोठे अनुप्रयोग विकसित करणे अधिक कठीण होत आहे
• प्रोफाइलिंग ऍप्लिकेशन्समध्ये अडचण आहे (केवळ लॉग तुमच्यासाठी उपलब्ध आहेत, परंतु नेहमीच्या अर्थाने प्रोफाइलिंग नाही)
• आवृत्ती नाही

खरे सांगायचे तर, मी काही वर्षांपूर्वी सर्व्हरलेस बद्दल ऐकले होते, परंतु इतक्या वर्षात ते योग्यरित्या कसे वापरायचे ते मला स्पष्ट नव्हते. रुस्लानच्या अहवालानंतर, समज दिसून आली आणि बॅकएंड विभागातील निकोलाई स्वेर्चकोव्ह (इव्हिल मार्टियन्स) च्या अहवालानंतर, ते एकत्रित केले गेले. मी परिषदेला गेलो हे व्यर्थ ठरले नाही :)

CI गरीबांसाठी आहे, की वेब स्टुडिओसाठी तुमचा स्वतःचा CI लिहिणे योग्य आहे का?

येकातेरिनबर्ग येथील फ्लॅग वेब स्टुडिओचे प्रमुख मिखाईल रेडिओनोव्ह यांनी स्व-लिखित CI/CD बद्दल सांगितले.

त्याचा स्टुडिओ "मॅन्युअल सीआय/सीडी" (SSH द्वारे सर्व्हरमध्ये लॉग इन करा, एक गिट पुल करा, दिवसातून 100 वेळा पुनरावृत्ती करा) वरून जेनकिन्स आणि स्व-लिखित टूलवर गेला आहे जो तुम्हाला कोडचे निरीक्षण करू देतो आणि पुलकिन्स नावाचे प्रकाशन करू देतो. .

जेनकिन्सने का काम केले नाही? ते डीफॉल्टनुसार पुरेशी लवचिकता प्रदान करत नाही आणि सानुकूलित करणे खूप कठीण होते.

Laravel (PHP फ्रेमवर्क) मध्ये “ध्वज” विकसित होतो. CI/CD सर्व्हर विकसित करताना, मिखाईल आणि त्याच्या सहकाऱ्यांनी Laravel च्या अंगभूत यंत्रणेचा वापर केला ज्याला Telescope आणि Envoy म्हणतात. परिणाम म्हणजे PHP मधील सर्व्हर (कृपया लक्षात ठेवा) जो इनकमिंग वेबहुक विनंत्यांवर प्रक्रिया करतो, फ्रंटएंड आणि बॅकएंड तयार करू शकतो, वेगवेगळ्या सर्व्हरवर तैनात करू शकतो आणि स्लॅकला अहवाल देऊ शकतो.

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

प्रकल्प Github वर आहे

आम्ही सर्व्हर रिलीझ रोलबॅकची संख्या 99% ने कशी कमी केली

Devops विभागातील शेवटचा अहवाल Viktor Eremchenko, Miro.com (पूर्वीचे RealTimeBoard) मधील प्रमुख डेव्हॉप्स अभियंता यांचा होता.

RealTimeBoard, Miro टीमचे प्रमुख उत्पादन, एका मोनोलिथिक Java अनुप्रयोगावर आधारित आहे. डाउनटाइमशिवाय ते गोळा करणे, चाचणी करणे आणि तैनात करणे हे एक कठीण काम आहे. या प्रकरणात, कोडची अशी आवृत्ती उपयोजित करणे महत्वाचे आहे जेणेकरून ते परत आणले जाण्याची गरज नाही (हे एक भारी मोनोलिथ आहे).

तुम्हाला हे करण्याची परवानगी देणारी प्रणाली तयार करण्याच्या मार्गावर, मिरो एक मार्गाने गेला ज्यामध्ये आर्किटेक्चरवर काम करणे, वापरलेली साधने (अ‍ॅटलाशियन बांबू, अॅन्सिबल इ.) आणि संघांच्या संरचनेवर काम करणे समाविष्ट आहे (त्यांच्याकडे आता आहे एक समर्पित डेव्हॉप्स टीम + वेगवेगळ्या प्रोफाइलच्या डेव्हलपर्सकडून अनेक वेगळे स्क्रम टीम).

मार्ग कठीण आणि काटेरी बनला आणि व्हिक्टरने संचित वेदना आणि आशावाद सामायिक केला जो तिथेच संपला नाही.

प्रश्न विचारण्यासाठी पुस्तक जिंकले

बॅकएंड विभाग

मी 2 अहवालांना उपस्थित राहण्यास व्यवस्थापित केले - निकोले स्वेर्चकोव्ह (एव्हिल मार्टियन्स), सर्व्हरलेस बद्दल आणि ग्रिगोरी कोशेलेव्ह (कोंटूर कंपनी) कडून टेलीमेट्रीबद्दल.

निव्वळ मर्त्यांसाठी सेवारहित

जर रुस्लान सरकिनने सर्व्हरलेस म्हणजे काय याबद्दल बोललो, तर निकोलेने सर्व्हरलेस वापरून साधे ऍप्लिकेशन दाखवले आणि AWS Lambda मधील ऍप्लिकेशन्सची किंमत आणि गती प्रभावित करणाऱ्या तपशीलांबद्दल बोलले.

एक मनोरंजक तपशील: किमान सशुल्क घटक 128 Mb मेमरी आणि 100 ms CPU आहे, त्याची किंमत $0,000000208 आहे. शिवाय, दरमहा अशा 1 दशलक्ष विनंत्या विनामूल्य आहेत.

निकोलाईच्या काही कार्यांनी अनेकदा 100 ms मर्यादा ओलांडली होती (मुख्य ऍप्लिकेशन रुबीमध्ये लिहिलेले होते), त्यामुळे त्यांना Go मध्ये पुन्हा लिहिल्याने उत्कृष्ट बचत होते.

व्होस्टोक हरक्यूलिस — टेलीमेट्री पुन्हा छान बनवा!

टेलीमेट्रीबद्दल ग्रिगोरी कोशेलेव्ह (कोंटूर कंपनी) कडील बॅकएंड विभागाचा नवीनतम अहवाल. टेलीमेट्री म्हणजे लॉग, मेट्रिक्स, ऍप्लिकेशन ट्रेस.

या उद्देशासाठी, कंटूर Github वर पोस्ट केलेली स्व-लिखित साधने वापरते. अहवालातील साधन - हरक्यूलिस, github.com/vostok/hercules, टेलीमेट्री डेटा वितरीत करण्यासाठी वापरला जातो.

Devops विभागातील व्लादिमीर लिलाच्या अहवालात Elasticsearch मध्ये लॉग संग्रहित करणे आणि त्यावर प्रक्रिया करणे यावर चर्चा केली आहे, परंतु अजूनही हजारो डिव्हाइसेस आणि ऍप्लिकेशन्समधून लॉग वितरित करण्याचे कार्य आहे आणि व्होस्टोक हरक्यूलिस सारखी साधने त्यांचे निराकरण करतात.

सर्किटने अनेकांना ज्ञात असलेल्या मार्गाचा अवलंब केला - RabbitMQ ते Apache Kafka पर्यंत, परंतु सर्वकाही इतके सोपे नाही)) त्यांना सर्किटमध्ये Zookeeper, Cassandra आणि Graphite जोडावे लागले. मी या अहवालावरील माहिती पूर्णपणे उघड करणार नाही (माझे प्रोफाइल नाही), तुम्हाला स्वारस्य असल्यास, तुम्ही कॉन्फरन्स वेबसाइटवरील स्लाइड्स आणि व्हिडिओंची प्रतीक्षा करू शकता.

इतर परिषदांशी त्याची तुलना कशी होते?

मी त्याची मॉस्को आणि सेंट पीटर्सबर्गमधील परिषदांशी तुलना करू शकत नाही, मी त्याची तुलना युरल्समधील इतर कार्यक्रमांशी आणि समारामधील 404 फेस्टशी करू शकतो.

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

आणखी एक मनोरंजक मुद्दा असा आहे की बर्याच कंपन्यांमध्ये कॉन्फरन्समध्ये एकाच वेळी 3-4 स्पीकर असतात (हे कॉन्टूर, एव्हिल मार्टियन्स, टिंकॉफच्या बाबतीत होते). त्यापैकी बरेच प्रायोजक होते, परंतु अहवाल इतरांच्या बरोबरीने आहेत, हे जाहिरात अहवाल नाहीत.

जायचे की नाही जायचे? आपण युरल्समध्ये किंवा जवळपास राहत असल्यास, आपल्याकडे संधी आहे आणि विषयांमध्ये स्वारस्य आहे - होय, नक्कीच. जर तुम्ही लांबच्या सहलीचा विचार करत असाल, तर मी मागील वर्षांतील अहवाल आणि व्हिडिओ अहवालांचे विषय बघेन www.youtube.com/user/videoitpeople/videos आणि निर्णय घेतला.
प्रदेशांमधील कॉन्फरन्सचा आणखी एक फायदा, नियमानुसार, अहवालानंतर स्पीकरशी संवाद साधणे सोपे आहे; अशा संप्रेषणासाठी कमी अर्जदार आहेत.

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

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