Рекомендации по оптимизации затрат для устойчивых рабочих нагрузок на Azure

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

В этой статье устойчивость рассматривается с точки зрения компонента оптимизации затрат, а также даются ответы на следующие вопросы проектирования:

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

Сделать затраты видимыми и доступными для действий

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

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

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

Recommendation Преимущество устойчивости
Отслеживайте затраты на уровне компонента или рабочей нагрузки, а не только на уровне инфраструктуры. Упрощает выявление и устранение скрытых неэффективностей.
Используйте сигналы затрат в качестве одного входного значения для измерения устойчивости. Создает практическую основу для измерения улучшения с течением времени.
Определите явные базовые показатели эффективности для критически важных систем. Помогает командам выявлять отклонения до того, как неэффективные модели работы войдут в норму.
Рассматривайте затраты на наблюдаемость как часть процесса оптимизации. Ограничивает рост объёма журналирования и телеметрии, который приводит к затратам, не принося достаточной пользы.
Назначьте ответственность за затраты на уровне рабочей нагрузки. Рекомендует сквозную оптимизацию вместо изолированных локальных исправлений.
Ставьте под сомнение локальные оптимизации, которые перекладывают затраты в другое место. Повышает эффективность всей системы, а не перемещает отходы между командами.

Сокращение структурных отходов на уровне приложений

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

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

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

Recommendation Преимущество устойчивости
Сократите избыточную частоту обращений к API, размер передаваемых данных и количество ненужных повторных вызовов. Снижает избегаемый спрос на вычислительные ресурсы и сетевую передачу.
В первую очередь оптимизируйте алгоритмы и пути выполнения в коде, на который приходится основная часть затрат времени выполнения. Уменьшает базовое потребление ЦП и памяти, где это важно.
Кэшируйте ответы, которые повторяются, предсказуемы или требуют больших затрат на повторную генерацию. Предотвращает повторные вычисления, которые не приносят дополнительной пользы.
Будьте осторожны при добавлении абстракций на критически важных для производительности участках кода. Ограничивает затраты на выполнение и затраты на координацию в горячих путях.
Выберите монолитные или микрослужбы на основе реальных потребностей масштабирования и изоляции. Избегает затрат на распределенную систему, которая не улучшает результаты рабочей нагрузки.
Оцените варианты SSR и CSR в отношении общего объема вычислительных ресурсов и передачи данных. Сокращает избыточную работу по отрисовке и ненужное перемещение данных.
По возможности удалите дублирование данных между службами и избыточные модели домена. Ограничивает увеличение объема хранилища и увеличение вычислительных ресурсов в системе.

Сокращение простоя и базовых отходов платформы

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

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

Эти шаблоны легко пропустить, так как система по-прежнему выглядит здоровой. Значительную часть затрат становится привязанной к неактивности, избыточности или размеру по умолчанию, а не полезной работе.

Recommendation Преимущество устойчивости
Автоматически масштабируйте рабочие нагрузки в соответствии с фактическим спросом, а не предполагаемой пиковой нагрузкой. Сокращает постоянное избыточное выделение ресурсов и неиспользуемые мощности.
Отключайте или уменьшайте масштаб непроизводственных сред, когда они не нужны. Удаляет базовое потребление, которое не обеспечивает бизнес-ценность.
Регулярно удаляйте неиспользуемые и зомби-ресурсы. Предотвращает незаметное накопление расходов из-за забытой инфраструктуры.
Сопоставление уровней платформы и резервирований с фактическими шаблонами использования. По умолчанию позволяет избежать затрат на избыточную инфраструктуру.
Предпочитайте контейнеры, PaaS или бессерверные, если они соответствуют рабочей нагрузке. Улучшает использование, опираясь на более эффективную общую емкость платформы.
Используйте точечные виртуальные машины только в том случае, если прерывание допустимо и восстановление понято. Эффективно использует свободные облачные ресурсы, не создавая предотвратимых операционных рисков.
Оптимизируйте конвейеры CI/CD с помощью кэширования, повторного использования и добавочных сборок. Сокращает избыточное выполнение вычислений в рабочих процессах проектирования.

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

Намеренное использование географии и времени

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

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

Например, команды иногда используют однородные развертывания между регионами и фиксированными окнами выполнения, так как эти значения по умолчанию удобны для работы. Это упрощение может быть по стоимости ненужного использования ресурсов и более высоких затрат на передачу и вычислительные расходы.

Recommendation Преимущество устойчивости
Учитывайте регионы с более низким уровнем выбросов углерода при принятии решений о размещении рабочих нагрузок. Может сократить выбросы на единицу вычислительной мощности, если другие требования по-прежнему выполняются.
Планируйте пакетные задачи так, чтобы выполнять их в периоды с меньшей углеродной интенсивностью или более низкой стоимостью. Выравнивает гибкие вычисления с более чистыми или более эффективными операционными окнами.
Размещайте рабочие нагрузки ближе к пользователям, если это оправдано требованиями к задержке и характером передачи данных. Уменьшает сетевое расстояние, задержку и ненужные затраты на передачу.
Избегайте маршрутизации и репликации между регионами, которые не требуют четкой рабочей нагрузки. Снижает нагрузку на сеть и повторяющиеся действия инфраструктуры.
Переоценка вариантов регионального развертывания в отношении фактического использования с течением времени. Предотвращает превращение решений о статическом размещении в источник долгосрочной неэффективности.

Ограничить усиление маршрута доставки

Стоимость сети часто недооценивается, так как она распространяется на множество небольших взаимодействий, а не сосредоточена в одной очевидной системе. Тем не менее каждый дополнительный запрос, передача полезных данных или вызов между службами предоставляет скрытые затраты на вычисления и маршрутизацию.

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

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

Recommendation Преимущество устойчивости
Используйте CDN для контента, к которому многократно обращаются в больших масштабах. Снижает потребность в вычислительных ресурсах исходного сервера и повторной передаче данных по сети.
Сжимайте полезную нагрузку и с осторожностью выбирайте формат передачи. Снижает потребление пропускной способности без изменения бизнес-результатов.
Уменьшите межсервисные цепочки вызовов и ветвление запросов при одном действии пользователя. Предотвращает усиление запросов, увеличивающее нагрузку на серверную часть.
Сохраняйте трафик в пределах региональных границ, когда архитектура разрешает ее. Избегает дорогой и ненужной маршрутизации между регионами.
Размещайте рабочие нагрузки ближе к пользователям, если это оправдано характером доставки. Сводит к минимуму расстояние передачи и помогает управлять издержками, связанными с задержкой.
Централизуйте обработку медиаданных, если иначе те же преобразования пришлось бы выполнять повторно. Сокращает повторяющиеся операции кодирования и преобразования на платформе.

Контроль роста хранилища с течением времени

Системы хранения, как правило, растут независимо от фактической бизнес-ценности, так как удаление требует намеренного усилий, пока хранение является пассивным.

Журналы, резервные копии, промежуточные наборы данных и исторические артефакты часто остаются долго после снижения их полезности. Без активного управления хранилище становится долгосрочным источником как затрат, так и экологической нагрузки.

Дублирование усугубляет проблему. Один и тот же набор данных часто копируется между службами или конвейерами для удобства, что приводит к ненужному росту объема памяти и вычислительной обработки.

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

Поддерживайте соразмерность инженерных процессов

Рабочие процессы проектирования могут стать скрытым источником постоянных отходов, когда они масштабируются независимо от фактического изменения кода. Сборки, тесты и развертывания часто выполняются в полном объеме, даже если только небольшая часть системы изменилась. Со временем CI/CD становится основным центром затрат, хотя большая часть вычислительных ресурсов не улучшает качество или скорость доставки.

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

Recommendation Преимущество устойчивости
Динамически масштабируйте ресурсы CI/CD вместо того, чтобы постоянно держать мощности доступными. Предотвращает простой вычислительных ресурсов между инженерными задачами.
Агрессивно кэшируйте артефакты сборки там, где их можно надёжно использовать повторно. Избегает повторяющихся вычислений для без изменений входных данных.
Запустите тесты для измененных компонентов, если выполнение полного набора не требуется. Снижает вычислительные затраты на валидацию, которая дает мало полезной информации.
Внедряйте стратегии инкрементальной сборки там, где инструменты хорошо их поддерживают. Ограничивает ненужную перекомпьютерацию полной системы.
Удалите избыточные этапы конвейера и повторяющиеся проверки. Снижает общий объем вычислительных ресурсов рабочих процессов доставки.
Не применяйте постоянное тестирование всего набора, если уровень риска этого не оправдывает. Снижает базовую стоимость CI/CD, не устраняя значимую валидацию.
  • Last updated on