VK 28 сентября рассказала о внедрении в production-кластере сервиса подбора рекламы канареечной доставки снапшотов данных. Новая схема сначала применяет снапшот на ограниченной группе экземпляров под реальной нагрузкой, проверяет технические и продуктовые метрики и лишь затем допускает обновление к основной группе.
Снапшот в этой архитектуре — подготовленный слепок данных, который сервис загружает в память для обработки запросов. Отдельный компонент Seeder формирует согласованный набор из базы, упаковывает его и передаёт в контур доставки. VK разделяет такие данные на глобальный снапшот с базовыми данными сервиса и снапшот рекламных кампаний. Обновления могут менять результат подбора рекламы даже без выпуска новой версии приложения.
Ранее сборка снапшота занимала 30–40 минут, после чего файл попадал в S3, а метаданные — в индекс снапшотов. Существующий оркестратор находил новую версию, организовывал скачивание, в том числе с P2P-обменом между экземплярами, и подавал команду применить данные. Однако успешная транспортировка файла сама по себе не показывала, сохранилось ли ожидаемое поведение рекламного сервиса.
Чтобы не перестраивать критический тракт доставки, команда использовала маршрутизацию по type_id. Базовый тип получает канареечная группа, а тип с суффиксом _verified предназначен для основной эксплуатации. После успешной проверки оператор публикует новую индексную запись с прежними метаданными и ссылкой на тот же файл. Поэтому большой снапшот не требуется копировать или собирать повторно.
Проверка состоит из двух последовательных этапов. Сначала в течение пяти минут, с измерением раз в минуту, система убеждается, что версия дошла до основной части канареечных экземпляров и они сохранили состояние ready. Затем 20 минут анализируется влияние обновления: ошибки, задержки, отсутствие выдачи, объём подобранной рекламы и CPM на ключевых площадках сравниваются с нормализованными показателями контрольной группы.
Процессом управляет оператор на основе Kubernetes CRD, а не периодический скрипт. В ресурсе сохраняются конфигурация, текущая фаза и результаты измерений, поэтому после перезапуска контроллер может продолжить работу. Предусмотрены предварительная проверка конфигурации, пауза, повторные попытки при временных сбоях и ручной force-verified для уполномоченного инженера, позволяющий обойти автоматику в аварийной ситуации.
Практический контекст: Практическое значение подхода — перенос контроля качества данных непосредственно в процедуру развёртывания. Это особенно применимо к ML-моделям, поисковым индексам, рекомендательным признакам и конфигурациям, способным менять продуктовый результат без изменения кода. Однако надёжность такого барьера зависит от репрезентативности канареечной группы, чувствительности выбранных метрик и корректности допустимых порогов.
Компромисс — увеличение времени доставки из-за окон наблюдения и появление двух логических потоков одного снапшота. Сама VK также отмечает, что схема через type_id менее универсальна, чем прямое управление группами через API оркестратора: она не показывает отдельным интерфейсом, какая доля экземпляров уже получила версию и на каком этапе находится раскладка.
| Этап | Окно анализа | Критерий |
|---|---|---|
| Доставка и готовность | 5 минут, раз в минуту | Версия появилась на основной части canary-инстансов; экземпляры сохранили ready |
| Проверка влияния | 20 минут, раз в минуту | Технические и продуктовые показатели не выходят за допустимое отклонение от контрольной группы |
Ограничения архитектурного решения
Два логических потока усложняют конфигурацию, окна наблюдения увеличивают время доставки, а строгость допуска зависит от выбранных метрик и порогов. Реализация через type_id не предоставляет отдельного API управления состоянием раскладки.
Источники
Дата события: 2026-09-28. Дата первоисточника: 2026-09-28.
