Глубокое погружение в техники автомасштабирования облака
Введение
Авто-масштабирование — это техника облачных вычислений, при которой количество вычислительных ресурсов в среде хостинга динамически корректируется в зависимости от текущего спроса. Это позволяет инфраструктуре приложения автоматически расти, когда спрос увеличивается, и сокращаться, когда спрос уменьшается. Добавление и удаление ресурсов вручную — это процесс, подверженный человеческим ошибкам, часто приводящий к ситуациям, когда ресурсов недостаточно для удовлетворения текущего спроса (что приводит к замедлению или сбоям) или к избыточному использованию ресурсов (что приводит к waste денег и других ресурсов). Автоматическое масштабирование помогает решить эту проблему, автоматически добавляя и удаляя ресурсы по мере необходимости для поддержания производительности при оптимизации затрат.
В этом посте мы объясним, как работает автоматическое масштабирование и почему оно важно. Мы рассмотрим различные типы автоматического масштабирования и политики масштабирования. Вы также узнаете, как крупные облачные провайдеры поддерживают автоматическое масштабирование, как работает автоматическое масштабирование в Kubernetes, распространенные ошибки и как их избежать.
Основные выводы
- Автошкалирование относится к возможности динамически регулировать объем вычислительных ресурсов, используемых для соответствия текущему спросу. Оно обычно используется для обеспечения стабильной производительности при одновременной экономии затрат.
- Он устраняет ручные усилия по масштабированию и также может служить средством для снижения риска человеческой ошибки и предотвращения чрезмерного или недостаточного обеспечения. Он гарантирует, что вы платите только за то, что используете.
- Авто-масштабирование может быть достигнуто путем добавления/удаления серверов (горизонтальное масштабирование) или увеличения/уменьшения существующей мощности серверов (вертикальное масштабирование). Это позволяет гибко реагировать на изменения нагрузки.
- AWS, Azure, Google Cloud, DigitalOcean, Kubernetes и другие популярные платформы все предлагают функцию автоматического масштабирования, что делает её доступной для большинства современных облачных рабочих нагрузок.
- Настройте свои политики автоскейлинга правильно, чтобы они соответствовали потребностям вашего приложения. Обязательно проверяйте и тестируйте политики, чтобы избежать распространенных ошибок автоскейлинга.
Как работает автоскейлинг?
Авто масштабирование работает, отслеживая производительность вашего приложения или метрики нагрузки, а затем автоматически предпринимая действия для добавления или удаления ресурсов, когда выполняются определенные условия. Общее представление о процессе выглядит следующим образом:
- Мониторинг – Служба (облачный инструмент мониторинга, сервер метрик Kubernetes и т.д.) регулярно измеряет и сообщает метрики для ваших экземпляров приложений. Это включает использование процессора, использование памяти, сетевой трафик и другие соответствующие метрики. Эти метрики указывают на требуемую нагрузку на вашу систему.
- Политики масштабирования/Триггеры – Вы определяете правила или политики, по которым хотите масштабировать (увеличивать емкость) или уменьшать (уменьшать емкость). Политики могут основываться на значениях порогов (например, «если средний ЦП более 80% в течение 10 минут, добавить 4 сервера»), целевых значениях (например, «поддерживать ЦП на уровне 60%, автоматически регулируя количество экземпляров»), или расписаниях (например, «масштабироваться до 12 экземпляров в 8 утра каждый рабочий день, масштабироваться до 5 экземпляров после 9 вечера»).
- Выполнение (Масштабирование действий) – Когда условие для политики масштабирования выполняется, система автоматического масштабирования автоматически выполнит связанное действие масштабирования. В случае события масштабирования (scale-out) она выделит дополнительные ресурсы. В случае события уменьшения масштаба (scale-in) она завершит или остановит лишние экземпляры.
- Охлаждение/Стабилизация – После действия по масштабированию автоматическое масштабирование, как правило, накладывает период охлаждения (иногда называемый периодом стабилизации), в течение которого дальнейшие действия по масштабированию приостановлены или ограничены. Это помогает системе стабилизироваться с новой мощностью и предотвращает колебания (частое масштабирование вверх и вниз).
- Шкалировать до желаемого состояния – Многие реализации автоматического масштабирования также позволяют вам указать желаемую емкость или целевое состояние. Например, вы можете указать, что желаемое количество экземпляров составляет 6, минимальное – 4, а максимальное – 12 (в AWS Auto Scaling).
За кулисами автоматизированная служба масштабирования для каждого поставщика будет управлять деталями. В любом случае схема одинакова: мониторинг -> триггер -> действие масштабирования -> стабилизация -> повторение, всё основано на ваших определённых политиках.
Понимание горизонтального и вертикального масштабирования
При обсуждении автоскейлинга важно понять два основных способа масштабирования систем:
- Горизонтальное масштабирование (масштабирование вверх/вниз): Это относится к добавлению большего количества экземпляров ресурса для обработки увеличенной нагрузки или их удалению, когда спрос падает. Например, если у вас есть веб-сервис, размещенный на трех серверах, горизонтальное масштабирование для обработки большего трафика может включать добавление двух дополнительных серверов (масштабирование вверх до пяти серверов). Если трафик уменьшается, масштабирование вниз может снизить количество обратно до, например, трех серверов.
- Вертикальное масштабирование (Увеличение/уменьшение): Это предполагает увеличение или уменьшение мощности ресурсов, назначенных одной инстанции, например, миграция вашего приложения на более крупный сервер с большим количеством CPU, RAM или диска, или добавление дополнительных ресурсов к виртуальной машине. Например, вертикальное масштабирование может означать изменение размера Azure VM с 2 vCPUs/8 ГБ RAM на 8 vCPUs/32 ГБ RAM. Некоторые рабочие нагрузки могут потребовать вертикального масштабирования, если их невозможно распределить для работы на нескольких узлах. На практике современные облачные системы в производстве используют горизонтальное масштабирование для эластичности, когда это возможно, и вертикальное масштабирование как дополнительный подход.
Методы автоматического масштабирования в различных облачных провайдерах
Основные облачные провайдеры предлагают автоматическое масштабирование. Приложения остаются отзывчивыми, и затраты оптимизируются за счет автоматического масштабирования виртуальных машин или контейнеров по мере необходимости.
AWS Автоматическое масштабирование
Amazon Web Services предоставляет различные виды услуг автоматического масштабирования:
- Группы автоматического масштабирования EC2 – Выполняет операции над несколькими группами экземпляров Amazon EC2. Пользователи устанавливают минимальную, максимальную и желаемую емкость, а группа автоматического масштабирования автоматически заменяет ненадежные экземпляры и добавляет/удаляет емкость на основе заданных политик.
- Автошкалирование приложений – Позволяет вам масштабировать несколько ресурсов AWS (таких как контейнеры ECS, пропускная способность DynamoDB и параллелизм Lambda) на основе использования.
- AWS Auto Scaling (сервис) – единый сервис, который рекомендует и организует политики масштабирования для нескольких сервисов AWS.
Авто масштабирование можно управлять через консоль управления AWS, AWS CLI, SDK или инструменты инфраструктуры как код, такие как CloudFormation. С помощью шаблона CloudFormation вы можете определить ресурс AWS::AutoScaling::AutoScalingGroup вместе с основными свойствами, такими как MinSize, MaxSize и сетевой подсеть, где вы хотите разместить свои инстансы. Затем вы связываете группу с AWS::AutoScaling::ScalingPolicy, которая определяет, когда и как происходит масштабирование. Например, вы можете установить политику для поддержания средней загрузки ЦП около 50%, с периодом охлаждения в 5 минут, чтобы предотвратить быстрые решения по масштабированию. Следующий фрагмент кода YAML показывает пример конфигурации:
Resources: MyAutoScalingGroup: Type: AWS::AutoScaling::AutoScalingGroup Properties: MinSize: '2' MaxSize: '20' DesiredCapacity: '2' VPCZoneIdentifier: - subnet-xxxxxxxxxxxxxxxxx # Specify your subnet ID(s) here LaunchTemplate: LaunchTemplateId: !Ref MyLaunchTemplate Version: !GetAtt MyLaunchTemplate.LatestVersionNumber MyCPUScalingPolicy: Type: AWS::AutoScaling::ScalingPolicy Properties: AutoScalingGroupName: !Ref MyAutoScalingGroup PolicyType: TargetTrackingScaling TargetTrackingConfiguration: PredefinedMetricSpecification: PredefinedMetricType: ASGAverageCPUUtilization TargetValue: 50 # Maintain 50% CPU utilization Cooldown: '300' # 5-minute cooldown MyLaunchTemplate: Type: AWS::EC2::LaunchTemplate Properties: LaunchTemplateData: ImageId: ami-0c55b159cbfafe1f0 # Example Amazon Linux 2 AMI InstanceType: t2.micro Группа автоматического масштабирования будет автоматически регулировать размер экземпляров EC2 в зависимости от спроса и поддерживать оптимальное использование процессора, масштабируясь вверх или вниз по мере необходимости.
Автоматическое масштабирование Azure
Microsoft Azure предоставляет функцию, называемую масштабируемыми наборами виртуальных машин (VMSS), которую можно использовать для горизонтального масштабирования виртуальных машин. Она также включает в себя интегрированную службу автоматического масштабирования Azure, которую можно использовать с другими ресурсами, такими как приложения, облачные службы и другие. Azure более ориентирован на тесную интеграцию с другими компонентами Azure и сильную поддержку гибридного облака (одна и та же стратегия масштабирования используется как для локальных, так и для облачных развертываний). Например, масштабируемые наборы виртуальных машин позволяют вам развертывать набор идентичных виртуальных машин, которые могут автоматически масштабироваться (вслед за увеличением или уменьшением) на основе метрик или расписаний.
Автоматическое масштабирование Google Cloud
Google Cloud Platform предлагает управляемые группы инстансов, которые можно использовать для авто-масштабирования виртуальных машин. Google Cloud Autoscaling также известен своей способностью масштабировать контейнеризированную среду с помощью Google Kubernetes Engine (GKE), который обеспечивает автоматическое масштабирование кластеров и подов. Управляемые группы инстансов могут масштабироваться автоматически на основе множества сигналов (ЦП, балансировка нагрузки HTTP, метрики очереди и т. д.). Их также можно интегрировать с GKE для обработки авто-масштабирования базового кластера. Существует период инициализации (охлаждения) для автоскейлера GCP, в течение которого он временно игнорирует метрики от вновь созданных инстансов.
Автоматическое масштабирование DigitalOcean
DigitalOcean представила функцию авто-масштабирования для облачных услуг. Пулы авто-масштабирования дроплетов позволяют автоматически (добавлять/удалять) изменять количество дроплетов (виртуальных машин) в пуле в зависимости от использования ЦП или памяти, обеспечивая управляемое горизонтальное масштабирование для облачных услуг DigitalOcean. Например, вы можете определить пул дроплетов веб-сервера, чтобы поддерживать стабильное использование ЦП на уровне 60%, и пул будет автоматически масштабироваться по мере необходимости. Авто-масштабирование на основе ЦП также доступно на платформе приложений DigitalOcean, которая автоматически добавляет/удаляет компоненты приложений (контейнеры) в зависимости от порогового значения использования ЦП.
Автоматическое масштабирование Kubernetes (Pods и Nodes)
Kubernetes — это платформа для оркестрации контейнеров, которая предоставляет функции автоскалирования. Она широко используется в облачных средах (а иногда и в локальных средах). В Kubernetes существует два уровня масштабирования:
Горизонтальный автоскейлер подов
Горизонтальный автоскейлер подов (HPA) — это контроллер Kubernetes, который автоматически изменяет количество реплик подов для рабочей нагрузки (Deployment, ReplicaSet, StatefulSet и т. д.) в зависимости от наблюдаемых метрик. Он позволяет горизонтально масштабировать поды контейнеризованного приложения. Предположим, у вас есть развертывание с 2 подами веб-приложения. HPA может отслеживать их использование CPU и увеличить количество реплик до, например, 5 подов, если использование CPU высокое, и уменьшить до 2, когда они не загружены. По умолчанию HPA масштабируется на основе использования CPU (информация предоставляется сервером метрик Kubernetes, который собирает данные об использовании CPU/памяти с узлов). Он также может быть настроен для масштабирования на основе использования памяти (через сервер метрик) и пользовательских метрик (с помощью API autoscaling/v2). Вы создадите определение ресурса HorizontalPodAutoscaler в формате YAML (или с использованием kubectl autoscale). Оно будет содержать целевое развертывание (или другой контроллер нагрузки), минимальное и максимальное количество реплик для масштабирования и предел целевой метрики. Вот пример конфигурации HPA, нацеленной на использование CPU:
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa labels: app: my-app spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 70
Система Kubernetes будет поддерживать минимальное количество подов для развертывания my-app на уровне 2, ограничивая максимум до 10. Количество подов будет увеличиваться (добавляться) или уменьшаться (удаляться), чтобы поддерживать среднюю загрузку ЦП по всем подам на уровне ~70%. Если потребление ЦП на один под превысит порог, следует добавить больше подов (до максимума в 10 здесь).
Если целевой процент меньше 70%, а поды используются не полностью, количество подов уменьшится (но не менее 2, как установлено параметром minReplicas). Стоит отметить, что HPA проверяет метрики через определенные интервалы. Интервал контролируется параметром horizontal-pod-autoscaler-sync-period, который устанавливает частоту обновлений решений по масштабированию HPA на основе наблюдаемых метрик. Он также учитывает окно стабилизации, чтобы предотвратить частое увеличение и уменьшение масштабов.
Автоаскаляр кластеров (CA)
Рассмотрим ситуацию, когда наш кластер Kubernetes исчерпал свои мощности (отсутствуют свободные ЦП/память на любом узле для планирования новых подов). В этом случае HPA не может самостоятельно добавить больше узлов; здесь на помощь приходит автоаскаляр кластера. Автоаскаляр кластера работает как компонент кластера Kubernetes, взаимодействуя с облачным провайдером (или другой инфраструктурой) для добавления/удаления рабочих узлов (ВМ) в кластере на основе ожидающих подов. Вот несколько ключевых аспектов управления автоаскаляром Kubernetes:
- Для управляемых услуг (GKE, EKS, AKS и др.) вы включите автоматическое масштабирование кластера, указав минимальное и максимальное количество узлов в пуле узлов. Автоматический масштабировщик кластера будет следить за планировщиком Kubernetes.
- Если есть поды, которые не могут быть запланированы из-за нехватки ресурсов (т.е. вы запросили 1 ЦП, но ни один узел не имеет 1 ЦП доступным), это даст сигнал облаку создать новую ВМ и добавить ее в кластер.
- С другой стороны, если система обнаружит недоиспользуемые узлы и определит, что их поды могут быть перемещены на другие узлы без ущерба для общей емкости, она может уменьшить масштаб (удалить) недоиспользуемые узлы, при условии, что оставшаяся емкость превышает текущий спрос.
Лучшие практики: Каждая группа узлов (пул) должна содержать однородные типы экземпляров, и обычно вы маркируете группы узлов, которые могут масштабироваться. Автошкала следует правилам бюджета разрушения Pod, чтобы предотвратить завершение важных pods. Она также не будет уменьшаться, если это нарушит требования pod (например, pod, который нельзя переместить).
Многие управляемые облаком предложения Kubernetes заботятся о кластерном автоскейлере за вас, как только он включен (например, DigitalOcean Kubernetes (DOKS) предоставляет встроенный автоскейлер для пулов узлов).
Сравнение ручного масштабирования, автоматического масштабирования и эластичного масштабирования
Авто-масштабирование может быть запутанным вопросом, когда дело доходит до различия между ручным предоставлением, масштабированием, основанным на политике, и облачно-нативным понятием эластичности. В таблице ниже мы разберем различия между ручным масштабированием, автоматическим масштабированием и эластичным масштабированием. Это позволит вам понять, как эти три концепции отличаются по операциям, триггерам, точности и даже по некоторым примерам из реальной жизни. Команды DevOps и облака могут использовать эти ключевые различия, чтобы определить, какой из методов наиболее подходит для их рабочих нагрузок.
| Подход к масштабированию | Определение | Механизм триггера | Скорость и точность | Недостатки/Риски | Примеры облаков |
|---|---|---|---|---|---|
| Ручное масштабирование | Корректировки, выполняемые человеком через консоль или скрипты, часто связанные с статическим или реактивным обеспечением. | Запускается вручную операторами (консоль, CLI, заявки) | Медленно (минуты – часы), часто неточно и консервативно | Трудоемкий, подверженный ошибкам и дорогой из-за избыточного обеспечивания. | Ручное изменение размера экземпляров EC2 или ВМ |
| Авто масштабирование | Автоматическое масштабирование на основе политик, правил, метрик или расписаний. | Управляется системой через пороги, отслеживание целей или запланированные события | Быстро (секунды — минуты), последовательно и эффективно | Требует точной настройки; неправильно настроенные политики могут привести к нестабильности или чрезмерным затратам | Группы автоматического масштабирования AWS, наборы масштабирования Azure VM, управляемые группы экземпляров GCP, HPA/VPA Kubernetes |
| Эластичное масштабирование | Широкое понятие сопоставления ресурсов с потреблением в реальном времени, автоматическое масштабирование часто поддерживает это поведение. | Являясь подразумеваемым в платформе, обычно встроено в безсерверные или PaaS-сервисы. | Почти мгновенно (от долей секунды до секунд), altamente эффективный | Ограниченное ручное управление; логика масштабирования абстрагируется | AWS Lambda, Azure Functions, Google Cloud Functions, DigitalOcean App Platform |
Ручное масштабирование будет иметь более медленное время отклика, так как зависит от человека, который инициирует масштабные действия. Автоматическое масштабирование является превентивным и реактивным. Оно включает системно определенные правила масштабирования, которые быстро запускают расширение и должны уметь сокращаться так же быстро, как позволяет базовая инфраструктура. Эластичное масштабирование — это облачный нирвана: ресурсы автоматически и мгновенно увеличиваются и уменьшаются, управляемые в фоновом режиме движками автоматического масштабирования.
Политики автмасштабирования: Динамические, Запланированные и Предсказуемые
Политики автоматического масштабирования определяют, КОГДА и КАК будет происходить ваша активность по масштабированию. Правильное сочетание политик позволит системе оставаться высокоустойчивой во время всплесков нагрузки, оптимизировать затраты в моменты простоя и обеспечивать быструю реакцию на колеблющиеся нагрузки.
| Тип политики | Триггер/Механизм | Профи | Недостатки/Предостережения | Поддерживается |
|---|---|---|---|---|
| Динамический (Реактивный) | Мониторит метрики в реальном времени (ЦП, память, задержка, длина очереди). На основе порогов: например, “ЦП > 70% в течение 5 мин → +2 экземпляра; ЦП < 20% в течение 10 мин → –1 экземпляр. ” Отслеживание целевых значений: поддерживайте целевое значение с помощью алгоритмических корректировок. | Реагирует на резкие всплески нагрузки. Высокоавтоматизированный и детализированный | Может замедляться во время резких всплесков. Требует тщательной настройки порогов и времени восстановления. | AWS ASG, Azure Monitor Autoscale, GCP MIG, Kubernetes HPA |
| Запланированное Масштабирование | Действия на основе времени (например, «Каждый рабочий день в 8 утра, добавлять экземпляры»). Работает как задача cron для масштабирования. | Идеально подходит для предсказуемых циклов нагрузки. Обеспечивает готовность ёмкости заранее. | Не может реагировать на неожиданные события. Требуется точное прогнозирование использования. | Запланированные действия AWS, правила расписания Azure, запланированное автомасштабирование GCP, Пулы DigitalOcean |
| Прогнозируемое масштабирование | Использует машинное обучение на исторических данных, чтобы предсказать спрос и проактивно масштабироваться (например, за 15–60 минут). | Снижает задержку масштабирования. Оптимизировано для повторяющихся паттернов. | Требуется ≥1–2 недели данных. Может неверно предсказать нерегулярные события. | Предсказательное автоскалирование AWS, предсказательное виртуальное масштабирование Azure, предсказательное управление группами GCP |
| Руководство (Фиксированное) | Управляется человеком; автоматическое масштабирование отключено или настроено вручную — обычно во время обслуживания или отладки. | Полный контроль, когда это необходимо. Полезно в экстренных ситуациях. | Нет автоматической отзывчивости. Это может привести к неэффективному использованию ресурсов. | Поддерживается всеми основными облаками в качестве базового уровня |
Ключевые выводы
- Начните с динамических политик для немедленной реактивности. При необходимости регулируйте пороги и окна стабилизации.
- Ставьте запланированные политики поверх динамических для повторяющихся нагрузок (рабочие часы, окна обслуживания и другое).
- Рассмотрите возможность предиктивного масштабирования, если у вас есть обширные исторические данные и циклические модели спроса в вашей среде. Предиктивное масштабирование поможет подготовиться к вашему ближайшему спросу.
- Ручная политика должна использоваться для поддержания контроля во время сбоев системы и операций по устранению неполадок.
Общие ошибки автоподмасштабирования
Авто масштабирование упрощает управление облаком, но может вызвать проблемы, если оно настроено неправильно. Вот некоторые распространенные проблемы, на которые стоит обратить внимание:
Добавление слишком большого или слишком малого количества ресурсов
Проблема: Если ваши политики масштабирования определены неправильно, вы можете столкнуться с избыточным предоставлением ресурсов (например, добавление слишком большого количества серверов), что приведет к ненужным затратам. Это также может привести к недостаточному предоставлению серверов, что вызовет проблемы с производительностью. Лучшие практики: Вы можете протестировать и настроить свои параметры, а также увеличить или уменьшить масштаб до нужного размера в зависимости от ваших потребностей.
Внезапная нагрузка может привести к задержке масштабирования
Проблема: Авто масштабирование может реагировать медленно на внезапное увеличение нагрузки из-за задержки в мониторинге ресурсов или медленного процесса добавления новых серверов. Рекомендация: Контейнеры быстрее масштабируются, так как их можно настроить на запуск за считанные секунды. Вы также можете заранее запланировать масштабирование (вверх или вниз) для событий, которые, как вы знаете, будут иметь высокий трафик.
Проблемы совместимости со старыми системами Проблема: Устаревшие приложения могут быть не настроены на горизонтальное масштабирование или взаимодействие с системами оркестрации. Поэтому автоматическое масштабирование таких систем может привести к нестабильности и ошибкам. Рекомендация: Вы можете протестировать свои рабочие нагрузки и их зависимости, чтобы определить, являются ли они облачными и безсостояниевыми перед внедрением автоматического масштабирования. Устаревшие приложения могут быть переписаны для масштабирования, где это возможно. Вы также можете использовать ручное масштабирование для любых компонентов, которые нельзя модернизировать.
Часто задаваемые вопросы
Что такое авто-масштабирование в облачных вычислениях?
Автомасштабирование — это автоматизированный процесс регулировки вычислительных ресурсов (виртуальных машин, контейнеров, серверов) в реальном времени в соответствии с фактической загрузкой. Оно используется для поддержания производительности приложения и оптимизации затрат.
В чем разница между горизонтальным и вертикальным масштабированием?
Горизонтальное масштабирование включает добавление/убирание экземпляров (масштабирование вширь/вузь), улучшая отказоустойчивость и параллелизм, в то время как вертикальное масштабирование включает увеличение/уменьшение ресурсов на одном экземпляре (масштабирование вверх/вниз).
Что вызывает автоматическое масштабирование?
Триггеры обычно представляют собой метрики, такие как использование CPU, использование памяти, скорость запросов, длина очереди или пользовательские метрики, специфичные для приложения.
Заключение
Авто-масштабирование — это облачный сервис, который динамически настраивает ресурсы для вашего приложения на основе фактического спроса. Он может помочь избежать недообеспечения или переобеспечения, а также гарантировать, что ваше приложение сможет обрабатывать входящий трафик. Ручное масштабирование медленно и подвержено человеческим ошибкам, в то время как эластичное масштабирование обеспечивает золотой стандарт в управлении ресурсами. Авто-масштабирование предлагает идеальный баланс, позволяя современным приложениям эффективно работать на любом уровне нагрузки. Соблюдайте лучшие практики, избегайте распространенных ошибок и настройте политики авто-масштабирования для вашей рабочей нагрузки. При правильной конфигурации авто-масштабирование помогает обеспечить надежную производительность и оптимизировать затраты. Это позволит вам и вашим командам сосредоточиться на инновациях, а не на инфраструктуре.
Ссылки и ресурсы
- Что такое автоматическое масштабирование?
- Обзор автоматического масштабирования с помощью наборов масштабирования виртуальных машин Azure
- Авто масштабирование Amazon EC2
- Группы автоматического масштабирования экземпляров
- Как использовать пулы автошкалирования для автоматического горизонтального масштабирования
- Обзор автоматического масштабирования с помощью наборов масштабирования виртуальных машин Azure
- автомасштабирование
Добавить комментарий