РЕФЕРАТ

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

источники.

Актуальность работы : Метод активации разрешает обеспечить

сверхнизкую задержку в работе с веб-сервисами на основе бессерверных

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

определенного веб-сервиса вы хотите держать активными и она справится с

масштабированием за вас. С временем трафик веб-сервиса может

увеличиться, а это значит, что нужно удерживать больше активных

экземпляров, или меньше, если напротив. Нужно иметь некоторый

коэффициент масштабирование, какой будет автоматически Вычисляться

учитывая текущий трафик веб-сервиса. Это позволит более эффективно

использовать веб-сервисы на основе бессерверных облачных вычислений и

уменьшить операционные затраты.

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

бессерверных облачных вычислений.

Предмет исследование : Метод активации веб-сервисов на основе

бессерверных облачных вычислений.

Цель работы : Усовершенствовать метод активации веб-сервисов на

основе бессерверных облачных вычислений для повышение эффективности

их использование.

Для достижения цели исследования были поставлены и решены

следующие основные задачи:

1. Провести анализ проблем эффективности использования веб-

сервисов на основе бессерверных облачных вычислений и обзор

существующих их методов решения.

2. Проанализировать существующие методы улучшение

эффективности использование веб-сервисов на основе бессерверных

облачных вычислений да сформировать подход к автоматического

вычисление коэффициента масштабирование.

3. Усовершенствовать метод активации веб-сервисов на основе

бессерверных облачных вычислений за счет автоматического

вычисления коэффициента масштабирование.

4. Оценить эффективность предлагаемого решения на основе натурного

моделирование.

5. Разработать стартап-проект.

на основе проведенного анализа обнаружено проблему низкой

эффективности использование веб-сервисов на основе бессерверных

облачных вычислений. Анализ показал, что одним из способов повышения

эффективности использование есть усовершенствование метода активации

веб-сервисов на основе бессерверных облачных вычислений.

Усовершенствовав метод активации, за счет автоматического вычисление

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

повысить эффективность использования этого веб-сервиса, что было

подтверждено результатами проведенного анализа За результатами работы

было разработано стартап-проект для оценки затрат на реализацию метода

активации да возможного прибыли от его усовершенствование.

Научная новизна: Предложен подход к автоматическому вычислению

коэффициента масштабирование какой базируется на измерении трафика

веб- сервиса, что позволит повысить эффективность использования веб-

сервисов на основе бессерверных облачных вычислений.

Практическая ценность: Результаты исследования

обеспечивают уменьшение операционных затрат на внедрение метода

активации веб- сервисов на основе бессерверных облачных

вычислений и более эффективное использование облачных ресурсов

Методы исследования : Основными методами

исследования являются математическое да имитационное

моделирование.

Ключевые слово: бессерверные вычисление, FaaS, трафик веб-

сервиса, эффективность использование, время отзыва, холодный старт, метод

активации, динамическое масштабирование, асинхронные вызовы,

тестирование нагрузка, AWS Lambda.

4 
 
СОДЕРЖАНИЕ 
ВВЕДЕНИЕ  ................................................................................................. 11 
РАЗДЕЛ 1  .................................................................................................... 12 
АНАЛИЗ ПРОБЛЕМ ЭФФЕКТИВНОСТЬ ИСПОЛЬЗОВАНИЕ ВЕБ- 
СЕРВИСОВ НА ОСНОВЫ БЕЗСЕРВЕРНЫХ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ 
ТА ОБЗОР СУЩЕСТВУЮЩИХ МЕТОДОВ их РЕШЕНИЕ  ......................... 12 
1.1. Анализ проблем эффективности использование веб-сервисов на 
основе бессерверных облачных вычислений  ..................................................... 12 
1.2. Обзор существующих методов решение проблем 
эффективности использование  .......................................................................... 16 
7 
Выводы  ........................................................................................................ 19 
РАЗДЕЛ 2  ...................................................................................................... 21 
АНАЛИЗ СУЩЕСТВУЮЩИХ МЕТОДОВ УЛУЧШЕНИЕ 
ЭФФЕКТИВНОСТЬ ИСПОЛЬЗОВАНИЕ  И  ФОРМИРОВАНИЕ  ПОДХОДА 
К  АВТОМАТИЧЕСКОМУ ВЫЧИСЛЕНИЕ КОЭФИЦИЕНТА 
МАШТАБИРОВКА  ............................................................................................. 20 
2.1. Сравнение методов повышение эффективности использование на 
примере платформы AWS Lambda  ...........  
2.2. Формирование подхода к автоматического вычисление 
коэффициента масштабирование на примере AWS Lambda  ............................ 27 
Выводы  ........................................................................................................ 28 
РАЗДЕЛ 3  ...................................................................................................... 30 
СОВЕРШЕНСТВОВАНИЕ МЕТОДА АКТИВАЦИИ ВЕБ-СЕРВИСОВ 
НА ОСНОВЫ  БЕЗСЕРВЕРНЫХ  ОБЛАЧНЫХ  ЗА  СЧЕТ 
АВТОМАТИЧЕСКОГО ВЫЧИСЛЕНИЕ КОЭФИЦИЕНТА 
МАШТАБИРОВКА  ............................................................................................. 30 

5 
 
3.1. Архитектура тестовой системы  ......................................................... 30 
3.2. Интегрирование метода активации веб-сервисов к тестовой 
системы да его усовершенствование  .................................................................. 31 
3.3. Реализация механизма автоматического вычисление 
коэффициента масштабирование активных экземпляров функций тестовой 
системы  34 
Выводы  ........................................................................................................ 43 
РАЗДЕЛ 4  ...................................................................................................... 44 
ОЦЕНКА  ЭФФЕКТИВНОСТИ 
 ПРЕДЛАГАЕМОГО РЕШЕНИЕ НА ОСНОВЫ НАТУРНОГО 
МОДЕЛИРОВАНИЕ  44 
4.1. Анализ  эффективности  использования  и  измерения  времени 
отклика веб-сервисов тестовой системы  .................. Ошибка! Закладка нет 
определена. 5 
4.2. Анализ эффективности использование да времени отзыва веб-
сервисов тестовой  системы  после  усовершенствования  метода  активации 
Ошибка! Закладка не определена. 
Выводы  ........................................................................................................ 49 
РАЗДЕЛ 5  .................................................................................................... 5 0 
РАЗРАБОТКА СТАРТАП-ПРОЕКТА  ....................................................... 54 
Выводы  ...................................................................................................... 59  
ОБЩИЕ ВЫВОДЫ ПО РАБОТЫ  ............................................................ 60  
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ  ................................ 64  

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

API

Application Programming Interface

AWS

Amazon Web Services

EC2

Amazon Elastic Compute Cloud

ENI

Elastic Network Interface

FaaS

Function as a Service

Amazon Simple Storage Service

SNS

Amazon Simple Notification Service

Virtual Machine

VPC

Virtual Private Cloud

ВВЕДЕНИЕ

Бессерверные вычисление есть горячей темой в мире архитектуры

программного обеспечение. под этой названием понимают программное

обеспечение, какое включает программы да службы, размещены в облака,

для управление логикой и состоянием сервера. Как правило, это различные

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

данных, служб аутентификации тому подобное. Поставщики облака

предлагают вычислительные среды, известные как FaaS-платформы, где

запускается код таких программ. Название «бессерверное» появилось

потому, что решение по управлению сервером и планированию мощностями

веб-сервисов скрытые от разработчика или оператора. Это значит, что вам,

нет придется иметь дело с сервером самостоятельно. Существуют очевидны

преимущества таких программ в сравнить с традиционными, но есть и

недостатки, такие как «холодный старт», несмотря на существующие методы

оптимизации все еще остаются серьезными проблемами.

Метод активации разрешает обеспечить параллельность веб-сервисов

на основе бессерверных облачных вычислений. Вы передаете программе

сколько экземпляров определенного веб-сервиса вы хотите держать

активными постоянно и она справится с масштабированием за вас. Это

позволяет использовать веб- сервисы со сверхнизкой задержкой и без

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

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

если трафик уменьшился. Нужно иметь некоторый коэффициент

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

текущий трафик веб-сервиса. Это позволит более эффективно использовать

экземпляры веб-сервиса на основе бессерверных облачных вычислений и

уменьшить операционные затраты. Работа выполнена в рамках ГДР кафедры

№0119U001184: "Гетерогенная сеть сбора, передачи и обработки

информации для системы распределенной генерации MicroGrid." да

№0116U005092

«Повышение эффективности обработки данных со потребительских

устройств в телекоммуникационной сети Интернета вещей».

РАЗДЕЛ 1

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

СЕРВИСОВ НА ОСНОВЕ БЕЗСЕРВЕРНЫХ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ

И ОБЗОР СУЩЕСТВУЮЩИХ МЕТОДОВ ИХ РЕШЕНИЕ.

1.1. Анализ проблем эффективности использование веб-сервисов на

основе бессерверных облачных вычислений

В общем случае, бессерверные вычисления означают программы, где

серверная логика все еще пишется разработчиком, но, на отличие от

традиционных систем, они выполняются в контейнеры, которые нет

сохраняют своего состояния после вызова, которые вызываются событием

(HTTP запрос, запись в базе данных, сообщения в очереди/канале),

эфемерные (могут продолжаться только в рамках одного вызова) и

полностью управляются третьей стороной (облачным провайдером). Поэтому

их еще называют «функциями». Объяснение:

1. Клиент делает запрос на платформу бессерверных вычислений

для исполнение определенной функции (сервиса).

2. Платформа бессерверных вычислений сначала проверяет, или

выполняется функция на любом из ее серверов. Если функция

еще нет запущена, то платформа загружает код этой функции со

хранилища.

3. Платформа затем развертывает функцию на одном из своих

серверов, которые предварительно настроены со средой

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

4. Платформа выполняет функцию и фиксирует результат.

5. Платформа возвращает результат назад клиенту.

Платформа бессерверных вычислений, такая как AWS Lambda,

разрешает сохранять код ваших веб-сервисов и развертывать их без

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

инициализирует новые экземпляры функций только на требование (англ. on-

demand). Каждый раз, когда платформа получает запрос, но у нее нет

активных экземпляров функции, она назначает ему новый. Затем этот

экземпляр функции должен скачать код функции или файл с кодом да

отгрузить их в память, прежде чем он сможет обработать запрос. Процесс

инициализации кода требует времени, что значительно увеличивает задержку

ответы[3].

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

последовательность шагов, которые совместно называются «холодный

старт»:

1. Платформа выделяет базовый ресурс VM для размещение вашей

функции.

2. Платформа создает контейнер Linux на выделенной VM, в

котором будет запускаться ваш код.

3. Платформа прикрепляет ENI к контейнера, если вы указали

использовать VPC.

4. Платформа копирует код к контейнера, какой вы

предоставили под время развертывание.

5. Платформа запускает среда исполнение, какое вы указали, в в

пределах контейнера.

6. Среда исполнение запускает код вашей функции.

Холодный старт необходимый, когда нету доступного контейнера для

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

1. Когда меняется код или конфигурация функции (в поэтому

числе, когда разворачивается первая версия функции).

2. Когда все предыдущие контейнеры были «утилизированные» через

возраст.

3. Когда все предыдущие контейнеры утилизировались через

неактивность.

4. Когда функции нужно масштабироваться, поэтому что все

текущие контейнеры для необходимой функции уже возделывают

события.

В то время как первые 2 случаи неизбежны, последних можно

избежать, заставив функцию обработать фиктивные «пинг» события [1],

распределив их на нужное количество контейнеров финкции с помощью

параллельных вызовов этой функции и повторяя это периодически – этот

метод называется «Метод активации веб-сервисов на основе бессерверных

облачных вычислений». Идея метода состоит в том, чтобы иметь событие в

срабатывающем планировщике каждые N минут и посылает M асинхронных

запросов нужной функции (рис. 1.2). Если все или запросы попадают

одновременно, платформа должна обеспечить по меньшей мере M

экземпляров функции для их обработки. Фактический операция «активации»

не должна выполнять никакой полезной работы, т.е. бизнес-логики, но она

сбрасывает таймер утилизации назад к нулю.

Через некоторое время нагрузка на вашу функцию может увеличиться

и как следствие платформа начнет создавать новые среды исполнение на

требование чтобы поглотить эту нагрузку, что приводит к увеличению

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

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

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

Вам также может потребуется уменьшить количество экземпляров функции,

если трафик следует за шаблоном вниз, чтобы уволить ресурсы да уменьшить

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

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

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

вручную, можно усовершенствовать метод активации таким образом, чтобы

коэффициент масштабирования вычислялся автоматически, учитывая

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

Совершенствование метода активации позволит улучшить

эффективность использование веб-сервисов на основе бессерверных

облачных вычислений за счет автоматического масштабирования

экземпляров этих веб-сервисов во время изменения трафика, при этом, держа

значение времени отзыва веб-сервиса низким.

1.2. Обзор существующих методов решение проблемы

эффективности использование веб-сервисов на основе

бессерверных облачных вычислений

Известно, что «холодный старт» случается, когда вы впервые

вызываете функцию или когда функция вызывается после длительной

неактивности. Они также встречаются, когда платформа масштабирует

функцию, поскольку каждый новый экземпляр функции есть новой средой

исполнение.

Раньше бессерверное общество создавало программы для активации

функций [1], чтобы повысить вероятность обработки запроса существующим

средой исполнение. Это хороший подход для разработки да тестирование

стабильных систем (рис. 1.3), или там, где вам не нужна гипер-готовность

функций.

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

сервисов на основе бессерверных облачных вычислений

Однако для многих клиент-ориентированных систем нагрузки сильно

колеблются. Для нестабильных систем, которые нуждаются низкой задержки

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

этой функции, чтобы увеличить или уменьшить количество активных

экземпляров соответственно.

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

Довольно часто увеличение частоты запросов частично предсказуемо.

Например, использование увеличивается в рабочее время и уменьшается

ночью, или это может быть любой другой период времени в зависимости от

бизнеса. Увеличивая количество активных экземпляров функции в нужный

момент времени, как изображено на рис. 1.4, можно избежать

дополнительной задержки через

«холодный старт» да обеспечить лучший опыт для конечных

пользователей. А благодаря возможностям планировщика, такого как Amazon

CloudWatch Events, можно автоматизировать изменение количества активных

экземпляров функции на определенную дату или время.

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

изменению нагрузка функции

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

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

автоматическое масштабирование активных экземпляров функций на основе

измеренного использования этой функции, как показано на рис. 1.5. Этот

метод предполагает наблюдение за вызовами функции, анализ и сохранение

статистики в виде числовых метрик. После этого можно находить

коэффициент масштабирование, есть увеличивать или уменьшать количество

активных экземпляров функции на основе метрики использование их

использование.

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

нагрузки функции

Недостаток метода состоит в том, что появляются дополнительные

операционные. расходы на наблюдение, анализ да сохранение данных

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

коэффициента масштабирование, которые можно минимизировать в

зависимости от реализации.

Выводы

1. Проведено анализ проблем эффективности использование веб-

сервисов на основе бессерверных облачных вычислений Определено,

что главными проблемами есть «холодный старт» да

непредсказуемость трафика реальных систем

2. Рассмотрено существующие методы решение проблем

эффективности использование веб-сервисов на основе облачных

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

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

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

использования, а для предполагаемого – подходит профиль

планируемого масштабирования.

РАЗДЕЛ 2

АНАЛИЗ СУЩЕСТВУЮЩИХ МЕТОДОВ ДЛЯ

УЛУЧШЕНИЯ ЭФФЕКТИВНОСТЬ ИСПОЛЬЗОВАНИЕ

ВЕБ-СЕРВИСОВ ТА

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

КОЭФИЦИЕНТА МАШТАБИРОВКА

2.1. Анализ существующих методов улучшение эффективности

использование веб-сервисов на основе бессерверных облачных

вычислений

Масштабирование активных экземпляров функций разрешает

подготовить среды выполнения до получения реального трафика Метод

активации веб-сервисов на основе бессерверных облачных вычислений,

кроме загрузки кода функции, также запускает код инициализации за

пределами основного обработчика бизнес-логики функции. Это

обеспечивает надежный способ поддерживать функции готовыми в течении

двузначной задержки в миллисекундах к возможности реагирования на

реальные запросы от пользователей. Все активные экземпляры функции

(независимо от среды выполнение) обрабатывают запросы скорее, нож новые

экземпляры, которые были созданные платформой на требование, чтобы

поглотить погрузки. Конечно, такие среды исполнение как 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 мс

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

эффективность функции.

Вместо этого того, чтобы резервировать фиксированную количество

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

масштабирование, которое будет увеличивать количество асинхронных

«пинг» вызовов для метода активации под время роста трафика функции и

будет уменьшать – в противном случае, тем самым улучшая эффективность

использования экземпляров этой функции нет жертвуя при этом временем

отзыва.

Нужно разработать подход к автоматическому вычислению

коэффициента масштабирование активных экземпляров функции да

усовершенствовать существующий метод активации веб-сервисов на основе

бессерверных облачных вычислений.

2.2. Формирование подхода к автоматическому вычислению

коэффициента масштабирование

Метод активации основывается на асинхронной отправке программой

фиктивных «пинг» запросов к функции, которую нужно активировать, то

есть иметь активных экземпляров этой функции. Из-за некоторый время

бездействия функции

FaaS платформа начнет утилизировать активные экземпляры, чтобы

освободить облачные ресурсы Чтобы постоянно держать экземпляры

функции активными нужно регулярно отправлять асинхронных запросов к

ней. Значение и уникальные идентификаторы функций передаются на Вход

программы, какая периодически запускается средствами планировщика.

Значение сдается вручную да равно среднем времени исполнение функции,

умноженному на рабочее нагрузка функции во время пика плюс некоторый

остаток на буфер. Чтобы автоматически вычислять нужно также принимать

во внимание текущий трафик рассматриваемой функции является достаточно

не тривиальной задачей и требует значительных операционных ресурсов

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

активных экземпляров функции мы можем делать выводы относительно

текущего трафика этой функции в целом [2].

Например, мы хотим держать использование активных экземпляров

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

стабильно превышает 77% (110% от запланированных 70%) что

соответствует изменению трафика функции по шаблону вверх, мы можем

увеличить значение на коэффициент масштабирование , где

для активации большей количества экземпляров, а когда текущее

использование экземпляров функции стабильно меньше 63% (90% от

запланированных 70%) что соответствует изменению трафика функции по

шаблону вниз, то мы можем уменьшить значение на коэффициент

масштабирование , где

В результате новое значение количества активных экземпляров

функции будет примерно равняться или соответственно, а

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

(≥ 77% или ≤ 63%) теперь будет примерно

отвечать заданном , есть 70%.

Реализация подобной метрики использование активных экземпляров

функции в значительной степени зависит от выбранной FaaS платформы,

архитектуры системы (какие облачные ресурсы вам доступны) и среды

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

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

метрики да использовать его для дальнейшего вычисление коэффициента

масштабирования.

Выводы

1. Проанализированы различные методы повышения эффективности

использования веб-сервисов на основе бессерверных облачных

вычислений. на основе проведенного анализа был выбран профиль

динамического масштабирования для усовершенствование метода

активации веб-сервисов на основе бессерверных облачных

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

которых трафик непредсказуем.

2. Предложено подход к автоматического вычисление коэффициента

масштабирование. Определено, что создав метрику использование

активных экземпляров функции мы можем делать выводы

относительно текущего трафика этой функции да увеличивать или

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

метода активации на коэффициент масштабирования.

РАЗДЕЛ 3

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

ОСНОВЫ БЕССЕРВЕРНЫХ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ ЗА СЧЕТ

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

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

3.1. Архитектура тестовой системы

В этом разделе будет показано, как устранить задержку «холодного

старта» в бессерверных архитектурах, поддерживающих реальные веб-

приложения из непредсказуемым трафиком, при этом, улучшив

использование их экземпляров за счет динамического масштабирования. Как

пример системы, я буду использовать веб-приложение Ask Around Me

размещенный в инфраструктуре Amazon, который уже упоминался ранее. Эта

система позволяет пользователям задавать и отвечать на вопросы в своем

географическом регионе. Веб-приложение использует архитектуру какая

изображена на рис. 3.1.

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

По-прежнему я буду проверять только часть веб-приложения Ask

Around Me, которая отвечает за создание вопросов и архитектура которой

изображена на рис. 3.2.

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

Так как нас интересуют только функции влияющие на время отклика

веб- приложении, то нам нужно «активировать» Lambda функцию

PostQuestions, та же сама функция что фигурировала в предыдущем разделе

во время анализа

Тестировать наш участок системы мы будем с помощью API шлюза

POST /questions, какой будет передавать вызовы Lambda функции, да Artillery

Community Edition – инструмента с открытым кодом для тестирование

бессерверных API. Нужно только настроить количество запросов в секунду

да общую продолжительность теста, и программа сделает все за нас,

используя «безголовый» (англ. headless) браузер Chromium для запуска своих

тестовых потоков.

За сбор данных времени отзыва да создание диаграмм будут отвечать

службы Amazon CloudWatch Metrics и AWS X-Ray, результат работы

которых мы уже видели в предыдущем разделе.

3.2. Интегрирование метода активации веб-сервисов в тестовую

систему и его усовершенствование

Мы уже знаем экземпляры которой функции нужно активировать,

осталось решить «как именно» да «как часто» мы это будем делать. В

бакалаврской работе [1] я активировал функции каждые 5 минут (рис. 3.3),

чтобы нет даты платформе бессерверных вычислений утилизировать их

экземпляры, что было в полной мере достаточно. Фиксированное значение

асинхронных «пинг» вызовов сохранялось в конфигурации среды Warming

Lambda функции.

Да само как и в бакалаврской работе, в тестовой системе Lambda

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

Lambda функции PostQuestions (рис. 3.4), которая должна отличить

фиктивный вызов от настоящего запроса пользователя да подождать меньше

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

PostQuestions.

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

на этот раз значение асинхронных «пинг» вызовов нет будет

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

иметь смогу изменять значение без изменения конфигурации функции для

«разогрева» (ведь при смене конфигурации, меняется версия функции да

создается новый контейнер) мы будем передавать его в теле запроса, но уже

нет от планировщика CloudWatch Scheduled Events, а другой Lambda

функции для «масштабирование», какая это значение будет вычислять. А

вызывая Lambda функцию для «масштабирование» за расписанием каждые N

минут мы сохраним целостность метода активации функции PostQuestions

тестовой системы.

Остается только реализовать механизм за помощью которого значение

будет автоматически вычисляться принимая к внимания метрику

использование активных экземпляров функций тестовой системы.

3.3. Реализация механизма автоматического вычисление

коэффициента масштабирование активных экземпляров функций

тестовой системы

Мы уже знаем, чтобы предотвратить утилизацию экземпляров

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

Конечно, нужно внести необходимы изменения в нашу функцию

PostQuestions тестовой системы, чтобы различать «пинг» события да

настоящие запросы клиентов [1]. Благодаря запросам на

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

активными, но не все так просто.

Так как мы используем функцию PostQuestions в производстве (для

настоящих клиентов), нужно сделать асинхронных запросов на «разогрев»,

чтобы сохранить активных контейнеров. на этом этапе существуют два

риски:

– Вы держите все ваши контейнеры занятыми обработкой

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

Найти место для исполнение. Это приведет «холодный старт»

для подлинного вызова.

– Функция в одному контейнере может задержать все вызовы

одновременно, если они достаточно быстро обрабатываются, и

это может сделать другие контейнеры неактивны через

некоторый время.

Чтобы решить или проблемы, мы должны немного подождать на

стороне функции, то есть приостановить главный поток функции на время.

Таким Таким образом, один экземпляр функции не поймает все "пинг"

запросы. А заставив главный поток ожидать не более 150 мс, мы убедимся

что блокируем только шестую часть вызовов за секунду.

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

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

«разогрева» нашей тестовой системы. Как мы уже знаем она имеет уметь делать

следующее:

1. Принимать запрос от Lambda функции для «масштабирование»

с параметром в теле запроса.

2. Асинхронно вызвать заданные Lambda функции передавая им

на Вход «фиктивную» событие.

3. Сообщать о результат операции.

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

1. Принять на Вход объект тела запроса.

2. Считать данные с объекта тела запроса, которые содержат

список с идентификаторов функций да количества контейнеров

для них.

3. Выполнить процесс «разогрева» на основе этих данных.

4. Если операция прошла нет успешно, то залоговать сообщение об

ошибке.

И как потоки будут выполняться одновременно то в конце достаточно

будет только залоговать результат операции. В результате, операция

«разогрева» завершится тогда когда закончит свое исполнение последний

поток.

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

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

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

следующее:

1. Принимать запрос от планировщика CloudWatch Scheduled Events.

2. Вычислять значение метрики использования

активных экземпляров за последние N минут для

каждой функции.

3. Вычислять значение коэффициента масштабирование X да

значение количества контейнеров для каждой функции.

4. Хранить новое значение количества контейнеров для каждой

функции.

5. Вызвать Lambda функцию для «разогрева».

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

1. Принять на Вход объект тела запроса.

2. Считать данные с объекта тела запроса, которые содержат

список с идентификаторов функций да начальной количества

контейнеров для каждой с них.

3. Достать сохраненные значения количества контейнеров для

каждой функции из CloudWatch Metrics. Если их нет, то

использовать начальные значение количества контейнеров .

4. Вычислить значение метрики использования активных

экземпляров каждой функции за последние N минут,

коэффициент масштабирования и новое значение количества

контейнеров , при этом, сохранив его как метрику для каждой

функции в CloudWatch Metrics да перезаписав старое значение в

объекте тела запроса.

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

объект тела запроса.

6. Если операция прошла нет успешно, то залоговать сообщение об

ошибке.

Хранить и считывать значение количества контейнеров мы будем с

помощью соответствующих запросов к Amazon CloudWatch Metrics.

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

отдельный Log Stream, чтобы публиковать туда сообщения во время

выполнения программы, считывать текущее значение метрики использования

мы будем за помощью запроса к Amazon CloudWatch Logs, который будет

считать количество Log Streams нашей функции в которых были сообщения

об обработке запроса от пользователей за последние N минут. Таким

образом, узнав количество экземпляров функции, которые обрабатывали

запросы от пользователей за последние N минут, мы сможем вычислить

использование этой функции, приравняв это число к заданному количества

контейнеров , принятого за 100%.

Для развертывания Lambda функций я использовал инструменты для

работы с AWS вседоступными и интегрируемыми в среду разработки. Перед

развертыванием тестовой системы я создал и настроил свой аккаунт, с

помощью инструкций, которые доступны на официальном сайте облачного

провайдера Amazon.

Выводы

1. Поставлена задача усовершенствовать метод активации веб-сервисов

на основе бессерверных облачных вычислений и интегрировать его в

тестовую системы.

2. Разработано программу Lambda функции для «разогрева», какая

будет асинхронно вызвать функции тестовой системы раз. Разработано

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

вычислять значение асинхронных «пинг» вызовов на основе метрики

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

«разогрева». Блок-схемы алгоритма программ функций для

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

рисунках для

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

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

да

«разогрева» с использованием стандартной библиотеки AWS Lambda

SDK да развернуто или Lambda функции в инфраструктуре тестовой

системы.

РАЗДЕЛ 4

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

ОСНОВЫ НАТУРНОГО МОДЕЛИРОВАНИЯ

4.1. Анализ эффективности использование да измерение времени

отзыва веб-сервисов тестовой системы

Мой эксперимент для тестовой системы моделировал от 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 минут, чтобы когда-нибудь иметь возможность поглотить

эту нагрузку – не эффективно и влетит в копейку владельцу веб-приложение.

Поэтому именно для решения этой проблемы и было предложено

усовершенствовать метод активации веб-сервисов, чтобы улучшить

эффективность использование функций под время изменения трафика да

уменьшить время отзыва большинства запросов.

4.2. Анализ эффективности использования и времени отклика веб-

сервисов тестовой системы после усовершенствование метода активации

Следующий эксперимент так же моделировал от 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 функцию, которая будет изменять их количество автоматически,

используя минимум ресурсов

Выводы

1. Проведен обзор результатов измерения времени отклика веб-

сервисов. тестовой системы в течении. Определено влияние

«холодного старта» на веб-сервисы тестовой системы.

2. Проанализировано результаты измерение времени отзыва веб-

сервисов тестовой системы после усовершенствования метода

активации. Определено, какие факторы посодействовали получению

таких результатов.

3. Проведено сравнение результатов измерение времени отзыва веб-

сервисов существующей системы до и после усовершенствования

метода активации веб-сервисы. Определено, что после

усовершенствование метода активации нагрузка на веб-сервисы

поглощается эффективнее, за счет динамического масштабирование.

Построено графики распределения значений времени отзыва функций

тестовой системы к да после усовершенствование.

РАЗДЕЛ 5

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

В этом разделе будет проведен анализ стапт проекта

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

облачных вычислений».

Стартап как форма малого рискового (венчурного) предпринимательства

на протяжении последнего десятилетие приобрела широкого распространение в

мире из-за снижения барьеров входа в рынок (с появлением Интернета как

инструмента коммуникаций да сбыта стало проще находить потребителей да

инвесторов, заниматься поиском ресурсов, пересекать границы между рынками

разных стран), и считается одной из краеугольных составляющих

инновационной экономики, поскольку счет мобильности, гибкости и большого

количества стартап-проектов общая масса инновационных идей растет.

1.1 Опыс идеи проекта

Идея проекта состоит в использование функции масштабирование для

автоматического вычисление коэффициента масштабирование веб-сервисов да

их активации, что уточнено в таблицы 5.1.

В таблице 5.1 изображено содержание идеи и возможные базовые

потенциальные рынки, в пределах которых нужно искать группы

потенциальных клиентов.

Таблица 5.1.

Опыс идеи cтаpтап

проекта

Содержание идеи

Направления применение

Выгоды для пользователя

Использование

Веб-приложения

построены за

Новый метод улучшает

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

технологией бессерверных

эффективность веб-сервисов по

динамической активации

веб-

облачных вычислений

счет уменьшение времени отзыва.

сервисов на основе

Предложенный алгоритм

бессерверных облачных

улучшает использование

вычислений.

экземпляров этих веб-сервисов

при

активации.

Итак, предлагается усовершенствованный метод активации веб-сервисов

на основе бессерверных облачных вычислений Общей целью предложенного

решения является автоматическое увеличение количества экземпляров веб-

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

Итак, он укорачивает эффективность веб-сервисов в целом по сравнению с

методом активации, за счет автоматическое вычисление коэффициента

масштабирования этих веб-сервисов. Таким образом, это также указывает на то,

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

метод активации какой было взято за основу.

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

идеи сравнительно из предложениями конкурентов:

 определяемo перечень технико-экономических свойств да

хаpактеpиcтик идеи;

 определяем предыдущее круг конкурентов (проектов-конкурентов)

или товаров-заменителей или товаров-аналогов, которые уже существуют на

рынке, и производим сбор информации по значениям технико-экономических

показателей для идеи собственного проекта да проектов-конкурентов

соответствующе до определенного выше перечня;

 пpоводимo сравнительный анализ показателей: для собственной

идеи определены показатели, что имеют

 а) худшие значение (W, слабости);

 б) аналогичные (N, нейтральные) значение;

 в) лучшие значение (S, сильные) (табл. 5.2).

Таблица 5.2

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

проекта

№

Технико-

экономические

хаpактеpиcтики

идеи

(потенциальные)

товары/концепции

конкурентов

Усовершенство

ванный

Метод

активации

Улучшение

использование веб-

сервисов при смене

нагрузка

Более

эффективн

ый

Средний

Уменьшение время

отзыва веб-сервиса

Увеличенный

Средний

Увеличение

операционн

ых

расходов

Средний

Усложнение

архитектур

ы системы

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

что предложенный алгоритм справляется с изменением нагрузки веб-сервиса

лучше. Следовательно, эффективность веб-сервисов в целом улучшается.

методом активации, который был взят за основу, за счет динамической

активации экземпляров веб-сервисов тестовой системы.

1.2 Технологический аудит идеи проекта

В пределах данного подразделения пpоводимo аудит технологии, за

помощью какой можно реализовать идею создание проекта.

Определение технологической свершенности идеи проекта предполагает

анализ составных которые указаны в таблицы 5.3.

Таблица 5.3

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

проекта

№

п/п

Идея проекта

Технологии

ее

реализации

Наличие

технологий

Доступность

техно-логий

Метод активации

веб- сервисов на

основе

бессерверных

облачных

вычислений с

использованием

профиля

динамическог

масштабирова

ние

Статистика

Наяна

Доступная

Экспериментальные

исследования

В наличии

Доступная

Тестирование

В наличии

Доступная

Выбор технология реализации идеи проекта: налицо да доступная на рынка

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

достаточно умов для проверки своей точности, базисных оценок, на которых

формируется пpoблематика.

1.3 Анализ рыночных возможностей запуск cтаpтап проекта

Определим рыночные возможности, которые можно использовать во

время рыночного сопровождение проекта, да рыночные загpoзы, какой могут

перемешать его реализации.

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

Сначала проведем анализ спроса: наличие спроса, объем, динамика по

развитию рынка (таблица 5.4).

Таблица 5.4

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

проекта

№

Показатели состояния рынка

(наименование)

Характеристика

Число главных игроков, oд

Общий объем пpодаж, гpн/усл.

5000 гpн

Динамика рынка (качественно оценка)

Окончательно

Наличие ограничений для входа (указать

хаpактеp ограничений)

Наличие сертификата

соответствия

тех.pегламента

Сегодня норма pентабельности в отрасли (или по

рынка), %

20%

Рентабельность - понятие, что характеризует экономическую

эффективность производства, за которой за счет денежной выручки от

реализации продукции (работ, услуг) полностью возмещает затраты на ее

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

воспроизводства С данной таблицы можно сделать заключение, что рынок есть

привлекательным для вхождение за предварительным оценкой.

Целевая аудитория проекта — компании, которые используют

бессерверные. вычисление для веб-разработки. Этот рынок достаточно

широкий, поэтому его динамика есть именно содержащейся.

Удалили определяемo потенциальные группы клиентов, их

характеристики, да формируем ориентировочный перечень требование к товару

для каждой группы (табл. 5.5).

Таблица 5.5

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

проекта

№

п/п

Потребность, что

формирует

рынок

Целево

аудитори

(целевые

сегменты

рынка)

Отличия в

поведении

разных

потенциальных

целевых

группа

клиентов

Требования

Потребителей

к товара

Эффективность

веб- сервиса в

целом

Владельцы

веб- сервисов

построенных

за технологией

бессерверных

вычислений

Стоимость

проекта.

Уменьшенный

время отзыва веб-

сервиса

Эффективность

использование

экземпляров веб-

сервиса при

смене

нагрузка

Владельцы

веб- сервисов

которые

разогреваются

с помощью

метода

активации

Стоимость

проекта.

Повышение

эффективнос

ти

использовани

экземпляров веб-

сервиса

В связи с тем, что аудитория достаточно широкая, вызвать доверия

новыми решениями будет нет очень сладко. Но технология должна

действительно повышать эффективность использования экземпляров веб-

сервисов на основе бессерверных облачных вычислений. А как показывают

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

которого он был разработан.

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

Да как прямой потребитель - может быть как рядовой владелец веб-

сервисов, да и другие компании, согласование таких изменений в архитектуре

системы занимает богато ресурсов. Однако это не является единственной

проблемой.

Таблица 5.6

Факторы угроз

№

п/п

Фактop

Содержание загpoзы

Возможна реакция

компании

Спроса

Совершенствование может

оказаться нет настолько нужен.

Пеpеpахунок ваpтocтей для

подтверждение

эффективности

Экономическая

Собрание инфляции

Поиск возможностей

для дешевого

тестирование

Конкуренция

Возможно будет разработан

более эффективный

алгоритм

Увеличение проверок да

хороших отзывов

Научно-

техничес

кая

Быстрый развитие платформ

бессерверных вычислений

облачных провайдеров

Мониторинг научных

новостей да поиск новых

путей совершенствование

проекта

Риски icнуют, тоже нужно иметь прочный фундамент в виде документов,

сертификатов, подтверждающих все возможные намерения, результаты

тестирований да выделение основных перевес этого метода для большей

эффективности использование веб-сервисов на основе бессерверных облачных

вычислений. Но пред из кругом загpoз icнуют i уверены возможности (таблица

5.7).

Таблица 5.7

Факторы

возможностей

№

п/п

Фактop

Содержание

возможности

Возможна реакция

компании

Конкуренция

Нету аналогов

Увеличение объемов

интеграции

Экономическая

Уменьшение операционных

расходов

Снижение потенциалы

Спроса

Интеграция может

создавать перевес в

сочетании нескольких

систем

одновременно за ценой

одной

Вызов доверия

Природные и

экологические

факторы

Повышение потребности в

использовании

бессерверных вычислений

как более зеленой

технологии

Спрос

Сбыта

Уменьшение круг решение

до

одной компании

Закрепление за сбой

лидерства в отрасли

Некоторые угрозы могут служить факторами развития новых

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

дополнительных ресурсов для решение этих пpoблем.

Конкурация также была как и фактором угрозы, так и возможностью

показать свои пеpеваги. Для этого был пpoведенный предоставили анализ

предложения: определяются общие рисы конкуренции на рынке

Таблица 5.8

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

рынка

Обстоятельств

конкурентного

среды

В чем пpоявляется данная

хаpактеpиcтика

Влияние на деятельность

предприятия (возможны

действия компании, чтобы

быть

(конкурентоспособной)

Тип конкуренции:

олигополия

Небольшая количество фирм

на

рынка

Поддержка высокий качества

обслуживание

По уровню

конкурентной борьбы:

национальный

Многие системы

используют старый

инструменты

повышение

эффективности

Ведя конкуренцию на

национальном уровне,

компании необходимо

приложить соответствующие

усилия для охлаждение всего

национального рынка

По отраслевому

признаку:

внутриотраслевая

Стоит только отрасли

бессерверных облачных

вычислений

Необходимо сосредоточить

усилия на поиске

конкурентных перевесов,

какой разрешат компании

занимать стойкие

конкурентные позиции на

данному рынка

Конкуренция за

видами товаров:

товарно-

подова

Между другими

потенциальными

решениями

Улучшать рекламы

За хаpактеpом

конкуpентных

преимуществ: циново

Потребитель обращает

внимание на то, сколько

будет стоить

интеграция нашего

проекта в его продукт

Поиск подрядчиков, которые

бы выполнять работы

пpоцеcы за ниже цену

По

интенсивности:

морочно

Один известный

продукт бренда может

пpинеcть

продажи других

продуктов. Тоже появится

cенc

улучшать актуальные

продукты.

Набор всех необходимых

документов и данных для

легкой да удачной интеграции

Анализ подтверждает, что даже при своей специфике, наш проект требует

значительных усилий для того, чтобы войти в рынок, зафиксироваться и

предлагать свои возможности своим клиентам. И это как раз тот случай, когда

стоимость влияет на принятие решение.

Таблица 5.9

Анализ конкуренции в отрасли М.

Поpтеpом

Составля

ющие

анализа

Прямыми

конкуренты

в отрасли

Потенци-ине

конкуpен-ты

Поставщики

Клиенты

Товары-

заменител

Метод активации

Возможн

ы новые

методы

Работа сила,

элементы в

системами

совершенствов

ание

Ценно-

pения

Некачест

венные

заменител

Выводы

Нет высокой

конкуренции,

поскольку

разработан

метод

превосходит уже

существующие

решение, но есть

да называемое

«превосходство

пеpепpоходцев»

Новые

решение

потенциаль

но могут

иметь

предпочтен

ие над

разработан

ы м нами.

Клиенты

диктуют

основные

условия на

рынка

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

конкурентоспособности.

Таблица 5.10

Обоснование фактов конкурентоспособности

№

п/п

Фактop

конкурентоспособности

Обоснование (наведение факторов, что poблять

фактop для сравнение конкурентных проектов

значимым)

Цена

Цена интеграция влияет на принятие решение. А

наша цена выгоднее, чем в аналогов.

Актуальность

Совершенствуется метод, однако должен быть

важен основная, какая подтверждает

актуальность. I она

доказана нашим проектом.

Спрос

Наука развивается, как и информационные

системы. I

технология нет может быть несовременной.

Энергоэффективность

Наш метод есть наиболее эффективным на рынке.

Инновационность

Побить украинский науку на уровни с другими

странами.

Финальным этапом рыночного анализа возможностей внедрение проекта

есть составление SWOT-анализа (матрицы анализа сильных (Strength) да

слабых (Weak) сторон, угроз (Troubles) и возможностей (Opportunities) (табл.

5.12) на основе выделенных рыночных угроз да возможностей, да

сильных и слабых сторон (табл. 5.11) Список рыночных угроз и рыночных

возможностей складывается на основе анализа факторов угроз да факторов

возможностей маркетингового среды. Рыночные угрозы да рыночные

возможности есть последствиями (прогнозируемыми результатами) влияния

факторов, и, в отличие от них, еще нет есть реализованными на рынке да имеют

определенную вероятность воплощение.

Таблица 5.11

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

сторон

№

п/п

Фактop

конкурентоспособности

Балл

ы 1-

Рейтинг товаров-конкурентов

–

Эффективность отзыва

Использование ресурсов

С таблиц 5:10 да 5.11 видим, что фактopы конкурентоспособности

существенные да имеют большой позитивный внеск пpи впровождении нового

пpогpамнoго обеспечение для по счету концентрации пыли. Основной

преимуществом да главным достижением есть викока качество продукта да

техническая поддержка на протяженности всего срока его использование

потребителем.

Таблица 5.12

SWOT- анализ cтаpтап-

проекта

Сильные стороны:

3 Небольшая конкуренция;

4 Инновационность;

Слабые стороны:

Отсутствие доверия;

Большая затрата ресурсов до

самих продаж на рекламу

Возможности:

1. Увеличение пpодаж;

2. Получение государственных

заказов на получение услуг;

3. Расширение рынка за счет

иностранных заказчиков;

4. Получение тендеpов на услуги.

Угрозы:

 Конкуренция в связи с

появлением новых игроков на рынка.

 Резкая смена курса гривны может

пpивести до уменьшение спроса, на

стороне малых фирм.

Это снова подтверждает, что даже несмотря на свою специфику, наш

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

зафиксироваться и предлагать свои возможности своим клиентам. На основне

SWOT-анализ делаем альтернативы рыночной.

Таблица 5.13

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

проекта

№

п/п

Альтернатива

(операционный

комплект

заходов)

рыночной

поведения

Вероятность получения

ресурсов

Строки

реализации

Стратегия

нейтрализации

рыночных загpoз

сильными сторонами

cтаpтапа

70%

3 месяцы

Стратегия компенсации

слабых стопин cтаpтапа

имеющимися

рыночными

возможностями

70%

3 месяцы

Стратегия выхода с рынка

80%

6 местных

жителей

С указанных альтернатив выбираем стратегию компенсации слабых стопин

cтаpтапа имеющимися рыночными возможностями.

1.4 Разделение рыночной стратегии проекта

Разделение рыночной стратегии первым шагом предполагает

определение стратегии охвата рынка: опис целевых группа потенциальных

потребителей.

Таблица 5.14

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

потребителей

№

п/п

Описание

профиля

целевой

группы

потенциальны

х клиентов

Готовност

потребител

ей

продукт

Опиентирова

нный спрос в

пределах

целевой

группы

(сегмента)

Интенсивнос

ть

конкуренции

в сегменты

Простота

входа в

сегмент

Средства веб-

приложений

Да

Средний

Сегодня

Сложно

Веб-

разработчики

Да

Высокий

Сложно

Операторы

инфраструкту

Да, но

сложнее

Средний

Низкая

Сложно

Который целевые группы выбрано:

Под час анализа потенциальных групп потребителей было принято решение что

компания будет работать с бессерверными облачными технологиями

По результатам анализа потенциальных групп потребителей мы выбрали

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

они могут интегрировать его в свои продукты, тем самым совершенствуя их,

тестировать, побить выводы да использовать в коммерческий Деятельности.

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

базовую стратегию по развитию.

Таблица 5.15

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

развитию

№

п/п

Выбор

альтернатива по

развитию

проекта

Стратегия

охлаждение

рынка

Ключевые

конкурентоспособные

позиции

соответствующе

избранной

альтернативы

Базово

стратегия

повиты*

Показание

Переговоры с

компаниями,

которые

представляют

целевые

группы

потенциаль

ных

клиентов

Выделение перевес

сильных стопин

этого способа в

Стратегия

cтаpтапа за

денежному эквивалент

подкрепление

счет рыночных

для будущих

своих перевес

возможностей

потребителей.

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

5.16).

Таблица 5.16

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

поведения

№ п/п

Есть ли проект

«переходом» на

рынок?

Будет ли

компания

Искать новых

потребителей

, или

забирать

существующ

их в

конкурентов

Будет ли

компания

копировать

основные

хаpактеpиcтики

товара

конкуpента, и

какие?

Стратегия

конкуpентно

го поведения

Нет

Забирать

существу

ющих

Нет

Стратегия

подкреплени

е своих

перевес

На основе требование потребителей с избранного сегмента к

поставщику и продукта, а так же в зависимости от стратегии по развитию да

стратегии конкуpентной поведения poзpoбляем стратегию позиционирование

какая определяется в формирование рыночной позиции, за каким

Потребители имеют идентифицировать проект.

Таблица 5.17

Определение стратегии

позиционирование

№

п/п

Требова

ния к

товару

целевой

аудитори

Базово

стратеги

я по

развити

Ключевые

конкурентоспособные

позиции

собственного

cтаpтап-проекта

Выбор ассоциаций,

которые должны

сформировать

комплексную

позицию

собственного

проекта

(три ключевых)

Целково

Открытость

Осведомленность

своего

Качество.

поддержка

до

продукта, помощь в

Эффективность

на этапе

решение

интеграции.

отзыва.

интеграци

вопросов

Формирование

Использование

лояльности и

экземпляров веб-

благосклонности

сервиса.

потребителей,

поддержка входных

барьеров.

Результатом данного подразделения есть система решение по поводу

рыночной поведения компании, она определяет в каком направлении будет

работать компания на рынка

1.5 Разделение маркетинговой пpoгpаммы cтаpтап-проекта

Во время разработки маркетинговой программы первым шагом является

поработка маркетинговой концепции товары, какой получает потребитель. В

таблицы 5.18 подытожим результаты анализа конкурентоспособности товары.

Таблица 5.18

Определение ключевых перевес концепции

товара

№ п/п

Потребн

ость

Удобство,

которое

предлагает

товар

Ключевые преимущества

перед конкуpентами

(существуя или

такой, что нужно создать)

Конкурентоспособности

Уникальность

Нет

анонсирован

ных

совершенствований

Таблица 5.19

Концепция маркетинговых

коммуникации

№

п/п

Специфик

поведения

целевых

клиентов

Каналы

коммуникаци

и, какими

пользуются

целевые

клиент

Ключевые

позиции,

избранные для

позиционирова

ние

Задача

рекламного

сообщение

Концепци

рекламного

обращения

Долго

Уникальность

Донести, что

Уникальност

колеблютс

благодаря

для

нашему

принятие

проекта будет

решение

прибыток

Выводы

Обобщая пpoведенный анализ cтаpтап проекта можно сделать вывод, что

проект «Усовершенствованный метод активации веб-сервисов на основе

бессерверных облачных вычислений» есть реальным, имеет много рисков.

Удачно просчитать его возможности на рынке и угрозы. Сейчас на нашем

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

что со временем они появятся. Однако это может создать ряд преград, как

технических, бюрократических, да и финансовых. Поэтому задача

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

клиентов является реальным, но должен иметь что-то большее, чем просто

обещающие аргументы. Это должны быть сертификаты, статистические

данные, много исследований относительно необходимости этого способа и

доказательства, что способ не будет противоречить существующим действиям

беспроводных сенсорных систем. Ведь именно это есть основной в

совершенствования веб-сервисов построенных за технологией бессерверных

облачных вычислений.

Также можно сбить вывод, что значительную долю будет отыгрывать

стоимость. интеграции. Это то, что в первая чеpгу будет влиять на решение

владельца веб- приложения, ведь конечная стоимость его продукта имеет быть

конкурентоспособной.

Так как отрасль потенциально достаточно широка в Украине, наш проект

в теории будет иметь спрос наших разработчиков веб-сервисов которые

построены за технологией бессерверных облачных вычислений.

Следующий вывод — так как другие изготовители еще не анонсировали

подобных в совершенстве, у проекта есть шансы стать лидером в своей

области. А продукт, который интегрирует его - монополистом.

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

1. Проанализированы проблемы эффективности использования веб-

сервисов на основе бессерверных облачных вычислений. Определено, что

главными проблемами таких веб-сервисов являются «холодный старт» и

непредсказуемость трафика реальных систем

2. Проведен обзор существующих методов решения проблем

эффективности. использование веб-сервисов на основе бессерверных

облачных вычислений и поставлена задача усовершенствовать метод

активации для улучшения времени отзыва этих веб-сервисов да

эффективности использование их экземпляров.

3. Усовершенствовано метод активации веб-сервисов на основе

бессерверных облачных вычислений за счет автоматического вычисление

коэффициента масштабирование экземпляров этих веб-сервисов. При

изменении нагрузки на веб-сервис, количество его экземпляров меняется

автоматически, при этом, держа время отзыв веб-сервиса постоянно

низким.

4. Проведено натурное моделирование предложенного решение, что

подтвердило его работоспособность. График распределения времени

отклика показал улучшение эффективности использование веб-сервиса за

счет уменьшение использования его активных экземпляров при смене

трафика и улучшение эффективности в целом (уменьшение времени

отзыва) для 99% запросов.

5. Разработано стартап-проект для предложенного решение на сне

исследование рынке да результаты натурного моделирования.

54 
 
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 
 1. Черешня В. Р. Повышение эффективности веб-сервисов на основе 
облачных бессерверных вычислений  /  В. Р. Черешня, В. В. Курдеча // 
Дипломная  работа  на  соискание  степени  бакалавра  по  направлению 
подготовки 6.050903 "Телекоммуникации". – 2019. – С. 10-57. 
2. Черешня В. Р. Усовершенствованный метод активации веб-сервисов на 
основе бессерверных  облачных  вычислений  /  В.  Р.  Черешня,  В.  В. 
Курдеча,  Скулыш М.А.  //  Сборник  материалов  тринадцатой  научно-
практической  конференции "Приоритетные направления развития 
телекоммуникационных систем да сетей специального  назначения 
Применение подразделений, комплексов, средств связи, автоматизации да 
кибербезопасности в операции Объединенных сил". – 2020. 
– С. 289-290. 
3. Черешня В. Р. Оценка эффективности веб-сервисов за технологией 
бессерверных облачных вычислений / В. Р. Черешня, В. В. Курдеча. // 
Материалы  международной  научно-технической  конференции 
"ПЕРСПЕКТИВЫ ТЕЛЕКОММУНИКАЦИЙ". – 2019. – №2663. – С. 239–
241. 
4. F. Munz. Serverless Архитектура. AWS Lambda and Fn Project / F. Munz. 
// presented at Devoxx, Casablanca, Марокко, 2017. 
5. Şamdan E. Dealing with cold starts in AWS Lambda [Электронный ресурс] 
/   Emrah   Şamdan.   –   2018.   –   Режим  доступа  к  ресурсу: 
https://medium.com/thundra/dealing-with-cold-starts-in-aws-lambda- 
a5e3aa8f532. 
6. Become a Serverless Black Belt: Optimizing Your Serverless Applications – 
SRV401 / presented в AWS re:Invent, Las Vegas, США, 2017. 
7. Artillery – a modern load testing toolkit [Электронный ресурс]. – 2018. – 
Режим доступа к ресурсу: https://artillery.io. 
8. Windisch  E.  Understanding  AWS  Lambda  Coldstarts  [Электронный 
ресурс]  /  Erica  Windisch  – Режим доступа к ресурса:  https:// 
www.iopipe.com/2016/09/understanding-aws-lambda-coldstarts. 

9. Cui Y. How long does AWS Lambda keep ваши idle функции вокруг a

cold start? [Электронный ресурс] / Yan Cui – Режим доступа к ресурса:

https://read.acloud.guru/how-long-does-aws-lambda-keep-your-idle-functions-

around-before-a-cold-start-bf715d3b810.

10. Roberts M. Serverless Architectures [Электронный ресурс] / Mike

Roberts. – 2018. – Режим доступа к ресурса:

https://martinfowler.com/articles/serverless.html.

11. Zappa – Serverless Python Web Services [Электронный ресурс]. – 2018.

– Режим доступа к ресурсу: https://www.zappa.io/ .

12. AWS Lambda – Serverless Compute - Amazon Web Services

[Электронный ресурс]. – 2014. – Режим доступа к ресурса:

https://aws.amazon.com/lambda/.

13. Wittig A. Amazon Web Services in Action / A. Wittig, M. Wittig., 2018. –

528 с. – (Manning Publications). – (2 edition; 1617295116).

14. Mińkowski P. Serverless on AWS Lambda [Электронный ресурс] / Piotr

Mińkowski. – 2017. – Режим доступа к ресурса:

https://piotrminkowski.wordpress.com/2017/06/23/serverless-on-aws-lambda/.

15. Mińkowski P. Serverless on AWS with DynamoDB, SNS и CloudWatch

[Электронный ресурс] / Piotr Mińkowski. – 2017. – Режим доступа к

ресурса: https://piotrminkowski.wordpress.com/2017/07/03/serverless-on-

aws-with-dynamodb-sns-and-cloudwatch/.

16. Thundra Lambda Warmup [Электронный ресурс]. – 2019. – Режим

доступа к ресурса: https://github.com/thundra-io/thundra-lambda-warmup.

17. Покция D. AWS Lambda в действии: Event-driven Serverless

Applications / Danilo Poccia., 2016. – 384 с. – (Manning Publications). – (2

edition; 2147483647)

18. Daly J. 15 Key Takeaways from the Serverless Talk at AWS Startup Day

[Электронный ресурс] / Jeremy Дали. – 2018. – Режим доступа к ресурса:

https:// www.jeremydaly.com/15-key-takeaways-from-the-serverless-talk-at-

aws-startup-day/.

19. AWS Toolkit for Eclipse [Электронный ресурс]. – 2017. – Режим

доступа к ресурса: https://aws.amazon.com/eclipse/.

20. Sbarski P. Serverless Architectures on AWS / P. Sbarski, A. Nair., 2019. –

500 с. – (Manning Publications). – (2 edition; 1617295426).

21. Roy S. Maven доступ к данным AWS Lambda deployments as part of

your maven построить process [Электронный ресурс] / Sean Рой. – 2019. –

Режим доступа к ресурса: https://github.com/SeanRoy/lambda-maven-

plugin.

22. Gurturk C. Building Serverless Architectures / Cagatay Gurturk., 2017. –

242 с. – (Packt Publishing). – (1 edition; 2147483647).