Серверлес з AWS Lambda та Quarkus: як ми оптимізували витрати у 1000 разів

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Усім привіт! Я Андрій — Java Lead в компанії Geniusee. Сьогодні хочу поділитися своїм досвідом використання серверлесу в Java-проєкті та розповісти, чому я вважаю, що іноді це чудовий спосіб досягти кращих результатів для клієнта та компанії.

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

Початкова ситуація

Під час роботи над одним із проєктів я зіткнувся з серйозною проблемою, яка впливала на стабільність і вартість системи. Серверне рішення клієнта мало стабільне середнє навантаження на рівні 200 запитів на хвилину, що не вимагало надмірних ресурсів. Однак особливості бізнес-процесів спричиняли раптові пікові навантаження, коли кількість запитів могла зростати до 5000+ на хвилину.

Такі піки виникали миттєво та були непередбачуваними, що значно ускладнювало планування інфраструктури.

Для обробки трафіку використовували ECS-інстанси, які масштабувалися горизонтально у відповідь на зростання запитів. Проте запуск нових серверів займав від 30 секунд до хвилини. У результаті інфраструктура просто не встигала адаптуватися до різких піків, що призводило до втрати GET-запитів, помилок у роботі сервісів та незадоволених клієнтів.

Окрім технічних складнощів, проблема мала й фінансовий вимір. У системі використовувалося понад 30 мікросервісів, кожен із яких потребував підтримки окремих інстансів ECS. Через нерівномірність навантаження більшість цих інстансів простоювала значну частину часу, працюючи без дійсного навантаження. Своєю чергою, клієнт не бажав тримати інстанси постійно активними, оскільки це спричиняло б значні витрати на підтримку інфраструктури.

Таким чином, ми зіткнулися з двома основними викликами: забезпечити здатність системи обробляти пікові навантаження без втрат запитів і знайти спосіб знизити витрати на інфраструктуру, уникаючи непродуктивного використання ресурсів.

Дві основні проблеми, з якими звернувся клієнт

Використання ресурсів було неефективним. Сервери ECS працювали без навантаження протягом більшої частини часу. У клієнта спостерігалися періоди простою, коли навантаження на систему значно знижувалося або його не було взагалі. Наприклад, у нічний idle time. Запуск додаткових машин, які б працювали постійно, не мав сенсу, адже це призвело б до невиправданих витрат.

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

А також дефолтний ECS не міг швидко масштабуватися, щоб впоратися з різким зростанням запитів, що призводило до неможливості отримання своїх даних клієнтами.

Рішення: перехід на серверлес з Quarkus

Командою ухвалили рішення перейти на серверлес-архітектуру, обравши AWS Lambda. Основними причинами вибору цієї технології стали її здатність автоматично масштабуватися відповідно до наявного навантаження, модель оплати «pay-as-you-go», яка дає змогу значно знизити витрати, а також висока доступність та інтеграція з іншими сервісами AWS, що було важливим для проєкту.

Наша основна задача: забезпечити мінімізацію змін у кодовій базі під час перенесення наявного сервісу на Lambda.

Ми прагнули зберегти функціональність і стабільність сервісу, водночас отримуючи вигоди від переходу на серверлес-архітектуру.

Раніше перехід на Lambda був можливий, але часто супроводжувався суттєвими труднощами. Однією з головних проблем були cold-start, особливо для Java-застосунків, які традиційно потребують більше часу на ініціалізацію в порівнянні з іншими мовами програмування. Це створювало затримки у відповідях і могло вплинути на користувацький досвід під час пікових навантажень.

Результат: які проблеми вдалось розв’язати

Перехід на Quarkus допоміг суттєво покращити продуктивність системи та мінімізувати проблему cold-start. Раніше час холодного старту сервісів міг займати кілька секунд, що було критичним для сценаріїв із короткотривалими запитами. Завдяки Quarkus cold-start тепер займає максимум 1,1 секунди, що значно прискорило роботу системи та забезпечило кращий користувацький досвід.

Окрім цього, продуктивність сервісів зросла в десятки разів. Наприклад, запити, які раніше на ECS і Spring Boot оброблялися за 500 мілісекунд, після міграції на Quarkus оброблялися лише за 13. Це забезпечило швидшу реакцію системи навіть під час пікових навантажень і значно знизило затримки.

Переваги серверлес-архітектури у цьому кейсі:

• AWS Lambda дала клієнту змогу сплачувати лише за ті ресурси, які реально використовувалися. У періоди простою витрати на інфраструктуру були відсутні, а при пікових навантаженнях Lambda автоматично масштабувалася, забезпечуючи обробку додаткових запитів без втрат даних.
• Lambda забезпечила миттєве масштабування системи, усунувши проблему затримок із запуском нових інстансів. Система адаптувалася до змін навантаження без додаткового втручання, гарантуючи стабільну роботу навіть у пікові періоди.
• Перехід на серверлес зменшив потребу в адмініструванні інфраструктури та прискорив процес впровадження змін, що допомогло заощадити час і ресурси команди.
• AWS Lambda забезпечила високу доступність системи, стабільно обробляючи запити навіть за раптових пікових навантажень.

До міграції клієнт витрачав понад $50 000 на рік на ECS-інфраструктуру, тоді як після переходу витрати знизилися до $46 на рік.

Чому саме Quarkus

На відміну від Spring Boot, який має довгий час ініціалізації та значне споживання пам’яті, Quarkus допоміг нам адаптувати сервіс для AWS Lambda без істотного переписування коду.

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

Тож, підсумовуючи, перехід на серверлес з допомогою Quarkus дав нам значні покращення в кількох ключових аспектах.

Завдяки тому, що клієнт став платити лише за фактичне використання ресурсів, витрати на інфраструктуру знизилися в рази. Це дало змогу значно скоротити бюджет на підтримку інфраструктури, зекономивши понад 1000 разів у порівнянні з попередньою моделлю на ECS.

Після міграції на серверлес з Quarkus час обробки запитів зменшився в 150 разів. Ті ж запити, які раніше потребували 500 мілісекунд на традиційному серверному рішенні, на новій архітектурі обробляються за 13. Це значно покращило швидкість реагування системи.

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

Висновки

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

Однак коли сервіс не потребує постійного завантаження 24/7, має нерегулярні або пікові навантаження, та виконує короткотривалі запити, серверлес-архітектура стає не лише логічним, а й економічно вигідним вибором.

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