Оркестрация контейнеров и атака клонов: как развивался wi-fi.ru

Эволюция порталов публичной сети MT_FREE, от румынского домена и атаки клонов до собственного медиа с авторским контентом.

«МаксимаТелеком» создает и монетизирует публичные сети Wi-Fi. В 2013 году мы первыми в мире развернули высокоскоростную (~100 Мбит/с) сеть в движущемся поезде метро и запустили массовый сервис для пассажиров.

Сеть MT_FREE в метро состоит из множества компонентов: оборудование в тоннелях и поездах, системы авторизации и монетизации, и это далеко не всё. Наиболее заметная часть сервиса — это портал Wi-Fi.ru, новостной ресурс, на который ежемесячно совершается более 66 млн визитов.

За развитие и управление порталом отвечает «Квант» — совместное AdTech-предприятие «МаксимаТелеком» и холдинга «Газпром-Медиа». Команда портала, которая занималась разработкой последние два года, рассказывает, из чего состоит Wi-Fi.ru и как эволюционировал сайт.

Идея портала возникла, как только мы развернули авторизацию в сети с показом рекламы. Авторизация — это процесс «узнавания» пользователя. Она начинается, как только он подключается к MT_FREE, и заканчивается, когда он открывает первый экран в браузере.

Сначала после прохождения авторизации мы хотели переадресовывать пользователей на главную страницу одного из поисковиков. Это — лёгкий путь, но он бы отобрал у нас собственную коммуникационную площадку. Кроме того, собственный портал создавал дополнительную возможность монетизации.

Так мы приняли решение создать свое городское медиа.

Своя версия портала есть у каждого подсайта wi-fi.ru (мы называем их сегментами). Но с точки зрения инфраструктуры портала всего два: московский wi-fi.ru и петербургский spb.wi-fi.ru. Порталы в аэропорту Уфы или в торговых центрах Ульяновска делаются на их инфраструктуре.

Помимо wi-fi.ru мы владеем доменом vmet.ro — сейчас его используют для внутренних задач, абонентам он больше не виден. Расскажем о нём подробнее.

В 2013 году силы «Максимы» сосредоточились на строительстве инфраструктуры Wi-Fi в метро. Поэтому первую версию медийного портала разрабатывало внешнее агентство. Портал назвали vmet.ro, домен выбрали из-за звучания «в метро».

Полностью вверять судьбу портала в руки агентства мы не хотели, поэтому разработали страницу авторизации — auth.vmet.ro — сами. Получилось, что страница авторизации и портал разработаны разными командами.

Домен из Юго-Восточной Европы (.ro) подвёл нас в 2014 году: датой продления был назначен ближайший новый год — с 31 декабря по 2 января. Но регистратор доменного имени ошибся и не продлевал доступ до 7 января.

Уже тогда мы понимали, что сеть будет расти за пределы метрополитена, поэтому начали искать подходящие альтернативы: что-то вроде wi-fi.ru или wifi.ru. Всё было занято, поэтому идея ждала своего часа до конца 2015 года.

Сайт мы позиционировали как мультимедиа пространство: там были разделы «Радио», «Кино», «Новости» и «Книги». Но не было собственного контента — мы занимались только его агрегацией.

В 2015 мы начали разрабатывать собственный портал — стало не хватать функций предыдущего сайта. Скажем, первый портал не позволял привязать баннер к верхней части страницы, а об играх на HTML5 речи вообще не было. Предыдущий портал работал на старых технологиях: всё было организовано на смеси PHP и MySQL. Ситуация ухудшилась из-за аутсорсинга разработки — с такой командой сложно проверять гипотезы, потому что есть коммуникационный барьер. Кроме того, техническая архитектура портала на тот момент имела много ограничений.

Проект новой версии портала внутри компании назвали «Портал 2.0». Тогда в «Максиме» уже был полноценный отдел разработки и техническое решение полностью готовилось внутри компании, без аутсорсинга.

Портал объединяет сегменты сети в разных локациях, много кода, пользователей и рекламодателей, которых нельзя подводить. Поэтому на вторую версию собственной разработки мы переходили постепенно.

Новый адрес портала wi-fi.ru появился в 2015 году, когда мы нашли владельца домена. Он планировал продвигать сайт женской тематики, а у нас был ресурс с десятками тысяч посещений в день. Сошлись на бартере — владелец передаёт нам домен, а мы несколько месяцев бесплатно размещаем на нём баннеры.

После мы несколько раз создавали новые поддомены на основе wi-fi.ru для разных сегментов сети в зависимости от локации. К 2015 году бизнес у нас резко вырос — стало больше сетей в транспорте, в том числе за пределами Москвы.

Просто перенаправлять всех на wi-fi.ru с московскими новостями не корректно. Несмотря на это, управлять контентом на портале для новых сегментов сразу не получилось, поэтому первое время мы «клонировали» сайт и контент на нём. Это время мы называем «атакой клонов».

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

Уже тогда у нас было несколько десятков порталов: на публикацию одной новости везде вручную могло уйти несколько часов. Так что необходимость новой админки никто не ставил под вопрос.

Кроме того, страдала и страница авторизации — наша разработка из 2014 года была статичной и не обновлялась под новые сегменты. Помимо этого, смущали отношения сегментов — порталы управлялись по отдельности и никак не были связаны между собой.

В 2016 году, спустя год после появления второй версии портала, мы поняли, что «клонирование» сайтов отбирает слишком много ресурсов у программистов и редакции — сегментов сети становилось все больше. На время мы «замораживаем» производство новых клонов и разрабатываем механики исключительно для рекламы и редактуры, не заходя глубже.

Спустя четыре года после запуска сети в метро, благодаря росту бизнеса и появлению новых рекламных механик, мы начали готовиться к радикальному перезапуску. Вот, что от него требовалось:

• создание новых сегментов портала без клонирования;

• адаптация под специфические спецпроекты: графику, игры и видео;

• улучшение монетизации — оптимизация рекламных мест, скорости загрузки и отрисовки баннеров;

• хранение новостей и картинок максимально долго;

• хранение истории работы над публикациями.

В портале изменилась и технология и логика взаимодействия компонентов. 3.0 — большой шаг вперед по сравнению со вторым порталом.

Третья версия осуществила мечту, с которой мы создавали портал, — полиморфный дизайн всех страниц (это значит, что страницы от сегмента к сегменту не клонируются с изменениями, а создаются отдельно) и улучшенную персонализацию контента.

Вот, как портал выглядит сейчас:

• Все сегменты управляются одной системой;
• Все сегменты одинаково мониторятся — есть информативная плашка с данными по работе портала. Техподдержка уверена в работоспособности каждого сегмента;
• При потере связи с любым компонентом портала, система тут же перезапускает его на другой виртуальной машине или в другом дата-центре;
  
• В админке хранится история редактирования материалов, можно вносить правки в тексты источников и назначать роли редакторам;
  
• Брендирование настраивается автоматически — логотипы сайтов, фирменный стиль оформления можно установить в два клика;
  
• Добавились новые форматы рекламы;
  
• Поддержка эмбедов: в статьи можно вставлять видеоролики, посты из социальных сетей и рекламные коды без угрозы для безопасности портала;
  
• Портал обновляется целиком на всех сегментах сразу.
  

На третью версию мы переходили не сразу — начали с декабря 2018, а полностью закончили в июне 2019. В промежуток между датами разные сегменты сети были на разных версиях портала: например, сеть Московского центрального кольца уже была на 3.0, а в метро работала 2.0.

Начать решили с МЦК. Пользователей там не так много, как в метро, но и не так мало, как в региональных аэропортах. На декабрь 2018 года МЦК обеспечивало 10% подключений среди всех сегментов MT_FREE. Так мы застраховались от ошибок: если что-то пойдёт не так, потеряется не много рекламного трафика.

Помните виртуальные машины из второго раздела? К концу 2018 года на все сегменты портала их уходило целых 50 штук — один сегмент на одной виртуальной машине (ВМ).

Пилотную версию портала 3.0 на МЦК мы запустили на одной ВМ. Запуск на МЦК оказался успешным — время загрузки страниц снизилось, сервис не падал и худшие сценарии не оправдались.

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

После МЦК решили «заходить» в наземку — развернулись на сети Netbynet, на тот момент оператора Wi-Fi в наземном транспорте Москвы. Сегмент опять выбрали небольшой — 8% от всего трафика. Автобусы и трамваи повторили успех МЦК в апреле 2019. После запуска метрики опять порадовали: глубина просмотров увеличилась — пользователи стали смотреть за сеанс в среднем на 2,5 страницы больше. Время на сайте и просматриваемость рекламных форматов также возросли.

Приняли решение расширяться на Петербург, но кое-что не учли…

После наземки мы запустили ещё 5—6 сегментов и доказали эффективность нового релиза. После этого решили запускать пилотные версии порталов в системе с большей отказоустойчивостью, чтобы набраться опыта перед запуском «ответственных» сегментов — метро Москвы и Петербурга.

Всё работало слаженно, третий портал, помимо прочего, решил проблему неэкономного использования ресурсов. Проблема в следующем: все сегменты портала по-разному используют ресурсы виртуальных машин.

Отсюда и проблема: зачем выделять одному сегменту по виртуальной машине, если, в зависимости от нагрузки, им может хватить и половины, и трети той мощности, которую даёт ВМ? Проблема решается контейнеризацией.

Третий портал мы сразу проектировали под контейнеры — а от отдельных ВМ, на которых раньше разворачивали сегменты, ушли к оркестрации контейнеров c помощью Kubernetes. Вместо ВМ сервис держит все контейнеры порталов в «облаке» и выделяет им ресурсы по мере необходимости.

Кроме экономии места и вычислительных ресурсов, оркестрация контейнеров уменьшила количество взаимодействий между командой разработки и IT.

Санкт-Петербург занимает второе место среди наших сетей по трафику. После большой сети можно было бы переключаться на мелкие: Казань, Магадан и другие регионы. Если проблем не возникло на крупном сегменте, на мелких площадках всё точно будет хорошо.

Кроме того, на крупной площадке вроде Петербурга стоило проверить и новую оркестрацию от Kubernetes — в теории она работает без проблем, но никогда не знаешь, где могут возникнуть недочёты.

Мы развернули портал на северную столицу и стали использовать канал Москва-Петербург для связи между фронтендом и бэкендом. Вскоре возникла авария у провайдера канала и мы решили, что дальше на него полагаться не будем — канальная инфраструктура на такое применение не рассчитана, её использовать стоит только на крайний случай.

Выхода было два: или сделать апгрейд каналов, или перенести часть инфраструктуры в Петербург. Решили остановиться на втором — он соответствует архитектурным принципам ИТ-ландшафта: обеспечить обеим столицам собственную инфраструктуру.

Сейчас отношение между инфраструктурой двух столиц работает так: все приложения и системы (включая портал) находятся в Москве и Петербурге, тот самый канал связи используется только для синхронизации Big Data между столицами. Если с сетью в Москве что-то случится, то Петербург продолжит работу, но со старой Big Data (что в перспективе приведёт к ухудшению таргетирования рекламы).

Тем не менее, инфраструктура Петербурга может несколько дней работать без существенных потерь. По нашим расчётам, любую неисправность с сетью можно исправить за день.

В итоге решение для Петербурга появилось последним из всех. Оно заключается в том, что мы продублировали инфраструктуру (всю, кроме BigData) в Петербург, с тем же расчётом — минимум день автономной работы. Перезагрузили все системы и вздохнули с облегчением.

На момент запуска в метро Москвы мы настолько наладили процесс, что были готовы к нагрузкам в десятки раз превышающие расчётные. Поэтому запуск не принёс ничего интересного — сервис выдержал нагрузку, а команда портала разошлась по домам (дело было вечером).

Полезным был разве что опыт исправления утечек памяти с помощью профилирования Node.js сервера с SSR.

У третьего портала появилась гибкость, с ним мы можем внедрять экспериментальные решения. А проверять решения теперь проще всей команде.

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

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

Мы готовимся к тому, чтобы встроить тесты нового портала в процесс разработки — так они будут запускаться при каждом обновлении без нашего участия.

До запуска третьего портала мы тестировали код Unit-тестами и тестами API, при этом проверки интерфейса приходилось проводить вручную. Система становилась сложнее, и тесты UI тоже решили автоматизировать. Сейчас готовимся к встраиванию автоматических тестов нового портала в систему непрерывной интеграции — так они будут запускаться при каждом обновлении без нашего участия.

Под рекламодателем мы понимаем бизнес или человека, который хочет разместить у нас рекламу. Они размещаются на портале как напрямую, так и через рекламных вендоров. Во втором случае речь идет о технологиях programmatic, которые позволяют выкупать только конкретную аудиторию на площадках.

Помимо тестов функциональности портала, существуют ещё и тесты механик рекламной монетизации. Раньше всем рекламодателям, которых мы получаем от крупных вендоров (Google AdX, Criteo, MyTarget и другие), на портале мы выделяли одинаковые каналы трафика вне зависимости от эффективности их рекламы. Теперь разным рекламодателям мы даём разные доли трафика, а низкодоходных и вовсе отключаем от системы.

С помощью сплит-тестов мы обрабатываем несколько сотен сценариев за раз. Например, оцениваем эффективность рекламодателей и форматов.

В рекламе собачьего корма спецпроект в виде мини-игры может оказаться эффективнее полноэкранного баннера. Задача тестирования — определить эффективность рекламного формата и выразить её в числовом отношении.

Также мы оцениваем эффективность сервисов, встроенных в портал. Скажем, рекомендательный виджет Яндекса отличается по выхлопу от обычных механик рекомендаций контента.

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

• Детальная сегментация. У нас есть несколько сегментов интересов: красота и здоровье, спорт, кино и гаджеты. Если посетителя портала мы можем определить в один из сегментов, он попадает не на главную страницу, а на один из разделов портала, например, wi-fi.ru/sport. Ожидаем, что благодаря такой сегментации, к концу 2020 года отказов станет меньше на 40%.
• Запуск рекомендательной системы контента и сравнение её эффективности с рекомендательными виджетами сторонних систем. К концу 2020 покажем первую версию системы.