1. Как показывать 200 миллионов
баннеров ежедневно и быть
готовым показать миллиард.
Евгений Коковихин, руководитель отдела разработки Wapstart.
Разработчик баннерной сети http://plus1.wapstart.ru/.

2. О компании WapStart
WapStart – владелец крупнейшей в России мобильной рекламной сети
Plus1 WapStart и наиболее полного и популярного в России каталога
мобильных сайтов Top WapStart.
Компания оказывает услуги тысячам издателей мобильных сайтов и
приложений. Ежемесячная рекламная емкость WapStart – свыше 4,2
млрд. показов, число уникальных посетителей – более 25 миллионов.
Компания WapStart владеет передовыми
технологиями таргетинга и анализа аудитории,
позволяющими проводить рекламные кампании
в мобильной среде с высокой рентабельностью
инвестиций.

3. Marketing is so marketing

4. 0
500
1000
1500
2000
2500
3000
3500
4000
4500
Millions

5. Задача
• Будьте готовы показать миллиард. //это примерно 13-15K rps.

6. Год назад у нас было так
front1
farm1 farm2 farm3 farm4 … farmN
front2
Master-db
Slave-db
Cache 1 Cache 2 Cache 3

7. Идеи
• Все должно быть локально.

8. Идеи
• Пользователь должен всегда попадать на один и тот же бекенд
(так как у нас все локально).

9. Идеи
• Ротатор (баннерная крутилка / php-fpm) не должен ходить в
базу.

10. Идеи
• Нужна какая-то умная штука для синхронизации.

11. Реализация.

12. Задача: сделать так
front1
farm1
cache1
farm2
cache2
farm3
cache3
farm4
cache4
…
…
farmN
cacheN
front2
Master-db
Slave-db
queue
filler

13. Реализация:
• Для nginx есть модуль persistent upstream
https://github.com/replay/ngx_http_consistent_hash
• Мы его доработали
https://github.com/WapStart/ngx_http_consistent_hash
Пользователи должны попадать в один и тот же
upstream
include /usr/local/etc/nginx/fastcgi_params;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param CONSISTENT_HASH $consistentHash;
fastcgi_param GEOIP_COUNTRY_CODE $geoip_country_code;
fastcgi_pass consistent-upstream;

14. Реализация:
• Выпиливаем из конфигов подключение к СУБД и отлаживаем.
Безбазье

15. Реализация:
• Все апстримы ходят исключительно в локальный кеш.
• Делаем центр, из которого будут наполняться кеши на разных
серверах.
• Интерфейс неизменный. При этом читаем всегда из локального
кеша, а пишем во все.
• Пишем только из центра.
Преднаполняторы кеша

16. Реализация:
Клики

17. Реализация:
Клики; теория перекрутов
• Показы продолжались после окончания лимитов.
• Пользователь что-то изменил, но это подействовало не сразу.
• Показали до окончания лимитов, но кликнули после.

18. Реализация:
Клики; теория перекрутов
• Среднюю величину перекрутов любого рода можно предсказать.
• Время реакции тоже предсказуемо.
//Осталось лишь согласовать с бизнесом )

19. Реализация:
Клики; обработка в фоне
• Было: Event -> database.
• Стало: Event -> file queue -> logAnalyzer -> database.
• Цепочка стала более длинной, время реакции увеличилось.
Решение:
• Предсказываем события.

20. Масштабирование на уровне дата-центров

21. Задача. Сделать так:
Центр
Primary
DNS
СУБД
Синхрони-
затор
Управлятор
трафиком
Монито-
ринг
Internet
Дата-
центр 1
Дата-
центр 2
Дата-
центр 3
Дата-
центр 4

22. В пределах дата-центра
front1
farm1
cache1
farm2
cache2
farm3
cache3
…
…
farmN
cacheN
центр
VPNСинхрони-
затор

23. Масштабирование на уровне дата-центров
Можно выбрать дорогой дата-центр, а можно быть
готовым к его падению
• Пишем LowCost, подразумеваем Hetzner.
• На один рубль обрабатываем в три раза больше трафика!
• Не забывайте про VAT (еще дешевле).
• Пока стандартная конфигурация вас устраивает – все очень
дешево.

24. Масштабирование на уровне дата-центров
Hetzner: проблемы и ограничения

25. Масштабирование на уровне дата-центров
• Не более 6 серверов в «кластере».
• Техподдержка не на вашей стороне.
• Иногда теряются пакеты.
• Иногда «утекает» база паролей и кредиток :)
• Возникают спонтанные проблемы с сетью.
• Не совсем «серверное» железо.
Решение
• Приложение должно быть готовым к кратковременному
отсутствию связи.
• Если упадет «датацентр» целиком, мы должны продолжить
работу.
Hetzner: проблемы и ограничения

26. Масштабирование на уровне дата-центров.
Мониторинг.

27. Масштабирование на уровне дата-центров
Мониторинг
• Трафик/логи.

28. Масштабирование на уровне дата-центров
Мониторинг
• CPU load.

29. Масштабирование на уровне дата-центров
Мониторинг должен быть распределенным
• Что будет, если упадет сервер с мониторингом?
• Каждый «узел» должен наблюдаться как минимум из двух мест.
• Особо критичные триггеры должны отправляться по смс.

30. Масштабирование на уровне дата-центров
Как делить трафик?

31. Масштабирование на уровне дата-центров
Как делить трафик: DNS
• Измеряем трафик по подсетям или странам.
• Создаем view в bind (google://named views).
• Ждем.
Ограничения
• Иногда dns сервер клиента находится за пределами его сети.
• DNS рассасывается не моментально.
• Порции трафика выделяются по подсетям => иногда они
слишком большие, а иногда – маленькие.

32. Масштабирование на уровне дата-центров
Как делить трафик: http permanent rewrites
• Находим какой-нибудь критерий деления (площадка, user-
agent, etc).
• В nginx rewrite … permanent.
• Изменения вступают в силу сразу.
Ограничения
• Применимо только client-to-server подключений.
• Лишняя нагрузка на фронт-«делитель».
• Повышенное время ответа клиенту.

33. Масштабирование на уровне дата-центров
Как делить трафик: поддомены для крупных
партнеров
• Для крупных server-to-server партнеров можно завести
отдельный субдомен partnerName.ro.plus1.wapstart.ru и
заставить гнать траффик на него.
• Изменяем dns и ждем.
Ограничения
• Применимо только для крупных партнеров.
• Время реакции DNS.

34. Масштабирование на уровне дата-центров
Оставшиеся проблемы
VS

35. Масштабирование на уровне дата-центров
Очереди
• Списки баннеров доставляются шарманкой, но «срочные
изменения» мы пока доставлять не умеем.
• Аггрегаторы кликов ходят в базу напрямую.
Решение
• Нужен AMQP.

36. Масштабирование на уровне дата-центров
Смерть / потеря связи
• Дата-центр некоторое время может жить без связи с «центром».
• Деньги не обсчитываются => возможны перекруты.
• Показывать можно не все баннеры.
• Дата-центр может умереть навсегда.

37. Масштабирование на уровне дата-центров
Плюсы

38. Масштабирование на уровне дата-центров
Плюсы
• Легкое масштабирование.
• Возможность разместить сервера ближе к пользователю (aka
CDN).
• Возможность менять конфигурацию/расположение серверов
без существенных проблем.

39. Переезд
Задача – из-за форс-мажора надо оперативно
поменять основной дата-центр
• Едем ночью.
• Трафик к крутилке может работать без субд и линейно
масштабирутся.
• Админку перевозим с минутным даунтаймом.

40. Спасибо!

41. Контакты.
• https://wapstart.ru/
• https://github.com/WapStart
• dev@co.wapstart.ru
• https://www.facebook.com/WapStart
• dovg@dovg.ru
• https://github.com/dovg
• https://vk.com/ekokovikhin

42. Специальный 42ой слайд.