4 июня состоялась infra.conf 2024 — конференция про создание инфраструктуры и эксплуатацию высоконагруженных систем от команды Yandex Infrastructure. На мероприятии мы попросили поделиться своими инфраструктурными историями инженеров не только Яндекса, но и Ozon.Tech, T1, MTS Web Services, Т‑Банка, SberDevices, Альфа‑банка, «Лаборатории Касперского», Selectel, Postgres Pro, СберМаркета и Авито. В результате, по отзывам участников, «хардкор‑концентрат железа и DevOps зашкаливал и летал прямо в воздухе».
В этой статье мы собрали самые интересные моменты по тем докладам, которые вызвали наибольшую реакцию и восторг от полезности в кулуарах и чатах, — чтобы вам было проще сориентироваться, что стоит пересмотреть.
YDB Topics: история взаимоотношений с Kafka
Мы уже писали на Хабре об истории становления шины данных YDB Topics, например, здесь. В своём докладе руководитель группы разработки YDB Александр Зевайкин напомнил о задачах платформ для обработки очередей и рассказал о вызовах, которые возникают, когда объёмы данных достигают 20 миллионов EPS.
Что делать, если существующие опенсорс‑платформы для работы с потоковыми сообщениями существенно ограничивают возможности, например, при работе с кластерами и георезервированием? На infra.conf об этом можно было поговорить в диалоговом формате и задать свои даже провокационные вопросы.
Случайный кадр доклада:
Самый провокационный вопрос к докладу (по версии ведущего):
Команда YDB нам говорит, что «большой» Яндекс давно использует YDB для своих высоконагруженных задач. Но как мы понимаем, Yandex Infrastructure — это не Yandex Cloud, есть разница. Можно ли сказать в чём?
Очень обширный вопрос, давайте отвечу в рамках темы доклада: отличается ли YDB в облаке и во внутренней инфраструктуре. YDB работает на единой кодовой базе, независимо от того, это опенсорс, внутренняя инсталляция, внешняя инсталляция. Внутри Яндекса есть маленький кусочек, связанный с внутренней системой авторизации и внутриоблачными особенностями, например, это мультитенантность. Это единственные небольшие отличия, которые есть.
Как удобно жить на железе в 2К24 базовой инфраструктуре
Управление железным сетевым парком становится очень интересной задачей, когда речь идёт о серьёзных масштабах:
сотни железных серверов,
200 гигабит на хост.
Борис Литвиненко из группы разработки сетевой инфраструктуры и мониторинга Yandex Infrastructure рассказал о том, как команда подошла к задаче оркестрации сетевыми сервисами и автоматизированного управления ресурсами. Чтобы управление было проще, сервисы перевели в облачную инфраструктуру через контейнеры Kubernetes. А для этого была разработана система автоматизации сети и сетевых компонентов YANET, которая позволила унифицировать сервисы с остальной инфраструктурой Яндекса — и о которой мы обязательно расскажем в отдельной статье.
Случайный кадр доклада:
Самый залайканный вопрос к докладу из чата:
Вы как специалист с опытом работы с kubeadm можете ответить: «Если у меня получится настроить кластер с помощью kube‑adm с первого раза, это магия или просто везение?»
На самом деле, это не магия, и сейчас всё идёт к упрощению. Наверное, сложнее понимать нюансы, и как это работает внутри. Я бы сказал, что проблема Kubernetes сейчас — это то, что информации очень много, много однотипных решений, и нужно выбрать что‑то своё.
Собственная реализация S3 поверх Сeph-Lusca — как мы научились предсказуемо работать с индексом и экономить место при тех же гарантиях
С ростом нагрузок на S3 инженерная команда может столкнуться со сложностями при использовании опенсорс‑решений: например, проблемами с масштабируемостью хранилища и распределением нагрузки.
Виктор Корейша, руководитель направления Managed Services в Ozon Tech, в деталях показал, как возникают эти проблемы на масштабе компании. Несколько цифр и деталей использования S3:
около 1000 сервисов Ozon Tech;
20 000 бакетов;
5 000 000 000 объектов;
60 петабайт данных;
сотни тысяч RPS.
На конференции Виктор показал, как его команде удалось обнаружить «узкие места», возникшие при эксплуатации объектного хранилища, выбрать наиболее подходящее решение и реализовать его с учётом всех внутренних требований.
Случайный кадр доклада:
Самый залайканный вопрос к докладу из чата:
Представь, что мы все живем в большом распределенном хранилище данных, где каждый человек — это объект с различными атрибутами. Как думаете, кто бы занял место BlueStore, и как мы бы управляли объектами типа 'человек' в такой системе? Будет ли RadosGW выступать в роли доброжелательного портира, пытающегося упорядочить поток данных, или мы все окажемся в непрерывном цикле компактирования RocksDB, пытаясь освободить место для новых 'объектов'?
DNS over YTsaurus: как устроено хранилище DNS-данных всего Яндекса
Объём DNS‑данных всего Яндекса не превышает 10 ГБ — но это очень важные десять гигабайт. От них зависит работоспособность почти всех сервисов Яндекса. Именно с этого начал свой доклад Сергей Фомин, руководитель группы YP и Discovery в Yandex Infrastructure.
Рассказ Сергея про DNS Storage подробно останавливается на том, как создать отказоустойчивое, высоконагруженное и консистентное хранилище.
Случайный кадр доклада:
Самый неожиданный вопрос‑ответ к докладу из чата:
Если бы DNS‑записи были детьми, как часто, вы думаете, они спрашивали бы «Почему?» перед тем, как обновиться?
…главное много запросов в авторитетных родителей не проливать.
Собственная автотестовая система Hive
В «Лаборатории Касперского» для тестирования продуктов ежедневно запускается более миллиона задач на сотнях разных платформ. Сначала требования компании к автотестовой инфраструктуре выглядели вполне стандартными, и для её создания были выбраны готовые решения. Но со временем потребности стали расти.
Александр Крымов, старший разработчик инфраструктуры Hive в «Лаборатории Касперского», рассказал, как и почему было решено создать собственную автотестовую систему, и какие нестандартные сценарии это помогло решить.
Случайный кадр доклада:
DevEnv как сервис
Когда мы формируем единое повторяемое окружение для разработчиков, то чаще всего говорим о том, что у нас есть Testing, Staging, Pre‑stable и Production, которые управляются через IaC‑решения. Но при этом про девелоперские окружения нередко забывают, а таких намного больше, чем стейджинговых окружений. Сложности с их настройкой могут приводить к потерям unstaged changes и другим проблемам.
Виталий Дмитриев, технический менеджер проектов в Yandex Infrastructure, показал, как эти размышления привели к созданию управляемого сервиса Codenv, за который отвечает отдельная команда.
Случайный кадр доклада:
Самый настойчивый вопрос к докладу из чата (и ответ на него):
У разработчиков есть какие‑то квоты/лимиты по использованию окружений? Может ли кто‑то злоупотреблять и создать больше окружений, чем нужно? Предусмотрено какое‑то согласование?
Скорее, здесь всё так же, как у любого сервиса: есть мониторинг, есть информация о том, кто сколько потребляет. Всё это прослеживается в реальном времени, и при необходимости мы можем отреагировать на какие‑то аномалии.
Улучшаем качество нагрузочного тестирования, подкручивая инфраструктуру
Михаил Жилин, руководитель группы производительности департамента внедрения и технической поддержки в Postgres Pro, на infra.conf поделился своим богатым опытом нагрузочного тестирования. До прихода в компанию он также занимался вопросами производительности, но последние 3 года в Postgres Pro принесли новые возможности: полный доступ к bare metal при управлении нагрузкой на базу данных.
В докладе Михаил рассказал о том, как команда обжигалась на особенностях Linux, подкручивала power saving процессора, писала свой демон привязки ядер и многое другое.
Случайный кадр доклада:
Современный мир Cloud Native и подходы к его аварийному восстановлению
Дмитрий Рыбалка, TechLead отдела базовой ИТ‑инфраструктуры в СберМаркете, делится статистикой: за последние полгода у большинства облачных операторов были зафиксированы аварии. Такая суровая реальность неизбежно приводит инженерные команды к созданию DR‑планов. Но такие планы будут немного отличаться для решений Cloud Native.
В своём докладе Дмитрий постепенно переходит от концепции Disaster Recovery к концепции Disaster Avoidance, показывает множество стратегий восстановления и объясняет, как здесь может помочь подход Cloud Agnostic.
Случайный кадр доклада:
Трюки in-memory баз данных в традиционных СУБД
«Засунуть отвёртку» в базу данных, которая оказалась рядом, может быть полезно для лучшего понимания разных способов оптимизации производительности. Андрей Бородин, руководитель подразделения разработки РСУБД с открытым исходным кодом в Yandex Cloud, делится опытом своих многолетних наблюдений и анализа работы баз данных и показывает сразу несколько трюков:
Pointer swizzling. Поиск по первичному ключу проходит длинный путь бинпоиском по страницам B‑деревьев, распаковывая IndexTuple, TID, перекладывая страницы в разделяемые буферы, и, наконец, данных HEAP. На этой не самой прямой дороже есть пара мест, где можно срезать.
Более подходящие для кэширования структуры страниц. Бинарный поиск может затрагивать меньше строк кэша, а сама страница может иметь колоночную структуру (Partition Attributes Across layout).
Более оптимистичный подход к блокировке shared buffers: чтение без блокировки, сброс результата в случае каких‑либо изменений.
Случайный кадр доклада:
Static-Fallback
Павел Лакосников, руководитель юнита ArchGovernance в Авито, фокусно занимается задачами надёжности более 4 лет и за это время успел увидеть немало аварий и несколько релизов, которые были «сожжены деплоем». Всё это привело его команду к созданию fallback‑системы, которая позволяет прикрыть Авито «закешированным всем».
В докладе Павел делится дизайном такой системы, подходами к масштабированию и к обеспечению качества кеширования.
Случайный кадр доклада:
Провокационный вопрос к докладу из чата (и ответ на него):
Наказывают ли за аварии? Ведь виновных зачастую не найти.
Самое страшное наказание за падение — это разбор инцидента. Нужно проработать карту рисков для компонентов, которые упали, и это на самом деле самое эффективное решение в этой ситуации.
Это лишь малая часть всего, что произошло на infra.conf. Смотрите полную запись трансляции на нашем канале, делитесь впечатлениями, если были на площадке офлайн, и приходите на следующие мероприятия.