DUMP conference | grep ‘backend\|devops’
На прошлой неделе я сходил на 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 для правильной работы с ним.
Проект есть на Github: github.com/michaelradionov/pullkins
Как мы уменьшили количество откатов серверных релизов на 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, github.com/vostok/hercules, используется для доставки данных телеметрии.
В докладе Владимира Лилы в секции Devops рассматривалось хранение и обработка логов в Elasticsearch, но есть еще задача доставить логи с многих тысяч устройств и приложений, и их решают инструменты типа Vostok Hercules.
Контур прошел известный для многих путь — от RabbitMQ к Apache Kafka, но не все так просто)) Им пришлось добавить в схему Zookeeper, Cassandra и Graphite. Информацию по этому докладу я полноценно не раскрою (не мой профиль), если интересно — можно дождаться слайдов и видео на сайте конференции.
Как по сравнению с другими конференциями?
С конференциями в Москве и СПб не сравню, могу сравнить с другими мероприятиями на Урале и с 404фест в Самаре.
ДАМП проводится в 8 секций, это рекорд для уральских конференций. Очень большие секции Science и Менеджмент, это тоже необычно. Аудитория в Екатеринбурге достаточно структурированная — в городе есть большие отделы разработки Яндекс, Контур, Тинькофф, это накладывает отпечаток и на доклады.
Еще один интересный момент — у многих компаний сразу по 3–4 докладчика на конференции (так было у Контура, Evil Martians, Тинькофф). Многие из них были спонсорами, но доклады вполне на уровне с другими, это не рекламные доклады.
Идти или не идти? Если вы живете на Урале или рядом, у вас есть возможность и интересны темы — да, конечно. Если думаете о дальней поездке — я посмотрел бы темы докладов и видео докладов с прошлых лет www.youtube.com/user/videoitpeople/videos и принимал решение.
Спасибо Дампу и Екатеринбургу!)
