Чуть-чуть об облачных вычислениях

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

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

Сначала немного базы.

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

Front-end, он же фронтенд, интерфейс, то есть некое приложение, загруженное в телефон.

База данных, в которой хранится вся информация, необходимая для работы приложения – авторизационные данные, информация о товарах, заказах и тд.

И Back-end – программный продукт, передающий и обрабатывающий данные между фронтендом и базой.

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

Первый (картинка 1) – это монолитное приложение, запускаемое на сервере. Это приложение одновременно реализует и API (application programming interface), то есть интерфейс, который в зависимости от точки входа (или входных параметров) передает данные в соответствующий обработчик (например, добавить пользователя, изменить пользовтеля, удалить пользователя – это три действия, то есть три точки входа в API и три обработчика), так и сами эти обработчики, осуществляющие вычислительные операции, обращения к базе данных, их обработку и возврат результата и тд.

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

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

Чего мы хотим от приложения? Чтобы оно работало быстро и стабильно. Скорость обработки данных зависит в значительной степени от мощности сервера. Окай, втыкаем много мощных серверов, ставим у балансировщика границу допустимой нагрузки пониже и вуаля! Но нет. Сервера стоят денег. Много мощных серверов стоят много денег. Соответственно, возникает задача постоянного подбора оптимальной мощности с учетом прогноза затрат. И помнить, что даже когда приложением не пользуется вообще никто – мы все равно платим за запущенные сервера, ожидающие нагрузку.

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

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

А второй вариант реализации бэкенда – это распределенные облачные бессерверные функции (картинка 2).

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

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

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

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

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

Сервис облачных функций Lambda был запущен в облаке AWS (Amazon Web Services) в 2014 году, и с тех пор стал одним из ключевых и наиболее популярных продуктов, используемым как крупнейшими мировыми корпорациями (CocaCola, Siemens, Toyota и дугие), так и бесчисленным множеством более мелких компаний и стартапов, позволяя с минимальными затратами обеспечить быструю, стабильную и надежную работу интернет-сервисов.

В России сервисы облачных вычислений доступны в Яндекс.Облаке и Сбер.Облаке, но на данный момент по сравнению с AWS Lambda они имеют значительные технические и технологические ограничения.