Разработчик бэкенда в Yandex Monitoring
Привет! Меня зовут Стас, я руковожу командой Observability Metrics. Мы строим платформу Observability, которая обрабатывает миллиарды семплов в секунду, хранит петабайты данных и должна работать даже тогда, когда всё вокруг горит. Если вы любите копать глубоко, не боитесь сложных технических вызовов и считаете, что высоконагруженная Java — это не оксюморон, то нам есть о чём поговорить.
С приходом микросервисов архитектура даже простых систем стала гораздо более распределённой. Чтобы понимать, что происходит с сервисом в конкретный момент, нужны подходящие инструменты: метрики, трейсы, логи, алерты, дашборды и т. д.
Платформа Monium помогает нашим пользователям легко и быстро получать однозначный ответ о состоянии своих систем в любой момент.
Yandex Monitoring — часть платформы, отвечающая за количественный мониторинг инфраструктуры и приложений. Мы каждую секунду обрабатываем 2,5 миллиарда семплов на запись и 2 миллиарда на чтение, каждую минуту рассчитываем 18 миллионов алертов, храним 8 петабайт исторических данных.
Такие объёмы требуют решения сложных задач масштабирования и отказоустойчивости:
- Как построить надёжный пайплайн сбора и обработки метрик, позволяющий опрашивать миллионы эндпойнтов?
- Как хранить миллиарды уникальных временных рядов, чтобы их можно было мгновенно найти?
- Как равномерно распределять stateful-нагрузку между тысячами серверов и эффективно утилизировать ресурсы в мультитенантной системе?
Мониторинг активно развивается — его используют почти все команды Яндекса, а также внешние пользователи сервисов Yandex Cloud. Помимо этого, мы разрабатываем слой совместимости с Prometheus, что позволяет клиентам Yandex Cloud пользоваться привычными инструментами и не думать о масштабировании собственных средств мониторинга.
Стек:
- Бо́льшая часть компонентов на Java (мы стараемся использовать самые свежие версии)
- Небольшая часть на C++
- Данные и метаданные хранятся в YDB
Динамическая агрегация метрик
Агрегаты на записи существенно ускоряют вычисления для запросов с большой кардинальностью (например, когда нужно посчитать RPS не для одного сервера, а для кластера из тысяч машин). Однако пользователи не всегда знают заранее, по каким измерениям им потребуются агрегаты, а создавать их для всех возможных комбинаций невозможно.
В чём вызов? Такие агрегаты можно рассматривать как своего рода индексы в классических базах данных — ускоряя сценарии чтения, мы неизбежно замедляем запись. Нам нужно разработать интеллектуальный метод, который на основе статистики будет понимать, когда агрегаты действительно нужны и стоит создать новые правила агрегирования, а когда агрегат больше не используется и можно освободить ресурсы.
Антиэнтропийные механизмы для распределённого хранилища
Для надёжности мы храним данные в нескольких репликах, но значения между ними могут расходиться. Нам нужно разработать механизм, который будет обнаруживать и устранять такие расхождения, не замедляя основной процесс записи.
В чём вызов? Механизмы синхронизации данных могут нарушать порядок записей, что критично для алгоритмов сжатия временны́х рядов (например, Gorilla encoding). Нужно создать решение, которое будет работать быстро и при этом сохранять эффективность сжатия данных.
Auto Split/Merge для шардирования индекса
Обратный индекс даже для метрик одного сервиса может быть настолько велик, что не уместится в памяти одной машины. Мы разрабатываем систему, которая станет динамически разделять и объединять части индекса в зависимости от нагрузки и паттернов доступа.
В чём вызов? Разработать стабильный алгоритм, который будет не слишком часто перераспределять данные, создавая лишнюю нагрузку на сеть и процессор, но при этом эффективно реагировать на изменения в характере данных, особенно с учётом высокого churn rate в Kubernetes-окружениях.
Развитие движка вычисления запросов
В нашем движке запросов большое пространство для оптимизаций: от переноса расчёта агрегатных функций ближе к данным до реализации стриминговой обработки и параллелизации вычислений.
В чём вызов? Для эффективной параллелизации требуется не только пересмотреть архитектуру движка, но и изменить подход к тому, как данные хранятся и распределяются.
Поддержка опенсорс-форматов и протоколов
Мы развиваем совместимость с ключевыми стандартами отрасли: PromQL для запросов, OpenTelemetry для сбора данных, Prometheus Remote Write для интеграций. Это позволяет пользователям легко мигрировать на нашу платформу.
В чём вызов? Опенсорс-форматы часто проектируются для общего случая, без учёта экстремальных нагрузок. Нам предстоит создать высокооптимизированные реализации этих протоколов, не меняя их внешнюю спецификацию, чтобы справляться с объёмами данных на порядки больше типичных.
- Разрабатывали высоконагруженные отказоустойчивые распределённые системы
- Понимаете принципы многопоточного программирования, знакомы с основными подходами, проблемами и ограничениями в этой области
- Знаете классические алгоритмы и структуры данных, умеете выбирать оптимальные для конкретных задач
- Оптимизировали производительность: умеете профилировать код, находить узкие места, оптимизировать работу с памятью и CPU
- Готовы копать глубоко: читать исходники JVM, патчить сторонние библиотеки, расследовать сложные инциденты
- Глубоко знаете Java: понимаете устройство JVM, GC, JIT, модель памяти, знакомы с JMH, JFR, async-profiler
- Участвовали в разработке систем хранения и обработки данных
- Интересовались устройством Prometheus, Apache Cassandra, Apache Druid
- Знакомы с принципами Mechanical Sympathy и Data-Oriented Design
- Работали с системами мониторинга (Prometheus, Grafana, Datadog и др.)
- Умеете читать код на Go и C++
Смотрите другие вакансии направления Yandex Cloud Monium по ссылке.
Подписывайтесь на телеграм-канал Inside Yandex Cloud , чтобы узнать больше про нашу команду и технологии!
