Конфигурация Amazon Cloud для веб-приложения Java EE с MySQL

Question

В своей работе мне нужно переместить некоторые существующие приложения Enterprise Java в AWS.Я просмотрел много страниц на aws.amazon.com и также достаточно погуглил.Кроме того, я попытался пройти через все связанные вопросы в stackoverflow.Все это прояснило многие вещи, однако, я все еще испытываю некоторую путаницу.Вот наша структура приложения:

1. Это приложение на основе Spring, которое использует Spring MVC в качестве уровня представления и простые Java-интерфейсы и классы для обработки логики бизнеса и данных.
2. MySQL - этоиспользуется для постоянства.

Итак, архитектура приложения достаточно проста.Однако выгода заключается в том, что нам нужно развернуть множество экземпляров этого приложения.В настоящее время это число составляет 15 и может превышать 30. Еще один момент заключается в том, что все эти экземпляры совместно используют общую базу данных.

Теперь вот что нам нужно достичь, перейдя в AWS:

1. Более высокая отказоустойчивость для применения.Недавно мы столкнулись со сбоем в работе сервера / источника питания на выделенном хостинге, что привело к простоям на несколько часов.
2. Более высокая производительность для всех экземпляров приложения с точки зрения времени отклика и пропускной способности.
3. Более высокая отказоустойчивость дляMySQL.Экземпляры приложений на одном из наших серверов недавно вышли из-за аппаратного обеспечения (жесткого диска), которое в основном привело к неожиданной остановке MySQL.Вся файловая система на жестком диске стала доступной только для чтения, что привело к сбоям в работе экземпляров приложений, размещенных на этом сервере.
4. Очевидно, что сократились общие затраты и затраты на управление инфраструктурой.

Насколькотак как я могу понять инфраструктуру AWS до сих пор, вот что нам нужно в AWS для нашей настройки:

1. 4 экземпляра, каждый из которых содержит около 10 экземпляров приложения, некоторых LINUX AMI на основе EBS с Tomcatи MySQL установлен на этом.
2. Я предполагаю, что нам также понадобится 1 экземпляр для отказоустойчивости для каждого из этих 4 экземпляров, всего 8 экземпляров.
3. Все экземпляры сервера будут иметьоколо 160 ГБ EBS.
4. 4 эластичных IP-адреса
5. 4 эластичных балансировщика нагрузки
6. Другие вещи, такие как снимок и т. д.

Теперь вот мои вопросы:

1. Нужно ли мне иметь этот дополнительный экземпляр сервера (для отказоустойчивости) для каждого экземпляра основного сервера, учитываяПеред лицом того, что EBS автоматически резервируется AWS, и они предоставят новые EBS с такими же данными в случае аппаратного сбоя?

2. Как бы я поделился базой данных между всеми экземплярами сервера (4x2) ввыше сценарий?Один вариант, который я вижу, состоит в том, чтобы реализовать кластеризацию MySQL среди этих экземпляров сервера.Допустим, кластер MySQL будет содержать 1 узел управления, 3 узла SQL и 4 узла данных.Однако в этом случае поддержание кластера будет для нас дополнительной нагрузкой, и это может быть не принято, поскольку мы хотим избавиться от управления инфраструктурой.

3. Нужно ли мне вместо этого использовать RDS?для базы данных и удалить экземпляры MySQL со всех серверов (4x2)?Если да, нужно ли мне покупать экземпляры RDS в дополнение к экземплярам EC2 (я думаю, если мне нужно будет покупать отдельные экземпляры для RDS, тогда стоимость всей инфраструктуры увеличится как минимум на 75%), или экземпляры RDS также дадут вычислительные единицыдля разработки приложений, таким образом уменьшая общее количество экземпляров для развертывания приложений?

4. В случае реализации RDS, действительно ли нужны экземпляры EC2 на основе EBS?Если мы сможем каким-то образом удалить требование EBS из экземпляров EC2 с установленными экземплярами RDS, мы сможем уменьшить общую стоимость.

Любая помощь будет принята с благодарностью, и, пожалуйста, дайте мне знать, если я неясно, чтобы указать мою проблему, и нужно больше разъяснений по любому вопросу.

Answer 1

Я не эксперт по инфраструктуре, но у меня есть некоторый опыт работы с AWS, и я надеюсь, что смогу помочь хотя бы с некоторыми из ваших вопросов.Мой опыт работы не позволяет мне давать вам какие-либо советы по поводу размера вашей инфраструктуры, но я могу помочь с рекомендациями по поводу типа инфраструктуры.
Прежде всего, я бы определенно пошел с EBS.Помимо того, что он физически отделен от вашего сервера приложений, он также обладает высокой надежностью и высокой доступностью.Я могу сказать вам, это спасло меня пару раз.Хотя я и сказал, что не скажу вам ничего о размере, я не думаю, что вам понадобятся дополнительные 4 экземпляра «отказоустойчивости», но, возможно, вы могли бы оставить наготове около 2 экземпляров для отвода трафика, на всякий случай.

Что касается вашей БД, вам определенно следует пойти дальше и использовать RDS для MySQL (http://aws.amazon.com/rds/mysql/). Они предоставляют вам предварительно сконфигурированные узлы, автоматическое исправление, автоматическое резервное копирование, автоматическую репликацию и масштабирование в один клик, в(IMHO) небольшая цена. Все эти функции готовы, из коробки, для MySQL. Вы также можете использовать метрики и мониторинг, все это включено. RDS не дает вам вычислительные единицы, но этоРекомендуется хранить их отдельно в AWS. У вас также может быть установка с 4 узлами EC2 Tomcat + 2 узлами RDS. Это просто вопрос размеров :)

Если вы уже читали о Amazon Elastic Load Balancingвыглядит идеально подходит для вашего решения.Вы можете присоединить несколько узлов EC2 к каждому из ваших узлов ELB и забыть о балансировке нагрузки.Это просто работает, и вы также можете настроить липкие сессии, если хотите.Однако я не знаю, сколько узлов ELB вы должны выбрать, но помните об одной проблеме: вы можете добавлять узлы EC2 из одного географического региона (например, восточное побережье США) в один и тот же ELB.Невозможно сбалансировать трафик, например, между Tomcat на Западном побережье и другим на Восточном побережье.Если вы решите распределить свои узлы по нескольким регионам, вам потребуется другое решение LB за пределами Amazon.

Мой последний совет: продолжайте с ECB + RDS на базе ELB + EBS.Это значительно упростит ваш мониторинг, развертывание и обслуживание, а стоимость, как правило, будет намного ниже.Вы, вероятно, больше знаете о том, сколько узлов каждого типа вам понадобится, но не бойтесь пропустить, потому что на AWS очень просто увеличить или уменьшить масштаб вашей инфраструктуры.