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, попробовать стоит. Если будет время, то я обязательно поделюсь практическим опытом использования.
    Метки:
    EPAM 129,03
    Компания
    Поделиться публикацией
    Комментарии 23
    • 0
      Звучит не плохо.
      Андрей, ждем пример готовой реализации :)
      • +1
        Уже есть пара идей где применить:
        • для автоматизации удаления ресурсов, ассоциированных с инстансами, например, из мониторинга, шефа (но есть проблема: инстансы не поддерживаются как источник событий, но думаю API спасет)
        • для запуска кучи задач по расписанию, но тут проблема с джавой пока

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

                  Например, я тут прикинул, если раз в секунду проверять очередь, то в месяц заплатим 1$ за SQS.
                  • 0
                    https://habrahabr.ru/post/309040/
          • +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
                  Время астрономическое или машинное? Если машинное, как ввод/вывод считается?
                  А если функция создаст фоновый процесс, а сама завершится — как это будет считаться?

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

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