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

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

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

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

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

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

Ответ 1

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

Amazon EC2 автоматически не масштабируется с нагрузкой. EC2 - это просто виртуальная машина. Вы можете добиться масштабирования экземпляров EC2 с помощью Автомасштабирование и Эластичная балансировка нагрузки.
Базы данных SQL плохо масштабируются. Поэтому люди начали использовать базы данных NoSQL. Лучше всего посмотреть, какую базу данных предлагает ваш облачный провайдер в качестве управляемой службы: Datastore в GAE и DynamoDB на Амазонке.
Установка собственной базы данных в экземплярах EC2 очень непрактична, поскольку EC2 имеет ephemeral storage (при перезагрузке он теряет все данные на диске).
GAE Datastore - фактически одна большая база данных для всех приложений, работающих на ней. Таким образом, он довольно масштабируемый - ваш миллион пользователей не должен быть проблемой для него. http://highscalability.com/blog/2011/1/11/google-megastore-3-billion-writes-and-20-billion-read-transa.html
Да App Engine автоматически масштабируется, как внешние экземпляры, так и база данных. Нет ничего особенного, чтобы сделать его масштабным, просто используйте их API.
Существуют ограничения, которые вы можете сделать с AppEngine:

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

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

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

Некоторые подсказки для экономии денег (ускорение) GAE:

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

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

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

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

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