Артем Вольфтруб: Колеги, добрий день! Мене звуть Артем Вольфтруб. Я керую розробкою в компанії "Gramant" і сьогодні буду вам розповідати про банерні системи.

Ідея цієї доповіді виникла у мене за результатами деякої роботи, хоча ми не займаємося банерними системами весь час. Ми робимо не тільки їх. Але чомусь так сталося, що дуже часто приходять запити на різні банерні системи. Ми зробили досить багато складних систем, в деяких з них тільки брали участь, консультували розробників і так далі.

Для початку трохи піару, щоб говорити не про якихось абстрактних системах, а про більш-менш відомих. Ми робили такі системи, як ValueCommerce, Imho VI. Розроблена нами система hh.ru зараз практично запущена.

Перейдемо безпосередньо до доповіді. Примітивна баннерка складається з трьох речей: банер-сервера, консолі управління ( «адмінки»), бази даних і статистики.

Звичайно, все набагато складніше. Окремі компоненти можна розгортати в більш складну структуру. Це ближче до реальності. Сьогодні ми будемо говорити, в першу чергу, про банерні сервера, статистику та моніторинг. Про управління і «адмінку» говорити не будемо, тому що там, по-моєму, все досить просто, дуже індивідуально і багато в чому залежить від використовуваної системи.

Давайте визначимося з тим, які бувають баннеркі. Вірніше, виходячи з чого вибирається та чи інша архітектура. Судячи з нашого досвіду, існує 3 бізнес-моделі, які мають на увазі використання баннерок.

Перша модель - коли баннеркі заробляють на трафіку. Є великий ресурс, або ресурси, або кілька сайтів з великим трафіком, де розміщується реклама. Наприклад, медійна реклама. При цьому практично неважливо, кому вона продається. Важливо, щоб вона транслювалася. У цей список можна внеси також промо-кампанії, брендування і т.д.

Друга модель - коли продається "інтерес" користувача: покази або кліки.

Третя модель (наскільки я знаю, в Росії вона практично не представлена) - коли продається сам продаж. Банерна система заробляє на кінцевих продажах.

Відповідно, в залежності від того, яка модель бізнесу використовується, у баннеркі є та чи інша особливість. Скажімо, якщо ми робимо баннерку, яка орієнтується на трафік, то вона, звичайно, характеризується великим навантаженням, як і будь-яка інша баннерка. Але тут важливо, що логіка показів дуже проста. Це просто віддача статичного контенту без якихось складних правил таргетування, без лімітів, без урахування унікальних користувачів, тому що це нікого особливо не цікавить. Важливо показати рекламу. Кому вона була показана, вже не так важливо.

Також ми можемо орієнтуватися на інтерес. Тут все набагато складніше. Це найпоширеніший тип, природно (особливо в Росії). Тут, як правило, є таргетинг. Тут виникають питання боротьби з накрутками. Обов'язково є складна статистика. Як правило, присутній підрахунок унікальних користувачів, що створює чимало проблем.

Останнє - баннеркі, які орієнтовані на продажу. Тут найскладніший компонент - це моніторинг продажів. Складність тут в тому, що потрібно інтегруватися з рекламодавцями. Не завжди вдається впровадити їм якийсь свій код. Іноді доводиться просити у них дані про продажі і якимось чином зіставляти їх з тими подіями, які відбувалися в баннерке.

Там, як правило, дуже складний білінг. По-перше, потрібно вважати все комісії з тим транзакціях, які були. Крім того рекламодавці, як правило, використовують досить "навороченную" модель комісій. Є поділ за категоріями товарів, за обсягами, по користувачах, по регіонах. Дуже багато правил, які треба враховувати.

Почнемо з баннерного сервера. Зрозуміло, що в будь-який баннерке це основний компонент, без якого баннерка працювати не буде, одночасно і це найбільш навантажений компонент.

Які вимоги пред'являються до банерної сервера?

• Простота. Чим простіше він працює, тим краще. Простота - це швидкість, в першу чергу.

• Слабка зв'язаність. Потрібно намагатися, щоб банерний сервер якомога менше звертався до інших компонентів нашої баннеркі. В ідеалі - нікуди не звертався, але це не завжди виходить. Чим менше зв'язаність, тим краще.

• Незалежність від інших банерних серверів. Це теж дуже важливо, щоб кожен банерний сервер був абсолютно незалежний від інших, оскільки це сильно впливає на маштабованість.

• Масштабованість - основна вимога для банерних серверів. Якщо бізнес йде добре, то навантаження зростає швидко, і маштабіроваться теж треба швидко.

• Принцип «не мовчати». Сенс його в тому, щоб банерний сервер в будь-якому випадку, незалежно від того, що відбувається, віддавав якийсь результат за кінцеве час. Це потрібно, щоб користувачі або системи, які очікують відповіді баннерного сервера, не показували повідомлення про помилку або - ще гірше - тайм-аут і так далі. Важливо зробити так, щоб ваша баннерка давала відповідь за якийсь кінцевий час. Навіть якщо вона не може показати потрібний банер. Нехай краще віддасть якийсь банер-заглушку, але, по крайней мере, це буде якась відповідь.

Трохи поговоримо про стратегії поновлення банерних серверів. Їх дві. Одна стратегія - так звана Pull. Банерні сервери запрошують дані або з бази даних, або з якогось проміжного компонента (API і так далі), запитують дані рекламних кампаній, які треба показати.

На мій погляд, це неправильна стратегія. Проте, вона присутня. Я бачив кілька разів, як її використовували. Аргументи зазвичай були такі: це прямий зв'язок між банером і базою даних або системою зберігання, системою управління кампаніями. Немає ніяких зайвих ланок у ланцюзі. Дуже просто додати нові сервера. Вони говорили: «Ми ставимо новий сервер, викочуємо на нього код баннеркі, запускаємо його - і все, він при старті зчитує всю інформацію про, починає показувати». В принципі, дійсно, це так.

Ще був аргумент: «Можна мати різний вміст на різних банерних серверах». Скажімо, одні банерні сервери віддають картинки, інші - флеш-ролики, треті - відео. Не знаю, навіщо це потрібно. Але іноді зустрічається така вимога.

Проте, така модель дуже сильно ускладнює код баннерного сервера, тому що весь механізм синхронізації повинен розташовуватися на баннерном сервері. Вона не дозволяє оновити всі сервери одразу. Але якщо у нас проблеми, ми переїхали в новий дата-центр або ще щось зробили, нам доводиться оновлювати кожен банерний сервер окремо.

Головний мінус цієї стратегії поновлення: вона не дозволяє нам зрозуміти, що сервер "впав". Звичайно, можна поставити систему моніторингу на кожен банерний сервер. Але, в общем-то, якщо банерний сервер "впав", то система моніторингу, швидше за все, теж впаде разом з ним. Ми не дізнаємося про те, що якийсь сервер "впав".

Збільшується непослідовність (англ. Inconsistency) даних, оскільки кожен сервер запитує поновлення у сховища бази даних в довільний період часу. Через це може виявитися, що в один і той же момент часу інформація на них різна. Це теж недобре, якщо у нас діє принцип однорідності банерних серверів.

Друга стратегія - це push-поновлення, тобто ми через якийсь спеціальний модуль синхронізації оновлюємо відразу весь пул банерних серверів. На мій погляд, цей підхід більш правильний, більш хороший, тому що у нас є єдина точка моніторингу. Якщо в процесі оновлення якийсь банерний сервер не відповідає, ми про це відразу дізнаємося. Ми можемо оновити всі сервери одразу або задати розклад оновлення. Це, насправді, дуже важливо, якщо ми знаємо про якісь події, які відбуваються в нашій панелі адміністратора.

Трохи пізніше я буду говорити про значно менші ліміти. Ліміти можуть вираховуватися на основі статистики. Якщо ми знаємо момент, коли статистика готова, в цей момент добре б оновити інформацію на банерних серверах. Якщо ми робимо зворотну операцію (pull), то ми не знаємо, готова статистика чи ні. Може бути, вона буде готова через секунду після того, як ми запитаємо оновлення, а ми упустимо можливість отримати актуальну інформацію.

Проте, є деякі мінуси (на мій погляд, несуттєві). Перший - потрібно реєструвати новий сервер в цьому модулі синхронізації. Він повинен знати про всі банерних серверах, які стоять в пулі.

Тут єдина точка відмови. Це теж часто наводять як мінуса. Так, хоча, насправді, її легко моніторити. Можна зробити кілька модулів синхронізації. Можна "піднімати" його автоматично. При падінні це, на мій погляд, теж спірне аргумент.

Скажу пару слів щодо підтримки контенту на різних банерних серверах. Дійсно, якщо таке завдання стоїть, то доведеться підтримувати це на рівні модуля синхронізації. Але моя особиста думка така: цього не потрібно робити. Я жодного разу не зустрічав ситуацію, коли дійсно потрібно було б мати різний контент на різних банерних серверах. Краще, щоб вони були незалежні. Це значною мірою знижує і масштабування, і підтримку, і позбавляє від ряду інших проблем.

Раз вже ми почали говорити про синхронізацію, згадаємо про те, яка вона взагалі може бути. Буває двох видів - Інкрементальний і повна.

Інкрементальний синхронізація означає, що ми оновлюємо не всю інформацію, а тільки ту, яка змінилася з моменту останнього нашого оновлення. Це, з одного боку, економить нам трафік і зменшує затримки поновлення. Процес в цьому випадку синхронізації займає менше часу, ніж у випадку повної синхронізації.

З іншого боку, такий підхід трохи більш складний, тому що нам доводиться стежити за версійна об'єктів на банерних серверах. Ми не можемо одномоментно переключити версію.

У разі повної синхронізації ми можемо створити в пам'яті баннерного сервера копію поточного стану нашої бази даних і в один момент переключити то, що він до цього показував, на те, що ми йому оновили. У разі інкрементальною це зробити складніше.

Зрозуміло, що повну синхронізацію простіше реалізувати. Вона в будь-якому випадку знадобиться. Наприклад, встановили новий сервер в пул, і треба "залити" на нього всі дані. Або, наприклад, сервер "впав" і "пролежав" 2 дні, потім у нього замінили диск (або пам'ять додали), і потрібно його оновити. У разі інкрементальною синхронізації в цьому випадку можуть виникнути помилки, тому що дуже складно відновити весь ланцюжок версій. Набагато простіше з нуля все "залити".

Трохи розповім про зберігання медіа даних. Тут, в принципі, нічого складного немає. Знаю 3 варіанти.

1. Коли ми зберігаємо їх в файлової системі банерних серверів, у нас досить простий варіант, ні від чого не залежний. У момент синхронізації ми якимось чином копіюємо на банерні сервери власне самі банери і "розкладаємо" їх там якимось чином. Швидше за все, всюди будуть використовуватися стандартні засоби Unix. Про інші можна навіть не говорити.

2. Окреме сховище - це варіант, коли ми виділяємо якийсь спеціальний сервер і "спілкуємося" з ним, наприклад, по DAV-протоколу. Викладаємо туди банери. Кінцеві користувачі завантажують ці банери до себе по протоколу HTTP. Тут теж все досить просто. Потрібно тільки потримати цей протокол обміну по WebDAV, хоча є купа готових клієнтів, і великої складності це не представляє.

3. Розподілене сховище. Досить популярний останнім часом варіант. Особливо якщо у нас мова йде про відео, про великих картинках або, наприклад, якщо нам потрібно покрити якийсь великий регіон в Росії. Набагато вигідніше використовувати CDN з точки зору ціни трафіку, щоб користувачеві, який живе у Владивостоці швидше доставляти трафік, який лежить десь поруч (хоча б в Новосибірську, а не в Москві). Це хороший варіант, який, безумовно, треба розглядати, якщо у вас стоїть завдання охоплення великої аудиторії або виникає проблема вартості трафіку, якого багато.

ліміти

Переходимо до лімітів. Якщо ми говоримо про баннерке, яка орієнтована на інтерес користувачів, там завжди виникає питання лімітів. Продаються зазвичай або покази, або кліки. Найчастіше у нас в Росії продаються, по-моєму, покази. Хоча зараз потихеньку все рухається в сторону кліків, що, на мій погляд, правильно.

Для бізнесу це одна з найважливіших опцій. Рекламодавці дуже охоче її купують, тому що вони розуміють, за що вони платять. Вони платять не за якийсь абстрактний показ реклами. Вони платять за конкретних користувачів, які перейшли до них на сайт.

Тут завжди виникає питання. Є менеджери, які продають цю рекламу і кажуть: «Нам потрібно дуже уважно стежити за лімітами. Ми не можемо перекручувати рекламні кампанії. Ми повинні завершувати всі кампанії, як тільки у нас ліміт показів або кліків вичерпаний ». Є розробники, які починають пропонувати різні компроміси: «Може бути, півгодини затримка. Чи багато ми там за півгодини перекрутити. Якщо півгодини багато, то яку затримку можна ввести? »Починається суперечка і торгівля.

Два типу лімітів

• Один тип - по рекламної кампанії, коли є бюджет. Наприклад, кількість кліків в кампанії, за яку заплатив рекламодавець.

• Другий тип лімітів, який теж дуже люблять, це ліміт показів по якомусь конкретному користувачу. Ліміт кліків зробити навряд чи вдасться. Буде ліміт показів. Показати банер одному користувачеві не більше x раз.

Насправді, це різні ліміти, які, як з'ясовується, потрібно по-різному реалізовувати. Є два рішення щодо того, як можна реалізувати ліміти.

Перше - оновлювати через статистику. Ми "відкручуємо" рекламу, збираємо статистику. Дивимося, скільки ми "відкрутили", і ці оновлені ліміти передаємо на банерний сервер в процесі синхронізації. Це спрощує роботу самого баннерного сервера, тому що йому нізвідки не потрібно діставати ці ліміти, вони "приїжджають" разом з нашими даними під час чергової синхронізації.

Це зменшує час відповіді, тому що всі дані знаходяться у баннерного движка (англ. Banner engine). Їй не потрібно звертатися нікуди зовні, щоб отримати ці дані. Але це не можна зробити без затримки, тому що завжди будуть перекрутки. Оновлювати статистику в реальному часі ми не можемо.

Також потрібно дуже швидка обробка статистики. Якщо у нас багато даних, то затримка може бути істотною (може бути 5 хвилин, а може бути і півгодини). Коли ми робили систему, де було кілька сотень мільйонів показів щодня, затримка статистики була порядку півгодини. Там, на щастя, лімітів не було. Але, в принципі, це було великою проблемою, тому що за півгодини можна показати дуже багато.

Таке рішення не дозволяє вважати покази по унікальним користувачам, тому що цих даних настільки багато, що в реальному часі їх вважати не вдається. Можна, звичайно, робити якісь прогнози (порахувати якусь порцію і екстраполювати це на число користувачів). Але якщо ми хочемо точності, то статистику не порахувати в реальному часі.

Друге рішення - використовувати загальний кеш. Як варіант - memcached або інші рішення. Це дозволяє нам мати актуальні дані. У момент показу ми відразу інкрементіруем лічильники - і банерні сервери з ними працюють. Це гарантує нам відсутність перекруток. Але це дає нам додаткову точку відмови, тому що memcached (і взагалі кеш) може зламатися.

Ще одна проблема - потрібно синхронізувати ці дані зі статистикою, в якийсь момент передавати інформацію (вона може розходитися) або покладатися на ті логи, які ми обробляємо. Але в ідеалі нам потрібно актуальні дані з memcached передавати в нашу статистику, щоб потім цю інформацію повернути назад банеру.

Ще одна проблема. Якщо, зокрема, ми використовуємо memcached, то дані можуть "вимиватися". Якщо їх стане занадто багато, то якісь дані будуть загублені. В цьому випадку ми взагалі не знайдемо нашого значення.

Загальна рада і рекомендація щодо лімітів така, що якщо вам не потрібно їх використовувати, краще їх взагалі не використовувати. Це, правда, рідко буває.

По можливості, краще використовувати статистику (по крайней мере, коли ми говоримо про значно менші ліміти по кампаніям). Все-таки краще пожертвувати п'ятихвилинної затримкою, якщо у вас не півгодини, і тим самим спростити роботу баннерного сервера.

Потрібно очікувати "падіння" кеша. Потрібно не допускати ситуації, коли даних в кеші не буде, а банерний сервер не буде знати, що з цим робити.

Краще використовувати дві стратегії для різних типів лімітів. Скажімо, наш останній підхід полягає в тому, щоб ліміти по кампаніям оновлювати через статистику, а ліміти по показам для кінцевого користувача зберігати в кеші і звідти "діставати" (в статистиці взагалі не потрібні ліміти по користувачах, тільки для показів).

орієнтування

Насправді, розповідати про нього особливо нічого. Все досить просто. Є тільки два моменти, які потрібно враховувати.

Перший момент полягає в тому, що, за нашими розрахунками, вибір таргетингу, перевірка всіх умов - це велика частина часу обробки запиту на стороні баннерного сервера. Тому краще використовувати, звичайно, не простий повний перебір і цикл, а якийсь більш розумний алгоритм. Зокрема, ми використовуємо побітові маски, щоб швидко вибирати за наявними умовами потрібний банер. Це не єдиний алгоритм, просто як приклад.

Другий момент. Звичайно, варто намагатися обмежити число параметрів таргетування. Чим більше параметрів, тим складніше їх буде вважати. Дуже важливо домовитися про те, де будуть зберігатися параметри.

Ні в якому разі не треба допускати ситуації, коли вам кажуть: «Прийшов запит від користувача. Там є IP-адреса. За IP-адресою визначте регіон і зробіть таргетинг по регіону ». Це дуже погано. Банерний сервер повинен отримувати все значення таргетингу в момент надходження запиту на показ банера, інакше дорогоцінний час буде витрачено даремно. Краще нехай той, хто передає вам дані, зробить цю роботу. Тим самим ви заощадите дорогоцінний час вашого баннерного сервера.

Реєстрація подій

Тут теж все досить просто. Але на практиці була ситуація, коли люди робили велику помилку і потім з нею мучилися. Помилка полягала, по-перше, в тому, що вони логи, які накопичуються на баннерном сервері, тримали в пам'яті. По-друге, вони дані з баннерного сервера оновлювали безпосередньо в базі даних. Це дуже поганий варіант.

Перший мінус - якщо "падає" банерний сервер, то всі ваші логи губляться. Другий мінус - якщо "падає" канал з базою даних, то взагалі незрозуміло що відбувається. Третій мінус - звернення до бази даних по мережі - це "дорога" операція, яку краще не використовувати.

Найпростіший патерн - спочатку зберігаємо дані в пам'яті. Як тільки пам'ять буфера наповнюється, "скидаємо" файл. Як тільки розмір файлу перевищує певне значення, робимо ротацію, і ті файли, які вже готові, потім забере наш модуль, який вважає статистику.

Звичайно, ніякої попередньої обробки на банерних серверах не потрібно робити. Нехай це робить окремий модуль, який буде "знати", як краще обробити статистику. Він збере її з різних банерних серверів, а ви просто, знову ж таки, ускладніть логіку баннерного сервера. Цього не треба робити.

Стратегія показів

Кілька варіацій того, з чим можна зіткнутися. Теж з практики - які виникають запити від менеджерів, які продають рекламу.

Рівномірний розподіл по часу доби (хоча б показів). І то це велика проблема, тому що якщо у нас статичні місця, без таргетингу, там все досить просто. Ми можемо це порахувати.

Якщо у нас таргетинг, то зрозуміло, що різні запити випадають з різною частотою. По-хорошому, це треба робити на основі статистики. Це сильно збільшує складність зберігання. Якщо нам треба зберегти статистику за різними параметрами таргетингу (причому не просто за окремими параметрами, а ще й по їх комбінацій), то це в геометричній прогресії збільшує обсяг даних. Цього треба побоюватися. Якщо вже так сталося, то потрібно намагатися кількість параметрів націлювання, які будуть враховуватися, хоча б тут скоротити. Чим менше їх буде (не самих параметрів, а їх можливих значень), тим менше даних буде у вас в статистиці.

Динамічний вибір кращого банера. Тут, в принципі, не дуже складно це зробити. У чому сенс? Є кілька банерів, які завантажує рекламодавець. Через якийсь час, коли у нас накопичується статистика, ми вибираємо той, у якого вище CTR, тим самим підвищуємо ймовірність кліка на нього і приносимо користь рекламодавцю. В принципі, особливої ​​проблеми немає, але треба дивитися, як би не вийшло так, що ми не зможемо вибрати потрібний банер, скажімо, в разі банерів, націлених.

Примусова "откруткі". Коли у нас є ліміти на покази (наприклад, 10 тисяч показів, і нам потрібно вибрати їх за добу). Йдеться про те, щоб динамічно "підкручувати" ваги наших банерів і показувати той банер, який найгірше "відкручується". Тут проблема в тому, що модуль, який це робить, може вступити в конфлікт з самим собою. Для двох банерів, які "крутяться" на одному і тому ж місці, він буде поступово збільшувати ваги, і вони будуть один з одним "боротися". За цим треба стежити.

Статистика

Є два основних типи даних.

• Найпростіша статистика, де покази, кліки, CTR.

• Статистика по унікальним користувачам. Ми зберігаємо інформацію про кожного користувача, зберігаємо у нього в куки-файлі ідентифікатор, і потім цей ідентифікатор відстежуємо.

Абсолютна більшість банерів, які робляться у нас, "хочуть" отримувати статистику по унікальним користувачам, тому що вона дозволяє робити всякі бізнес-речі, про які я далі розповім.

Співвідношення обсягів даних приблизно таке, як відображено на слайді. Даних з користувачами в 2 тисячі разів більше, ніж даних без користувачів. Чому - тому що дані без користувача легко "згортаються" по рекламному місця. Якщо у нас є якесь місце на сайті, ми можемо все покази з цього місця інкрементіровать в одному рядку бази даних. Якщо у нас є унікальний користувач, ми цього робити не можемо.

Щоденне збільшення даних

Для 50-ти мільйонів показів в день щоденне збільшення приблизно таке:

• 30-40 тисяч записів, якщо ми групуємо дані по рекламним місцях без користувачів.

• 6-8 мільйонів, якщо ми робимо це з користувачами.

В результаті наша робота з такою системою приводила до того, що щодня доводилося копіювати, робити архів, секціонування бази, яка зберігала дані по унікальним користувачам, і складати їх в архів. Інакше вона просто не працювала.

Для чого потрібна статистика?

Чому, власне, все так хочуть мати цю статистику? Тому що вона дає масу звітів, які дійсно гарні і цікаві. Наприклад, можна подивитися частотну характеристику.

Можна побачити, як росла аудиторія рекламної кампанії з моменту її старту. Може бути, в якийсь момент має сенс зупиняти цю кампанію.

Можна дивитися перетин аудиторії. Перетин одного і того ж користувача на різних сайтах, на різних банерах.

Можна дивитися аналіз параметрів орієнтування. Це теж здорово. Як я вже сказав, це потрібно, щоб планувати покази.

Найважливіше - пост-клік аналіз. Його всі хочуть, але мало хто робить. Це відстеження поведінки користувача на сайті рекламодавця. Ставляться спеціальні маркери, пов'язані з баннеркой. Далі ми можемо бачити, наскільки глибоко проникнення, скільки відкритих сторінок, які дії користувач здійснював - в загальному, масу всяких речей, які маркетологи просто обожнюють.

Обробка статистики

Добре б статистику виносити в окремий компонент системи, робити спеціальний вузол, який буде підсумовувати і фільтрувати дані (тобто відсікати "паразитичний" трафік, який іноді трапляється, "накліківаніе" і так далі).

Дуже важливо швидко завантажувати ці дані в базу дані, які не SQL-запитом, а бажано засобами бази даних типу SQL * Loader для Oracle або Copy для Postgres (якісь стандартні утиліти).

Важливо розділяти бази даних. Відокремлювати статистику, скажімо, від даних рекламних кампаній і, тим більше, від статистики унікальних користувачів. Статистика по ним - це нежиттєздатна архітектура, якщо ці дані живуть разом з чимось ще.

Для звітів припадає денормалізовать дані. Готувати для кожного звіту свою табличку з даними, куди в процесі обробки статистики складати рівно те, що потрібно для побудови звіту.

Дані по унікальних користувачах

Дані по унікальним користувачам не вважаються в реальному часі, і доводиться робити це в офлайні. Судячи за вашою практикою, найпростіший варіант - робити все в фоновому режимі. Робити чергу звітів, щоб вони запускалися, а результати складалися куди-небудь на диск, щоб два рази не перераховувати один і той же звіт. Можна в кінці дня перераховувати звіт за унікальними відвідувачами за день, можна робити це за запитом користувача. Але важливо, щоб це робилося один раз.

моніторинг

Це велика тема, тому просто перерахую основні моменти.

Навіщо потрібен моніторинг, нікому, я думаю, розповідати не треба. Всі прекрасно розуміють, що це і прогнозування навантаження, і діагностика, і - головне - виявлення типових проблем, які дозволяють створювати типові рішення для підтримки.

Виходячи з нашої практики, 3 види моніторингу мають сенс.

Фізичний рівень - коли ми моніторимо такі речі, як мережа, доступність сервера, ЦП, пам'ять, вільне місце на диску.

Моніторинг на рівні додатків - теж стандартні, в принципі, речі. HTTP-помилки, актуальність банерів, статистика, розмір черг і так далі.

Саме останнє - моніторинг на бізнес-рівні, який залежить виключно від логіки додатків. Наприклад, це може бути динаміка кампаній, кількість відфільтрованих даних. Якщо ми бачимо, що у нас за якийсь період різко падає число показів, значить, щось відбувається, треба на це якось реагувати. Це все теж можна подивитися. Але знову ж таки, це визначається вже конкретної системою.

У плані вимірювання у нас теж все стандартно. В основному використовуємо Nagios, для якого пишуться якісь критерії, тренди Cacti, журнали Tenshi, графіки, аналіз логів. Це все робиться в єдиному комплексі.

Виглядає це приблизно так. Список і інформація про програму і серверах додатків "зливаються" в систему моніторингу, яка на основі критеріїв генерує якісь події. Ці події обробляються командою системних операторів.

Причому для більшості подій заздалегідь готується спеціальна так звана «книга рецептів», яка «говорить», яку кнопочку треба натиснути, якщо загорілася лампочка певного кольору. Це дозволяє сильно скоротити навантаження на системних адміністраторів і надати їм можливість займатися тільки дійсно важливими проблемами, з якими впоратися можуть спеціально навчені інженери.

підтримка системи

Скажу зовсім трохи про підтримку. Головне, що дає хорошу підтримку, це наявність налагодженої системи моніторингу, наявність тих самих «готових рецептів», які дозволяють вирішувати більшість проблем, не залучаючи фахівців. Чим простіше архітектура, тим простіше її підтримувати. Дуже важливо не забувати про налагоджену систему процедури оновлень, яка дозволяє уникнути безлічі проблем, пов'язаних саме з "викатки" нових версій і з помилками, які можуть бути помітні рекламодавцям і клієнтам.

У мене все. Я готовий відповісти на питання.

Питання та відповіді

Питання із залу: Доброго дня! Дякую за доповідь. Питання. На чому ви писали банерні сервери? Як багато навантаження тримає один сервер в секунду (запитів)? Про статистику. База даних у вас - це який-небудь Hadoop або самописние речі?

Артем Вольфтруб: Оскільки тут згадувалося кілька систем, я візьму якусь одну для прикладу. В принципі, ми пишемо на Java. Банерні сервери теж пишемо на Java.

За навантаженні, якщо не помиляюся, це близько півтори тисячі запитів в секунду на сервер, без проблем.

З приводу бази даних: у нас звичайна реляційна база даних. Hadoop ми не використовуємо. Я спілкувався з доповідачем, який виступав в сусідньому залі. Там вони використовують для статистики якраз NoSQL базу даних. Але, в принципі, це не дає їм великого бенефітів, тому що вони також вважають в офлайні всі запити за унікальними відвідувачами. Це не було для нас вузьким місцем (реляційна база даних).

Питання із залу: У мене питання наступного. Я говорю як людина зі сторони, тому що баннерами ніколи не займався. Але в результаті прослуховування доповіді виникло питання по аналогій. Вчора була доповідь по системам збору даних, сьогодні - ваш доповідь. Впадає в очі дуже велика аналогія задач. Те ж саме, що ви зараз говорили по лімітах, в тих системах це уставки на телепараметри і так далі. Завдання настільки аналогічні. За показу далі були ці аналогії.

Питання. Розробники банерних систем використовують той досвід, який напрацьовано в паралельній області? У промислової автоматизації досвід на пару-трійку десятиліть більше. Там існують і архітектурні, і інші рішення.

Артем Вольфтруб: Питання, звичайно, дуже хороший. Я, на жаль, вчора не зміг бути присутнім на виступі, про який ви говорите. Але що стосується наших завдань, зробити цю систему - це не ракетобудування. Питання не в тому, щоб писати код. Це не дуже довго. Питання в тому, що там багато даних. Швидше, це питання "заліза" і швидкості оновлення.

Тут, мені здається, що колеги нічого принципово краще не зробили. Наскільки я розумію, у них теж якась своя система. Я, якщо чесно, не знаю якогось рішення з відкритим вихідним кодом, яке б дозволяло вирішити проблему лімітів. Може бути, я просто не в курсі. Але, знову ж таки, за вашою практикою написати це не дуже складно.

Питання із залу: У мене просте питання. У вас є якісь системи антічита або прогнозування?

Артем Вольфтруб: Хороше запитання. Я його викинув з доповіді, тому що часу не було. Насправді, тут є два аспекти. По-перше, боротьба з "накліківаніем". Наскільки я знаю, все, що використовують (і ми, і наші колеги), - це стандартний набір критеріїв. Кількість кліків з одного користувальницького IP-адреси в одиницю часу, перевіряється браузер, перевіряється під сіть. Якийсь набір правил, який дозволяє відсікти такий "паразитичний" трафік. Це, звичайно, не стовідсоткова гарантія. Але це основне. Я не знаю, може бути, щось ще з'явилося.

Є другий момент. Він пов'язаний з перевіркою баннеркі. Дуже часто рекламодавці вимагають, щоб можна було якимось чином перевірити, наскільки правильно баннерка показує рекламу. Вони купили, умовно кажучи, мільйон показів і хочуть переконатися, що баннерка дійсно "відкрутила" мільйон показів. Це робиться за допомогою вставки в банерну систему (навіть не в саму систему, а на сайт, де стоїть банер) коду з якоюсь сторонньою авторитетної банерної системи (Double Click, або AdRiver, або якісь ще системи). Такі завдання виникають постійно. Це, в принципі, вирішується вставкою коду, який дозволяє порівняти кількість показів за версією AdRiver, наприклад, і за версією нашої баннеркі.

Питання із залу: Що ви можете ще сказати про моніторинг?

Артем Вольфтруб: Я говорив про моніторинг. Є один з критеріїв моніторингу на рівні додатку. Ми дивимося кількість кліків ... Припустимо, у нас є майданчик, ми знаємо, який у неї CTR. Якщо ми бачимо, що у нас в якийсь момент CTR різко зростає (кількість кліків зростає), то для нас це привід розбиратися, що там відбувається.

Можна ще дивитися на статистику і відстежувати динаміку. Або запустилася якась потужна рекламна кампанія, і вона дійсно приносить такі кліки, або це якийсь "паразитичний" трафік, який треба відстежувати. У будь-якому випадку, інформація про кліки накопичується, вона зберігається якийсь час. Якщо виникає така ситуація, потім це можна просто розібрати, вичистити і "підкрутити" статистику.