TFTL · Пропозиція архітектури · для Avalon · 24.06.2026
Після кампанії пропонуємо перенести проєкт із єдиної машини на набір сфокусованих сервісів AWS Lightsail: окремий бекенд, окрема керована база, картинки через CDN і окремий фронтенд із SSR наживо. Менше конкуренції за ресурси, більше запасу під пік, передбачувана ціна.
Навіщо
Зараз на одному сервері одночасно живуть база даних, бекенд, фронтенд на Node, CI-runner, FTP і роздача картинок — і всі вони ділять одну й ту саму оперативну памʼять. Саме ця конкуренція за памʼять і ставила сервер на межу. Ідея проста: дати кожному завданню свій сфокусований сервіс, де воно нікому не заважає.
Усе в одному ящику
Кожен компонент відкушує памʼять у сусіда. Важкий момент в одного — і страждають усі: база, сайт, API.
Кожному завданню — свій сервіс
База, картинки і фронтенд зʼїжджають із бекенда. Кожен сервіс має власні ресурси й не валить сусідів.
Схема рішення
Три окремі гілки: фронтенд за балансувальником, окремий бекенд із базою, і доставка картинок. Балансування потрібне лише фронтенду — бекенд стоїть окремо.
Як це працює
Розділення означає, що важка роздача зображень більше ніколи не конкурує з логікою застосунку та базою.
Запит сторінки / даних
динаміка застосунку
Користувач відкриває сторінку → Cloudflare (захист, кеш статики).
Load Balancer приймає запит фронтенду й перевіряє його здоровʼя.
Фронтенд (Nuxt SSR) рендерить сторінку на сервері та звертається до бекенда за даними.
Бекенд (окремо, не за балансувальником) виконує логіку на власних 16 GB.
Керована MySQL віддає дані з окремої машини з власною памʼяттю.
Запит картинки
важкі файли — повз бекенд
Браузер просить фото квартири → Cloudflare → CDN.
CDN віддає картинку з найближчої до користувача точки — миттєво.
Якщо файлу ще нема в кеші — CDN бере його раз із Bucket і далі роздає сам.
Бекенд узагалі не бере участі в роздачі — його памʼять і канал вільні для логіки.
Компоненти та запропоновані витрати
Кожен сервіс підібраний під реальний розмір проєкту — без переплати за зайве. Нижче — запропонована щомісячна вартість кожного елемента.
Lightsail · Ubuntu 24.04 LTS
Удвічі більше памʼяті, ніж сьогодні — і вона належить лише застосунку, без бази, картинок і CI поруч. 6 TB трафіку в комплекті дають запас під піки кампанії.
Lightsail · окремий інстанс
Nuxt рендериться на сервері (SSR) наживо. Памʼяті та свопу вистачає, щоб gitlab-runner збирав фронтенд прямо тут, а не на окремому білд-агенті. Фронт відокремлений від API.
Керована MySQL
База зʼїжджає з бекенда — зникає головна причина минулої памʼятевої кризи. AWS сам робить резервні копії й оновлення. База маленька (371 МБ, 77 таблиць), тож 2 GB — з комфортним запасом. Опція: план із резервуванням (High Availability) — $60.
Load Balancer · лише фронтенд
Тримає фронтенд однаковим і стабільним, додає перевірку здоровʼя та SSL. Бекенд за балансувальник не ховаємо — балансування потрібне саме фронтенду.
Object Storage · Bucket
Фото лежать окремо від сервера. Це знімає з бекенда і памʼять, і канал, які зараз витрачаються на роздачу важких файлів.
CDN Distribution
Картинки летять із найближчої точки до користувача, а не з Франкфурта. Швидше для відвідувачів і жодного навантаження на бекенд. Перший рік — безкоштовно.
Ядро · бек + база + картинки
$127 / міс
Бекенд ($84) + керована MySQL ($30) + Bucket ($3) + CDN ($10). Частина, що розвантажує сервер.
Разом · повна конфігурація
$169 / міс
Плюс фронтенд із SSR наживо: окремий інстанс ($24) + Load Balancer ($18) = $42.
Чому це краще за один сервер
Кінець конкуренції за памʼять
База більше не ділить RAM із бекендом, Node і CI. Зникає першопричина памʼятевих збоїв.
База під наглядом AWS
Автоматичні резервні копії, оновлення та (за бажанням) резервування — без ручного тюнінгу my.cnf.
Картинки повз сервер
Важкі файли роздає CDN із Bucket. Бекенд звільняє і памʼять, і мережевий канал.
Фронт і бек — окремо
SSR-фронтенд за балансувальником, бекенд сам по собі. Проблема на одному не кладе інший.
Запас трафіку в комплекті
6 TB на бекенді + окремі ліміти CDN. Передбачувано під піки реклами, без сюрпризів.
Незалежне масштабування
Сайт, API та база ростуть окремо. Проблема в одному більше не кладе решту.
Фронтенд · SSR наживо
Фронтенду потрібен серверний рендер (SSR), тож він працює як живий Node-сервіс на власному інстансі — окремо від API, із балансувальником попереду.
Окремий SSR-інстанс
Nuxt рендериться на сервері
Сайт віддається із серверним рендером наживо. Інстанс — 4 GB RAM + 4 GB swap, окремо від бекенда: проблема на фронті не зачіпає API та базу. Load Balancer попереду тримає фронт однаковим і додає health-checks + SSL.
Збірка прямо на сервері
gitlab-runner будує тут само
gitlab-runner збирає Nuxt на цьому ж інстансі — без окремого білд-агента десь збоку. Своп дає запас памʼяті на важкі моменти збірки, щоб вона не падала. Деплой лишається простим і повністю на нашому боці.
Бекенд, база й картинки від фронтенду не залежать — кожен сервіс масштабується окремо. Балансування додаємо лише фронтенду; бекенд лишається окремо.
План переходу · після кампанії
Нічого не ламаємо наживо. Нова інфраструктура збирається поряд, а перемикання відбувається лише коли все перевірено.
КРОК 1
Збірка поряд
Піднімаємо сервіси Lightsail паралельно, не чіпаючи робочий сервер.
КРОК 2
База
Переносимо MySQL на керовану БД, звіряємо дані та бекапи.
КРОК 3
Картинки
Перекладаємо фото у Bucket і вмикаємо CDN-доставку.
КРОК 4
Фронтенд
Піднімаємо SSR-інстанс, gitlab-runner збирає на ньому, заводимо за Load Balancer.
КРОК 5
Перемикання
Переводимо трафік, спостерігаємо за метриками, тримаємо миттєвий відкат.
Критерій успіху: проєкт працює на розділених сервісах, сервер більше не конкурує сам із собою за памʼять, а картинки й сторінки віддаються швидше — без жодного простою на переході.