Рубріки: Веб-розробка

Спробуйте нове: популярні варіанти використання AWS Lambda та 5 головних інструментів для роботи з нею

Сергій Свеженців

У своїй попередній статті на Highload я детально розповів про користь лямбда-функцій, які значно спрощують роботу девелопера.

Сьогодні ми продовжимо розмову і звернемо увагу на витрати, моніторинг, популярні варіанти використання лямбда-функції, а також фреймворки та інструменти для роботи з нею.

Оптимізація витрат при роботі з AWS Lambda

Оплата за послуги AWS розраховується у кілобайт-секундах. Це кількість кілобайт оперативної пам’яті в налаштуваннях лямбди, помножених на час виконання функції в секундах. Майже завжди збільшення пам’яті жодним чином не впливає на загальну суму. А все тому, що разом зі зростанням продуктивності зменшується й час.

Наприклад, при збільшенні оперативної пам’яті вдвічі час може скоротитися більш ніж вдвічі.

Погляньмо на цей графік. Тут найнижчі витрати досягаються на відрізку від 1024 до 1536 МБ. Хоча спочатку могло здаватися, що для максимальної економії треба ставити базові 128 МБ.

Моніторинг із CloudWatch

За замовчуванням відстеження роботи лямбда-функції здійснюється через сервіс CloudWatch. У нього інтегруються та відправляються службові дані, які частково не доступні у логах. Існує близько десятка популярних метрик для налаштування та виведення на дашборд.

У прикладі нижче наведено три таких метрики:

Із першого графіку зрозуміло, що близько 12:00 значно зросла кількість звернень до лямбда-функції. На другому графіку видно, що час виконання функції в середньому становить близько 1000 мілісекунд. На третьому — фіксується високий показник помилок. Усе разом дає чимало приводів для роздумів про виконання лямбди, падіння по таймінгу та отриманих фейлах.

Також через сервіс CloudWatch відбувається логування даних із лямбда-функції.

Тобто все, що надсилається до STDOUT (log або print), надсилається саме в CloudWatch. Там для кожної лямбда-функції створюється своя лог-група, всередині якої збираються стріми.

Стрім — це вся інформація з логів від функції, від одного екземпляра енвайроменту. Якщо у вас було кілька звернень до функції за короткий проміжок часу, і вона весь час працювала, це буде зібрано в одному стрімі.

Шлях до нього складається з дати першого виконання, версії лямбда-функції та рандомного хешу із цифр:

На наступній ілюстрації наведено приклад логів лямбда-функції, яка була написана вище. Маємо три звернення до лямбди, коли тричі передавалося ім’я John. І все це з інтервалом у кілька секунд тричі збиралося в цьому звіті:

У першому лозі зверніть увагу на принт Loading function у другому рядку, який оголошено поза лямбдою-функцією. Він ніде не повторюється. В цьому випадку для Python не відбувається жодного імпорту бібліотек для вже створеного оточення.

Також у першому лозі є важливий блок Init Duration. Це час на завантаження коду, створення оточення та виконання всіх імпортів та самого коду поза методом оброблювача. Фактично це все, що відбувається при холодному старті: підключення до різних баз даних та сервісів, де зберігаються секрети. При повторному використанні середовища це вже не відбуватиметься.

Пермісії

В інфраструктурі сервісів AWS передбачено чіткий поділ доступів на читання та виконання для різних ресурсів навіть в одному обліковому записі. Для цього використовується механізм сервісу Identity Access Management. Він передбачає створення Policy — політик. Описи пояснюють, який ресурс та до чого має доступ.

Тут усе доволі суворо обмежено: неможливо навіть зробити запис у CloudWatch без Policy на дозвіл зміни у логах. Ми в нашій команді часто створюємо ліміт на функцію консолі, в дашборді AWS, щоб він автоматично підставляв такі пермісії до ролей.

Для лямбда-функції існують два типи політик:

  • Політики ресурсу (на схемі ліворуч)

Описують, який сервіс може звертатися до лямбди та запускати її. Ця політика застосовується на лямбда-функцію та існує як окремий роут. API Gateway звертається до функції, аде не йдеться про конкретну функцію. Така політика пов’язана з однією дією для кількох ресурсів.

  • Політики виконання

Вказують, до яких ресурсів може звертатися функція. Ці політики існують як окремі сутності та можуть бути розшарені між кількома лямбдами. Також тут прописуються дії, які мають здійснитися, та ресурс, до якого є доступ. Для цього використовується ARM (Amazon Resource Name), що виступає ідентифікатором ресурсу.

Layers

Це зручний спосіб упаковки бібліотек та залежностей, якщо їх потрібно використовувати спільно для декількох лямбда-функцій. Сам по собі це ZIP-архів, який для оточення лямбда-функції розпаковується у директорію opt. Він може бути публічним або приватним.

Також лейери знадобляться у випадку частих змін коду лямбда-функції, коли залежності залишаються такими ж. Тоді ви змінюєте розмір функції при деплої. Бізнес-логіка переважно важить мало, але пакет залежностей може бути дуже важким. Тому з лейєром вам не потрібно витрачати час на повторне завантаження залежностей до хмари.

Ось приклад розподілу лейєрів. Лямбда-функції 1 та 3 спільно використовують бібліотеки. Лямбда-функції 2 та 3 ділять ассети. Наприклад, шаблони листів чи HTML, до яких вони матимуть доступ:

Популярні варіанти використання лямбда-функції

Усі ці приклади стосуються взаємодії користувачів із функцією та базою даних. Про кожен із них розповім окремо.

Почнемо по рядках зверху донизу:

  • Перший варіант починається з ендпоінту, створеного за допомогою API Gateway.
  • Далі розташований Kinesis Data Streams. Він отримує інформацію зі стріму користувачів і передає її до лямбда-функції.
  • Остання ж обробляє і фільтрує дані, які потім зберігаються в DynamoDB. Так, скажімо, влаштована аналітика дій користувачів у сфері реклами.

У наступному Use Case за API Gateway йде лямбда-функція. Фактично вона є вебзастосунком до Flask або Fastapi (на них пишуться функції).

Перед нами моноліт, що не є хорошою практикою, але це рішення є виправданим. Адже так можна позбутися втрат часу на холодному старті.

Схема організована наступним чином:

  • Спочатку ця вебпрограма приймає запит від користувача.
  • Далі відбувається асинхронний виклик функції, яка повинна здійснювати API call у сторонній сервіс IP-телефонії. Тобто відбувається передача масиву інформації про користувачів, їх номери телефонів тощо.
  • Ця лямбда-функція в змінних оточення матиме токен на доступ до сервісу IP-телефонії. При цьому у вебзастосунку дозволу немає, тому схема досить сек’юрна. Отже можна відразу повернути респонс ініціатору запиту, не очікуючи звернення до стороннього сервісу. Перебір користувачів в одній лямбда-функції або запуск безлічі функцій для кожного юзера IP-телефонії здійснюватиметься фоново для окремої функції-обробника.

Третій рядок на схемі визначає роботу з базою даних. У ній лямбда-функція підключена до БД через RDS Proxy. Це хороша практика, адже інстансів у лямбді може бути безліч. Тобто водночас до бази даних надходитимуть десятки звернень. RDS Proxy допомагає уникнути можливих проблем. Проксі збирає всі підключення від лямбда-функції та встановлює єдине підключення до реляційної бази даних.

Оскільки в цій схемі відсутні Gunicorn, Nginx чи Apache, розробнику достатньо підключити якусь бібліотеку. Є лише метод handler для обробки реквесту від API Gateway. Наприклад, для Flask цим способом є Lambda middleware, яку підключають до Flask-застосунку. Він трансформує івент від API Gateway на щось більш читабельне та схоже на WSGI-реквест від вашого HTTP-серверу.

Для асинхронних фреймворків на зразок Fastapi існує кілька бібліотек, які запускають програму в асинхронному циклі. Всередині циклу вони також трансформують івент від API Gateway на об’єкт, альтернативний ASGI-реквесту.

Найнижчий приклад на схемі показує завантаження користувачем файлів безпосередньо до S3 в обхід ендпойнту та лямбда-функції. У відповідь на ей івент спрацьовує певний тригер. Він ніби каже: потрібно зберегти інформацію про завантажений файл у базу даних та метадані на кшталт часу завантаження. Все це записується до івенту, який формується у S3. Лямбда-функції залишається лише отримати ці дані та записати їх у реляційну БД.

Фреймворки та інструменти для роботи з AWS Lambda

1AWS Serverless Application Model

На мою думку, це найзручніший і найгнучкіший інструмент для написання лямбда-функцій. Він розроблений та підтримується Amazon.

SAM складається з двох частин:

  • перша — консольна утиліта для ініціалізації, деплою і тестування проєктів;
  • друга — це YAML для опису ресурсів.

Причому це не обов’язково має бути лямбда-функція. Допустимі як serverless-ресурси, на кшталт DynamoDB та Aurora, так і звичайні амазонівські ресурси. Також тут можна розписати всі ролі з правами доступу.

2AWS Command Line Interface

Основна консольна утиліта для роботи з обліковим записом. Якщо працюєте з TensorFlow, можливо вам знадобиться генерувати креди і токени. Їх можна прописати за допомогою цієї утиліти. Майже всі фреймворки для розробки лямбда-функцій є надбудовою AWS CLI.

3Serverless Framework

Своєрідний шаблон, де описуються потрібні ресурси. Serverless Framework підтримує роботу з Azure і Google Cloud.

4AWS Chalice

Одночасно консольна утиліта і Python бібліотека для розробки serverless-застосунків. У цьому випадку вам не треба описувати властивості ресурсів у шаблонах, як це необхідно з YAML.

Всі операції виконуються за допомогою декораторів, що надаються функціям, написаним у Chalice. Далі ця утиліта перед деплоєм за допомогою консолі підхоплює всі дані та розгортає. Дуже зручно та швидко.

5AWS Amplify

Потужний фреймворк для фулстек-розробки. Являє собою консольну утиліту з набором бібліотек для фронтенду. Наприклад, можна розробити сервіс для авторизації користувачів без розуміння принципів роботи самого AWS.

Вам буде достатньо прочитати документацію, щоб за кілька операцій у консолі створити Amplify At Authorization. Потім так само читаєте документацію з фронтенду — і в самому проєкті імпортуєте, наприклад, клас для React. А він вже реалізує форму авторизації та локально збереже токен.

Щоправда, через певні обмеження інколи це працює «на милицях». Наприклад, у SAM можна вписати в шаблон потрібні ресурси, щоб утиліта сама генерувала все необхідне. А в Amplify в принципі немає такої реалізації. Якщо ви впишете щось самостійно, то при наступному оновленні ресурсу або зміні його властивостей система все зітре. Тож використовуйте цей фреймворк обережно.


Цими інструментами робота з лямбда-функціями не обмежується. Та й сама тема AWS Lambda набагато ширша. Тож раджу вам не зупинятися на базових поняттях і постійно пробувати щось нове. З лямбда-функціями ви неодмінно отримаєте широкі можливості для покращення свого проєкту.

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

Останні статті

IT в Україні йде до свого фінального кінця. І потраплятимуть туди виключно за покликом душі

Коротко про українську IT-сферу у 2024 році Це коли на одну вакансію Middle розробника по…

26.03.2024

Блокчейн-розробка сьогодні: зарплати і перспективи на ринку праці

Формування криптовалютної галузі в Україні почалося ще у 2014 – саме тоді з'явилися перші стартапи,…

18.03.2024

Скільки рішень ухвалює розробник? Погляд новачка, який запускає продукт

Автор цього блогу — Python-девелопер Сергій Солдатов, який вирішив створити досить унікальний продукт. І це…

12.03.2024

Чи треба готуватись до співбесіди?

Думки шукачів діляться на: «так, однозначно» і «ні, не вартує, я все і так про…

04.03.2024

Відкладаєте до останнього? Що таке «синдром студента» і як з ним боротися

Синдром студента — це форма прокрастинації, яка полягає в тому, що людина, якій дали завдання,…

23.02.2024

Вчимося працювати з Git: основи конфігурації, гілки, додавання файлів та директорій

Git — це найпопулярніша CVS прямо зараз, яка дозволяє відстежувати історію розробки і спільно працювати.…

20.02.2024