Окончательное архитектурное решение GAE против AWS - PullRequest
Новая
       9

Окончательное архитектурное решение GAE против AWS

12 голосов
/ 02 декабря 2010

Я знаю, что раньше так или иначе задавали этот вопрос, но большинство основных вопросов, связанных со стабильностью GAE, похоже, задавались в конце 2008 года, в начале 2009 года, или не имеют прямого отношения к играм в масштабе(что меня интересует).

По сути, я спорил с моим деловым партнером о том, использовать ли GAE или AWS для бэк-энда нашего движка социальной игры, и теперь это хруствремя.Я люблю GAE (Java) по многим причинам, и хотя раньше это было нестабильно, сейчас это довольно хорошо.Основным аргументом в пользу AWS является тот факт, что AWS зарекомендовал себя несколькими играми, в которых ежедневно работают десятки миллионов активных пользователей.Очевидным детищем для AWS является Zynga с пиковым значением Farmville на уровне 80+ миллионов DAU.И это только одна из самых успешных игр, работающих на инфраструктуре AWS.Замечательное достижение.

Итак, так или иначе, это ИЗВЕСТНО работать.GAE, с другой стороны, не имеет никаких примеров, которые я мог бы найти, выполняя эти виды чисел.Даже не близко. Так я могу доверять этому?Есть ли один пример крупной социальной игры с более чем 2 миллионами ежедневных активных пользователей, использующей GAE?

Основные соображения для нашей социальной игры:

  1. Надежный CDN (Amazon CloudFront / S3 отлично подходит для этого, так же как и превосходный DataStore от Google).
  2. Возможность масштабирования без перепадов (AWS-EC2 доказано здесь, GAE, похоже, не имеет примеров большихигровые приложения, которые могут обрабатывать тысячи запросов в секунду. Раньше GAE был довольно нестабильным в этом отношении, и поэтому моя главная задача).
  3. Надежная база данных без SQL.(AWS-SimpleDB и Google DataStore отлично подходят для этого. Нам действительно не нужен SQL).
  4. Служба поддержки / кто-то, кто позвонит / свяжется, если возникнет проблема.(Это одна из самых больших проблем с GAE. Я понятия не имею, кому я могу позвонить, или если это вообще возможно. AWS имеет SLA и поддержку.)

Я с нетерпением жду ваших мыслей,но, пожалуйста, также обратите внимание, что это не предназначено для начала какой-либо пламенной войны.Я люблю обе системы, но у обеих есть свои плюсы и минусы, но я собираюсь принять архитектурное решение, которое, скорее всего, не отменится.

С уважением,

Шейн

Ответы [ 2 ]

8 голосов
/ 02 декабря 2010

Я никогда не работал с AWS-EC2, поэтому я собираюсь поделиться своими знаниями только на стороне Google App Engine.

  1. Google App Engine не должен быть CDN ;Несмотря на то, что он может обслуживать статический контент через мощную инфраструктуру, обеспечивающую кэширование вблизи пользователей, он не гарантирует такого же высокого качества и сервиса высокой доступности для реальной CDN, поскольку это не входит в его обязанности.
    Дополнительные данные:
    • Максимальный размер файла при использовании службы BlobStore: 2 гигабайта
    • Максимальный размер статического файла: 10 мегабайт
    • В настоящее время App Engine всегда возвращает 200 статус для статических файлов даже при условном получении (вы должны полагаться на стороннюю библиотеку кэширования, например, cirruxcache ).

  2. Недавно команда Google App Engine закрыла Галерею приложений по одной простой причине: слишком много игрушечных приложений!
    Google хочет противодействовать этомутенденция, показывающая успешные бизнес-кейсы;Вот некоторые из них:

    Другие интересные примеры здесь

  3. "Мы хорошо знаем о простоях и проблемах с надежностью и прилагаем все усилия для их решения: повышение надежности App Engine - наш приоритет номер один", - недавно сказал менеджер по связям с разработчиками Google здесь .
    App Engine все еще находится на стадии бета-тестирования и представляет собой развивающуюся платформу, поэтому вы должны быть готовы справиться с простоями и проблемами.

  4. Команда Google App Engine только что запустила предварительный просмотр App Engine для бизнеса , обеспечивающий 99,9% времени безотказной работыДоступна поддержка разработчиков emium.

Вот мое мнение о том, что стоит :
Я знаю, что это сложный вызов;прочитав много статей о GAE , я испытываю смешанные чувства по этому поводу, потому что вы можете перейти от недавнего катастрофического Carlos Ble отчета к счастливому опыту Flower Garden или Gri.pe .
App Engine для бизнеса выглядит многообещающе, и я бы рассмотрел это в случае серьезного плана бизнес-проекта.Свежий SDK 1.4.0 огромен, и он ясно показывает, что команда действительно старается исправить некоторые раздражающие проблемы (запросы на разогрев) и ослабляет некоторые ограничения (10-минутный процесс в TaskQueue).

Последнее, на что нужно обратить внимание: если у вас будут большие цифры, команда Google App Engine, вероятно, примет ваше приложение в качестве успешного примера, который последует за распространением бесплатного и мощного Hype.

5 голосов
/ 02 декабря 2010

BuddyPoke - один из примеров крупномасштабного социального приложения, работающего на GAE. Насколько большой я не уверен. В этой статье говорится о 30 млн ежедневных просмотров страниц (не пользователей):

http://googleappengine.blogspot.com/2008/10/app-engine-case-studies.html

На их странице в Facebook говорится, что 2,7 миллиона пользователей в месяц (не ежедневно):

http://www.facebook.com/buddypoke

Хотя они также находятся в куче других социальных сетей:

http://www.buddypoke.com/

Лично я решил пойти с GAE, по нескольким основным причинам:

  • Единица масштабируемости - это отдельный запрос, а не целый экземпляр, как в AWS.
  • Я могу работать на более высоком уровне, не беспокоясь о настройке экземпляров.

Если ваша точка 4 для вас важна, то вам может быть лучше с AWS. С GAE, кажется, вы ничего не можете сделать, и никто не может связаться.

Около недели назад у меня возникла проблема с моим приложением - оно внезапно начало давать сбой в коде Google, в месте, которое работало нормально в течение последних 5 дней, то есть с момента последней загрузки моего приложения. Похоже, что единственный способ сообщить о проблемах в Google - это использовать их шаблон рабочей проблемы:

http://code.google.com/p/googleappengine/issues/entry?template=Production%20issue

Я сообщил о проблеме и ничего не слышал. Поскольку он работает на серверах Google, я не смог прибегнуть к какой-либо «обычной» экстренной тактике, такой как перезапуск сервера. Через час проблема решилась сама собой - я не уверен, что кто-то в Google видел мое сообщение и что-то исправил, или оно просто исчезло. Я обновил свой отчет об ошибке, чтобы сказать, что проблема была исправлена, но даже сейчас, спустя неделю, проблема не была закрыта или даже подтверждена. Кроме того, поскольку проблема должна быть опубликована, мое приложение теперь получает случайные попадания от ботов.

По общему признанию, мое приложение в настоящее время только в бета-версии и поэтому имеет только сто или около того пользователей, так что это не было для меня серьезным инцидентом. Если бы я получал тысячи / миллионы обращений, возможно, либо Google сам заметил бы проблему раньше, либо они бы обратили больше внимания на мое сообщение об ошибке.

Что касается вашего пункта 3, даже мое небольшое приложение с небольшим объемом трафика выдает случайные ошибки хранилища данных (даже в периоды, которые не отражаются в диаграммах доступности в качестве отключений).

Сказав это, я все еще люблю GAE (я использую версию Python) и планирую придерживаться этого. Обещанием GAE является его масштабируемость - хотя теперь он иногда падает для моего небольшого трафика, он не должен больше падать, когда он масштабируется до гораздо большего трафика (т. Е. Ваша точка 2), при условии, что я правильно его кодировал раздор. Я посмотрю, как это будет.

Наконец, что касается вашего пункта 1, хранилище BLOB-объектов и / или статические файлы больше похожи на CDN в GAE, чем на хранилище данных. Однако для очень больших объемов трафика реальный CDN может быть дешевле. Это также не обязательно CDN, см. Google app engine & CDN .

...