У меня есть сайт WordPress, который на данный момент я полностью использую Amazon Lightsail пример. Он получает надлежащее резервное копирование; доступность в порядке; безопасность хорошая; это простая установка. Все хорошо.
Я хочу улучшить доступность и время загрузки, переместив сайт в Amazon Elastic Beanstalk и внесение некоторых других важных изменений в серверную часть сайта (обеспечение независимости базы данных сайта от сервера PHP, переход на nginx и т. д.). Это было бы хорошо по множеству причин, главная из которых: EBS - это просто более надежный сервер, чем Lightsail.
В Руководство, предоставленное Amazon для создания сайта WordPress на Beanstalk советует монтировать только /wp-content/uploads/ на Amazon Elastic File System, и сценарий конфигурации по умолчанию делает это за клиента. Обратной стороной этого является то, что основные файлы WordPress не передаются между экземплярами EC2; вместо этого они реплицируются в каждом экземпляре, поэтому запуск процесса обновления WordPress на вашем сайте означает, что некоторые экземпляры фактически не обновляются, что приводит к нежелательному поведению.
В руководстве рекомендуется обновить WordPress (и плагины), выполнив ужасный процесс экспорта всего содержимого сайта с помощью инструмента экспорта WordPress (бета) и его повторного импорта с помощью инструмента импорта (бета) в новую среду Beanstalk, в которой работает обновленный WordPress.
Я не категорически против автоматизации этого процесса, чтобы мне было проще обновлять WordPress, но я ценю оставаться в курсе обновлений, поэтому я хочу оптимизировать для этого, и я скептически отношусь к тому, что лучшее решение для меня (или любого клиента) - использовать бета-инструменты импорта и экспорта WordPress в процессе обновления системы или плагина.
Например, иногда эти обновления являются обновлениями безопасности, для которых WordPress предлагает автоматическую систему исправлений, что очень желательно для максимальной безопасности сайта. Однако это автоматическое исправление не будет работать должным образом, если основные файлы WordPress не будут совместно использоваться экземплярами EC2 из-за проблемы обновления, которую я уже описал.
При этом сказано:
С какими архитектурными или системными проблемами я могу столкнуться, если помещу все свои файлы WordPress, а не только /wp-content/uploads/ каталог - на общем хранилище EFS?
Я, конечно же, проведу собственное тестирование, чтобы увидеть, как идут дела, но я хочу знать, на что обращать внимание, если что, и где устанавливать свои ожидания, когда я пытаюсь это сделать.
(Осторожно: я не эксперт, но искал вопрос без ответа, чтобы вернуть его на serverfault.com)
Сначала я бы занялся масштабированием Lightsail. Документы (https://aws.amazon.com/lightsail/features/) обсуждают наличие нескольких экземпляров с балансировщиком нагрузки. Вы пробовали это? Ознакомьтесь с мониторингом CloudWatch, чтобы узнать, насколько загружены ваши экземпляры. Горизонтальное масштабирование позволяет сократить время отклика. Кроме того, вы можете расширить Lightsail, чтобы использовать автономные экземпляры базы данных.
На мой взгляд, Word Press - чудовище, когда дело касается вычислительной эффективности. Он может загружать сотню скриптов для выполнения одного запроса. Обрезка может помочь. Есть ненужные плагины? Можно ли объединить код в меньшее количество модулей? Вероятно, для этого есть инструменты оптимизации / профилирования, которые могут помочь вам ускорить ваш сайт.
Кроме того, подумайте, какая часть вашего сайта является статической, а не вычислительной. Выгрузка статических файлов в AWS S3 - отличное решение. Кроме того, реализация кеша CDN (например, AWS CDN) может сократить время отклика при загрузке страниц, не связанных с вычислениями, а также потенциально перемещать контент ближе к тому месту, где находятся ваши пользователи. И, наконец, часто забывают, сколько HTTP-запросов нужно сделать вашим пользователям для загрузки данной страницы. У вас есть много JS-библиотек, которые нужно загрузить? Рассмотрите возможность объединения их в один файл, который можно загрузить за одну транзакцию. Использование инструментов разработчика браузера в Chrome или Firefox действительно может помочь вам определить причину задержки.
Если вы хотите использовать подход к управлению своими серверами, обновление WP можно выполнить более простыми способами. Я предлагаю вам начать использовать контейнеры Docker. Затем вы можете просто запустить один образ на N серверах и поддерживать каждый из них в актуальном состоянии. Используйте AWS ECR для своего изображения. Если вы хотите обновить WP или плагины, вы создаете новую версию образа контейнера. Затем используйте AWS EKS или Fargate, чтобы развернуть новую версию постепенно. Все это часть темы домашние животные против крупного рогатого скота. Вы не выполняете обслуживание отдельных серверов (контейнеров), но если есть изменения, вы выбрасываете старые и развертываете новые.
Но после всего этого, если вы все еще хотите пойти по пути общего хранилища, я бы не предлагал вам использовать EFS. С этим вы не получите безопасности. Вместо этого я бы запустил файловый кеш S3 на каждом сервере. Он будет извлекать файлы локально всякий раз, когда они изменяются в S3, поэтому изменения будут доступны всем. Пример кеша https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon .
Я бы провел тестирование, чтобы увидеть, есть ли какие-либо записи в файлы WP во время работы. Если есть и то, что написано, зависит от экземпляра, вам придется сохранить эти каталоги как локальные на сервере.