Припустимо, що ви керуєте стартапом або компанією, тісно пов’язаною зі зберіганням даних. Досить тісно, ​​щоб левова частка ваших витрат — до 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 Kernel-based Virtual Machine Linux.

На початку травня було запущено першу партію серверів, і на нові сервери було направлено 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% до того часу, коли всі кешовані сторінки були перенаправлені.

При міграції серверу багато поставлено на карту. Якщо щось піде не так чи відстане від графіка, то це принесе великі проблеми. Ось чому ми подбали про реалізацію відмовостійких систем на кожному етапі міграції — щоб мати можливість відступити, якщо щось піде не так. Саме тому ми провели невелике тестування, перш ніж розпочати решту міграції.

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