Как архитектура Neon Lakebase переживает аварии AWS: секреты Stateless Compute и клеточной изоляции

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

Клеточная изоляция: один регион — не значит один домен сбоя

Региональные развертывания Neon не монолитны. Каждый регион состоит из одной или нескольких идентичных ячеек (cells), где каждая ячейка включает собственный Kubernetes control plane, пул вычислительных ресурсов и ресурсы хранения . Такая компартментализация означает, что сбой в одной ячейке — вызванный аварией у облачного провайдера, программной ошибкой или исчерпанием ресурсов — не распространяется на соседние ячейки в том же регионе.

Во время майской аварии AWS 2026 года в us-east-1 отказ облачного провайдера специфически затронул его способность поднимать новые инстансы и выделять IP-адреса . Для монолитной архитектуры это означало бы региональный инцидент. В клеточном дизайне Neon пострадали только те ячейки, которые исчерпали предварительно зарезервированный буфер вычислительных инстансов. Остальные ячейки, с достаточным запасом уже выделенных и запущенных машин, продолжили работу без перебоев .

Такой результат — следствие осознанного архитектурного выбора: ячейки имеют такой размер, чтобы ресурсные лимиты ни одной из них не могли стать региональным узким местом. К этому решению подтолкнули более ранние уроки. До перехода на клеточную изоляцию Neon использовала один Kubernetes-кластер на регион, и тестирование показало деградацию сервиса после 10 000 одновременных баз данных из-за лимитов памяти etcd в EKS, ограничений сетевой конфигурации и ограничения частоты запросов к Kubernetes API . Клеточная архитектура полностью убирает эти «потолки» единого кластера, распределяя нагрузку по независимым, не взаимодействующим друг с другом ячейкам.

Снижение зависимости от облачного провайдера: предварительное резервирование и своя виртуализация

Отношения Neon с облачным провайдером намеренно держатся на расстоянии вытянутой руки. Вместо вызова EC2 API по требованию каждый раз, когда нужно запустить базу данных, Neon заранее выделяет пулы крупных (часто bare-metal) инстансов и поддерживает буферную емкость, способную пережить сбои в предоставлении ресурсов . Этот буфер — не маленький «теплый» пул для приоритетных клиентов, а структурный компонент системы планирования вычислений.

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

Долговечность данных работает по тому же принципу. Все содержимое баз данных находится в собственном зонально-устойчивом сервисе хранения Neon, который опирается на объектные хранилища вроде Amazon S3 или Azure Blob Storage, а не на блочные устройства облачного провайдера . У API объектных хранилищ иной профиль отказов, чем у API выделения виртуальных машин, и на практике их устойчивость при сбоях регионального control plane значительно выше. Когда узел pageserver или safekeeper выходит из строя, никакое долговременное состояние не теряется — другой узел может восстановить необходимые страницы из WAL и объектного хранилища .

Зонально-избыточное хранение — это фундамент, а не премиум-опция

Во многих управляемых БД мультизональная репликация хранилища — это платная функция, требующая явной настройки. В Neon каждая база данных, независимо от тарифного плана, располагается на распределенном, зонально-избыточном объектном хранилище с SSD-кэшами (NVMe), разнесенными по нескольким зонам доступности . Это снимает физическую репликацию между зонами как отдельную задачу, потому что сам слой хранения по своей природе реплицирован.

Дизайн репликации WAL предоставляет конкретные гарантии долговечности: записи синхронно реплицируются на safekeeper с требованием кворума (одна из опубликованных конфигураций — шестикратная репликация с кворумом четыре из шести). Это означает, что целая зона доступности плюс еще одна реплика могут выйти из строя без потери данных . Это не теоретическая устойчивость, а свойство пути записи, которое должно быть выполнено до подтверждения транзакции клиенту.

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

Цели доступности и что показывают данные

Опубликованные SLI доступности для архитектуры Neon Lakebase находятся в диапазоне примерно от 99,93% до 99,96% . Эти цифры отражают дизайн, в котором сбои вычислений исправляются заменой stateless-узлов, а не переключением на бездействующий горячий резерв, а долговечность хранения достигается за счет репликации, опирающейся на объектное хранилище, а не синхронное зеркалирование дисков.

Собственная история инцидентов Neon дает полезную калибровку этих целей. Инцидент в мае 2025 года в us-east-1 вызвал 5,5 часов недоступности операций создания и запуска баз данных в ходе двух отдельных событий; активные базы данных при этом остались незатронутыми . Первопричина — исчерпание IP-адресов в подсетях Kubernetes, вызванное перегрузкой control plane и неверной конфигурацией AWS CNI, — выявила предел масштабирования, который клеточная архитектура впоследствии и была призвана устранить . Еще раньше, в августе 2024 года, сбой pageserver в us-east-1 затронул примерно 0,4% клиентских проектов на срок до двух часов после отказа EC2-инстанса; поскольку pageserver выступает как локальный дисковый кэш с S3 в качестве durable-хранилища, потеря pageserver означала временную недоступность, а не безвозвратную утрату данных .

Эти инциденты подчеркивают, что stateless-вычисления и разделяемое хранилище снижают тяжесть отказов, но не устраняют их полностью. Свойства устойчивости архитектуры — отсутствие потери данных при сбоях вычислений, автоматическое восстановление через переподключение, ограниченный ячейкой радиус поражения — держатся в реальных условиях отказов, но система не застрахована от программных дефектов, исчерпания ресурсов или зависимостей от облачного провайдера, которые пока не удалось разорвать полностью (например, выделение IP-адресов).

Тестирование устойчивости: как Neon проверяет свой дизайн

В инженерном блоге Neon утверждается, что система тестируется на реальных сценариях отказов, включая сбои в предоставлении ресурсов облачным провайдером и симуляции отключения целых зон доступности . Эти тесты нагружают те самые механизмы — пулы предварительно запущенных инстансов и границы клеточной изоляции, — которые и должны ограничивать радиус поражения. Общая форма chaos engineering, описываемая Neon, отражает устоявшуюся практику: определить гипотезу устойчивого состояния о том, как система должна вести себя при сбое, впрыснуть контролируемый отказ (например, отключить целую зону доступности или исчерпать вычислительные буферы), наблюдать, подтверждается ли гипотеза, и итеративно улучшать архитектуру, если нет .

Хотя Neon не публиковала детальную методологию chaos engineering и конкретные результаты экспериментов за пределами архитектурного обзора в блоге, доступные данные показывают, что тесты напрямую целятся в отличительные заявления системы об устойчивости. Описываемые Neon тесты — симуляция сбоев предоставления ресурсов и отказов целых зон доступности — это ровно те сценарии, где stateless-вычисления и клеточная изоляция должны обеспечить наибольшее преимущество перед традиционными архитектурами управляемых БД. Майская авария AWS 2026 года фактически сработала как незапланированная валидация этих же механизмов, и ограниченный радиус поражения соответствует тому, что и должны давать предварительное резервирование и клеточная изоляция.

Что это значит для команд, выбирающих serverless Postgres

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

Архитектура также заставляет честно оценивать облачные зависимости. Ни один сервис БД по-настоящему не независим от своего облачного провайдера, однако степень связанности колоссально разнится. Решение Neon предварительно резервировать мощности, использовать собственный слой виртуализации и хранить данные в объектном хранилище, а не на блочных томах, сокращает площадь поверхности облачных API, которые должны быть доступны для функционирования уровня баз данных. Эта более узкая поверхность зависимостей окупилась во время майской аварии AWS 2026 года, когда ячейки с достаточным заранее выделенным буфером продолжили работу в условиях, которые для более жестко связанной архитектуры вылились бы в региональный коллапс.

Для команд, строящих инфраструктуру на serverless-решениях, подход Neon демонстрирует, что локализация взрыва — это не запоздалая мысль, а продукт архитектурных решений, принятых на границе хранения и вычислений и в структуре доменов сбоев задолго до того, как случится реальная авария.