How Blitz scaled their game coaching app with lower latency and leaner operations Это быстрорастущий стартап, который предоставляет персонализированные тренинги для игр, таких как League of Legends, Valorant и Fortnite. Они направлены на то, чтобы помочь игрокам стать легендами League of Legends через знания в режиме реального времени и анализ после матча. блиц В то время как игроки играют, приложение выполняет довольно много работы. оно захватывает данные о матчах в реальном времени, анализирует их быстро и использует его для реального времени игрового экрана и персонализированного послеигрового тренинга. Руководство основано на текущей и исторической игровой активности каждого игрока, а также данных, собранных в миллиардах матчей, в которых участвуют сотни миллионов пользователей. Благодаря растущей осведомленности о популярной статистике Blitz и приложении для тренинга игр, их постоянно растущая база пользователей подтолкнула их оригинальную архитектуру на основе Postgres и Elixir к своим пределам. Чтобы обеспечить низкую задержку, высокую доступность и горизонтальную масштабируемость своей растущей базе пользователей, они в конечном итоге: TL;DR Мигрированные сервисы backend от Elixir до Rust. Заменили Postgres на ScyllaDB Cloud. Значительно уменьшили свой отпечаток. Удалили свой кластер Riak. Замененная обработка очередей с обработкой в реальном времени. Консолидированная инфраструктура от более чем ста ядер микросервисов до четырех узлов Google Cloud n4‐4 (плюс небольшой экземпляр Redis для кэширования краев) В качестве дополнительного бонуса эти изменения в конечном итоге сократили затраты на инфраструктуру Blitz и уменьшили нагрузку на их инженерный персонал. Фонари Blitz Как объяснил Навид Хан (Head of Engineering at Blitz), «мы собираем много данных от издателей игр и во время игры.Например, если вы играете в League of Legends, мы используем API Riot для получения данных о матчах, а если вы устанавливаете наше приложение, мы также контролируем игру в реальном времени.Все эти данные хранятся в нашей транзакционной базе для первоначальной обработки, и большая часть этого в конечном итоге заканчивается в нашем озере данных». Скалирование прошлого Postgres Одной из ключевых частей системы Blitz является API Playstyles, который анализирует данные перед игрой как для товарищей по команде, так и для соперников. Этот интенсивный процесс оценивает до 20 матчей на игрока и работает девять раз за игру (один раз для каждого игрока в матче). Команда стратегически переделала и консолидировала многочисленные микросервисы, чтобы улучшить производительность. Но объем данных оставался интенсивным. Первоначально они использовали Postgres, который хорошо обслуживал их на ранних стадиях. Тем не менее, по мере масштабирования их рабочих нагрузок, операционная сложность и затраты на Google Cloud значительно выросли. Кроме того, масштабирование Postgres стало довольно сложным. Naveed поделился, «Мы попробовали всевозможные вещи для масштабирования. Мы построили несколько услуг вокруг Postgres, чтобы получить масштаб, который нам нужен: кластер Redis, кластер Riak и очереди Elixir Oban, которые время от времени переполнялись. управление очереди стало большой задачей». По мере того, как стартапы расширяются, они часто переходят от «просто используют Postgres» к «просто используют NoSQL». Соответственно, команда Blitz подумала о переходе на MongoDB, но в конечном итоге исключила его. «У нас было много опыта MongoDB в команде, и некоторым из нас это действительно понравилось. Это создаст бутылку для их конкретной рабочей нагрузки и ожидаемого роста. Первичная и вторичная архитектура MongoDB Тесты показали, что он удовлетворит их потребности в задержке, поэтому они выполнили необходимые данные (ре)моделирования и перенесли несколько небольших игр из Postgres в RocksDB. Однако, в конечном итоге они решили против RocksDB из-за проблем с масштабом и высокой доступностью. «Основываясь на имеющихся данных из нашего тестирования, было ясно, что RocksDB не сможет справиться с нагрузкой наших более крупных игр – и мы не могли рисковать вертикальным масштабированием одного экземпляра, а затем имея этот один экземпляр, чтобы упасть», — объяснил Навед. Почему ScyllaDB Один из их инженеров предложил ScyllaDB, поэтому они вышли и провели доказательство концепции.Они в первую очередь искали решение, которое может справиться с пропускной способностью письма, масштабировать горизонтально и обеспечивать высокую доступность. Они сначала протестировали его на своем собственном оборудовании, а затем переехали в ScyllaDB Cloud. По Naveed, «стоимость была довольно близка к самохостингу, и мы получили полное управление бесплатно, так что это было бессмысленно. У нас теперь существенно сокращенный кластер Redis, плюс мы избавились от кластера Riak и зависимостей от очередей Oban. Просто напишите ScyllaDB и все просто работает. С точки зрения производительности, сдвиг удовлетворил их цель повышения уровня пользовательского опыта ... и также упростил жизнь для их инженерных команд. Брайан добавил: «ScyllaDB оказалась исключительной, предоставляя надежную производительность с возможностью экономить после оптимизации. Наш продукт Лиги достигает максимума примерно в 5 000 операций/сек с отчетом кластера ниже 20% нагрузки. Нашим самым большим ограничением было использование диска, которое мы развернули несколько обновлений, чтобы смягчить. Новая система теперь может часто возвращать результаты сразу, вместо того чтобы полагаться на кешированные данные, предоставляя более актуальную информацию о других игроках и даже идентифицируя частых товарищей по команде. Результаты этой миграции были впечатляющими: более ста ядер микросервисов были заменены High-Level Architecture of Blitz Server with Rust and ScyllaDB Переписывать услуги Elixir в Rust В рамках масштабной реформы, команда Blitz начала переосмысливать всю свою инфраструктуру – за пределами ранее описанного перехода от Postgres к высокопроизводительному и распределенному ScyllaDB. Наряду с этой миграцией баз данных, они также решили запустить свои сервисы на базе Elixir в пользу более современного языка. После тщательной оценки, Rust появился как очевидный выбор. „Elixir отлично подходит и хорошо служит своей цели“, – объяснил Навид. „Но мы хотели двигаться к чему-то более широкому принятию и более сильной экосистеме на уровне систем. Теперь, когда первая партия переписанных сервисов Rust находится в производстве, Naveed и команда не оглядываются назад: «Rust фантастичен. Это быстро, и компилятор заставляет вас писать защищенный код памяти заранее, вместо того чтобы дебютировать вопросы сбора мусора позже.
