Чому я переніс свій Laravel-додаток на AWS Serverless (і як це може заощадити ваш час і гроші) - javascript.org.ua

Спойлер: Справа не лише в економії грошей — хоча мій гаманець і не скаржиться.

Уявіть собі: ви створили блискучий Laravel-додаток — ваш шедевр, цифровий швейцарський ніж із функціями, які настільки гострі, що можуть різати масло… або відгуки користувачів. Але є одна проблема. Щомісяця ви платите за EC2-інстанс, який використовується так само мало, як абонемент у спортзал після січня. А масштабування нагадує спробу припаркувати круїзний лайнер під час урагану.

Знайомо? Я теж там був.

Три роки тому я зробив те, що більшість розробників назвали б божевіллям: я запустив PHP на AWS Lambda. "PHP? На serverless? Це як ананас на піці!" — казали вони.

Але зараз, через три роки, я їм свою ананасову піцу з гордістю. Дозвольте мені пояснити, чому serverless Laravel — це хмарне оновлення, яке ви навіть не знали, що вам потрібне.

1. Проблеми традиційного хостингу Laravel

(або: Чому мої EC2-інстанси страждали від кризи ідентичності)

До переходу на serverless мій Laravel-додаток працював на EC2. Для непосвячених EC2 — це версія віртуального приватного сервера від Amazon, де ви орендуєте частину машини для виконання свого коду. Звучить непогано, чи не так? Поки реальність не б'є сильніше, ніж несподіваний composer update.

a) Перше: Вартість "дихання"

Утримувати EC2-інстанс — це як мати Tesla, яка працює 24/7, просто на випадок, якщо ви захочете поїхати. Мій додаток не завжди був завантаженим, але це не зупиняло лічильник витрат. Між EC2-інстансами, балансувальниками навантаження та спільним сховищем я витрачав близько $110 на місяць на серверну інфраструктуру, яка більшість часу простоювала. Мій гаманець? Відчував себе як "Титанік".

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

b) Далі: Кошмар масштабування

EC2-інстанси схожі на друга, який завжди перебільшує.

Сплеск трафіку? "Я зараз впаду, дякую!"
Затишшя в трафіку? "А я все одно спалю твої гроші!"

Керування автоматичним масштабуванням було схоже на навчання риби жонглюванню — це можливо, але за яку ціну? Ручне налаштування груп масштабування, конфігурування балансувальників навантаження та молитви, щоб я не виділив зайві ресурси, відчувались як друга робота, на яку я не підписувався.

c) І, нарешті, DevOps: неоплачуваний стажер

Ніхто не попереджав мене, що розробка Laravel включає в себе обов'язки системного адміністратора:

Установка патчів безпеки.
Налагодження конфігурацій nginx/apache о 3 ранку.
Шепіт "лагідних" слів до команд sudo, сподіваючись, що вони спрацюють цього разу.

Я не підписувався на таке життя.

Саме тоді я почав шукати альтернативи, і serverless став ідеальним рішенням для цих проблем.

2. AWS Serverless: Перевтілення PHP у хмарі

Розвінчаємо міф: serverless не означає "без серверів". Це означає, що серверами займається хтось інший. У цьому випадку, важку роботу виконує AWS, а я зосереджуюсь на тому, що мені справді подобається — написанні коду.

a) Lambda: Чарівник, що працює за подіями

AWS Lambda — це як супергерой, який з’являється тільки тоді, коли це потрібно. Він виконує ваш код у відповідь на події — HTTP-запити, повідомлення SQS, cron-завдання, ви називаєте. І після завершення роботи зникає швидше, ніж безкоштовна піца на зустрічі розробників.

Жодних витрат на простій: Платіть тільки за час виконання (вимірюється в мілісекундах).
Магія автоматичного масштабування: Сплеск у 100,000 запитів? Lambda обробляє їх без жодних проблем (і без руйнування вашого бюджету).
Стейтлес за дизайном (Stateless): Це як чистий аркуш щоразу — дизайн, який змушує вас думати модульно.

b) Керовані сервіси: Невидимі герої

Serverless — це не тільки Lambda, це ціла екосистема.
AWS замінює вашу інфраструктуру власного управління на керовані сервіси, які "просто працюють":

Бази даних: Оптимізовані для serverless варіанти, як-от Aurora Serverless (MySQL/Postgres), для тих, хто любить SQL.
S3: Зберігайте файли без занепокоєння щодо нестачі місця на диску.
SQS: Розділяйте довготривалі завдання та обробляйте їх асинхронно.

c) PHP-парадокс

Мушу зізнатися: PHP не народжувався для serverless. Це як просити рибу залізти на дерево — вона буде скаржитися, але зрештою зробить це. Laravel, традиційно залежний від PHP-FPM, потребував деяких доопрацювань, щоб процвітати у світі епізодичності Lambda:

Сесії: Перенесіть їх до зовнішньої бази даних, наприклад MySQL або Redis.
Файлове сховище: Перенаправте всі операції зі збереження файлів до S3, використовуючи фасад Storage Laravel.
Обробка черг (Queue handling): Налаштуйте SQS як драйвер черги за замовчуванням для асинхронного виконання завдань.
Кешування: Використовуйте зовнішні сервіси, такі як Redis або DynamoDB, замість локального сховища.
Оптимізація часу завантаження (Boot time optimization): Мінімізуйте холодні старти, видаляючи зайві залежності.
Змінні середовища (Environment variables): Замініть .env файли на AWS Secrets Manager або Parameter Store для безпечного та централізованого управління конфігурацією.

Пам’ятайте, serverless — це не просто заміна серверів на функції Lambda. Це переосмислення вашої архітектури — перекладання операційних завдань на AWS, щоб ви могли зосередитися на розробці.

3. Як Serverless розкриває весь потенціал Laravel

Отже, чи виправдовує serverless Laravel свої обіцянки?

Serverless — це не просто модне слово, це зміна гри. Чарівність serverless Laravel полягає у здатності вирішувати проблеми традиційного хостингу, забезпечуючи при цьому швидші, масштабовані та економічно ефективні рішення. Але справжня магія проявляється, коли ці переваги об'єднуються. Розберімо це докладніше.

a) Холодні старти: відокремлення міфів від реальності

Холодні старти виникають, коли Lambda ініціалізує новий екземпляр. Уявіть, що це PHP, який прокидається після короткого сну. Критики трактують це як апокаліпсис, але насправді це керована проблема:

Реальність: Типовий холодний старт із PHP + Laravel триває ~3–5 секунд.
Рішення:
- Laravel Octane: Зберігає застосунок "живим" між запитами, зменшуючи час завантаження. Наступні запити обробляються за ~200 мс або менше.
- Provisioned Concurrency: AWS попередньо прогріває екземпляри для критичних кінцевих точок (коштує додатково, але виправдано для критичних сценаріїв).

b) Масштабування без сліз

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

Ось приклад:

Сценарій: Ваш додаток стає вірусним 🚀!
Стара конфігурація EC2: Збільшується затримка, ви в паніці входите в AWS, вручну змінюєте кількість інстансів і сподіваєтеся на краще 🫠. І не забудьте належним чином збалансувати ці інстанси по зонах доступності.
Нова конфігурація Lambda: AWS автоматично запускає стільки інстансів, скільки потрібно, обробляючи тисячі одночасних запитів без вашого втручання. Ви насолоджуєтесь попкорном і спостерігаєте за метриками CloudWatch, як за серіалом Netflix 🍿.

Це не просто зручність — це спокій. Поки ви святкуєте успіх свого додатка, Lambda виконує всю важку роботу.
І найкраща частина? Ви платите лише за час виконання обчислень, а не за невикористану потужність, яка може знадобитися "про всяк випадок".

c) Ефективність витрат: справжній герой

Serverless не просто економить гроші — це як буфет за $5, де ви платите тільки за те, що з’їли.

Моя стара конфігурація EC2:

4x EC2 t3.small інстанси: $60.00
1x Load Balancer: $16.40
1x EBS (спільне сховище між EC2 інстансами): $7.80
1x RDS MySQL інстанс (db.t4g.medium): ~26.00
~$110 /місяць.

Lambda

Lambda, API Gateway ~2.5M запитів (~500 мс / 512MB пам’яті) /місяць: $4.80
Керовані сервіси (S3, SQS, CloudWatch): ~$2.90
RDS MySQL інстанс (db.t4g.medium): ~26.00
~$34 /місяць (економія 60%!).

Коротко кажучи, serverless не просто економить гроші — він звільняє ментальний простір. Чим менше ресурсів витрачається на турботи про надмірне виділення потужностей, тим більше можна зосередитись на створенні чогось дивовижного.

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

d) Свобода від обслуговування: попрощайтеся з нічними кошмарами Ops

Serverless звільнив мене від кайданів обслуговування серверів. Ось як:

Жодних ручних оновлень: AWS займається патчами серверів, оновленнями операційної системи та середовища виконання, що гарантує безпеку та актуальність інфраструктури.
Спрощені конфігурації: Завдяки сервісам на кшталт API Gateway та S3 складність управління конфігураціями nginx та кастомними деплойментами залишилась у минулому.
Еластична потужність: Забудьте про переплати за невикористані серверні ресурси або метушню з їх виділенням під час сплесків трафіку. Lambda автоматично масштабується під запит, а під час простою припиняє стягувати кошти.
Фокус на функціях, а не на проблемах: Час, який раніше витрачався на застосування патчів або налагодження проблем у продакшені, тепер присвячується створенню функцій і покращенню досвіду користувачів.

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

4. Але чи підходить Serverless Laravel для всіх?

Наскільки революційним є serverless Laravel, це не універсальне рішення. Для деяких додатків безстанова, подієва природа serverless може бути справжньою мрією. Для інших це може нагадувати спробу втиснути квадратний кілок у круглий отвір. Перш ніж стрибати на хвилю serverless, зробімо крок назад і оцінімо, чи це підходить для вашого проєкту.

a) Безстанова природа: двосічний меч

Laravel любить операції, які залежать від стану, такі як локальне збереження файлів або кешування сесій у файловій системі. Для переходу на serverless необхідно змінити:

Сесії: Використовуйте бази даних (MySQL/Postgres) або Redis — більше ніяких файлових систем.
Файли: Перенаправте завантаження на S3 або обходьте Laravel через попередньо підписані URL-адреси S3.
Логи: Налаштуйте Laravel для стрімінгу логів у CloudWatch.
Конфігурація: Перенесіть змінні .env до AWS Secrets Manager або Parameter Store для централізованого управління.
Черги: Перенесіть завдання до AWS SQS для масштабованого управління чергами та обробки повідомлень.

b) Залежність від постачальника (Vendor Lock-In)

Сервіси AWS є магічними, але вони також є власними:

Хочете перейти з SQS на Redis черги? Готуйтеся переписувати код.
Хочете змінити Lambda на Docker? Приготуйте каву — це буде довга ніч.

c) Коли варто уникати Serverless

Serverless не є чарівною паличкою для всіх завдань. Уникайте його, якщо:

Вам потрібні WebSockets: Хоч це можливо з API Gateway + WebSocket API або сторонніми інструментами, такими як Ably, це додає складності.
Ваш додаток виконує інтенсивні обчислювальні задачі: Завдання, такі як AI/ML інференсія або кодування відео, можуть досягти ліміту в 15 хвилин для Lambda.
Ви залежите від стану серверів: Додатки, які припускають постійний диск або стан сервера, можуть бути дорогими для рефакторингу.

5. Що далі?

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

Запитання до вас: Який ваш найбільший страх щодо serverless? Поділіться в коментарях — я розгляну топ-3 у другій частині!

Перекладено з: Why I Migrated My Laravel App to AWS Serverless (And Why It Could Save You Time and Money)