• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
WapStart: Как показывать 200 миллионов баннеров ежедневно и быть готовым показать миллиард.
 

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

on

  • 537 views

 

Statistics

Views

Total Views
537
Views on SlideShare
537
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Как показывать 200 миллионовбаннеров ежедневно и бытьготовым показать миллиард.Евгений Коковихин, руководитель отдела разработки Wapstart.Разработчик баннерной сети http://plus1.wapstart.ru/.
    • О компании WapStartWapStart – владелец крупнейшей в России мобильной рекламной сетиPlus1 WapStart и наиболее полного и популярного в России каталогамобильных сайтов Top WapStart.Компания оказывает услуги тысячам издателей мобильных сайтов иприложений. Ежемесячная рекламная емкость WapStart – свыше 4,2млрд. показов, число уникальных посетителей – более 25 миллионов.Компания WapStart владеет передовымитехнологиями таргетинга и анализа аудитории,позволяющими проводить рекламные кампаниив мобильной среде с высокой рентабельностьюинвестиций.
    • Marketing is so marketing
    • 050010001500200025003000350040004500Millions
    • Задача•  Будьте готовы показать миллиард. //это примерно 13-15K rps.
    • Год назад у нас было такfront1farm1 farm2 farm3 farm4 … farmNfront2Master-dbSlave-dbCache 1 Cache 2 Cache 3
    • Идеи•  Все должно быть локально.
    • Идеи•  Пользователь должен всегда попадать на один и тот же бекенд(так как у нас все локально).
    • Идеи•  Ротатор (баннерная крутилка / php-fpm) не должен ходить вбазу.
    • Идеи•  Нужна какая-то умная штука для синхронизации.
    • Реализация.
    • Задача: сделать такfront1farm1cache1farm2cache2farm3cache3farm4cache4……farmNcacheNfront2Master-dbSlave-dbqueuefiller
    • Реализация:•  Для nginx есть модуль persistent upstreamhttps://github.com/replay/ngx_http_consistent_hash•  Мы его доработалиhttps://github.com/WapStart/ngx_http_consistent_hashПользователи должны попадать в один и тот жеupstreaminclude /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.•  Цепочка стала более длинной, время реакции увеличилось.Решение:•  Предсказываем события.
    • Масштабирование на уровне дата-центров
    • Задача. Сделать так:ЦентрPrimaryDNSСУБДСинхрони-заторУправлятортрафикомМонито-рингInternetДата-центр 1Дата-центр 2Дата-центр 3Дата-центр 4
    • В пределах дата-центраfront1farm1cache1farm2cache2farm3cache3……farmNcacheNцентр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.
    • Масштабирование на уровне дата-центровСмерть / потеря связи•  Дата-центр некоторое время может жить без связи с «центром».•  Деньги не обсчитываются => возможны перекруты.•  Показывать можно не все баннеры.•  Дата-центр может умереть навсегда.
    • Масштабирование на уровне дата-центровПлюсы
    • Масштабирование на уровне дата-центровПлюсы•  Легкое масштабирование.•  Возможность разместить сервера ближе к пользователю (akaCDN).•  Возможность менять конфигурацию/расположение серверовбез существенных проблем.
    • ПереездЗадача – из-за форс-мажора надо оперативнопоменять основной дата-центр•  Едем ночью.•  Трафик к крутилке может работать без субд и линейномасштабирутся.•  Админку перевозим с минутным даунтаймом.
    • Спасибо!
    • Контакты.•  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ой слайд.