DUMP კონფერენცია | grep 'backend|devops'

გასულ კვირას მივედი DUMP IT კონფერენციაზე (https://dump-ekb.ru/) ეკატერინბურგში და მინდა გითხრათ რა იყო განხილული Backend და Devops სექციებში და ღირს თუ არა რეგიონალური IT კონფერენციები ყურადღების ღირსი.

ნიკოლაი სვერჩკოვი ბოროტი მარსიანებიდან უსერვერის შესახებ

მაინც რა იყო?

საერთო ჯამში კონფერენციას 8 სექცია ჰქონდა: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.

ყველაზე დიდი დარბაზები, სხვათა შორის, არის მეცნიერება და მენეჯმენტი)) ~ 350 ადამიანზე თითოეული. Backend და Frontend არ არის ბევრად უფრო მცირე. Devops ოთახი იყო ყველაზე პატარა, მაგრამ აქტიური.

მოვისმინე მოხსენებები Devops-ისა და Backend-ის განყოფილებებში და ცოტა ველაპარაკე დინამიკებს. მსურს ვისაუბრო კონფერენციაზე განხილულ თემებზე და მიმოვიხილო ეს სექციები.

SKB-Kontur-ის, DataArt-ის, Evil Martians-ის, ეკატერინბურგის ვებ სტუდიის Flag-ის, Miro-ს (RealTimeBoard) წარმომადგენლებმა ისაუბრეს Devops და Backend სექციებში. თემები დაფარული CI/CD, რიგის სერვისებთან მუშაობა, ლოგირება; სერვერის გარეშე თემები და PostgreSQL-თან მუშაობა Go-ში კარგად იყო დაფარული.

იყო აგრეთვე Avito-ს, Tinkoff-ის, Yandex-ის, Jetstyle-ის, Megafon-ის, Ak Bars Bank-ის რეპორტაჟები, მაგრამ ფიზიკურად დასასწრებად დრო არ მქონდა (რეპორტაჟების ვიდეოჩანაწერები და სლაიდები ჯერ არ არის ხელმისაწვდომი, გვპირდებიან, რომ გამოქვეყნებენ 2 კვირაში. dump-ekb.ru-ზე).

Devops განყოფილება

რა გასაკვირი იყო ის, რომ განყოფილება ყველაზე პატარა დარბაზში იყო, დაახლოებით 50 ადგილიანი. ხალხიც კი იდგა დერეფნებში :) მოგიყვებით იმ მოხსენებებზე, რომელთა მოსმენაც მოვახერხე.

ელასტიური მასით პეტაბაიტი

სექცია დაიწყო ვლადიმერ ლილის (SKB-Kontur) მოხსენებით კონტურში Elasticsearch-ის შესახებ. მათ აქვთ საკმაოდ დიდი და დატვირთული ელასტიური (~800 ტბ მონაცემები, ~1.3 პეტაბაიტი სიჭარბის გათვალისწინებით). Elasticsearch ყველა Kontur სერვისისთვის არის ერთი, შედგება 2 კლასტერისგან (7 და 9 სერვერისგან) და იმდენად მნიშვნელოვანია, რომ კონტურს ჰყავს სპეციალური Elasticsearch ინჟინერი (სინამდვილეში, თავად ვლადიმერი).

ვლადიმირმა ასევე გააზიარა თავისი მოსაზრებები Elasticsearch-ის სარგებელსა და მის პრობლემებზე.

უპირატესობები:

• ყველა ჟურნალი ერთ ადგილზეა, მათზე მარტივი წვდომა
• მორების შენახვა ერთი წლის განმავლობაში და მათი მარტივად გაანალიზება
• მორების მუშაობის მაღალი სიჩქარე
• მონაცემთა მაგარი ვიზუალიზაცია ყუთიდან

პრობლემები:

• მესიჯების ბროკერი აუცილებელია (კონტურისთვის მის როლს კაფკა ასრულებს)
• Elasticsearch კურატორთან მუშაობის მახასიათებლები (პერიოდულად შექმნილი მაღალი დატვირთვა კურატორის რეგულარული ამოცანებიდან)
• არ არის ჩაშენებული ავტორიზაცია (მხოლოდ ცალკეული, საკმაოდ დიდი ფულისთვის, ან როგორც ღია კოდის დანამატები სხვადასხვა ხარისხის მზაობის წარმოებისთვის)

Open Distro for Elasticsearch-ზე მხოლოდ დადებითი მიმოხილვები იყო :) ავტორიზაციის იგივე საკითხი იქაც მოგვარებულია.

საიდან მოდის პეტაბაიტი?მათი კვანძები შედგება სერვერებისგან 12*8 Tb SATA + 2*2 Tb SSD. ცივი საცავი SATA-ზე, SSD მხოლოდ ცხელი ქეშისთვის (ცხელი საცავი).
7+9 სერვერი, (7 + 9) * 12 * 8 = 1536 ტბ.
ფართის ნაწილი არის რეზერვში, გამოყოფილია სიჭარბისთვის და ა.შ.
დაახლოებით 90 აპლიკაციის ჟურნალი იგზავნება Elasticsearch-ში, მათ შორის Kontur, Elba და ა.შ.

განვითარების მახასიათებლები სერვერზე

შემდეგი არის რუსლან სერკინის მოხსენება DataArt-დან სერვერის გარეშე.

რუსლანმა ისაუბრა იმაზე, თუ რა არის ზოგადად სერვერის მიდგომით განვითარება და რა არის მისი მახასიათებლები.

სერვერის გარეშე არის განვითარების მიდგომა, რომლის დროსაც დეველოპერები არანაირად არ ეხებიან ინფრასტრუქტურას. მაგალითი - AWS Lambda Serverless, Kubeless.io (Serverless შიგნით Kubernetes), Google Cloud Functions.

იდეალური სერვერის პროგრამა უბრალოდ ფუნქციაა, რომელიც უგზავნის მოთხოვნას სერვერის პროვაიდერს სპეციალური API Gateway-ის მეშვეობით. იდეალური მიკროსერვისი, ხოლო AWS Lambda ასევე მხარს უჭერს თანამედროვე პროგრამირების ენების დიდ რაოდენობას. ინფრასტრუქტურის შენარჩუნებისა და განლაგების ღირებულება ღრუბლოვანი პროვაიდერების შემთხვევაში ნულოვანი ხდება, მცირე აპლიკაციების მხარდაჭერა ასევე ძალიან იაფი იქნება (AWS Lambda - $0.2 / 1 მილიონი მარტივი მოთხოვნა).

ასეთი სისტემის მასშტაბურობა თითქმის იდეალურია - ღრუბლოვანი პროვაიდერი თავად ზრუნავს ამაზე, Kubeless ავტომატურად მასშტაბირებს Kubernetes კლასტერში.

არსებობს უარყოფითი მხარეები:

• დიდი აპლიკაციების შემუშავება უფრო რთული ხდება
• არის აპლიკაციების პროფილირების სირთულე (თქვენთვის ხელმისაწვდომია მხოლოდ ჟურნალები, მაგრამ არა პროფილირება ჩვეულებრივი გაგებით)
• ვერსიების გარეშე

მართალი გითხრათ, რამდენიმე წლის წინ გავიგე Serverless-ის შესახებ, მაგრამ მთელი ამ წლების განმავლობაში ჩემთვის გაუგებარი იყო მისი სწორად გამოყენება. რუსლანის მოხსენების შემდეგ გაჩნდა გაგება, ხოლო ნიკოლაი სვერჩკოვის (ბოროტი მარსიანელები) მოხსენების შემდეგ Backend-ის განყოფილებიდან, იგი გაერთიანდა. ტყუილად არ მივედი კონფერენციაზე :)

CI არის ღარიბებისთვის, თუ ღირს თუ არა საკუთარი CI-ის დაწერა ვებ სტუდიისთვის?

მიხაილ რადიონოვმა, ვებ სტუდიის Flag-ის ხელმძღვანელმა ეკატერინბურგიდან, ისაუბრა თვითნაწერ CI/CD-ზე.

მისი სტუდია „სახელმძღვანელო CI/CD“-დან (შესული იყო სერვერზე SSH-ის საშუალებით, აკეთებდა git pull-ს, მეორდებოდა დღეში 100-ჯერ) ჯენკინსზე და სახლში დაწერილ ინსტრუმენტზე, რომელიც საშუალებას გაძლევთ აკონტროლოთ კოდი და შეასრულოთ გამოშვებები სახელწოდებით Pullkins.

რატომ არ მუშაობდა ჯენკინსი? ის არ უზრუნველყოფდა საკმარის მოქნილობას ნაგულისხმევად და ძალიან რთული იყო მისი მორგება.

„დროშა“ ვითარდება Laravel-ში (PHP Framework). CI/CD სერვერის შემუშავებისას, მიხაილმა და მისმა კოლეგებმა გამოიყენეს Laravel-ის ჩაშენებული მექანიზმები, სახელწოდებით Telescope and Envoy. შედეგი არის სერვერი PHP-ში (გთხოვთ გაითვალისწინოთ), რომელიც ამუშავებს შემომავალ webhook-ის მოთხოვნებს, შეუძლია შექმნას ფრონტენტი და ბექენდი, განთავსდეს სხვადასხვა სერვერებზე და მოახსენოს Slack-ს.

შემდეგ, იმისათვის, რომ შეძლონ ლურჯი/მწვანე განლაგების შესრულება და ერთიანი პარამეტრები dev-stage-prod გარემოში, ისინი გადავიდნენ Docker-ზე. უპირატესობები იგივე დარჩა, დაემატა გარემოს ჰომოგენიზაციისა და უწყვეტი განლაგების შესაძლებლობები და დაემატა Docker-ის სწავლის საჭიროება მასთან სწორად მუშაობისთვის.

პროექტი Github-ზეა

როგორ შევამცირეთ სერვერის გამოშვების უკან დაბრუნება 99%-ით

ბოლო მოხსენება Devops-ის განყოფილებაში იყო ვიქტორ ერემჩენკო, წამყვანი devops ინჟინერი Miro.com-ზე (ყოფილი RealTimeBoard).

RealTimeBoard, Miro გუნდის ფლაგმანი პროდუქტი, დაფუძნებულია მონოლითურ Java აპლიკაციაზე. მისი შეგროვება, ტესტირება და დანერგვა შეფერხების გარეშე რთული ამოცანაა. ამ შემთხვევაში, მნიშვნელოვანია კოდის ასეთი ვერსიის განლაგება, რათა არ მოხდეს მისი უკან დაბრუნება (ეს მძიმე მონოლითია).

სისტემის შექმნის გზაზე, რომელიც ამის საშუალებას მოგცემთ, მირომ გაიარა გზა, რომელიც მოიცავდა მუშაობას არქიტექტურაზე, გამოყენებულ ინსტრუმენტებზე (Atlassian Bamboo, Ansible და ა.შ.) და მუშაობა გუნდების სტრუქტურაზე (მათ ახლა აქვთ Devops-ის თავდადებული გუნდი + ბევრი ცალკე Scrum გუნდი სხვადასხვა პროფილის დეველოპერებისგან).

გზა რთული და ეკლიანი გამოდგა და ვიქტორმა გაიზიარა დაგროვილი ტკივილი და ოპტიმიზმი, რომელიც ამით არ დასრულებულა.

მოიგო წიგნი კითხვების დასმისთვის

Backend განყოფილება

მე მოვახერხე 2 რეპორტაჟის დასწრება - ნიკოლაი სვერჩკოვისგან (ბოროტი მარსიანელები), ასევე სერვერის გარეშე და გრიგორი კოშელევისგან (კომპანია Kontur) ტელემეტრიის შესახებ.

უბრალო მოკვდავებისთვის სერვერის გარეშე

თუ რუსლან სირკინმა ისაუბრა რა არის სერვერის გარეშე, ნიკოლაიმ აჩვენა მარტივი აპლიკაციები სერვერის გარეშე და ისაუბრა იმ დეტალებზე, რომლებიც გავლენას ახდენენ AWS Lambda-ში აპლიკაციების ღირებულებასა და სიჩქარეზე.

საინტერესო დეტალი: მინიმალური ფასიანი ელემენტია 128 მბ მეხსიერება და 100 ms CPU, ღირს $0,000000208. უფრო მეტიც, თვეში 1 მილიონი ასეთი მოთხოვნა უფასოა.

ნიკოლაის ზოგიერთი ფუნქცია ხშირად აჭარბებდა 100 ms-ის ლიმიტს (მთავარი აპლიკაცია დაწერილი იყო Ruby-ში), ამიტომ Go-ში მათი გადაწერა შესანიშნავ დაზოგვას უზრუნველყოფდა.

ვოსტოკ ჰერკულესი - ისევ გახადე ტელემეტრია შესანიშნავი!

გრიგორი კოშელევის (კომპანია Kontur) Backend განყოფილების უახლესი ანგარიში ტელემეტრიის შესახებ. ტელემეტრია ნიშნავს ჟურნალებს, მეტრიკას, აპლიკაციის კვალს.

ამ მიზნით, Contour იყენებს Github-ზე გამოქვეყნებულ თვითნაწერ ინსტრუმენტებს. ინსტრუმენტი მოხსენებიდან - ჰერკულესი, github.com/vostok/hercules, გამოიყენება ტელემეტრიული მონაცემების მიწოდებისთვის.

ვლადიმერ ლილას მოხსენებაში Devops-ის განყოფილებაში განხილული იყო ჟურნალების შენახვა და დამუშავება Elasticsearch-ში, მაგრამ ჯერ კიდევ არსებობს მრავალი ათასი მოწყობილობიდან და აპლიკაციიდან ჟურნალების მიწოდების ამოცანა და ინსტრუმენტები, როგორიცაა Vostok Hercules, აგვარებს მათ.

წრე ბევრისთვის ნაცნობ გზას გაჰყვა - RabbitMQ-დან Apache Kafka-მდე, მაგრამ ყველაფერი ასე მარტივი არ არის)) მათ წრეში უნდა დაემატებინათ Zookeeper, Cassandra და Graphite. მე სრულად არ გავამჟღავნებ ინფორმაციას ამ მოხსენების შესახებ (არა ჩემს პროფილზე), თუ გაინტერესებთ, შეგიძლიათ დაელოდოთ სლაიდებსა და ვიდეოებს კონფერენციის ვებსაიტზე.

როგორ ადარებს ის სხვა კონფერენციებს?

მე ვერ შევადარებ მას მოსკოვისა და პეტერბურგის კონფერენციებს, შემიძლია შევადარო ურალის სხვა ღონისძიებებს და სამარაში 404fest-ს.

DAMP ტარდება 8 სექციაში, ეს არის რეკორდი ურალის კონფერენციებისთვის. ძალიან დიდი მეცნიერებისა და მენეჯმენტის სექციები, ეს ასევე უჩვეულოა. ეკატერინბურგის აუდიტორია საკმაოდ სტრუქტურირებულია - ქალაქს აქვს Yandex, Kontur, Tinkoff-ის განვითარების დიდი განყოფილებები და ეს თავის კვალს ტოვებს მოხსენებებზე.

კიდევ ერთი საინტერესო მომენტია ის, რომ ბევრ კომპანიას ჰყავს კონფერენციაზე ერთდროულად 3-4 მომხსენებელი (ასე იყო Kontur, Evil Martians, Tinkoff). ბევრი მათგანი იყო სპონსორი, მაგრამ რეპორტაჟები საკმაოდ შეესაბამება სხვებს, ეს არ არის სარეკლამო რეპორტაჟები.

წავიდე თუ არ წავიდე? თუ თქვენ ცხოვრობთ ურალში ან მის მახლობლად, გაქვთ შესაძლებლობა და დაინტერესებული ხართ თემებით - დიახ, რა თქმა უნდა. თუ გრძელ მოგზაურობაზე ფიქრობთ, გადავხედავ წინა წლების რეპორტაჟებისა და ვიდეო რეპორტაჟების თემებს www.youtube.com/user/videoitpeople/videos და მიიღო გადაწყვეტილება.
რეგიონებში კონფერენციების კიდევ ერთი უპირატესობა, როგორც წესი, არის ის, რომ მოხსენებების შემდეგ მომხსენებელთან კომუნიკაცია მარტივია, უბრალოდ, ასეთი კომუნიკაციისთვის აპლიკანტები ნაკლებია.

მადლობა დუმპს და ეკატერინბურგს! )

წყარო: www.habr.com