Михаил Кабищев — Эволюция платформы Ozon

Transcript

1. Ozon Tech 2022 Эволюция платформы Ozon Михаил Кабищев, Head of сore platform
2. Ozon образца 2018 2 < 100 человек в IT Всем известный «онлайн-магазин книжек» Все на Windows • бэкенд на .NET • огромные монолиты MSSQL • десктопные приложения на Delphi • прочие прелести жизни…
3. Ozon образца 2022 3 4K человек Один из лидеров e-com’a в России ~ 3500 сервисов 3 дата-центра 5кк RPS-нагрузка на наши сервисы
4. 4 • Платформа • Конвенции и стандарты • Создание сервиса • Деплой • Service mesh • Observability • Managed services О чем мы сегодня поговорим
5. Платформа 5
6. 6 1. Продуктовые команды должны решать продуктовые задачи 2. Максимальная абстракция и унификация инфраструктуры 3. Решение самых популярных кейсов 4. Стандартизация 5. Change management 6. Снижение time-to-market Зачем нужна платформа?
7. Структура платформы 7 Платформа Microservices Application Services Compute Hardware & Network
8. Платформа — технологический фундамент 8
9. Конвенции и стандарты 9
10. Лучше безобразно, но однообразно 10 © Цитаты великих людей
11. 11 1. Именование 2. Версионирование 3. Конфигурация 4. Протоколы 5. Observability Конвенция по микросервисам Наша конституция
12. 12 1. Версии языка, компилятора и т.д. 2. Ограничение версий библиотек и модулей 3. Codestyle 4. Best practices Конвенция по языкам и технологиям
13. Создание сервиса 13
14. Языки 14 C#
15. 15 • Структура проекта • Платформенные файлы (k8s, gitlab-ci) • Методы-заглушки • RPC: gRPC, gRPC-Gateway, Swagger • Rate-limit, circuit-breaker, … • Онлайн-конфигурация • Телеметрия на все случаи жизни Генераторы сервисов
16. 16 Конфигурация manifest config-uploader ETCD Vault service
17. 17 • Где хранить контракты? • Кто и как их должен генерировать? Клиенты к другим сервисам
18. Тут все было очень печально… 18
19. 19 • Не было никаких правил по написанию proto • Кто-то генерировал клиенты сам и раздавал как зависимости • Кто-то копировал proto из чужих репозиториев к себе • Не работал gRPC-reflection Генерация клиентов
20. 20 2020: Protogen Первый шаг к стандартизации Правила хранения и написания proto-файлов Резолвинг зависимостей Генерации на стороне сервиса клиента cli-утилита
21. 21 2022: Mimir Серверная эволюция protogen’a Отправляешь в него proto + необходимые зависимости Получаешь архив с каталогом proto Генерация происходит локально
22. Сборка и деплой 22
23. Сборка проекта 23
24. Деплой 24
25. Как сделать жизнь разработчиков проще? 25 Общий флоу разработки в Ozon.
26. Service Mesh 26
27. 27 2018: Linkerd ingress linkerd service 1 service 2 linkerd service 3
28. 28 2018: Linkerd Крутили Вертели Получали большие задержки И...
29. 29 А мы – нет!
30. 30 2019: Ingress ingress service 1 service 2 service 3 ingress ingress
31. 31 • Задержки есть, но они нас устраивают • Ничего дополнительного делать не надо 2018: Ingress
32. Но ингресс ведь не для этого 32 © Команда куберменов
33. 33 2020: Warden ingress service 1 service 2 service 3 warden K8s api
34. 34 • Ингресс используется как ингресс • Нет дополнительных задержек • Нету сайдкаров, все реализовано в виде библиотеки 2020: Warden
35. 35 • Единый discovery для всего Warden • сервисы • Postgres • Redis/Memcached • Kafka • Разные алгоритмы балансировки • WRR • P2C • Канареечные деплои • Тестирование новых версий • Локализация трафика • Subsetting
36. 36 Канареечные деплои service 1 service 2 ver A service 2 ver B warden 10% 90%
37. 37 Тестирование новой версии service 1 service 2 ver A service 2 ver B service 3 x-o3-meshversion: service2=B
38. 38 Тестирование новой версии service 1 service 2 ver A service 2 ver B service 3 x-o3-meshversion: service2=B,service4=D service 4 ver C service 4 ver D
39. 39 Subsetting service 1 service 2 service 2 service 2 service 2 service 2 service 2 service 2 service 2 service 2 service 1 service 1
40. Observability 40
41. 41 • Метрики • Трейсинг • Логи • Continuous profiling Observability
42. 42 Метрики Системные метрики RPC-слой Внешние зависимости Рантайм Общие дашборды Огромное количество базовых алертов
43. 43 Service overview
44. 44 Service overview
45. 45 Service overview
46. 46 By handler
47. 47 By zone
48. 48 gRPC
49. 49 Go runtime
50. 50 Resources
51. 51 Resources
52. 52 Запросы к другим сервисам
53. 53 Запросы к конкретному сервису
54. 54 Базовые алерты • Десятки базовых алертов • состояние контейнеров • системные метрики • RPC • базы • … • Нужно только настроить пороговые значения
55. 55 Трейсинг • 2018: Начинали с ванильного jaeger’a • 2019: Переписали бэкенд по свои нужды • 2020: Перешли на opentelemetry Что умеем: • Хранить все трейсы за 10-15 минут • Делать умное семплирование • Считать критический путь и много другой информации https://www.youtube.com/watch?v=GlHLuoVHFpE
56. 56 Трейсинг
57. 57 Критический путь Определение: спан A находится на критическом пути в момент времени t тогда и только тогда, когда уменьшение его длины в момент времени t уменьшит общее время запроса.
58. 58 Трейсинг
59. 59 Continuous profiling Регулярно собираем профили с приложением Умеем делать поиск и агрегации Поддерживаем Go, Java и .NET
60. 60 Continuous profiling
61. 61 Ждите в opensource
62. Managed Services 62
63. Инфра все делает очень долго… 63 © Из разговоров в коридорах продуктовой разработки
64. Давайте сделаем все по кнопке! 64 © Из разговоров в коридорах платформы
65. 65 • Для разработки Что-то-as-a-Service • уменьшение времени реагирования • уменьшение влияния человеческого фактора • мониторинг, алерты • контроль доступа • Для платформы • стандартизация использования • разработка «от железа до библиотеки»
66. 66 Что-то-as-a-Service
67. 67 • Redis • Memcached • Kafka • PostgreSQL • S3 Какие ресурсы у нас уже есть?
68. 68 Добавление ресурса
69. 69 • Каждый ресурс принадлежит сервису • Каждый сервис принадлежит команде • У каждой команды есть квоты • Есть бюджет и планирование • Разработчики запускают/удаляют/ресурсы без нашей помощи Managed services
70. 70 • Платформа — фундамент для всей разработки • Разработка — главный клиент • Стандартизация и унификация — наше все • Не можешь победить — возглавь Заключение
71. mkabishchev@ozon.ru Спасибо за внимание Михаил Кабищев, Head of сore platform