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

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

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

Итак, так или иначе это ЗНАЛО работать. GAE, с другой стороны, не имеет примеров, которые я мог бы найти, делая эти виды чисел. Даже не близко. Могу ли я доверять этому? Есть ли один пример большой социальной игры с 2 миллионами + ежедневных активных пользователей, используя GAE?

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

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

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

Привет,

Шейн

Ответ 1

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

Google App Engine не предназначен для CDN; хотя он может служить статическим контентом благодаря своей мощной инфраструктуре, обеспечивающей кеширование рядом с пользователями, он не гарантирует такого же высокого качества и высокой доступности службы реального CDN, поскольку он не является частью его обязанностей.
Дополнительные данные:
- Максимальный размер файла с использованием службы BlobStore: 2 гигабайта
- Максимальный размер статического файла: 10 мегабайт
- В настоящее время App Engine всегда возвращает 200 статусов для статических файлов даже в Conditional gets (вы должны полагаться на стороннюю библиотеку кеширования, например cirruxcache, например).
Недавно команда Google App Engine закрыла Галерея приложений по одной простой причине: слишком много приложений для игр!
Google хочет противодействовать этой тенденции, демонстрируя успешные бизнес-исследования; вот некоторые из них:
- BuddyPoke (приложение viral Facebook с 65 миллионами установок)
- WalkScore (обслуживает 3 миллиона запросов в день тысячам сайтов-партнеров по недвижимости)
- Веб-заставки
- Snapabug
- Optimizely
- игра Ubisoft Facebook TikTok
Другие интересные тематические исследования здесь
"Мы хорошо знаем проблемы с простоем и надежностью и прилагаем все усилия для их решения: повышение надежности App Engine - это наш приоритет номер один", - недавно сказал менеджер по связям с разработчиками Google здесь.
App Engine по-прежнему находится в стадии бета-тестирования и является развивающейся платформой, поэтому вы должны быть готовы к тому, чтобы справляться с простоями и проблемами.
Команда Google App Engine только что запустила предварительный просмотр App Engine for Business, обеспечив 99,9% соглашения об уровне обслуживания и поддержки премиум-разработчиков доступны.

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

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

Ответ 2

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, blobstore и/или статические файлы больше похожи на CDN на GAE, чем на хранилище данных. Однако для очень больших объемов трафика реальный CDN может быть дешевле. Это также не обязательно CDN, см. механизм Google для приложений и CDN.