Усовершенствованный метод активации веб-сервисов на основе бессерверных облачных вычислений

РЕФЕРАТ

Работа содержит 67 страниц да 28 рисунков. Было использовано 22 источники.

Актуальность работы : Метод активации разрешает обеспечить сверхнизкую задержку в работе с веб-сервисами на основе бессерверных облачных вычислений. Вы передаете программе сколько экземпляров определенного веб-сервиса вы хотите держать активными и она справится с масштабированием за вас. С временем трафик веб-сервиса может увеличиться, а это значит, что нужно удерживать больше активных экземпляров, или меньше, если напротив. Нужно иметь некоторый коэффициент масштабирование, какой будет автоматически Вычисляться учитывая текущий трафик веб-сервиса. Это позволит более эффективно использовать веб-сервисы на основе бессерверных облачных вычислений и уменьшить операционные затраты.

Объект исследование : Процесс использование веб-сервисов на основе бессерверных облачных вычислений.

Предмет исследование : Метод активации веб-сервисов на основе бессерверных облачных вычислений.

Цель работы : Усовершенствовать метод активации веб-сервисов на основе бессерверных облачных вычислений для повышение эффективности их использование.

Для достижения цели исследования были поставлены и решены следующие основные задачи:

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

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

Практическая ценность: Результаты исследования обеспечивают уменьшение операционных затрат на внедрение метода активации веб- сервисов на основе бессерверных облачных вычислений и более эффективное использование облачных ресурсов

Методы исследования : Основными методами исследования являются математическое да имитационное моделирование.

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

СОДЕРЖАНИЕ

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

ВВЕДЕНИЕ

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

Метод активации разрешает обеспечить параллельность веб-сервисов на основе бессерверных облачных вычислений. Вы передаете программе сколько экземпляров определенного веб-сервиса вы хотите держать активными постоянно и она справится с масштабированием за вас. Это позволяет использовать веб- сервисы со сверхнизкой задержкой и без холодного старта. Со временем трафик веб-сервиса может увеличиться, а это значит, что нужно удерживать больше активных экземпляров или меньше, если трафик уменьшился. Нужно иметь некоторый коэффициент масштабирование, какой будет автоматически вычисляться учитывая текущий трафик веб-сервиса. Это позволит более эффективно использовать экземпляры веб-сервиса на основе бессерверных облачных вычислений и уменьшить операционные затраты. Работа выполнена в рамках ГДР кафедры №0119U001184: "Гетерогенная сеть сбора, передачи и обработки информации для системы распределенной генерации MicroGrid." да №0116U005092

«Повышение эффективности обработки данных со потребительских устройств в телекоммуникационной сети Интернета вещей».

РАЗДЕЛ 1

АНАЛИЗ ПРОБЛЕМ ЭФФЕКТИВНОСТЬ ИСПОЛЬЗОВАНИЕ ВЕБ-

СЕРВИСОВ НА ОСНОВЕ БЕЗСЕРВЕРНЫХ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ И ОБЗОР СУЩЕСТВУЮЩИХ МЕТОДОВ ИХ РЕШЕНИЕ.

В общем случае, бессерверные вычисления означают программы, где серверная логика все еще пишется разработчиком, но, на отличие от традиционных систем, они выполняются в контейнеры, которые нет сохраняют своего состояния после вызова, которые вызываются событием (HTTP запрос, запись в базе данных, сообщения в очереди/канале), эфемерные (могут продолжаться только в рамках одного вызова) и полностью управляются третьей стороной (облачным провайдером). Поэтому их еще называют «функциями». Объяснение:

Платформа бессерверных вычислений, такая как AWS Lambda, разрешает сохранять код ваших веб-сервисов и развертывать их без необходимости конфигурирование да управление базовыми серверами. Она инициализирует новые экземпляры функций только на требование (англ. on-demand). Каждый раз, когда платформа получает запрос, но у нее нет активных экземпляров функции, она назначает ему новый. Затем этот экземпляр функции должен скачать код функции или файл с кодом да отгрузить их в память, прежде чем он сможет обработать запрос. Процесс инициализации кода требует времени, что значительно увеличивает задержку ответы[3].

Когда инициализируется код вашей функции, платформа проходит последовательность шагов, которые совместно называются «холодный старт»:

Холодный старт необходимый, когда нету доступного контейнера для обработки события. Эта ситуация происходит в следующие времена:

В то время как первые 2 случаи неизбежны, последних можно избежать, заставив функцию обработать фиктивные «пинг» события [1], распределив их на нужное количество контейнеров финкции с помощью параллельных вызовов этой функции и повторяя это периодически – этот метод называется «Метод активации веб-сервисов на основе бессерверных облачных вычислений». Идея метода состоит в том, чтобы иметь событие в срабатывающем планировщике каждые N минут и посылает M асинхронных запросов нужной функции (рис. 1.2). Если все или запросы попадают одновременно, платформа должна обеспечить по меньшей мере M экземпляров функции для их обработки. Фактический операция «активации» не должна выполнять никакой полезной работы, т.е. бизнес-логики, но она сбрасывает таймер утилизации назад к нулю.

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

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

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

Раньше бессерверное общество создавало программы для активации функций [1], чтобы повысить вероятность обработки запроса существующим средой исполнение. Это хороший подход для разработки да тестирование стабильных систем (рис. 1.3), или там, где вам не нужна гипер-готовность функций.

Рис. 1.3 График нагрузки функции при применении метода активации веб- сервисов на основе бессерверных облачных вычислений

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

Планируемый профиль масштабирования

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

«холодный старт» да обеспечить лучший опыт для конечных пользователей. А благодаря возможностям планировщика, такого как Amazon CloudWatch Events, можно автоматизировать изменение количества активных экземпляров функции на определенную дату или время.

Рис. 1.4 График соответствия планируемого масштабирования изменению нагрузка функции

Динамический профиль масштабирования

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

Рис. 1.5 График соответствия динамического масштабирования изменению нагрузки функции

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

Выводы

РАЗДЕЛ 2

АНАЛИЗ СУЩЕСТВУЮЩИХ МЕТОДОВ ДЛЯ УЛУЧШЕНИЯ ЭФФЕКТИВНОСТЬ ИСПОЛЬЗОВАНИЕ ВЕБ-СЕРВИСОВ ТА

ФОРМИРОВАНИЕ ПОДХОДА К АВТОМАТИЧЕСКОМУ ОЧИСЛЕНИЮ КОЭФИЦИЕНТА МАШТАБИРОВКА

Масштабирование активных экземпляров функций разрешает подготовить среды выполнения до получения реального трафика Метод активации веб-сервисов на основе бессерверных облачных вычислений, кроме загрузки кода функции, также запускает код инициализации за пределами основного обработчика бизнес-логики функции. Это обеспечивает надежный способ поддерживать функции готовыми в течении двузначной задержки в миллисекундах к возможности реагирования на реальные запросы от пользователей. Все активные экземпляры функции (независимо от среды выполнение) обрабатывают запросы скорее, нож новые экземпляры, которые были созданные платформой на требование, чтобы поглотить погрузки. Конечно, такие среды исполнение как C# да Java, имеют намного более медленный время инициализации контейнера, чем Node.js или Python, но более быстрое время выполнения после инициализации. Если усовершенствовать метод активации за счет подключение масштабирование, или среды исполнение выиграют как от стабильно низкой задержки из-за отсутствия «холодных стартов», да и от производительности под время выполнения.

Анализ метода с использованием профиля запланированного масштабирование

Увеличивая количество активных экземпляров функции в нужный момент времени за расписанием можно избежать дополнительной задержки через "холодный старт". Например, рассмотрим ситуацию, когда одна из компаний электронной коммерции проводит акцию «соглашение дня» ежедневно в полдень. Во время нее в системе снижается цена на конкретный товар на 60 минут. Функция, которая создает заказ, назовем ее CreateOrder, обрабатывает около 20 запросов на секунду в течение дня. В полдень зарегистрированным пользователям отправляется оповещения, которые затем подключаются к веб-сайту. Трафик резко возрастает и может превышать 400 запросов за секунду для функции CreateOrder. Этот повторяющийся шаблон показан на рис. 2.1.

Рис. 2.1 График вызовов Lambda функции CreateOrder в системе электронной коммерции

Изучая время отзыва функции в AWS X-ray, первый график показывает нормальный трафик (рис. 2.2):

Рис. 2.2 График нормального распределения времени отклика Lambda функции CreateOrder в системе электронной коммерции

Пока второй график показывает пик (рис. 2.3):

Рис. 2.3 График распределения времени отклика Lambda функции CreateOrder в системе электронной коммерции под время пика

Средняя задержка (p50) выше во время пика – 535 мс против 475 мс при нормальной нагрузке. Значения p90 и p95 показывают, что большинство вызовов не превышают 800 мс на первом графике, но около 900 мс на второму. Эта разница обусловлена «холодным стартом», когда платформа AWS Lambda готовит новые среды выполнения, чтобы поглотить нагрузку под время пика.

Интегрировав метод активации веб-сервисов на основе бессерверных облачных вычислений да увеличивая количество асинхронных «пинг» запросов в полдень можно избежать этой дополнительной задержки и обеспечить лучший опыт для конечных пользователей. В идеале их количество также следует уменьшить о 13 часов, чтобы избежать лишних расходов. А благодаря возможностям планировщика, такого как Amazon CloudWatch Events, можно настроить изменение количества асинхронный «пинг» запросов полдень и о 13:00 на регулярной основе.

Необходима количество активных контейнеров функции, или еще параллельность функции, равно средний количества запросов за секунду, умноженной на среднюю продолжительность функции. Например, если среднее время выполнение функции – 500 мс, а рабочая нагрузка во время пика – 450 запросов на секунду, то нужно регулярно присылать 250 (450 * 0.5 + 10%) асинхронных «пинг» запросов, включая для 10% буфера, что имеет быть достаточно для поглощение заданной погрузки.

на следующем графику задержки (рис 2.4) большинство запросов теперь выполняются менее чем за 800 мс, в соответствии с производительностью в течение остальных дня.

Рис. 2.4 График распределения времени отклика Lambda функции CreateOrder в системе электронной коммерции под время пика после усовершенствование метода активации

Распределение времени отклика в течение «соглашения дня» теперь сравнимо с в любое другое время. Это помогает обеспечить стабильное взаимодействие с пользователями даже при больших нагрузках. А настроив метод активации веб-сервисов на основе бессерверных облачных вычислений увеличивать количество асинхронных «пинг» запросов на начало акции о 11:45 да остановку о 13:15 каждого дня также поможет оптимизировать расходы, ограничивая использование профиля масштабирование к 90 минут на день.

Анализ метода с использованием профиля динамического масштабирование

Мы также можем использовать профиль динамического масштабирование, чтобы автоматизировать предоставление соответствующей мощности во время смены трафика. Бессерверные платформы, такие как AWS Lambda, поддерживают автоматическое масштабирование "из коробки", но каждый раз будет создаваться новое среда исполнение на требование, что приводит к увеличение задержки за счет «холодного старта». Для решение проблемы

«холодного старта» мы уже знаем, что нужно применить метод активации веб-сервисов на основе бессерверных облачных вычислений. Но заставить динамическое масштабирование работать в паре с методом активации – не такова тривиальная задача. Для того чтобы разобраться, предлагаю рассмотреть эти два способы по отдельности да провести необходимы измерение, чтобы после усовершенствование метода активации мы могли сравнить результаты. На этот раз я буду использовать веб-приложение Ask Around Me как пример.

В веб-приложения Ask Around Me пользователи задают вопрос да отвечают на них в своем географическом регионе. Ожидаемое почасово загрузка – 1000 новых вопросов, 10 000 новых ответов да 50 000 запросов на поиск вопросов. Я буду использовать эти цифры как основу для тестов. Для простоты, я буду проверять только часть веб-приложения Ask Around Me, архитектура которой изображена на рис. 2.5.

Рис. 2.5 Высокоуровневая архитектура веб-приложения Ask Around Me

Я запрограммировал создание случайного количества POST/questions API запросов пользователей от 3 до 20 каждую секунду. Минимально это соответствует примерно 10800 запросам пользователей в течении 1 часы, что уже превышает предполагаемую нагрузку для этой части веб-приложения. После тестирование я получил следующие результаты (рис. 2.6).

Рис. 2.6 Результаты тестирования погрузки участка веб-приложения Ask Around Me

В тесте нагрузка в течении 5 минут медиана времени отзыва составляет 175 мс, а самое медленное значение - 2149 мс. Медиана времени отзыва, вероятно, есть приемлемой для пользователя, тогда как любой время отзыва медленнее 2 секунд делает взаимодействие с приложением уже не настолько комфортным.

Я повторно запустил тест нагрузки для этого участка, чтобы собрать более информативные данные за помощью AWS X-ray (рис. 2.7).

Рис. 2.7 Результаты тестирования погрузки участка веб-приложения Ask Around Me в AWS X-ray

Я выбрал все вызовы функции PostQuestions на графике после маркера p95, представляя самые медленные 5% всех запросов. В результате оно отфильтровало 34 запроса, которые соответствуют количеству активных экземпляров. функции, которые было создано платформой на требование при автоматическом масштабировании (рис. 2.8).

Рис. 2.8 Результаты тестирования нагрузки участка веб-приложения Ask Around Me в AWS X-ray

Выбрав один такой запрос можно увидеть продолжительность каждого сегмента процесса (рис. 2.9).

Рис. 2.9 Результаты тестирования погрузки участка веб-приложения Ask Around Me в AWS X-ray

Этот анализ показывает, что на работу функции влияет «холодный старт», потому что инициализация среды выполнения и кода функции занимает больше 1 секунды.

Включив метод активации для этой функции, можно значительно снизить время отзыв [1] для 95% вызовов функции, то есть мы максимально приблизить значение маркера p95 к медианы, какая примерно равно 175 мс да есть приемлемой для пользователя, а следовательно улучшить эффективность функции.

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

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

Метод активации основывается на асинхронной отправке программой фиктивных «пинг» запросов к функции, которую нужно активировать, то есть иметь активных экземпляров этой функции. Из-за некоторый время бездействия функции

FaaS платформа начнет утилизировать активные экземпляры, чтобы освободить облачные ресурсы Чтобы постоянно держать экземпляры функции активными нужно регулярно отправлять асинхронных запросов к ней. Значение и уникальные идентификаторы функций передаются на Вход программы, какая периодически запускается средствами планировщика. Значение сдается вручную да равно среднем времени исполнение функции, умноженному на рабочее нагрузка функции во время пика плюс некоторый остаток на буфер. Чтобы автоматически вычислять нужно также принимать во внимание текущий трафик рассматриваемой функции является достаточно не тривиальной задачей и требует значительных операционных ресурсов Воспользовавшись собственноручно созданной метрикой использования активных экземпляров функции мы можем делать выводы относительно текущего трафика этой функции в целом [2].

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

стабильно превышает 77% (110% от запланированных 70%) что соответствует изменению трафика функции по шаблону вверх, мы можем увеличить значение на коэффициент масштабирование , где

для активации большей количества экземпляров, а когда текущее использование экземпляров функции стабильно меньше 63% (90% от запланированных 70%) что соответствует изменению трафика функции по шаблону вниз, то мы можем уменьшить значение на коэффициент масштабирование , где

В результате новое значение количества активных экземпляров функции будет примерно равняться или соответственно, а количество активных экземпляров функции, какая раньше отвечала (≥ 77% или ≤ 63%) теперь будет примерно отвечать заданном , есть 70%.

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

Выводы

РАЗДЕЛ 3

СОВЕРШЕНСТВОВАНИЕ МЕТОДА АКТИВАЦИИ ВЕБ-СЕРВИСА НА

ОСНОВЫ БЕССЕРВЕРНЫХ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ ЗА СЧЕТ АВТОМАТИЧЕСКИЙ ВЫЧИСЛЕНИЕ КОЭФИЦИЕНТА

МАШТАБИРОВКА

В этом разделе будет показано, как устранить задержку «холодного старта» в бессерверных архитектурах, поддерживающих реальные веб-приложения из непредсказуемым трафиком, при этом, улучшив использование их экземпляров за счет динамического масштабирования. Как пример системы, я буду использовать веб-приложение Ask Around Me размещенный в инфраструктуре Amazon, который уже упоминался ранее. Эта система позволяет пользователям задавать и отвечать на вопросы в своем географическом регионе. Веб-приложение использует архитектуру какая изображена на рис. 3.1.

Рис. 3.1 Высокоуровневая архитектура веб-приложения Ask Around Me

По-прежнему я буду проверять только часть веб-приложения Ask Around Me, которая отвечает за создание вопросов и архитектура которой изображена на рис. 3.2.

Рис. 3.2 Высокоуровневая архитектура участки веб-приложения Ask Around Me

Так как нас интересуют только функции влияющие на время отклика веб- приложении, то нам нужно «активировать» Lambda функцию PostQuestions, та же сама функция что фигурировала в предыдущем разделе во время анализа

Тестировать наш участок системы мы будем с помощью API шлюза POST /questions, какой будет передавать вызовы Lambda функции, да Artillery Community Edition – инструмента с открытым кодом для тестирование бессерверных API. Нужно только настроить количество запросов в секунду да общую продолжительность теста, и программа сделает все за нас, используя «безголовый» (англ. headless) браузер Chromium для запуска своих тестовых потоков.

За сбор данных времени отзыва да создание диаграмм будут отвечать службы Amazon CloudWatch Metrics и AWS X-Ray, результат работы которых мы уже видели в предыдущем разделе.

Мы уже знаем экземпляры которой функции нужно активировать, осталось решить «как именно» да «как часто» мы это будем делать. В бакалаврской работе [1] я активировал функции каждые 5 минут (рис. 3.3), чтобы нет даты платформе бессерверных вычислений утилизировать их экземпляры, что было в полной мере достаточно. Фиксированное значение асинхронных «пинг» вызовов сохранялось в конфигурации среды Warming Lambda функции.

Да само как и в бакалаврской работе, в тестовой системе Lambda функция для «разогрева» будет делать асинхронных «пинг» вызовов к Lambda функции PostQuestions (рис. 3.4), которая должна отличить фиктивный вызов от настоящего запроса пользователя да подождать меньше секунды чтобы распределить запросы на отдельных экземпляров функции PostQuestions.

Совершенствование метода активации

на этот раз значение асинхронных «пинг» вызовов нет будет сохраняться в конфигурации среды Lambda функции для разогрева. Чтобы иметь смогу изменять значение без изменения конфигурации функции для

«разогрева» (ведь при смене конфигурации, меняется версия функции да создается новый контейнер) мы будем передавать его в теле запроса, но уже нет от планировщика CloudWatch Scheduled Events, а другой Lambda функции для «масштабирование», какая это значение будет вычислять. А вызывая Lambda функцию для «масштабирование» за расписанием каждые N минут мы сохраним целостность метода активации функции PostQuestions тестовой системы.

Остается только реализовать механизм за помощью которого значение будет автоматически вычисляться принимая к внимания метрику использование активных экземпляров функций тестовой системы.

Мы уже знаем, чтобы предотвратить утилизацию экземпляров функции, нужно посылать «фиктивные» запросы с определенной частотой. Конечно, нужно внести необходимы изменения в нашу функцию PostQuestions тестовой системы, чтобы различать «пинг» события да настоящие запросы клиентов [1]. Благодаря запросам на

«разогрев», платформа бессерверных вычислений будет держать контейнеры активными, но не все так просто.

Так как мы используем функцию PostQuestions в производстве (для настоящих клиентов), нужно сделать асинхронных запросов на «разогрев», чтобы сохранить активных контейнеров. на этом этапе существуют два риски:

«фиктивных» событий, и настоящий запрос клиента не может Найти место для исполнение. Это приведет «холодный старт» для подлинного вызова.

Чтобы решить или проблемы, мы должны немного подождать на стороне функции, то есть приостановить главный поток функции на время. Таким Таким образом, один экземпляр функции не поймает все "пинг" запросы. А заставив главный поток ожидать не более 150 мс, мы убедимся что блокируем только шестую часть вызовов за секунду.

Lambda функция для «разогрева»

Рассмотрим более подробно реализацию Lambda функции для «разогрева» нашей тестовой системы. Как мы уже знаем она имеет уметь делать следующее:

Чтобы удовлетворить этим условиям наша Lambda функция должна:

И как потоки будут выполняться одновременно то в конце достаточно будет только залоговать результат операции. В результате, операция «разогрева» завершится тогда когда закончит свое исполнение последний поток.

Lambda функция для «масштабирование»

Рассмотрим более подробно реализацию Lambda функции для

«масштабирование» нашей тестовой системы. Она имеет уметь делать следующее:

Чтобы удовлетворить этим условиям наша Lambda функция должна:

Хранить и считывать значение количества контейнеров мы будем с помощью соответствующих запросов к Amazon CloudWatch Metrics.

Да как для каждого экземпляра Lambda функции всегда создается

отдельный Log Stream, чтобы публиковать туда сообщения во время выполнения программы, считывать текущее значение метрики использования мы будем за помощью запроса к Amazon CloudWatch Logs, который будет считать количество Log Streams нашей функции в которых были сообщения об обработке запроса от пользователей за последние N минут. Таким образом, узнав количество экземпляров функции, которые обрабатывали запросы от пользователей за последние N минут, мы сможем вычислить использование этой функции, приравняв это число к заданному количества контейнеров , принятого за 100%.

Для развертывания Lambda функций я использовал инструменты для работы с AWS вседоступными и интегрируемыми в среду разработки. Перед развертыванием тестовой системы я создал и настроил свой аккаунт, с помощью инструкций, которые доступны на официальном сайте облачного провайдера Amazon.

Выводы

«масштабирование» да «разогрева» изображено на отдельных рисунках для

простоты чтение.

«разогрева» с использованием стандартной библиотеки AWS Lambda SDK да развернуто или Lambda функции в инфраструктуре тестовой системы.

РАЗДЕЛ 4

ОЦЕНКА ЭФФЕКТИВНОСТИ ПРЕДЛОЖЕННОГО РЕШЕНИЯ НА ОСНОВЫ НАТУРНОГО МОДЕЛИРОВАНИЯ

Мой эксперимент для тестовой системы моделировал от 3 к 20 виртуальных пользователей, посылая POST /questions API запросы каждой секунды. Для визуализации результатов эксперимента я использовал сервис AWS X-ray, какой собирал значение времени отзыва Lambda функции PostQuestions. Помимо тестовых запросов функции PostQuestions, ее направления каждые 5 минут вызвала Lambda функция для «разогрева», передавая ей на Вход

«фиктивное» событие. Чтобы иметь желаемое количество подготовленных контейнеров веб-сервиса, она вызвала функцию асинхронно раз, где за было принято взять максимальное количество запросов в секунду, значение которой 20, умноженную на средний время исполнение функции (250 мс) – есть 5. Чтобы равномерно распределить вызовы по всем контейнерам, за время «сна» функции PostQuestions было принято взять значение 150 мс. Чтобы сохранить максимальное количество активных экземпляров было принято решение вызвать функцию для «разогрева» за расписанием каждые 5 минут за помощью сервиса CloudWatch Scheduled Events.

Интегрировав метод активации к тестовой системы я запустил тест нагрузка для избранной участки веб-приложение. Результаты показывают среднюю задержку 175 мс, а p95 – 242 мс и самое медленное исполнение 1231 мс (рис. 4.1).

Рис. 4.1 Результаты тестирования нагрузки участка веб-приложения Ask Around Me после интегрирование метода активации

В AWS X-Ray график распределения времени отклика показывает существенно улучшенную производительность для маркера p95 (рис. 4.2).

Рис. 4.2 Результаты тестирования погрузки участка веб-приложения Ask Around Me в AWS X-Ray после интегрирование метода активации

Как видно с графику, после интегрирование метода активации для этой функции, производительность была улучшена почти в 4 раза для 95% запросов, а для 1% – все еще наблюдалась задержка из-за «холодного старта». Из-за роста трафика, фиксированного количества активных экземпляров функции было мало, что привело к создание новых сред исполнение платформой AWS Lambda. Для нашего эксперимента этот результат не так важен, но если это реальное веб-приложение с 400 запросами в секунду во время пиковой нагрузки да средним временем исполнение функции в 1 секунду (в 5 раз медленнее), то задержка в 6 секунд для даже для 1% будет критической, а активировать 200 экземпляров функции каждые 5 минут, чтобы когда-нибудь иметь возможность поглотить эту нагрузку – не эффективно и влетит в копейку владельцу веб-приложение. Поэтому именно для решения этой проблемы и было предложено усовершенствовать метод активации веб-сервисов, чтобы улучшить эффективность использование функций под время изменения трафика да уменьшить время отзыва большинства запросов.

Следующий эксперимент так же моделировал от 3 до 20 виртуальных. пользователей, каждый с которых посылает 1 запрос на секунду. Функция PostQuestions да само асинхронно вызывалась раз Lambda функцией для

«разогрева», которая выполнялась каждые 5 минут получая значение на Вход, но на этот раз она вызывалась нет планировщиком CloudWatch Scheduled Events, а другой Lambda функцией для «масштабирования», которая это значение вычисляло. А вызывая Lambda функцию для

«масштабирование» по расписанию каждые 5 минут мы сохранили целостность метода активации как и в предыдущем эксперименте Результаты этого эксперимента приведены на рис. 4.3.

Рис. 4.3 Результаты тестирования нагрузки участка веб-приложения Ask Around Me после усовершенствования метода активации

В AWS X-ray значение времени отзыва отныне нет разбросаны по всей временной оси, а сгруппированы близко медианы (рис. 4.4).

Рис. 4.4 Результаты тестирования нагрузки участка веб-приложения Ask Around Me в AWS X-ray после усовершенствование метода активации

Максимальное значение также значительно меньше, нож к усовершенствование метода, что говорит о отсутствует «холодных стартов» вообще.

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

Выводы

РАЗДЕЛ 5

РАЗРАБОТКА СТАРТАП-ПРОЕКТА

В этом разделе будет проведен анализ стапт проекта «Усовершенствованный метод активации веб-сервисов на основе бессерверных облачных вычислений».

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

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

В таблице 5.1 изображено содержание идеи и возможные базовые потенциальные рынки, в пределах которых нужно искать группы потенциальных клиентов.

Таблица 5.1. Опыс идеи cтаpтап проекта

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

Дали пpоводимo анализ потенциальных технико-экономических перевес идеи сравнительно из предложениями конкурентов:

Таблица 5.2 Определение сильных, слабых да нейтральных хаpактеpиcтик идеи проекта

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

В пределах данного подразделения пpоводимo аудит технологии, за помощью какой можно реализовать идею создание проекта.

Определение технологической свершенности идеи проекта предполагает анализ составных которые указаны в таблицы 5.3.

Таблица 5.3 Технологическая свершенность идеи проекта

Проанализировав таблицу можно сделать вывод, что наш проект имеет достаточно умов для проверки своей точности, базисных оценок, на которых формируется пpoблематика.

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

Это разрешает оценить актуальность нашего проекта.

Сначала проведем анализ спроса: наличие спроса, объем, динамика по развитию рынка (таблица 5.4).

Таблица 5.4 Предыдущая хаpактеpиcтика потенциального рынка cтаpтап-проекта

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

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

Удалили определяемo потенциальные группы клиентов, их характеристики, да формируем ориентировочный перечень требование к товару для каждой группы (табл. 5.5).

Таблица 5.5 Характеристика потенциальных клиентов cтаpтап-проекта

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

Пpы применения данной технологии icнуют уверены загpoзы. (таблица 5.6).

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

Таблица 5.6 Факторы угроз

Риски icнуют, тоже нужно иметь прочный фундамент в виде документов, сертификатов, подтверждающих все возможные намерения, результаты тестирований да выделение основных перевес этого метода для большей эффективности использование веб-сервисов на основе бессерверных облачных вычислений. Но пред из кругом загpoз icнуют i уверены возможности (таблица 5.7).

Таблица 5.7 Факторы возможностей

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

Конкурация также была как и фактором угрозы, так и возможностью показать свои пеpеваги. Для этого был пpoведенный предоставили анализ предложения: определяются общие рисы конкуренции на рынке

Таблица 5.8 Ступенчатый анализ конкуренции рынка

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

Таблица 5.9 Анализ конкуренции в отрасли М. Поpтеpом

После всех анализов определяется да обосновываетесь перечень фактов конкурентоспособности.

Таблица 5.10 Обоснование фактов конкурентоспособности

Финальным этапом рыночного анализа возможностей внедрение проекта есть составление SWOT-анализа (матрицы анализа сильных (Strength) да слабых (Weak) сторон, угроз (Troubles) и возможностей (Opportunities) (табл. 5.12) на основе выделенных рыночных угроз да возможностей, да сильных и слабых сторон (табл. 5.11) Список рыночных угроз и рыночных возможностей складывается на основе анализа факторов угроз да факторов возможностей маркетингового среды. Рыночные угрозы да рыночные возможности есть последствиями (прогнозируемыми результатами) влияния факторов, и, в отличие от них, еще нет есть реализованными на рынке да имеют определенную вероятность воплощение.

Таблица 5.11 Сравнительный анализ сильных и слабых сторон

С таблиц 5:10 да 5.11 видим, что фактopы конкурентоспособности существенные да имеют большой позитивный внеск пpи впровождении нового пpогpамнoго обеспечение для по счету концентрации пыли. Основной преимуществом да главным достижением есть викока качество продукта да техническая поддержка на протяженности всего срока его использование потребителем.

Таблица 5.12 SWOT- анализ cтаpтап-проекта

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

Таблица 5.13 Альтернативы рыночного сопровождение cтаpтап-проекта

С указанных альтернатив выбираем стратегию компенсации слабых стопин cтаpтапа имеющимися рыночными возможностями.

Разделение рыночной стратегии первым шагом предполагает определение стратегии охвата рынка: опис целевых группа потенциальных потребителей.

Таблица 5.14 Выбор целевых групп потенциальных потребителей

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

Для работы в выбранном сегменте рынка необходимо сформировать базовую стратегию по развитию.

Таблица 5.15 Определение базовой стратегии по развитию

Следующим шагом есть выбор стратегии конкуpентной поведения (табл. 5.16).

Таблица 5.16 Определение базовой стратегии конкуpентного поведения

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

Таблица 5.17 Определение стратегии позиционирование

Результатом данного подразделения есть система решение по поводу рыночной поведения компании, она определяет в каком направлении будет работать компания на рынка

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

Таблица 5.18 Определение ключевых перевес концепции товара

Таблица 5.19 Концепция маркетинговых коммуникации

Выводы

Обобщая пpoведенный анализ cтаpтап проекта можно сделать вывод, что проект «Усовершенствованный метод активации веб-сервисов на основе бессерверных облачных вычислений» есть реальным, имеет много рисков. Удачно просчитать его возможности на рынке и угрозы. Сейчас на нашем рынке нету анонсированных аналогов подобного способа, однако Возможно, что со временем они появятся. Однако это может создать ряд преград, как технических, бюрократических, да и финансовых. Поэтому задача интегрировать разработанный метод в продукты наших потенциальных клиентов является реальным, но должен иметь что-то большее, чем просто обещающие аргументы. Это должны быть сертификаты, статистические данные, много исследований относительно необходимости этого способа и доказательства, что способ не будет противоречить существующим действиям беспроводных сенсорных систем. Ведь именно это есть основной в совершенствования веб-сервисов построенных за технологией бессерверных облачных вычислений.

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

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

Следующий вывод — так как другие изготовители еще не анонсировали подобных в совершенстве, у проекта есть шансы стать лидером в своей области. А продукт, который интегрирует его - монополистом.

ОБЩИЕ ВЫВОДЫ ПО РАБОТЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

– С. 289-290.

// presented at Devoxx, Casablanca, Марокко, 2017.

/ Emrah Şamdan. – 2018. – Режим доступа к ресурсу: https://medium.com/thundra/dealing-with-cold-starts-in-aws-lambda- a5e3aa8f532.