"Request Lifecycle at Prom.ua", Vitaliy Kharytonskiy
0 likes•411 views
A detailed journey of a single user request through prom.ua infrastructure including hardware, networks, services, and databases. This talk will feature an explanation of our architecture and reasons behind its current state and external and internal challenges which arise in a high load project built completely on premise.
"Request Lifecycle at Prom.ua", Vitaliy Kharytonskiy
- 1. Prom.ua ВIталIй Харитонський Request Lifecycle у Prom.ua
- 2. План I. Мережі, датацентри, фронтенди II. Гейтвей сервіси III. Всередині кластера IV. Всередині сервіса V. Які проблеми все це вирішує/Що робити далі? N. Інтро
- 3. N
- 4. N
- 5. Чому це може бути цікаво? - досвід це не тільки те що ви зробили, але ще й наслідки того як ви це зробили - це не детальний розбір одного загального компонента, сервіса чи фреймворка, але послідовність кроків для отримання хайлод- мікросервіс-орієнтед-обзервабл-аркітекче в нашому конкретному кейсі - більшість з того про що я буду розповідати це інхауз рішення, тобто ніякого клауда або зовнішніх інтеграцій
- 6. 2008 bare-metal Apache Monolithic Python app 2012 bare-metal nginx Monolithic Python app App wrapper Simple micro-services 2014 bare-metal nginx Monolithic Python app Simple micro-services App wrapper Containers(vagga) t, р. Як розвивалася архітектура Prom.ua
- 7. t, р. 2016 bare-metal nginx Monolithic Python app Simple micro-services Containers(vagga) CI/CI(GitLab) Orchestration(verwalter) 2019 bare-metal nginx envoy/istio Monolithic Python app Complex micro-services Containers(docker) CI/CI(GitLab) Orchestration(k8s) 2021 bare-metal VM(OpenStack) nginx envoy/istio Frontend NodeJS app Backend Python app Complex micro-services Containers(docker) CI/CI(GitLab) Orchestration(k8s) Як розвивалася архітектура Prom.ua
- 8. Які навантаження - 9к rps на всі домени prom.ua і сайтів - 5.6к rps на бекенди(моноліт + сервіси) - 8.3к rps на CDN з зображеннями - ~20 млн. переглядів сторінок за добу - 3 млн. унікальних юзерів на добу - до 6.5 Gb/s вихідного трафіка
- 9. - до 500 нод в кластері k8s - до 140 нод пошукового кластера(ElasticSearch) - до 35 серверів баз даних - до 300 Gb в різних мемкешах, редісах, тощо. - до 110 Тб зображень Який об’єм інфраструктури
- 11. I
- 13. DNS - 53.541 доменів - інтеграція з PowerDNS - власна панель керування доменом - переключення між майданчиками за допомогою API & GUI PowerDNS App Control Plane Ns1/Ns2
- 14. Мережа - автономна система - інтеграція з декількома провайдерами - 6 Gb/s вихідного трафіка Evo FIORD RETN VOLZ Gigatrans Giganet-ix
- 15. Мережа - 3 дц - “пласка” структура мережі - адресація подів без NAT - адресація сервісів в k8s без iptables Evo DC Dc III Dc II Dc I Nginx bare metal App pod k8s IP User device IP
- 16. Вхід в ДЦ - TCP Load Balancer - попадаємо на 1 з 8 фронтендів - nginx - SSL Offload TCP LB nginx nginx TCP TCP HTTP
- 17. SSL - 50k + сертифікатів - інтеграція з LetsEncrypt/ZeroSSL за допомогою мікросервіса - синхронізація нових сертифікатів по rsync - регулярне оновлення всіх доменів - додавання нового SSL сертифіката одним викликом API Lets Encrypt/Zero SSL nginx Evo SSL rsync
- 18. Логіка фронтенду - Lua - auth_request - WebDav - X-Accel-Redirect - Ingress discovery за допомогою интеграції з k8s api nginx Auth Service auth_request Control Plane WebDAV
- 19. Логіка фронтенду - X-Accel-Redirect - Ingress discovery за допомогою интеграції з k8s api nginx k8s operator backend push API Backend X-Accel-Redirect
- 20. Метрики фронтенду - парсинг логів nginx - віддача метрик в Prometheus - метрики по статуса - метрики по юзерагентам - метрики по горячим хостам/ендпоінтам nginx Log Parser Prometheus Metric Agg
- 25. II II
- 26. IPS - рейт ліміти - CAPTCHA-challenge - WAF(частково) - інтеграція з мобільним додатком - чорні списки ботнетів - захист від фейкових ботів - захист зовнішніх доменів nginx IPS Можна? Push Service
- 28. Susanin - роутінг - розділення трафіка - редіректи трафіка між датацентрами - CORS Offloading nginx Susanin Куди? App domains
- 30. Concierge - аутентифікація - single-sign-on - user data storage nginx Concierge Хто? App users
- 31. Concierge App(Python) auth inside App(Golang) auth outside prom.ua/track Nginx Concierge auth auth Users cookie cookie
- 32. III
- 33. Envoy/Istio - роутінг між мікросервісами - дебаг режим - canary режим - розділення на приватне/публічне апі - метрики latency - grpc load-balancing Envoy Istio Pilot(k8s operator) VirtualService/ Gateway
- 34. Envoy Catalog Site Admin Bots Debug Canary Nginx Susanin headers Shopping Cart Tracking
- 37. IV
- 38. SSR - server-side rendering - static resources preload - apollo/graphql api - html-streaming(in-progress) - route bypass SSR(nodejs) App(python) Susanin+nginx+envoy App(python)
- 41. GraphQL API - single backend to rule them all - доступ до вкладених сутностей - multi-threaded - синхронна обробка запиту - асинхронні запити до зовнішніх ресурсів Mobile Desktop Internal Shopping cart GraphQL API
- 42. VI
- 43. Які проблеми вирішує така архітектура - резервування мережі за допомогою незалежної ASN - гнучкість http-load balancer + lua - прозорість метрик фронтендів, гнучка передача даних з бекенда в лог - повна автоматизація випуску сертифікатів і керування DNS - обмежений захист від DDOS для необмеженої кількості трафіку/доменів - гнучка логіка роутінгу з можливістю додавати будь які фічі в т.ч. з даними з бази - загальний service-middleware для аутентифікації, zero-cost авторизація - ізоляція різних частин моноліта для мінімізації впливу помилок різних частей - розділення бекенда і фронтенда на різні deploy unit
- 44. Що можна було б покращити? - перейти на асинхроні бібліотеки для всіх зовнішнів запитів - перейти на більш простий і надійний Nginx Ingress Controller - отримувати трейсинг логів з урахуваннням ingress - розбити моноліт на різні функціональні частини замість штучного розділення трафіка - отримувати більше ріалтайм телеметрії з основного бекенда(профайлінг, трейсінг) - інтегруватися з трейсінгом і APM Sentry - додати API Gateway для GraphQL