#AWSLambda

Сьогодні не те щоб найцікавіші функції, яких в кожному проєкті вистачає. (Хоча гарно, що простий CRUD на Swift UI робиться без зайвих перешкод.) Тому розкажу про іншу цікаву знахідку.

На вихідних одна AWSLambda накрилася та почала замість 15 секунд тривати 15 хвилин, тобто вилітати за браком часу. Лямбда ця запускається за розкладом та перекачує дані з Kafka ще кудись. Ніяких підстав бути такою повільною в неї не було.

В Кафки особливий підхід до споживачів, а саме: щоб уникнути повторної обробки даних, споживачі в групі ділять між собою потік задач. (Саме для того потоки — теми - topic діляться на розділи - partition.) А це своєю чергою значить, що коли споживач уходить, або зʼявляється новий, Кафка негайно виконує перебалансування групи. А якщо споживач просто відвалився, то щоб переконатися в його відсутності потрібний ще й тайм-аут. (Тому важливо завжди виходити з групи ввічливо.)

(До речі, це значить, що лямбди — не краще поєднання з Кафкою; сталий сервіс однозначно природніше. Втім, в моєму випадку на цілий сервіс задач було мало.)

Що, гадаю вийшло: в якийсь момент чергова лямбда “спіткнулася” - можливо, в Кафці йшли роботи, які самі викликають перебалансування — та зависла. Після того її наздогнала наступна лямбда, та вони почали ділити між собою групу в Кафці. Далі почався каскадний ефект: поки старі лямбди запускалися наново, зʼявлялися ще й нові та викликали нове перебалансування, причому кожна з них мала необмежену кількість спроб, тому вони нікуди не зникали, та проблема тривала аж до ручного втручання.

Виявилося, що запуск лямбд за розкладом — не така тривіальна справа. 1)тайм-аут лямбди повинен бути менше за інтервал розкладу - це, думаю, очевидно. 2) в налаштуваннях рівночасності треба вказати 1 рівночасне виконання, щоб уникнути набігання. 3) в налаштуваннях надійності вказати 0 повторних спроб, бо лямбда все одно запуститься за наступним розкладом. 4) там же ж вказати мінімальний вік подій, бо знов-таки немає сенсу обробляти старий розклад, коли завжди буде новий.