Тюним WordPress в AWS

Создание сайта на WordPress сейчас происходит очень просто и быстро. Много документации написано на этот счет. В AWS уже существуют предопределенные образы для виртуальных машин (вот, например), где все установлено и настроено. Несколько кликов мышкой и сайт функционирует, остается только выбрать тему, сделать минимальные настройки и загрузить контент. В этом посте расскажу, как сделать сайт на WordPress немного более надежным, защищенным и какие сервисы AWS для этого можно использовать. Отправной точкой будет созданный и функционирующий Web сайт, который запущен на одной виртуальной машине. То есть MySQL, PHP и сам WordPress установлены и настроены на одной машине.

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

Database

Первым шагом видится логичным разнести WordPress и базу данных по разным виртуальным машинам. В Amazon есть сервис RDS, который планируется использовать. Можно сервер баз данных запустить самому на виртуальной машине, ничего в этом сложного нет. Но тогда за доступностью, бэкапами и т.д. нужно следить самому. RDS же управляемый сервис, т.е. Amazon заботится о самом сервере базы данных (патчи, бэкапы, автоматическое восстановление в случае чего), пользователь же заботится и данных. Очевидно, что дешевле делать сервер самому, Amazon за RDS сервер берет дополнительные деньги.

Перед созданием RDS инстанции нужно создать «Subnet group», определить место в сети, где будет жить RDS инстанция. Для этого должен быть создан VPC и минимум две подсети. Так как мы строим высокодоступную архитектуру, то подсети должны находится в разных зонах доступности. Таким образом мы страхуемся от проблем, которые выведут всю зону доступности из строя.

Создание самой RDS инстанции очень простое. Выбираем тип, задаем логины-пароли и настройки самой базы, «Subnet group» и т.д. Для обеспечения высокой доступности не забываем выбрать Multi-AZ. Amazon поднимет две инстанции в разных зонах доступности, данные будут синхронно записываться в обе базы. Также вторая инстанция снимет нагрузку с первой при проведении бэкапов и апдейтов. Нужно будет задать «Maintenance window» — временное окно, во время которого Amazon будет делать бэкапы и апдейты. Есть один нюанс при создании файрвола (RDS security group). Если параметр «Public accessibility» выбран «No», то создается одно правило – доступ по порту 3306 (если не был выбран другой) для IP адреса компьютера, с которого производится создание RDS инстанции. Возможно, его нужно изменить, в зависимости от того, откуда будет производится работа с этой инстанцией.

Перенос данных для примера был сделан с MariaDB в MySQL. Эти базы совместимы, поэтому тут проблем не должно возникать. Если же миграция более сложная, то можно воспользоваться сервисами миграции данных. В моем случае было сделано просто:
$ mysqldump -u USER -pPASSWORD wordpressdb > dump.sql
$ mysql -h ENDPOINT -u USER -pPASSWORD rdswordpressdb < dump.sql
И все, данные перенесены.
Затем нужно переопределить переменные в файле wp-config.php:
define(‘DB_NAME’, ‘rdswordpressdb’);
define(‘DB_USER’, ‘USER’);
define(‘DB_PASSWORD’, ‘PASSWORD’);
define(‘DB_HOST’, ‘ENDPOINT’);

Изменяемые данные

Разделяем статические и динамические данные. Схемы, плагины и загрузочные файлы хранятся в папке «wp-content». Видится логичным отделить эти данные от остальных, переложив их на общий ресурс и подключать к Web серверу во время загрузки. Так мы сможем сделать Web сервер stateless. Для этих целей будем использовать сервис Amazon Elastic File System. Итак, создаем файловую систему, несколько кликов в консоли. Тут нет никаких подводных камней, разве что нужно обратить внимание на настройки файрвола (RDS security group), EFS должна быть доступна с Web сервера. После создания к файловой системе можно будет обращаться через EFSENDPOINT. Далее просто монтируем ее на Web сервер:
$ sudo mv wp-content wp-content.orig
$ sudo mkdir wp-content
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 EFSENDPOINT:/ wp-content
$ sudo cp -r wp-content.orig /* wp-content /
И добавить соответствую строчку в /etc/fstab, для того, чтобы EFS подключалась во время загрузки. Теперь из этой виртуальной машины можно сделать образ и использовать его для автоматического масштабирования.

Auto-scaling

Далее нужно настроить автоматическое масштабирование. Делать это будем как описано в документации, по шагам

  1. Создание Target Group
    Тут важно указать порт, на котором работает Web сервер. Сейчас это 80. Если при конфигурации Web сервера указывался другой, но нужно указать его. Можно также изменить параметры Health Check, но можно оставить это на потом.
  2. Получение сертификата безопасности.
    Этот шаг опциональный, конечно, и к Auto-scaling отношение не имеет. Нужно указать имя домена, для которого выпускается сертификат и несколько минут подождать пока сертификат будет выпущен. Кстати, если этот сертификат использовать для балансировщик нагрузки, то плата за сертификат не взимается.
  3. Создать балансировщик нагрузки
    Здесь хочется отметить несколько нюансов. Балансировщик будет Application Loda Balancer и будет виден извне. «Слушать» будем только HTTPs, то есть на 443 порту и использовать только что выпущенный сертификат. А вот передавать от балансировщика в Target Group будет по HTTP, то есть по 80-у порту.
    После создания балансировщика будет доступно его DNS имя, которое можно прописать как A-record в настройках вашего домена.
  4. Создание Launch Configuration.
    В данной конфигурации описано что мы будем запускать, если там нужно будет увеличить количество инстанций. Для создания конфигурации потребуется настроенный образ виртуальной машины, который у нас уже создан. Процесс создания очень похож на «урезанный» процесс запуска инстанции. Единственное, на чем хочется заострить внимание – это выделение публичных IP адресов для виртуальных машин. Если в настройках выставить «Do not assign a public IP address to any instances.», то эти машины не будут видны извне, кроме как через балансировщик. Это своего рода защита Web серверов.
  5. Создание Auto Scaling group
    На последнем шаге необходимо создать группу Auto Scaling – набор правил, по которым количество сервером в группе будет увеличиваться/уменьшаться. Важным моментом тут является указание того, что трафик мы будет получать от балансировщика, о чем необходимо упомянуть в «Advanced Details». Правила зададим следующие: масштабироваться будем от одной до четырех инстанций; будем прибавлять один сервер, если CPU utilization превысит 70% на протяжении 5 минут; будем выключать один сервер, если CPU utilization станет меньше 40% на протяжении 5 минут.

После создания Auto Scaling group запустится одна инстанция, добавится в Target Group и будет доступна по https://domainname. Возможно, еще потребуется некоторые изменения в настройках Web сервера для обеспечения работы HTTPs

Заключение

После всех этих манипуляция Web сайт становится гораздо более доступным и защищенным. Однако есть еще несколько вещей, которые можно имплементировать. Например, использовать Amazon CloudFront для доставки/кэширования контента, что увеличит скорость отклика Web сайта. Особенно если сайт предназначен для глобальной аудитории. Также можно выстроить уровень кэша перед Web сервером или перед базой данных с использованием управляемого сервиса Amazon ElastiCache for Memcached, увеличив тем самым производительность сайта. Для этого существуют уже написанные плагины, которые можно установить и настроить.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *