"Edge computing in SaaS: how we reduced latency and what went wrong", Ihor Zakutynskyi.pptx

We wanted to make our service lightning-fast for users anywhere in the world. Edge computing looked like the perfect solution. In practice, we achieved lower latency — but also ran into a whole bunch of unexpected problems.

1. CleanerGuru Ігор Закутинський Chief Technology Officer at FORMA by Universe Group Понад 10 років у розробці PhD in Computer Science Великий досвід у побудові високонавантажених систем Викладач у НАУ AWS Certified Solutions Architect

2. Universe Group сьогодні Нам 7 років 3 прибуткових бізнеси та R&D 300 + людей в команді Створюємо продукти для понад 200 млн користувачів зі 18 6 країн світу

3. Наші бізнеси користувачів 200+ млн R&D

4. Agenda 01 Що таке Edge Computing? 02 03 04 5 Edge-провайдери 6 7 8 Бізнес мотивація Наша архітектура “до” Нова архітектура Latency: до і після Архітектурні виклики Що пішло не так?

5. Edge computing - це архітектурна концепція, яка передбачає виконання обчислень ближче до користувача або до пристрою, замість централізованих дата-центрів.

6. Ключові ідеї Локація: обчислення на “краю” мережі, біля джерела даних.

7. Ключові ідеї Локація: обчислення на “краю” мережі, біля джерела даних. Мета : мінімізувати latency та знизити навантаження на core.

8. Ключові ідеї Локація: обчислення на “краю” мережі, біля джерела даних. Мета : мінімізувати latency та знизити навантаження на core. Приклади : CDN, IoT, AI inference біля користувача.

9. Трохи історії 2000-ті : поява Content Delivery Networks (CDN) (Akamai, Limelight) — перші edge-вузли для доставки статичного контенту ближче до користувача.

10. Трохи історії 2000-ті : поява Content Delivery Networks (CDN) (Akamai, Limelight) — перші edge-вузли для доставки статичного контенту ближче до користувача. 2010-ті : Mobile & IoT boom → потреба в обробці даних ближче до сенсорів, щоб зменшити затримки.

11. Трохи історії 2000-ті : поява Content Delivery Networks (CDN) (Akamai, Limelight) — перші edge-вузли для доставки статичного контенту ближче до користувача. 2010-ті : Mobile & IoT boom → потреба в обробці даних ближче до сенсорів, щоб зменшити затримки. 2016 : AWS запускає Lambda@Edge → перший масштабний serverless-edge підхід.

12. Трохи історії 2000-ті : поява Content Delivery Networks (CDN) (Akamai, Limelight) — перші edge-вузли для доставки статичного контенту ближче до користувача. 2010-ті : Mobile & IoT boom → потреба в обробці даних ближче до сенсорів, щоб зменшити затримки. 2016 : AWS запускає Lambda@Edge → перший масштабний serverless-edge підхід. 2017–2020 : Cloudflare Workers, Fastly Compute@Edge — edge стає платформою для логіки, не лише кешу.

13. Чому це важливо?

14. ⏱ 1 секунда затримки на сторінці може призвести до зниження конверсій на 7%: Google

15. ⏱ 1 секунда затримки на сторінці може призвести до зниження конверсій на 7%: Google Amazon оцінює, що 100 мс затримки коштує їм 1% продажів (тобто сотні мільйонів доларів на рік)

16. ⏱ 1 секунда затримки на сторінці може призвести до зниження конверсій на 7%: Google Amazon оцінює, що 100 мс затримки коштує їм 1% продажів (тобто сотні мільйонів доларів на рік) Google : затримка у 500 мс зменшує трафік на 20%

17. ⏱ 1 секунда затримки на сторінці може призвести до зниження конверсій на 7%: Google Amazon оцінює, що 100 мс затримки коштує їм 1% продажів (тобто сотні мільйонів доларів на рік) Google : затримка у 500 мс зменшує трафік на 20% 53% мобільних користувачів залишають сайт, якщо він завантажується довше 3 секунд - Bing

18. ⏱ 1 секунда затримки на сторінці може призвести до зниження конверсій на 7%: Google Amazon оцінює, що 100 мс затримки коштує їм 1% продажів (тобто сотні мільйонів доларів на рік) Google : затримка у 500 мс зменшує трафік на 20% 53% мобільних користувачів залишають сайт, якщо він завантажується довше 3 секунд - Bing Core Web Vitals напряму впливають на SEO та ранжування в Google

19. Типові сценарії Персоналізація контенту - різні відповіді для різних гео/UA/мови. Переписування URL / редіректи - маршрутизація до різних backend або версій. A/B тести та feature flags - швидке розгалуження логіки без зміни core API. Зменшення Latency - виконання логіки ближче до користувача

20. Бізнес мотивація

21. Зменшення latency Користувачі у Європі та Японії отримували затримку 200–600 мс, що негативно впливало на UX і конверсію. Мета - стабільно тримати <100 мс для більшості ринків.

22. Оптимізація інфраструктури Розвантаження core: все, що можна було обробити ближче до користувача, потрібно винести на edge Core залишається для обробки даних, платежів, важких ML-задач

23. Гнучкіші експерименти та маркетинг A/B-тести, персоналізація, локалізація - усе має відпрацьовуватися на edge без зайвого навантаження на бекенд.

24. Оптимізація костів

25. Додатковий рівень безпеки та контролю Попередня перевірка запитів, rate limiting, блокування підозрілих патернів ще до core. Менше вразливостей, менше ризиків DDoS.

26. Edge-провайдери

27. Cloudflare Workers Безсерверні edge-функції, що виконуються у PoP Cloudflare по всьому світу Глобальна мережа - понад 300 точок присутності у 120+ країнах. В будований DDoS protection, WAF, автоматичне масштабування. Зручний деплой через CLI wrangler, простий локальний dev-mode.

28. Інструментарій

29. KV (Key-Value Storage) Просте key–value сховище (типу Redis, але глобально розподілене). Використовується для сесій, конфігів, токенів, feature flags. Дані доступні у всіх PoP Cloudflare з eventual consistency. Приклад: : env.KV.put("user:123", JSON.stringify({ plan: "pro" }))

30. D1 (Cloudflare D1 Database) Реляційна база на SQLite, що працює на edge локаціях. Запити через SQL (SELECT, INSERT, UPDATE). Підходить для маленьких, але структурованих даних: користувачі, логи, конфіги. const { results } = await env.DB.prepare("SELECT * FROM users LIMIT 5").all();

31. R2 (Object Storage) Аналог Amazon S3 Може бути джерелом для CDN або AI pipeline Використовується для зберігання файлів await env.R2.put("report.pdf", req.body)

32. DO (Durable Objects) Примітив для зберігання стану (stateful logic) на edge. Кожен об’єкт - це окремий ізольований процес із власною пам’яттю та логікою. Підходить для чатів, WebSocket-конекшенів, rate limiting. Приклад: room-chat, де кожен DO відповідає за одну кімнату.

33. Wrangler CLI-інструмент для розробки, тестування і деплою Cloudflare Workers та сервісів. Використання: wrangler dev локальний запуск wrangler deploy деплой у глобальну мережу wrangler kv:key put , wrangler d1 execute робота з KV/D1 напряму

34. wrangler deploy

35. Приклад CF Worker

36. AWS Lambda@Edge Інтеграція з CloudFront — виконання коду безпосередньо в точках присутності Amazon. Глобальне охоплення — усі регіони, де є CloudFront PoP. П рацює як на viewer request/response, так і на origin request/response. Д оступ до сервісів AWS (S3, DynamoDB, Secrets Manager) безпосередньо з edge.

37. Як це працює? Пишемо функцію, у якої є доступ до контексту request / response.

38. Як це працює? Пишемо функцію, у якої є доступ до контексту request / response. Прив’язуємо її до CloudFront дистрибутиву.

39. Як це працює? Пишемо функцію, у якої є доступ до контексту request / response. Прив’язуємо її до CloudFront дистрибутиву. Функція виконується на edge-сервері, найближчому до користувача, а не в центральному регіоні AWS.

40. Точки виклику (triggers) Viewer Request — перед обробкою запиту користувача. Origin Request — перед запитом до origin-сервера. Origin Response — після відповіді origin. Viewer Response — перед відправкою відповіді клієнту.

41. CloudFront Function

42. Lambda@Edge Function

43. Інструментарій

44. Основні провайдери Провайдер Географія / PoP Інтеграції Обмеження / Особливості Типові сценарії Cloudflare Workers 300+ PoP у 120+ країнах KV, D1, R2, Durable Obj. Обмежений CPU/пам’ять, eventual consistency Auth, кешування, легкий SSR, A/B AWS Lambda@Edge ~ 400+ PoP AWS (S3, DynamoDB, Secrets Manager), etc Cold start 200–400 ms, складність IAM Auth, URL rewrite, персоналізація Vercel Edge Functions Основні регіони (менше ніж CF/AWS) Інтеграція з Next.js / React Vendor lock-in, без stateful logic SSR/SSG, frontend-heavy SaaS Fly.io ~30 регіонів (VM-based) Stateful VM, volume storage Менше PoP, ручне керування Stateful apps, регіональні API

45. Проведемо експеримент

46. Порівняння продуктивності AWS Lambda Edge , CloudFront Function та Cloudflare Workers

47. Сценарій За допомогою Ddosify Cloud генеруємо вхідний трафік. Було відправлено 10 000 запитів протягом 10 секунд (лінійне зростання до 1 000 RPS). Тестування проводилося окремо для кожної функції (AWS Lambda і Cloudflare Workers). Запити надсилалися з 17 Європейських країн рівномірно розподіленими потоками.

48. AWS Lambda@Edge

49. AWS CloudFront

50. CloudFlare Workers

51. Результати Метрика Cloudflare Workers AWS Lambda Edge AWS CloudFront Function Середній час відповіді (мс) 170 178 153 Максимальний час відповіді (мс) 929 940 1893 Мінімальний час відповіді (мс) 92 103 88 Успішність (HTTP 200) 100% 100% 100%

52. Cold Start P90 Response Time

53. Наша архітектура “до”

54. Що змінилося?

55. Яку логіку ми винесли на Edge рівень? A/B тестування — швидке перемикання варіантів без навантаження на core. Кешування статики — HTML, CSS, JS, зображення, попередній рендер сторінок. Geo-based роутинг — спрямування користувача до найближчого регіонального сервісу. Персоналізація контенту — банери, локалізація за мовою/країною. 01 02 03 04

56. Яку логіку ми винесли на Edge рівень? Безпекові правила — rate limiting, фільтрація шкідливих запитів, WAF-логіка. Переписування заголовків і URL — редіректи, підготовка даних для core API. Авторизація / перевірка токенів — валідація JWT, cookies (in progress) 05 06 07

57. Що ми отримал и ? Зменшення latency : EU/APAC: ↓ до 50–100 мс (було 200–600 мс)

58. Що ми отримали? Зменшення latency : EU/APAC: ↓ до 50–100 мс (було 200–600 мс) Покращили (UX): Менше відмов, підвищили Click to Visitor (+8–10%) Розвантажили основний cloud: До 60% запитів обробляється на edge Core використовується лише для heavy compute та даних

59. Що ми отримали? Зменшення latency : EU/APAC: ↓ до 50–100 мс (було 200–600 мс) Покращили (UX): Менше відмов, підвищили Click to Visitor (+8–10%) Розвантажили основний cloud: До 60% запитів обробляється на edge Core використовується лише для heavy compute та даних Оптимізація витрат: Баланс між вартістю edge і core вигідніший, ніж масштабування тільки core

60. Що ми отримали? Зменшення latency : EU/APAC: ↓ до 50–100 мс (було 200–600 мс) Покращили (UX): Менше відмов, підвищили Click to Visitor (+8–10%) Розвантажили основний cloud: До 60% запитів обробляється на edge Core використовується лише для heavy compute та даних Оптимізація витрат: Баланс між вартістю edge і core вигідніший, ніж масштабування тільки core Додатковий рівень безпеки: Edge-валідація запитів + rate limiting

61. Що пішло не так?

62. Кешування “зайвого” Проблеми: перезаписувалися результати A/B-тестів, конфлікти з ключами сесій. Рішення: винесли критичні дані у persistent storage (D1, DO), TTL для кешу, чіткі ключі.

63. Складний дебаг Проблеми: CloudWatch на наших об’ємах виявився надто дорогим, логів із edge не вистачає Локальний дебаг також ускладнений, через неможливість відтворити production оточення

64. Cold Start на Lambda@Edge +200–400 мс при низьких навантаженнях Рішення : прогрівати функції

65. Висновки

66. Коли edge computing це overhead? Тривалі, ресурсомісткі задачі (GPU, великі моделі). Платіжні системи, PII, фінансові дан і Якщо користувачі нашого сервісу знаходяться в одному регіоні . Якщо архітектура core неоптимальна, винесення логіки на edge не допоможе.

67. Поради і чекліст Визначте чітку бізнес-потребу - виміряйте latency у ключових регіонах. Якщо проблема є - edge може дати приріст. Централізовані логи й метрики з edge - використовуйте tracing ID Автоматизуйте CI/CD 01 02 03 04 Починайте з простого - Auth, кешування, geo-роутинг. Не переносіть одразу всю логіку на edge.

68. Поради і чекліст Врахуйте, що деплой іде в десятки PoP Для edge використовуйте KV/D1/R2/DO з чіткою політикою TTL та consistency. Canary-релізи, швидкі rollback. 05 06 07 08 Чутливу інформацію тримайте в core

69. Посилання на контакти: Дякую за увагу!