Доклады секции "Platform Engineering"

Современная платформа — это не только долгосрочный проект, это еще и дорогая инфраструктура. Платформа Туту обходится компании в 5 раз дешевле, чем аналогичная инфраструктура в облаках.

В докладе я расскажу:
* Про нашу систему внутреннего биллинга и ресурсные дашборды для продуктовых команд;
* Про механизмы Garbage Collector в инфраструктуре и другие инструменты для оптимального использования ресурсов;
* Рассмотрим модель затрат на IT-Платформу;
* Как мы нашли общий язык с бизнесом и считаем эффективность IТ-платформы.

Почему и как мы пишем на Rust новые утилиты массовой асинхронно-неблокирующей работы с AWS-совместимыми облаками для Яндекс Облака и VK Cloud. Расскажем, как мы реплицируем события бакета s3 и как мы удалили несколько петабайт и миллиарды файлов на Rust, активно используя асинхронные сокеты и аллокатор jemalloc. Поделимся опытом, как правильно и быстро писать полезные утилиты, работающие с AWS-совместимым API и как быстро прокачать стеку асинхронного Rust разработчиков других стеков: Python, Java, PHP, JavaScript.

Cluster API — это мощный инструмент для декларативного управления жизненным циклом Kubernetes-кластеров. Он активно развивается и поддерживает множество провайдеров для различных платформ: GCP, AWS, Azure, vSphere, bare metal и др. Однако на момент начала нашего проекта не существовало открытого провайдера для Yandex Cloud — что делало невозможным его использование в гибридных инфраструктурах.

Этот доклад будет полезен DevOps-инженерам, SRE и платформенным командам, которые стремятся упростить и унифицировать управление кластерами с помощью Cluster API, в том числе в Yandex Cloud, а также тем, кто интересуется разработкой собственных провайдеров.

Я расскажу, как мы в Т‑Банке решили эту проблему, разработав собственный Cluster API-провайдер для Yandex Cloud с нуля. Разберем архитектуру, взаимодействие с Yandex Cloud API, управление ресурсами (инстансами, балансировщиками). Особое внимание уделю нюансам разработки инфраструктурных провайдеров: спецификации CRD и reconciliation loop. Провайдер уже доступен в open source, и я покажу, как его можно начать использовать.

Вы услышите реальную историю от идеи до производственной эксплуатации — с вызовами, техническими решениями и опытом, который мы готовы передать сообществу.

Осознанное потребление ресурсов — это то, к чему мы стремимся в Яндекс Вертикалях. У нас тысячи сервисов и сотни хранилищ данных, поэтому контроль потребления ресурсов был нетривиальной задачей, но на помощь пришла наша IDP!

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

Задумываетесь над внедрением системы единого входа (SSO)? Расскажу на примере реального опыта, поделюсь инсайдами, как мы это сделали.

Почему стоит прийти:
* для архитекторов и DevOps-инженеров: вы получите готовые примеры интеграции Keycloak с ключевыми компонентами ML-инфраструктуры — никаких абстрактных теорий, только проверенные решения;
* для тех, кто работает с мультитенантными системами: узнаете, как разграничить доступ между разными организациями и командами внутри одной платформы без компромиссов по безопасности;
* для руководителей IT-проектов: поймете, как централизовать управление доступом и сократить издержки на администрирование множества разрозненных систем.

Ключевые аспекты доклада:
* тонкости настройки OpenID Connect для Airflow, MLFlow и Superset — нюансы, которых нет в документации;
* простые решения для сервисов без нативной поддержки OAuth;
* практические кейсы организации изолированных пространств в Grafana через Keycloak;
* разделение авторизации для пользователей и для межсервисного взаимодействия.

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

Приходите за практическими инсайтами, которые сэкономят вам недели разработки и тестирования!

В этом докладе я расскажу, как мы построили единую платформу аутентификации для группы компаний.

Рассмотрим:
* почему мы разделили авторизацию и аутентификацию;
* почему Keycloak;
* как мы деплоим Keycloak, чтобы не бояться даунтаймов;
* управляем Keycloak, через IaC с помощью Pulumi (и почему именно Pulumi);
* разработали типовые архитектурные принципы работы с Keycloak;
* стандартизировали заявки на создание сущностей Keycloak;
* авторизуем пользователей из мульти-AD-инфрастурктуры с кучей дублей учетных записей между AD.

Каждая ДЗО имеет свой стек технологий и уровень зрелости IT-ландшафта. Но при этом необходимость взаимодействия друг с другом никуда не делась. Как взаимодействовать, если с одной стороны REST, а с другой Kafka? Или RabbitMQ и Kafka? Под каждый поток данных писать адаптер?

Расскажу, как мы в команде MWS Octapi решили эту проблему с помощью Event Mesh. Теперь пользователю достаточно сформировать манифест взаимодействия, описать поток данных при помощи Json Schema и все. Система поднимет валидатор, коннектор, контроллер… Упорядочит потоки, сформирует артефакты гарантированной доставки и запустит поток.

Часто шутят, что Istio — это всего лишь 500 мегабайт на сайдкар. Но это обидная неправда — на самом деле сайдкары бывают и по гигабайту.

В докладе будет исчерпывающий гайд про потребление памяти в Istio в больших и сверхбольших промышленных инсталляциях на реальных примерах. А также все способы это потребление сократить — от простых и понятных до самых экзотических.

SaluteEye — платформа продуктовой аналитики. Собираем события с умных устройств Сбера и других источников, обрабатываем и предоставляем для аналитики и мониторинга технических показателей продуктов. Сегодня мы собираем и обрабатываем более 5 млрд событий в день и храним в быстром доступе аналитиков более 200 Тб, но так было не всегда...

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

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

В докладе я расскажу:
* что такое онлайн-биллинг? >80 млн абонентов, 1 млрд транзакций в секунду;
* разбираем легаси-продукт, который никто не описывал 30 лет: 3,5 млн строк превращаются в 1700 тарифов и 11 унифицированных классов услуг;
* в чем сложность замены онлайн-биллинга? 80% проектов свопов неуспешны. Расскажу про классические ошибки;
* итак, мы создали онлайн-биллинг. Как мигрировать? Виды миграции и выбор подхода;
* ключевые проблемы, с которым мы столкнулись в процессе миграции: боттлнеки в 20 тыс. абонентов, сигнальные штормы и «дергания» миллионов абонентов.