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

Question

В настоящее время я ищу облачный PaaS, который позволил бы мне масштабировать приложение, чтобы обрабатывать что-либо между 1 пользователем и 10 миллионами пользователей + ... Я никогда не работал над чем-то таким большим и большим вопросом, который я могу ' Похоже, что четкий ответ на этот вопрос заключается в том, что если вы разрабатываете, скажем, стандартное приложение с реляционной базой данных и soap-webservices, оно автоматически масштабируется при развертывании в решении Paas или вам все равно нужно создавать приложение осенью сверх того, избыточность и все эти вещи на уме?

Допустим, я внедряю приложение Spring Hibernate в Amazon EC2 и создаю один экземпляр Ubuntu Server с установленным Tomcat. Будет ли это приложение масштабироваться бесконечно или мне нужно больше экземпляров Ubuntu? Если требуется более одного экземпляра Ubuntu, заботится ли Amazon о запуске приложения в обоих экземплярах или это ответственность разработчика? Как насчет хранения базы данных, могу ли я установить базу данных в EC2, которая будет масштабироваться по мере роста базы данных, или мне нужно вместо этого использовать один из их API, если я хочу, чтобы он масштабировался бесконечно?

CloudFoundry позволяет вам создавать локально и просто развертывать прямо на их PaaS, но, поскольку он находится в бета-версии, существует ограничение на количество ресурсов, которые вы можете использовать, и базы данных ограничены 128 МБ, если я правильно помню, так что это не идти на сейчас. Некоторые предлагали установить CloudFoundry на Amazon EC2, как он масштабируется и как обрабатывается слой базы данных?

GAE (Google App Engine), это позволит мне просто развернуть приложение и не беспокоиться о том, как оно масштабируется и реализует избыточность? Похоже, есть некоторые ограничения, которые вы можете и не можете использовать в GAE, и их повышение цен в последнее время расстроило довольно большое количество разработчиков, действительно ли это так дорого по сравнению с другими провайдерами?

Так в принципе, будет ли оно масштабироваться и что нужно сделать, чтобы его масштабировать?

Answer 1

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

1. Amazon EC2 не масштабируется автоматически при загрузке.EC2 - это просто виртуальная машина.Масштабирование экземпляров EC2 можно достичь с помощью Автоматическое масштабирование и Упругая балансировка нагрузки .

2. Базы данных SQL плохо масштабируются.Вот почему люди начали использовать базы данных NoSQL в первую очередь.Лучше всего посмотреть, какую базу данных ваш облачный провайдер предлагает в качестве управляемого сервиса: Хранилище данных в 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.Комета поддерживается только через их собственный API-интерфейс Channels

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

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

Некоторые подсказки, чтобы сэкономить деньги (ускорить) GAE:

A.Используйте метод get вместо запроса в Datastore (требуется тщательная обработка ключей).

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

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

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

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