Мы развертывали стандартную конфигурацию веб-сервера для основного программного обеспечения CMS, такого как Drupal и WordPress, с сервером и хранилищем на EC2 / EBS и базой данных для этих программных пакетов в RDS / MySQL.
Обычно мы начинаем производство с t2.micro ЦП и db.t2.micro DB, что делает клиентов счастливыми с нами и AWS, поскольку они часто могут оставаться на уровне бесплатного пользования в течение первого года. Инструменты мониторинга по умолчанию на EC2 ясно показывают, когда мы можем превышать самый дорогой ресурс для веб-хоста, а именно: Загрузка ЦП. Если порог приближается или превышает 10%, значит, мы знаем, что пришло время перейти на t2.small тип экземпляра.
Мы гораздо менее уверены, как определить, когда нам может потребоваться обновление с db.t2.micro к db.t2.small и, возможно, за его пределами. Эти требования не связаны с несколькими зонами доступности или репликами чтения, а только с условиями, когда программное обеспечение CMS может сильно зависеть от базы данных в периоды пиковой нагрузки, которые нам нужно будет определить с помощью графика или сигнала тревоги.
В документы для инстансов EC2 четко указать, каковы их собственные ограничения, и мне было интересно, можно ли рекомендовать какие-либо такие ограничения для экземпляров RDS для нашего простого случая. Общие требования в их Лучшие практики для Amazon RDS полезны, хотя я не перешел по всем ссылкам, поскольку я просто пытаюсь установить пороговые значения, которые мы можем установить, которые явно потребуют обновления экземпляра БД таким образом, чтобы мои нетехнические клиенты могли понять и наблюдать.
Признаюсь, я не администратор базы данных; По роду своей работы я оставил архитектуру базы данных разработчикам программного обеспечения CMS. Я, безусловно, готов изучить основы оценки производительности, если кто-то скажет мне, с чего начать, поскольку это относится к этой конфигурации на платформе AWS. Может быть, я просто еще не нашел нужных официальных документов или руководств.
В качестве альтернативы: нам просто нужно знать, как количественно измерить, если какая-либо задержка в доступе к нашему экземпляру RDS является результатом слишком маленького размера экземпляра (или, возможно, параметров ресурсов MySQL, установленных слишком низко), в зависимости от того, что мы видим в CloudWatch.
Очевидно, я могу сказать, что метрика CloudWatch Свободная память приближается к нулю, тогда нам потребуется обновление экземпляра. И, как и в случае с нашим экземпляром EC2, также должно быть максимум Загрузка ЦП что, я думаю, будет намного ниже 100%, хотя, опять же, я не видел этого задокументированного, как для EC2. Я полагаю, что практический максимум для Подключения к БД. Наконец, я надеюсь, что кто-нибудь подскажет мне, как интерпретировать Запись IOPS и чтение IOPS и будут ли они налагать ограничения на производительность для небольших конфигураций, таких как наша, или если они просто используются для расчета стоимости.
p.s., я пытался выложить это на Форумы AWS: Amazon Relational Database Service но Опубликовать новую тему ссылка в настоящее время дает "цикл перенаправления". (Извините, я не могу включить сюда больше URL, но мне это не разрешено.)
[редактировать, ответ на комментарий] спасибо @ Росс, я не знал CPUCreditBalance также был доступен на RDS (я видел его на EC2); не видел, что есть второй экран с еще 7 метриками, все 17 которых можно выбрать из списка. Мне все еще интересно, какие ограничения могут быть наложены на контролируемые ресурсы, кроме ЦП, особенно на активность ввода-вывода, в зависимости от типа экземпляра RDS.
p.p.s., я немного уточнил вопрос и опубликовал его на форумах AWS (Как определить подходящий размер экземпляров RDS T2 с помощью статистики CloudWatch?)
У меня было некоторое представление об этом в последние несколько месяцев, и я считаю, что эти предметы, которые нужно посмотреть, решат все проблемы, указанные выше:
1) Комментарий от @Ross к исходной публикации является ключевым. Инстансы T2, независимо от их масштаба и независимо от того, являются ли они EC2 или RDS, перестанут работать, когда их ресурсы ЦП закончатся, поскольку пиковые требования ЦП продолжаются.
2) Режим отказа веб-сервера CMS, который мы видели чаще всего, определяется именно этим условием: график CloudWatch опускается к нулю, когда процент ЦП, необходимый для httpd процессов превышает процент ЦП, назначенный этому типу экземпляра (см. ссылку на документ ниже).
3) Быстрое решение для инстанса T2, у которого исчерпаны ресурсы ЦП, - выключить, обновить тип инстанса и снова запустить инстанс, что занимает около 3-4 минут. Наиболее важное описание возможностей различных типов инстансов находится здесь: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html
4) Любой производственный веб-сервер на AWS должен иметь заранее назначенный эластичный IP-адрес по этой причине: в противном случае и масштаб экземпляра будет изменен, IP-адрес изменится, в результате чего веб-сервер станет недоступным далеко за пределами того, что в противном случае было бы только 3- 4 минуты простоя.
5) Единственный способ получить больше кредитов ЦП - это обновить тип машины. Количество кредитов, которое может содержать каждый размер экземпляра T2, описано в приведенной выше ссылке на документ: оно всегда равно работе ЦП, которую этот тип экземпляра будет выполнять за 24 часа.
6) Машину можно вернуть в исходное состояние во время запланированного простоя (опять же, 3-4 минуты) после того, как снизятся требования к максимальной производительности.
7) Операции ввода-вывода пока не привели к снижению производительности нашего веб-сервера в пиковые периоды. Количество операций ввода-вывода в секунду определяется строго размером тома EBS. Как точное значение IOPS, так и эта взаимосвязь описаны здесь: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html
8) Ни одна из метрик Cloud Watch Свободная память ни Подключения к БД были полезны для прогнозирования или исправления проблем с производительностью в среде с интенсивным использованием веб-серверов.