Проектирование оптимизации использования
 Максимальное использование ресурсов и операций. Примените их к согласованным функциональным и нефункциональным требованиям решения. |
|---|
Службы и предложения предоставляют различные возможности и ценовые категории. После приобретения набора функций не используйте их. Найдите способы максимально эффективного увеличения инвестиций на уровне. Аналогичным образом, непрерывно вычисляйте модели выставления счетов, чтобы найти те, которые лучше соответствуют использованию на основе текущих рабочих нагрузок.
Пример сценария
В настоящее время Университет Contoso размещает коммерческое решение вне полки (COTS), которое позволяет преподавателям университета создавать и обновлять курсы для учебного года и является основным порталом регистрации, используемым студентами для этих курсов. Решение имеет настраиваемую интеграцию с системой управления обучением как услуга (SaaS), в которой они надеются в конечном итоге перенести все свои функции в течение нескольких лет. В то же время они хотят оптимизировать затраты на пользовательские компоненты интеграции.
Технологическое решение ПРЕДЛОЖЕНИЯ COTS обычно рассматривается как черное поле, за исключением базы данных, которая База данных Azure для MySQL. Настраиваемая интеграция — это устойчивая функция Azure, которая запускается в рамках плана обслуживания уровня "Стандартный" в службе приложение Azure. Этот Служба приложений ранее размещал веб-сайт университета, но это больше не так. Эта устойчивая функция — это приложение Python, поддерживаемое выделенной учетной записью служба хранилища Azure, которая выполняет ночную синхронизацию из базы данных MySQL в API SaaS.
Использование цен на основе потребления, когда это практически
Могут быть службы, которые предлагают цены на основе потребления, что означает, что вам выставляются только счета за использование службы, и вы можете завершить работу службы, если она не требуется для прекращения расходов. Если у вас есть компоненты рабочей нагрузки, которые используются только периодически, это может помочь свести к минимуму затраты по сравнению с оплатой компонента для запуска 24/7/365.
Используя цены на основе потребления, вы оплачиваете только то, что вы используете. Этот вариант является хорошим выбором, если вычислительную нагрузку не будут использовать полный рабочий день.
Задача Компании Contoso
- Задание синхронизации обычно выполняется около часа каждую ночь в определенное время. Производительность его исторически была удовлетворительной. Ошибки являются редкими и временными сбоями обрабатываются хорошо в текущей конфигурации.
- Так как вычислительные ресурсы, необходимые для задания синхронизации, используются только в час в день, и они платят за 24 часа независимо от использования, команда рабочей нагрузки заинтересована в альтернативе текущему проектированию.
- Команда рассмотрела написание сценария для завершения работы службы каждую ночь после выполнения синхронизации и повторного развертывания ее на следующий день, но это решение будет иметь высокую степень риска и сложности.
Применение подхода и результатов
- Команда анализирует журнал заданий и находит, что самая длинная функция, когда-либо запущенная, была чуть менее двух часов. Они сравнивают стоимость выделенного плана с стоимостью плана Функции Azure потребления для наихудшего сценария и заключают, что план потребления будет менее дорогим.
- Команда запускает тест производительности, чтобы обеспечить достаточную производительность, и они замечают небольшое увеличение времени выполнения, но это по-прежнему в допустимых ограничениях.
- Общая стоимость рабочей нагрузки уменьшается с помощью плана потребления, так как они несут только затраты при выполнении задания.
Оптимизация проектирования высокой доступности
Определите приоритет развертывания активно-активных или активных только над активными пассивными моделями в рамках плана восстановления, если вы уже заплатили за ресурсы.
Если ваша конструкция по умолчанию использует активные пассивные модели, может потребоваться простой ресурс, который может использоваться в противном случае. Преобразование в активный режим может позволить вам соответствовать требованиям по выравниванию нагрузки и масштабированию, не перерасписываясь. Если вы можете выполнить целевые показатели восстановления с помощью активной модели, затраты на эти ресурсы можно полностью удалить.
Задача Компании Contoso
- Приложение COTS использует гибкий сервер База данных Azure для MySQL, настроенный для обеспечения высокого уровня доступности той же зоны, которая предоставляет резервный сервер в той же зоне доступности, что и основной сервер. Они также включили автоматические резервные копии.
- RPO рабочей нагрузки относительно длинный в 12 часов, и RTO составляет три часа в течение учебного дня.
- На основе предыдущих тестов восстановления команда знает, что они могут соответствовать целевым объектам RPO и RTO с помощью автоматической отработки отказа на резервный сервер. Они также проверили восстановление базы данных из резервной копии, и они могут соответствовать целевым объектам в этом сценарии.
Применение подхода и результатов
- Команда рабочей нагрузки повторно оценивает преимущества проектирования высокой доступности и стоимость службы в два раза больше, чем один экземпляр.
- Команда проверяет создание нового экземпляра и восстановление базы данных из резервной копии, и они удовлетворены тем, что они по-прежнему будут соответствовать целевым объектам восстановления, поэтому они решили исключить резервный экземпляр.
- Команда обновляет план аварийного восстановления, чтобы отразить новую стратегию восстановления и реализовать экономию затрат с помощью новой конфигурации.
Защита облачной среды от неиспользуемых ресурсов и данных
Регулярно и строго просматривайте развертывания для неиспользуемых ресурсов и данных и их вывода из эксплуатации. С течением времени ресурсы и данные, которые были необходимы для некоторых целей в прошлом, но больше не используются, могут задерживаться в облачных средах и ненужные расходы. Будьте бдительными в отношении поддержания чистоты сред, чтобы помочь оптимизировать затраты на эффективность.
Завершение работы неиспользуемых ресурсов и удаление данных, когда вам больше не нужны, уменьшается количество отходов и освобождает средства, чтобы вы могли инвестировать их в других местах.
Задача Компании Contoso
- Университет исторически принял консервативный подход к выводу решений, опасаясь, что им может потребоваться отменить изменения до предыдущей конфигурации. Эта осторожность привела к отказу от служб, работающих в одной или нескольких средах в течение нескольких месяцев, которые были забыты в некоторых случаях.
- При обнаружении заброшенных служб обычно это происходит случайно, так как нет официального процесса для проверки окружающей среды для таких служб.
Применение подхода и результатов
- Команда добавляет списание Служба приложений в невыполненную работу в рамках миграции из Служба приложений в размещение потребления для устойчивой функции. В рамках следующего спринта они завершат работу Служба приложений развертываний во всех средах.
- Чтобы помочь в упреждающем обнаружении заброшенных ресурсов, команда настраивает оповещения в Помощнике По Azure, чтобы уведомить их об неиспользуемых ресурсах.
- Команда реализует новую политику, которая требует от команды выполнять ежемесячные полные проверки предварительной среды и квартальные полные проверки рабочей среды для выявления заброшенных ресурсов. Все брошенные ресурсы будут добавлены в невыполненную работу для вывода из эксплуатации.