Миналата седмица посетих IT конференция DUMP (https://dump-ekb.ru/) в Екатеринбург и искам да разкажа за темите, обсъждани в секциите Backend и Devops, и дали си заслужава вниманието регионалните IT конференции.
Николай Сверчков от Evil Martians за Serverless
Какво всъщност се случи там?
На конференцията имаше общо 8 секции: Backend, Frontend, Mobile, Тестиране и QA, Devops, Дизайн, Наука и Мениджмънт.
Най-големите зали, между другото, бяха в секциите Наука и Мениджмънт )) По около 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 в Контур. Те имат доста голям и натоварен Elastic (~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.
Защо Дженкинс не ни удовлетворяваше? Той не предоставяше достатъчна гъвкавост по подразбиране и беше твърде сложен за кастомизация.
„Флаг” разрабатва на Laravel (PHP фреймуорк). При разработката на CI/CD сървера, Михаил и колегите му използваха вградените механизми на Laravel, наречени Telescope и Envoy. В резултат на това получихме сървър на PHP (обърнете внимание), който обработва входящи webhook заявки, успява да извършва сборка на фронтенда и бектенда, да деплойва на различни сървъри и да извършва отчети в Slack.
След това, за да имат възможност да извършват blue/green деплой, с еднообразни настройки в dev-stage-prod среди, те преминаха на Docker. Предимствата останаха същите, добавиха се възможности за хомогенизация на средата и безшевен деплой, и се наложи да изучават Docker за правилната работа с него.
Как намалихме броя на откатите на сървърните релизи с 99%.
Последната презентация в секцията DevOps беше от Виктор Еремченко, Lead DevOps инженер в Miro.com (бивш RealTimeBoard).
В основата на RealTimeBoard, основния продукт на екипа на Miro, лежи монолитно приложение на Java. Събирането, тестването и деплойването му без престой — сложна задача. Важно е да се извърши деплой на версия на кода, която не трябва да бъде откатена (всичко това е тежък монолит).
По пътя към изграждането на система, която позволява да се постигне това, Miro преминаха през път, включващ работа по архитектурата, използваните инструменти (Atlassian Bamboo, Ansible и т.н.), и работа по изграждането на екипи (сега те разполагат с отделен DevOps екип + много отделни Scrum екипи от разработчици с различни профили).
Пътят се оказа труден и трънлив, а Виктор сподели натрупаната болка и непрекъснатото оптимистично настроение.
Спечелих книга за въпросите.
Секция Backend.
Успях да присъствам на две презентации — от Николай Сверчков (Evil Martians), също за Serverless, и от Григорий Кошелев (компания Контур) за телеметрия.
Serverless за обикновените смъртни.
Докато Руслан Сиркин разказваше какво е Serverless, Николай показа прости приложения с използване на Serverless и разказа за детайлите, които влияят на цената и скоростта на работа на приложенията в AWS Lambda.
Интересен детайл: минималният платим елемент — 128 Mb памет и 100 ms CPU, струва 0,000000208$. В същото време 1 милион подобни заявки на месец е безплатен.
Някои функции на Николай често надвишаваха лимита от 100 ms (основното приложение беше написано на Ruby), така че пренаписването им на Go осигури отлична икономия.
Vostok Hercules — върнете телеметрията обратно на върха!
Последният доклад на секция Backend от Григория Кошелева (компания Контур) за телеметрията. Телеметрията е логове, метрики, трасировки на приложения.
Контур използва за това ръчно написани инструменти, публикувани на Github. Инструментът от доклада — Hercules, , се използва за доставка на данни за телеметрия.
В доклада на Владимира Лила в секцията Devops се разглеждаше съхранението и обработката на логове в Elasticsearch, но има и друга задача — да се доставят логовете от хиляди устройства и приложения, и за това се използват инструменти като Vostok Hercules.
Контур премина известния път — от RabbitMQ до Apache Kafka, но не всичко е толкова просто )) Им се наложи да добавят във схемата Zookeeper, Cassandra и Graphite. Информацията от този доклад не мога да я разкрия напълно (не е моята област), ако ви интересува — може да изчакате слайдове и видео на сайта на конференцията.
Как е в сравнение с другите конференции?
Не мога да сравня с конференциите в Москва и СПб, мога да сравня с други събития в Урал и с 404фест в Самара.
ДАМП се провежда в 8 секции, което е рекорд за уралските конференции. Много големи секции на Science и Мениджмънт, което също е необичайно. Аудиторията в Екатеринбург е добре структурирана — в града има големи разработки на Яндекс, Контур, Тинькофф, което оказва влияние и върху докладите.
Още един интересен момент — много компании имат по 3–4 докладчика на конференцията (така беше при Контур, Evil Martians, Тинькофф). Много от тях бяха спонсори, но докладите бяха на ниво с останалите, не са рекламни.
Да отидете или не? Ако живеете в Урал или в близост, имате възможност и темите ви интересуват — да, разбира се. Ако мислите за дълго пътуване — бих се загледал в темите на докладите и видеата от предишни години. и взимах решение.
Още един плюс на конференциите в регионите е, че обикновено е по-лесно да общувате със спикерите след докладите, просто претендентите за такова общуване са по-малко.
Благодаря на Дамп и Екатеринбург! )
Източник: habr.com
