RAID: Shadow Legends у хмарі: як ми перевезли гру зі 100 млн гравців за 45 хвилин
Привіт. Я Олександр Коваленко, Global Director of Infrastructure Operations Department у Plarium. У цьому матеріалі я поділюся, як нашій команді вдалося за 45 хвилин перенести сервери RAID: Shadow Legends у нову інфраструктуру Google Cloud Platform.
У RAID: Shadow Legends грає понад 100 млн користувачів, понад 1 млн — щоденно. Для них це був звичайний день, як ми й хотіли. Але підготовка до нього тривала майже пів року. До процесу перенесення даних на різних етапах залучили понад 35 фахівців, а тести й підготовчі роботи тривали місяцями.
Це історія про неочевидну складність, нові технології, plan vs reality та гру проти часу.
Чому ми переносили RAID у хмару
Ще з 2011 року, коли вийшла одна з перших ігор компанії Total Domination, ми розгортали продакшн-сервер у невеликому дата-центрі в США. На той час це було компромісне рішення з погляду вартості й місця розташування інфраструктури. Хостинг стабільно працював довгий час, хоча рідко, але ставалися типові для таких рішень нюанси. І якщо для маленьких проєктів, це типова історія, то з нашим розвитком і розвитком RAID, усе це створювало додаткові ризики.
Перші розмови про міграцію в безпечніше місце почалися ще у 2023 році. Тоді ми з командою зустрілися з інженерами Google: за їхнім попереднім оцінюванням, утілити таку ідею в життя було доволі складно.
Ми регулярно проводимо власні тести та постійно вдосконалюємо наші підходи. В 2023 році ми вирішили залучити стороннього підрядника, аби отримати зовнішній і незалежний відгук на це. За результатами попередня інфраструктура не передбачала чітких процедур відновлення у разі надзвичайних ситуацій, так званих disaster-сценаріїв у термінах управління ризиками. Події останніх років у світі стали додатковим стимулом для переосмислення нашого підходу до стабільності й безпеки інфраструктури.
Ці ризики завжди існують у роботі, тому ми регулярно створювали резервні копії баз даних у хмарному середовищі. Водночас у разі відновлення частина даних, згенерованих між копіями, могла б бути недоступною — йдеться про незначні обсяги, але навіть вони мали значення для нас, особливо на такому великому проєкті, як RAID.
Після цього ми почали оцінювати варіанти. Уже на етапі планування стало зрозуміло, що найбільша складність полягатиме в перенесенні даних.
Пошуки шляхів міграції
Хіба складно перенести теку з файлами з локального диска до хмари? А тепер уявіть, що ці файли постійно перезаписуються, а зміни в одному файлі впливають на інший. Щосекунди до них звертаються користувачі в мережі, які засмутяться, якщо їхні апдейти файлів не враховуватимуться. І вишенька на торті — швидкість перенесення в хмару обмежена можливостями вашого старенького роутера Wi-Fi. Орієнтовно такий вигляд має завдання з міграції живої багатокористувацької гри.
Декілька слів про те, як виглядала інфраструктура RAID до міграції. Це були 11 серверів баз даних, кожен із яких містив 4 сегменти-бази. Також було 50 так званих воркерів — вебсерверів, що обробляли запити від клієнта. Загальний обсяг даних складав 15 терабайтів, трафік між воркерами й базами даних становив приблизно 8 гігабітів на секунду, ще до 2 гігабітів на секунду — зовнішній трафік до клієнтів.
Якби RAID: Shadow Legends був одиночною грою, усі ці дані можна було б умістити на п’ятнадцяти таких дисках і грати на одному надпотужному компі. Але головна особливість багатокористувацьких проєктів — це постійний обмін інформацією між гравцями та серверами й велика кількість запитів, які потрібно розраховувати щосекунди.
Які варіанти ми мали:
Варіант № 1. Обʼєднати у велику мережу-кластер поточні ігрові сервери й порожні бази даних у Google Cloud Platform та копіювати в них дані наживо. Ідея виглядала цікавою, але після детального аналізу ми вирішили зосередитися на більш оптимальних за співвідношенням цінності, складності й масштабованості рішеннях.
Варіант № 2. Переносити бази частинами. Для цього нам треба було мати дуже швидкий канал обміну даними: не більше ніж 4 мілісекунди затримки між різними частинами інфраструктури.
Ми знайшли найближчий дата-центр Google всього за 5 кілометрів від нашого хостингу, але в тестах отримали затримки
Єдиним робочим виявився варіант № 3. Поставити гру на паузу й перевезти всі дані за раз. Оцінка за першими тестами становила 6 годин даунтайму. 6 годин, коли гра буде недоступною у всьому світі. Уявіть масштаб події для проєкту з мільйонами гравців в усіх часових зонах.
Ми з командою пройшли всі 5 стадій від заперечення до прийняття, провели додаткові розрахунки й у лютому 2024 року пішли з усіма цифрами до команди розроблення RAID.
«Треба так треба», — кажуть вони. Подивилися roadmap, визначили найбільш сприятливий слот на кінець серпня. Зі свого боку ми обіцяли зробити все можливе, щоб зменшити час даунтайму. Так почалися наші перегони із часом.
Lift and Shift, або Як перевезти і не зламати хмарочос дорогою в хмару
Ми мали приблизно пів року, щоб спланувати та провести переїзд. Але мігрування такого проєкту — це як перевозити цілий хмарочос із паркінгом, трубами, кабелями, парком і кав’ярнею поблизу. Інфраструктура RAID містить не тільки сервери, а ще й купу додаткових залежностей: платформа для паблішингу Plarium Play, Game BI, сервіси команд Monetization & Game Services, а також маркетингова система GoGame. Тому ми почали з того, що стали складати схему поточної інфраструктури та схеми залежностей.
Ми почали збирати команди Monetization & Game Services, RAID Server, Game BI, ProdOps та Plarium Play на міти, щоб з’ясувати, наскільки глибоко всі ці компоненти пов’язані між собою, що можна розділити, а що треба переносити разом із RAID. Уже за декілька зустрічей зʼясувалося, що не все так складно, як здавалося. Разом із грою треба перевезти лише декілька додаткових сервісів.
Міграція даних — це завжди відповідальний процес. Розуміючи чутливість інфраструктури під час міграції, ми відмовилися від зайвих змін, аби мінімізувати ризики й забезпечити безперервність роботи. Тому на черговому мітингу зі стейкхолдерами я використав метафору з Lego Ferrari, яку бачив в офісі.
Як і ця машинка, наш проєкт не є монолітом і має купу зʼєднань, що можуть пошкодитися на нерівній дорозі. Так ми затвердили стратегію Lift and Shift, яка передбачає перенесення точної копії разом зі сховищем даних та операційною системою — із мінімумом cloud-friendly змін. Під час міграції ми мали розібрати половину проєкту й замінити деякі частини на хмарні сервіси від Google. Сам процес передбачав три етапи: бекап даних, перенесення до Google Cloud та відновлення.
Усе ще поставало питання, як пришвидшити переїзд. Для повної підготовки ми домовилися з Google, і нам виділили окрему команду з трьох інженерів. Наш Production Operations Administrator почав працювати в цьому напрямку й разом із командою долати виклик за викликом.
Спочатку сервери баз даних нагадували спорткар із прив’язаними до коліс гирями:
Зображення згенероване ШІ
Мережа стала швидкою, але тепер диски не встигали обробляти запити. Додали SSD, кешували бази — швидкість зросла. Але коли всі сервери одночасно вирішили «залити» дані в Google Cloud, хостинг поскаржився на утилізацію всієї доступної пропускної спроможності. Довелося розподілити процес у часі й узгодити все так, щоб не було сюрпризів.
Результати тестів показали, що значно швидше розбивати дані на декілька блоків та завантажувати їх у Google паралельно. Але в такому разі процес ускладнювався, бо робити це треба було синхронно для 40 баз на 10 серверах, що передбачало складні скрипти й оркестрацію всього процесу.
Міграція — це як ремонт дороги: що довше триває, то більший затор утворюється. Тому ми вирішили, що спочатку переносимо основний обсяг, а потім додаємо лише оновлення, які з’явилися за цей час (так званий диференціальний бекап). Google запропонували свій Data Migration Service. Це рішення мало великий потенціал, і наша команда доклала зусиль, аби самостійно протестувати й адаптувати його до потреб проєкту, але на той час він не підтримував диференціальні бекапи.
Ми намагалися це обійти, але виходило щось на кшталт «по ложці пити океан», бо під час гри запис до бази відбувається так інтенсивно, що за 6 годин даунтайму ми отримали б до 60% нових даних. На щастя, на черговому мітингу Google повідомили, що в альфі вже є підтримка диференціальних бекапів.
Хоча рішення ще не мало повної документації чи тестової бази, ми оцінили його потенціал, провели власну валідацію. Ми взяли на себе тестування, провели верифікацію — і таки реалізували сценарій, який раніше здавався малоймовірним. Наша команда дослідила можливості інструменту, швидко адаптувала його під потреби проєкту та успішно інтегрувала в міграційний процес. Це дало нам важливий досвід роботи з інноваційними інструментами ще на ранніх етапах їх розвитку.
Ресурси в Google теж мали обмеження. Конфігурація для стабільної роботи проєкту й конфігурація для відновлення даних у разі переїзду дуже різняться. Під час міграції кожна хвилина була на вагу золота, тому ми взяли вчетверо потужнішу й дорожчу конфігурацію серверів баз даних CloudSQL, щоб пришвидшити відновлення даних, а потім оптимізували.
За півтора місяця до. Перша спроба
Фінальну дату переїзду ми призначили на 16 вересня, а на 1 серпня запланували майже повноцінну тестову міграцію, яка передбачала всі етапи, крім останнього — перемикання трафіку гравців із поточного хостингу до Google Cloud Platform. Цей пункт у нас уже був перевірений та автоматизований через Cloudflare API — сервіс, який допомагає керувати трафіком. За тиждень до цього ми протестували пререлізну версію Data Migration Service (DMS) від Google із диференціальними бекапами й підтвердили її працездатність.
Якщо коротко, план був у тому, щоб перевезти всі дані, заміряти час кожної операції та попросити QA-команди RAID перевірити працездатність гри в Google Cloud Platform. Якщо детально:
- запустити повний бекап даних, не вимикаючи гру;
- перенести бекап до Google та розгорнути на хмарних базах даних;
- вимкнути гру, щоб не надходили нові дані;
- зробити бекап різниці, яка накопичилась під час попереднього етапу;
- перенести цю різницю до Google, додати до наявних даних і запустити базу;
- увімкнути ігровий кластер і перевірити працездатність гри.
Такий вигляд мав розписаний похвилинно план міграції. Усі операції треба було робити паралельно й синхронно для 41 бази.
Результати потішили. Гра успішно запустилася, QA-команда RAID перевірила функціональність. Даунтайм — час, коли гра мала бути вимкнена, — склав усього 33 хвилини. Якщо порівнювати із шістьма годинами первинного оцінювання, це був неймовірний результат.
Під час перенесення даних сумарна пропускна здатність досягла 41 гігабіта на секунду. Навіть для хостингової компанії, з якою ми тоді працювали, це були приголомшливі цифри. Ми поділилися результатами зі всіма залученими командами Plarium і Google та почали готуватися до остаточного переїзду.
Завжди має бути план Б
Ще однією сірою зоною для нас була потужність ресурсів у Google, бо важко порівнювати фізичні сервери з хмарними віртуальними машинами та інстансами-екземплярами баз даних. Разом із серверною командою ми зробили декілька синтетичних SQL-тестів навантаження, але реальні умови можуть створити лише гравці.
Нам був потрібен план повернення до хостингу, якщо виникнуть проблеми з продуктивністю хмарної інфраструктури. Імовірність такого сценарію була дуже низькою, але в нас мав бути план Б. За попереднім оцінюванням, процедура становила 4 години. На жаль, у такому разі ми не могли перевезти левову частку даних наживо, не вимикаючи гру.
Під час чергової дискусії з командами народилася ідея не вмикати білінг одразу після переїзду, бо саме відновлення платежів та нарахування ресурсів є найскладнішою частиною. План полягав у тому, щоб запустити гру в хмарі й подивитися, яке навантаження створять гравці за 30 хвилин.
Якби виникли суттєві проблеми, ми могли б оперативно перемкнутися на копію гри на хостингу. У такому разі прогрес у грі за цей короткий період міг би не зберегтися, проте вдалося б уникнути можливих непорозумінь щодо придбань, забезпечивши коректне оброблення всіх транзакцій після стабілізації системи.
16 вересня. Міграція
Команда нервувала, усі хотіли бачити кожен крок. У мене навіть була ідея перемкнути гравців під час чергового тесту, який ми зробили на початку вересня, щоб ще раз перевірити всі етапи. До речі, тест теж пройшов добре, ми отримали ті самі цифри. Тоді можна було б сказати: «Розслабтеся, ми вже 2 тижні як працюємо в Google», — але, звісно, ніхто б так не ризикував.
Ми вирішили розгорнути всю потрібну для продакшну інфраструктуру заздалегідь, аби впевнитися, що нам буде достатньо серверів. Також ми планували використовувати дуже потужні ресурси, щоб пришвидшити міграцію і мати запас, та не розуміли, як вплине реальне навантаження. Потужні ресурси, багато серверів, розвертання інфраструктури за декілька днів до міграції для тестів — це було дорого, проте якщо не інвестувати в надійність процесу, ми ризикували втратити більше. Одразу після переїзду в нас була запланована оптимізація ресурсів.
16 вересня о 9:30 ранку за Києвом ми почали підготовчі заходи. Даунтайм у грі був оголошений на одну годину з 13:30. Усе пройшло чітко за планом, уже через 45 хвилин ми увімкнули гру в хмарі. Віртуальні сервери чудово тримали навантаження, і ми попросили команду Monetization & Games Services увімкнути білінг.
Протягом дня ми запитували ще два коротких мейнтененси на 15 хвилин, щоб оптимізувати витрати на ресурси. Завдяки тому, що вся інфраструктура була розгорнута на Terraform, будь-які зміни можна було вносити швидко й без ризику щось пропустити в такій кількості серверів та баз даних.
Happy End. To Be Continue
Станом на зараз RAID працює в хмарі вже понад пів року. Ми продовжуємо оптимізацію інфраструктури та розробляємо заходи для підвищення стійкості проєкту в разі надзвичайних ситуацій.
Міграція суттєво зменшила ризики для RAID, бо інфраструктура Google Cloud Platform значно надійніша та має додаткові опції високої доступності. Наприклад, бази даних автоматично перемкнуться в резервний дата-центр, якщо з основним щось трапиться. Обслуговування подорожчало, але інвестиція в досвід гравців і спокійний сон команд того варта.
Дякую, що дочитали цей лонгрід. Сподіваюся, історія була для вас цікавою та корисною. Буду радий побачити ваші думки й досвід у коментарях.
Maksym Skorupskyi
Dmitrii Hruzdiev
2 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів