У SaaS-продукта может быть много исправных серверов и одна общая причина для остановки всех клиентов: неудачное изменение, тяжёлый импорт или запрос, на котором падает обработчик. Добавление экземпляров не всегда меняет масштаб последствий. Иногда оно просто позволяет быстрее разнести проблему по всей платформе.
Cell-Based Architecture предлагает обслуживать разные группы клиентов в отдельных ячейках. Это не деление приложения на «оплату», «каталог» и «отчёты». Каждая ячейка содержит необходимые компоненты определённого сервиса для своей части нагрузки. Разделяем прежде всего клиентов и их рабочий путь, а не названия функций.
Сначала выберите границу, которая имеет смысл
Возьмём платформу управления ремонтом для нескольких компаний. Естественным ключом может быть организация: её заявки, сотрудники и документы находятся в одной ячейке. Тогда перегрузка импорта у одного клиента с меньшей вероятностью займёт ресурсы всех остальных — при условии, что критические ресурсы действительно разделены.
Деление по отдельным пользователям может оказаться менее удачным. Сотрудники одной компании постоянно работают с общими заявками, и их действия начнут пересекать границы. Если обычная операция требует синхронного ответа соседней ячейки, отказ соседа снова становится нашим отказом.
Поэтому ключ проверяют на реальных сценариях: совместная работа, поиск, выгрузка, смена подразделения. Удобный способ равномерно разложить идентификаторы ещё не обязательно создаёт самостоятельные группы работы. Базовое устройство ячеек и роль ключа описаны в руководстве AWS.
У ячейки должен быть известный предел
Если каждая ячейка просто растёт без ограничений, компания со временем получит несколько прежних проблем вместо одной. Полезнее знать проверенную ёмкость: какую смесь обычных запросов, фоновых задач и данных выдерживает один экземпляр сервиса с приемлемым качеством.
Число клиентов — грубый ориентир. Небольшая организация и крупная сеть могут отличаться по нагрузке сильнее, чем две соседние ячейки целиком. Поэтому для размещения важны профиль работы, размер данных, пиковые операции и запас для роста.
Когда безопасная граница близка, создают новую ячейку или заранее переносят часть нагрузки. У крупного клиента может появиться выделенная ячейка, но это не отменяет её ограничений. Если его работа больше проверенной ёмкости, понадобится ещё одно осмысленное деление или изменение самого сервиса.
Такая модель позволяет испытать размер, который действительно собираются эксплуатировать. Именно ограниченную, проверяемую ёмкость подчёркивает разбор преимуществ ячеек AWS, а не бесконечное увеличение каждого отдельного блока.
Общая зависимость легко отменяет изоляцию
Отдельные приложения с одной общей очередью или базой могут по-прежнему мешать друг другу. Разделять нужно ресурс, который способен исчерпаться, а не только процессы в схеме развёртывания. Для некоторых угроз достаточно раздельных пулов и лимитов; для других требуется самостоятельное хранилище или более глубокая изоляция.
Общие службы всё равно могут остаться: маршрутизация, вход пользователей, настройки, управление размещением. Для каждой надо определить последствия отказа. Например, недоступность создания новых ячеек не обязательно должна останавливать уже работающих клиентов. Но это получится лишь при соответствующем устройстве обычного пути запросов.
Маршрутизатор лучше оставить небольшим: определить назначенную ячейку и передать запрос. Если туда же собрать расчёт тарифов, сложные разрешения и продуктовую оркестрацию, получится новый общий центр отказа. Рекомендации по маршрутизации отдельно выделяют эту опасность.
Одинаковый код тоже связывает ячейки
Изоляция ресурсов не остановит плохой релиз, если одновременно установить его повсюду. То же относится к общей ошибочной настройке или массовому включению функции. Для изменения нужны этапы: ограниченная группа, наблюдение за рабочими сценариями, затем расширение. При этом задержанная ошибка может проявиться не сразу — одной успешной проверки после запуска мало.
С другой стороны, не нужно превращать каждую ячейку в уникальный продукт. Разные версии на период выпуска допустимы, постоянный набор особых ручных настроек делает восстановление непредсказуемым. Повторяемое развёртывание и учёт конфигураций здесь становятся ежедневной работой.
Ячейки также не равны географическому резерву. Несколько изолированных групп в одном регионе могут вместе потерять доступ к его инфраструктуре. Защита от потери региона решает другую задачу, даже если оба подхода используются в одном продукте.
Нельзя просто отправить пострадавшего клиента к соседям
У здоровой ячейки может не быть ни данных клиента, ни мощности для него. Слепая смена маршрута способна распространить перегрузку и добавить ошибки доступа к данным. Уменьшение числа пострадавших не означает мгновенного восстановления для тех, кто уже попал в аварию.
Плановый перенос требует работы с данными, незавершёнными задачами и моментом смены владельца записи. Надо решить, как обрабатывать запросы во время перехода и куда попадут повторы старых сообщений. После переключения новая сторона может получить изменения, которых уже нет на старой: обратный перевод адреса не будет полноценным откатом.
Для компании-клиента такой перенос должен сохранять правила доступа и целостность её рабочего пространства. Это особенно важно, если организация объединяет подразделения или меняет принадлежность пользователей: технический ключ размещения не должен случайно стать разрешением увидеть чужие документы.
Как понять, что расходы на ячейки оправдались
Считать только долю затронутых клиентов недостаточно. В одной ячейке могут оказаться самые крупные заказчики или критический операционный поток. Нужны последствия для конкретных процессов, длительность восстановления и работа сотрудников поддержки, а не обещание, что любой инцидент затронет одинаковую небольшую долю выручки.
Цена включает резерв мощности, сопровождение нескольких групп, переносы и проверку общей инфраструктуры. Иногда часть ресурсов можно перераспределить из прежней системы, а не умножать всё оборудование. Но дополнительные процедуры и возможный простой свободной мощности остаются.
Хорошая приёмка — намеренно перегрузить одну выбранную ячейку в согласованном испытании и проверить рабочие операции в остальных. Затем проверить маршрутизатор и выпуск новой версии. Если соседи продолжают работать только пока общая зависимость здорова, именно эту границу защиты и нужно записать, а не объявлять платформу полностью изолированной.