Резервирование и единые точки отказа

Что такое единая точка отказа на самом деле

Единая точка отказа (single point of failure, SPOF) — любой компонент, чей индивидуальный отказ валит всю систему. Это несущая стена: выбей её — и всё, что выше, обрушится. Дисциплина построения под доступность по сути — это дисциплина выслеживания SPOF и их устранения, по одной, потому что обычно их больше одной и они прячутся.

Находят их мысленным экспериментом над каждым прямоугольником и линией на диаграмме архитектуры: «Если эта одна вещь умрёт прямо сейчас, система продолжит обслуживать?» База данных из вступления провалила тест — убей её, и всё встанет. Так же и единственный балансировщик перед «зарезервированным» флотом, единственный NAT-шлюз, через который течёт весь исходящий трафик, единственный DNS-провайдер, единственный CI-сервер, хранящий единственную копию ключей деплоя, одинокий дежурный инженер, который знает, как работает легаси-джоб биллинга. SPOF — это не только машины; это любая единичная зависимость, включая человека или вендора.

Резервирование: N, N+1, N+2

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

• N — ровно та ёмкость, что нужна под пиковую нагрузку, без запаса. Если спрос — 4 единицы и каждый ящик обслуживает 1, ты держишь 4. Потеряешь любой — и ты уже под ёмкостью. N — не зарезервировано.
• N+1 — один запасной сверх нужды. Держишь 5 ящиков под спрос в 4 единицы; теряешь один, и оставшиеся 4 всё ещё несут пик. Это базовая планка «зарезервированности», и она терпит ровно один отказ за раз.
• N+2 — два запасных, чтобы пережить отказ пока другой узел уже лежит (например, один на обслуживании, а второй умер). Высшие уровни доступности и всё с медленной заменой хотят N+2.

Тонкость, которую упускают джуны: резервирование надо размерять под пик, а не среднее. «У нас два сервера, значит мы зарезервированы» ложно, если один сервер не несёт пик в одиночку: потеря одного перегружает выжившего, что сваливается в коллапс очередей из раздела масштабируемости, и твоя «зарезервированная» пара отказывает как единое целое. Настоящий N+1 значит, что каждое выжившее подмножество всё ещё держит SLO.

Active-active против active-passive

Есть два способа расставить зарезервированные копии, и выбор меняет стоимость на скорость восстановления:

• Active-active — все копии обслуживают трафик одновременно, за балансировщиком. Теряешь одну — другие мгновенно впитывают её долю (ты под это размерял через N+1). Никакой задержки «переключения», и ты непрерывно гоняешь каждую реплику, так что знаешь — они все работают. Цена: каждая копия должна быть размерена и оплачена всегда, а stateful active-active нуждается в разрешении конфликтов, ведь две копии могут принимать записи одновременно.
• Active-passive — одна копия обслуживает; резерв простаивает (или тёплый) и берёт на себя, только когда активная умрёт. Дешевле для stateful-систем (один писатель, нет конфликтов) и проще для рассуждения, но failover берёт время, и резерв, который никогда не гоняли, может оказаться тихо сломанным, когда наконец понадобится — классический сбой «бэкап не сработал».

Ловушка: фальшивое резервирование через общую зависимость

Вот режим отказа, что превращает уверенно «зарезервированные» архитектуры в сбои: две копии, выглядящие независимыми, но делящие скрытую зависимость, вообще не зарезервированы. Если две реплики БД живут на одном физическом хосте, одном массиве хранения, в одной стойке, на одной линии питания или в одной зоне доступности, то единственное событие — тот хост, тот массив, та стойка, тот фид питания, та AZ — кладёт обе разом. Ты заплатил за две копии всего и всё ещё имеешь единую точку отказа, просто менее очевидную.

Это коррелированный отказ (correlated failure), и это центральная причина, почему математика доступности на независимости («каждая реплика 99,9%, значит две дают 99,9999%») оптимистична до опасности. Умножение держится, только если отказы независимы. В момент, когда они делят причину, твоя реальная доступность управляется этой общей вещью, а не числом реплик. Весь смысл облачных зон доступности (availability zones, AZ) — дать тебе домены размещения, спроектированные отказывать независимо: раздельные питание, охлаждение и сеть, достаточно далеко друг от друга, чтобы одно наводнение/пожар/сбой питания не унесло обе — так что разнос реплик по AZ делает их отказы по-настоящему некоррелированными.

Радиус поражения: ограничь отказ, который не предотвратить

Ты никогда не устранишь каждый отказ, поэтому вторая дисциплина — ограничить, сколько может унести один отказ — его радиус поражения (blast radius). Вопрос дизайна смещается с «это упадёт?» (упадёт) на «когда упадёт, сколько уйдёт вместе с ним?». Помогает разбиение: шардь пользователей по ячейкам, чтобы отказ одной ячейки задел 1/N пользователей вместо всех; изолируй тенантов, чтобы шумный или сломанный не заморил остальных; деплой регион за регионом, чтобы плохой релиз поймать до глобального. Система с малыми радиусами поражения деградирует ломтиками; система с одним гигантским общим всем отказывает разом. Снижение радиуса поражения не повышает вероятность остаться поднятым для отдельного пользователя, но резко снижает тяжесть отказов, что всё же случаются — а тяжесть и есть то, что всплывает в постмортеме.