Компания
63,50
рейтинг
16 декабря 2014 в 18:40

Разработка → AWS Lambda и никаких серверов

Лично для меня Amazon Web Services всегда ассоциировался с Infrastructure as a Service (IaaS), на базе которого каждый строил свои сервисы и приложения. Но есть и претендующие на роль платформы в виде сервиса, например, Elastic Beanstalk и OpsWorks. Хотя, по моему мнению, их с натяжкой можно считать PaaS, так как остается доступ к инфраструктуре, и вместе с тем головная боль по её администрированию.

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

Итак, по словам представителей AWS, Lambda позволит забыть об инфраструктуре и запускать приложения в облаке, при этом получая интеграцию с другими сервисами Amazon, масштабируемость, низкую цену использования вычислительных ресурсов. Все, что нужно для старта, — написать функцию, ассоциировать её с событиями. После этого амазон автоматически выполнит функцию при каждом новом событии. О масштабировании и высокой доступности можно не думать: наша функция сможет обработать десятки тысяч запросов в час без каких-либо усилий с нашей стороны, без бекенда в традиционном его понимании.


Концепция


Основной рабочей лошадкой является лямбда-функция (или Лямбда-выражение). Лямбда-функция связывается с контекстом:
  • Окружение: ЯП, количество оперативной памяти, настройки доступа
  • Ресурсы, изменения которых нужно отслеживать
  • Код — та самая функция, выполняемая при получении сообщения об изменении ресурса


Как это работает


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

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

Необходимо помнить о том, что наша функция не сохраняет свое состояние (stateless), поэтому результаты работы нужно сохранять в каком-либо хранилище данных. В нашем примере — это S3 bucket.

Окружение


На данный момент поддерживается только JavaScript + Node,js. Также можно загружать библиотеки и использовать AWS SDK. Насколько я понял из видео презентации, под капотом используется Docker, запущенный на EC2 инстансе.

Текущие ограничения и планы на будущее


В первую очередь бросилось в глаза:
  • отсутствие готового CI/CD
  • нет интеграции с системами контроля версий (git, svn)

Также, как было сказано выше, поддерживается только JavaScript, как язык программирования.

В планах расширить список поддерживаемых сервисов (сейчас это S3, DynamoDB и Amazon Kinesis) и увеличить количество поддерживаемых ЯП.

Цена


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

Количество запросов


  • первый миллион запросов в месяц — бесплатно
  • все, что сверх этого предела, — $0.20 за 1 млн запросов ($0.0000002 за один запрос)

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


  • время запуска считается от начала работы функции до возврата результата, либо до остановки по таймауту (задается для каждой функции)
  • время округляется в большую сторону до ближайшего кратного 100 мс числа
  • стоимость каждой секунды зависит от количества выделенной памяти, т.е. $0.00001667 за каждую Гигабайт-секунду


По обыкновению, AWS предоставляет бесплатный период (free tier). Подробнее о ценах можно посмотреть здесь. Там же есть несколько примеров. Я приведу один из них.
Если время выполнения функции равно 1 секунде, и она будет запущена 3 млн раз в течение месяца, то мы получим счет в $18.34.

Ссылки по теме


Официальный блог
Стартовая страница сервиса

P.S.


AWS Lambda находится в стадии «preview», чтобы зарегестрироваться и получить доступ, необходимо заполнить запрос по ссылке. Учитывая очень хороший free tier, попробовать стоит. Если будет время, то я обязательно поделюсь практическим опытом использования.
Автор: @morkot
EPAM
рейтинг 63,50

Комментарии (22)

  • 0
    Звучит не плохо.
    Андрей, ждем пример готовой реализации :)
    • +1
      Уже есть пара идей где применить:
      • для автоматизации удаления ресурсов, ассоциированных с инстансами, например, из мониторинга, шефа (но есть проблема: инстансы не поддерживаются как источник событий, но думаю API спасет)
      • для запуска кучи задач по расписанию, но тут проблема с джавой пока

      • +2
        а какие сейчас у вас проблемы с удалением инстансов из шефа и мониторинга?
        вроде бы, и до лямбды было достаточно возможностей.
        разве что, в перспективе, можно будет немного сократить расходы на iaas.
        • +1
          Проблем никаких. Чем меньше сервисов нужно администрировать, тем лучше. Мониторинг и шеф — просто пример. На проекте есть множество задач, которые запускаются по расписанию или событию. Минус в том, что нужно поддерживать серверы, на которых эти задачи выполняются.
      • +2
        Ну автоматизировать удаление достаточно просто, в случае с aws — если у инструмента таймаут на пинг мониторингом — спрашиваем амазон через апи и удаляет отовсюду если инстанс удален
        • +1
          Это всего лишь один из способов. Мне больше всего нравится делать чистку после получения сообщения в sqs.
        • +1
          в условиях большого динамически скейлящегося кластера у вас с такой реализацией будет приличный лаг типа «оно отвалилось, но мониторинг еще не убрал», а алерты уже все получили.
          • 0
            Не совсем так. Это зависит от мониторинга и реализации. Например, если мониторинг близкий к реальному времени, тогда да. Если же нет, то sqs-очередь проверять можно с большй частотой.

            Например, я тут прикинул, если раз в секунду проверять очередь, то в месяц заплатим 1$ за SQS.
  • +2
    Амазон наконец запилил свой IronWorker
    • 0
      Не совсем:
      • Модель тарифная у IronWorker не pay-as-you-go, а статическая цена в месяц с ограниченими по количеству воркеров и времени запуска
      • Нет интеграции с другими сервисам амазона. Т.е. формировать те самые ивенты нужно самому


      Любобытно, что воркеры и очередь хостятся в AWS либо Rackspace.
      А так, идея не нова, конечно же.
      • +1
        вообще pay-as-you-go тоже было (первоначально), но вы правы, для новых клиентов эти планы уже недоступны.
        Воркеры хостятся и на амазоне и на ракспейсе и на азюре (очередь тоже)
        • 0
          азюре
          — звучит мильенько так, в такой транскрипции. Извините не удержался.

          Что касается IronWorker и IronMQ, то поддержка нескольких провайдеров — это преимущество, когда нужно избежать vendor lock.
  • +2
    Т.е. если мы делаем функцию, отдающую веб-страницу, и на основе этого строим CMS, то мы оплачиваем, грубо говоря, генерацию страниц (и работу в бек-энде, конечно).

    Пусть сайт у нас посещают 5000 человек в сутки, это 30*5000 = 150000 запусков функции в месяц, плюс сколько-то еще страниц увидит (запросит) администратор сайта в админке. Знать бы скорость выполнения функции (она сильно зависит от окружения: видел как-то, как страница сайта генерилась секунд 30 из-за тупящей дисковой подсистемы), чтобы понять расходы, но на глазок эти пара баксов терпимы.

    Но сайт — это не только страницы, это еще и статика, и ajax, который явно увеличивает число запросов (и вызовов функции).

    В любом случае, идея неплохая!
    • +1
      Ну, кстати, может быть интересно использовать со «статичными» CMS. Каждый раз, когда что-то на сайте меняется, лямбда генерит новые html-ки и пихает их в кэш, из которого все и раздается. Вероятно, это будет выгодно для визиток, лэндингов, ряда SPA и прочих штук, не требующих сложной бэкенд-логики.
      • +1
        Да, точно.

        Хочется все же понять, как быстро будет функция исполняться. Дорогого стоит, если страницы почти всегда будут не более 100 мс создаваться.
        • 0
          Обещают очень быстро. Из видио презентации: «в течение милисекунд ваша функция будет запущена»
          • +1
            Хм… Это лишь означает, что диспетчеризация события на экземпляр функции произойдет быстро, и что функция будет в состоянии «всегда готов».

            Но вот сколь много мне выделят мощности CPU, и как долго я буду ждать ответы от других подсистем Амазона… Ну, вы поняли )
            • 0
              Нужно тестировать для конкретного приложения. Думаю, что всякие задачки по типу обработки картинок будут проходить быстро. Как хранилище данных можно использовать DynamoDB — скорость записи должна быть ок.
  • +1
    Хотя формально поддерживается только Node.js, но вместе с JS-файлами туда можно загружать произвольные ресурсы, в том числе и исполнимые файлы, написанные на других языках. И вызывать их потом из JS.

    Вот тут пишут об успешном запуске Go-программы: blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/

    Go тут удобен тем, что он компилирует всё в один статический экзешник, поэтому неважно, в каком окружении его запустит Лямбда.
    • 0
      Круто! А сторонние библиотеки Go тоже компилирует в исполняемый артифакт?
      • +1
        Совсем сторонние, не на Go написанные — в общем случае нет, у них могут быть свои динамические зависимости. Тут надо отдельно на каждую либу внимательно смотреть.

        И сама go-программа тоже не абсолютно автономна, для некоторых функций она обращается к системным библиотекам. Самая заметная такая функция — резолвинг DNS (см. коммент к тому посту blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/#comment-1719377745). Но в данном случае это не мешает, т. к. системные либы в лямбда-окружении доступны.
  • 0
    Время астрономическое или машинное? Если машинное, как ввод/вывод считается?
    А если функция создаст фоновый процесс, а сама завершится — как это будет считаться?

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

Самое читаемое Разработка