Об эффективности бессерверных вычислений

Автор оригинала: Allan Chua
  • Перевод

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

Не нужно тратить усилия на управление серверами

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

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

  • управление масштабируемостью кластеров;

  • реализация мер по снижению рисков;

  • реализация стратегий аварийного восстановления;

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

  • установка обновлений операционной системы;

  • наем персонала для управления серверами.

Снижение рисков и затрат в области безопасности

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

Сокращение расходов на вычислительные ресурсы

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

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

  • необходимостью проектирования высокодоступных систем (вы не платите за резервирование и аварийное восстановление серверов).

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

Сокращение затрат и времени на разработку

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

  • на настройку и обслуживание серверов;

  • на тестирование масштабируемости и отказоустойчивости кластеров;

  • на проектирование и внедрение систем аварийного восстановления.

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

Анонимный кейс

Последние полтора года я работаю в команде, в которой 90% бессерверной инфраструктуры. У нас в общей сложности 71 стек Cloud Formation — это чистая бессерверная магия, включающая более 460 Lambda-функций. В июле 2020 года мы выполнили 91000 API-вызовов, что потребовало 91 час фактического времени исполнения на уровне AWS Lambda и стоило нам ноль сингапурских долларов с точки зрения поддержки нашей среды разработки.

Мы также отправили 6.6 млн сообщений, используя SQS, и заплатили за это скромную сумму в два сингапурских доллара за тот месяц. С другой стороны, традиционная архитектура потребовала бы минимум 19 тысяч сингапурских долларов при следующих допущениях:

  • одна виртуальная машина EC2 t2.xlarge обходится в 0.185 сингапурских доллара в час;

  • обычно для поддержки высокодоступной HA-архитектуры нам требуется две таких виртуальных машины, что будет стоить 0.370 сингапурских долларов в час;

  • рассчитать стоимость аренды ресурсов EC2 за весь месяц можно по такой формуле:

Цена одного API-кластера в месяц

0.370 х 730 часов в месяц = $270.10 в месяц

 Умножим эту сумму на 71 (число API-стеков в нашей среде разработки)

270.10 x 71 = 19710 сингапурских долларов в месяц

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

P. S. От переводчика

Лично я не жду, что процесс внедрения Serverless-архитектур будет быстрым. Массовых отказов от старой архитектуры в ближайшее также не предвидится. Чтобы работать с Serverless, нужно не просто выучить пару новых штук, а изменить своё мышление под новый тип разработки. О новых шагах Serverless-сервисов, подробностях и нюансах разработки можно узнать в сообществе Serverless в Telegram: Yandex Serverless Ecosystem.

Комментарии 17

    +6
    6 миллионов сообщений за месяц это 2 сообщения в секунду. копеечная нагрузка для любого mq типа nats.
    и, если я правильно понимаю, то 91 час суммарного времени выполнения значит что 1 виртуальное ядро процессора было загружено 91 час на 100%. тоесть в среднем за месяц одно ядро было бы загружено на 12%, что вполне укладывается в нормы запаса производительности чтобы обработать пиковое потребление (сферическое в вакууме. возможно там нагрузка вся приходится ровно на один час в сутки, но об этом в статье не сказано).
    тоесть хватило бы пару виртуалок по одному ядру. общей стоимостью 10-20$ в месяц. и никакого вендорлока.
      +1

      Лямбды по 100мс тарифицируются :)


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

        +3

        "Облако в целом похоже на обоюдоострый меч. При правильном использовании он может быть очень полезен, но при неправильном — пеняй на себя." — цитата из статьи по первой ссылке.

        0

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

          0
          А можно немного конкретнее, про цены на облачных администраторов? Реально хочется разобраться в этой теме, может получится приличный материальчик. Пока кажется, тут я перекрестился, что этим занимаются примерно те же люди, примерно за те же деньги.
            0

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


            касательно планов восстановления: по идее люди используют Availability zone, но конечно есть сервисы которые когда упадут — не дадут ниче сделать, например недавний кратковременный сбой amazon IAM) — виртуалки работали, но никого не пускало в панель управления

              +1
              по идее люди используют Availability zone

              к их использованию тоже надо прийти, простой перенос не HA инфраструктуры в облако (lift & shift) особо availability не увеличит ведь.

              0

              Сужу по рынку Киева, администратора для десятка линуксовых (V)DS с php, mysql, redis да elastic можно найти за 1000-1500$ То же делать на AWS/GCP — хотят от 2000 до бесконечности, если хотя бы год опыта с ними есть в резюме. Админ учит облака (вариант — кубер), внедряет у себя как-то, меняет "шилдик" на "девопс" и повышает ожидания раза в два. Поработав немного с AWS и кубером как админ (на позиции девлида), я бы тоже так сделал, если бы админом был — мозги вывернулись — сложно было на место назад вправить ))

                0
                Интересное наблюдение, мне казалось, что быть админом без опыта облаков сейчас как-бы моветон.
                  0

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

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

                      Знания — да, опыт — разве что "игрался с {cloudName}", если у вас нет популярного пет-проекта.

            0

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

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

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

                0
                Если вы ориентированы на западный рынок то скорее всего AWS будет правильным выбором. А на отечественном рынке рекомендую посмотреть в сторону Yandex.Cloud.

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

              Самое читаемое