AWS Step Functions та основні способи його використання

Якщо вам потрібно координувати роботу AWS сервісів та об’єднати окремі процеси у єдиний воркфлоу, AWS Step Functions — те, що треба.

У статті ви дізнаєтесь, чим відрізняється цей інструмент від інших подібних рішень в екосистемі AWS. Я розгляну основні задачі, які може вирішити AWS Step Functions, та наведу спрощені приклади налаштування воркфлоу.

Що таке оркестрація

AWS Step Functions застосовується для оркестрації AWS сервісів. У розробці програмного забезпечення оркестрація означає автоматичну конфігурацію та координацію сервісів або систем. Це дозволяє поєднати їх в єдиний автоматизований процес.

Інструмент для оркестрації забирає на себе типові задачі, що можуть виникнути при створенні воркфлоу, зокрема:

• послідовний запуск тасків;
• ретраї неуспішних тасків;
• паралелізація процесів;
• вибір гілки воркфлоу в залежності від результатів попередніх кроків;
• обробка помилок.
Онлайн курс з промт інжинірингу та ефективної роботи з ШІ від Powercode academy.
Курс-інтенсив для отримання навичок роботи з ChatGPT та іншими інструментами ШІ для професійних та особистих задач, котрі допоможуть як новачку, так і професіоналу.
Записатися на курс

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

Переходимо до AWS Step Functions

AWS Step Functions — це безсерверний інструмент оркестрації, який може керувати AWS сервісами і створювати з їх комбінацій воркфлоу.

Step Functions базується на поняттях state machine і стейтів (станів). Стейт — одиниця роботи, тобто крок у воркфлоу, що виконує інший AWS сервіс. State machine — це опис переходів між цими стейтами. Прикладом простої стейт машини може бути вендінговий автомат. Він має зліченну, заздалегідь визначену кількість стейтів та ланцюжки переходів між ними:

Типові патерни використання Step Functions

AWS Step Functions дозволяє створювати воркфлоу через візуальний редактор (Workflow Studio) або через JSON документ.  Нижче я наведу перелік поширених патернів побудови воркфлоу.

Послідовний запуск сервісів

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

Розгалуження логіки

Можна обирати різні гілки виконання воркфлоу в залежності від даних.

Обробка помилок

Степ функція реалізує як ретраї для неуспішних кроків так і try/catch функціонал з можливістю по-різному обробляти різні типи помилок.

Колбеки

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

Паралельне виконання

Можливість запускати окремі гілки воркфлоу у паралель. Такі гілки необов’язково повинні мати однакову структуру і довжину. Для кожної гілки потрібно визначити умову успішного завершення. В результаті дані усіх гілок складаються у масив, до якого можна отримати доступ з наступних кроків.

Динамічна паралелізація (Map)

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

Step Functions серед інших рішень

Workflow у Lambda-based застосунках

Чому б просто не викликати наступну лямбду з коду попередньої або не використовувати додаткову лямбду як оркестратор? Якщо ми хочемо створити альтернативу до Step Functions за допомогою лямбди та мати центральну лямбду-координатор, яка зберігає стан між стейтами та інкапсулює управління воркфлоу, це призводить до кількох проблем:

• Висока вартість. Одна з категорій ціноутворення у лямбд — тривалість використання. Якщо лямбда очікує завершення тасків від інших лямбд або сервісів (наприклад, щоб зберігати стан воркфлоу) тривалість її роботи стає більшою, відповідно зростає ціна.
• Коротка максимальна тривалість роботи. У лямбд є максимальна тривалість роботи, яку не можна змінити — 15 хвилин. Максимальна тривалість роботи для Step Functions — 1 рік (для Standard воркфлоу).
• «‎Роздутий» код обробки помилок. Лямбда-координатор стає відповідальною за обробку усіх помилок, які виникають у вкладених лямбд, а це призводить до розростання коду.

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

До того ж це тісно пов’язує лямбди між собою й ускладнює подальші зміни. Наприклад, додавання або видалення сервісу з воркфлоу. Кращим рішенням для подолання цих проблем є використання Step Functions, або роз’єднання сервісів за допомогою черг (наприклад, AWS SQS).

AWS Simple Workflow Service

SWF допомагає координувати роботу між розподіленими компонентами застосунку. Сервіс з’явився на 4 роки раніше за Step Functions. На відміну від них, SWF це не серверлес сервіс. Тож розробники відповідають за управління інфраструктурою, на якій «‎біжить» воркфлоу.

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

Згідно з офіційною документацією, AWS рекомендує розпочинати нові проєкти, що потребують оркестрації, саме на Step Functions. Це просте, наочне рішення на противагу SWF. Винятком є випадки, коли складність воркфлоу потребує більшого контролю над програмою-координатором, ніж це дозволяє Step Functions.

Також існує AWS Flow Framework — офіційний фреймворк, що спрощує розробку для SWF. Наразі він підтримується тільки для Java. Розробка під інші мови програмування поки не планується.

AWS EventBridge

Це event bus з великою кількістю доступних інтеграцій з AWS сервісами. EventBridge збирає івенти з сервісів і дозволяє визначати правила, за якими маршрутизує ці івенти в інші сервіси. Останні ж визначають поведінку, якою вони реагують на ті чи інші івенти. Цей паттерн інтеграції називається хореографією.

Хореографія відрізняється від оркестрації тим, що в ній відсутній єдиний координатор, який керує процесом.

Переваги такого підходу:

• більша незалежність мікросервісів (loose coupling);
• гнучкість воркфлоу (можна легко додавати і прибирати сервіси з системи;
• враховуючи що координатора немає, він не становить єдину точку відмови, бо його несправність призводить до непрацездатності всієї системи.

Серед недоліків хореографії — складність відстежування, траблшутингу і підтримки воркфлоу.  Зважаючи на особливості оркестрації та хореографії, можна обирати між Step Functions та EventBridge для конкретної задачі.

Найчастіше EventBridge використовується в якості інтеграції для мікросервісів, якщо не потрібно суворо координувати і синхронізувати їхню роботу.

Standard vs Express workflow

При створенні стейт машини необхідно обрати тип — Standard або Express. Standard більше підходить для тривалих воркфлоу максимум на рік. Час очікування у воркфлоу не оплачується. Платними є тільки кількість переходів між стейтами. Повна історія кожного виконання воркфлоу зберігається 90 днів.

Якщо не визначена поведінка Retry, Standard воркфлоу слідує моделі виконання exactly-once, тому підходить для неідемпонтентих дій. Тобто коли повторна дія змінює результат, досягнутий при першому виконанні.

Express воркфлоу оптимізований для обробки великого обсягу даних. Максимальна тривалість значно менша — 5 хвилин. Оплачується за кількістю виконань, тривалістю воркфлоу та обсягом використаної пам’яті. Слідує моделі at-least-once, тому підходить тільки для ідемпотентних тасків, де не страшно, якщо таск виконається більше, ніж раз.

Express не підтримує патерни інтеграції .sync (пауза воркфлоу, очікування на завершення джоби) та колбек із таск токеном (пауза воркфлоу, очікування на повернення токену).

Cкладові Step Functions

Workflow

Воркфлоу у Step Functions описується з допомогою Amazon States Language. ASL має синтаксис на основі JSON, додатковими внутрішніми функціями для обробки вхідних/вихідних даних та зданою структурою опису стейтів. JSON з визначенням стейт машини зберігається у файл із розширенням .asl.json. 

Кожен воркфлоу повинен містити поле StartAt, масив стейтів і визначення закінчення флоу — поле End у стейті або стейт Success/Fail. Ось приклад воркфлоу з одним стейтом, що запускає лямбду:

Усі наведені тут і далі приклади коду можете переглянути у моєму GitHub.

States

Стейти — це будівельні блоки, з яких складається стейт машина. Стейти структуровані як маппінг імені стейту до його об’єкту. Вони можуть виконувати такі функції:

• Task: запуск інших сервісів:
• Choice: вибір між гілками воркфлоу. ASL містить багато вбудованих порівняльних операторів для різних типів даних, а також логічні оператори, що дозволяють поєднувати умови. Припустимо, вхідні дані стейту Choice виглядають так:А визначення стейту Choice і стейтів-гілок — наступним чином:Оскільки value == 2, виконається гілка SecondMatchState. Якщо value не дорівнює ні 1, ні 2, виконається DefaultState.
• Succeed, Fail: Зупинка воркфлоу з (не)успішним статусом:
• Pass: Передача вхідних даних у вихідні дані стейту. Вони можуть передаватися у чистому вигляді для дебагу, адже стейт машина логує вхідні і вихідні дані кожного стейту. Або ж стейт можна використовувати для трансформації даних за допомогою вбудованих фільтрів ASL.У прикладі нижче застосовується поле Parameters, яке дозволяє відфільтрувати вхідні дані, структурувати їх, як вам зручно, додавати статичні значення. Взагалі управління вхідними/вихідними даними стейтів — це окрема велика тема. Більше про це можете дізнатись з офіційної документації. За умови наступного інпуту:

  У такий стейт:

  

  Ми отримаємо наступний аутпут:

  

• Wait: Затримка на задану кількість часу або до конкретної дати і часу:
  
• Parallel: Паралельне виконання гілок воркфлоу. Кожна гілка має синтаксис окремого воркфлоу зі StartAt полем, групою States та визначенням завершення обробки:
• Map: Динамічна паралелізація, однакова паралельна обробка елементів масиву. Може бути inline aбо distributed.  Inline запускається у контексті воркфлоу, що містить стейт Map, має обмеження до 40 паралельних процесів і приймає на вхід тільки JSON масив.У distributed кожна ітерація запускається як окремий під-воркфлоу. Тому максимальна кількість паралельних процесів зростає до 10 000. У цьому режимі на вхід можна передати JSON масив або об’єкт із S3, наприклад CSV файл. У наведеному далі прикладі — запуск валідатора для усіх елементів масиву users. За замовчуванням Map стейт запускається в inline режимі:

Патерни інтеграції

Step Functions підтримує три патерни інтеграції сервісів:

• Request Response. Викликає сервіс й одразу після отримання респонсу про те, що сервіс запущено, переходить до наступного стейту, не чекаючи на фактичне завершення таску. Такий патерн використовується, якщо стейт Task має поле Resource, і там не вказано нічого, крім ARN:
• Синхронний запуск (.sync). На відміну від попереднього патерну, чекаємо на завершення таску і тільки потім переходимо до наступного стейту. Цей паттерн підтримується не для всіх сервісів. Повний список можете подивитися тут. У JSON визначенні такий патерн можна задати, якщо до ARN в полі Resource додати суфікс .sync:
• Колбек із таск токеном. Воркфлоу стає на паузу і чекає на повернення заздалегідь визначеного токену. Так можна реалізувати інтеграцію зі сторонніми системами або очікування на відповідь від людини. Підтримується для більшої кількості сервісів, ніж .sync, але теж не для всіх. У JSON схемі додається суфікс .waitForTaskToken до ARN у ресурсі. Токен автоматично генерується при запуску воркфлоу і присутній в об’єкті контексту, до якого можна отримати доступ через шлях $$.

Висновки

Step Functions — гнучкий інструмент для оркестрації в екосистемі AWS. Між різними типами воркфлоу, видами стейтів та патернів інтеграції він дає можливість побудувати координований воркфлоу під широкий спектр задач.

У якості оркестратора AWS сервісів Step Functions простіше у використанні рішення, аніж AWS SWF. Step Functions дозволяє створювати воркфлоу як через зручний візуальний редактор, так і через JSON визначення. Також надає можливість інтегрувати у воркфлоу сторонні сервіси і навіть людське втручання.

Тому Step Functions має переваги над іншими рішеннями, якщо система потребує воркфлоу із центральним керуванням. Step Functions надає покрокове логування та інкапсулює логіку оркестрації та обробку помилок.