Multi-AZ endpoint сам по себе не делает модель отказоустойчивой. Архитектура Salesforce показывает неприятную, но полезную деталь: инфраструктура может быть распределена между зонами, а копии конкретной модели всё равно соберутся так, что отказ одной AZ выключит инференс.
Для команды, которая разворачивает модели у клиента, это меняет предмет проверки. Смотреть нужно не только на число инстансов и статус endpoint, но и на фактическое размещение каждой копии модели, поведение масштабирования и доступную ёмкость после потери зоны.
Где возникает ложная уверенность
В AWS Machine Learning Blog описана производственная схема Agentforce, AI-платформы Salesforce для агентов. Компания использовала SageMaker Inference Components, чтобы размещать несколько моделей на общих GPU. По данным AWS, это сократило инфраструктурные расходы Salesforce в восемь раз.
Но экономия создала новый класс риска. Стандартный алгоритм размещения рассматривал каждую операцию развёртывания IC отдельно: новые копии распределялись между инстансами, но баланс по AZ не гарантировался. Поэтому даже endpoint с инстансами в нескольких зонах мог получить перекошенное размещение конкретной модели.
Отсюда два сценария отказа. Если копии модели находятся на одном инстансе, его падение выключает их все. Если они сосредоточены в одной AZ, недоступность зоны делает недоступной всю модель. Для Salesforce это было ещё и вопросом внутренних требований: каждая production-модель должна поддерживать две AZ.
Это важное различие для архитектурных ревью. Endpoint описывает контур вычислений, а доступность сервиса определяется размещением копий конкретной модели внутри этого контура. Зелёный статус управляемого endpoint здесь легко превращается в дорогую декорацию.
Как Salesforce закрыла разрыв
AWS добавила параметр SchedulingConfig в API CreateInferenceComponent. Он управляет распределением копий IC между зонами и инстансами.
За межзонный баланс отвечает AvailabilityZoneBalance. Параметр MaxImbalance задаёт допустимую разницу в количестве копий между двумя AZ. В примере Salesforce четыре копии модели размещаются на четырёх инстансах: две в первой зоне и две во второй. При MaxImbalance: 1 система допускает разницу максимум в одну копию. Для лёгкой модели с двумя копиями значение 0 задаёт строгую схему: по одной копии в каждой зоне.
Внутри AZ действует PlacementStrategy. Режим SPREAD раскладывает копии по максимально возможному числу инстансов, уменьшая зависимость от одного узла. BINPACK, напротив, уплотняет размещение ради эффективности использования ресурсов. Это уже не выбор между хорошим и плохим. Это явная цена риска: либо лучше изоляция отказов, либо плотнее занятые GPU.
При увеличении CopyCount SageMaker размещает новые копии с учётом заданного межзонного баланса. При уменьшении удаляет их симметрично по AZ. AWS отдельно предупреждает: для HA-критичной модели нельзя снижать CopyCount до единицы, потому что одна копия физически может находиться только в одной зоне.
Есть и менее очевидный операционный хвост. SchedulingConfig управляет планом каждой отдельной операции масштабирования. После повторяющихся scale-in и scale-out для постоянной консолидации и перебалансировки AWS предлагает включить у endpoint стратегию CONSOLIDATION. Фоновый процесс будет собирать копии плотнее, освобождать простаивающие инстансы и при этом учитывать ограничения по AZ.
Доступность начинается там, где заканчивается экономия
Схема Salesforce полезна не как готовый рецепт из нескольких параметров, а как шаблон проверки. Сначала команда получила восьмикратное снижение затрат за счёт совместного использования GPU. Затем выяснилось, что оптимизация размещения по стоимости не обеспечивает требуемую изоляцию отказов. Обычная история инфраструктуры: бесплатная отказоустойчивость существует в основном на слайдах.
Для forward-deployed инженера минимальный чек-лист теперь выглядит так:
- Сколько копий имеет каждая production-модель, а не endpoint в целом?
- В каких AZ и на каких инстансах эти копии реально находятся?
- Сохраняется ли баланс после нескольких циклов увеличения и уменьшения
CopyCount? - Что произойдёт, если одна зона исчезнет при текущей нагрузке?
- Хватит ли оставшейся GPU-ёмкости, или архитектура формально переживёт отказ, но перестанет выдерживать рабочий объём инференса?
Последний вопрос и показывает реальную стоимость HA. Распределить копии недостаточно. Нужно держать такой запас, при котором оставшаяся зона сможет продолжить работу. Архитектура Salesforce сокращает путь к этому контуру, потому что не требует отдельного стека оркестрации размещения. Но она не отменяет плату за резервную ёмкость.
Маркер работоспособности схемы конкретен: после серии scale-out и scale-in копии модели должны оставаться распределёнными между AZ, а тест потери одной зоны не должен оставлять модель без копий и доступной вычислительной ёмкости. Если проверяется только число инстансов у endpoint, тестируется не отказоустойчивость, а аккуратность Terraform.