Как веб-сервису масштабироваться при взрывном росте трафика без боли: кейс Puzzle English

Системный архитектор онлайн-сервиса изучения английского языка Puzzle English Кирилл Косенков рассказал в нашем блоге о том, как небольшая команда, создавшая сервис глобального уровня, выбирала CDN, переезжала в облако и искала нестандартные способы ускориться на фоне роста трафика - и все это с учетом коронакризиса.

Рынок онлайн-образования на подъеме: развиваются edtech-платформы, венчур инвестирует в новые проекты, а российские игроки ищут новую аудиторию за рубежом и планируют агрессивную экспансию.

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

Рост - это круто, да?

Puzzle English входит в мировой топ-3 среди приложений для изучения английского языка по оценкам пользователей. Один из основных драйверов успеха - фокус на качестве контента: разработчики и профессиональные методисты-лингвисты создали более 20 уникальных тренажеров для развития всех основных языковых навыков. С каждым месяцем количество контента на платформе увеличивалось.

Увеличивался и охват аудитории: только за последний год, с июня 2019 года по июнь 2020 года, база пользователей выросла на 19% до 8,7 млн человек, а число активных пользователей - до 3 млн. Несмотря на кратный рост, мы не раздували штат - количество людей в команде до сих пор не превышает 50 человек.

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

...но есть нюанс

Мы начали опасаться, что в моменты пиковой нагрузки платформа не сможет обслужить запросы всех посетителей. Кроме того, за два последних года произошло резкое увеличение трафика с мобильных устройств: если раньше доля мобильного трафика составляла около 30%, в 2020 году она составляла уже более 60%. Из-за того, что большую часть контента Puzzle English составляют “тяжелые” изображения, веб-сайт, в том числе ключевые конвертирующие страницы, высоконагружен, и показатели скорости загрузки страниц и оттока на мобильных устройствах из-за этого были хуже, чем на десктопах. Эта проблема усугублялась тем, что 70% пользователей находятся в регионах, где скорость мобильного соединения может быть низкой, а покрытие - нестабильным.

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

Как понять, что вам нужен CDN?

1. Ваша аудитория географически распределена

2. У вас много “горячего” контента, для кэширования и преобразования которого нужны мощные дорогостоящие сервера

3. Для вашего веб-ресурса характерны кратковременные, но масштабные всплески посещаемости

4. Растут объемы передаваемого трафика, под которые нужно наращивать инфраструктуру

Мы приступили к поискам поставщика, но, как оказалось, есть особенности, которые усложняли выбор.

Первый этап ускорения: переезжаем в распределенное облако из ЦОДа

Рост для масштабного сервиса всегда сопряжен с серьезными инвестициями в ИТ: если объемы передаваемого в сторону пользователей трафика растут, пропорционально растут и затраты на закупку дополнительных серверов и другой инфраструктуры. Чтобы все это внедрить и поддерживать, нужны руки и головы - а это уже более высокие эксплуатационные издержки на найм дополнительных ИТ-кадров, аренду стоек в ЦОДе и так далее. В этот момент обычно как раз приходит осознание: “Кажется, мы доросли до CDN”.

Как устроен CDN

CDN - это географически распределённая сетевая и вычислительная инфраструктура, которая состоит из множества узлов, расположенных в различных локациях и подключенных к разным операторам связи. Исходные файлы хранятся на серверах оригинации; пользователи получают контент с кэширующих серверов (edge-серверов), а система балансировки трафика определяет, с какого edge-сервера лучше отдать запрашиваемый пользователем файл, основываясь на географическом положении и подключении юзера, топологии и состоянии сети, чтобы сделать время ответа для пользователей сайта/сервиса минимальным.

До этого у нас была своя собственная “микро-CDN” в одном датацентре. На самом деле, это были несколько серверов, которые делили между собой растущую нагрузку. Наш датацентр располагался в Германии, и удаленность узла от конечных пользователей, разбросанных по всей России и нескольким странам СНГ, создавала риск, что мы не сможем обеспечить высокую скорость загрузки. На практике в часы пиковой нагрузки мы испытывали проблемы с доступом. Поэтому нам определенно не подходила модель централизованной сетевой инфраструктуры - нужна была географически распределенная.

По каким критериям мы выбирали CDN-провайдера?

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

Динамическая оптимизация маршрута до пользователя

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

Стоимость передачи бита

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

Возможность кастомизации

Канал передачи данных — это уже давно коммодити, что объясняет постоянное удешевление передачи бита на протяжении нескольких лет. Нам же, помимо доставки контента, нужно было проводить ряд кастомизаций, учитывая архитектуру нашего приложения. Например, мы планировали справиться с проблемой воспроизведения видео в некоторых версиях Chrome, где при использовании протокола HTTP 2.0 в определенных версиях браузеров не загружался контент, и мы должны были реализовать загрузку по протоколу HTTP 1.1. Для нас подобные кастомизации потенциально означали дополнительный найм и разрастание команды разработки и эксплуатации - мы же хотели не раздувать штат и оставаться небольшой, но эффективной командой. То есть, было бы оптимально, если бы команда была со стороны поставщика, но это оказалось большой редкостью.

Выбор

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

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

Как внедряли?

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

Мы начали миграцию с перевода статики в облако. Вот пара важных лайфхаков, если вы переводите высоконагруженный сервис на инфраструктуру облачного провайдера:

1. Заведите отдельный домен третьего уровня для статики

Если этого не сделать, то при миграции в облако нужно привлекать дополнительный ресурс разработчиков для внесения изменений в код сайта. Если вывести статику на отдельный поддомен, то переключить его может команда эксплуатации через изменение записи в DNS. Также существуют ограничения браузера на количество подключений на один домен в случае использования HTTP/1.1. Так можно даже увеличить скорость загрузки веб-страниц, если, например, приложение использует уже не новый протокол HTTP/1.1, вы получите дополнительное ускорение.

2. Используйте заголовки кэширования. Всегда.

Если нет заголовков кэширования, то можно столкнуться с проблемой, когда, например, на edge-серверах кэшируется динамический контент, но статический не кэшируется. Кроме того, некоторые промежуточные прокси работают на устаревшем ПО и могут не знать всех директив или новых заголовков кэширования (например, Cache-Сontrol). Наконец, сайт может работать некорректно: возникает повышенная нагрузка на сервера оригинации, некорректно отображается контент. Если заголовки кэширования прописаны правильно, промежуточные прокси обрабатывают нужные директивы и при необходимости перезапрашивают нужный контент с сервера оригинации. Облачная платформа автоматически сориентируется, какой контент кэшировать, а какой - нет.

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

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

Неожиданный бонус:

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

Никогда такого не было, и вот опять

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

Трафик веб-ресурсов сегмента “Образование” с начала февраля по конец апреля 2020 года

Статистика: NGENIX
Динамика поисковых запросов "английский язык онлайн" Данные: Яндекс Wordstat
Рост интереса аудитории продолжается, и во втором "ковидном" квартале 2020 достигает максимума Данные: Яндекс Wordstat

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

Второй этап ускорения: оптимизация изображений в облаке

Из-за бурного роста во время Ковида (за март объемы передаваемого трафика у нас увеличились в 2,7 раза) мы запланировали общую оптимизацию платформы, и в рамках этих мероприятий решили озаботиться нашим огромным каталогом изображений. Эти изображения тяжелые, это влияет на скорость загрузки веб-сайта. При росте количества обращений масштаб проблемы также растет.

Что мы имеем? Сотни тысяч изображений. И чем больше разрастается этот каталог, тем сложнее обучать контент-редакторов, к тому же требуется организовывать новый процесс контроля качества от создания контента до выкатки в продакшен. Оптимизировать этот “фотобанк” своими силами мы бы не взялись — это слишком сложно и ресурсоемко.

Потенциально снизить объемы передаваемого в сторону пользователей трафика могла бы конвертация форматов PNG и JPEG в более оптимизированный формат WebP от Google, который делает изображение в среднем на 40% легче – но тут есть свои сложности. Его поддерживают не все платформы (о поддержке WebP на iOS было объявлено только в июне 2020 года), то есть, если бы мы сконвертировали все изображения в WebP по умолчанию, у значительной доли пользователей веб-страницы отображались бы неправильно. Поэтому мы постоянно откладывали идею использования WebP и не могли к ней подступиться.

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

Решение

У NGENIX есть отдельный сервис, который можно подключить по запросу, не привлекая ресурсы ИТ-команды. Его основная фича в том, что платформа сама анализирует HTTP-заголовки запросов от пользовательских устройств и определяет, поддерживает ли устройство WebP. Если да, то запрашиваемое изображение асинхронно конвертируется на серверах преобразования в WebP и раздается на устройства в оптимизированном формате. Если не поддерживает - пользователю отдается изображение в оригинальном формате.

Сервис Image Optimization прошел апгрейд в сентябре: теперь платформа, помимо конвертации в WebP, может автоматически производить ресайзинг изображений, чтобы раздавать конечным пользователям изображения в определенном формате - под различные форм-факторы экранов. Картинки можно сжимать, кропить, задавать параметры длины и ширины - для этого администратору нужно настроить несколько профилей изображений и привязать их к системной конфигурации в личном кабинете.

Результат оптимизации

После оптимизации скорость загрузки изображений выросла на 45% за счет того, что среднее время запроса к файлу изображений для мобильных платформ снизилось в 3 раза (до 1 мс), а для ПК-платформ - в 3,5 раза (до 6 мс).

В общем среднее время запроса сократилось на 40%. “Вес” передаваемых на устройства изображений также значительно снизился (более чем в 2,4 раза):

За счет этого в среднем на 48% сократились объемы трафика, который мы передаем на устройства пользователей.

Что это дало?

· Повышение общей отказоустойчивости сервиса без дополнительного капекса: при растущем количестве запросов объемы передаваемого трафика снизились почти вполовину, нагрузка на инфраструктуру снизилась

· Более высокая скорость загрузки веб-страниц - это меньше отказов: по сути, каждая секунда задержки свыше 3 секунд на конвертирующей странице повышает показатель отказов на 11%

· Ускорение загрузки веб-сайта для мобильных пользователей - скорость загрузки на мобильных устройствах во многом зависит от качества мобильной связи, а это может быть большой проблемой, особенно в регионах. Для нас это было важно, так как доля мобильных пользователей за два года выросла вдвое до 60%, притом большая часть нашей аудитории находится вне двух столиц

· Одинаковая доступность сервиса для всех пользователей вне зависимости от географического положения - все получают контент одинаково быстро. Для региональных мобильных пользователей есть свои бенефиты - вес страницы из-за использования WebP намного ниже, а значит, потребление мобильного интернета сокращается

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

· Прозрачность использования платформы - мы мониторим в реальном времени потребление трафика, всплески количества запросов, объекты, потребляющие канал связи, все довольно интуитивно.

Выводы

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

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

0
Комментарии
-3 комментариев
Раскрывать всегда