Сколько узлов резервной ёмкости AWS CodeBuild macOS нужно? Модель затрат предприятия 2026

📋 Содержание

Не покупайте резервную ёмкость AWS CodeBuild macOS по числу разработчиков: рассчитайте минимальный Fleet по пиковой скорости поступления задач, времени занятия узла, допустимой очереди и резерву на отказ. Если нагрузка стабильна и узлы большую часть рабочего окна заняты, оставляйте минимальный резервный парк; при редких релизах и длинных периодах простоя сначала проверяйте гибрид с эластичной арендой удалённого Mac.

Эта статья для вас, если вы обосновываете бюджет AWS CodeBuild macOS перед закупками или FinOps. Она также пригодится руководителю, который распределяет несколько iOS-проектов между общей ёмкостью, изолированным подписанием и аварийным контуром.

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

Главная ошибка в планировании — считать по формуле «один разработчик — один Mac-узел». Разработчик может запускать сборки редко, а один релизный pipeline способен занять несколько узлов подряд. Поэтому исходными данными должны быть события CI, а не штатное расписание.

Соберите за полный расчётный период:

время поступления каждой задачи;
время ожидания до старта;
фактическое время занятия macOS-узла;
результат сборки и факт повторного запуска;
тип задачи: pull request, ночной regression, TestFlight или production release;
проект, уровень доверия к коду и используемый signing profile;
доступ к приватным зависимостям, VPC и секретам.

AWS подтверждает, что ёмкость Fleet определяет количество сборок, которые могут выполняться параллельно, а параметры Fleet и тип вычислений задаются отдельно от конфигурации проекта. Это нужно учитывать при чтении документации AWS о свойствах reserved capacity Fleet и настройках среды проекта CodeBuild.

Входная таблица для расчёта

Входной параметр	Что выгрузить из CI	Как влияет на решение
Скорость поступления задач	События по временным окнам, особенно перед релизом	Показывает момент, когда очередь начинает расти
Время занятия узла	Старт и завершение каждой сборки	Определяет, сколько параллельных узлов требуется
Допустимое ожидание	SLO для pull request и release	Разделяет минимальный Fleet и комфортную ёмкость
Повторные запуски	Причина и время rerun	Показывает скрытый спрос, который нельзя списывать на разработчиков
Класс доверия	Обычная проверка, внутренний код, production signing	Определяет, можно ли объединять задачи в общий пул
Отказ узла	Недоступность, запуск замены, восстановление	Формирует аварийный резерв, а не только рабочий минимум

Для базового окна используйте переменные:

λ — максимальная скорость поступления задач в выбранном окне;
τ — среднее или выбранное консервативное время занятия узла;
q — допустимое число задач в очереди либо допустимое ожидание;
r — резерв на отказ, обслуживание и недоступность;
N — число узлов Fleet.

Упрощённая оценка рабочей ёмкости выглядит так:

Nрабочее ≥ λ × τ

Затем добавьте резерв:

Nминимум = округление вверх(Nрабочее + r)

Эта формула не заменяет анализ очереди. Она показывает нижнюю границу. Если λ резко меняется в течение дня, среднее значение скроет перегрузку. При одинаковом среднем объёме два проекта могут иметь совершенно разные расходы: один распределяет задачи равномерно, другой создаёт короткие очереди перед релизом.

Важно: средняя загрузка Fleet не доказывает, что ёмкость достаточна. Если очередь регулярно появляется в одном и том же временном окне, планируйте по этому окну, а не по среднему значению за период.

Рабочий день против релизного окна

AWS CodeBuild macOS нельзя автоматически рассматривать как обычную оплату фактически использованных минут. Согласно официальной странице тарифов CodeBuild, резервная ёмкость оплачивается во время её конфигурации, а для macOS действуют требования к минимальному периоду использования. Поэтому простаивающий узел остаётся статьёй затрат, даже если сборки приходят редко.

Это отвечает на частый вопрос о том, почему macOS-сборки не сводятся к простой оплате каждой фактической минуты. Сначала оплачивается доступная зарезервированная ёмкость, а затем нужно доказать, что она используется достаточно часто, чтобы оправдать постоянный расход.

Разделите поток на независимые сценарии:

pull request и обычные проверки;
ночные regression-запуски;
сборки для TestFlight;
production release;
повторные сборки после неудачной подписи или загрузки.

Не складывайте эти задачи в одно среднее число. Релиз может конкурировать с обычными проверками, но его требования к доверию, секретам и времени ожидания отличаются. Если production pipeline должен начать работу сразу, его нельзя считать обычным потребителем общей очереди только ради лучшей загрузки.

Сравнение вариантов покрытия пика

Вариант	Когда подходит	Сильная сторона	Скрытая цена или риск	Оценка
Постоянно держать дополнительные узлы	Релизы часты и предсказуемы	Простая операционная модель	Плата за простой между релизами	Высокая предсказуемость
Заранее менять размер Fleet	Пиковые окна известны заранее	Снижает длительность постоянного простоя	Нужны календарь, контроль запуска и время на изменение	Средняя сложность
Добавлять эластичный удалённый Mac	Пики редкие или возникают вне графика	Можно проверять спрос без постоянного Fleet	Нужно подтвердить Xcode, подпись, сеть и восстановление	Высокая гибкость
Смешанная схема	Есть стабильный базовый поток и отдельные релизы	Рабочая ёмкость не оплачивает весь пик	Появляются два контура наблюдения и поддержки	Лучший компромисс при переменной нагрузке

Сравнивайте не только стоимость узла. В модель входят время изменения Fleet, задержка запуска, ручное вмешательство, стоимость неуспевшего релиза и труд инженера, который устраняет сбой в пиковое окно. Конкретные суммы берите из действующей официальной тарифной таблицы AWS CodeBuild и собственного биллинга, а не из старого примера в блоге.

Общий Fleet против разделения проектов

Общий Fleet может повысить загрузку, но общая очередь не означает полную изоляцию. Очистка рабочей директории удаляет артефакты проекта, однако не гарантирует удаление глобального состояния, Keychain, кэшей, временных credentials и иных следов предыдущего задания.

Поэтому сначала назначьте проектам уровни доверия:

Обычная проверка — код и секреты ограниченного риска, нет production signing.
Доверенная сборка — внутренние репозитории, приватные зависимости и доступ к корпоративной сети.
Производственный выпуск — сертификаты, provisioning profile, ключи загрузки и право отправить результат в магазин.
Аварийная сборка — отдельные права, короткий список пользователей и проверяемый журнал действий.

Несколько iOS-проектов могут использовать один CodeBuild Mac Fleet, если совпадают требования к сети, образу, версии Xcode, кэшам и уровню доверия. Для production signing, разных владельцев секретов или конфликтующих версий инструментов общее размещение становится не оптимизацией, а дополнительным риском.

AWS описывает управление доступом через IAM в документации по identity-based policies для CodeBuild. Но IAM не заменяет изоляцию самого macOS-окружения. Он ограничивает вызов API и права, а не делает глобальное состояние узла автоматически чистым после каждой сборки.

Стоимость общей ёмкости

Модель	Что считается базовой затратой	Что нужно добавить в модель	Когда разделение оправдано
Один общий пул	Зарезервированный Fleet	Очистка, аудит, контроль кэшей, влияние сбоя на все проекты	Проекты имеют сопоставимый риск и одинаковую среду
Общий пул плюс доверенный контур	Базовый Fleet и отдельные узлы выпуска	Простой выделенного пула и управление маршрутами задач	Production signing нельзя смешивать с обычными PR
Отдельный Fleet на проект	Ёмкость каждого проекта	Суммарный простой и обслуживание нескольких контуров	Разные версии Xcode, сети, владельцы секретов
Рабочий Fleet плюс эластичный резерв	Минимальный постоянный Fleet	Проверка внешнего Mac, передача артефактов и аварийные процедуры	Основная нагрузка стабильна, релизы редки или скачкообразны

При расчёте общей модели учитывайте не только процент загрузки. Добавьте стоимость инцидента, если загрязнённый Keychain или неправильный кэш приводит к повторной сборке, отзыву credentials или ручной проверке артефакта.

Приватная сеть и production signing как отдельный пул

VPC-доступ, внутренние зависимости и Secrets Manager меняют границы Fleet. Узел может быть технически свободен, но непригоден для конкретной задачи, если у него нет маршрута к приватному репозиторию или требуемого разрешения.

Разделите минимум на два пула:

пул проверки — pull request, обычные тесты, задачи с ограниченными секретами;
доверенный пул — production signing, загрузка релиза, доступ к внутренним сервисам и операциям с чувствительными ключами.

Для каждого пула отдельно определите:

допустимое ожидание;
рабочую минимальную ёмкость;
резерв на отказ;
правила запуска повторной сборки;
владельца разрешений;
процедуру удаления или отзыва credentials.

Проверьте, какие ограничения возникают при доступе через прокси и к приватным ресурсам: официальное описание managed proxy в CodeBuild нельзя заменять предположением, что любой внешний Mac будет иметь такую же сетевую достижимость.

Ту же проверку проведите для версии Xcode и runtime. Поддерживаемые среды нужно сверять по списку доступных runtime CodeBuild, а не только по названию macOS в проекте. Если нужная версия или инструмент не воспроизводится, низкая цена резервного узла не компенсирует ручную работу по восстановлению pipeline.

Отказ одного узла против непрерывной поставки

Один узел может быть достаточен для редкого потока, но он не одновременно выполняет сборки, проходит обслуживание и переживает отказ без очереди. В модель нужно включить:

время, пока Fleet недоступен;
задержку запуска или замены;
незавершённые задачи;
повторный checkout и восстановление кэшей;
проверку подписи после восстановления;
процедуру возврата к рабочему маршруту.

Не называйте целевое время восстановления без записи из вашей среды. Возьмите его из журналов CI, отчётов об инцидентах и результатов восстановления. Если таких данных нет, проведите контролируемое упражнение и отдельно зафиксируйте время обнаружения, принятия решения и фактического запуска сборки.

Региональные ограничения и доступность вычислительных типов также нужно проверять по документации AWS о Fleet, регионах и типах вычислений. Не переносите конфигурацию из одного региона в другой как готовую гарантию.

Пошаговый порядок расчёта

Экспортируйте очередь и историю сборок из AWS CodeBuild за репрезентативный период.
Разметьте каждую задачу по проекту, типу pipeline, уровню доверия и сетевым требованиям.
Постройте временные окна поступления задач и выделите самое загруженное окно, а не только среднюю нагрузку.
Рассчитайте λ × τ для обычных проверок и отдельно для релизных задач.
Добавьте резерв r, опираясь на реальные отказы, обслуживание и требование непрерывной поставки.
Проверьте, какие проекты могут делить Fleet без смешения ключей, кэшей и приватных маршрутов.
Сопоставьте минимальный Fleet с вариантом заранее менять ёмкость и с внешним эластичным Mac.
Запустите PoC на реальном Xcode-проекте: подпись, тесты, загрузка артефакта и восстановление после сбоя должны пройти одинаково.
Зафиксируйте бюджетные переменные в отдельной таблице и назначьте дату повторной проверки.

Условия выбора: резервировать, расширять или переходить к гибриду

Используйте следующие ветвления, а не универсальное правило:

Если пик повторяется регулярно, задачи поступают равномерно, а рабочая загрузка Fleet стабильно оправдывает постоянную плату — выбирайте минимальную резервную ёмкость с документированным отказоустойчивым запасом.
Если основная очередь стабильна, но релизы создают короткие всплески — оставляйте базовый Fleet и проверяйте эластичную аренду удалённого Mac для пиков.
Если большая часть периода проходит без задач, а очередь возникает только перед редкими релизами — не добавляйте постоянные узлы до проведения PoC.
Если разные проекты требуют разных signing permissions, приватных сетей или несовместимых версий Xcode — разделяйте пулы, даже если общий Fleet выглядит дешевле.
Если фактическое ожидание уже нарушает целевой уровень, сначала увеличьте доступную параллельность или измените маршрут задач; не объясняйте проблему только числом разработчиков.
Если резервный контур не прошёл реальную сборку, подпись, загрузку и восстановление — считайте его неподтверждённым, независимо от заявленной доступности.

Порог замены схемы задаётся не одной цифрой загрузки. Смотрите на устойчивую комбинацию сигналов: очередь выходит за целевой предел, Fleet простаивает в большинстве рабочих окон, меняется состав проектов, растёт число изолированных signing-задач или обновляется Xcode. Эти условия пересматривайте ежеквартально и после каждого существенного изменения CI.

Для низкочастотных задач полезно сравнить не только AWS CodeBuild, но и аренду удалённого Mac по циклу, который совпадает с релизной активностью. В обзоре тарифов bare-metal macOS вы можете использовать отдельный сценарий для проверки срока аренды, доступа и требований к реальному Mac. Это не готовая замена Fleet: совместимость с вашим signing-процессом, сетью и восстановлением нужно доказать самостоятельно.

Если вы сравниваете физический узел и виртуализацию, сначала проверьте ограничения доступа, изоляции и производственного pipeline в разборе bare-metal и виртуализации macOS. Для корпоративного PoC оценивайте не обещание «быстрее», а долю успешно завершённых сборок, время передачи артефакта и работу с ключами.

В текущей схеме AWS CodeBuild macOS вы платите за зарезервированную ёмкость даже тогда, когда релизов нет, зависите от границ конкретного Fleet и должны самостоятельно поддерживать правила разделения проектов, сетей и подписей. Она остаётся разумной для стабильной нагрузки, но хуже подходит для редких пиков, частых изменений Xcode и сценариев, где постоянный узел простаивает. В такой ситуации аренда Mac через MacDate может дать более подходящий экспериментальный контур: вы проверяете реальный Xcode pipeline и расширяете мощность на нужный цикл, не превращая редкий пик в постоянную статью Fleet-бюджета.

Начните с выгрузки очереди, времени занятия узлов и истории повторных запусков за месяц. Подставьте значения в формулы и сценарную таблицу, затем проведите PoC только для тех релизных задач, которые действительно могут уйти на удалённый Mac. Такой порядок позволит решить, нужен ли вам постоянный резерв AWS CodeBuild macOS, смешанная ёмкость или отдельный контур аренды без оплаты простаивающих узлов.