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

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



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

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

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


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


    Железо




    ПО


    Мы стремимся к единообразию:
    • Фронты — freebsd, nginx.
    • Ферма (сервера приложений) — Debian GNU/Linux, php 5.3 fpm, onphp framework, memcached, свои демоны (о них мы расскажем в следующем докладе).
    • Сервера баз данных — Debian GNU/Linux, Postgres 9.0, репликация из коробки.
    • Обслуживающие сервера — Debian GNU/Linux, zabbix, pinba.

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




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



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

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




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

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

    Мониторинг




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

    Ошибки


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

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

    ps. Мы делимся с сообществом нашими наработками — https://github.com/Wapstart
    pps. О том как мы «обманываем» наши приложения будет отдельный пост.
    WapStart
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 19

      +2
      Побольше бы такой рекламы. Я в хорошем смысле — подробно описаны моменты, которые мне были весьма интересны (а не как сделали купикупон/дора).
      Будет замечательно, если вы продолжите публикацию статей (например, о настроке серверов для high-load)
        +1
        Да, обязательно продолжим. Про сервера предложение учтём.
        +2
        Весьма креативные иллюстрации :)
          0
          Спасибо, я старался :)
          +1
          Хорошая статья

          > Сейчас в качестве основного сервиса для мониторинга мы используем zabbix. Не могу сказать, что он быстр, но на нашем наборе триггеров и серверов работает вполне сносно

          В чем проблема с Zabbix и почему он начинает тормозить? Имеется ввиду что он не успевает снимать показания?
            0
            В чем проблема с Zabbix и почему он начинает тормозить? Имеется ввиду что он не успевает снимать показания?

            Интерфейсы тормозят на нашем наборе данных. Если выбрать screen «потолще» и попробовать открыть его за день, то ответ приходится ждать секундами, а иногда и минутами. Это печалит.

            На самом деле, gui zabbix для большинства наших задач не нужен — нам будет достаточно какой-нибудь rrdtool
              0
              В конфиге Zabbix пытались задирать параметры связанные с кешем?

              Вообще насколько меняется динамика скорости загрузки при изменении параметров кеша в конфиге Zabbix? Они реально помогают или существенно скорость не увеличивается?
                0
                Дальше физического быстродействия железяки сдвинуться нельзя :)
                Проблема в том, что «редкие» данные надо поднять с диска.
              0
              Кстати, недавно Мамба хвасталась своим решением, но я еще не успел посмотреть.
              0
              а как одна сервисная машина записывает статистику в файл? и что будет при попытке одновременной записи в файл?
                0
                Файлы пишутся на каждом сервере фермы.
                При попытке одновременной записи в файл ничего плохого не произойдет. Это, кстати, обеспечивается стандартными инструментами php. См третий параметр к ru2.php.net/file_put_contents
                  0
                  Если вы будете использовать флаг LOCK_EX, то возможна ситуация при которой два и более одновременных процесса записи попытаются войти в режим блокировки файла. Что будет тогда?
                    0
                    Мы пишем с FILE_APPEND. Его не нужно блокировать, см bugs.php.net/bug.php?id=49329
                    В документации сейчас ошибка.
                0
                Хорошо расписали (только вот почерк почти как у врача :)
                Так же интересно почитать про настройку серверов и про работу каталога сайтов.
                Контекст сайта как-то анализируется или баннеры выдаются просто по фильтрам (оператор, устройство и т.д.)?
                  0
                  Контекст сайта как-то анализируется или баннеры выдаются просто по фильтрам (оператор, устройство и т.д.)?

                  У площадки есть категории, их можно задать при регистрации.

                  Контент сайта не анализируется, мы в этом плане доверяем пользователям: если баннер имеет хороший ctr на конкретном сайте, то в очереди он будет постепенно всплывать наверх.
                  0
                  По onphp есть документация? Примеры? Интересно посмотреть
                    0
                    Есть wiki, статья на хабре, и разные статьи в жж, например.

                    Вообще, мы придерживаемся мнения, что исходный код — это лучшая документация. :)
                    0
                    Спасибо за подробный рассказ.
                    Ферма (сервера приложений) — Debian GNU/Linux, php 5.3 fpm, onphp framework, memcached, свои демоны (о них мы расскажем в следующем докладе).
                    Очень интересно о каких именно демонах идет речь?

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое