На мінулым тыдні я схадзіў на IT канферэнцыю DUMP (https://dump-ekb.ru/) у Екацярынбурзе і жадаю распавесці, пра што ішла гаворка ў секцыях Backend і Devops, і ці вартыя ўвагі рэгіянальныя IT канферэнцыі.
Мікалай Цвыркуноў з Evil Martians аб Serverless
Што там было ўвогуле?
Усяго на канферэнцыі было 8 секцый: Backend, Frontend, Mobile, Тэставанне і QA, Devops, Design, Science і Management.
Самыя вялікія залы, дарэчы, у Science і Management)) На ~350 чалавек кожны. Backend і Frontend ненашмат менш. Зала Devops была самая маленькая, але актыўная.
Я слухаў даклады ў секцыях Devops і Backend і крыху пагутарыў з дакладчыкамі. Жадаю распавесці аб расчыненых тэмах і зрабіць агляд гэтых секцый на канферэнцыі.
У секцыях Devops і Backend выступілі прадстаўнікі СКБ-Контур, DataArt, Evil Martians, екацярынбуржскай вэб-студыі Сцяг, Miro (RealTimeBoard). Тэмы тычыліся CI/CD, працы з сэрвісамі чэргаў, лагіравання, добра была раскрыты тэмы Serverless і праца з PostgreSQL у Go.
Яшчэ былі даклады Авіта, Тинькофф, Яндэкс, Jetstyle, Мегафон, слоік Ак Барс, але іх я наведаць фізічна не паспеў (відэазапісы і слайды дакладаў яшчэ не даступныя, абяцаюць выкласці на працягу 2-х тыдняў на dump-ekb.ru).
Devops секцыя
Што здзівіла - секцыя праходзіла ў самай маленькай зале, каля 50 месцаў. Людзі стаялі нават у праходах 🙂 Раскажу пра даклады, якія паспеў паслухаць.
Эластык вагой у петабайт
Пачалася секцыя з даклада Уладзіміра Ліла (СКБ-Контур) пра Elasticsearch у Контуры. У іх досыць вялікі і нагружаны Эластык (~800 Тб дадзеных, ~1.3 петабайт з улікам надмернасці). Elasticsearch для ўсіх сэрвісаў Контуру адзіны, складаецца з 2-х кластараў (з 7 і 9 сервераў), і настолькі важны, што ў Контуры ёсць спецыяльны Elasticsearch інжынер (уласна, сам Уладзімір).
Уладзімір таксама падзяліўся думкамі аб карысці ад Elasticsearch і праблемах, якія ён дастаўляе.
карысць:
- Усе логі ў адным месцы, лёгкі доступ да іх
- Захоўванне логаў на працягу года і іх лёгкі аналіз
- Высокая хуткасць працы з логамі
- Класная візуалізацыя дадзеных "са скрынкі"
Праблемы:
- брокер паведамленняў - must have (у Контуру яе ролю выконвае Kafka)
- асаблівасці працы з Elasticsearch Curator (перыядычна ствараецца высокая нагрузка ад рэгулярных заданняў у Curator)
- няма ўбудаванай аўтарызацыі (толькі за асобныя, дастаткова вялікія грошы, альбо як апенсорс убудовы рознай ступені гатоўнасці да прадакшн)
Пра Open Distro for Elasticsearch водгукі былі толькі станоўчыя 🙂 Тое ж пытанне аўтарызацыі там вырашана.
Адкуль петабайт?Іх ноды складаюцца з сервераў з 12*8 Tb SATA + 2*2 Tb SSD. Cold storage на SATA, SSD толькі пад гарачы кэш (hot storage).
7+9 сервераў, (7 + 9) * 12 * 8 = 1536 Tb.
Частка месца ў рэзерве, закладзена на надмернасць і інш.
У Elasticsearch адпраўляюцца логі каля 90 прыкладанняў, у тым ліку ўсе сэрвісы справаздачнасці Контуру, Эльба і інш.
Асаблівасці распрацоўкі на Serverless
Далей даклад Руслана Серкіна з DataArt аб Serverless.
Руслан распавёў аб тым, што такое распрацоўка з Serverless падыходам наогул, і якія яе асаблівасці.
Serverless – гэта падыход да распрацоўкі, пры якой распрацоўшчыкі ніякім чынам не датычацца інфраструктуры. Прыклад - AWS Lambda Serverless, Kubeless.io (Serverless ўнутры Kubernetes), Google Cloud Functions.
Ідэальнае Serverless дадатак - гэта проста функцыя, якая адпраўляе запыт Serverless правайдэру праз спецыяльны API Gateway. Ідэальны мікрасэрвіс, пры гэтым у тым жа AWS Lambda падтрымліваецца вялікі лік сучасных моў праграмавання. Кошт падтрымкі і разгорткі інфраструктуры становіцца нулявой у выпадку хмарных правайдэраў, падтрымка невялікіх прыкладанняў таксама будзе вельмі таннай (AWS Lambda - 0.2 $ / 1 мільён простых запытаў).
Маштабаванасць такой сістэмы з'яўляецца практычна ідэальнай - хмарны правайдэр пра гэта клапоціцца сам, Kubeless скейлі аўтаматычна ўнутры кластара Kubernetes.
Ёсць недахопы:
- распрацоўка вялікіх прыкладанняў становіцца складаней
- ёсць складанасць з прафіляваннем прыкладанняў (вам даступныя толькі логі, але не прафайлінг у звыклым разуменні)
- няма версійнасці
Скажу сапраўды, аб Serverless я пачуў яшчэ некалькі гадоў назад, але ўсе гэтыя гады мне было незразумела, як карэктна яго ўжываць. Пасля даклада Руслана разуменне з'явілася, а пасля даклада Мікалая Сверчкова (Evil Martians) з Backend секцыі замацавалася. Ужо не дарма схадзіў на канферэнцыю 🙂
CI для бедных, ці варта пісаць свой CI для вэб-студыі
Міхаіл Радзіёнаў, кіраўнік вэб-студыі Сцяг з Екацярынбурга, распавёў пра самапісны CI/CD.
Яго студыя прайшла шлях ад "ручнога CI/CD" (зайшоў на сервер па SSH, зрабіў git pull, паўтарыць 100 раз у дзень) да Jenkins і да самапіснай прылады, які дазваляе кантраляваць код і выконваць рэлізы пад назовам Pullkins.
Чаму не задаволіў Jenkins? Ён не даваў дастаткова гнуткасці па змаўчанні і быў занадта складаным пры кастамізацыі.
"Сцяг" распрацоўвае на Laravel (PHP фрэймворк). Пры распрацоўцы CI/CD сервера Міхась з калегамі скарысталіся ўбудаванымі механізмамі Laravel пад назовам Telescope і Envoy. У выніку атрымаўся сервер на php (звярніце ўвагу), які апрацоўвае incoming webhook запыты, які ўмее выконваць зборку фронтэнда, бэкенда, дэплоіць на розныя серверы і даваць справаздачу ў Slack.
Далей для магчымасці выконваць blue/green deploy, мець аднастайныя налады ў dev-stage-prod асяродках яны перайшлі на Docker. Плюсы засталіся ранейшымі, дадаліся магчымасці гамагенізацыі асяроддзя і бясшвоўнага дэплою, і дадалася неабходнасць вывучаць Docker для правільнай працы з ім.
Як мы зменшылі колькасць адкатаў серверных рэлізаў на 99%
Апошні даклад у Devops секцыі быў ад Віктара Яромчанкі, Lead devops engineer у Miro.com (былы RealTimeBoard).
У аснове RealTimeBoard, асноўнага прадукта каманды Miro, ляжыць маналітнае прыкладанне на Java. Збіраць, тэставаць і дэплоіць яго без даунтайма - складаная задача. Пры гэтым важна выконваць дэплой такой версіі кода, каб яго не даводзілася адкочваць (цяжкі маналіт жа).
На шляху да выбудоўвання сістэмы, якая дазваляе зрабіць гэта, Miro прайшлі шлях, які ўключае працу над архітэктурай, якія выкарыстоўваюцца інструментамі (Atlassian Bamboo, Ansible, etc), і працу над будовай каманд (у іх зараз ёсць выдзеленая Devops каманда + шмат асобных Scrum-каманд з распрацоўшчыкаў розных профіляў).
Шлях апынуўся цяжкім і цярністым, і Віктар падзяліўся назапашаным болем і не скончыўся пры гэтым аптымізмам.
Выйграў кнігу за пытанні
Backend секцыя
Я паспеў на 2 даклада – ад Мікалая Сверчкова (Evil Martians), таксама аб Serverless, і ад Рыгора Кошалева (кампанія Контур) аб тэлеметрыі.
Serverless для простых смяротных
Калі Руслан Сіркін распавядаў аб тым, што такое Serverless, Мікалай паказаў простыя прыкладанні з выкарыстаннем Serverless, і распавёў аб дэталях, якія ўплываюць на кошт і хуткасць працы прыкладанняў у AWS Lambda.
Цікавая дэталь: мінімальны аплачваны элемент – 128 Mb памяці і 100 ms CPU, ён варта 0,000000208 $. Пры гэтым 1 падобных запытаў у месяц бясплатны.
Некаторыя функцыі ў Мікалая часта выходзілі за ліміт у 100 ms (асноўнае прыкладанне было напісана на Ruby), таму перапісванне іх на Go дало выдатную эканомію.
Vostok Hercules – make telemetry great again!
Апошні даклад Backend секцыі ад Рыгора Кашалёва (кампанія Контур) аб тэлеметрыі. Тэлеметрыя - гэта логі, метрыкі, трасіроўкі прыкладанняў.
Контур выкарыстоўвае для гэтага ўласнаручна напісаныя прылады, выкладзеныя на Github. Інструмент з даклада - Hercules, , выкарыстоўваецца для дастаўкі дадзеных тэлеметрыі.
У дакладзе Уладзіміра Лілы ў секцыі Devops разглядалася захоўванне і апрацоўка логаў у Elasticsearch, але ёсць яшчэ задача даставіць логі з шматлікіх тысяч прылад і прыкладанняў, і іх вырашаюць прылады тыпу Vostok Hercules.
Контур мінуў вядомы для шматлікіх шлях ад RabbitMQ да Apache Kafka, але не ўсё так проста )) Ім прыйшлося дадаць у схему Zookeeper, Cassandra і Graphite. Інфармацыю па гэтым дакладзе я паўнавартасна не раскрою (не мой профіль), калі цікава - можна дачакацца слайдаў і відэа на сайце канферэнцыі.
Як у параўнанні з іншымі канферэнцыямі?
З канферэнцыямі ў Маскве і СПб не параўнаю, магу параўнаць з іншымі мерапрыемствамі на Ўрале і з 404фэст у Самары.
Дамп праводзіцца ў 8 секцый, гэта рэкорд для ўральскіх канферэнцый. Вельмі вялікія секцыі Science і Мэнэджмент, гэта таксама незвычайна. Аўдыторыя ў Екацярынбурзе дастаткова структураваная - у горадзе ёсць вялікія аддзелы распрацоўкі Яндэкс, Контур, Тинькофф, гэта накладвае адбітак і на даклады.
Яшчэ адзін цікавы момант - у многіх кампаній адразу па 3-4 дакладчыка на канферэнцыі (так было ў Контуру, Evil Martians, Тинькофф). Многія з іх былі спонсарамі, але даклады цалкам на ўзроўні з іншымі, гэта не рэкламныя даклады.
Ісці ці не ісці? Калі вы жывяце на Ўрале або побач, у вас ёсць магчымасць і цікавыя тэмы - так, вядома. Калі думаеце аб далёкай паездцы - я паглядзеў бы тэмы дакладаў і відэа дакладаў з мінулых гадоў і прымаў рашэнне.
Яшчэ адзін плюс канферэнцый у рэгіёнах, як правіла - лёгка пагутарыць са спікерам пасля дакладаў, проста прэтэндэнтаў на такія зносіны менш.
Дзякуй Дампу і Екацярынбургу! )
Крыніца: habr.com