Весною 2012 року за рекомендаціями наших постійних клієнтів до нас звернувся молодий, амбітний та наполегливий бізнесмен з Москви з замовленням, яке поставило нас в ступор… І хоча на той момент ми працювали на ринку Друпал-розробки біля 5 років, проте таких складних завдань перед нами ще не ставилося. Проект називався HiConversion і передбачав наступний функціонал:
- публікація та управління рекламними оголошеннями в соц.мережі VK;
- збір статистики по всім опублікованим оголошенням із зовнішніх джерел, таких як VK, Google Analytics, Yandex.Metrica;
- можливість перегляду статистики по опублікованим оголошенням за будь-який період часу;
- автоматичне або ручне управління, в залежності від результатів зібраної статистики;
- можливість налаштовувати всі таргетинги як в індивідуальному порядку, так і масово;
- інтерфейси для роботи рекламних агенцій, ієрархічна система ролей та доступів;
- контроль стану рахунку клієнта: можливість його поповнення, автоматична зупинка оголошень.
І це далеко не вичерпний список. Але давайте розглянемо архітектурний підхід до реалізації такого технічно складного проекту більш детально.
Як бачите, поставлені перед проектом задачі були далеко не тривіальні для веб-додатку, тим більше, вони повністю виходити за рамки “рідного” для Drupal функціоналу. Необхідність оновлювати десятки тисяч запитів за хвилину інформацією з зовнішніх джерел змусила нас шукати нетрадиційні рішення для подолання обмежень більшості механізмів як ядра Drupal, так і сторонніх сервісів.
Для найбільш ефективного використання обмежень сторонніх сервісів на запити, враховуючи різний формат даних, їх принципів комунікації та аутентифікації, нам довелося переосмислити формат збереження та обробки черг в Drupal. Черга оброблялася не завдяки повільним запитам за розкладом (cron), а php-демоном, який постійно моніторив наявність елементів у черзі та виконував задачі настільки швидко, наскільки це взагалі було можливо. За лімітами ресурсів вела спостереження складна система “семафорів”, побудована на механізмі замків Drupal (Lock API), а створені нами інтерфейси дозволяли зручно та комфортно додавати нові типи елементів черги.
Оскільки нам доводилося зберігати величезні об’єми статичних даних (близько мільйона записів) і постійно їх оновлювати, ми були змушені глибоко модифікувати принцип обробки полів в Drupal. Для того, щоб зовсім не відходити від філософії Drupal та мати можливість використовувати максимальну кількість стандартних рішень, ми не тільки створили нові, більш підлаштовані до наших потреб типи полів, але й використали можливості Drupal Field Storage API на всі 100%. В нашому випадку більшість операцій вимагали великої кількості полів однотипної інформації за один раз, тому ми значно виграли в продуктивності, додавши можливість масового оновлення полів із подальшим викликом необхідних хуків. Пізніше такий підхід дозволив нам використовувати готові модулі для побудови складних представлень (views) із заплутаними наборами фільтрів і можливістю їх збереження.
Незважаючи на всю складність побудованої нами системи, ми також заклали в її фундамент можливість розширення функціоналу та додавання обробників подій черги з гнучкими налаштуваннями. У юзер-інтерфейсі це виглядало як додавання нового елемента Field Collection із набором полів налаштувань, а з боку коду необхідно було лише додати обробник цих налаштувань і правил реакції на події, розширивши базовий клас поведінки (reaction handler-a).
Звичайно, крім цього, перед нами було поставлено й інші, більш характерні для звичайних веб-додатків, задачі. Наприклад, можливість редагування рекламних оголошень, використовуючи вивантаження таблиць Excel (до того ж, в обидві сторони), парсити за розкладом фіди Яндекс.Маркету, та багато інших задач, пов’язаних із складним користувацьким інтерфейсом. Варто також звернути увагу, що в ході роботи над цим проектом нами було викладено декілька патчів для contrib модулів, в тому числі й модуля Views.
Тепер наведемо декілька реальних цифр, з якими успішно вправився цей “монстр” на момент завершення нами співпраці з цим клієнтом:
- 400 000 нод на сайті;
- від 4 000 до 20 000 нових оголошень в день;
- 2 000 активних рекламних кампаній;
- 145 000 опублікованих оголошень;
- 8 000 одночасно запущених оголошень;
- 21 000 оголошень, по яким збирається статистика та обробляється тактика таргетингу менш ніж за хвилину;
- до 90 000 запитів до API VK в день, середнє значення - 30 000;
- розмір бази даних 8Гб, до двох мільйонів записів в одній таблиці;
- 1 рік розробки силами команди з 4 чоловік;
- більше 32 000 рядків коду.
Звичайно, не кількістю рядків коду вимірюється якість роботи. Тому давайте змістимо акценти й на інші пункти, більш зрозумілі далеким від програмування людям:
- Цей проект став однією з 7 рекламних мереж, які отримали акредитацію VK;
- HiConversion було номіновано на премію “Стартап року 2012” в Росії;
- За перші півроку з моменту запуску першої ітерації проекту клієнтами цього сервіс-провайдера стали великі корпорації, серед них МТС, Евросеть, Teamo, Sotmarket, Альфа-Банк та інші.
Незаперечну роль в такому успіху проекту відіграли й самі власники цього стартапу: вони дуже грамотно підійшли до побудови бізнес-архітектури свого дітища. І до слова, другу ітерацію проекту було реалізовано за наступний рік із використанням зовсім іншої технології розробки. Проект продовжує розвиватися та утримувати позиції на ринку таргетингової реклами в соц.мережах. Усім би таких клієнтів і таких цікавих проектів!