Stas Kozosvyst: Чому ми відмовилися від VPS у двох дата-центрах на користь Cloudflare Workers, D1 та R2 — утричі дешевше та в 5 разів швидше
Мене звати Stas Kozosvyst, і коли ми будували бекенд для платформи Avmira, першим технічним рішенням була перевірена роками класика. Ми орендували віртуальні сервери (VPS), налаштували Nginx, підняли базу даних і рознесли інстанси по двох дата-центрах у різних регіонах. Головна мета полягала в тому, щоб збалансувати глобальний трафік між континентами та забезпечити стабільний аптайм: якщо падає один дата-центр, другий бере навантаження на себе.
Але коли проєкт почав зростати й з'явилися користувачі з різних куточків світу, ми вперлися у фундаментальні мінуси такого підходу. Ми зіткнулися з двома речами, які неможливо обійти на класичному залізі: відчутними мережевими затримками через фізичну відстань до серверів і постійними переплатами за ресурси, які простоювали більшу частину доби.
Зрештою ми повністю відмовилися від виділених віртуалок і перенесли всю логіку на serverless-інструменти Cloudflare: Workers, розподілену SQL-базу D1 та об'єктне сховище R2.
За нашими контрольними замірами середня затримка зменшилася приблизно у 5 разів, а підсумковий чек за серверні ресурси впав орієнтовно втричі. Розповідаю технічну сторону цього переходу: що конкретно було не так із двома дата-центрами, як влаштований наш нинішній стек і які цифри ми отримали в результаті.
Чому балансування між двома дата-центрами виявилося поганим рішенням
Ідея геобалансування через два дата-центри на папері виглядає логічно: запит спрямовується до найближчого сервера, завдяки чому користувач має отримувати швидкий відгук. У реальності цей сетап приніс купу проблем:
Підписуйтеся на наші соцмережі
-
1
Два дата-центри не дають рівномірної швидкості по світу. Наші машини стояли у Франції та США. Якщо для жителів Західної Європи чи східного узбережжя Штатів відгук ще був адекватним, то для відвідувачів з Азії, Латинської Америки, Австралії чи навіть Східної Європи затримка легко вилітала за 150–250 мс. Кожен окремий запит до API, кожне встановлення TLS-з'єднання та вибірка даних змушували пакети летіти через пів планети. Побудувати справжній low-latency для всього світу на двох точках фізично нереально.
-
2
Постійна переплата за надлишкове залізо. Трафік ніколи не буває рівномірним: уночі споживання мінімальне, у години пік воно різко зростає. Щоб сайт не ліг під час сплесків, машини в обох дата-центрах доводилося брати з суттєвим запасом за обсягом RAM і ядрами CPU. У підсумку 70–80% часу ми платили за ресурси, які просто «гріли повітря», тому що тарифікація на класичних VPS фіксована й нараховується щомісяця незалежно від реальної активності на сайті.
-
3
Операційний оверхед і адміністрування. Два окремих сервери потребують постійного ручного нагляду. Потрібно власноруч налаштовувати GeoDNS і правила перенаправлення, тримати механізми перевірки доступності (health checks), розв'язувати конфлікти реплікації бази між континентами, накатувати оновлення безпеки на Linux і розгрібати логи. Замість написання коду продукту ми витрачали купу годин на роль сисадмінів.
Нова архітектура: Cloudflare Workers + D1 + R2
Ми вирішили не намагатися будувати власну розподілену мережу з десятків дрібних VPS, а повністю віддати задачу маршрутизації та обчислень платформі Cloudflare, розподіливши систему на три ключові компоненти:
- Cloudflare Workers (Compute): Логіка бекенду більше не прив'язана до конкретного міста чи країни. Код виконується на найближчих до користувача нодах global anycast-мережі. На відміну від контейнерів Docker, які можуть довго виходити зі сплячого режиму, тут використовується технологія V8 isolates. Вона запускає ізольований контекст за частки мілісекунди, повністю прибираючи проблему відчутного «холодного старту».
- Cloudflare D1 (Database): Це serverless SQL-база на SQLite, інтегрована з Workers. Вона дозволяє працювати з SQL-даними без підтримки окремого database-сервера та добре вписується в архітектуру Workers.
- Cloudflare R2 (Storage): Зберігання зображень, медіа та статичних ресурсів. Головний економічний фактор вибору R2 замість AWS S3 чи локального сховища VPS — відсутність плати за вихідний трафік (Zero Egress Fees). Коли платформа активно віддає картинки й файли аудиторії по всьому світу, рахунки за трафік в інших хмарах швидко з'їдають значну частку бюджету. R2 зняв це питання повністю.
Результати внутрішніх тестів і замірів
Після повної міграції та перенесення логіки на новий стек ми провели серію вимірювань затримки за допомогою синтетичних запитів із різних локацій і зафіксували такі зміни:
- Мережева затримка (TTFB) по світу: на старому сетапі з двома VPS вона коливалася в межах 120–190 мс зі спайками до 250+ мс на далеких маршрутах. Після переходу на Workers та D1 показник стабілізувався на рівні 20–35 мс — фактично затримка зменшилася приблизно у 5 разів.
- Щомісячний чек за інфраструктуру: замість фіксованої орендної плати за надлишкові гігабайти пам'яті, ядра та дисковий простір у двох дата-центрах ми перейшли на оплату виключно за фактично спожиті операції. Рахунок скоротився десь до 30–35% від початкової суми — чиста економія втричі.
- Час на адміністрування операційної системи: раніше на патчі, моніторинг ресурсів, оновлення пакетів і виправлення конфігів ішло від 4 до 6 годин на тиждень. У serverless-моделі базове середовище виконання не потребує від команди окремого адміністрування операційної системи.
За рахунок того, що запит від користувача спочатку потрапляє в мережу Cloudflare, а серверна логіка виконується через Workers, нам вдалося суттєво скоротити мережеву затримку на шляху до бекенду.
Практичний висновок
Для стартапів на ранніх етапах спроба збудувати всесвітнє покриття на базі кількох орендованих VPS у дата-центрах часто стає пасткою: ви платите за ресурси, які не використовуєте, і водночас не можете дати користувачам стабільно низьку затримку на рівні всієї земної кулі.
Перехід на зв'язку Workers + D1 + R2 дозволяє команді будь-якого розміру отримати глобальну інфраструктуру «з коробки», прибрати рутинне адміністрування серверної операційки та скоротити витрати без шкоди для показників затримки.
* Наведені цифри витрат і затримок базуються на внутрішніх тестах і замірах нашого проєкту під час міграції конкретної архітектури. На інших технологічних стеках, типах навантаження, співвідношенні читання/запису в базу даних та сценаріях використання результати, витрати й затримка можуть відрізнятися.