Урок: «Система, работающая с двумя миллионами пользователей, не обязательно сможет справиться с десятью миллионами».
После выпуска Pokémon Go в США в июле 2016 года она стала самой популярной на тот момент игрой в дополненной реальности. Этот продукт многолетнего сотрудничества игрового разработчика Niantic и Google (пока Niantic не встала на ноги, она была внутренним стартапом Google). Поэтому инфраструктура Pokémon Go сильно зависела от облачной платформы и служб приложений Google. (Компании Nintendo и Pokémon тоже приняли участие в создании захватывающего игрового процесса выращивания маленьких монстриков для мобильных платформ.)
Это была не первая игра Niantic в дополненной реальности. Ранее компания создала Ingress, игру о вторжении инопланетян, выпущенную в 2013 году для устройств Android. Но Pokémon Go стала игрой совершенно другого уровня — покемоны уже давно были культурным феноменом. Игра заинтересовала аудиторию, долгие годы ожидавшую мобильную игру. Поэтому количество установок росло стремительно. За полдня игра заняла первую позицию по доходам на iPhone. В какой-то степени это был самый масштабный в мире выпуск мобильной игры.
Но её успех повысил нагрузку на платформу: через два дня после выпуска технический директор Niantic Джон Ханке (John Hanke) объявил, что компания откладывает всемирный выпуск Pokémon Go, виной чему стали перегруженные серверы. В то же время возникли проблемы с конфиденциальностью из-за способов работы Niantic с сервисами идентификации и определения местоположения Google. Компании пришлось исправлять множество ошибок, одновременно решая проблемы с серверными мощностями.
В теории, облако должно справляться с периодами пиковых нагрузок, упрощая управление приложением, а сервисы, предоставляемые поставщиками облачных решений, должны были упростить разработку различных мобильных приложений (не только игр). И возможности облаков действительно упростили использование новых возможностей, требующих больших вычислительных мощностей (таких как дополненная реальность).
Но, как и в случаях с другими сетевыми платформами прошлого, разработчики выяснили, что наличие всех этих мощностей не важно, если отсутствует возможность подключения к ним. Чем более интерактивны мобильные приложения, тем сложнее становится обмен данными между мобильными устройствами и облачной инфраструктурой. Добавьте фактор различий в скорости передачи данных у операторов связи по всему миру и получите систему, в которой для обеспечения необходимой пользователям скорости нужно учитывать множество параметров.
Немногие приложения «взлетают» так же, как ставшая виральной в мировом масштабе Pokemon Go. Тем разработчикам, которые стремятся к масштабированию игр и приложений, будет полезным исследование того, как Niantic и другие разработчики игр справлялись с навалившимся на них неожиданным успехом. Если хитовые мобильные игры могут справляться с препятствиями, возникающими при тестировании и отладке производительности взаимодействия устройств и облака, то и корпорации тоже способны решать проблемы с неожиданными пиками пользовательской активности.
Всех их обработаем
Чтобы усвоить уроки, полученные Pokémon Go, Arstechnica недавно пообщалась с техническим директором Niantic Филом Кеслином (Phil Keslin). Мы поговорили о сложных взаимодействиях между открытыми для публики частями облака Google и внутренними данными.
Pokémon Go использует Google Compute Engine, его облачное хранилище данных и полный стек сетевых технологий, включая инфраструктуры обработки данных и запросов. Разумеется, в игре используются и Google Maps для определения местоположения игрока. По словам Кеслина, все изменения в AI игрового процесса требуют того, чтобы мобильный клиент осуществлял вызовы к хранилищу данных Niantic. «При каждом изменении состояния игры — броске покебола, поимке покемона или другом действии выполняется взаимодействие с хранилищем данных».
Когда возник первый большой пик, то, по словам Кеслина, «Google этого даже не заметила, а ведь игра по крайней мере в два раза увеличила количество обрабатываемых данных». Однако это не привело к перегрузке систем. «Проще всего сказать так: у нас был прогноз наихудшего сценария, но игра превзошла даже его». В день выпуска произошёл настоящий взрыв. «Мы обнаружили узкие места, замедлявшие производительность. После их устранения мы упирались в новое „бутылочное горлышко“».
Часть узких мест находилась в коде Niantic, «но у нас возникли проблемы и с парой библиотек с открытым кодом, чего мы никак не ожидали — именно их было сложнее всего решить». В целом Niantic обнаружила пять или шесть узких мест, на устранение каждого из которых потребовались один-два дня.
Но неисправности возникали и со стороны Google. У Pokémon Go возникли проблемы с облачной инфраструктурой; движок контейнера содержал подсистемы, которые никогда не тестировались под такой нагрузкой. Появилась пара проблем и с сетевым стеком.
Устранение узких мест потребовало много труда от команды из пяти человек, состоявшей из Кеслина, руководителя команды и трёх сервисных инженеров. «В первые две недели мы почти не спали», — рассказывает Кеслин. «Ребята из Google тоже выкладывались по полной».
Ещё одним фактором, повлиявшим на производительность в различных регионах, по словам Кеслина, стали различия между мобильными операторами в разных частях света. «Мы разрабатывали Pokémon Go таким образом, чтобы игра могла работать в мобильных устройствах с низкой пропускной способностью. Возникшие проблемы больше касались маркетинговых программ операторов связи». Например, крупный оператор мобильной связи в Филиппинах предоставил всем своим абонентам бесплатный доступ к Pokémon Go, поэтому Niantic нужно было обеспечить включение пользователей и их отключение после завершения рекламной акции.
Несмотря на первоначальный хаос, Кеслин заявил, что Niantic не пришлось менять архитектуру Pokémon Go после выпуска игры. (Компания продолжает последовательно совершенствовать приложение и готовится к выпуску второго поколения Pokémon Go, которое, как она надеется, даст игре второе дыхание, после того, как волна покемании утихла.) «Инфраструктура была разработана с учётом полного набора покемонов», — говорит он. «Ядро системы останется тем же, мы просто добавим новый геймплей. Нам повезло, что получилось создать масштабируемую систему, мы не тестировали её. К счастью, созданная архитектура надёжно масштабируется».
Что может посоветовать Кеслин другим разработчикам, стремящимся создать новый феномен дополненной реальности? «Думайте о масштабировании с самого начала. Команда разработки нашей игры была сосредоточена на производительности. Благодаря этому мы смогли максимизировать производительность при низких затратах, и были способны масштабировать систему».
Пристрастие к Trivia Crack
Логотип Trivia Crack компании Etermax
Другие компании тоже шли путём публичного облака с игровой инфраструктурой, результаты были противоречивыми. За два года до того, как Pokémon Go выпал джекпот, аргентинская компания Etermax создала собственный хит мобильного гейминга: Trivia Crack, игру из набора соревновательных игр, работающих в Amazon Web Services.
По словам технического директора Etermax Гонзало Гарсии (Gonzalo Garcia) огромный успех Trivia Crack приходил к ней двумя волнами: первый, в марте 2014 года, ознаменовал успех игры в части южноамериканских стран. Трафик при этом увеличился с 100 тысяч до 10 миллионов ежедневных активных пользователей. Вторая волна накатила, когда игра стала популярной в США в октябре того же года, увеличив количество ежедневных активных пользователей до 25 миллионов.
«Мы не предвидели этого», — говорит Гарсия. «По нашим оценкам и тестам мы знали, что сможем справиться с одним миллионом игроков, и планировали два миллиона. Но мы не ожидали такого роста — мы даже не инвестировали так сильно в рекламу! Без сервера облачной инфраструктуры мы бы ни за что не справились».
«Мы считали, что выпускаем очередную игру компании», — добавляет директор по информационным технологиям Etermax Мартин Домингес (Dominguez). «Раньше нашим пределом был один миллион пользователей, но то, что подходит двум миллионам, не всегда достаточно для десяти миллионов».
Такая нагрузка подвергла стрессу процесс разработки Agile компании. «Мы считали, что не привязаны к Scrum, и всегда работали в стиле Agile», — рассказывает Домингес. «Проблема заключалась в том, что при таком скачке количества пользователей спринты нельзя было завершать за две недели, нам приходилось работать день за днём».
Чтобы справиться с популярностью, Etermax сначала пришлось отказаться от части функций. Ей также пришлось изменить некоторые базы данных и адаптировать процессы для повышения эффективности. В частности, Etermax изменила способ использования Amazon Relational Database Service (RDS). Она реализовала фрагментацию, вторичные серверы и обмен данными между вторичными серверами. Также она сотрудничала с AWS для решения проблемы с количеством пакетов в секунду.
Для поддержки расширенных сетевых возможностей Etermax пришлось мигрировать из публичной сети Amazon в виртуальное частное облако. «Это было довольно сложно», — вспоминает Домингес. «На втором пике пользователей, увеличившем количество до 25 миллионов, сотрудники AWS сказали, что никогда не видели компанию, использовавшую RDS на таком уровне».
Гарсия рассказал, что со взрывным ростом популярности Trivia Crack Etermax помогла справиться одна особенность. «В Trivia Crack интерфейс почти полностью находился в мобильном устройстве, поэтому передавались только мелкие объёмы информации». Благодаря этому синхронные подключения стали меньшей проблемой для Trivia Crack по сравнению с другими играми Etermax, например, мобильной игры в «бинго» Bingo Crack: «Нам постоянно нужно было передавать информацию о шарах бинго, чтобы знать, кто первым, вторым или третьим выкрикнет „Бинго!“». Чему Etermax научил успех Trivia Crack? По словам Домингеса, когда дело касается инфраструктуры, нужно соображать быстро, быть проактивными при внесении изменений, и догадываться, какие проблемы возникнут. «У Pokémon Go была та же проблема — каждый день нужно было выживать». Чтобы подготовиться к испытаниям и быть готовыми к новому популярному хиту Etermax увеличила количество сотрудников основной команды разработки с трёх до десяти инженеров.
Управление успехом
Патрик Палм (Patric Palm) является техническим директором и основателем шведской компании Hansoft. Она создала ПО для коллективной работы Favro, используемое многими разработчиками игр, в том числе Ubisoft и id Software. Патрик имеет возможность наблюдать за клиентами компании, решающими свои задачи в отрасли мобильных игр.
Рассматривая проблемы, с которыми столкнулась Pokémon Go, Палм выделяет вопрос различий скорости соединения в разных регионах мира. Однако он подчёркивает, что благодаря облачным вычислениям масштабируемость стала сейчас меньшей помехой.
«Несколько лет назад масштабируемость была гораздо более серьёзной проблемой, для решения которой требовалось намного больше людей». Поскольку Niantic смогла переложить решение части проблем на Google Cloud, она смогла сосредоточиться на реализации и регистрации в различных странах. «Облачные системы решают одну из крупнейших проблем бизнеса», — сказал Палм.
Благодаря тому, что решение проблемы масштабируемости было найдено, внимание обратили на другие, более мелкие проблемы. В случае Pokémon Go ими стали быстрый разряд батареи телефона, заставлявший игроков бегать по городу с внешними аккумуляторами. «Игра Niantic сильно разряжала батареи», — говорит Палм. «Разработчики облачных игр теперь сильно задумались об энергопотреблении».
Ещё одна связанная с этим проблема: ограничения передачи данных в разных тарифах. «Не у каждого пользователя есть удачный тариф мобильного оператора». Это ещё один стимул переноса большей части бремени на сторону сервера. Игры, запущенные в фоновом режиме, потребляют не только энергию, но и данные.
«Нам понадобится облако побольше».
Правила игры
Если Pokémon Go и Trivia Crack смогли справиться с проблемами масштабирования облачных вычислений на мобильных платформах, то и у вас это получится. Вот подсказки для оценки ваших собственных задач:
- Рассматривайте сценарий «хуже худшего». Разумеется, когда дело дойдёт до оценок, нужно выбрать какие-то показатели. Но нужно также планировать, как масштабироваться выше максимального предела. Основное преимущество облачных вычислений — в их эластичности, подумайте о том, что будет, если эти масштабы будут расширяться быстрее, чем вы тестировали.
- Обсудите нештатные ситуации с поставщиком услуг. Когда трафик вырос, Niantic и Etermax пришлось тесно сотрудничать с Google и Amazon. При выборе поставщика облачных услуг конкретно обговорите, какие услуги они могут предоставить, если ваши потребности резко вырастут по сравнению с ожидаемыми.
- Изучите операторов связи и мобильные устройства. Если ваша облачная технология будет выполняться на собственных мобильных устройствах пользователей (возможно, в разных частях мира), то подумайте, сколько соединений будет передаваться от устройства к облаку и оцените тарифные планы с самыми медленными подключениями у самых проблемных операторов, с которыми придётся столкнуться вашему продукту.
Автор: PatientZero
