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. Смотрите полную запись трансляции на нашем канале, делитесь впечатлениями, если были на площадке офлайн, и приходите на следующие мероприятия.
ссылка на оригинал статьи https://habr.com/ru/articles/821859/
Добавить комментарий