DUMP conference | grep 'backend|devops'

Минулого тижня я сходив на IT конференцію DUMP (https://dump-ekb.ru/) в Єкатеринбурзі і хочу розповісти, про що йшлося у секціях Backend та Devops, і чи варті уваги регіональні IT конференції.

DUMP conference | grep 'backend|devops'
Микола Сверчков з 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-команд із розробників різних профілів).

Шлях виявився важким і тернистим, і Віктор поділився болю, що накопичився, і не закінчився при цьому оптимізмом.

DUMP conference | grep 'backend|devops'
Виграв книгу за запитання

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. Інформацію щодо цієї доповіді я повноцінно не розкрию (не мій профіль), якщо цікаво — можна дочекатися слайдів та відео на сайті конференції.

Як у порівнянні з іншими конференціями?

З конференціями в Москві та СПб не порівняю, можу порівняти з іншими заходами на Уралі і з фест у Самарі.

Дамп проводиться в 8 секцій, це рекорд для уральських конференцій. Дуже великі секції Science та Менеджмент, це теж незвичайно. Аудиторія в Єкатеринбурзі досить структурована - у місті є великі відділи розробки Яндекс, Контур, Тінькофф, це накладає відбиток і на доповіді.

Ще один цікавий момент - у багатьох компаній відразу по 3-4 доповідачі на конференції (так було у Контуру, Evil Martians, Тінькофф). Чимало їх ми були спонсорами, але доповіді цілком рівні з іншими, це рекламні доповіді.

Іти чи не йти? Якщо ви живете на Уралі або поряд, у вас є можливість та цікаві теми – так, звичайно. Якщо думаєте про дальню поїздку — я подивився б теми доповідей та відео доповідей з минулих років www.youtube.com/user/videoitpeople/videos та приймав рішення.
Ще один плюс конференцій у регіонах, як правило, легко поспілкуватися зі спікером після доповідей, просто претендентів на таке спілкування менше.

DUMP conference | grep 'backend|devops'

Дякую Дампу та Єкатеринбургу! )

Джерело: habr.com

Додати коментар або відгук