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

Как мы уменьшили количество откатов серверных релизов на 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 и принимал решение.
Еще один плюс конференций в регионах, как правило — легко пообщаться со спикером после докладов, просто претендентов на такое общение меньше.

Спасибо Дампу и Екатеринбургу! )

Источник: habr.com