Я занимаюсь настройкой решения для масштабирования веб-сайта typo3 9 на aws.
Моя установка выглядит примерно так:
Существует экземпляр EC2 в виде WriterNode, который может использоваться для публикации sh контента. Каталог /var/www/mysite синхронизируется через задание cron с частным сегментом S3 (через aws s3 sync ...). /var/www/mysite/fileadmin синхронизируется с другим пабом c S3, который служит точкой входа для моего облачного фронта cdn. RewriteRule перезаписывает каждый запрос к / fileadmin / * к URL-адресу cdn.
И есть моя группа автоматического масштабирования, которая содержит n экземпляров EC2 в качестве ReaderNodes. Экземпляр синхронизирует каталог /var/www/mysite с соответствующим сегментом S3 через задание cron, но в другом направлении, как WriterNode. ReaderNode - это всегда полная копия WriterNode с максимальной задержкой в 2 минуты (задания cron выполняются каждую минуту). Серверы AMI как основа для группы автоматического масштабирования. При запуске новый экземпляр сначала синхронизирует c это каталог /var/www/mysite для извлечения различий, возникших с момента создания AMI.
Узлы совместно используют базу данных MySql, размещенную на RDS.
Я не специалист по Typo3, поэтому я не уверен насчет кэширования. Насколько я понимаю, каждый ReaderNode будет создавать свои собственные файлы кэша и соответствующие записи в базе данных. Но из-за s3 bucket syn c файлы удаляются при следующем задании cron syn c, которое происходит каждую минуту. Кроме того, я думаю, что кеш жидкости тоже может быть проблемой. Есть ли еще кеши?
Я начал тестирование с ElastiCache -> MemCached / Redis, но я не уверен, смогу ли я охватить каждый кеш таким подходом. Я тоже не хочу замораживать кеш. Какое наилучшее практическое решение для этого?
Некоторые отзывы о моем архитектурном подходе также приветствуются.