How a team of just two engineers tackled real-time persisted events for hundreds of millions of players С помощью всего двух инженеров Supercell взяла на себя сложную задачу — превратить свою базовую систему учетных записей в социальную платформу, соединяющую сотни миллионов игроков.Управление учетными записями, запросы друзей, кросс-игровые промо-акции, чат, отслеживание присутствия игроков и формирование команды — все это должно было работать на протяжении пяти основных игр. Инженер-сервер Supercell Эдвард Фагерхольм недавно поделился тем, как их мощная команда из двух человек справилась с этой задачей.Читайте дальше, чтобы узнать, как они превратили простой инструмент управления учетными записями в всеобъемлющую инфраструктуру социальных сетей, которая ставит приоритет как на простоту работы, так и на высокую производительность. Примечание: Если вам нравится слушать о инженерных достижениях, как это, присоединяйтесь к нам в Monster Scale Summit (бесплатно + виртуально). Инженеры из Disney+ / Hulu, Slack, Canva, Uber, Salesforce, Atlassian и другие будут делиться стратегиями и тематическими исследованиями. с с . нота Если вам нравится слушать об инженерных достижениях, как это, присоединяйтесь к нам Саммит Monster Scale Инженеры из Disney+/Hulu, Slack, Canva, Uber, Salesforce, Atlassian и других будут делиться стратегиями и тематическими исследованиями. нота Саммит Monster Scale Оригинальное название: Who’s Supercell? Supercell является финской компанией, стоящей за хит-играми Hay Day, Clash of Clans, Boom Beach, Clash Royale и Brawl Stars.Каждая из этих игр генерировала $1B в доходах на протяжении всей жизни. До недавнего времени все функции управления аккаунтами для игр, обслуживающих сотни миллионов ежемесячно активных пользователей, строились и управлялись всего двумя инженерами. Генезис Supercell ID Supercell ID родился как базовая система учетных записей – что-то, что помогает пользователям восстанавливать учетные записи и перемещать их на новые устройства. Эдвард объяснил: «Клиент мог выполнять HTTP-запросы к учетному API, который в основном возвращал подписанные токены, которые клиент мог представить игровому серверу, чтобы доказать свою личность. Некоторые операции, такие как выполнение запросов друзей, требовали, чтобы учетный API отправил уведомление другому игроку. Например, «Вы одобряете это запрос друга?» Для этой цели была очередь событий для уведомлений. Вступление в двустороннее общение После того, как Эдвард присоединился к проекту Supercell ID в конце 2020 года, он начал работать над базой уведомлений – в основном для кросс-промоции в своих пяти играх. Клиенты, подключенные к флоту прокси-серверов, затем механизм маршрутизации направлял события непосредственно к клиентам (без прохождения через игру).Это было достаточно для непосредственной цели обработки запросов на перекрестное продвижение и друзей.Это было довольно просто и не нужно поддерживать высокую пропускную способность или низкую задержку. Они поняли, что могут использовать двустороннюю связь, чтобы значительно увеличить сферу применения системы Supercell ID. Эдвард объяснил: «Основным образом, это позволило нам реализовать функции, которые ранее были частью игрового сервера. Наша цель заключалась в том, чтобы использовать функции, которые могут понадобиться любым новым играм в процессе разработки, и упаковать их в нашу систему, тем самым ускоряя их развитие». С этого момента Supercell ID стала трансформироваться в кросс-игровую социальную сеть, которая поддерживала такие функции, как графики друзей, создание команд, чат и отслеживание состояния друзей. Эволюция Supercell ID в социальную сеть Cross-Game В этот момент сторона социальной сети в бак-энде все еще была проектом одного человека, поэтому они разработали его с простотой в виду. Найти правильную абстракцию «Мы хотели иметь только одну простую абстракцию, которая поддерживала бы все наши приложения, и поэтому могла быть спроектирована и реализована одним инженером, — объяснил Эдвард. — Другими словами, мы хотели избежать создания чат-системы, системы присутствия и т. д. Мы хотели построить одну вещь, а не многие». Поиск правильной абстракции был ключевым.И иерархическое хранилище ключевых значений с Change Data Capture идеально подходило к счету. Ключи верхнего уровня в магазине ключевых значений — это темы, на которые можно подписаться. Существует двухслойная карта под каждым ключом верхнего уровня – карта(строка, карта(строка, строка)). Любые изменения данных под ключом верхнего уровня транслируются всем подписчикам этого ключа. Значения в самой глубокой карте также временные.Каждый источник данных контролирует свои временные знаки и определяет правильный порядок.Клиент опускает любое обновление с более старым временным знаком, чем то, что он уже хранил. Карта (Стринг, Стринг и Стринг) Типичное изменение данных было бы чем-то вроде «уровни равны 10» и «уровни равны 11».По мере того, как игроки играют, они запускают всевозможные обновления, как это, что означает, что много небольших писем участвуют в сохранении всех событий. Найти нужную базу данных Им нужна была база данных, которая поддерживала бы их технические требования и была бы управляемой, учитывая их минималистическую команду. Обработка множества небольших записей с низкой латентностью Поддержка иерархической модели данных Управление резервными копиями и кластерными операциями как услугой ScyllaDB Cloud оказался отличным решением (ScyllaDB Cloud является полностью управляемой версией ScyllaDB, базы данных, известной тем, что обеспечивает предсказуемую низкую задержку в масштабе). Как все играет Для представления о том, как это происходит в играх Supercell, давайте рассмотрим два примера. Для начала рассмотрим чат-сообщения.Простое чат-сообщение может быть представлено в их модели данных следующим образом: Эдвард объяснил: «Ключ верхнего уровня, к которому подписывается подписка, — это идентификатор чата. Ключ следующего уровня — это UID-часовой штамп, поэтому у нас есть порядок каждого сообщения и мы можем задавать запросы по истории чата. Далее, давайте посмотрим на «присутствие», которое широко используется в новой (и очень ожидаемой) игре Supercell, mo.co. Цель присутствия, по словам Эдварда: «Когда вы объединяетесь для боя, вы хотите увидеть в реальном времени аватар и текущую сборку ваших друзей - в основном оружие и оборудование ваших друзей, а также то, что они делают. Players’ state data is encoded into Supercell’s hierarchical map as follows: Note that: Верхний уровень — это ИД игрока, второй уровень — это тип, а внутренняя карта содержит данные. Supercell ID не нуждается в понимании данных; он просто передает их игровым клиентам. Игровым клиентам не нужно знать график друзей, так как маршрутизацию осуществляет Supercell ID. Глубже в архитектуру системы Давайте завершим экскурсию по архитектуре системы, как это сделал Эдвард. «Бак-энд разделен на API, прокси и серверы маршрутизации событий/хранения. Темы живут на серверах маршрутизации событий и разделяются между ними. Клиент подключается к прокси, который обрабатывает подписку на тему клиента. Прокси маршрутизирует эти подписки на соответствующие серверы маршрутизации событий. Конечные точки (например, для чата и присутствия) отправляют свои данные на серверы маршрутизации событий, и все события сохраняются в облаке ScyllaDB. Каждая тема имеет первичную и резервную шард. Если первичная опускается, первичная шард поддерживает номера последовательности памяти для каждого сообщения, чтобы обнаружить утерянные сообщения. Вторичная передаст сообщения без последовательных номеров. Если первичная опускается, первичная подъем вызовет обновление состояния на клиенте, а также перезагрузку последовательных номеров. API для уровней маршрутизации - это простой пост-событие RPC, содержащий партию темы, типа, ключа, значения. Задача каждого API состоит в том, чтобы просто переписать свои данные в вышеуказанное представительство. Каждое событие написано в ScyllaDB перед трансляцией абонентам. Наши API синхронны в том смысле, что если API вызов дает успешный ответ, сообщение сохранялось в ScyllaDB. Отправление одного и того же события несколько раз не вредит, так как применение обновления на клиента является идеальной операцией, за исключением возможностей многочисленных последовательных номеров, переносящихся на одно и то же сообщение. При подключении прокси узнает всех ваших друзей и подпишется на их темы, то же самое касается групп чатов, к которым вы принадлежите.Мы также подписываемся на темы для подключающегося клиента. Перезагрузка маршрутизатора запускает перезагрузку тем из прокси. Мы используем протокол буферов, чтобы сэкономить затраты на пропускную способность. Весь баланс нагрузки находится на уровне TCP, чтобы гарантировать, что запросы через одно и то же соединение HTTP/2 обрабатываются одним и тем же разъемом TCP на прокси. Это позволяет нам кешировать определенную информацию в памяти на первоначальном прослушивании, поэтому нам не нужно перезагружать другие запросы. У нас достаточно одновременных клиентов, чтобы нам не нужно отдельно загружать баланс отдельных запросов HTTP/2, так как трафик равномерно распределяется в любом случае, и запросы примерно одинаково дорогие, чтобы обрабатывать между различными пользователями. Мы используем постоянные разъемы между прокси и маршрутизаторами. Но это не конец игры Если вы хотите посмотреть полный технический разговор, просто нажмите play ниже: И если вы хотите узнать больше о роли ScyllaDB в игровом мире, вы также можете прочитать: Epic Games: Как Epic Games использует ScyllaDB в качестве бинарного кэша перед NVMe и S3 для ускорения глобального распространения крупных игровых активов, используемых Unreal Cloud DDC. Tencent Games: Как Tencent Games построили архитектуру сервисов на основе CQRS и моделей снабжения событиями с помощью Pulsar и ScyllaDB. Discord: Как Discord использует ScyllaDB для стимулирования своего массового роста, переходя от нишевой игровой платформы к одной из крупнейших в мире коммуникационных платформ. Игры для Epic: Игры от Tencent: Разногласия :
