Инженеры, работающие с базами данных, часто представляют себе масштабирование как что-то из области магии — особенно когда речь идёт о таких продуктах, как PlanetScale. Но что, если попробовать воспроизвести эту архитектуру самостоятельно? В июле 2026 года разработчик Онат (Onatm) опубликовал подробный отчёт о том, как он собирает собственную версию PlanetScale с нуля, используя Vitess, Kubernetes и другие современные инструменты. В этой статье разберём ключевые архитектурные решения и вызовы, с которыми столкнулась команда проекта Источник.
Проблема: почему PlanetScale не так прост, как кажется
PlanetScale — это managed-сервис на базе Vitess, который предоставляет совместимость с MySQL, горизонтальное масштабирование и бесшовные миграции схем. Однако за этим скрывается сложная инфраструктура: Vitess сам по себе требует управления кластером, настройки шардинга, балансировки нагрузки и мониторинга. В статье автор отмечает, что ключевая сложность — не в самом Vitess, а в построении надёжной операционной платформы вокруг него: автоматическое восстановление после сбоев, управление конфигурациями и бесшовное развёртывание.
Основная проблема, которую решает проект, — отсутствие простого, воспроизводимого способа развернуть PlanetScale-подобную архитектуру в частном облаке или на собственном «железе». Многие компании сталкиваются с вендор-локом или высокой стоимостью облачных managed-сервисов, а документация Vitess часто ориентирована на опытных DevOps-инженеров. Проект Homescale (так автор назвал свою сборку) призван заполнить эту нишу.
Решение: пошаговая сборка инфраструктуры
В первой части серии статей автор описывает базовую инфраструктуру. В качестве основы выбран Vitess версии 21.x, развёрнутый в Kubernetes (K8s). Используется стандартный оператор Vitess для K8s, что упрощает управление жизненным циклом компонентов: VTGate (прокси-слой), VTTablet (агенты на узлах) и etcd для хранения метаданных.
Ключевые архитектурные решения:
- Sharding по диапазону ключей: используется хеширование ID записей для равномерного распределения данных по шардам.
- Автоматическое переключение при сбое: настройка Orchestrator (или его аналога) в связке с Vitess для обнаружения отказа реплики и promotion нового мастера.
- Балансировка запросов: VTGate автоматически направляет запросы к нужному шарду на основе ключа шардирования, что скрывает сложность от приложений.
- Online DDL (изменение схемы без блокировок): используется механизм VReplication для выполнения миграций без даунтайма — критично для production-сред.
В материале подчёркивается, что важной частью является настройка мониторинга: Prometheus + Grafana для отслеживания метрик производительности (QPS, latency, количество соединений) и алертов на основе порогов. Автор приводит пример файла конфигурации для Prometheus, который собирает метрики с VTGate и VTTablet.
Результаты: что получилось на практике
По словам автора, после развёртывания базового кластера удалось достичь следующих показателей:
- Время развёртывания полного стека (Vitess + K8s + мониторинг) — около 2 часов с использованием подготовленных Helm-чартов.
- Пропускная способность — до 10 000 write-запросов в секунду на шард при использовании SSD-накопителей и 8 ядер CPU на узел.
- Время восстановления после отказа мастера — менее 30 секунд (включая обнаружение и promotion).
Однако автор честно признаётся: в отличие от PlanetScale, в Homescale пока нет встроенного web-интерфейса для управления данными и миграциями, а также отсутствует интеграция с GitHub для автоматизации deployment. Это оставляет пространство для будущих улучшений.
Выводы: стоит ли повторять этот опыт?
Проект Homescale — отличный пример того, как современные open-source инструменты позволяют инженерам воспроизводить сложные облачные сервисы локально. Хотя он не заменит PlanetScale для команд, которые ценят zero-ops, он даёт глубокое понимание того, как работают распределённые базы данных под капотом.
Для тех, кто хочет углубиться в тему, рекомендуется изучить официальную документацию Vitess и Kubernetes. Если вы работаете с распределёнными системами и хотите управлять несколькими базами данных через единый API, обратите внимание на платформы, которые предлагают готовую интеграцию с Vitess и MySQL. Например, ASI Biont поддерживает подключение к Vitess и MySQL через API — подробнее на asibiont.com/courses.
В следующих частях цикла автор обещает рассказать о настройке шардирования для реального приложения и о том, как справляться с горячими точками (hotspots) — следите за обновлениями.
Комментарии