Что посмотреть из докладов на Highload Channel за 2018 год

on conferences

Продолжаю серию обзоров конференций. Этим летом на YouTube выложили все доклады за прошлый 2018 год с Highload++ и смежных с ним конференций (Backend Conf, РИТ etc). В этом посте вы найдете топ самых интересных докладов с краткими заметками. В основном сюда вошли доклады посвящены матчасти, т.е. как работает та или иная технология, и обзорные доклалы.

Последние изменения в IO-стеке Linux с точки зрения DBA

https://www.youtube.com/watch?v=0o7uNUOS-Ho

Уровень: hardcore

Докладчик: Илья Космодемьянский (много и часто выступает на Highload++ по PostgreSQL)

Парень рассказывает об IO-подсистеме Linux в целом и о недавних изменениях.

Скорость IO-подсистемы очень важна для баз данных, а особенно скорость записи на диск (сохранение системных буферов памяти). И если нагрузка на базу настолько большая, что все упирается в производительность IO-подсистемы, то приходиться настраивать уже сам Linux.

Изменения в IO-подсистеме связаны с все большим и большим использованием SSD дисков. Текущая реализация IO Scheduler’а очень консервативна и была заточена под HDD с его головками и цилиндрами. Сейчас пришло время адаптироваться и под SSD.

IO Scheduler занимается переупорядочиванием и оптимизацией операций чтения/записи с диском. Это имеет смысл для HDD, когда надо учитывать задержки для поворота и перемещения дисков/головок. Но это не нужно для SSD, который работает по совсем другим принципам и в нем уже реализованы сложные оптимизации.

IO Scheduler’ы в Linux развивались следующим образом:

  • Linus Elevator (изначальное решение)
  • CFQ, deadline, noop/none (Linux 2.6)
  • blk-mq (Linux 3.13)
  • kyber, BFQ (4.12)

Ссылки из доклада:

Ссылки по теме:

MariaDB и MySQL — какую статистику использует оптимизатор

https://www.youtube.com/watch?v=KHvoLyLdTJ0

Уровень: hardcore

Докладчик: Сергей Голубчик, Chief Architect MariaDB

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

Речь идет об оптимизаторе плана выполнения SQL-запросов. Он выбирает порядок join-а таблиц, алгоритмы для прохода по таблице и принимать решение об использовании индексов. Для этого оптимизатору нужно знать какие данные хранятся в таблицах и чем больше информации известно тем лучше будет итоговый план SQL запроса. Статистика по данным автоматически собирается базой данных и регулярно обновляется.

Оптимизатор может опираться на следующие данные:

  • Таблица - кол-во строчек
  • Индекс - кол-во разных значений колонки
  • Столбец:
    • Минимум и максимум
    • Кол-во NULL’ов
    • Средняя длина
    • Кол-во разных значений
    • Распределение значений (гистограмма)
      • Равной высоты
      • Равной ширины
      • Для дискретных значений

QUIC illustrated

https://www.youtube.com/watch?v=E8sEITa5Qtk

Уровень: hardcore

Это технический доклад о том как протокол QUIC работает, как его изучать и отлаживать. QUIC это сетевой протокол не-понятно-какого уровня на базе UDP, который должен заменить TCP. По сути это агрегация HTTP + TLS + TCP протоколов, которая разрабатывалась для HTTP/2, чтобы улучшить производительность и уменьшить задержки.

Решает проблемы:

  • Head-of-line blocking
  • 0-RTT handshake

Hol blocking правда уже был решен протоколом SCTP, но в QUIC решают больше проблем и применяют больше техник оптимизации.

Ссылки из доклада:

Ссылки на тему:

Трафик-инфраструктура Dropbox

https://www.youtube.com/watch?v=TSWBOJ19ofA

Уровень: medium

Доклад покроет весь путь запроса от пользователя к серверам приложений Dropbox. Внешняя DNS/BGP-балансировка с использованием RUM, устройство точек присутствия по миру: ipvs/nginx/lua. Трафик внутри дата-центра: самописный reverse-proxy на Go, изоляция, метрики и трейсинг.

Парень рассказывает, как отдавать файлики пользователей по всему миру с минимальными задержками. Это не самая простая задача учитывая масштабы Dropbox’а с эксабайтами (10^18) данных пользователей и петабайтами (10^15) метаданных. Эту магию называют Global server load balancing (GSLB).

Используются следующий подход - разбросать по земного шарику точки присутствия и направлять пользователя к ближайшей/оптимальной для него точке. Точка присутствия подключена к backbone (собственные кабели Dropbox) в которых надежная связь, высокая скорость и нет потерь пакетов.

Дальше надо решать уже другую проблему - как направить пользователя к оптимальной точке присутствия. Рассматривают следующие варианты:

  • BGP Anycast
  • Geo-dns
  • Hybrid geo-dns & any cast
  • HTTP & DNS Colocation
  • Real user monitoring (RUM)

DNS в Facebook

https://www.youtube.com/watch?v=l4HR5eFtWQM

  • Как мы балансируем нагрузку, и причём тут DNS-инфраструктура в Facebook.
  • Как ресурсные записи попадают в глобальную инфраструктуру Facebook.
  • Как Facebook использует DNS в организации dogfooding.

Парень рассказывает о том же, что парень из Dropbox - об уменьшении задержки (latency).

Решение проблемы точно такое же - добавление точек присутствия (point of presence). И возникает та же самая задача - выбор правильной точки присутствия для конкретного пользователя. Она решается таким же способом - строят сетевую карту задержек запросов пользователей. Это позволяет не только выбирать самую оптимальную точку но и оперативно обновлять эту информацию (раз в минуту). Но этот подход работает, только если клиенты ходят за DNS к серверам Facebook напрямую, иначе Facebook отдаст IP адрес точки присутствия оптимальной не для клиента, а для DNS resolver’а-посредника.

Из интересного - DNS карта раздается серверам через BitTorrent протокол.

Типовые ошибки в приложениях, которые ведут к bloat в PostgreSQL

https://www.youtube.com/watch?v=-GNHIHEHDmQ

Уровень: medium

Специфичный для PostgreSQL технический доклад. Докладчик рассматривает три ситуации с базой данных, когда таблицы разпухают и база начинает сильно тормозить (bloat). Он разбирает что, как и почему ломается и дает рекомендации как это лечить и избегать.

Рассматриваются такие ситуации:

  • с одним сервером
  • с парой мастер-реплика
  • с миграцией данных

Инструменты:

  • Для выявления bloat - расширение pgstattuple
  • Лечение bloat:
    • VACUUM FULL
    • pg_repack
    • pgcompacttable

Ссылки:

Платформа 4К-стриминга на миллион онлайнов

https://www.youtube.com/watch?v=pqz_qld6jVA

Уровень: medium

Докладчик: Александр Тоболь (Одноклассники)

Любопытный доклад о live трансляциях. Здесь мало технических деталей и доклад интересно слушать в первую очередь из-за его обзорности, опытного докладчика и новизны темы. Сам доклад немного скомкан, докладчик говорит быстро и не все заходило с первого раза. Вероятно из-за специфики темы.

Речь идет о стриминге видео начиная с маленьких трансляций на несколько человек и до футбольных матчей или хоккея с миллионами зрителей online. Ребята решали задачу как отдавать 4K видео на 3 Тбт/с с низкими задержками. Они оптимизировали перекодировку входящих потоков в разные разрешения/кодеки для выходящих, чтобы это работало на CPU и не требовало дорогих GPU, и выбирали контейнеры для отдачи видео клиентам/плеерам.

Рассказывают еще об инфраструктуре, кластерах серверов (4 датацентра и 100 серверов на раздаче), балансировке при повышении нагрузок и о пайплайнах. В конце говорят немного о настройке TCP, о том, что будущее за QUIC, и о трендах в кодеках и сетевых протоколах.

Из интересного - рассказали как работает эстиматор в видео-плеерах. Он динамически выбирает разрешение из списка доступных (которые предоставляет сервис трансляции) отталкиваясь от пропускной способности сети клиента.

Ссылки:

FAQ по архитектуре и работе ВКонтакте

https://www.youtube.com/watch?v=_GqcriadL-s

Уровень: easy

Прикольный рассказ о реализации ВК с высоты птичьего полета - архитектура, базы данных, логи/мониторинг и деплои.

Ссылки:

«Платформа» в Badoo: как мы построили инфраструктурную разработку

https://www.youtube.com/watch?v=3xdnq9SfaGo

Уровень: easy

Докладчик: директор платформенной разработки в Badoo

Любопытный рассказ о том, как в большой компании выделили отдельную команду, которая не клепает фичи, а занимается инфраструктурой и платформой в целом - помогает продуктовым командам и занимается глобальными проблемами проекта.

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

Основные направления команды:

  • продуктовые бекэнды
  • инфраструктурные сервисы
  • и инструменты для разработки.

Примеры задач такой команды - шардирования баз данных, логи/метрики/визуализация, хардкорные бэкэнды на C/C++/Go.

Особенности микросервисов на примере e-Com-платформы

https://www.youtube.com/watch?v=hRcTvC6bznA

Уровень: easy

Доклад о том, как в крупном интернет-магазине переходили с монолита на микросервисы. На самом деле это короткий и поверхностный доклад. Он интересен тем, что это практический пример, а не голая обобщенная теория, и можно перенять некоторые идеи. Например, парень говорит, что в их ситуации для борьбы со сложностью связей между сервисами пришлось выделить явные слои/типы сервисов:

  • api layer - по сути это api gateway
  • business layer - реализуют логику и не имеют состояния (т.е. не работают с базой напрямую)
  • data layer - обычно обертка над базой или storage (Redis, …)

Интересен их подход к ответственностьи за разработку и тестирование новых фич, которые затрагивают несколько микро-сервисов (за которые отвечают другие команды). Реализует и тестирует код в чужом микро-сервисе команда-хозяин фичи, а не команда-хозяин этого микросервиса.

Что мы знаем про хэши

https://www.youtube.com/watch?v=zr4ZDtfp0N0

Уровень: easy

Докладчик: Андрей Аксенов, разработчик системы полнотекстового поиска Sphinx

Тема доклада - хеш-таблицы, теория и практика, в рамках многотомника Кнута. Общая матчасть с примерами и картинками и немного из личного опыта автора.

Докладчик, Андрей Аксенов, известен и другими своими докладами на Highload++, доставляет своей манерой излагать, харизмой и опытом. Умеет доходчиво рассказать, пошутить и немного матернуться.

Как стать классным спецом по базам данных?

https://www.youtube.com/watch?v=SpLVs6lfXps

Уровень: easy

Докладчик: Илья Космодемьянский

Парень рассказывает, что нужно знать DBA и как этого достичь. Это часто очевидные вещи, но тем не менее правильные. Мне нравится этот докладчик - интересно рассказывает, хорошая структура докладов. Несмотря на начальный уровень доклада - будет однозначно полезным.

Детальнее:

  • для DBA практический опыт важнее чем теория
  • нужен широкий кругозор и погружение в смежные области знаний
  • книги по базам быстро устаревают (кроме фундаментальных), поэтому надо смотреть больше в документацию
  • хорошее начало с PostgreSQL - чтение доки по конфигурированию https://www.postgresql.org/docs/current/runtime-config.html

Ссылки:

Доступные видео на YouTube