Представим, что вы управляете стартапом или компанией, тесно связанным с хранением данных. Достаточно тесно, что львиная доля ваших трат — до 90%, — составляла оплата хранения этих данных сторонним облачным сервисам.  С подобной проблемой столкнулась компания Prerender.io, которая ежегодно отдавала около $1 млн Amazon Web Services.

Prerender — сервис, который помогает сайтам JS лучше взаимодействовать с поисковиками вроде Google и улучшает их продвижение (это нужно интернет магазинам, блогам, СМИ и т.д.). Как рассказал в интервью технический руководитель и генеральный менеджер проекта Золт Варга, его компания сэкономила 800 тысяч долларов, избавившись от зависимости от AWS в пользу создания собственной инфраструктуры для обработки трафика и кэшированных данных.

Мы выбрали главное из его рассказа.

Какую проблему решала компания

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

Однако все эти данные и процессы должны происходить на сервере, и, конечно же, мы пользовались услугами AWS — крупнейшего облачного провайдера. В чем была проблема? Хранение нескольких терабайт предварительно обработанного содержимого веб-страниц обходилось в астрономические суммы денег только за обслуживание и плату за хостинг.

Спустя несколько лет роста мы обрабатываем более 70 000 страниц в минуту, храним около 560 миллионов страниц — за это AWS пришлось платить более $1 млн в год. Если бы мы им пользовались. Вместо этого мы смогли сократить расходы на 80% чуть более чем за три месяца благодаря нестандартному подходу и четкому плану.

Планирование миграции: почему это важно

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

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

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

План переноса данных с AWS

Этап 1 — тестирование (от 4 до 6 недель)

Фаза №1 в основном включала настройку серверов без операционной системы и тестирование миграции на небольшой и более управляемой установке перед масштабированием. На этом этапе потребовалась минимальная адаптация программного обеспечения, которую мы решили запустить на виртуализации KVM Linux (Kernel-based Virtual Machine).

В начале мая была запущена первая партия серверов, и на новые серверы был направлен 1% трафика Prerender. Через две недели миграции мы уже экономили $800 в день. К концу месяца перенесли большую часть рабочих нагрузок трафика с AWS, сократив ежедневные затраты на рендеринг Chrome на 45%.

На стороне сервера наши затраты в тот момент составляли $13 тысяч в месяц. То есть, в сочетании с использованием AWS, расходы уже были на 22% ниже.

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

Этап 2 — техническая настройка (4 недели)

Реализация второго этапа в основном заключалась в переносе кэш-хранилища на «голые» серверы. Спустя 6 недель после начала миграции, у нас было 300 серверов, которые работали очень гладко с общим объемом кэшированных страниц 200 миллионов. Мы использовали узлы Apache Cassandra на каждом из серверов, совместимых с AWS S3.

Мы разбили онлайн-миграцию на четыре этапа с разницей в неделю или две. Проверив, можно ли кэшировать страницы Prerender как в S3, так и в minio, мы постепенно перенаправили трафик с AWS S3 на minio. Когда запись в S3 была полностью остановлена, Prerender экономил $200 в день на затратах на API S3. В тот момент мы были готовы начать удаление данных, кэшированных в нашем кластере Cassandra.

Однако большое открытие произошло в конце этой фазы, когда мы перенесли большую часть рабочей нагрузки кэша с AWS S3 на наш собственный кластер Cassandra. Ежедневная стоимость AWS снизилась до $1,1 тысяч в день, прогнозируя $35 тысяч в месяц, а ежемесячная регулярная стоимость новых серверов оценивалась примерно в $14 тысяч.

На тот момент на S3 все еще были остатки данных, которые стоили около $60 долларов в день и полностью исчезли естественным образом через несколько недель. Хотя мы могли бы переместить все данные, чтобы немедленно сократить плату до нуля, это стоило бы нам $5 тысяч платы за перенос данных из AWS.

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

Этап 3 — внедрение и масштабирование (от 4 до 6 недель)

На этом этапе миграция шла полным ходом и уже сэкономила сервису значительную сумму денег. Осталось только перенести остаток данных на родные сервера. Этот шаг включал перемещение всех инстансов Amazon RDS сегмент за сегментом. Это часть процесса, где больше всего вероятны ошибки, но, поскольку значительное количество данных уже было перенесено, любые сбои или узкие места не привели бы к сбою всей миграции.

Вот общий вид этого последнего этапа процесса миграции:

• зеркалировали осколки PostgreSQL, хранящие таблицы cached_urls в Cassandra;
• переключили service.prerender.io на балансировщик нагрузки Cloudflare, чтобы обеспечить динамическое распределение трафика;
• настроили новые серверы приватного кэширования в ЕС;
• продолжили проводить стресс-тесты, чтобы решить вероятные проблемы с производительностью.

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

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

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