Илья Шевела – Ozon Fresh и модель собственных продаж изнутри

Transcript

1. Ozon Tech Intro Meetup 2023 Ozon Fresh и модель собственных продаж изнутри Руководитель департамента по продукту и технологиям собственных продаж и Фреш Шевела Илья
2. О чем мы сегодня будем говорить 2 • Что такое Ozon Fresh и Ozon Retail • Ozon Fresh: про короткие слоты и как мы доставляем быстро (проект «Автомаршрутизация курьерской доставки») • Ozon Retail: про распиливание большого монолита и превращение его в микросервисы
3. 3 Ozon Retail и Ozon Fresh — cервис заказа продуктов питания и товаров для дома с гибким временем доставки со складов и дарксторов
4. 4 1P — 80% 3P — 20% Модель 1P (First-Party) означает, что Ozon выступаетв качестве розничного продавца, а вы выступаете в качестве оптового поставщика для компании Ozon Модель 3P (Third-Party) означает что вы являетесь розничным продавцом и продаете товары напрямую потребителям через торговую площадку Ozon 1P — 100% Ozon Fresh Ozon Retail
5. 5 Электроника Home Care&Kids CTM (Ozon Fresh) FMCG Food FMCG non-food Health&Beauty Аптека Хлебобулочные изделия Cotton&Paper Фрукты и Овощи Ozon Fresh & Ozon Retail
6. Что заказывают чаще всего: Быстрая доставка 6 Огурцы Бананы Молоко Туалетная бумага Памперсы Кофе (в течение часа/от 1 часа)
7. Цифры Fresh 200 Микросервисов Go, .Net, 1C, Kotlin, Swift, Delphi, JS/TS Vue PostgreSQL, M$SQL, Kafka, Memcached, Redis Vertica, ClickHouse, Hadoop 210 Микросервисов Retail .Net, Go, JS/TS Vue PostgreSQL, Kafka, Redis Vertica, ClickHouse, Hadoop
8. Ozon Fresh: про короткие слоты и как мы доставляем быстро (проект «Автомаршрутизация курьерской доставки») 8
9. Короткие слоты 9
10. Горизонт планирования и слоты доставки Слот доставки — совокупность временных интервалов, описывающих нормативы операционного процесса доставки • Regular — будущее туманно, но предсказуемо • Express (on demand, доставка в течении часа) — сильное возмущение в силе Принимаем заказы с витрины Закрываем слот(cut_in) Собираем заказ Передаем курьеру(cut_off) 
 В дороге до клиента Окно доставки 10:10 10:20 10:30 10:40 10:50 11:00 10:00 Принимаем заказы с витрины Закрываем слот(cut_in) Собираем заказ Передаем курьеру(cut_off) 
 В дороге до клиента Окно доставки t Regular + Express у одно курьера = Profit
11. 11 Вычислительная сложность задачи зависит от размера входных данных экспоненциально VRP — это NP-трудная задача, со множеством ограничений. Задачи маршрутизации транспорта Задачи комбинаторной оптимизации, в которых для парка транспортных средств, расположенных в одном или нескольких депо, должен быть определен набор маршрутов до нескольких отдаленных точек-потребителей Vehicle Routing Problems, VRP
12. 12 Ограничения SLA склада Учесть время на сборку заказа ОВХ заказов Учесть размеры заказов, грузоподъемность и объем машины Окно доставки клиенту Надо успеть вовремя Пробочная ситуация Учесть пробки на маршруте Ресурс курьеров Учесть количество свободных курьеров 01 02 03 04 05
13. Защитные Что хотим получить Найти приближенное решение, которое удовлетворит критериям качества. Решение — это всегда баланс качественных оценок Defect rate DR — совокупная метрика, куда включаются все дефекты сервиса. Например: опоздание к клиенту Дисперсия заработка курьера Большая дисперсия снижает мотивацию курьеров, увеличивает текучку и наши расходы на поиск новых Утилизация курьера Утилизация показывает, насколько оптимально мы используем наших курьеров Cost per order CPO – метрика стоимости доставки заказа. Строя оптимальные маршруты, мы сокращаем пробег и увеличиваем доступность курьеров Профит
14. Как мы это делаем? Задачи VRP лежат на пересечении двух хорошо изученных задач: 14 • Множественная задача коммивояжера (Multiple Traveling Salesman Problem, MTSP) • Задача об упаковке рюкзака (Bin Packing Problem, BPP)
15. Анализ географии и кластеризация 01. Простой способ локализовать курьера и избавиться от дорогих ребер 15
16. 16 01. Анализ географии и кластеризация На карте нет МЛ с одним постингом
17. Поиск решения с помощью алгоритмов из OR-tools 02. 17
18. Эвристики для оценки решения 03. Имплементируем опыт наших логистов и курьеров в наших сервисах 18 • Пиковые нагрузки • Ресурсный буфер • Заказы по требованию • Сохранение мотивации курьера • et cetĕra
19. Автомаршрутизация для нас — это: 19 • Оптимизация логистических расходов • Масштабирование сервиса • Удовлетворение растущих потребностей наших клиентов и повышение качества сервиса
20. Ozon Retail: Про распиливание большого монолита и превращение его в микросервисы 20
21. Монолит в микросервисы User Interface Business Logic Data Access Layer Microservice UI Microservice Microservice Microservice Microservice DB DB DB DB Monolithic Architecture Microservice Architecture
22. Монолит Плюсы: 22 • Простое развертывание • Приложение легче разрабатывать • Производительность • Упрощенное тестирование • Удобная отладка • Снижение скорости разработки • Масштабируемость • Надежность • Препятствия для внедрения технологий • Недостаточная гибкость. • Развертывание Минусы:
23. Микросервисы Плюсы: 23 • Гибкое масштабирование • Непрерывное развертывание • Легкость обслуживания и тестирования • Независимое развертывание • Гибкость технологий • Удобство отладки за счет технологий трассировки и поиска неисправностей • Разрастание процесса разработки. Если разрастание не контролируется должным образом, оно приводит к замедлению разработки и снижению операционной эффективности или к созданию архитектуры Big ball of mud • Экспоненциальный рост расходов на инфраструктуру • Дополнительные организационные расходы • Отсутствие стандартизации • Отсутствие ясности в вопросах владения Минусы:
24. Кто вы, мистер GoodZon Техническая сторона M$ SQL + Delphi 7 Вся логика в БД ~1000 хранимок Сотни таблиц 10+ ТБ данных
25. Кто вы, мистер GoodZon С точки зрения бизнеса 1. Система управления закупками и поставками 2. Ни один товар не попадет на склады Ozon без этой системы 3. Расчет потребности в закупках. Сколько какого товара и на какой склад нужно привести 4. Управление заказами поставщикам. Согласование закупок внутри Ozon и с поставщиками 5. Атрибуты товаров и поставщиков, необходимые для закупок 6. Десятки других функций, потому что «так исторически сложилось»
26. А может не надо? Работает и ладно 1. Устаревший стек. Сложно найти разработчиков 2. Возможность вертикального масштабирования практически исчерпана 3. В Расчет потребности (после DS) занимал ежедневно 4 часа. А днем вообще не проходил, из-за наплыва пользователей. И это только один пример
27. 1. Отсутствие экспертизы. В команде был только 1 разработчик, участвовавший в создании монолита (создали в 2016 году отпочкованием от еще одного монолита) Дополнительные трудности 2. Вся логика в хранимках. Код не получится переиспользовать 3. Система устарела морально. Требовалась не только техническая переработка, но и переосмысление бизнес-процессов 4. Поезд нужно пересобирать на полном ходу 27
28. 1. Провели аналитику. Сформулировали скоуп и осознали масштаб работ Взялись за дело! 2. Выделили 10+ этапов. Каждый – проект на несколько месяцев 3. Выявили зависимости и приоритеты для бизнеса 4. Составили роадмап План – всему голова! Но все это только на втором году распила 😀 А в начале – тушили пожары и лечили там, где болело сильнее всего 28
29. Монолит в микросервисы • Определиение границы данных • Осторожный рефакторинг исходного приложения, чтобы абстрагировать «микросервис» в свой собственный класс/API, который вызывает остальная часть кода • Использование Kafka в качестве шины событий для асинхронного межсервисного взаимодействия. Этот архитектурный стиль очень хорошо сочетается с потребностями связи микросервисов, когда один сервис может транслировать данные для использования любым количеством потребителей. Переход от SQL Service Broker к Kafka • Использование преимуществ gRPC • Уход от хранимых процедур, для возможности масштабирования и переиспользования кода
30. Монолит в микросервисы • Для гарантий доставки использование патерна outbox (уход от cdc) для гарантированности и консистентности доставки событий/данных • Рефакторинг монолитна — все операции чтения и записи данных в одном домене с четкими границами • Запись данных в исходную базу данных и их отправка в новый сервис (дублирование потоков). При этом исходная база данных остается источником истины для чтения пользовательских данных • Чтение в монолите из нового сервиса с регистрацией любых несоответствий данных, чтобы устранить любые возникающие ошибки. Обратная запись идет в монолит для синхронизации • Перенос бизнес логики с ее рефакторингом в части событийных моделей, статусных моделей
31. Что в итоге: 31 Долго, дорого, качественно 70+ сервисов .NET, Postgres, Kafka, Vue Система легко масштабируется под ежегодно x2 растущие объемы Тот самый финальный расчет потребности занимает < 20 мин.
32. 1. Желания Бизнеса – закон. Но нужно уметь приоритизировать Выводы 2. Без плана и аналитики далеко не уедешь. Но иногда – это форма прокрастинации, а надо просто брать и делать 3. Результат превыше всего 32
33. Наши вакансии 33 Go разработчик, Фреш, отдел автоматизации коммерции и товародвижения Android разработчик, Департамент разработки Фреш
34. ishevela@ozon.ru Спасибо за внимание Шевела Илья, руководитель департамента по продукту и технологиям собственных продаж и Фреш