Масштабирование без ограничений: зачем нужен Azure Compute Fleet для массовых нагрузок

By Mirko Peters · 2026-08-13

«Добро пожаловать обратно в наш постоянный разбор продвинутых облачных архитектур. В последнем выпуске подкаста „Azure Compute Fleet – Simply Explained“ мы разобрали м…»

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в наш цикл материалов о современных облачных архитектурах. В нашем последнем выпуске подкаста Azure Compute Fleet – Simply Explained мы разобрали серьезную задачу, с которой сталкиваются современные компании при работе с облачной инфраструктурой. Если вы когда-либо пытались развернуть сразу сотни или тысячи виртуальных машин для ресурсоемкого пакетного задания, симуляции высокопроизводительных вычислений или конвейера обработки больших данных, вы наверняка знаете, насколько неприятно внезапно упереться в ограничения по ёмкости. В этой статье мы подробнее разберем эти концепции, покажем, почему традиционные методы не справляются, и объясним, как Azure Compute Fleet меняет подход к получению и управлению большими вычислительными ресурсами в облаке.

Что такое Azure Compute Fleet?

Azure Compute Fleet — это специализированный управляемый сервис, созданный именно для решения задач нехватки ёмкости при масштабных развертываниях. Когда нужно мгновенно масштабировать нагрузку от нуля до тысяч рабочих узлов, стандартные методы развертывания легко упираются в узкие места. Создать одну виртуальную машину несложно, а вот попросить регион выделить тысячу одинаковых виртуальных машин одного точного SKU — совсем другая задача. Azure Compute Fleet меняет сам базовый вопрос, который вы задаете облаку. Вместо вопроса «Как получить тысячу одинаковых ВМ именно этого размера?» вы спрашиваете: «Как получить вычислительную ёмкость, которая нужна моей нагрузке, используя набор допустимых вариантов?» Описывая общие требования к ёмкости, допустимые размеры ВМ, региональные предпочтения и готовность использовать как обычные (on-demand), так и более дешевые Spot-цены, вы позволяете Azure интеллектуально искать ресурсы в нескольких пулах доступности, чтобы обеспечить то, что нужно вашему приложению.

Почему важна гибкость

Чтобы понять, почему Compute Fleet так мощен, нужно внимательно посмотреть на то, как устроена облачная ёмкость. SKU виртуальной машины представляет собой конкретное сочетание ЦП, памяти, архитектуры хранилища и семейства процессоров. Если ваши скрипты автоматизации запрашивают только один конкретный SKU, Azure может искать только это точное совпадение. Если это семейство испытывает высокий спрос в целевом регионе, развертывание либо застрянет в очереди, либо завершится ошибкой. Compute Fleet вносит гибкость, позволяя указать широкий набор допустимых размеров ВМ. Пока ваша нагрузка способна корректно выполняться на разных аппаратных конфигурациях, Azure может динамически распределять ваши рабочие узлы. В большом масштабе эта гибкость многократно повышает вероятность получить именно тот суммарный объем вычислительной мощности, который нужен, именно тогда, когда он нужен.

До 10 000 ВМ в одном флоте

Ручное управление крупномасштабной инфраструктурой быстро приводит к операционному истощению. Написание собственных скриптов оркестрации для повторных попыток развертывания, резервных размеров ВМ и мониторинга по десяткам разных конфигураций очень быстро превращается в неподдерживаемый кошмар. Compute Fleet призван устранить эти операционные издержки: один запрос флота поддерживает до 10 000 виртуальных машин. Вы один раз задаете параметры флота, а Azure оценивает доступные ресурсы по всем разрешенным вариантам, автоматически определяет оптимальное сочетание и разворачивает необходимые группы базовых виртуальных машин. Эта нативная возможность позволяет инженерным командам сосредоточиться на своих рабочих нагрузках, а не тратить бесчисленные часы на поиск ошибок выделения инфраструктуры.

Чего Compute Fleet не делает

Хотя Azure Compute Fleet – это настоящий прорыв в получении вычислительных мощностей, важно понимать его границы. Compute Fleet решает проблему нехватки мощностей, но не диктует и не заменяет всю архитектуру приложения. Вы по-прежнему полностью отвечаете за образы виртуальных машин, сетевые конфигурации, группы безопасности и прикладное программное обеспечение, которое нужно каждому рабочему узлу для выполнения задач. Compute Fleet не знает по своей природе, рендерят ли ваши рабочие узлы кинематографические визуальные эффекты, выполняют ли сложные финансовые расчёты, запускают ли автоматизированные регрессионные тесты или анализируют ли необработанную научную телеметрию. Кроме того, он не заменяет базовые архитектурные компоненты, такие как балансировщики нагрузки, долговечные очереди сообщений, логику приложения или механизмы аварийного восстановления. Его единственная, узко направленная задача – получение и управление большими объёмами вычислительных мощностей, когда доступно несколько приемлемых конфигураций.

Выбор приемлемых размеров виртуальных машин

Проектирование эффективного развёртывания флота начинается с критически важного архитектурного решения: определения того, какие размеры виртуальных машин ваше приложение действительно может использовать. В масштабах флота главная задача не должна сводиться к выбору конкретной модели процессора по личным предпочтениям. Вместо этого необходимо тщательно проанализировать программные требования. От каких количеств ядер ЦП, пороговых значений памяти, показателей производительности локального хранилища или типов ускорителей действительно зависит ваше приложение? Если под эти операционные пороги подходит несколько семейств виртуальных машин, их включение даёт Azure гораздо более широкое пространство для поиска. Однако каждый размер, который вы включаете, необходимо строго проверить. Никогда не добавляйте семейство виртуальных машин в конфигурацию флота только потому, что оно кажется дешевле, если ваше ПО требует определённых наборов инструкций, специализированных драйверов, особых конфигураций хранилища или конкретных аппаратных возможностей.

Мощность и цена

Ещё одно важное соображение при проектировании связано с балансом между немедленной потребностью в мощностях и общей оптимизацией затрат. Разные рабочие нагрузки требуют совершенно разных стратегий развёртывания. Например, ночной расчёт финансовых рисков может иметь жёсткое окно выполнения и должен завершиться до открытия глобальных рынков следующим утром. В таком сценарии получение гарантированных мощностей немедленно гораздо важнее, чем поиск абсолютно минимальной цены за ядро. С другой стороны, другие рабочие нагрузки предлагают огромную гибкость в планировании. Фоновое тестирование, долгосрочные симуляции, обработка накопленных данных и временные среды разработки зачастую могут мириться с небольшими задержками при получении полного объёма мощностей в обмен на значительно более низкие затраты на инфраструктуру. Compute Fleet даёт организациям архитектурную свободу адаптировать развёртывания под эти различные операционные приоритеты.

Выбор виртуальных машин на основе атрибутов

Чтобы сделать настройку ещё более гибкой, Azure предлагает подход выбора виртуальных машин на основе атрибутов, который в наших недавних подкастах был отмечен как перспективная функция в режиме предварительного просмотра. Вместо того чтобы вручную перечислять десятки отдельных точных SKU виртуальных машин, эта возможность позволяет задать обобщённые характеристики. Можно указать такие параметры, как минимальное и максимальное количество vCPU, диапазоны памяти, требования к локальному хранилищу NVMe или специализированные ускорители GPU. Azure затем динамически определяет и использует размеры виртуальных машин, соответствующие этим атрибутам. Это обеспечивает исключительную готовность к будущему по мере того, как Microsoft внедряет новые, более эффективные поколения виртуальных машин в облаке, однако ваши приложения всё равно должны пройти должную проверку на любых вновь подобранных аппаратных профилях.

Виртуальные машины по запросу

Построение надёжного флота требует понимания различных ролей моделей закупки. Виртуальные машины по запросу образуют стабильную, надёжную основу вашего флота. Когда вы запрашиваете виртуальную машину по запросу, вы платите стандартную, предсказуемую ставку, и Azure гарантирует, что не отзовёт ресурс только потому, что спрос другого клиента вырос. Поэтому мощности по запросу идеально подходят для абсолютного минимального базового объёма вычислений, необходимого вашей рабочей нагрузке для постоянной работоспособности. Критически важные компоненты инфраструктуры, такие как координаторы заданий, слушатели очередей сообщений и основные базовые рабочие узлы, почти всегда должны использовать мощности по запросу, чтобы обеспечить непрерывный контроль.

Spot-виртуальные машины

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

Сочетание Spot и стандартных мощностей

Не обязательно выбирать между чисто стратегией оплаты по факту использования и исключительно подходом на основе Spot. На самом деле наиболее устойчивые архитектуры объединяют обе модели оплаты в единый согласованный парк. Используя виртуальные машины с оплатой по факту использования для постоянной control plane и базовых рабочих узлов, вы гарантируете предсказуемый минимальный уровень производительности. Одновременно вы можете заполнить парк виртуальными машинами Spot, чтобы справляться с масштабным вычислительным ростом за долю обычной стоимости. Если Azure отберёт часть ваших рабочих узлов Spot во время нехватки ресурсов, основные узлы с оплатой по факту использования продолжат работу без прерываний, обеспечивая отличный экономический баланс между финансовой экономией и операционной стабильностью.

Проектирование с учётом прерываний

Хотя Azure Compute Fleet эффективно управляет распределением базовых ресурсов и обрабатывает уведомления о прерываниях Spot, он не может волшебным образом защитить данные приложения, которые хранятся исключительно в памяти отдельного рабочего узла. Чтобы по-настоящему использовать возможности парка, рабочая нагрузка должна изначально проектироваться с учётом завершения работы узлов. Например, рассмотрим распределённый конвейер рендеринга видео. Если проект разделён на отдельные задачи рендеринга кадров, и Azure забирает виртуальную машину Spot во время обработки кадра 412, эта конкретная задача должна автоматически вернуться в вашу центральную очередь сообщений, чтобы другой доступный рабочий узел мог её взять. Такой же архитектурный шаблон в равной мере применим к научным симуляциям, автоматизированным сборкам программного обеспечения, тестированию в рамках непрерывной интеграции и масштабной аналитике данных.

Храните состояние вне рабочего узла

Чтобы выжить в динамичном парке, ваше приложение должно следовать золотому правилу: полностью храните состояние вне рабочего узла. Не полагайтесь на локальное временное дисковое хранилище для критически важных постоянных данных. Вместо этого используйте надёжные решения для хранения, такие как Azure Blob Storage, управляемые реляционные базы данных или распределённые NoSQL-хранилища, чтобы поддерживать источник истины. Используйте надёжные очереди для распределения задач по парку и обеспечьте регулярное создание контрольных точек рhigher в ходе длительных операций. Проектируйте задачи как идемпотентные, то есть такие, которые можно выполнять несколько раз без создания дублирующих записей или повреждённых результатов. Когда виртуальная машина Spot неожиданно исчезает, вы должны потерять лишь крошечную часть работы, которая выполнялась в данный момент, а не часы невосстановимой обработки.

Compute Fleet против Virtual Machine Scale Sets Сегмент [[D]] в исходнике обрывается на слове «м…», поэтому я перевёл только видимую часть. Пришлите полный текст, и я переведу его целиком.

Частый вопрос, который задают инженеры при изучении этой технологии: чем Compute Fleet отличается от Azure Virtual Machine Scale Sets (VMSS)? Оба сервиса управляют группами виртуальных машин, но созданы для решения принципиально разных задач. Virtual Machine Scale Sets обычно начинаются с конкретного уровня приложения. Вы развёртываете веб-приложение, API на основе микросервисов или корпоративное приложение, работающее за балансировщиком нагрузки, и VMSS масштабирует количество идентичных экземпляров вверх или вниз в зависимости от входящего сетевого трафика или порогов загрузки ЦП. Compute Fleet, напротив, исходит из совершенно иной предпосылки: как быстро получить большой пул гибких вычислительных мощностей, чтобы справиться с горой распределённой работы?

Когда использовать Virtual Machine Scale Sets

Virtual Machine Scale Sets остаются безусловным стандартом для долгоработающих, непрерывных слоёв приложений, где экземпляры выполняют одинаковые роли и должны динамически реагировать на трафик пользователей. Идеальные сценарии включают клиентские веб-приложения, публичные API, интернет-магазины и серверные приложения за Azure LoadBalancer или Application Gateway. В таких средах главными проектными задачами становятся поддержание непрерывной работоспособности приложения, бесперебойная маршрутизация трафика клиентов и управление последовательными обновлениями операционной системы на одинаковых экземплярах.

Когда использовать Compute Fleet

И наоборот, Compute Fleet лучше всего проявляет себя, когда основная задача состоит в получении большого объёма вычислительных мощностей для асинхронных, пакетных или независимых задач. Типичные сценарии включают кластеры высокопроизводительных вычислений, пакетную обработку финансовых данных, моделирование молекулярных процессов, конвейеры приёма больших объёмов данных, автоматизированные наборы тестов, фермы рендеринга медиаконтента и временные пулы рабочих узлов. В таких архитектурах рабочий узел берёт отдельную единицу работы, обрабатывает её, записывает итоговый результат в постоянное хранилище и сразу переходит к следующей задаче. Если рабочий узел исчезает, система просто передаёт эту единицу работы другому доступному узлу.

Можно использовать оба варианта

Лучшее в современной облачной архитектуре то, что не нужно выбирать только один инструмент. Azure Compute Fleet и Virtual Machine Scale Sets не исключают друг друга; они могут гармонично работать вместе в рамках одной корпоративной экосистемы. Например, сложное корпоративное приложение может использовать Virtual Machine Scale Set для высокодоступного веб-фронтенда и API-слоя, обеспечивая безупречный пользовательский опыт. В то же время это приложение может в фоновом режиме развернуть Azure Compute Fleet для ресурсоёмкой ночной обработки данных в хранилищах, пакетного формирования отчётов или сложных симуляций. Выбирая подходящий инструмент для каждого уровня, вы создаёте архитектуру, которая одновременно очень отзывчива для пользователей и экономически эффективна в масштабе.

Чтобы глубже разобраться в этих архитектурах и получить практические советы по внедрению, обязательно послушайте наш полный сопутствующий выпуск подкаста: Azure Compute Fleet – Simply Explained. Не забудьте поддержать наше шоу и оставайтесь с нами, чтобы получать новые глубокие разборы облачной инженерии!

Стать поддержителем этого подкаста: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.