Будет ли использование Cloud PaaS автоматически решать проблемы масштабируемости?

Столько вопросов для одного поста. В любом случае:

1. Amazon EC2 не масштабируется автоматически при нагрузке. EC2 — это просто виртуальная машина. Вы можете добиться масштабирования инстансов EC2 с помощью Auto Scaling и Упругая балансировка нагрузки.

2. Базы данных SQL плохо масштабируются. Вот почему люди начали использовать базы данных NoSQL. Лучше всего посмотреть, какую базу данных ваш облачный провайдер предлагает в качестве управляемой службы: Datastore в GAE. и DynamoDB на Amazon.

3. Установка собственной базы данных на экземпляры EC2 крайне непрактична, поскольку EC2 имеет временное хранилище (при перезагрузке все данные на "диске" теряются).

4. GAE Datastore на самом деле представляет собой одну большую базу данных для всех запущенных в ней приложений. Так что это довольно масштабируемо — ваш миллион пользователей не должен быть для него проблемой. http://highscalability.com/blog/2011/1/11/google-megastore-3-billion-writes-and-20-billion-read-transa.html

5. Да App Engine масштабируется автоматически, как интерфейсные экземпляры, так и база данных. Вам не нужно делать ничего особенного, чтобы масштабировать его, просто используйте их API.

6. Существуют ограничения на то, что вы можете делать с AppEngine:

   A. Нет локального хранилища (файловой системы) — вам нужно использовать Datastore или Blobstore.

   B. Comet поддерживается только через собственный API каналов.

   C. Хранилище данных — это база данных NoSQL: никаких JOIN, ограниченные запросы, ограниченные транзакции.

7. Стоимость GAE неплохая. Мы делаем 1 млн запросов в день примерно за 5 долларов в день. Самая большая экономия достигается за счет того, что вам не нужен системный администратор в GAE (но он вам нужен для EC2). По сравнению со стоимостью рабочей силы GAE невероятно дешев.

Несколько советов по экономии денег (ускорение) GAE:

О. Используйте get вместо query в хранилище данных (требуется тщательная разработка собственных ключей).

B. Используйте memcache для кэширования данных, полученных из хранилища данных. Это можно сделать автоматически с помощью objectify и его @Cached аннотации.

C. Денормализация данных. Это означает, что вы записываете данные избыточно в разных местах, чтобы получить к ним как можно меньше операций.

D. Если у вас много REST-запросов с устройств, где вы не используете куки, то отключите поддержку сессий (или накрутите свою, как мы). Сеансы используют хранилище данных под капотом и для каждого запроса, который он получает и отправляет.

Д. Узнайте об настройке параметров приложения. Попробуйте разные настройки (в зависимости от того, насколько терпимо ваше приложение к задержке и шаблонам/пикам трафика). Нам удалось сократить число экземпляров внешнего интерфейса на 70%.