FAQ: Scaling WordPress in AWS

Original "Scaling WordPress in AWS " Architecture Post can be viewed here


1) Can EBS be used as the Shared Storage Pool between WP EC2 instances?
Currently Amazon Elastic Block Storage (EBS) can be attached to only one EC2 instance at a point in time. Because of this constraint we cannot attach the same EBS with Multiple WP EC2 instances and use it as a Shared Storage pool.


2) Can S3 be used as the Shared Storage Pool between WP EC2 instances?
S3 can be used as Shared Storage Pool and it requires programming and customization efforts in WordPress front. This is not a common approach.


3) Can the Shared Storage Pool be eliminated by upload all the static contents in CDN?
Shared Storage Pool is not an Alternative for storing contents in CDN. CDN is used to reduce latency and improve performance of the WordPress application , whereas Shared Storage Pool is used for instant communication between WP Mgmt EC2 instance and Auto Scaled WP EC2 instances.


4) What is the Shared Storage Pool Software used in this Architecture?
We used GlusterFS as the Shared Storage Pool in this Architecture.


5) Why GlusterFS for Shared Storage Pool and not NFS?
NFS works fine for Fixed WP EC2 instances. When WP EC2 instances are configured in Auto Scaling mode, new WP EC2 instances are launched whenever load increases automatically and killed when load decreases. Such dynamic launch/Kill has negative effects in the NFS system. We have seen GlusterFS working well in such auto scaling conditions.


6) How Auto Scaling is achieved in this architecture?
Auto Scaling is done only on WP EC2 instances and not on WP Mgmt instances. We used Amazon AutoScaling on WP EC2 instances based on the CPU Utilization. Whenever load increases the CPU utilization also increases and Amazon AutoScaling will trigger the launch process of New WP EC2 instances. These new EC2 instances are configured to automatically get attached to the Load Balancer. When the Load decreases the CPU utilization also reduces and Amazon AutoScaling will trigger the termination of the WP EC2 instances automatically.
For more details about Amazon AutoScaling URL: http://harish11g.blogspot.com/2011/04/auto-scaling-in-aws-cloud.html



7) Is WP mgmt EC2 and WP EC2 are separate EC2 instances ?
Yes,they are separate EC2 instances in this architecture. WP mgmt EC2 instance is used for theme , plugins and content publishing. Auto Scaled WP EC2 instances automatically pick up all these changes from the common storage pool shared between WP mgmt EC2 and WP EC2 instances.



8) What Algorithm should be configured in Amazon ELB for Scaling?
Amazon ELB can be configured with Round Robin Session Sticky Algorithm.


9) Is RDS Read Replica’s mandatory in this architecture?
No, RDS Read Replicas are not mandatory in this Architecture. They are advised only for Read Intensive production deployments.


10) Why RDS MySQL and not MySQL on EC2?
RDS MySQL is a managed service from Amazon Web Services. It is easy to configure and maintain.


11) What are recommended Instance Types / Capacities for the following Layers?
We recommend the following instance types for production deployments based on this architecture
WP content EC2 instances: Large Instance Types (m1.large)
WP mgmt EC2 instance Large Instance Types (m1.large)
GlusterFS Storage Pool: Large Instance Types (m1.large)
RDS MySQL: Large Instance Types to start with




12) What Plugins are used for Performance Improvement?
We use W3TotalCache plugin with AWS Cloudfront CDN for offloading static content delivery and gain better response times
APC (or) Xcache plugin can be used for PHP opscode caching


13) Can you throw some ideas to make this architecture Cost effective?


p1) Amazon Auto Scaling built into this architecture aligns the number of EC2 WP instances according to the traffic demands there by cutting unwanted EC2 usage costs.


To get more insights about Amazon Auto Scaling check this URL: Http://harish11g.blogspot.com/2011/04/auto-scaling-in-aws-cloud.html


Http://harish11g.blogspot.com/2011/12/aws-cloud-tour-2011-technical-track.html


p2) Also the WP mgmt EC2 instance can be launched only during deployments and can be shutdown other times for further cost savings.


p3) we have built HA for all layers in this architecture. If you want to trade off HA and achieve only Scalability, then reduce HA EC2 instances in GlusterFS and RDS Layers. This again reduces the monthly infrastructure cost.


p4) Usage of RDS Read Replicas are optional in this architecture and are dependent upon Use cases. This can further reduce cost if used appropriately



14) Is w3totalCache plugin a must in this architecture ?
Yes , This architecture is dependent upon W3totalcache with Cloudfront CDN. If this is not used , all static assets will be accessed from the GlusterFS and it will add additional burden to the GlusterFS . This will decrease the overall performance of the entire architecture. So in our past experience , we have observed using W3TotalCache plugin with CDN is very effective in this architecture.



15) Any specific care while configuring ELB ?
Yes , Configuring a  lesser unhealthy threshold value with aggressive response time out + Health Check interval in ELB , will mark WP EC2 instance unhealthy quickly and will stop sending requests. In addition , will send a signal to Amazon Auto Scaling to relaunch this WP EC2 instance. Even though you had requested Amazon Auto Scaling to maintain minimum of 2 instances , you will find some EC2 instances getting frequently restarted. If you maintain W3TotalCache in these WP EC2 instances (Web servers) to offload the traffic from DB servers and Gluster Servers , such frequent WP EC2 web server restarts will not give enough time for cache warming. This will add burden to the WP EC2 instances in web layer, DB servers etc and overall bring down the entire infrastructure.