Case study: Example of an Auto-scalable AWS Set-up

AWS auto scaling is a service that tailors server capacity to match the demand, enabling a reliable performance at all times, while keeping costs at a minimum.

In what follows, you’ll find an example of project infrastructure concept hosted on AWS we developed for a client. Naturally, names and links have been redacted, however it should still serve as a potent example. It includes the deployment configuration concept, as well as infrastructure information.

Infrastructure diagram

Network diagram

Deployment configuration

Please see the deployment README in project(hidden)-deployments repository.

Magento FE infrastructure

Application stack

• Nginx
  ○ Web root /var/www/public
• php-fpm (7.0)
• CodeDeploy agent
• Newrelic

Description

The Magento FE serves store user requests which aren’t cached by Varnish. The frontend is set up as an autoscaled infrastructure consisting of a configurable amount of c4.xlarge nodes with a minimum of 1 active at all times.

The stores are configured to use static asset versioning which allows for the static assets to be requested from CDN and allows avoid any caching issues when a new static content version is deployed. All FE nodes are set up with EFS mount points for media, report, and logs.

Deployments

Deployments are executed using CodeDeploy and triggered from Bamboo or using ./run-deployment bash script. Magento FE does not do any static content deployments therefore drastically increasing the average time required for deployment. An FE node is removed from the ELB whilst deployment is being done, because of this, it is possible to avoid any downtime during deployment. The full deployment procedure can be seen in deployment README.

Magento BE infrastructure

Application Stack

• Nginx
  ○ Webroot /var/www/public
• php-fpm (7.0)
• CodeDeploy agent
• Gor
• Newrelic

Description

The Magento BE infrastructure takes care of running cron jobs, static content generation and media content storage in EFS. All BE infrastructure nodes have EFS mounted to store the media data. In addition, what is done on the FE nodes BE noes also run static content generation and dependency injection compilation? The CDN is configured to use the public load balancer as the origin for media and static files. (TBS Waiting for Walmart DNS change)

By default, Magento 2 will fail a cache flush action even if one of the Varnish nodes becomes inactive. To resolve this issue Gor is used, all Magento BE nodes are configured (http_cache_hosts) to use 127.0.0.1 for flushing Varnish even though if there isn’t any running on the BE, instead it points to the Gor which is configured to pass PURGE requests to all IP addresses in Varnish subnets.

Deployments

Please see deployment README in project(protected-by-NDA)-deployments repository.

Magento consumer infrastructure

Application Stack

• Nginx
  ○ Webroot /var/www/public
• CodeDeploy agent
• supervisord
• Newrelic

Description

The Magento consumers are a separate auto scaling group which does not process and website related requests, however, it does consume AWS SQS queue for transactions and migration. The supervisor is configured to launch Magento queue:consumers:start command.

Deployments

Please see deployment README in project(protected-by-NDA)-deployments repository.

Varnish infrastructure

Application Stack

• Varnish 4
• Newrelic
• Nginx

Description

The Varnish infrastructure consists of a fixed amount on Varnish nodes which can be increased manually by editing the ASG configuration. Since Varnish only resolves a hostname defined in the backend part of the VCL only upon starting it is strongly not advised to use ELB hostname there since its IP addresses might change.

To resolve this issue the backend is configured to use localhost on port 8080 which is pointing to the Nginx instance. Nginx is to cache domain names only for 30 seconds using the resolver directive. The VCL and Nginx configuration is updated during a deployment. Varnish deployments are configured to use completely separate deployment configuration.

Deployments

Please see deployment README in project(hidden)-deployments repository.

Logging configuration

Description

Since almost all parts of the infrastructure are automatically scaled logs must be stored in a centralized fashion.

Log sources

• S3 ingested logs for publicly available ALB
• S3 ingested logs from Cloudtrail
• Magento logs and reports from FE/BE/Consumer stored in EFS

CDN configuration

Description

To decrease the asset loading times for customers a CDN should be set up. The CDN takes care of serving of media and static assets which are originating from the BE instances. Magento has configured base_static_url and base_media_url which updates the page URLs to use the CDN hostname, therefore, making sure that customers are requesting assets from CDN.

Shared storage configuration

Database

The database consists of one AWS Aurora node.

Sessions and cache

Redis infrastructure one master server managed using Elasticache service. Magento is configured to use master Redis server for storing FPC and session data each in separate databases.

Media data

All media data and additionally other data if required is stored in Amazon EFS which is a centralized and fault tolerant NFS service.

Curious what are the set-up costs for your business? Let’s schedule a discovery call! Just drop us a line at [email protected] or in the contact form below and let’s talk.

Related articles:

Bamboo Deployment Tracking to Production Environments in Google Analytics

Share on: