Самое неприятное — попасть под массовую блокировку IP-адресов

Технические директора ИД «Комитет», «Бумаги», Independent Media и «Нашего Радио» — об IT-поддержке онлайн-изданий, выборе инфраструктуры и технологических вызовах для медиа.

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

«Бумага» хостится за рубежом. Отечественных провайдеров мы особо не рассматривали ни тогда, ни сейчас — нет острой необходимости. Персональные данные пользователей мы не собираем — только почты, а значит, под закон о хранении таких данных в России не попадаем. Несколько лет назад использовали серверы российского провайдера для небольшого сайд-проекта, но опыт нельзя было назвать вдохновляющим.

Хостинг за рубежом, в целом, нас устраивает. Хотя то, что наш провайдер вырос и работает с большим количеством клиентов, иногда влияет на порядок работы. Не всегда статус-панель отражает актуальное состояние систем, могут быть задержки. И вот, у тебя что-то отвалилось, а провайдер показывает, что у него все хорошо. Минут 30 думаешь, где же может быть загвоздка, пока наконец статус-панель не объявляет о существующей проблеме. Если подобное случается поздно вечером, о полноценном сне ночью можно забыть.

Основной сайт «Бумаги» поддерживают пять vpc (virtual private cloud). Один облачный сервер для базы данных, отдельная виртуалка для веб-сервера, еще несколько для интерпретатора PHP и запуска скриптов. Наконец, последняя vpc поддерживает поиск по сайту, сокращатель ссылок и другие мелкие сервисы.

В начале 2020 года — прям перед пандемией — мы изменили архитектуру «Бумаги», сделав ее более гибкой. Изначально все, что распределено сейчас между vpс, лежало на одном сервере. С учетом роста СМИ это стало вызывать проблемы.

Первый затык случился во время теракта в Санкт-Петербурге (3 апреля 2017 года — прим. ред.). Все начали искать информацию — у нас резко подскочил трафик, и мы не были к этому готовы. Тогда не могли зайти даже в админку. Вели текстовую трансляцию происходящего через сторонний сервис — это нас тогда выручило.

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

В итоге мы достаточно легко справились с ростом посещаемости во время локдауна. Даже не пришлось ничего переделывать и добавлять.

Онлайн-издание — это всегда большое количество статического визуального контента, объем которого растет год от года. Исторически все такие данные «Бумаги» лежали на одном сервере, пока не стали занимать все место. Мы решили попробовать S3-хранилище от AWS, но поняли, что это не очень выгодно. В итоге просто увеличили объем сервера для хранения статики и раздаем ее через CDN для экономии трафика.

Мы используем Project Shield от Google, и поэтому, кстати, «Бумага» недоступна в Крыму. PS позиционирует себя как защита от DDoS, но покрывает и функции CDN.

В целом, актуальная IT-архитектура «Бумаги» сложилось в том числе в результате решения проблем, с которыми мы сталкивались. Так, один раз у нас отвалилась часть инфраструктуры, на которой хранились картинки. И вместо того, чтобы сайт грузился без них, он перестал грузиться совсем. Причина была в том, что сервер с картинками был подключен через NFS (Network File System) к веб-серверу. И когда последний обращался по NFS к картинкам и не получал ответа, все его процессорное время уходило на ожидание подключения. Я исключил эту зависимость в логике инфраструктуры, и теперь, если картинки по какой-то причине отвалятся, они просто не прогрузятся для конечного пользователя (если не закэшированы).

Один из самых неприятных для медиа моментов — блокировка IP-адресов, при которой ты можешь попасть под раздачу. Первый раз «Бумаги» был запоминающимся. Мы тогда использовали Cloudflare в качестве CDN. И вот, в один день мы приходим утром на работу и понимаем, что наш сайт на работает для большого количества читателей. Потом оказалось, что Роскомнадзор заблокировал сайт то ли букмекера, то ли онлайн-казино. По чистой случайности они тоже использовали Cloudflare, тот же IP-адрес, что и мы. «Бумага» пошла в бан вместе с этим казино.

Второй случай был с небезызвестной блокировкой Telegram. Жертвой пал и весь Project Shield, которым мы пользовались тогда и сейчас. После случившегося я описал ситуацию техподдержке Project Shield, и они поместили нас на отдельный айпишник. С тех пор проблем не было. Кроме того, я давно завел привычку первым делом проверять IP-адрес через специального бота, когда поднимаю новый сервер.

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

Инфраструктуру поддерживаю в основном я: выполняю роль сисадмина и архитектора. Также мне помогает наша мидл-разработчица, которая выполняет часть задач и подключается в случае форс-мажоров. Концептуально обсуждаем все изменения IT-составляющей «Бумаги» с командой и нашим СEO Кириллом (Кирилл Артеменко, директор «Бумаги», — прим. ред.).

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

Все, кто знаком с медиа, объединенными в ИД «Комитет», знают, что они выглядят примерно одинаково. На самом деле, и в плане кода, и в плане инфраструктуры они являются близкими копиями друг друга. Если мы реализуем новую функцию, она применяется сразу ко всем сайтам. Разброс серверных мощностей между ними тоже примерно одинаковый.

Фундамент сайтов «Комитета» — Osnova, самописная платформа для контентных проектов. Пожалуй, самый сложный в разработке и поддержке продукт. Это монолит, который долгое время накапливал в себе код. Искать баги — отдельная задача: можно закопаться в коде и забыть, зачем ты вообще сюда зашел.

Мы начали постепенно распиливать наш монолит, выводя часть функционала в сервисы. Есть отдельный сервис для хранения и раздачи картинок, отдельный — для системы рекомендаций, автоматической озвучки статей или рекламной «крутилки» и так далее.

С самого начала мы хостились в Selectel на выделенных серверах. Без учета Coub мы используем более 35 серверов. На Coub только для раздачи статических данных работают 12 серверов. Арендуем серверы в разных дата-центрах в Санкт-Петербурге и Москве. Видео, картинки, аудиофайлы лежат в облачном хранилище. Защиту от DDoS-атак подключили в Selectel, а CDN используем от Akamai.

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

Кэширование мы используем активно, это обусловлено особенностями нашей площадки. Читатели vc.ru, TJ и DTF делятся на авторизованных пользователей и анонимов. Анонимы, как правило, приходят из самых разных каналов — соцсетей, поисковиков и так далее. У нас большой трафик как раз за счет них. Как правило такие пользователи приземляются на конкретную статью, а не на главную страницу с лентой новостей. Статьи редко сильно меняются после публикации, так что мы кэшируем страницу на некоторое время на уровне nginx и отдаем ее читателю целиком.

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

Под капотом, внутри серверов, у нас Kubernetes (перешли на него 3 года назад). Несмотря на то, что у нас не облачная инфраструктура и есть legacy в виде монолита, мы пользуемся контейнерами. С помощью них мы быстро запускаем и масштабируем сервисы, они позволяют нам следовать методологии CI/CD.

DevOps-специалистов в штате у нас нет. Обслуживание инфраструктуры мы отдаем на аутсорс. Инфраструктурой занимаются где-то 10-12 человек.

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

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

Для поддержки продуктов медиахолдинга («НАШЕ радио», Rock FM, «Радио Jazz», интернет-станция «Радио Ultra», информационное агентство «Национальная служба новостей») мы используем как выделенные, так и облачные серверы. На выделенных серверах в дата-центрах Selectel мы хостим наши сайты и приложения. Пул серверов в интранете обеспечивает работу нашего информационного агентства и вещание радиостанций (все интернет вещание, естественно, через CDN).

Некоторые сервисы, поддерживающие наши продукты, работают в облаке и достаточно нетребовательны — здесь мы выбираем VDS by Selectel, доступные виртуалки.

Под большие проекты стараемся выделять отдельные серверы. Например, для фестиваля НАШЕСТВИЕ мы строим локальный дата-центр в поле, с серверами Selectel. Обязательно как-нибудь снимем видео, как это выглядит. Серверы обеспечивают работу билетной системы и множества других сервисов собственной разработки Мультимедиа Холдинга. Система организации продажи билетов на фестиваль также работает на физических серверах.

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

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

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

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

Кроме того, в пандемию мы занялись автоматизацией бизнес-процессов в компании — понадобилась реорганизация с точки зрения инфраструктуры, чтобы обеспечить бесперебойную работу, в том числе удаленную.

Сейчас все приложения компании находятся в зарубежном облаке и управляются через Kubernetes. В облако мы ушли в связи с ростом онлайн-трафика и вектором на диджитал-развитие. Основные базы данных медиахолдинга развернуты в облаке, но бэкапы храним на серверах Selectel.

Здесь же арендуем мощный сервер для аналитики и CDN для всего трафика. На «аналитическом» сервере у нас развернут ClickHouse, который собирает действия пользователей и агрегирует всю статистику. Аналитика нужна для более гибкой автоматизированной рекомендации контента, в том числе рекламного.

Объединение инфраструктуры двух провайдеров, российского и зарубежного, в одну системы — это не тривиальная задача. Самым важным для нас было обеспечить высокую скорость и надежность передачи данных. Кроме того, в будущем Independent Media планирует внедрять системы машинного обучения для обработки данных — потребуется особо быстрая передача данных между базами данных на выделенных серверах Selectel и облаком зарубежного вендора.

Для сетевой связности мы выбрали услугу Global Connect c полосой трафика 300 Мбит/c. Помимо высокой скорости, мы получили независимость от возможных сбоев каналов публичного интернета и защиту от последствий массовой блокировки IP-адресов. Выделенные сетевые каналы подобные проблемы не затрагивают.

#selectel #медиа #инфраструктура #cерверы