Хабрахабр

Интересные доклады на HighLoad++ Siberia 2019 по версии Plesk

Всем привет! В июне в Новосибирске прошла конференция по разработке высоконагруженных приложений HighLoad++ Siberia 2019. Ранее в статьях на Хабре мы упоминали, что мы в компании Plesk проводим ретроспективу конференций и докладов, которые посещаем, чтобы не потерять полученные знания и впоследствии применить их. Мы расскажем, какие доклады для себя отметили, а также поделимся с вами рецептом ретроспективы. Организаторы постепенно выкладывают видео сюда: youtube-канал. Часть из того, что мы описываем, уже можно посмотреть.

Обзор докладов

Отказоустойчивый кластер PostgreSQL + Patroni. Реальный опыт внедрения

Виктор Еремченко (Miro)

Автор приводит схемы, типовые подводные камни очевидных решений, рассказывает об альтернативных решениях и почему они не подошли. Это обзорный доклад об успешной миграции Redis → PostgreSQL → Pgbouncer + PostgreSQL → Patroni Consul + Pgbouncer + PostgreSQL. Из интересного:

  • Инженеры Miro собрали своё решение, чтобы не платить за Amazon RDS, и это решение пока их устраивает.
  • Ликбез по менеджерам соединений для PostgreSQL.
  • Рассказано про процесс обновления узлов кластера без остановки приложения.
  • Показан приём для быстрого обновления PostgreSQL.

Полезно посмотреть тем, кто использует или собирается использовать PostgreSQL, и у кого растёт количество данных.

Реализация геораспределённой персистентной очереди сообщений на примере Yandex Message Queue

Василий Богонатов (Яндекс)

Коротко: Kafka — простая очередь, сложный получатель; RabbitMQ — сложная очередь, простой получатель. В качестве вводной докладчик провёл краткое сравнение некоторых особенностей Kafka и RabbitMQ. Важное замечание: ни одна очередь не может обеспечить доставку сообщения ровно 1 раз без поддержки на отправителе и получателе. Также автор рассказал про виды гарантий доставки сообщения из очереди.

YandexMQ (YMQ) — совместимая по API с Amazon SQS очередь. Доклад посвящён YandexMQ. Василий показал, в чём преимущество YandexMQ, как достигают строгой консистентности и безотказности, и сделал обзор архитектуры YMQ. Основой YandexMQ является Yandex Database (YDB). Фишка YMQ: когда consumer просит сообщение, то в очереди оно скрывается, чтобы больше никто его не взял в обработку. YMQ реализует паттерн «Competing consumers» — одно сообщение одному потребителю. Докладчик утверждает, что у Apache Kafka есть проблема потери данных при внезапном уничтожении процесса, Yandex MessageQueue устойчив к этому.
Если при обработке возникли проблемы, то после VisibilityTimeout сообщение снова становится видимым в очереди.

Доклад рекомендован всем, кто хочет разобраться в принципиальных особенностях очередей.

Time series данные в реляционной СУБД. Расширения TimescaleDB и PipelineDB для PostgreSQL

Иван Муратов (Первая Мониторинговая Компания)

Доклад о том, как хранить и обрабатывать в PostgreSQL time series данные.

TimescaleDB позволяет хранить большие объёмы за счёт хитрого партицирования, а PipelineDB предоставляет работу со стримами прямо в PostgreSQL (а также интеграцию с очередями).

TimescaleDB:

  • Имеет очень устойчивую скорость записи при росте объема базы под большими нагрузками и при увеличении количества партиций, измеряемого тысячами.
  • Позволяет использовать стандартные возможности PostgreSQL, такие как SQL, репликация, резервное копирование, восстановление и др.
  • Заявлен неплохой набор интеграций, к примеру, с Prometheus, Telegraf, Grafana, Zabbix, Kubernetes.
  • Есть бесплатная версия с открытым кодом.

Основная мысль: TimescaleDB нужна в первую очередь для хранения данных.

PipelineDB:

  • Позволяет непрерывно обрабатывать поступающие данные c помощью SQL и складывать результат в таблицу.
  • Имеет SQL интерфейс.
  • Есть выполнение хранимых процедур по условиям.
  • Возможны интеграции с Apache Kafka и Amazon Kinesis.
  • Есть бесплатная версия с открытым кодом.
  • Разработка PipelineDB заморожена на версии 1.0, и сейчас выходят только багфиксы.

Основная мысль: PipelineDB нужна в первую очередь для обработки данных.

Для задач, где одновременно необходима реляционная СУБД, NoSQL и time series, данный вариант может быть довольно удобен.

Не очень большие данные

Павел Лузанов (Постгрес Профессиональный)

Секционирование через наследование, шардинг. Хороший обзорный доклад про PostgreSQL, наследование таблиц и Tips&Tricks производительности PostgreSQL 10, 11, 12+. Полезно посмотреть всем, кто использует PostgreSQL и хочет сделать его чуть быстрее.

Архитектура высокопроизводительной и высокодоступной системы мониторинга в Яндексе

Сергей Половко (Яндекс)

Довольно подробно рассказано об архитектуре. Об облачном продукте Yandex Monitoring, который пока в стадии «Preview» — бесплатный. В качестве GUI используется Grafana, при этом оповещения свои, не в Grafana.
Показан интересный приём — отделение метаданных от данных, которое даёт возможность независимого масштабирования и оптимизации.

Рутина администратора баз данных

Андрей Сальников (Data Egret)

Рассказывается о том, какие параметры серверов автоматически отслеживаются, как расставляются приоритеты задач.
В Data Egret используют обобщенный опыт в Wiki с рецептами, чек-листами — это является основой для будущих статей и докладов. Опыт коммерческого системного администрирования множества серверов PostgreSQL. Выпустили ряд утилит для работы с PostgreSQL, приводят ссылки на них.
Используют базу инцидентов с описанием проблем и решений — это существенно экономит ресурсы.

Инфраструктура поиска Яндекс.Маркета

Евгений Соколов (Яндекс.Маркет)

Из интересного: Доклад об архитектуре сложного, высокодоступного, распределённого приложения Яндекс.Маркет и о процессах и инструментах его разработки, тестирования, обновления, мониторинга.

  • «Стоп-кран» — своё решение для быстрого применения и отката конфигурации, помогает тестировать новый функционал.
  • Трафик перенаправляется из текущего датацентра балансировщиком в другой датацентр в случае проблем.
  • Для мониторинга используются Graphite и Grafana.
  • Имеется дублирующий базовый мониторинг на другом стеке технологий.
  • Используется Shadow-кластер для разработчиков, на который дублируется часть пользовательского трафика. Пользователи при этом не видят ответов Shadow-кластера.
  • Производится автоматический подсчёт качества при A/B тестировании.

ClickHouse и тысяча графиков

Антон Алексеев (2ГИС)

Основное интересное: Доклад о том, чем хорош ClickHouse, и как его готовить в связке с Grafana.

  • Если не хватает скорости, стоит использовать семплирование (утверждается, что точности данных после семплирования хватает). Семплирование в ClickHouse — частичная выборка данных с агрегированием с сохранением соотношения разнообразных значений в ключе таблицы, позволяет в разы ускорить агрегирование и при этом иметь результат, очень близкий к реальному.
  • ClickHouse можно использовать для быстрого исследования инцидентов (в докладе интересный пример).
  • Для ускорения выборки в ClickHouse также есть MaterializedView.
  • Описан HTTP интерфейс ClickHouse для выполнения запросов и загрузки данных.

Это отличный обзор того, как работают видеоконференции на группу участников. В заключение обзора докладов хочется отметить, что нам также очень понравился доклад «Видеозвонки: от миллионов в сутки до 100 участников в одной конференции» (Александр Тоболь / Одноклассники), который вошёл в число лучших докладов конференции по результатам голосования. Если вдруг придётся делать видеозвонки, можно посмотреть доклад, чтобы быстро вникнуть в предметную область. Доклад отличается понятным системным изложением.

Структура ретроспектив конференций в Plesk

А теперь, на десерт, о том, как же мы пишем ретроспективу внутри компании. В первую очередь, мы стараемся написать ретро в первую неделю после посещения конференции, пока ещё свежи воспоминания. Кстати, материал ретроспективы может служить потом основой для статьи, как можно догадаться;)

Готовый список помогает сократить время на поиск интересных докладов для просмотра. Цель написания ретроспективы — это не только закрепить знания, но также и поделиться ими с теми, кто не был на конференции, но хочет быть в курсе последних трендов, интересных решений. Выписанные уроки помогают сфокусироваться и не потерять, что мы хотели сделать. Мы выписываем уроки, которые для себя вынесли, отмечаем конкретных людей с пометкой, почему нужно посмотреть доклад и подумать над идеями и решениями других. Посмотрев на записи через 3-6 месяцев мы поймём, не забыли ли мы о чём-то важном.

Документацию в компании мы храним в Confluence, для конференций у нас есть отдельное дерево страниц, кусочек дерева:

Как видно со скриншота, материалы мы раскладываем по годам для удобства навигации.

Кстати, страницу для ретро мы генерим из шаблона, в котором вся структура уже есть. Внутри страницы, посвящённой конкретной конференции, мы храним следующие секции: общий обзор (overview) с ссылками на сайт события, расписание, видео и презентации, список участников (лично и на трансляции), общее впечатление (overall impression) и детальный обзор (detailed overview). Также мы составляем содержание из заголовков, чтобы можно было очень быстро просмотреть список докладов и перейти к нужному.

Если участники были на конференции в прошлые годы, они могут сравнить их уровни и в целом понять для себя полезность посещения мероприятия. В разделе Overall impression дается краткая оценка конференции, приводятся впечатления участников.

Раздел Detailed overview содержит таблицу:

Пример заполнения таблицы:

Нам было бы интересно узнать о том, какие доклады понравились вам на Highload Siberia 2019, а также о вашем опыте проведения ретроспектив.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть