HighLoad.org – блог о высоких нагрузках
HighLoad.org > Как FarmVille масштабируется, чтобы давать собрать урожай 75 миллионам игроков

Как FarmVille масштабируется, чтобы давать собрать урожай 75 миллионам игроков
2010-02-14 20:29 my_fess 
  Если бы настоящее фермерство было бы настолько уже удобно, как в мегахите FarmVille от Zynga, тогда моя семья никогда бы не покинула суровые зимы Северной Дакоты. Ни одна из тех жутких историй про фермерство, которые мне рассказывала бабушка на ночь, не имеет ничего общего с FarmVille. Фермеры зарабатывают деньги, растения растут, а животные никогда не посещают красный амбар. Как же в FarmVille масштабировали веб приложение, чтобы справиться с 75 миллионами игроков? К счастью, Luke Rajlich из FarmVille согласился посвятить нас в некоторые их проблемы и секреты.
Формат интервью был таков, что я отправил Luke несколько общих вопросов, и вот что он ответил:
Набор задач масштабирования FarmVille уникален. Ей пришлось масштабироваться быстро и широко. После 4-х дней у нее был 1 миллион игроков в день, через 60 дней - 10 миллионов. На момент запуска у самой большой социальной игры было 5 миллионов ежедневных игроков. Сейчас, через 9 месяцев после запуска у FarmVille 20 миллионов игроков в день и 75 миллионов игроков в месяц. Таким образом, месячная база игроков FarmVille больше чем население Франции. Есть 2 фундаментальные черты, которые делают FarmVille уникальной задачей масштабирования: это самая большая игра в мире и самое большое приложение на веб-платформе. Оба этих аспекта порождают уникальный набор проблем масштабирования, которые FarmVille приходится преодолевать. В терминах инвестирования в технологии FarmVille преимущественно использует opensource компоненты и его ядро построено на основе стека LAMP.
Для того, чтобы масштабировать FarmVille как игру, нам приходится приспосабливаться к нагрузке игры. Состояние пользователя содержит большое количество данных, которые связаны между собой сложным и неуловимым образом. Например, в ферме объекты не могут занимать одно и то же место, поэтому, если пользователь размещает дом на своей Ферме, бэкенду необходимо проверить, что никакой другой объект на Ферме этого пользователя не занимает перекрывающееся место. В отличии от большинства крупных сайтов, таких как Google или Facebook, у которых основная нагрузка приходится на чтение, у FarmVille крайне высокая нагрузка приходится на запись. Соотношение чтения и записи данных составляет 3:1, и это очень высокая доля записи. Большинство запросов к бэкенду FarmVille тем или иным образом модифицирует состояние игрока. Чтобы сделать это масштабируемым, мы поработали над тем, чтобы приложение взаимодействовало преимущественно с кэшем. Кроме того, выпуск нового контента и возможностей имеет тенденцию вызывать скачки нагрузки, т.к. мы фактически расширяем игру. В день выпуска новых возможностей скачок нагрузки может составлять 50%. Нам приходится приспосабливаться к такому трафику.
Другой нюанс заключается в том, чтобы масштабировать FarmVille как самое большое приложение на веб платформе и один из крупнейших сайтов в мире. Так как игра работает внутри платформы Facebook, мы очень чувствительны к ее задержкам и колебаниям производительности. В результате мы проделали много работы, чтобы уменьшить эти колебания задержек: мы интенсивно кэшируем данные Facebook и элегантно сводим к минимум использование платформы, когда видим падение производительности. Мы развернули целый кластер кэширующих серверов для платформы Facebook. Количество трафика между FarmVille и платформой Facebook - гигантское. В пиковые моменты 3 Гигабита/сек проходит между FarmVille и Facebook, в то время как наши кэширующие сервера обслуживают еще 1.5 Гигабита/сек. Кроме того, так как производительность может изменяться, приложение должно иметь возможность динамически отключать любые обращения к платформе. Мы дополнительно поработали над тем, чтобы любые обращения к платформе не блокировали само приложение. Идея в том, что если все остальное не работает, то игроки могут хотя бы просто играть.
Высокие задержки убивают любое веб приложение, и в конечном счете сильно изменяющаяся задержка убивает ваше приложение. Мы поместили много кэширования перед компонентами с высокой задержкой, чтобы бороться с ней. Сильно изменяющаяся задержка требует переосмысления  того, как приложение полагается на части своей архитектуры, у которых обычно приемлемая задержка. Практически каждый компонент чувствителен к изменяющейся задержке, какие-то больше чем другие. По причине того, что в FarmVille сильная нагрузка приходится на запись и транзакции, непостоянность задержки приводит к усиленному эффекту на пользователя по сравнению с традиционным веб приложением. FarmVille справляется с этими сценариями благодаря тому, что каждый отдельный компонент рассматривается как деградирующая служба. Ключевые идеи: изолировать проблемные службы с высокой задержкой так, чтобы они не могли вызывать задержку и ухудшение производительности; при необходимости ограничивать функциональность приложения.
Мы используем различные opensource инструменты для того, чтобы справляться с управлением и мониторингом веб фермы Farmville. Nagios - для оповещения, munin - для мониторинга и puppet для конфигурирования. Мы интенсивно используем внутренние системы статистики, чтобы отслеживать производительность служб, используемых приложением: Facebook, DB, Memcached. Кроме того, когда мы видим падение производительности, мы профилируем события обращения к вводу/выводу на выборочной основе.
Извлеченные уроки
  1. В интерактивных играх сильная нагрузка приходится на запись. Типичные веб приложения читают больше чем записывают, поэтому многие распространенные архитектуры не подходят. Такие приложения могут обойтись кэширующим слоем перед единой базой данных. Приложениям с нагрузкой на запись необходимо разделять, поэтому запись рассредотачивается и/или использует архитектуру, основанную на оперативной памяти.
  2. Каждый компонент надо проектировать как деградирующую службу. Изолируйте компоненты, так чтобы увеличенные задержки в одной области, не разрушали другую. Уменьшайте использование, чтобы упростить проблемы. Отключайте возможности, когда необходимо.
  3. Кэшируйте данные Facebook. Когда вы сильно зависите от внешнего компонента продумывайте кэширование данных этого компонента, чтобы уменьшить задержки.
  4. Планируйте наперед скачки нагрузки связанные с выпуском новых возможностей и контента.
  5. Используйте выборки. При анализе больших потоков данных, например при поиске проблем, не надо обрабатывать все данные подряд. Работа  с выборочными данными может принести те же результаты с меньшими усилиями.

Автор статьи: Todd Hoff Дата: 8 февраля 2010


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD