встречайте Quasar
14 сентября 2021 года — важная дата, ознаменовавшая окончание целой эпохи и открывшая множество новых возможностей для EVE Online. В этот день произошло фундаментальное изменение, которое, хоть и осталось незамеченным среди других новшеств, таких как новый обучающий режим и сценарии обучения, обеспечит будущее игры.
В последний раз мы кардинально меняли сетевой уровень в 2011 году, создав собственную версию IOCP под названием CarbonIO, которая и положила начало печально известному эффекту замедления времени. Вскоре мы начали работу над черновиком проекта Project Sanguine, основной задачей которого стало решение проблемы среды CarbonIO. Любое улучшение производительности EVE Online сводится к тестированию работы глобальной блокировки интерпретатора (GIL) — функции языка программирования Python. Проще говоря, Python способен выполнять лишь одно действие за единицу времени. Использование Stackless Python, реализация IOCP сначала через StacklessIO, а затем через CarbonIO и совместное проектирование эффекта замедления времени призваны поддерживать прекрасную иллюзию реальности Нового Эдема. Но что если бы необходимость прогонять все идеи через GIL отпала? Как подстроить тактовую частоту отдельных процессоров к стремительному прогрессу в сфере аппаратного обеспечения?
Мы провели множество экспериментов, имеющих непосредственное отношение к Project Sanguine, самым известным из которых стал проект EVE: Aether Wars. Задача проекта состояла не в полной переработке коммуникационной модели EVE Online, а лишь в изменении модели симуляции. Сам же Project Sanguine был направлен на устранение ненужных и попросту скучных элементов EVE. Если бы нам удалось избавить игру от всего лишнего, скорость симуляции 9000 игроков в одном пространстве определённо повысилась бы. Так что Project Sanguine преследовал две цели: обойти глобальную блокировку интерпретатора и освободить место для новых возможностей.
Первый вариант Project Sanguine появился параллельно с ESI и начальной версией EVE Portal в конце 2016 года. Благодаря этим проектам в серверной архитектуре EVE Online была сформирована новая парадигма: сервисная шина. Имя в своём распоряжении это связующее ПО, мы пересмотрели уязвимые места GIL и сумели лучше оценить затраты производительности на маршрутизацию сообщений, сериализацию и передачу данных. Один выстрел из лазера в окружении тысячи кораблей — это тысяча сообщений, которые нужно немедленно разослать по всему миру. Сперва нужно назначить копию этого сообщения для тысячи адресов (маршрутизация сообщений), конвертировать данные в проводной формат (сериализация данных), а затем отправить их получателям (передача данных). В большинстве случаев механизмы CarbonIO справляются с этими задачами, но исключительно в рамках GIL. CarbonIO долго служил EVE Online верой и правдой, но с 2011 года технологии ушли далеко вперёд.
Увидев, как эти шаблоны развиваются в новой экосистеме, мы осознали, что для использования такой парадигмы необходим более стандартизированный протокол. С внедрением системы удалённого вызова процедур (gRPC) мы смогли объединить возможности маршрутизации сообщений, предоставляемые сервисной шиной, с мгновенной сериализацией буферов протоколов (стандарт сообщений gRPC). Нам всё ещё необходимо планировать передачу данных с помощью GIL, но теперь их буферизация проходит гораздо эффективнее — в отдельном потоке. Это значит, что передача данных, сериализация и маршрутизация сообщений осуществляются за пределами GIL, кроме копирования памяти, которая происходит посередине. Быстрее и быть не может.
больше лазеров
Теперь игра могла обрабатывать куда больше данных, но что из этого следовало? Параллельно с созданием ESI мы постепенно внедряли и другие облачные нативные технологии, например Kubernetes, а когда потребность в примитивах синхронизации для обработки всех этих данных стала достаточно очевидной, мы начали переход к языку Go. По мере того, как эти технологии формировали отдельную экосистему, шла работа по созданию функций, использующих новые возможности в соответствии с современными стандартами. Со многими из них вы уже знакомы.
Первая из них — система отслеживания. Эта функция позволяет держать руку на пульсе Нового Эдема и отслеживать все действия пилота. Существует также её вариация — система возможностей. Она пытается предугадать траекторию капсулёра и выделить наиболее интересные области Нового Эдема. Мы также применяем сервисную шину для обслуживания таблиц лидеров испытательного полигона Бездны. Огромная работа была проделана для того, чтобы предоставить команде разработчиков экосистему, привязывающую к этим функциям новую систему передачи сообщений. Однако у всех этих функций была одна ахиллесова пята — десктопный клиент.
До выхода сценариев обучения каждая функция передавала данные на сервер Tranquility посредством CarbonIO. Теперь же все операции сценариев обучения не только передаются через gRPC: они вообще не связаны с Tranquility и его базой данных.
Почему обход Tranquility и его базы данных так важен? Чтобы это объяснить, стоит немного рассказать об ошибках. За эти годы мы испробовали множество новых инструментов и технологий. Одной из них стала методика распределённой трассировки на базе нашего нового фаворита: Honeycomb.io (подробнее об этом читайте здесь). Вооружившись всеми современными «примочками», мы могли легко оценить, как развивалась ситуация со сценариями обучения после их выпуска:
Мы видели, что производительность оставалась в пределах нормы, хотя её ещё предстояло улучшить:
Однако уже на следующее утро начали происходить совершенно безумные вещи:
Да, отправка одного сообщения длилась 500 тысяч миллисекунд, то есть 8 минут 20 секунд. Для объяснения деталей понадобятся доска, маркер и кружка пива с нашего «Фанфеста». Вот главное, что вам нужно знать: Tranquility не рухнул, тысячи игроков остались на сервере, и большинство игроков не пострадало (можно увидеть, что основная часть сообщений так и находится в самом низу графика). А всё потому, что мы вообще не взаимодействуем с Tranquility. По крайней мере, в обычном смысле. Нет больше никаких CarbonIO, которые передают данные сперва на стандартные прокси, затем — на серверный узел и только потом — в базу данных. Вместо этого Tranquility занимается более важными задачами, а наш десктопный клиент через gRPC обменивается данными с новой экосистемой, где располагается служба сценариев обучения со своей базой данных.
Возможно, вы помните, что недавно мы даже осушили вулкан, чтобы провести на Tranquility второй эксперимент «Неотключаемый сервер». Одна из главных черт новой экосистемы — она не требует перезагрузки. Нам не нужно было перезапускать Tranquility для спасения системы сценариев. Нам не нужно было выпускать патч для сервера или десктопного клиента.
После долгих лет работы Project Sanguine превратился в новую техническую платформу EVE Online под названием Quasar. Мы почувствовали, что настало время дать ей имя. Так нам будет проще на неё ссылаться, а вам — понять, что эта платформа из себя представляет. Кроме того, мы хотели рассказать вам о последних технических достижениях EVE Online, а также о том, как эти достижения изменят игру на третьем десятке лет её существования. По удивительному совпадению, текущий квадрант получил название Gateway, поскольку подразумевает непосредственное использование шлюзов gRPC.
Да и вообще, все эти космические словечки… Они просто хорошо звучат.
Что дальше?
Мы продолжаем расчищать место, обновляя устаревшие сервисы. Поэтому сейчас у нас два основных вектора развития: создание целого ряда базовых возможностей для Quasar (а не только управление службой сценариев обучения) и оптимизация старых систем для ускорения работы.
Что это значит для рядового капсулёра? Появление новых мощных функций в широком разнообразии сред.
Мы также подумываем о публикации данных симуляции через Quasar… но это займёт время.
