Как веб-сервису масштабироваться при взрывном росте трафика без боли: кейс 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?
Мы приступили к поискам поставщика, но, как оказалось, есть особенности, которые усложняли выбор.
Первый этап ускорения: переезжаем в распределенное облако из ЦОДа
Рост для масштабного сервиса всегда сопряжен с серьезными инвестициями в ИТ: если объемы передаваемого в сторону пользователей трафика растут, пропорционально растут и затраты на закупку дополнительных серверов и другой инфраструктуры. Чтобы все это внедрить и поддерживать, нужны руки и головы - а это уже более высокие эксплуатационные издержки на найм дополнительных ИТ-кадров, аренду стоек в ЦОДе и так далее. В этот момент обычно как раз приходит осознание: “Кажется, мы доросли до CDN”.
До этого у нас была своя собственная “микро-CDN” в одном датацентре. На самом деле, это были несколько серверов, которые делили между собой растущую нагрузку. Наш датацентр располагался в Германии, и удаленность узла от конечных пользователей, разбросанных по всей России и нескольким странам СНГ, создавала риск, что мы не сможем обеспечить высокую скорость загрузки. На практике в часы пиковой нагрузки мы испытывали проблемы с доступом. Поэтому нам определенно не подходила модель централизованной сетевой инфраструктуры - нужна была географически распределенная.
По каким критериям мы выбирали CDN-провайдера?
На рынке представлено множество поставщиков - от локальных игроков до крупных международных корпораций, но как только мы стали сопоставлять предложения с нашими критериями, выбор значительно сузился. Вот основные критерии, которые были важны для нас):
Динамическая оптимизация маршрута до пользователя
Наша аудитория распределена по всей стране и даже за ее пределами, поэтому нам нужно было предусмотреть оптимальные маршруты для доставки контента.
Стоимость передачи бита
Мы рассматривали решения как крупных зарубежных вендоров, так и локальных. При сотрудничестве с первыми, учитывая, какими темпами рос наш веб-трафик, с увеличением объемов мы бы не увидели никакой экономической выгоды от своего роста из-за особенностей тарификации. Локальные вендоры предлагали очень выгодные расценки за бит, но у них был жесткий лимит по полосе пропускания в рамках тарифов. Масштабные всплески могли бы нивелировать всю выгоду от использования, либо нам бы пришлось снижать качество обслуживания пользователей. Мы искали вариант, при котором мы бы могли сэкономить на тарифицируемом ресурсе - пропускной способности.
Возможность кастомизации
Канал передачи данных — это уже давно коммодити, что объясняет постоянное удешевление передачи бита на протяжении нескольких лет. Нам же, помимо доставки контента, нужно было проводить ряд кастомизаций, учитывая архитектуру нашего приложения. Например, мы планировали справиться с проблемой воспроизведения видео в некоторых версиях Chrome, где при использовании протокола HTTP 2.0 в определенных версиях браузеров не загружался контент, и мы должны были реализовать загрузку по протоколу HTTP 1.1. Для нас подобные кастомизации потенциально означали дополнительный найм и разрастание команды разработки и эксплуатации - мы же хотели не раздувать штат и оставаться небольшой, но эффективной командой. То есть, было бы оптимально, если бы команда была со стороны поставщика, но это оказалось большой редкостью.
Выбор
В итоге мы остановились на NGENIX, так как, с одной стороны, они предоставляли географически распределенную облачную платформу с точками присутствия во всех федеральных округах, во-вторых, на платформе реализованы механизмы балансировки, который оптимизируют маршрут доставки трафика до конечного пользователя.
Также прилагалась сильная команда сопровождения: она работала с нами не только в плане технической поддержки, но и разрабатывала и развертывала кастомные функции сразу на облачной платформе.
Как внедряли?
У нас на сайте много картинок, и их количество только растет, так как методологи и контент-редакторы постоянно разрабатывают новые уроки и тесты.
Мы начали миграцию с перевода статики в облако. Вот пара важных лайфхаков, если вы переводите высоконагруженный сервис на инфраструктуру облачного провайдера:
Итак, мы перевели статику в облако и, хотя мы не замеряли эффект до и после, было очевидно, что проблемы доступности исчезли, даже при росте трафика. Нам не пришлось закупать и развертывать дополнительные сервера: так как облако эластичное, у тебя всегда есть план Б, если произойдет большой скачок запросов.
Вторым этапом, раз наш ресурс уже подключен к облачной инфраструктуре, мы решили перевести в облако передачу видео: одно дело нажать одну кнопку в личном кабинете, другое дело - значительно расширять собственную инфраструктуру, поэтому через подключение этого дополнительного сервиса мы смогли оптимизировать издержки.
Никогда такого не было, и вот опять
Мы уже увидели эффект от использования распределенного облака, и все работало прекрасно, но тут еще начался Ковид. Люди сели на удаленку и начали думать, как с пользой провести высвободившееся от дороги в офис или развлечений время: практически все образовательные сервисы испытали значительный рост трафика, на который и не рассчитывали.
Некоторые из наших коллег по отрасли наблюдали кратный рост нагрузки на ИТ-инфраструктуру и временами испытывали проблемы с доступом под возросшим количеством запросов. Хотя мы ни разу не столкнулись со сбоями, было очевидно, что следующее бутылочное горлышко в масштабировании сервиса не за горами. Мы начали искать решение, как снизить нагрузку и ускорить загрузку страниц при росте количества обращений.
Второй этап ускорения: оптимизация изображений в облаке
Из-за бурного роста во время Ковида (за март объемы передаваемого трафика у нас увеличились в 2,7 раза) мы запланировали общую оптимизацию платформы, и в рамках этих мероприятий решили озаботиться нашим огромным каталогом изображений. Эти изображения тяжелые, это влияет на скорость загрузки веб-сайта. При росте количества обращений масштаб проблемы также растет.
Что мы имеем? Сотни тысяч изображений. И чем больше разрастается этот каталог, тем сложнее обучать контент-редакторов, к тому же требуется организовывать новый процесс контроля качества от создания контента до выкатки в продакшен. Оптимизировать этот “фотобанк” своими силами мы бы не взялись — это слишком сложно и ресурсоемко.
Потенциально снизить объемы передаваемого в сторону пользователей трафика могла бы конвертация форматов PNG и JPEG в более оптимизированный формат WebP от Google, который делает изображение в среднем на 40% легче – но тут есть свои сложности. Его поддерживают не все платформы (о поддержке WebP на iOS было объявлено только в июне 2020 года), то есть, если бы мы сконвертировали все изображения в WebP по умолчанию, у значительной доли пользователей веб-страницы отображались бы неправильно. Поэтому мы постоянно откладывали идею использования WebP и не могли к ней подступиться.
Решение
У NGENIX есть отдельный сервис, который можно подключить по запросу, не привлекая ресурсы ИТ-команды. Его основная фича в том, что платформа сама анализирует HTTP-заголовки запросов от пользовательских устройств и определяет, поддерживает ли устройство WebP. Если да, то запрашиваемое изображение асинхронно конвертируется на серверах преобразования в WebP и раздается на устройства в оптимизированном формате. Если не поддерживает - пользователю отдается изображение в оригинальном формате.
Результат оптимизации
После оптимизации скорость загрузки изображений выросла на 45% за счет того, что среднее время запроса к файлу изображений для мобильных платформ снизилось в 3 раза (до 1 мс), а для ПК-платформ - в 3,5 раза (до 6 мс).
В общем среднее время запроса сократилось на 40%. “Вес” передаваемых на устройства изображений также значительно снизился (более чем в 2,4 раза):
За счет этого в среднем на 48% сократились объемы трафика, который мы передаем на устройства пользователей.
Что это дало?
· Повышение общей отказоустойчивости сервиса без дополнительного капекса: при растущем количестве запросов объемы передаваемого трафика снизились почти вполовину, нагрузка на инфраструктуру снизилась
· Более высокая скорость загрузки веб-страниц - это меньше отказов: по сути, каждая секунда задержки свыше 3 секунд на конвертирующей странице повышает показатель отказов на 11%
· Ускорение загрузки веб-сайта для мобильных пользователей - скорость загрузки на мобильных устройствах во многом зависит от качества мобильной связи, а это может быть большой проблемой, особенно в регионах. Для нас это было важно, так как доля мобильных пользователей за два года выросла вдвое до 60%, притом большая часть нашей аудитории находится вне двух столиц
· Одинаковая доступность сервиса для всех пользователей вне зависимости от географического положения - все получают контент одинаково быстро. Для региональных мобильных пользователей есть свои бенефиты - вес страницы из-за использования WebP намного ниже, а значит, потребление мобильного интернета сокращается
· Возможность подключать сервисы по запросу в облаке избавляет нас от дополнительного найма в команды разработки и эксплуатации даже в условиях роста - с нашей стороны требуется минимальное вовлечение, многие функции на платформе могут осуществляться без внесения изменений в код силами администратора
· Прозрачность использования платформы - мы мониторим в реальном времени потребление трафика, всплески количества запросов, объекты, потребляющие канал связи, все довольно интуитивно.
Выводы
Мы очень вовремя решили использовать CDN, задолго до того, как рост нагрузки мог серьезно повлиять на доступность нашей платформы. Если ваш трафик растет экспоненциально, то рано или поздно большой капекс на собственную инфраструктуру может остановить рост прибыли, и CDN - очевидный выход в этом случае. Если география продаж расширяется, то это еще один довод в пользу распределенной инфраструктуры. Это то, что помогло нам достойно пережить Ковид.
При выборе CDN-провайдера мы руководствовались несколькими соображениями: гибкостью ценообразования и возможностью аутсорсинга части функций в облако, но это всегда индивидуально. В нашем случае мы оценивали выгоду предложения не по стоимости передачи бита, а по тому, во сколько нам обойдутся превышения при кратном увеличении объемов трафика, а также по стоимости необходимых кастомизаций и оптимизаций, так как найм программистов или девопсов в штат в большинстве случаев не успевает за темпами роста.