Вычисления для рабочих нагрузок SaaS в Azure
Ваше программное обеспечение как услуга (SaaS) должно выполняться на вычислительной платформе. Как и другие компоненты в архитектуре, он должен соответствовать бизнес-требованиям и быть разработан в соответствии с бизнес-моделью. Выбор вычислительной платформы является значительным решением по проектированию. Ваше решение влияет на изоляцию клиентов, производительность и устойчивость, а ваша вычислительная платформа влияет на масштабирование и увеличение масштаба всего решения SaaS.
В этой статье описываются рекомендации по выбору модели размещения, операционных аспектов этой модели и оптимизации параметров технологий, которые помогут вам выполнить соглашения об уровне обслуживания и цели уровня обслуживания (SLOS).
Выбор вычислительной платформы
Выбор подходящей вычислительной платформы для рабочей нагрузки SaaS важен, но множество доступных вариантов может сделать выбор подавляющим. Оптимальная платформа зависит от таких факторов, как архитектура приложения, масштабирование, потребности в производительности и модель изоляции клиента. То, что оптимально для одного приложения, может быть не для другого.
Рекомендации по проектированию
Модель размещения. Azure предлагает различные модели размещения, в первую очередь инфраструктура как услуга (IaaS) и платформа как услуга (PaaS), каждая из которых имеет собственные преимущества и компромиссы. Оцените требования приложения и выберите наиболее подходящую модель.
IaaS предоставляет виртуальные машины (виртуальные машины) и полный контроль над ними, включая сети и хранилище. Однако для этого требуется управление и исправление, которое может быть трудоемким. Примерами являются масштабируемые наборы виртуальных машин и кластеры Служба Azure Kubernetes (AKS).
PaaS позволяет развертывать приложения без управления базовой инфраструктурой. Она включает встроенные функции для автомасштабирования и балансировки нагрузки. Примерами являются служба приложение Azure и приложения контейнеров Azure.
Службы PaaS обеспечивают меньший контроль по сравнению с IaaS, что может быть проблематично, если ваше приложение нуждается в конкретной конфигурации. Например, приложение может работать в операционной системе, которая не поддерживается службой PaaS.
Тип рабочей нагрузки. Некоторые платформы предназначены для конкретных рабочих нагрузок, а другие — универсальными. Например, Служба приложений предназначены для веб-приложений, а AKS — более общего назначения. Он может размещать веб-приложения, рабочие нагрузки ИИ и пакетные вычислительные задачи.
Разработка опыта команды. Большие изменения могут быть сложными, если команда не имеет опыта работы с новой платформой. Оцените навыки вашей команды и сопоставите их с требованиями к платформе. Начните с простой платформы и постепенно развивайте свою архитектуру, а не переходя прямо к более расширенному варианту.
Например, если вы создаете контейнерное приложение, начните с приложений-контейнеров для простого управления. По мере того как ваши потребности становятся более сложными, вы можете перейти на AKS, когда вы получите лучшее понимание платформы с течением времени.
Затраты на управление. Вычислительные платформы балансируйте нагрузку и управление. Больше ответственности по управлению отошел от вашей команды означает меньше контроля над платформой.
Например, IaaS обеспечивает высокий контроль над виртуальными машинами, но имеет значительные затраты. Если приложение развернуто в среде клиента, возможно, у вас ограниченный доступ к операциям управления. Оцените, являются ли эти компромиссы приемлемыми и допустимыми.
Требования к производительности. Ознакомьтесь с требованиями к производительности приложения, моделируя ЦП, память, сеть, включая пропускную способность и задержку, GPU и потребности доступности. Вы также должны рассмотреть будущий рост. Используйте эти сведения для выбора соответствующих вычислительных ресурсов, таких как ряд и размер виртуальных машин. Вам также может потребоваться выбрать определенные регионы, поддерживающие определенные серии виртуальных машин для удовлетворения специализированных требований.
Требования к надежности. Рассмотрим функции надежности вашей вычислительной платформы и убедитесь, что они соответствуют целевым показателям надежности. Может потребоваться использовать определенные уровни служб, чтобы иметь несколько экземпляров решения или развертывать между зонами доступности для повышения надежности.
Рекомендации RE:04 по определению целевых показателей надежности.
Безопасность и соответствие приложений. Оцените функции безопасности и сертификаты соответствия каждой вычислительной платформы , чтобы убедиться, что они соответствуют вашим потребностям. Например, если необходимо отслеживать исходящий трафик и фильтровать исходящий трафик, может потребоваться выбрать определенные вычислительные службы или уровни.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Оцените требования к производительности вычислений путем оценки измерений масштабирования ЦП, памяти, сети и GPU. Выполните нагрузочное тестирование, чтобы собрать более точные данные, чтобы сообщить о упражнении моделирования. |
Эти задачи помогают выбрать соответствующий размер для вычислительной платформы и масштабировать соответствующим образом при увеличении нагрузки на систему. |
| Оцените навыки вашей команды и начните с наименее сложной платформы, которая соответствует вашим потребностям или той, с которую команда уже знакома. | Вы гарантируете более гладкие операции и избегаете переполнения команды, выбрав вычислительную платформу, с которыми они знакомы. |
| Будьте гибкими в своем дизайне. Стремитесь к решению, которое можно выполнять с течением времени, чтобы адаптироваться к изменяющимся бизнес-требованиям и техническим требованиям. | Гибкость позволяет более легко адаптироваться к изменениям и улучшениям с течением времени. Вы можете эффективно реагировать на развитие бизнес-и технических потребностей. |
| Оцените общую стоимость владения (TCO), включая затраты на эксплуатацию решения. | У вас есть четкое представление о затратах, что имеет решающее значение для планирования модели ценообразования и обеспечения экономичных операций. |
| Оцените, нужно ли использовать определенные вычислительные платформы из-за стека технологий. Некоторые вычислительные платформы лучше подходят для определенных языков программирования, инструментов и операционных систем. Старайтесь использовать платформы, которые изначально поддерживают выбор технологий. | Вы избегаете изменения архитектуры, которая может включать миграцию на новую платформу. |
| Оцените функции надежности платформы и фактор гарантий поставщика облачных служб в ваших SLO. | Вы снижаете риск сбоев локализованных центров обработки данных, планируя функции надежности и используя зоны доступности, если они доступны. |
Модель аренды и изоляция
Бизнес-модель SaaS определяет, размещаете ли ресурсы для клиентов или управляете ими в среде клиента. Большинство поставщиков SaaS размещают ресурсы от имени своих клиентов, что обеспечивает гибкость в проектировании вычислительной платформы. Эффективно изолируйте рабочие нагрузки клиентов для оптимизации экономичности без ущерба для взаимодействия с клиентом или производительности.
Рекомендации по проектированию
Планирование модели аренды. Модель аренды определяет общий доступ к ресурсам между клиентами и влияет на бизнес-модели и модели ценообразования. Модели с одним клиентом имеют более высокие затраты по сравнению с полностью мультитенантными моделями. Ваши цены должны отражать эти различия.
Требования клиента. У некоторых клиентов могут быть определенные потребности в местонахождении данных, гарантии производительности или соответствие требованиям безопасности. Если эти требования требуют более высоких уровней изоляции, чем обычно, рассмотрите способ отражения повышенных затрат в бизнес-модели.
Шумная проблема соседа. Помните о шумной проблеме соседа при совместном использовании ресурсов между клиентами. Вычислительные ресурсы затрагиваются чаще всего. Дополнительные сведения см. в статье "Шумный сосед антипаттерн".
При выборе модели аренды сбалансируйте экономию ресурсов на совместном использовании ресурсов с необходимостью гарантировать производительность клиентов. Чрезмерное предоставление общего доступа к ресурсам или разрешение чрезмерного потребления может снизить уровень взаимодействия с клиентом.
Компромисс: производительность и стоимость. Совместное использование ресурсов среди клиентов может быть экономичным, но если некоторые клиенты используют больше ресурсов, чем ожидалось, этот подход может снизить производительность для других. Чтобы предотвратить это, реализуйте надлежащее управление ресурсами, чтобы гарантировать, что использование клиента остается в пределах ожидаемых ограничений.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Оцените функции изоляции вычислительной платформы, чтобы обеспечить соответствие требованиям модели аренды. | Прежде всего необходимо избежать повторной работы платформы, убедившись в критической конфигурации. |
| Применение модели изоляции. Будьте осторожны с общими ресурсами, такими как локальные кэши дисков, системная память и внешние кэши, так как они могут непреднамеренно утечки данных между клиентами, если они не управляются должным образом. Для обеспечения высоких требований к изоляции необходимо обеспечить изоляцию в вычислительной платформе и в приложении. |
Надежная изоляция снижает риск утечки данных между клиентами, серьезного инцидента безопасности. |
| Реализуйте управление ресурсами и мониторинг с видимостью метрик на уровне клиента. Заранее отслеживайте потребление ресурсов каждого клиента для обнаружения и устранения шумных проблем соседей. |
Вы не будете влиять на другие клиенты, отслеживая потребление ресурсов и уменьшая проблемы рано. |
Настройка масштабируемости и экономичности
Клиенты могут использовать приложение с различными профилями производительности. Они ожидают, что приложение будет обрабатывать растущие требования пользователей, крупномасштабные данные и сложные рабочие нагрузки без ущерба для скорости и производительности. Архитектура системы должна обеспечить масштабируемость и оптимальную производительность, независимо от того, управляет ли она сотнями или миллионами пользователей, при балансировке потребностей и затрат на производительность.
Дополнительные сведения об управлении затратами см. в статье "Управление выставлением счетов и затратами" для рабочих нагрузок SaaS в Azure.
Рекомендации по проектированию
Стратегии горизонтального и вертикального масштабирования. Подходы к горизонтальному и вертикальному масштабированию являются жизнеспособными для обработки повышенной нагрузки. Используемый подход зависит от способности приложения масштабироваться в нескольких экземплярах.
- Горизонтальное масштабирование включает добавление дополнительных экземпляров вычислительных узлов. Архитектура требует подсистемы балансировки нагрузки для распределения входящего трафика между несколькими серверами или экземплярами.
- Вертикальное масштабирование включает увеличение ресурсов, таких как ЦП и память на одном сервере. Используйте этот подход для приложений с отслеживанием состояния, которые не нуждаются во внешних хранилищах состояний, таких как кэши. Вертикальное масштабирование может привести к краткому прерыванию работы службы и ограничению ресурсов на одном сервере.
Рекомендации по масштабированию и секционированию см. в рекомендациях PE:05.
Автомасштабирование. Системам необходимо эффективно обрабатывать различные уровни спроса. По мере увеличения трафика пользователей ресурсы приложения должны масштабироваться для поддержания производительности. При уменьшении спроса ресурсы сокращаются, чтобы управлять затратами, не влияя на взаимодействие с пользователем. Такие факторы, как использование ЦП, время дня или входящие запросы, направляют эти корректировки. Автомасштабирование помогает сбалансировать производительность и затраты и снизить влияние высокого спроса на других клиентов.
Планирование емкости и выделение вычислительных ресурсов. Подключение новых клиентов к рабочей нагрузке SaaS использует емкость ресурсов. Даже если вы масштабируете вертикально или горизонтально, вы в конечном итоге достигаете пределов, таких как ограничения сети или хранилища, в масштабируемости вашего решения.
Примечание.
Шаблон "Метки развертывания" позволяет развертывать несколько независимых экземпляров решения. Он предоставляет другое измерение масштабирования. Важно понимать емкость каждой метки, чтобы определить, когда следует развертывать больше. Эта концепция также называется упаковкой корзины.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Выберите горизонтальное масштабирование по вертикали. Горизонтальное масштабирование часто является менее сложным, более надежным и более экономичным, чем вертикальное масштабирование. | Горизонтальное масштабирование часто проще, надежнее и экономично, что позволяет масштабировать до более высокой степени, чем вертикальное масштабирование. |
| Выполнение нагрузочного тестирования. | Имитация использования поможет определить узкие места и пороговые значения масштабирования перед развертыванием в рабочей среде. |
| Определите пороговое значение масштабирования для развертывания новой метки вместо горизонтального или вертикального масштабирования. Для эффективного масштабирования без потери производительности уплотните клиентов на максимальное количество ресурсов. |
Вы лучше готовы к росту за пределами текущей инфраструктуры. |
| Реализуйте автомасштабирование, где это возможно. Задайте правила автомасштабирования, чтобы точно отразить нагрузку приложения. | Вы оптимизируете производительность и затраты, увеличивая и уменьшая ресурсы по мере необходимости. |
| Мониторинг и оценка шаблонов использования клиентов. | Вы знаете, когда следует настроить инфраструктуру для повышения производительности или оптимизации затрат. |
| Реализуйте механизмы кэширования, где это возможно. | Вы снижаете потенциальную нагрузку на обработку на вычислительном слое. |
| Используйте оповещения о затратах. | Предупреждения помогают обнаруживать проблемы с высокими затратами на использование и управление ими раньше. |
| Используйте резервирования Azure для клиентов, имеющих долгосрочные обязательства и гарантированную загрузку вычислительных ресурсов в течение всего этого периода. | Вы обеспечиваете максимальную эффективность затрат на зарезервированную емкость. |
Проектирование для обеспечения устойчивости
Устойчивость вычислительного слоя играет большую роль в общей стратегии устойчивости. Приложение должно терпеть и восстанавливаться после распространенных сбоев автоматически и без влияния пользователя.
Рекомендации по проектированию
Требования к надежности. Задайте четкие требования к надежности. Эти требования включают внутренние целевые показатели или соглашения об уровне обслуживания, а также обязательства клиентов или соглашения об уровне обслуживания, которые часто указывают целевые показатели простоя, такие как 99,9% в месяц.
Рекомендации RE:04 по определению целевых показателей надежности.
Стратегия развертывания. Облачные ресурсы развертываются в определенных географических регионах. В Azure зоны доступности изолированы наборы центров обработки данных в пределах региона. Для обеспечения устойчивости разверните приложения в нескольких зонах доступности. Развертывание между регионами или поставщиками облачных служб повышает устойчивость, но увеличивает затраты и операционные сложности.
Ознакомьтесь с рекомендациями RE:05 по использованию зон доступности и регионов.
Рабочие нагрузки без отслеживания состояния. Для развертывания устойчивых приложений обычно требуется запускать избыточные копии в разных расположениях. Эта задача может быть сложной для рабочих нагрузок с отслеживанием состояния, которые должны поддерживать состояние сеанса. По возможности создайте рабочие нагрузки без отслеживания состояния.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Обработка временных сбоев в приложении. | Вы повышаете доступность, быстро восстанавливаясь после незначительных проблем. |
| Выберите приложения без отслеживания состояния. Если приложение должно быть состоянием, используйте внешний механизм хранения состояний, например кэш для хранения состояния. | Вы предотвращаете потерю состояния, которая вызвана недоступной экземпляром, например во время ошибочной балансировки нагрузки или во время сбоя. |
| Используйте зоны доступности. | Вы повышаете устойчивость путем устранения локализованных сбоев центра обработки данных. |
| Разработка многорегиональной архитектуры при наличии бизнес-обоснования для этого. | Вы соответствуете высоким требованиям и поддерживаете пользователей в разных регионах. |
| Выполните инженерию хаоса. | Лучше понять, где находятся точки сбоя, и их можно исправить перед сбоем. |
| Ограничение использования компонентов, совместно используемых несколькими метками. | Вы устраняете отдельные точки сбоя и сокращаете потенциальную область влияния на сбой. |
Дополнительные ресурсы
Мультитенантность — это основная бизнес-методология разработки рабочих нагрузок SaaS. В этих статьях содержатся дополнительные сведения о рекомендациях по вычислительной платформе:
Следующий шаг
Ознакомьтесь с рекомендациями по работе с сетями для рабочих нагрузок SaaS.