Назад | Перейти на главную страницу

Что следует учитывать при выборе типов инстансов AWS EC2 для горизонтального масштабирования

Я собираюсь масштабировать приложение на 100 000 пользователей. Приложение размещено на NodeJS. Я создал образы докеров для своего приложения, а также с помощью AWS ALB и т. Д. Мое приложение невелико, и меня больше всего беспокоит количество пользователей, которые попадут в приложение. Приложение занимает всего 600 МБ памяти (макс.) Для контейнера. Итак, я использовал 8 экземпляров t2.small (машина с 2 ГБ ОЗУ) и разместил по 3 контейнера в каждом экземпляре (т.е. 8 X 3 = 24 контейнера (по 3 в каждом контейнере)). С этой архитектурой я могу масштабировать это до 5000 пользователей. Я могу масштабировать это по горизонтали до 100 000 пользователей, но меня беспокоит, что, если я выберу m4.large вместо машины t2.small, которую я выбрал.

Поскольку вместо использования 8 машин t2.small (8 X 2 ГБ = 16 ГБ) мы также можем использовать 2 машины m4.large (2 X 8 ГБ = 16 ГБ). А также может разместить в нем 24 контейнера.

Почему я выбрал экземпляры t2.small, так это значение vCPU. И t2.small, и m4.large имеют 2 виртуальных ЦП. Итак, если мы возьмем 2 машины m4.large, для этих 24 контейнеров будет 4 виртуальных ЦП. Но если мы пойдем с 8 экземплярами t2.small, мы получим 16vCPU для этих 24 контейнеров.

Но есть ли еще какие-то факторы, которые мне нужно учитывать? Любой совет будет очень признателен.

Экземпляры типа m оптимизированы для памяти, если память не требуется, экземпляры m, вероятно, не являются правильным выбором. Это сильно зависит от вашего приложения и требований к ресурсам под нагрузкой.

Фактором является стоимость и динамическое масштабирование, которое зависит от ситуации. Если вам нужна высокая доступность, необходимы как минимум два экземпляра. Учитывая ваш сценарий 2 x m4, это будет означать, что у вас в любой момент времени есть ресурсы, необходимые для работы со 100% нагрузкой. Обычно приложения имеют пиковые периоды и времена, когда требуется лишь небольшая часть ресурсов. Переход на 8 x t2 будет означать, что вы можете сократить ресурсы до 25% от требуемых, сохраняя при этом высокую доступность. Все эти соображения действительно сказываются на цене.

Предложить, чтобы:

  • определить базовое количество пользователей (минимальное выделение ресурсов).
  • разделите это значение на требуемый коэффициент высокой доступности (например, два).
  • образец типичных пользовательских запросов в нагрузочном тесте (например, jmeter), спроектируйте плотность нагрузочного теста для соответствия расчетным значениям
  • запускать различные типы экземпляров, которые могут удовлетворить потребности (не используйте балансировщик нагрузки для этих тестов)
  • отслеживать их во время выполнения нагрузочного теста (например, ЦП, память), чтобы определить, какой тип лучше всего подходит для вашего приложения
  • соответственно спроектируйте автомасштабирование (используйте опыт нагрузочных тестов в качестве отправной точки для масштабирования триггеров)
  • избыточное обеспечение в зависимости от поведения спроса (пользователей)
  • если встроено предварительное масштабирование до времени пиковой нагрузки