Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Анатомия баннерной системы Lamoda

Анатомия баннерной системы Lamoda

Лев Тонких (Lamoda) @ MoscowPython Meetup 46

"В докладе рассмотрим баннерную систему, разработанную в Lamoda.

Поговорим о функционале этой системы, из каких частей она состоит, расскажем о планах, и узнаем, с какими трудностями пришлось столкнуться на пути в прод".

Видео: http://www.moscowpython.ru/meetup/46/anatomija-bannernoj-sistemy-lamoda/

Moscow Python Meetup

June 21, 2017
Tweet

More Decks by Moscow Python Meetup

Other Decks in Programming

Transcript

  1. Родовые травмы • Началось с Werkzeug, Flask.. • Кончилось велосипедами

    • Тяжело поддерживать • 150 ms, 60% timeouts • deploy скриптами
  2. – Dmitriy Zhiltsov, System Architect “Баннерка должна отвечать за 3

    ms!” Lamoda Tech Профилирование приложений Python в реальном времени
  3. правила таргетинга CRUD UI Публикация статика СУБК Storage баннерный сервер

    баннерный сервер баннерный сервер баннерный сервер Баннерный сервер Статистика Запрос Упрощенная схема
  4. Система управления баннерными кампаниями • Создание кампаний • Создание баннеров

    • Создание таргетинга • Выбор площадок (слотов) • Просмотр отчетов • Публикация в бс UI
  5. • Креативы надо где-то хранить • База для этого не

    сильно подходит (аварийная ситуация) • Nginx лучше подходит для кэширования и раздачи статики • Docker..
  6. Где размещать • Трафик • Обновление • Дисковое пространство FS

    баннерного сервера Webdav, s3, … • Меньше данных на каждом из серверов • Одно монолитное хранилище • Легко масштабировать
  7. • БС занимается показом баннеров — находит оптимальный баннер под

    заданные условия • targeting.json — правила таргетинга • 1 per time Публикация на webdav
  8. Баннерный сервер • простота (2 + 2) • слабая связаность

    • масштабируемость • отказоустойчивость Mission critical component old version (Werkzeug) — 150 ms. new — 10 ms
  9. Pull • Сразу видно, если что- то пошло не так

    • удобно обновлять все сервера • cron • по-событию • доступ к webdav Push • если есть лимиты - оповещать, чтобы не было перекруток • регистрация всех серверов = +1 точка отказа • health checks • 1 • 2
  10. targeting.json — M MB Инстансов баннерного сервера — G шт

    Публикация новых правил в день — O раз Передадим MB данных Если То
  11. O * M * G * N N — кол-во

    датацетров +
  12. Full • Обновление всего содержимого • Большой объем данных Diff

    • Δ с последнего обновления • сложно реализовать • малый объем передачи данных
  13. Как сделали мы • Большая вложенная структура • Отправляем изменившиеся

    сущности Изменилось название баннера — отправляем весь объект баннера + easy debug
  14. Как работает req front req` http headers: gender age country

    …18+ bs html(banners), redirects resp webdav creatives targeting rules … * very lite version stats готовая информация 10 ms no cache
  15. Что происходит в BS • pull правил • f =

    lambda x: eval(exprs) -> True | False • {‘key’: [f1, f2, f3, …]} • x — request obj • O(n) релевантный баннер
  16. 21m banners view per day 40m requests 300k clicks 150

    ms, 60% timeouts 10 ms, 0.04% timeouts
  17. Как работает req front req` http headers: gender age country

    …18+ bs html(banners), redirects resp webdav creatives targeting rules … * very lite version stats готовая информация 10 ms no cache
  18. Что происходит в BS • pull правил • f =

    lambda x: eval(exprs) -> True | False • {‘key’: [f1, f2, f3, …]} • x — request obj • O(n) релевантный баннер
  19. 21m banners view per day 40m requests 300k clicks 150

    ms, 60% timeouts 10 ms, 0.04% timeouts