Архитектура plus1.wapstart.ru

Добрый день, сообщество!

Изначально я планировал написать статью в виде конспекта с доклада ^[1] на devconf ^[2]. Потом на меня снизошло понимание, что сорокапятиминутное выступление сложно переложить в статью на хабре, при этом оставив ее размер вменяемым. Поэтому в статье речь пойдет об архитектуре plus1.wapstart.ru ^[3], а слайды с конференции можно посмотреть здесь ^[4].

Plus1.wapstart.ru ^[3] — это рекламная сеть для мобильного интернета. Наша «экосистема» — это рекламодатели, владельцы площадок (сайтов и приложений) и аудитория пользователей.
Владельцы площадок хотят максимально просто и эффективно монетизировать свою аудиторию, рекламодатели хотят эффективно вложить деньги, потребителей реклама должна как минимум не раздражать, а как максимум — они должны быть ей довольны.
Задача plus1.wapstart.ru — удовлетворение потребностей этих групп. Для нас их желания означают, что мы должны работать максимально быстро, не допускать ни минуты даутнайма и само собой следить за качеством и внешним видом рекламы.

Немного цифр:

• Пиковая нагрузка > 10³ динамических запросов в секунду.
• В день мы показываем более ~ 10⁷ объявлений.
• Cуммарное число баннеров и площадок измеряется четырехзначными цифрами.
• Среднее время отдачи баннера не превышает 90ms.

Если вам интересно как это всё работает — добро пожаловать под кат!

Железо

ПО

Мы стремимся к единообразию:

• Фронты — freebsd ^[5], nginx ^[6].
• Ферма (сервера приложений) — Debian GNU/Linux ^[7], php 5.3 fpm ^[8], onphp framework ^[9], memcached ^[10], свои демоны (о них мы расскажем в следующем докладе).
• Сервера баз данных — Debian GNU/Linux, Postgres ^[11] 9.0, репликация из коробки.
• Обслуживающие сервера — Debian GNU/Linux, zabbix ^[12], pinba ^[13].

Как мы подбираем баннер

Главное правило — если что-то можно посчитать заранее, это нужно считать заранее.

Сам процесс выглядит примерно таким образом:

• Мы разбираем запрос (http) на показ баннера. Из быстрого хранилища
  мы получаем характеристики этого запроса: определяем оператора по ip
  адресу, модель и операционную систему телефона по user-agent и другим
  заголовкам.
• По каждой характеристике запроса мы получаем список баннеров,
  подходящий для этого запроса.
• Пересекаем (intersect) списки.
• Полученная совокупность баннеров проверяется дополнительными
  «чекерами». Это обусловлено тем, что некоторые проверки можно сделать
  только во время выполнения, т.к. они привязаны к конкретному запросу.
  Например, нет смысла показывать баннер пользователю, если он его уже
  видел 10 раз и не кликнул на него.

Как мы считаем статистику

Надо быть всегда готовыми к росту. Процессы надо закладывать таким образом, чтобы их можно было легко распараллелить.

Работает оно так:

• Каждый сервер пишет статистические события (факт показа, факт клика, и т.д.) в файл в cериализованном виде.
• Файл в имени содержит метку времени.
• Обработчик файлов группирует записи из файла, «схлопывая» однородные события в одну запись, пишет полученный набор во временную таблицу в базу и архивирует файл.
• Временная таблица содержит метку времени в имени. После ее аггрегации в часовые таблицы она удаляется (drop).
• Из часовых таблиц строятся дневные таблицы, а из дневных — месячные. Данные в каждом виде таблиц имеют определенную давность хранения.

Мониторинг

Сейчас в качестве основного сервиса для мониторинга мы используем zabbix. Не могу сказать, что он быстр, но на нашем наборе триггеров и серверов работает вполне сносно. Мониторятся не только железные
показатели (io, cpu, la) и показатели приложения (время отдачи, отрост логов), но и бизнес-метрики (коммерческая тайна :).
Для сбора оперативной статистики приложения мы используем pinba (о ней я уже писал ^[14] :) ).
Наиболее критичные триггеры приходят к нам по sms.

Ошибки

Ошибки бывают у всех. Естественно, что разработчики должны знать об ошибках, причем желательно узнать о них до того как о них узнает пользователь. Для сбора ошибок мы используем syslog ^[15], благо php
умеет туда логгировать. Данные из syslog аггрегируются на обслуживающем сервере и раз в N минут отправляются по списку рассылки. Это позволяет оперативно отлавливать проблемы.

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

ps. Мы делимся с сообществом нашими наработками — https://github.com/Wapstart ^[16]
pps. О том как ^[17] мы «обманываем» наши приложения будет отдельный пост.

Автор: dovg