We're running Magento 2 on AWS behind an Application Load Balancer and in Auto Scaling Groups. Backend is cached by Redis. We're sharing pub/media and pub/static on AWS EFS and they are cached and delivered via AWS CloudFront. After updates, instances are deployed and an AMI is generated which serves as template for Auto Scaling.
This ensures all instances have all the data and caches are warmed up. In general, everything runs smooth and fast, because only few of all the requests reach to the nodes itself.
One big problem is when deploying new static content. Due to the nature of EFS, this is slow as hell and means a lot of downtime. Luckily, we only have 1-2 deployments per month, but this bothers me a lot.
What are better strategies (best practives?) to generate the static content and share it between instances?
Or would it be sufficient if I use the normal file system for pub/static, generate the AMI-image and spin up these instances in Auto Scaling? pub/static shouldn't change without deployment?
We ran into similar problems for sites that have "unpredictable surge in web traffic" where the EFS Usage Credits will get all used up and then defaults to ~50k/second transfer between EFS and EC2, effectively bringing the site down.
EFS may have good use case for very predictable web traffic. Not for an ecommerce company who ever decides to do an online sale of any sort.
(for search reasons, i'll also add we were instructed by amazon EFS engineering level 2 to add a bunch of "junk files" so our usage would be over 100GB at all times, effectively placing you in an upper usage tier. While this allows you to purchase more usage credits the following month, it doesn't solve the problem when your website has traffic spikes and flash sales.)
- create an NFS share on an multi-zone EC2 instance. Predictable. Reliable.
Hey. Are you actually generating the static content on EFS? If so, it is very inefficient and it would be much better if the static content would be generated on a iops provisioned EBS volume. Afterward, it can be either delivered through EFS or any other way.
Also, check blue/green deployments. While they won't work properly for database changes with M2 (i.e. db contains update scripts that add new code dependencies) out of the box, it should work just fine for static content re generation.
Instead of replicating to the nodes, why not configure static content to run through CloudFront to a single origin server (the primary that you deploy on). The scaled nodes could effectively have no /pub/static /pub/media at all because all that traffic is being directed to the CloudFront distribution.
I've been exploring scaling Magento on AWS and this is the direction I am leaning just because CloudFront is a far better CDN for getting the static content out than just having more nodes. You will never replicate CloudFront's ability to scale static content with your own EC2 nodes.
Anyone with advice/experience with this - please reply!