- tocdepth
2
Масштабирование контейнера в Container Apps
Сервис Container Apps поддерживает вертикальное и горизонтальное масштабирование контейнера.
Вертикальное масштабирование
Вертикальное масштабирование — увеличение или уменьшение ресурсов (vCPU + RAM), выделенных для экземпляра контейнера. Вертикальное масштабирование неавтоматическое, вы самостоятельно задаете нужное количество ресурсов на экземпляр при создании ревизии контейнера.
Изменить количество ресурсов для существующей ревизии можно только через создание новой ревизии.
Чтобы подобрать оптимальную конфигурацию, следите за количеством запросов к ревизии и потреблением ресурсов на графиках в разделе Мониторинг. Общее количество запросов к ревизии отображается на графике Количество запросов, а потребляемое количество vCPU — на графике Использование vCPU.
Горизонтальное масштабирование
Горизонтальное масштабирование — автоматическое увеличение или уменьшение количества «холодных» экземпляров контейнера в соответствии с количеством поступающих запросов.
Количество экземпляров устанавливается в настройках масштабирования при создании контейнера.
Минимальное количество экземпляров — экземпляры контейнера, которые постоянно поддерживаются в рабочем состоянии и готовы принимать запросы (экземпляры с «горячим» стартом). Даже при отсутствии запросов к приложению «горячие» экземпляры продолжают находиться в активном состоянии. Чтобы остановить работу «горячего» экземпляра, необходимо остановить или удалить контейнер вручную.
Максимальное количество экземпляров — количество экземпляров, до которого сервис автоматически масштабируется при увеличении числа запросов (экземпляры с «холодным» стартом).
Лимит на максимальное количество «холодных» экземпляров позволяет контролировать расходы, а также ограничивать количество подключений к вашим службам.
Иногда в случае значительных всплесков трафика установленного лимита на «холодные» экземпляры может быть недостаточно для обработки нагрузки. Тогда входящие запросы будут поставлены в очередь на время, которое было указано в поле Request-таймаут при создании контейнера. Если в течение этого времени ни один экземпляр не освободится, чтобы обработать запросы из очереди, запросы будут прерваны.
Если «холодный» экземпляр выполнил все запросы из очереди и новые запросы не поступают, экземпляр автоматически удаляется. Управлять временем удаления экземпляра при отсутствии запросов вы можете с помощью параметра Idle-таймаут при создании контейнера.
Значение поля Максимальное количество экземпляров не должно быть меньше значения поля Минимальное количество экземпляров. Если в обоих полях указать ноль, то контейнер не будет принимать запросы.
Правила масштабирования
Экземпляр контейнера обрабатывает один запрос в один момент времени. При увеличении нагрузки сервис автоматически создает новые экземпляры.
Тип масштабирования определяет правила создания новых экземпляров контейнера. Поддерживаются следующие типы масштабирования:
Запросы в секунду на экземпляр (RPS)
Определяет лимит на количество запросов в секунду на экземпляр контейнера в любой момент времени. При достижении указанного лимита запускается автомасштабирование.
Параллельные запросы на экземпляр (Сoncurrency)
Определяет лимит на количество одновременных запросов на один экземпляр контейнера в любой момент времени. При достижении указанного лимита запускается автомасштабирование.
Управление типом Сoncurrency осуществляется с помощью настройки мягкого и жесткого ограничения количества запросов.
Мягкое ограничение — это нестрогий лимит на количество одновременных запросов. В некоторых ситуациях, например, при внезапном всплеске запросов, этот лимит может быть превышен прежде чем начнется автомасштабирование.
Жесткое ограничение — это строгий лимит. Если количество запросов достигает этого лимита, то избыточные запросы будут помещены в буфер и должны ждать, пока не освободится достаточно ресурсов для их выполнения.
Если задано и мягкое, и жесткое ограничение, то будет использоваться ограничение с меньшим числовым значением.
Примечание
Использовать конфигурации с жесткими ограничениями рекомендуется только в том случае, если в этом есть необходимость. Если установить небольшое количество запросов в жестком ограничении, это может снизить пропускную способность и замедлить работу, а также стать причиной дополнительных запусков неподготовленных экземпляров («холодных» запусков).
Пример
Для ревизии контейнера укажем следующие настройки:
Количество ресурсов на экземпляр контейнера: 0,5 vCPU – 512 MB (RAM).
Минимальное количество «горячих» экземпляров: 1.
Максимальное количество «холодных» экземпляров: 2.
Тип масштабирования: Параллельные запросы на экземпляр (Сoncurrency).
Мягкое ограничение: 3.
Жесткое ограничение: 0.
При поступлении запросы сразу попадают на «горячий» экземпляр — он находится в постоянной готовности принимать запросы. Настройка мягкого ограничения в Сoncurrency означает, что на экземпляр будет распределяться по 3 запроса. Поскольку это мягкое ограничение, то количество одновременных запросов должно стабильно привышать 3 в течение некоторого времени, чтобы началось автомасштабирование.
Допустим, начался значительный всплеск запросов. Тогда сервис начинает автомасштабироваться — создавать новые экземпляры с «холодным» стартом в соответствии с нагрузкой.
Лимит на максимальное количество «холодных» экземпляров в нашем примере — 2. При достижении этого лимита автомасштабирование сервиса прекращается.
Когда всплеск нагрузки закончился и запросы перестали поступать, созданные «холодные» экземпляры удаляются. «Горячий» экземпляр остается в ожидании запросов.
Если в настройках контейнера указать количество «горячих» экземпляров равное нулю, то при масштабировании будут создаваться только «холодные» экземпляры, что может увеличить время обработки запросов.
См.также
для Dev & Test