The Wayback Machine — https://web.archive.org/web/20180726011409/https://aws.amazon.com/ru/serverless/

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

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

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

Бессерверные приложения обладают тремя ключевыми преимуществами.

• Отсутствие необходимости управлять серверами
• Гибкость масштабирования
• Автоматическое обеспечение высокой доступности

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

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

Бессерверные приложения по определению характеризуются доступностью и отказоустойчивостью. Эти возможности не требуется специально проектировать, поскольку сервисы, запускающие приложение, предоставляют их по умолчанию.

Международная корпорация Coca-Cola использовала AWS Lambda и AWS Step Functions для создания экономичных бессерверных решений.

Читать блог »

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

Подробнее »

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

Подробнее »

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

Подробнее »

Просмотрите другие примеры использования »

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

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

Осуществляйте координацию и управление состояниями всех распределенных компонентов или микросервисов своего бессерверного приложения с помощью AWS Step Functions.

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

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

Используйте AWS Serverless Application Repository, чтобы быстро развертывать бессерверные приложения и их компоненты для различных целей, включая мобильные и веб- серверы, чат-боты, Интернет вещей, Alexa Skills, обработку данных, обработку потоков и прочее. Кроме того, можно найти интеграции с популярными сторонними сервисами (например, Slack, Algorithmia, Twilio, Loggly, Splunk, Sumo Logic, Box и т. д.).

Обеспечьте безопасность и соответствие требованиям всей ИТ-среды с помощью ведения журналов, отслеживания изменений, контроля доступа и шифрования.

Осуществляйте безопасный контроль доступа к вашим ресурсам AWS с помощью сервиса AWS Identity and Access Management (IAM). Управляйте конечными пользователями бессерверных приложений и выполняйте их аутентификацию с помощью Amazon Cognito.

Используйте Amazon Virtual Private Cloud (VPC) для создания частных виртуальных сетей, доступ к которым будете контролировать только вы.

Выводите свои приложения и сервисы на глобальный уровень, используя широкий географический охват AWS. Сервис AWS Lambda доступен во множестве регионов AWS и во всех периферийных местоположениях AWS с использованием Lambda@Edge. Функции Lambda также можно запускать на локальных подключенных устройствах с помощью сервиса AWS Greengrass.

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

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

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

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

Lambda@Edge позволяет запускать функции Lambda в периферийных местоположениях AWS в ответ на события Amazon CloudFront.

Amazon API Gateway – это полностью управляемый сервис для разработчиков, предназначенный для создания, публикации, обслуживания, мониторинга и обеспечения безопасности API в любых масштабах. Amazon API Gateway позволяет обрабатывать сотни тысяч одновременных вызовов API; он обеспечивает управление трафиком, авторизацию и контроль доступа, мониторинг и управление версиями API.

Сервис Amazon Simple Storage Service (Amazon S3) – это надежное средство хранения объектов, которое легко масштабируется и отлично подходит для разработчиков и ИТ-подразделений. Amazon S3 удобен в использовании, оснащен простым веб-интерфейсом и позволяет отправлять на хранение любой объем данных и извлекать его из любого места в Интернете.

Amazon DynamoDB – это быстрый и гибкий сервис баз данных NoSQL. Он подходит для любых приложений, требующих стабильной работы с задержкой не более нескольких миллисекунд при любом масштабе. Эта полностью управляемая облачная база данных поддерживает работу на основе как документов, так и пар «ключ-значение».

AWS AppSync автоматически обновляет данные в мобильных и интернет-приложениях в режиме реального времени, а для автономных пользователей – сразу после повторного подключения. В AppSync используется язык для работы с данными GraphQL, который позволяет клиентским приложениям получать данные от серверов, изменять их и подписываться на них.

Amazon SNS – полностью управляемый сервис отправки сообщений по модели «издатель – подписчик» (Pub/Sub), который позволяет легко изолировать и масштабировать микросервисы, распределенные системы и бессерверные приложения.

Amazon SQS – полностью управляемый сервис очередей сообщений, позволяющий легко изолировать и масштабировать микросервисы, распределенные системы и бессерверные приложения.  

Сервис AWS Step Functions облегчает координацию компонентов распределенных приложений и микросервисов благодаря использованию наглядных схем рабочих потоков.

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

Step Functions – это простой способ координировать работу компонентов и последовательно контролировать функции приложения.

Amazon Kinesis – это платформа для работы с потоковыми данными в AWS. Она предлагает многофункциональные сервисы, которые обеспечивают легкую загрузку и анализ потоковых данных, а также позволяет создавать свои собственные настраиваемые приложения для решения специфических задач, возникающих при обработке потоковых данных.

Amazon Athena – интерактивный сервис запросов, позволяющий анализировать данные в Amazon S3 стандартными средствами SQL. Athena – это бессерверный сервис, поэтому не нужно управлять архитектурой, а плата начисляется только за выполненные запросы.

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

Подробнее »

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

Бессерверные интернет-приложения и серверные системы можно создавать, используя AWS Lambda, Amazon API Gateway, Amazon S3 и Amazon DynamoDB для отработки сетевых запросов, запросов от мобильных устройств, устройств «Интернета вещей» (IoT) и чат-ботов.

Эталонная архитектура. Диаграмма | Образец кода

Эталонная архитектура. Диаграмма | Образец кода

Компания Bustle использует бессерверные внутренние системы для своего приложения iOS и веб-сайтов, используя AWS Lambda и Amazon API Gateway.

Бессерверные архитектуры позволяют Bustle никогда не заниматься управлением инфраструктурой, поэтому каждый технический специалист компании имеет возможность сосредоточиться на создании новых возможностей и внедрении инноваций. Ознакомиться с примером использования »

Используя AWS Lambda, Amazon Kinesis, Amazon S3 и Amazon DynamoDB, можно создавать различные системы обработки данных в режиме реального времени.

Эталонная архитектура. Диаграмма | Образец кода

Компания Square Enix использует AWS Lambda при выполнении обработки изображений для своей массовой многопользовательской онлайн-игры.

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

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

Эталонная архитектура. Диаграмма | Образец кода

Компания Thomson Reuters использует бессерверную архитектуру для обработки до 4000 событий в секунду для своего сервиса аналитики использования.

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

Компания выполнила развертывание сервиса в рабочей среде всего через пять месяцев использования AWS. Ознакомиться с примером использования »

Amazon Prime Video: переход от микросервисов к монолиту сократил косты на 90%

В этой статье переводим Case-study команды Amazon, которое было опубликовано в их блоге.

Amazon Prime Video транслирует тысячи видео клиентам. Для получения контента клиентами, в Prime Video создан инструмент для мониторинга каждой просматриваемой клиентами трансляции. Этот инструмент позволяет автоматически определять проблемы с восприятием качества например, повреждения блоков или проблемы с синхронизацией аудио/видео и запускать процесс их устранения.

https://www.youtube.com/watch?v=BHmX12y2Y6w\u0026pp=ygVJ0JzQsNC90LjRhNC10YHRgiDRgNCw0YHQv9GA0LXQtNC10LvQtdC90L3Ri9GFINCy0YvRh9C40YHQu9C10L3QuNC5IEFtYXpvbg%3D%3D

У команды анализа качества видео (Video Quality Analysis, VQA) в Prime Video уже был инструмент для проверки качества аудио/видео, он не разрабатывался для работы в большом масштабе (целью был мониторинг тысяч параллельных потоков и постепенное увеличение этого числа).

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

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

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

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

Поскольку команда скомпилировала все операции в один процесс, можно все задеплоить на экземпляры Amazon Elastic Compute Cloud (Amazon EC2) и Amazon Elastic Container Service (Amazon ECS).

Distributed systems overhead

Сервис состоит из трех компонентов. Медиа конвертер преобразует входные аудио/видеопотоки в кадры или расшифрованные аудиобуферы, которые отправляются на «детекторы».

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

Как было описано выше, первоначальное решение состояло из: AWS Step Functions или AWS Lambda. В теории это позволяло масштабировать каждый компонент сервиса независимо.

Однако, способ использования некоторых компонентов привел к достижению жесткого предела масштабирования при примерно 5% от ожидаемой нагрузки.

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

На следующей схеме показана serverless архитектура сервиса которая была до перехода к «монолиту»:

Главным узким местом масштабирования в архитектуре было управление оркестрацией, которое было реализовано с помощью AWS Step Functions. Сервис выполнял много переходов состояний для каждой секунды стрима, поэтому Amazon быстро достигали лимитов учетной записи. Кроме того, AWS Step Functions взимает плату у пользователей за «per state transition»

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

Чтобы уменьшить вычислительно затратные задачи по преобразованию видео, команда создала микросервис, который разбивает видео на кадры и временно загружает изображения в хранилище Amazon Simple Storage Service (Amazon S3).

Затем детекторы дефектов (каждый из них также работает в качестве отдельного микросервиса) загружают изображения и обрабатывают их параллельно с использованием AWS Lambda. Однако большое количество вызовов Tier-1 к хранилищу S3 было дорогостоящим.

От распределенной микросервисной архитектуры к монолитному приложению

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

Amazon пришли к выводу, что распределенный подход не приносит много преимуществ в их конкретном случае, поэтому они упаковали все компоненты в один процесс.

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

Также реализовали оркестрацию, которая управляет компонентами в рамках одного экземпляра.

https://www.youtube.com/watch?v=BHmX12y2Y6w\u0026pp=YAHIAQE%3D

На следующей схеме показана архитектура системы после перехода к монолиту:

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

В концептуальном плане, высокоуровневая архитектура осталась неизменной. Есть те же компоненты, которые использовали в начальном проектировании (преобразование медиа, детекторы и оркестрация). Это позволило нам повторно использовать много кода и быстро перейти к новой архитектуре.

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

Результаты и полученные уроки

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

Перенос сервиса на монолитную архитектуру позволил сократить затраты на инфраструктуру более чем на 90%. Это также увеличило возможности масштабирования.

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

Перенос на Amazon EC2 и Amazon ECS также позволил амазону использовать программы экономии вычислительных ресурсов Amazon EC2, что поможет еще больше снизить затраты.

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

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

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

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

Создание распределенных систем на AWS

• В этой статье мы рассмотрим, как можно создать архитектуру распределенных сервисов. Использование контейнеров Docker, NodeJS, приложения Python/Flask и нескольких ресурсов AWS
• Привлекательность распределенных вычислений заключается в возможности использовать мощь нескольких, часто параллельных вычислительных ресурсов и воспользоваться преимуществами современных предложений облачных вычислений для практически неограниченного масштабирования.
• Давайте разделим наш блог на 4 основные части:

1. Архитектурный обзор
2. Ресурсы AWS
3. Разработка
4. Развертывание

1. Архитектурный обзор

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

Наш поток приложений

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

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

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

Ключевые моменты контейнерной архитектуры

• Последовательная и изолированная среда
• Мобильность – возможность запуска в любом месте
• Повторяемость и автоматизация
• Тестирование, откат и развертывание
• Гибкость
• Совместная работа, модульность и масштабирование

Наши 4 контейнера

• container-main: открыт для публичного доступа, будет обрабатывать вызовы API
• container-process: частный контейнер может взаимодействовать с нашим основным контейнером и не является общедоступным
• container-consume: контейнер-потребитель очередей, который будет потреблять очереди, создаваемые в SQS главным контейнером
• container-xray: будет прослушивать наш трафик и перехватывать http-соединения, чтобы потом можно было провести аудит из консоли.

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

2. Ресурсы AWS

SQSAmazon Simple Queue Service (SQS) – это полностью управляемый сервис очередей сообщений, который позволяет разделить и масштабировать микросервисы, распределенные системы и бессерверные приложения.

В нашей архитектуре один из контейнеров будет производить сообщения, а другой – потреблять их.

• Производитель: Конечные точки, которые записывают сообщения в очередь
• Потребитель: Срабатывает, когда сообщение передается в очередь.

X-RayAWS X-Ray – это служба, которая помогает разработчикам анализировать и отлаживать распределенные приложения. Вы можете использовать X-Ray для мониторинга трассировки приложения, включая производительность вызовов других компонентов или сервисов.

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

Демон X-RayДемон AWS X-Ray – это программное приложение, которое прослушивает трафик на порту UDP 2000, собирает необработанные данные сегментов и передает их в AWS X-Ray API. Демон работает совместно с AWS X-Ray SDK и должен быть запущен, чтобы данные, отправленные SDK, могли достичь службы X-Ray.

1. Вместо того чтобы отправлять данные трассировки непосредственно в X-Ray, SDK отправляет документы сегментов JSON процессу демона, прослушивающему UDP-трафик.
2. Демон X-Ray буферизирует сегменты в очереди и загружает их в X-Ray партиями.
3. CloudWatchAmazon CloudWatch – это служба мониторинга и управления, которая предоставляет данные и практические выводы для AWS.

3. Разработка

IAMДля того чтобы иметь возможность использовать AWS cli, необходимо создать пользователя IAM и предоставить ему соответствующие права. (Например, наша команда docker compose up развернет/создаст множество ресурсов AWS, ECS, Security Group и т.д., поэтому наш пользователь IAM должен иметь необходимые разрешения, чтобы иметь возможность сделать это).

Образ NodeJS (container-main, container-consume)

FROM node:alpine
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 8080
CMD [«node», «index.js»]

Образ Python (container-process) (стек Python необязателен, наша основная цель его использования – показать, как мы можем использовать несколько различных языков в распределенной архитектуре)

FROM python:3
WORKDIR /usr/src/app
COPY . .
RUN pip install —no-cache-dir -r requirements.txt
EXPOSE 8082
CMD [«python», «app.py»]

Образ демона рентгеновского излучения (container-xray)Ссылка: https://docs.aws.amazon.com/xray/latest/devguide/xray-daemon-ecs.html

FROM amazonlinux
RUN yum install -y unzip
RUN curl -o daemon.zip https://s3.us-east-2.amazonaws.com/aws-xray-assets.us-east-2/xray-daemon/aws-xray-daemon-linux-3.x.zip
RUN unzip daemon.zip && cp xray /usr/bin/xray
ENTRYPOINT [«/usr/bin/xray», «-t», «0.0.0.0:2000», «-b», «0.0.0.0:2000»]
EXPOSE 2000/udp
EXPOSE 2000/tcp

Docker compose

version: '3'
x-environment:
&default-environment
AWS_REGION: ${AWS_REGION}
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_XRAY_DAEMON_ADDRESS: xray:2000
MAIN_SQS_QUEUE_URL: ${MAIN_SQS_QUEUE_URL}
services:
xray:
image: ${XRAY_IMAGE}
container_name: XRAY
build:
context: ./container-xray
dockerfile: ./Dockerfile
environment: *default-environment
command: —local-mode
ports:
— «2000:2000/udp»
networks:
mynet:
ipv4_address: 172.19.20.1

main:
image: ${MAIN_IMAGE}
container_name: MAIN
build:
context: ./container-main
dockerfile: ./Dockerfile
depends_on:
— xray
ports:
— «8080:8080»
environment: *default-environment
networks:
mynet:
ipv4_address: 172.19.10.1

consume:
image: ${CONSUME_IMAGE}
container_name: CONSUME
build:
context: ./container-consume
dockerfile: ./Dockerfile
environment: *default-environment
networks:
mynet:
ipv4_address: 172.19.10.2

process:
image: ${PROCESS_IMAGE}
container_name: PROCESS
build:
context: ./container-process
dockerfile: ./Dockerfile
environment: *default-environment
networks:
mynet:
ipv4_address: 172.19.10.3

networks:
mynet:
driver: bridge
ipam:
driver: default
config:
— subnet: 172.19.0.0/16

Основные возможности Docker compose

• Запуск нескольких изолированных сред
• Модель параллельного выполнения
• Обнаружение изменений в файлах Compose
• Открытый исходный код

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

• Вы всегда можете использовать docker-compose —help, чтобы увидеть все доступные опции.

Что касается нашего .env файла, вы можете проверить .env.sample, чтобы заполнить все необходимые переменные, и создать новый .env файл с теми же значениями

AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=
AWS_REGION=
MAIN_SQS_QUEUE_URL=

MAIN_IMAGE=
PROCESS_IMAGE=
CONSUME_IMAGE=
XRAY_IMAGE=

Создание новой SQS FIFOОчереди FIFO (First-In-First-Out) предназначены для улучшения обмена сообщениями между приложениями, когда порядок операций и событий является критическим, или когда нельзя допускать дублирования. После создания очереди убедитесь, что вы скопировали Url и вставили его в файл переменных окружения (.env).

Коммуникационная логика

• Наш контейнер-main может взаимодействовать с частным контейнером, который называется ‘process’, поэтому, по сути, мы можем сделать обычный вызов API на http://process:8082/api/process (с помощью AWS Cloud Map и его сервиса discovery мы можем это сделать).
• Мы можем отправить SQS сообщение, используя aws-sdk.
• Наш контейнер-консум слушает нашу очередь SQS каждый раз, когда у нас есть сообщение, он потребляет его.

[примечание] проект с открытым исходным кодом и вы можете получить доступ к ссылке в конце этого блога

4. Развертывание

Первым делом нам нужно разместить наши образы в Amazon Elastic Container Registry (Amazon ECR), который является управляемым AWS сервисом реестра образов контейнеров.

• частный репозиторий не предлагает возможности поиска содержимого и требует аутентификации на основе Amazon IAM с использованием учетных данных учетной записи AWS, прежде чем разрешить извлечение изображений
• публичный репозиторий имеет описательное содержимое и позволяет любому человеку в любом месте извлекать образы без необходимости иметь учетную запись AWS или использовать учетные данные IAM.

Используя AWS CLI, вам нужно запустить 4 командные строки, сначала вы войдете в ECR cli и docker, затем создадите свой образ docker, пометите его и запустите его, эти командные строки можно найти, нажав на “View push commands” внутри репозитория ECR, который вы создали.

Для развертывания нашего приложения мы будем использовать команду docker compose up, по умолчанию Docker Compose CLI создает кластер ECS для вашего приложения Compose, группу безопасности для сети в вашем файле Compose на стандартном VPC вашего аккаунта AWS, LoadBalancer для маршрутизации трафика к вашим сервисам, а также прикрепляет IAM роль Task execution с двумя IAM ролями для вашего ECS Task Definition (AmazonEC2ContainerRegistryReadOnly & AmazonECSTaskExecutionRolePolicy).

[примечание] обязательно проверьте, можете ли вы запускать 2 задачи одновременно, если нет, вам нужно открыть запрос в AWS Support Center, чтобы добавить ваш лимит.

Для того чтобы развернуть нашу архитектуру, нам необходимо выполнить следующие командные строки

docker context create ecs
docker context use
docker compose up

Команда docker context позволяет легко экспортировать и импортировать контексты на разных машинах с установленным клиентом Docker

[примечание] docker-compose up создает контейнеры docker compose file на вашей локальной машине, однако docker compose up развертывает ваш docker compose file в AWS.

После развертывания он создаст следующие ресурсы (вы можете просмотреть все ресурсы, созданные в cloudformation stack)

• Кластер ECS
• Карта облака AWS
• AWS Network Load Balancer (NLB)
• Группа безопасности
• Целевая группа

Amazon Elastic Container Service (Amazon ECS) – это высокомасштабируемая и быстрая служба управления контейнерами. Вы можете использовать его для запуска, остановки и управления контейнерами на кластере. Вы можете запускать либо Fargate, либо экземпляры EC2.

При использовании типа запуска EC2 вы получите больше контроля, но пользователю необходимо управлять, предоставлять, масштабировать и исправлять виртуальные машины.

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

После определения требований приложения (вычислительные ресурсы и ресурсы памяти) Fargate будет управлять масштабированием для запуска контейнеров в высокодоступной среде. Он может одновременно запускать тысячи контейнеров и масштабироваться для запуска критически важных приложений.

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

Давайте посмотрим на изображение ниже.Как мы видим, наш кластер содержит наш контейнерный экземпляр ECS, который в нашем случае является Fargate, и для каждого контейнера у нас есть аналогичные 4 коробки (зеленые), четыре из которых находятся внутри одного кластера. Задача находится внутри сервиса, и она может запускать несколько контейнеров docker

ECS Task Definition ваши контейнеры определены в определении задачи, которое вы используете для запуска отдельной задачи или задач внутри сервиса. Одно определение задачи может создать несколько идентичных задач.

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

Наша Cloud Map:

Балансировщик нагрузки сети распределяет трафик конечного пользователя между несколькими облачными ресурсами, чтобы обеспечить низкую задержку и высокую пропускную способность. В нашем примере, поскольку мы открыли один из наших контейнеров на порт 8080:8080, создается NLB, но если бы мы открыли его на 80:80, то был бы создан ALB (https://docs.docker.com/cloud/ecs-compose-examples/).

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

Входящие правила:

Целевая группа указывает балансировщику нагрузки, куда направить трафик.

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

В дальнейшем я буду добавлять множество функций к текущей архитектуре и углубляться в конкретные темы.Исходный код: https://github.com/awedis/containers-architecture

Return of the Monolith: Amazon Dumps Microservices for Video Monitoring

A blog post from the engineering team at Amazon Prime Video has been roiling the cloud native computing community with its explanation that, at least in the case of video monitoring, a monolithic architecture has produced superior performance than a microservices and serverless-led approach.

For a generation of engineers and architects raised on the superiority of microservices, the assertion is shocking indeed. In a microservices architecture, an application is broken into individual components, which then can be worked on and scaled independently.

“This post is an absolute embarrassment for Amazon as a company. Complete inability to build internal alignment or coordinated communications,” wrote analyst Donnie Berkholz, who recently started his own industry-analyst firm Platify.

“What makes this story unique is that Amazon was the original poster child for service-oriented architectures,” weighed in Ruby-on-Rails creator and Basecamp co-founder David Heinemeier Hansson, in a blog item post Thursday.

“Now the real-world results of all this theory are finally in, and it’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse.

”

In the original post, dated March 22, Amazon Prime Senior Software Development Engineer Marcin Kolny explained how moving the video streaming to a monolithic architecture reduced costs by 90%. It turns out that components from Amazon Web Services hampered scalability and skyrocketed costs.

The Video Quality Analysis (VQA) team at Prime Video initiated the work.

The task as to monitor the thousands of video streams that the Prime delivered to customers. Originally this work was done by a set of  distributed components orchestrated by AWS Step Functions, a serverless orchestration service, AWS Lambda serverless service.

In theory, the use of serverless would allow the team to scale each service independently. It turned out, however, that at least for how the team implemented the components, they hit a hard scaling limit at only 5% of the expected load. The costs of scaling up to monitor thousands of video streams would also be unduly expensive, due to the need to send data across multiple components.

Initially, the team tried to optimize individual components, but this did not bring about significant improvements. So, the team moved all the components into a single process, hosting them on Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Container Service (Amazon ECS).

Takeaway

• Kolny was careful to mention that the architectural decisions made by the video quality team may not work in all instances.
• “Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis,” he wrote.
• To be fair, the industry has been looking to temper the enthusiasm of microservices over the past decade, stressing it is only good in some cases.

“As with many good ideas, this pattern turned toxic as soon as it was adopted outside its original context, and wreaked havoc once it got pushed into the internals of single-application architectures,” Hansson wrote. “In many ways, microservices is a zombie architecture. Another strain of an intellectual contagion that just refuses to die.”

The IT world is nothing but cyclical, where an architectural trend is derided as hopelessly archaic one year can be the new hot thing the following year. Certainly, over the past decade when microservices ruled (and the decade before when web services did), we’ve heard more than one joke in the newsroom about “monoliths being the next big thing.” Now it may actually come to pass.

Что такое serverless технологии

Всем привет!

Надеюсь вы готовы сделать шаг в будущее? Будущее DevOps-а и, скорее всего, вашей будущей жизни в качестве фул-стек разработчика? Конечно, я немного преувеличиваю, но serverless (переводится как «бессерверные») технологии заслуживают внимание.

https://www.youtube.com/watch?v=ed_4T2CnNx8\u0026pp=ygVJ0JzQsNC90LjRhNC10YHRgiDRgNCw0YHQv9GA0LXQtNC10LvQtdC90L3Ri9GFINCy0YvRh9C40YHQu9C10L3QuNC5IEFtYXpvbg%3D%3D

Данный выпуск — первый по serverless в блоге, с другими постами по теме вы можете ознакомиться по ссылкам ниже:

Серия статей:

Наш план на сегодня:

• Разберемся что это за зверь, поговорим о том, как работают «бессерверные» приложения и что с их помощью можно создавать.
• Узнаем плюсы и минусы облачных функций (в частности, AWS-лямбд)
• Рассмотрим одноименный с технологией фреймворк serverless и создадим нашу первую лямбда-функцию.
• В заключении рассмотрим, для чего еще применимы лямбды.

Что такое serverless? AWS Lambda? #

Есть много решений, как платных, так и опенсорсных, но мы будем рассматривать только AWS и serverless, как самые популярные решения в этой области.

Начнем с того, что можно понимать под «облаками» и облачными вычислениями? Это модель обеспечения удобного доступа к вычислительным ресурсам, которые поставляет поставщик (например, амазон) и отвечает за запуск вашего кода, распределение ресурсов (масштабирование), мониторинг и т.д. Бессерверные вычисления — это модель выполнения облачных вычислений, в которой нам, разработчикам, совсем не нужно думать о серверах — всю работу с ними берет на себя поставщик услуг.

Вы сейчас можете сказать: «wft, какая же это бессерверная технология, если все запускается на серверах?». Конечно же, она не такая уж и бессерверная, ваш код будет запускаться серверах, но как там все устроено?

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

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

Пользователь можно только задеплоить функции и подключить к ней источники событий.

Опять вопрос из зала: «В чем суть, зачем нам запускать какую-то функцию в контейнере?»

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

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

В момент получения события (например, http-запрос), автоматически запускается контейнер с определенным интерпретатором (или виртуальной машиной, в случае java; Да-да, лямбда это не только javascript, на ней можно запускать код на разных языках, таких как golang, .

net, java, python и nodejs), который выполняет полученный код, подставляя тело события в качестве первого аргумента:

/* Пример самой простой лямбды */
module.exports.handler = (event, context, callback) => {
const response = {
statusCode: 200,
body: '

Hello, Lambda

'
};

callback(null, response);
};

Источником событий могут быть самые разные сервисы (в рамках амазона, это их же сервисы):

• Например при добавлении/удалении файла в S3 (файловое хранилище)
• При изменении данных в таблице DynamoDB (база данных от амазона)
• При использовании планировщика задач
• И то, что нам будет интереснее всего — это API Gateway, который позволяет обрабатывать http запросы и абстрагировать их до события для лямбды.

В случае лямбды мы можем совсем не думать о серверах. Мы работаем с лямбдой не так, как мы работаем с обычными серверами. Как работает обычное приложение на Nodejs? Мы запускаем http-сервер, который слушает указанный порт.

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

Это был мой первый вопрос, когда я познакомился с serverless: как же на нем запустить http-сервер?

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

Для лямбд на Nodejs оно не так уж и велико, и составляет обычно менее 400 мс (по сравнению, например с Java или C#, которые требуют 5-6 секунд. Вы можете почитать материал, где описано, как можно получить это значение).

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

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

https://www.youtube.com/watch?v=ed_4T2CnNx8\u0026pp=YAHIAQE%3D

Если это для вас проблема (400 мс), то функции можно разогревать, например, каждые N секунд создавать событие для запуска функции.

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

Еще одно преимущество — это способ оплаты — pay-as-you-go. Он означает, что оплата за использование производится по времени выполнения конкретной функции.

Вместо запущенного сервера 24/7, вы можете размещать функции-лямбды, и сервер будет работать только в течении жизненного цикла запроса.

Это отлично подходят для прототипирования, так как платите за количество конкретных запросов, а в случае, если используете AWS Lambda, то у вас в наличии 1 миллион бесплатных запросов в месяц.

Давайте соберем все достоинства такой архитектуры вместе:

• Простота создания и развёртывания продукта. Нет необходимости думать о настройке и управлении серверами — мы можем полностью забыть об этом, и сосредоточится на бизнес-логике приложения;
• Горизонтальное масштабирования и высокая доступность проекта из коробки. И не важно, если завтра на ваш сайт придет пару человек или миллион, все будет работать как часы (По умолчанию в амазоне стоит ограничение на 100 одновременно выполняющихся функций, которое сделано с целью защиты от непреднамеренного вызова функций в процессе тестирования, но которое можно увеличить через консоль AWS);
• Оплата только за использованное время;
• Интеграция почти со всеми сервисами амазона (DynamoDB, Alexa, S3, API Gateway итд), которые позволяют обработать очень многие кейсы.

К минусам же можно отнести:

• Холодный старт контейнера, который мы рассмотрели выше;
• Отсутствие «целостности» приложения: каждая функция – это независимый объект. И если ваше приложение требует использование много функций, то нужно хорошенько подумать над архитектурой;
• Ограничения по размеру кода функции уставлено в 50 Мб. Сможете написать такую функцию? Не думаю 🙂 Но не стоит забывать про node_modules, которая разрастается молниеносно и можно запросто перейти лимит;
• Ограничения по времени выполнения. По умолчанию лямбда выполняется всего одну секунду и если функция не ответит за это время, то в ответ клиент получит ошибку с «таймаутом». В настройках это время можно увеличить до пяти минут и для обычно сайта этого времени достаточно. Но как вы могли догадаться, это проблема, если необходимы реалтаймовые приложения, которые, например, используют websocket-ы;
• Количество параллельных функций в минуту. Ограничение по максимальному количеству равно 500-3000 (в зависимости от региона) одновременно-выполняющихся функций в минуту.

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

Первая лямбда с serverless #

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

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

Он позволяет запускать все локально (используя плагин) и описать все интеграции и инфраструктуру проекта в одном yml-файле.

Его можно использовать не только для nodejs, и не только для AWS, но мы рассмотрим именно такой вариант использования.

«Serverless» не единственный фреймворк, но у него, кроме сообщества и хорошей поддержки, есть «киллер фича» — крутая экосистема плагинов. Уже написано огромное количество разных плагинов, но даже если вы не найдете нужного, написать свой не составит никакого труда.

Приступим? #

Перед началом у вас должен быть аккаунт в AWS с админским доступом или специальный пользователь с нужными правами (при неверно выданных правах все может работать не так, как нужно); бесплатно создать его можно тут. И установлена Nodejs v8 и выше.

Создадим лямбду, которая отрендерит нашу HTML-страницу. Первым делом установим глобально фреймворк:

npm install -g serverless

Далее создадим директорию для нового проекта и сгенерируем лямбду по уже готовому шаблону. Разработчики «Serverless» сделали возможность создавать сервисы из шаблонов, создав все необходимые файлы. В данном случае я использую темплейт aws-nodejs, который создаст функцию и конфигурационный файл serverless.yml:

mkdir lambda-demo
cd lambda-demo
sls create —template aws-nodejs
npm install

Сама функция находится в файле handler.js. Давайте немного отредактируем его:

module.exports.hello = async event => {
return {
statusCode: 200,
headers: { 'Content-Type': 'text/html;charset=UTF-8' },
body: '

Hello, Lambda

',
};
};

Точка доступа принимает два аргумента (если она написана с использованием async/await, иначе у функции появляется третий аргумент callback):

• event — данные события, вызвавшем функцию. В случае с использованием AWS API Gateway этот объект будет содержать данные по HTTP-запросу.
• context — объект, содержащий информацию о текущем состоянии окружения (данные о функции, информацию о пользователе и т.д.).
• сallback — функция формата callback(error, data), возвращающая результат событию, если использована не «асинхронная» функция (имеется ввиду не async/await).

И немного подправим serveless.yml:

service: aws-nodejs # Название вашей лямбды

provider:
name: aws
runtime: nodejs8.10
stage: dev # Название этапа (любое значение, имеющее для вас какое-то значение)
region: us-west-2 # Регион Амазона, который установлен у вас

functions:
hello:
handler: handler.hello
# События, которые запускают лямбду, в нашем случае — http api-gateway
events:
— http:
path: hello
method: get

В больших проектах значение stage обычно равно ${env:AWS_STAGE, '${opt:stage, 'dev'}'} (либо просто ${opt:stage, 'dev'}), что позволяет считывать значение stage как с переменной окружения, так и с консоли (причем по умолчанию он будет установлен в dev):

// Деплой функции на другой стейджинг
sls deploy —stage test

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

Для запуска функции локально можно воспользоваться следующей командой:

serverless invoke local —function hello

В результате в ответ мы увидим результат работы функции:

{
«statusCode»: 200,
«headers»: { «Content-Type»: «text/html;charset=UTF-8» },
«body»: »

Hello, Lambda

»
}

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

Деплой #

Запускаем:

sls deploy

В результате в консоли мы увидим следующее:

Serverless: Packaging service…
Serverless: Excluding development dependencies…
Serverless: Creating Stack…
Serverless: Checking Stack create progress…
…..
Serverless: Stack create finished…
Serverless: Uploading CloudFormation file to S3…
Serverless: Uploading artifacts…
Serverless: Uploading service aws-nodejs.zip file to S3 (10.17 KB)…
Serverless: Validating template…
Serverless: Updating Stack…
Serverless: Checking Stack update progress…
…………………………
Serverless: Stack update finished…
Service Information
service: aws-nodejs
stage: dev
region: us-east-2
stack: aws-nodejs-dev
resources: 10
api keys:
None
endpoints:
GET — https://XXXXXXX.execute-api.us-east-1.amazonaws.com/dev/hello
functions:
hello: aws-nodejs-dev-hello
layers:
None

И у нас есть открытый наружу url, по которому можно вызвать нашу лямбду:

curl https://XXXXXXX.execute-api.us-east-2.amazonaws.com/dev/hello

Или мы можем запустить лямбду напрямую и вывести результат работы в консоль с помощью команды invoke:

serverless invoke —function hello —log

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

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

Когда лямбду захочется удалить, достаточно выполнить:

sls remove

И удалится вся инфраструктура, которая описана в serverless.yml.

Что еще можно сделать на лямбдах? #

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

Но лучше всего лямбды конечно же подходят для прототипирования, чат-ботов, IoT (Internet of Things), обработкой файлов и т.п.

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

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

Но технология находится еще на начальном пути, и со временем будет только расти и развиваться, поэтому попробовать в любом случае рекомендую (тем более амазон на начальных этапах предлагает все попробовать бесплатно). На https://serverless.com/examples/ можно найти много примеров использования и туториалов, а на сайте амазона официальную документацию по лямбдам.