Цього тижня ми провели інтерв’ю з Зсотом Варгою, ведучим інженером та менеджером в Prerender.io. Він розповідає, як Prerender перейшов з AWS та зекономив $800 тис. , побудував свою власну внутрішню інфраструктуру для обробки трафіку та кешованих даних.

“Мета - зменшити витрати і зберегти при ту саму швидкість рендерингу та якість обслуговування клієнтів. Міграції, подібні до цієї, потребують ретельного планування, їх треба уважно виконувати. Неправильна конфігурація або погане проведення міграції призведе до збоїв у роботі веб-сторінок наших клієнтів та користувачі не зможуть потрапити до них з реклами з соц мереж, погрішиться СЕО-оптимізація і в результаті ми втратимо частину наших клієнтів.”

Найцікавіша технічна проблема, з якою зіткнувся Prerender

Prerender кешує та попередньо відрендерює ваші сторінки JavaScript, щоб пошукові системи могли індексувати чистий HTML. Щоб цим скористатись потрібно встановити їх middleware у себе на сайті. Це дозволяє швидко та безболісно заставити Google проіндексувати динамічно згенерований джаваскріптом контент.

Однак усі ці процеси пререндерингу повинні відбуватися у нас на сервері, і, звичайно, ми використовували AWS для цього. Кілька років зростання і ми обробляємо понад 70 000 сторінок на хвилину, зберігаємо близько 560 мільйонів сторінок і платимо понад 1 000 000 доларів на рік.

Або принаймні ми б платили так багато, якщо залишалися з AWS. Але замість цього ми змогли зменшити витрати на 80% за трохи більше 3 місяців завдяки деякому нестандартному мисленню та чіткому плану. Ось як нам це вдалось.

Планування міграції: Наш покроковий посібник

До недавнього часу Prerender зберігав на Amazon Web Services (AWS) сторінки, які він кешував і відрендерював для своїх клієнтів. AWS був одним з найбільших провайдерів хмарних послуг, він пропонує віртуальні сервери та сервіси.

До цього часу Prerender зберігав сторінки на AWS, він кешував їх, щоб вони були вже відрендерені коли їх хоче прочитати Google, Facebook або будь-який інший бот/павук, який шукає контент для індексації. Функціонал Prerender — доставка статичного HTML до Google та до інших пошукових систем. І доставка динамічного, інтерактивного JavaScript до людей.

В чому проблема? Зберігання кількох терабайтів попередньо відрендерених веб-сторінок таким чином на сервері стороньього сервісу є дуже дорогим. Зберігання кешованих сторінок таким чином коштувало Prerender астрономічних сум лише на хостинг.

Але була ще одна підступна деталь, про яку не багато стартапів думають наперед, і навколо якої не ведеться багато розмов: вартість трафіку.

Ми вирішили мігрувати кешовані сторінки на наші власні внутрішні сервери Prerender, щоб якнайшвидше зменшити нашу залежність від AWS. Тоді трафік до нас буде коштувати набагато дешевше, ніж трафік до AWS.

Коли ми розрахували витрати, ми зрозуміли, що можемо зменшити витрати на хостинг на 40%. Ми вирішили, що міграція сервера зекономить гроші як Prerender, так і наших клієнтів.

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

Постійне та систематичне тестування такої міграції відбувалося протягом тижнів та навіть місяців.

Переміщення Prerender з AWS: щотижневий огляд

Фаза 1 — Тестування (4-6 тижнів)

Фаза 1

В основному включала встановлення серверів на голому металі та тестування міграції в невеликому та більш керованому середовищі перед масштабуванням. Ця фаза вимагала мінімальної адаптації програмного забезпечення, яку ми вирішили запустити на віртуалізації KVM на Linux.

На початку травня перша партія серверів працювала, і 1% трафіку Prerender було спрямовано на нові сервери. Через два тижні після міграції ми вже економимо $800 на день. До кінця місяця ми перенесли більшість робочих навантажень трафіку з AWS, зменшивши щоденні витрати на робочі навантаження рендерингу хрому на 45%.
На серверному боці наші витрати наразі становлять $13K на місяць. Завдяки AWS ми вже скоротили наші витрати на 22%.

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

Завдяки нашому постійному моніторингу та чіткій комунікації, тести були успішними, наші прогнози щодо економії перевищили очікування, і все було готово для початку другої фази міграції.

Фаза 2 — Технічна настройка (4 тижні)

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

Коли міграція досягла середини червня, у нас було 300 серверів, які працювали дуже плавно, з загальною кількістю 200 мільйонів кешованих сторінок. Ми використовували вузли Apache Cassandra на кожному з серверів, які були сумісні з AWS S3.

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

Однак велике розкриття відбулося в кінці цієї фази близько 24 червня. Протягом останніх чотирьох тижнів ми перенесли більшість робочого навантаження кешу з AWS S3 на наш власний кластер Cassandra. Щоденна вартість AWS була зменшена до 1,1 тис. доларів на день, що прогнозувалося на 35 тис. доларів на місяць, а щомісячна повторювана вартість нових серверів була оцінена приблизно в 14 тис. доларів.

На цей момент на S3 все ще залишалося кілька залишків, які коштували приблизно 60 доларів на день і природним чином повністю вимруть за кілька тижнів. Хоча ми могли б вивести всі дані, щоб відразу їх обрізати до нуля, це залишило б у нас одноразове “грошове марнотратство” в розмірі $5K на виведення даних з AWS.

Переміщення даних — це те, де ви почнете зіштовхуватися з великими проблемами. Словами нашого нового головного технічного директора (Золт Варга):

“Справжня прихована ціна за AWS приходить від вартості трафіку, вони продають досить дешеве сховище, і навіть безкоштовно його завантажувати. Але коли ви виводите його, ви платите величезну ціну.

Малі стартапи часто не розраховують вартість трафіку, навіть якщо він може становити 90% їх рахунку”

Наприклад, якщо ви знаходитесь в регіоні US West(Oregon), вам доведеться витратити $0.080/GB, тоді як в регіоні Asia Pacific (Seoul) ця цифра зростає до $0.135/GB.

У нашому випадку це було легко близько $30k — $50k на місяць. До кінця другої фази ми знизили загальні щомісячні витрати на сервери на 41,2%.

Фаза 3 — Впровадження та масштабування (4–6 тижнів)

На цьому етапі міграція вже була в процесі і вже значно заощаджувала Prerender значну суму грошей. Єдине, що залишилося зробити, це було мігрувати всі інші дані на власні сервери. Цей крок включав переміщення всіх екземплярів Amazon RDS по шарах. Це була найбільш помилкова частина всього процесу, але оскільки значна частина даних вже була перенесена, будь-які перешкоди або затори не змогли би зруйнувати весь процес міграції.

Ось загальний погляд на цей останній етап процесу міграції:

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

У кінці міграція виявилася великим успіхом. Наші щомісячні витрати на сервер знизилися нижче нашої початкової оцінки на 40% до повних 80% до того часу, коли всі кешовані сторінки були перенаправлені.

Що ми вивчили

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

Що вас надихнуло на роботу над проблемою, яку вирішує Prerender?

Мене зацікавила ідея працювати на платформі, яка допомагає рухати веб вперед.

Бачите, з Prerender наші клієнти впроваджують веб-сайти, спрямовані на користувачів, і замість того, щоб концентруватися на SEO, вони надають найкраще для своїх клієнтів. Протягом останніх років, кожного разу, коли ми створювали нову лендінг-сторінку, ми завжди використовували WordPress лише для отримання найкращого SEO та залишали можливості SPA лише для неіндексованих сторінок, таких як секція адміністрування. Але зараз я працюю в компанії, яка допомагає вирішувати проблеми, які стримували мене в минулому ^.^

Який технологічний стек ви використовуєте і чому ви вибрали цей стек?

Ми використовуємо Javascript скрізь, оскільки ми вирішуємо “проблеми”, викликані рендерингом Javascript, ми хочемо набути якомога більше експертизи в цій галузі. Але для інших частин ми використовуємо розподілену систему CloudFlare для швидкого реагування та глобальної масштабованості. Хоча наші гарантії часу роботи підтримуються хмарною платформою Digital Ocean. Ми також використовуємо безліч інших постачальників SaaS, щоб максимізувати нашу ефективність.

Яким буде світ, коли ваша компанія досягне своєї мети?

Коли постає питання “Чи можемо ми використовувати React для нашого нового сайту?” відповідь буде “Звісно!”, оскільки зараз відділи маркетингу завжди ветують все, що може знизити рейтинг SEO. Я б сказав, заслужено. Щодо наших клієнтів, навіть якщо вони втрачають 1% ефективності, їм доведеться збільшити бюджет на рекламу на сотні тисяч доларів.

Як виглядає типовий день для вас?

Ха-ха, багато дзвінків від клієнтів! Оскільки ми прагнемо тримати нашу віддану команду малою і ефективною, я частіше, ніж не, беру участь у вступних дзвінках з ними. Але це весело для мене! Я завжди любив спілкуватися з клієнтами, дізнаватися про їхню ситуацію і говорити про рішення. Це дуже спрощує мою роботу, оскільки нам не потрібно придумувати ідеї, наші клієнти розповідають нам все, що нам потрібно знати. І я вважаю, що це найкращий вид ситуації, коли ви орієнтовані на клієнта, і мій KPI - це кількість задоволених клієнтів.

Опишіть ваше обладнання для комп'ютера

Ой, це варто статтю саму по собі. Я дещо занудний, і у мене вдома є 8 відданих серверів, хоча я в основному працюю на своєму macbook для зручності. Але коли я маю час для програмування, я запускаю свою “робочу станцію”, на якій працює Manjaro. Але рідко, коли я отримую трохи вільного часу, я таємно вмикаю свій комп’ютер з Windows для гри. І на момент написання я оточений ноутбуками, малинами та планшетами.

Побудова машин та проведення масштабованих тестів — моє захоплення пізно вночі.

Опишіть ваше програмне забезпечення для комп'ютера

VSCode — це остаточне рішення для мене, я не дуже захоплений жодною мовою програмування, і він дає мені можливість просто встановити розширення та писати код, підтримуваний IDE, за кілька секунд. Також, я мав щастя бути в бета-групі для CoPilot, і це визначено змінює гру.

Для контролю версій GitHub - це круто, але я б ніколи не відкидав інші рішення. GitLab став дуже крутим інструментом в останні роки.

Щодо месенджерів, я думаю, що Slack все ще є найпоширенішим професійним вибором, і оскільки він відмінно справляється зі своєю роботою, немає причин переходити на інший месенджер. Але недавно я виявив дуже цікаве програмне забезпечення під назвою Spike, і протягом останніх 3 місяців я використовував його як свій фактичний поштовий клієнт, оскільки воно робить розмови по електронній пошті набагато простіше.

Необхідні інструменти: Docker, іншого шляху немає, він змінив галузь на краще. Я все ще пам'ятаю темні старі часи, коли нам доводилося встановлювати залежності та вирішувати конфлікти пакетів…
Але так, Kubernetes повільно досягає того ж рівня адаптації.

Чи є у вас якісь поради для програмістів, які тільки починають?

Не бійтеся спілкуватися з клієнтами. Протягом усієї моєї кар'єри найкращі інженери-програмісти були ті, хто співпрацював з клієнтом для вирішення їх проблем. Іноді ви можете зекономити півроку часу розробки, просто дізнавшись, що можете вирішити проблему клієнта за допомогою одного рядка коду. Я вважаю, що кращі інженери створюють рішення для реальних проблем.

Ви наймаєте і на які посади?

Завжди! Ми завжди прагнемо наймати тільки тоді, коли ми можемо забезпечити, що наші нові колеги матимуть значущу роль і вони зроблять визначний внесок. Але наразі ми вже настільки великі, що нам потрібно розширювати нашу команду в кожному відділі. Тож, замість того, щоб перераховувати, просто перегляньте нашу сторінку кар'єри 😀 https://saas.group/career

Де ми можемо дізнатися більше?

Зайдіть на наш сайт за адресою prerender.io і якщо вас цікавить провести дзвінок зі мною щодо попереднього рендерингу і як це змінює веб, зв'яжіться зі мною за електронною поштою за адресою [