Schogini - Amazon AWS, Magento and Mobile Developers
 

Infrastructure as Code - Load Balanced AutoScaling Clustered Magento 2 EE with DevOps CI and CD

Success Story

This case study started in December, 2015. Magento 2 was just being launched and this customer already had Magento 1.x EE! The revised AWS infrastructure was done parallel with live data syncing to ensure minimal down time.

Schogini’s Magento and AWS certified team have done the entire infrastructure using a collection of version-able Bash Shell scripts. This made the architecture safe and repeatable.

Customer

Magento 2 EE Enterprise Edition with pre-existing Magento 1 EE with an in-house Magento development team. Schogini’s team members joined customers dev team seamlessly to collaborate with their DevOps culture.

Requirements

  • Magento 1 EE (M1EE) to Magento 2 EE (M2EE) Upgrade and Data Migration
  • Custom Magento 2 Module Development to Handle Gift Cards
  • NGINX/PHP-FPM Server
  • Varnish front-end caching clusters
  • AWS Elasticache (Redis backend and block caching)
  • Aurora RDS with Read Replica Database
  • Multi-A-Z deployment
  • AWS Cloudfront CDN for media and static content delivery
  • AWS Elastic Load balancer with Custom Health Check
  • AWS Autoscaling for the frontend clusters
  • AWS Route53 based Maintenance and DR (Disaster Recovery) system
  • Development, Staging/Testing and Production Automated CI/CD Pipeline

Caveats

  • M2EE maintaining atomicity of sessions/user cart contents across frontend EC2 clusters
  • Frontend Varnish cache purging across all clusters to force push changes made by the shop admin
  • Very low maintenance period
  • Automated Backup and Rollback system with auto-detection of shop defects

Schogini’s Custom Solution Highlights

  • The network setup containing VPC, Security Groups, Elastic IPs, Placement Groups etc. created using AWS CLI scripts
  • Custom AMI was created with the final M2EE code and made it as the source for the Launch Configuration.
  • Dedicated EC2 admin instance created with no Varnish and no Load Balancer to exclusive IP restricted access to security
  • Each frontend autoscaling cluster instance traffic came from the Load Balancer
  • Custom Health Check flag was created to communicate health of the shop to the Route53 to fail over to maintenance mode
  • Push to production script to automate going live process created
  • CloudFront CDN with the Admin server’s media and static folder as the origin defined
  • Custom command line module was created to auto generate thumbnails to reduce CDN miss latency

In this Magento AWS architecture, one S3 bucket has been designated for backup and rollback. The cluster generated static files (if any) were being copied to the admin server folder for CDN propagation. Local Git repository maintained the code and infrastructure versions.

Issues Faced

  • Full-page cache across the auto-scaled clusters posed inconsistencies during updates. This had to be fixed after repeated trials by Schogini’s custom scripts to force Varnish purging.

GET THE SOLUTION!

Author

Sree - Founder/MD/Chief Cloud & DevOps Architect
Sree is an evangelist and thought leader in the Continuous Delivery and DevOps space. In addition to being a Cloud Architect, he also imparts training in AWS, Docker and other DevOps related technologies. Sree's core speciality is in building scripted, version-able, repeatable, auto-scaling, load-balanced and self-healing infrastructures. Sree also works in server-less architectures using AWS Lambda service and Internet of Things (IOT). Sree is also an Amazon Certified AWS Cloud Architect with 15+ years of server experience. He is also the author of Docker Fundamentals [Integrated Course] published by Packtpub.
Know more about the author.
 
 
 

CONTACT US

We love to talk to you, all enquires are replied to in under 4 hours.