Бессерверные технологии, такие как Google App Engine (GAE) и AWS Lambda, являются мощными платформами для облачных программных систем. Простота развертывания и управления, предоставляемые бессерверными платформами, делает их привлекательным вариантом для многих организаций, переносящих свои рабочие нагрузки в облако.

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

В первой статье из этой серии статей о масштабируемости облака мы показали, как выбор языка программирования для бессерверной платформы (GAE) оказал значительное влияние на производительность и может привести к 4-кратному снижению затрат для достижения базовой пропускной способности. В дальнейшем мы поэкспериментируем с параметрами автомасштабирования в GAE. Результаты показывают, как можно повысить производительность при меньших затратах, изменив значения по умолчанию, чтобы они соответствовали рабочей нагрузке вашего сервиса.

В качестве альтернативы вы можете добиться сокращения затрат почти на 50% при почти идентичной производительности, обеспечиваемой настройками платформы GAE по умолчанию. По мере масштабирования вашей системы снижение затрат на 50% может быть очень большими деньгами.

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

Автомасштабирование Google App Engine

Автомасштабирование - это параметр, который вы указываете в файле app.yaml, который передается в GAE при загрузке кода сервера. Приложение с автомасштабированием управляется GAE в соответствии с набором значений параметров по умолчанию, которые вы можете переопределить в своем app.yaml. Базовая схема представлена ​​на рисунке 1.

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

Развертывание экземпляра может занять от 500 мс до нескольких секунд в зависимости от языка программирования, который вы используете. Это означает, что задержка может быть высокой, если нет резидентных экземпляров. Чтобы уменьшить влияние задержки загрузки экземпляра, вы можете указать минимальное количество экземпляров, которое будет доступно для обработки запросов. Это, конечно, стоит денег.

По мере роста нагрузки запросов планировщик GAE будет динамически загружать больше экземпляров для обработки запросов. Три параметра точно определяют, как это работает. Эти:

Целевое использование ЦП. Устанавливает порог загрузки ЦП, выше которого будет запущено больше экземпляров для обработки запросов. Диапазон составляет от 0,5 (50%) до 0,95 (95%). Если вы ничего не сделаете, вы получите значение по умолчанию, равное 0,6 (60%).

Максимальное количество одновременных запросов. Устанавливает максимальное количество одновременных запросов, которое может принять экземпляр, прежде чем планировщик создаст новый экземпляр. Значение по умолчанию - 10, а максимальное - 80. В документации не указано минимально допустимое значение, но, предположительно, 1 будет определять однопоточную службу.

Целевое использование пропускной способности: используется вместе со значением, указанным для максимального количества одновременных запросов, чтобы указать, когда запускается новый экземпляр. Диапазон составляет от 0,5 (50%) до 0,95 (95%). По умолчанию 0,6 (60%). Это работает следующим образом: когда количество одновременных запросов для экземпляра достигает значения, равного максимальному значению одновременных запросов, умноженному на целевое использование пропускной способности, планировщик пытается запустить новый экземпляр.

Понял? 😊

Таким образом, по умолчанию экземпляр будет обрабатывать 10 x 0,6 = 6 одновременных запросов, прежде чем будет создан новый экземпляр. И если из-за этих 6 (или менее) запросов загрузка ЦП экземпляра превысит 60%, планировщик также попытается создать новый экземпляр.

Я все равно думаю.

Но подождите, это еще не все!

Вы также можете указать значения для управления масштабированием экземпляров GAE в зависимости от времени, в течение которого запросы находятся в очереди ожидающих запросов, ожидая отправки экземпляру для обработки. Этот параметр максимальная задержка ожидания - это максимальное количество времени, в течение которого GAE должен позволить запросу ожидать в очереди ожидания перед запуском дополнительных экземпляров для обработки запросов и уменьшения общей задержки. Значение по умолчанию - 30 мс. Чем ниже значение, тем быстрее масштабируется приложение. И тем больше денег вам наверняка будет стоить.

Также существует параметр минимальная задержка ожидания со значением по умолчанию, равным нулю. Если вы смелы, здесь объясняется, как работают вместе минимальные и максимальные значения.

Эти настройки параметров автомасштабирования дают нам возможность точно настроить поведение службы, чтобы сбалансировать производительность и стоимость. Что здорово, не правда ли?

Тогда вопрос для архитектора программного обеспечения GAE: как выбрать значения параметров? С чего начать? Есть большое сочетание возможных настроек. Как узнать, что у вас есть значения параметров, которые обслуживают как пользователей, так и бюджеты, максимально приближенные к оптимальным? В этом видео есть несколько хороших общих советов от Google, но у вас все еще остается проблема с выбором точных значений параметров для вашего приложения.

В качестве примера, давайте рассмотрим только три из доступных параметров, как показано в таблице 1. Фактически существуют возможные конфигурации 45x45x80 для приложения. Если вам интересно, это 162К конфигураций. Не думаю, что хотел знать.

Даже если мы будем рассматривать 10 как практический минимум для максимального количества одновременных запросов, у нас все равно будет более 141K конфигураций. И если мы серьезно подойдем к практике и просто рассмотрим значения с шагом 0,05 для пропускной способности и использования ЦП и с шагом 10 для максимального количества одновременных запросов, мы получим 648 возможных конфигураций. Это все еще непрактично исследовать, тем более что мы действительно не знаем априори, насколько чувствительным будет наш сервис к какому-либо значению параметра.

Итак, как мы можем эффективно и действенно понять, как настроить наше приложение для масштабирования?

Читать дальше ….

Исследование параметров автомасштабирования GAE

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

Так что мы можем сделать?

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

Давайте определим такое исследование для приложения GAE.

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

В исследовании параметров, которое мы проиллюстрируем в этой статье, мы исследуем влияние изменения загрузки ЦП и максимальных значений параметров одновременных запросов. Мы выбираем три значения загрузки ЦП, а именно {0,6, 0,7. 0.8}, в диапазоне от 60% до 80% по умолчанию соответственно. Для максимального количества одновременных запросов на экземпляр мы выбираем 4 значения, а именно {10, 35, 60, 80}, при этом минимальное значение 10 является значением по умолчанию, а максимальное значение 80 - максимумом, как показано в таблице 2.

Это определяет 12 различных конфигураций для приложения GAE. Это позволяет нам исследовать диапазон значений каждого параметра и анализировать, как они взаимодействуют.

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

Теперь самое интересное - результаты!

Результаты экспериментов

Удобный способ изучить результаты исследования параметров - построить поверхность отклика для заданной интересующей метрики. В качестве примера на рисунке 2 показано среднее время отклика для каждой тестовой конфигурации. Мы видим, что наивысшая средняя пропускная способность происходит, когда максимальное значение одновременных запросов находится в нижней части диапазона значений параметра. Он также в основном нечувствителен к значению настройки загрузки ЦП. По мере увеличения максимального значения одновременных запросов средняя пропускная способность в худшем случае снижается примерно на 9%.

Затем давайте сравним стоимость каждой конфигурации, измеренную в часах экземпляра, затраченных GAE на выполнение каждого теста. На рисунке 3 показана поверхность отклика, которая показывает более высокие затраты, если для параллелизма в экземпляре установлено значение 10. При более высоких уровнях параллелизма затраты почти на 50% ниже и снова кажутся относительно нечувствительными к уровням загрузки ЦП.

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

Из этих результатов мы можем сделать несколько важных наблюдений:

  • Настройки параметров по умолчанию {CPU60, max10} не дают ни максимальной производительности, ни минимальной стоимости.
  • Мы получаем на 3% более высокую производительность с конфигурацией {CPU80, max10} при той же стоимости конфигурации по умолчанию.
  • Мы получаем незначительно (~ 2%} более высокую производительность при 18% меньших затратах от конфигурации {CPU70, max35} по сравнению с настройками конфигурации по умолчанию. Быстрее и дешевле - это хорошо.
  • Мы получаем ~ 96% производительности конфигурации по умолчанию при ~ 54% затрат с тестовой конфигурацией {CPU70, max80).

Очки на вынос

Эти результаты показывают, что изучение настроек параметров конфигурации для приложения GAE может окупиться. В этом эксперименте мы видим сокращение затрат почти на 50% с минимальными потерями в производительности. И мы можем получить немного лучшую производительность при значительно меньших затратах, чем при настройках GAE по умолчанию. Одни только эти результаты должны быть достаточной мотивацией для изучения того, как изменение значений конфигурации может улучшить соотношение затрат и производительности.

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

В тестовой среде развертывание и оценка различных конфигураций может быть дешевым и быстрым. Также возможно сделать такого рода эксперименты постоянной частью вашей производственной среды. GAE позволяет развертывать разные версии одного и того же кода с разными настройками параметров и использовать функцию разделения трафика GAE для маршрутизации одинакового процента запросов к каждой версии. Затем, используя консоль GAE и функции облачного мониторинга, вы можете отслеживать затраты и средние задержки для каждого экземпляра, чтобы сравнивать эффекты каждой комбинации настроек. Если вы работаете в магазине AWS Lambda, вы можете развернуть и отслеживать аналогичным образом, используя сглаживание лямбда-функций и смещение трафика.

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