5 лет масштабирования: от 5 до 500 серверов для ТехноМаркет

У ТехноМаркет не было ни резервного ДЦ, ни плана действий при отказе основного. Когда в марте 2021 года в московском ДЦ произошёл пожар на подстанции, сайт был недоступен 14 часов. Потери составили ~8 млн рублей в упущенных заказах.

Мы развернули полную копию инфраструктуры во втором ДЦ (Санкт-Петербург) с VPN-каналом между площадками:

• MySQL master-slave репликация между ДЦ
• lsync для синхронизации NFS-хранилища
• Двойной интернет-канал в каждом ДЦ

# Конфигурация MySQL репликации
# На master (Москва):
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
binlog_do_db = technomarket
expire_logs_days = 7

# На slave (СПб):
[mysqld]
server-id = 2
relay_log = /var/log/mysql/relay-bin
read_only = 1
super_read_only = 1

Параметр super_read_only стал нашим спасением — он блокирует любые записи, даже от пользователей с привилегиями SUPER, предотвращая случайные split-brain сценарии при ручном переключении.

Процедура failover была полностью задокументирована и протестирована ежемесячно. Время переключения — 15 минут с деградацией в read-only режим.

Перед миграцией каждый сервис прошёл чек-лист «12 факторов»:

• Конфигурация через переменные окружения (не файлы)
• Stateless-процессы (сессии в Redis, файлы в S3)
• Логирование в stdout/stderr
• Graceful shutdown по SIGTERM

Мы не мигрировали всё разом. Каждый сервис переносился поэтапно с переключением через Ingress:

# Ingress для постепенного переключения трафика
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: technomarket-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
spec:
  rules:
    - host: technomarket.ru
      http:
        paths:
          - path: /api/catalog
            pathType: Prefix
            backend:
              service:
                name: catalog-svc-k8s
                port:
                  number: 8080

Начинали с 5% трафика, отслеживали метрики в Grafana (ошибки, латентность, CPU/RAM) и за 1-2 недели доводили до 100%. На каждом этапе сохранялась возможность мгновенного отката на VM-версию.

Три функции Kubernetes, которые оказались критически важными:

• PodDisruptionBudget — гарантия минимального количества реплик при обновлениях узлов
• Liveness/Readiness probes — автоматическое удаление неработающих подов из балансировки
• HPA с кастомными метриками — автомасштабирование по глубине очередей RabbitMQ

# HPA по метрикам из Prometheus (глубина очереди)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-processor-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-processor
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: External
      external:
        metric:
          name: rabbitmq_queue_messages
          selector:
            matchLabels:
              queue: orders
        target:
          type: AverageValue
          averageValue: "100"

Вместо master-slave мы перешли на Percona XtraDB Cluster с синхронной репликацией между тремя площадками:

# Конфигурация Percona XtraDB Cluster (my.cnf)
[mysqld]
wsrep_cluster_name = technomarket-prod
wsrep_cluster_address = gcomm://10.1.1.10,10.2.1.10,10.3.1.10
wsrep_node_address = 10.1.1.10
wsrep_provider = /usr/lib/galera4/libgalera_smm.so
wsrep_sst_method = xtrabackup-v2
wsrep_sync_wait = 1

# ProxySQL для балансировки запросов
# Чтение — ближайший узел, запись — только master
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight)
VALUES 
  (10, '10.1.1.10', 3306, 1000),  -- writer
  (20, '10.1.1.10', 3306, 500),   -- reader DC1
  (20, '10.2.1.10', 3306, 500),   -- reader DC2
  (20, '10.3.1.10', 3306, 500);   -- reader DC3

Синхронная репликация критически зависит от латентности между узлами. Мы заказали выделенные оптоволоконные каналы между ДЦ с RTT менее 2 мс. Это дало:

• Синхронная репликация без заметной деградации производительности
• Возможность покомпонентного failover (отказ одного сервиса — не весь ДЦ)
• Split DNS для маршрутизации клиентов к ближайшему ДЦ

Мы построили трёхуровневый мониторинг:

• Инфраструктурный слой: Prometheus + node_exporter + Grafana. USE-метрики (Utilization, Saturation, Errors) на каждый сервер и каждый контейнер
• Прикладной слой: RED-метрики (Rate, Errors, Duration) по каждому vhost, location и контроллеру. Алерты в Alertmanager с маршрутизацией в Telegram дежурной команде
• Бизнес-слой: Количество заказов в минуту, средний чек, конверсия. Аномалии детектируются автоматически

# Пример правила алертинга: деградация конверсии
groups:
  - name: business-alerts
    rules:
      - alert: ConversionDropped
        expr: |
          rate(orders_completed_total[10m]) 
          / rate(sessions_started_total[10m]) 
          < 0.02
        for: 15m
        labels:
          severity: critical
        annotations:
          summary: "Конверсия ниже 2% более 15 минут"
          description: "Текущая конверсия: {{ $value | humanizePercentage }}"

Мы разработали админ-панель, позволяющую управлять процентом трафика на новую версию любого сервиса. Это позволило разработчикам ТехноМаркет самостоятельно выкатывать изменения с минимальным риском:

1. Новая версия деплоится как отдельный Deployment
2. Через панель направляется 5% трафика
3. A/B сравнение метрик в реальном времени
4. При отсутствии деградации — поэтапное увеличение до 100%
5. Автоматический rollback при росте ошибок выше порога

Переключение трафика между ДЦ было полностью автоматизировано через API CDN-провайдера. При обнаружении недоступности основного ДЦ система:

1. Переводит затронутый ДЦ в read-only режим
2. Переключает upstream в CDN на резервный ДЦ
3. Отправляет алерт дежурной команде
4. Автоматически возвращает трафик после восстановления

Время полного переключения сократилось с 15 минут до 45 секунд.