Готово ли Cloud для веб-приложения Enterprise Java? Поиск рекомендации по размещению Java EE

Приветствуем всех умных людей здесь!

Я хотел бы спросить, возможно ли вообще или вообще хорошая идея развернуть веб-приложение предприятия Java в Cloud, такое как Amazon EC2. Точнее, я ищу варианты инфраструктуры для приложения, которые будут обрабатывать несколько сотен пользователей с длинными, но не активными сессиями процессора и памяти. Я рассматриваю выделенные серверы, виртуальные частные серверы (VPS) и EC2. Я заметил, что существует проект под названием JBoss Cloud, так что люди работают над возможностью такого развертывания, с другой стороны, похоже, что он еще не зрел, и я не уверен, что облако уже готово для такого типа приложений, которые отличаются от типичных облачных приложений, таких как Twitter. Вы порекомендовали бы развернуть его в облаке? Каковы плюсы и минусы?

Приложение представляет собой веб-приложение Java EE 5, основная функция которого заключается в том, чтобы позволить пользователям составлять свой собственный продукт, объединяя доступные детали. Он использует сеансы без состояния и состояния beans и JPA для сохранения сущностей в РСУБД и получает информацию о частях из системы инвентаризации компании через веб-службу. Помимо внешних пользователей, он также используется несколькими внутренними, которые аутентифицированы против компании LDAP. Приложение должно обрабатывать около 300-400 одновременных пользователей, строящих свой продукт, и должно быть достаточно масштабируемым и доступным, хотя эти качества на данном этапе имеют лишь среднюю важность.

Я предложил архитектуру, состоящую из брандмауэра (FW) и балансировки нагрузки, поддерживающих липкие сессии и https (в Cloud это будет заменено EC2 Elastic Load Balancing service и FW на серверах приложений в физической архитектуре балансировщик нагрузки будет HW), а затем два физических кластерных сервера приложений в сочетании с веб-серверами (так что если один из них не удастся, пользователь не потеряет свой долговечный продукт) и, наконец, сервер базы данных. Серверу БД понадобится подчиненный экземпляр резервной копии, который может заменить основной экземпляр, если он терпит неудачу. Это должно обеспечить разумную доступность и отказоустойчивость и обеспечить хорошую масштабируемость, если одна RDBMS может поддерживать нагрузку, которая должна быть в порядке в течение долгого времени, поскольку большинство операций выполняется в памяти с использованием состояния bean и только иногда хранятся или извлекаются из БД, и количество данных также низкое. Проблематичной частью может быть зависимость от веб-службы удаленной инвентаризации, но с хорошим кэшированием ее выходов в приложении тоже должно быть ОК.

К сожалению, я имею лишь смутное представление о системных ресурсах (размер памяти, количество и скорость процессоров/ядер), что такое "среднее приложение Java EE" для нескольких сотен пользователей. Моя грубая и в основном необоснованная оценка, основанная на реальных предложениях Amazon, заключается в том, что для любого из двух серверов приложений должно быть достаточно 1,7 ГБ и одного двухъядерного "современного процессора" со скоростью около 2,5 ГГц (High-CPU Medium Instance) поскольку мы можем справляться с большей нагрузкой, предоставляя им больше). В качестве альтернативы я бы рассмотрел использование экземпляра Large (64b, 7,5 ГБ ОЗУ, 2 ядра на частоте 1 ГГц).

Итак, мой вопрос заключается в том, насколько такое развертывание в облаке технически и финансово осуществимо или будут ли выделенные/VPS-серверы лучшими, и есть ли какие-то реальные события с чем-то похожим.

Большое спасибо!/Якуб Святой

PS: Я нашел JBoss EAP в облачном примере, который показывает, что можно развернуть реальный Java EE приложение к облаку EC2, но, к сожалению, нет деталей относительно топологии, типов экземпляров или чего-либо: - (

Ответ 1

Я обслуживаю "несколько сотен пользователей" из одного экземпляра EC2 High-CPU Medium. Нет балансировки нагрузки, нет выделенных серверов БД, ничего необычного. Просто один ящик. Кроме того, я использую некоторые службы:

  • Эластичный блок Store для данных MySQL, MySQL binlogs и индексов Lucene
  • S3 для ресурса и резервного хранилища, очевидно, разные корзины для каждого
  • SimpleDB Метаданные для ресурсов
  • CloudFront для ресурсов - главным образом потому, что мы можем:)
  • Простая служба очереди для обмена сообщениями (используется для очереди некоторых фоновых задач)

Как я уже сказал, ничего необычного - по крайней мере, в среде Amazon cloud. И все за менее 200 $/месяц. Что касается ценообразования, вы должны позаботиться об этом. Amazon неплохо справилась с запутыванием основных расходов. Например, глядя на CloudFront Pricing, вы можете посмотреть 0,15 $за ГБ, но игнорировать 0,01 $за 10 000 - это смехотворно маленькая цена за много запросов, не так ли? Большой сюрприз: 2/3 нашей стоимости CloudFront для запросов (около 3 КБ на запрос). Запросы ввода-вывода для EBS - это аналогичная история.

Как было бы очень легко масштабировать (используйте больший экземпляр, переместите БД на Служба реляционной базы данных). Я предлагаю вам начать с та же настройка. Как вы сказали, бросать больше ящиков в довольно просто (если ваша установка поддерживает добавление/удаление узлов на лету). Это позволяет выбрать подходящую настройку путем проб и ошибок, что легко выполнимо - некоторые тщательные испытания нагрузки должны выполнять эту работу. Выберите то, что работает для вашей ожидаемой нагрузки (плюс дополнительная мощность), и увеличивайте/уменьшайте, как только у вас есть производственные данные.

В заключение: да, конечно, возможно разместить Java EE-приложения на EC2:)

Изменить: как примечание: сравнение цен EC2 с традиционным хостингом - сравнение яблок и апельсинов - по крайней мере, пока вы не получите SLA для своей сети, почти неограниченную масштабируемость, отсутствие аппаратных проблем, почти неограниченное количество и избыточное хранилище, различные зоны доступности и множество дополнительных сервисов. Если кто-то скажет вам, что традиционный хостинг дешевле, он может быть системным администратором, который беспокоится о своей работе;) Не поймите меня неправильно, это дешевле - но вы получите гораздо меньше за меньшие деньги.

И, кстати, я никоим образом не связан с Амазонией... но я чувствую, что я должен быть вознагражден за то, что был хорошим представителем, не так ли?: D