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