У меня есть веб-сайт электронной коммерции, который ежедневно посещают около 30 000 пользователей с более чем 50 000 сеансов. Мы используем экземпляр RDS m5.xlarge. Мы не сталкиваемся с какими-либо проблемами как таковые при операциях чтения или записи повседневно. Но иногда мы сталкиваемся со следующими проблемами:
Глядя на это, я не могу решить, следует ли мне дополнительно вертикально масштабировать экземпляр RDS или развернуть реплику для чтения. Два момента, которые я хочу учитывать при принятии этого решения:
В среднем на экземпляре m5.xlarge я использую следующее:
Кажется, что это очень низкое использование, кроме ЦП, является ли реплика чтения способом достижения большей масштабируемости без увеличения затрат?
Похоже, что вам нужен RDS с автоматическим масштабированием, которого, к сожалению, не существует для вычислений.
Увеличить размер RDS
Если вы увеличиваете размер инстанса, вы платите больше 24/7. Это самое простое решение, которое должно уменьшить многие ваши проблемы. Если стоимость не является проблемой, это, вероятно, лучший вопрос.
Читать реплику
Другой важный вариант - это реплика для чтения. Вам придется изменить свое программное обеспечение, чтобы использовать реплику для чтения, поскольку у нее будет конечная точка, отличная от URL-адреса основной базы данных. Например, вы можете отправлять все записи в основную базу данных и все чтения в реплику для чтения. Реплика для чтения может немного отставать от обновлений от мастера. Возможно, вы даже сможете уменьшить размер основной базы данных, но вам нужно будет провести сравнительный анализ или быть консервативным в своем подходе.
Вы можете рассмотреть возможность создания реплики для чтения вручную перед любыми ожидаемыми крупными событиями. Это будет вручную и займет некоторое время, а вашему приложению придется работать с базой данных, которая иногда, но не всегда, присутствует.
Кеширование
В зависимости от ваших шаблонов доступа кэширование данных в Redis / Memcached потенциально может снизить нагрузку на базу данных настолько, что вам не потребуется обновлять базу данных. Это, конечно, зависит от необходимости читать одни и те же данные более одного раза и наличия достаточного объема кеш-памяти.
Аврора
Вы могли бы рассмотреть Amazon Aurora для MySQL. Я сам не использовал его, но он предназначен для очень хорошего масштабирования - хотя каждая отдельная транзакция может быть не такой быстрой, как стандартная RDS.
Оптимизация базы данных
Другой вариант - посмотреть, что отнимает емкость базы данных и оптимизирует «дорогие» запросы или индексы. Если у вас простые запросы и это просто высокая нагрузка, это может не помочь.