Компромиссы по эффективности производительности

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

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

Компромиссы эффективности производительности с надежностью

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

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

Компромисс: повышенная сложность. Надежность определяет простоту.

Использование автомасштабирования для балансировки поставок рабочей нагрузки по требованию приводит к изменчивости в топологии рабочей нагрузки и добавляет компонент, который должен работать правильно, чтобы система была надежной. Автомасштабирование приводит к активации дополнительных событий жизненного цикла приложения, таких как запуск и остановка.
Секционирование и сегментирование данных помогают избежать проблем с производительностью в больших или часто доступных наборах данных, но они повышают сложность, так как (в конечном итоге) согласованность должна поддерживаться между дополнительными ресурсами.
Денормализация данных для оптимизированных шаблонов доступа может повысить производительность, но она представляет сложность, так как необходимо синхронизировать несколько представлений данных.
Шаблоны облачной разработки, ориентированные на производительность, иногда требуют внедрения дополнительных компонентов. Использование этих компонентов увеличивает область поверхности рабочей нагрузки. Затем компоненты должны быть надежными, чтобы обеспечить надежность всей рабочей нагрузки. Вот некоторые примеры.
- Шина сообщений для выравнивания нагрузки, которая вводит критически важный компонент с состоянием.
- Подсистема балансировки нагрузки для автомасштабируемых реплик, для которой требуется надежная работа и учет реплик.
- Разгрузка данных в кэши, для которой требуются надежные подходы к инвалидации кэша.

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

Тестирование производительности в активных средах, например использование синтетических транзакций, несет риск возникновения сбоев из-за действий или конфигураций теста.
Рабочие нагрузки должны быть инструментированы с помощью системы мониторинга производительности приложений (APM), которая позволяет командам учиться в активных средах. Средства APM устанавливаются и настраиваются в коде приложения или в среде размещения. Неправильное использование, превышение ограничений или неправильное настройку средства может скомпрометирует его функциональные возможности и обслуживание, что может привести к нарушению надежности.

Компромиссы производительности с безопасностью

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

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

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

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

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

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

Компромисс: удаление сегментации. Компонент безопасности определяет высокий уровень сегментации, чтобы обеспечить точное управление безопасностью и уменьшить радиус взрыва.

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

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

Компромисс: устаревшее состояние безопасности. Столп безопасности требует, чтобы решения об авторизации, содержимом и доверии отражали текущее состояние системы.

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

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

Компромиссы производительности с оптимизацией затрат

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

Чрезмерное распределение ресурсов — это риск, когда команды пытаются смягчить проблемы с производительностью в нагрузке. Ниже приведены некоторые распространенные причины чрезмерного резервирования:
- Первоначальное планирование емкости было неправильно оценено из-за того, что команда сосредоточилась только на оценках пиковой нагрузки, игнорируя стратегии пикового сглаживания при проектировании рабочих процессов.
- Масштабирование ресурса вверх или вширь на этапе устранения неполадок при реагировании на инцидент.
Автомасштабирование может быть неправильно настроено. Ниже приведены некоторые примеры неправильно настроенного автомасштабирования:
- Масштабирование при незначительных колебаниях спроса или продолжительном периоде стабилизации может обойтись дороже, чем требует спрос.
- Использование автомасштабирования без заданного верхнего предела может привести к неконтролируемму росту из-за сбоев системы или злоупотреблений и превышения ожидаемых требований к рабочей нагрузке.
Расширение в нескольких регионах может повысить производительность путем приближения рабочих нагрузок к пользователю и может избежать временных ограничений емкости ресурсов. Однако эта топология также добавляет сложность и дублирование ресурсов.

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

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

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

Службы уровня "Премиум" и номера SKU могут помочь рабочей нагрузке достичь целевых показателей производительности. Обычно эти службы стоят больше и могут предоставлять дополнительные функции. Они могут быть недоиспользованы, если многие из функций премиум не используются для достижения целевых показателей производительности.
Эффективная рабочая нагрузка требует данных телеметрии для обеспечения наблюдаемости, которые должны быть переданы и сохранены. Увеличение объема собираемой телеметрии производительности может привести к увеличению затрат на передачу и хранение телеметрических данных.
Действия по тестированию производительности добавляют затраты, которые не связаны со значением рабочей системы. Ниже приведены примеры затрат на тестирование производительности:
- Создание экземпляров сред, предназначенных для тестов, ориентированных на производительность.
- Использование специализированных средств повышения производительности.
- Затрата времени на выполнение тестов.
Обучение членов команды для выполнения специализированных задач по оптимизации производительности или оплата услуг по настройке производительности увеличивает стоимость рабочей нагрузки.