Оценка ограничений параллелизма для архитектуры AWS под управлением WordPress

Я пытаюсь оценить количество одновременно работающих пользователей, которых может выдержать установка WordPress AWS (она должна быть высокой доступности и поддерживать огромные нагрузки). Меня просят о свободном диапазоне, который, я бы сказал, мы можем гарантировать (они спросили парня, который плохо знаком с DevOps...).

Архитектура выглядит следующим образом:

  • Два РДС r5.2xlarge экземпляры (Main + Read replica) для БД.
  • Группа автоматического масштабирования, управляющая от 1 до 25 t2.2xlarge EC2 экземпляры.
  • CloudFront как CDN для контента.

Некоторые условия о приложении:

  • Есть около 1300 публикаций.
  • Каждая страница весит от 200 Кб до 3 Мб (очень редко), в основном это около 500 Кб.

Очевидно, что цель состоит в том, чтобы иметь "разумное" время отклика, хотя мне не сказали о диапазоне.

Под параллельными пользователями я подразумеваю одновременные петиции или обращения. Я бы с удовольствием проверил это, но, к сожалению, мне нужно много платных ресурсов.

Я действительно не знаю, что является правильным основанием для применения здесь. Самая полезная и связанная с этим вещь, которую я нашел до сих пор, заключается в следующем - однако, условия совершенно другие, и мы не можем реально взять числа и линейно их масштабировать. Автор поста измерил это с 18 t2.medium в случаях, когда скорость составляет 60%, можно запускать WP с 90 RPS и поддерживать время отклика около 350 мс. Распространение этого вывода на мою архитектуру ускользает от моего понимания.

В идеале, помимо ответа на мою проблему, я хотел бы получить метод для получения правильных ответов на эти вопросы.

Источник

1 ответ

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

В любом случае пара замечаний:

  • Если вы проектируете свою архитектуру так, чтобы она была действительно масштабируемой на всех уровнях - доставка контента (Cloud Front), веб-серверы (без сохранения состояния, одноразовые), хранилище файлов (EFS, S3), база данных (например, Aurora, реплики только для чтения) - тогда вы не нужно заботиться о том, сколько пользователей может поддерживать конкретная конфигурация. Если спрос будет ниже или выше, архитектура будет просто масштабироваться для удовлетворения спроса.

  • Кажется, ваша архитектура находится на правильном пути для масштабируемости, поэтому я думаю, что лучший способ - это подтвердить концепцию и провести профессиональное нагрузочное тестирование. Есть компании, которые могут сделать это из географически разбросанных мест. Это покажет вам, как работает ваш дизайн, и оттуда вы сможете интерполировать различные конфигурации, необходимые для различных одновременных пользовательских номеров.

  • Предупреждение о типах экземпляров T2 - они используют так называемые кредиты ЦП, которые заставляют их работать быстро в течение короткого периода времени, а затем замедляются. Когда они простаивают, они снова накапливают эти кредиты и в течение некоторого времени могут снова работать быстрее. Это отлично подходит для рабочей нагрузки, которая идет в шипах, но для устойчивой нагрузки вам лучше использовать, например, типы экземпляров M5 (например, m5.large) - они обеспечивают стабильную производительность.

  • Лучше иметь большее количество меньших экземпляров (например, 20x m5.large) вместо меньшего количества больших экземпляров (например, 5x m5.2xlarge) - масштабирование увеличивается и уменьшается, производительность диска выше, отказ одного узла не не имеет такого большого влияния и т. д.

  • Подумайте об использовании экземпляров Spot и парков Spot для дополнительной экономии затрат на экземпляр.

  • Вы упомянули, что обслуживаете несколько публикаций - если это статические PDF-документы, вам будет гораздо удобнее хранить их в S3, и CloudFront будет читать их непосредственно из S3, не обращаясь к WordPress вообще. Если они не являются общедоступными и нуждаются, например, в подписке, посмотрите подписанные URL-адреса CloudFront / S3. Это значительно снизит нагрузку на ваши серверы WordPress.

Надеюсь, это поможет:)

Источник
Другие вопросы по тегам