Как показывать 200 миллионов баннеров ежедневно и быть готовым показать миллиард.

Как показывать 200 миллионов баннеров ежедневно и быть готовым показать миллиард.

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

О компании WapStart

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

Marketing is so marketing

0

500

1000

1500

2000

2500

3000

3500

4000

4500

Mill

ions

Задача

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

Год назад у нас было так

front1

farm1 farm2 farm3 farm4 … farmN

front2

Master-db

Slave-db

Cache 1 Cache 2 Cache 3

Идеи

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

Идеи

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

Идеи

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

Идеи

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

Реализация.

Задача: сделать так

front1

farm1

cache1

farm2

cache2

farm3

cache3

farm4

cache4

…

…

farmN

cacheN

front2

Master-db

Slave-db

queue filler

Реализация:

•  Для 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;


•  Выпиливаем из конфигов подключение к СУБД и отлаживаем.

Безбазье


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

серверах. •  Интерфейс неизменный. При этом читаем всегда из локального

кеша, а пишем во все. •  Пишем только из центра.

Преднаполняторы кеша

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

Реализация: Клики; теория перекрутов

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

Реализация: Клики; теория перекрутов

•  Среднюю величину перекрутов любого рода можно предсказать. •  Время реакции тоже предсказуемо.

//Осталось лишь согласовать с бизнесом )

Реализация: Клики; обработка в фоне

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

Решение: •  Предсказываем события.

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

Задача. Сделать так:

Центр

Primary DNS

СУБД Синхрони-затор

Управлятор трафиком

Монито-ринг

Internet

Дата-центр 1




В пределах дата-центра

front1

farm1

cache1

farm2

cache2

farm3

cache3

…

…

farmN

cacheN

центр VPN Синхрони-

затор

Масштабирование на уровне дата-центров Можно выбрать дорогой дата-центр, а можно быть

готовым к его падению

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

дешево.


Hetzner: проблемы и ограничения


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

отсутствию связи. •  Если упадет «датацентр» целиком, мы должны продолжить

работу.

Hetzner: проблемы и ограничения

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

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

•  Трафик/логи.

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

•  CPU load.

Масштабирование на уровне дата-центров Мониторинг должен быть распределенным

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

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

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

•  Измеряем трафик по подсетям или странам. •  Создаем view в bind (google://named views). •  Ждем.

Ограничения •  Иногда dns сервер клиента находится за пределами его сети. •  DNS рассасывается не моментально. •  Порции трафика выделяются по подсетям => иногда они

слишком большие, а иногда – маленькие.

Масштабирование на уровне дата-центров Как делить трафик: http permanent rewrites

•  Находим какой-нибудь критерий деления (площадка, user-agent, etc).

•  В nginx rewrite … permanent. •  Изменения вступают в силу сразу.

Ограничения •  Применимо только client-to-server подключений. •  Лишняя нагрузка на фронт-«делитель». •  Повышенное время ответа клиенту.

Масштабирование на уровне дата-центров Как делить трафик: поддомены для крупных

партнеров

•  Для крупных server-to-server партнеров можно завести отдельный субдомен partnerName.ro.plus1.wapstart.ru и заставить гнать траффик на него.

•  Изменяем dns и ждем.

Ограничения •  Применимо только для крупных партнеров. •  Время реакции DNS.

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

VS

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

•  Списки баннеров доставляются шарманкой, но «срочные изменения» мы пока доставлять не умеем.

•  Аггрегаторы кликов ходят в базу напрямую.

Решение •  Нужен AMQP.

Масштабирование на уровне дата-центров Смерть / потеря связи

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

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

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

•  Легкое масштабирование. •  Возможность разместить сервера ближе к пользователю (aka

CDN). •  Возможность менять конфигурацию/расположение серверов

без существенных проблем.

Переезд Задача – из-за форс-мажора надо оперативно

поменять основной дата-центр

•  Едем ночью. •  Трафик к крутилке может работать без субд и линейно

масштабирутся. •  Админку перевозим с минутным даунтаймом.

Спасибо!

Контакты.

•  https://wapstart.ru/ •  https://github.com/WapStart •  [email protected] •  https://www.facebook.com/WapStart

•  [email protected] •  https://github.com/dovg •  https://vk.com/ekokovikhin

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

Как показывать 200 миллионов баннеров ежедневно и быть готовым показать миллиард.

Documents