Режим отказа hot shard: обнаружение, изоляция и долгосрочная политика

Почему хеш-шардирование не предотвращает горячие шарды

Хеш-шардирование (shard = hash(tenant_id) mod N) распределяет равномерно при равномерном распределении ключей. Реальные клиенты распределены по степенному закону: один-два клиента генерируют 60–80% трафика; остальные — длинный хвост.

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

Проблема структурная, а не баг: хеш-шардирование было правильным выбором (равномерное распределение по хвосту), но конструкция неполная без политики изоляции выбросов.

Обнаружение: что мониторить

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

Немедленное смягчение: изоляция клиента в Citus

Когда виновник — один клиент, переместите его на выделенный шард:

-- Переместить клиента 9821 на его собственный шард (онлайн, без downtime)
SELECT isolate_tenant_to_new_shard('orders', 9821, 'CASCADE');

Что делает Citus:

1. Создаёт новый шард.
2. Устанавливает логическую репликацию со старого шарда на новый, копируя только строки клиента 9821.
3. После синхронизации ненадолго приостанавливает записи к клиенту 9821 (суб-секунда), переключает указатель метаданных.
4. Возобновляет работу. Старый шард больше не содержит данных клиента 9821.

Общее время: минуты-часы в зависимости от объёма данных клиента (~10–100 МБ/с пропускная способность). Пауза записи — суб-секундная. CPU исходного шарда сразу падает до медианы кластера после переключения.

Для шардирования на уровне приложения без Citus: эквивалент — перемаппирование в directory — обновить карту шардов для этого клиента на новый Postgres, двойная запись во время перехода, переключение чтений. Для этого нужны готовые инструменты; команды без них тратят дни на экстренную ситуацию.

Долгосрочная политика: автоматизация, а не реакция

Один инцидент с горячим шардом допустим. Два — сбой процесса. Долгосрочное исправление — тиерированная политика:

1. Алерт на перекос (max/median > 1.5×) и нагрузку на клиента (> 5% кластера). Это опережающие индикаторы.
2. Автоматизировать изоляцию для клиентов, пересекающих порог 5%: фоновая задача вызывает isolate_tenant_to_new_shard. Без участия человека для рутинных случаев.
3. Эскалировать клиентов выше 20% на выделенный воркер; выше 50% — на выделенный кластер + разговор с клиентом.
4. Предварительно изолировать новые корпоративные аккаунты выше порогового размера при онбординге — не ждать скачка трафика.
5. Тренировать runbook ежеквартально на стейджинге, чтобы дежурные инженеры могли изолировать клиента менее чем за 15 минут.

Вместе эти пять шагов означают: ни одному инженеру не нужно принимать решение под давлением продакшна — политика решает за него. Без шага 2 (автоматизация) тебя будут будить в 3 ночи снова и снова; без шага 4 (предварительная изоляция) онбординг нового корпоративного клиента превращается в бомбу замедленного действия.