Масштабирование хранилища ломается не на объёме, а на неучтённых узких местах

Масштабирование хранилища ломается не на объёме, а на неучтённых узких местах

Распределённое хранилище обычно деградирует по одному из трёх сценариев: растёт latency на запись, падает эффективность ребалансировки или начинается перекос по «горячим» узлам. Анализ показал, что узкое место часто не в дисках, а в сети, метаданных и фоне обслуживания.

При разборе архитектуры смотрят на три слоя:
— data plane: сколько трафика реально проходит между репликами и как ведёт себя хвост задержек;
— control plane: где хранятся метаданные, как часто они обновляются и есть ли единая точка блокировки;
— failure domain: совпадают ли границы шардинга с rack, AZ или отдельными стойками.

Если система масштабируется плохо, проблема обычно в том, что добавление узла увеличивает не полезную ёмкость, а объём фоновой работы: репликацию, сканирование, восстановление, пересчёт индексов. Рекомендуется обратить внимание на метрику write amplification и время rebuild после потери узла. Если они растут нелинейно, горизонтальное расширение быстро становится дорогим.

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

Если кластер нельзя восстановить в предсказуемое время после отказа, он уже не масштабируется, а лишь маскирует накопленный технический долг.