Scaling WordPress with Amazon cloud

Miljenko Rebernišak

@miljenkor

Devops Meetup Beograd Novembar 2015

What I do daily ?

• Build applications with
  • WordPress
  • Symfony / Doctrine
• Build infrastructure with
  • Amazon Cloud
  • Ansible

Amazon components

• Virtual Private Cloud (VPC)
• Elastic Compute Cloud (EC2)
• Elastic IP
• Elastic Load Balancing (ELB)
• Route53
• Cloud Front
• Auto Scaling Group (ASG) / Launch Configuration
• Simple Storage Service (S3)
• Elastic Cache
• Relation Database Service (RDS)

Amazon components

• Logically isolated section of the Amazon Web Services (AWS)
• Virtual network that you define
• Your own IP address range
• Configuration of subnets
• Route tables control
• Network gateways
• Security groups

Virtual Private Cloud (VPC)

• Is a web service that provides resizable compute capacity in the cloud
• Virtual instance with CPU/Memory/Disk unit
• Place where your code is executed
• Variate of performances and types
• Storage
  • Persistent Elastic Block Storage(EBS)
    • General purpose SSD
    • Provisioned IOOPS SSD
  • Non-persistent local storage
    • all data is lost during reboot

Elastic Compute Cloud (EC2)

• A static IP address designed for dynamic cloud computing
• You can mask the failure of an instance by rapidly remapping the address to another instance in your account
• Elastic IP address is associated with your AWS account

Elastic IP

• Automatically route traffic across multiple instances and multiple Availability Zones
• Only healthy Amazon EC2 instances receive traffic
• Automatically scales its request handling capacity to meet the demands*
• SSL Offloading
• Layer 4 or Layer 7 Load Balancing
• Operational Monitoring

Elastic Load Balancing (ELB)

• Highly available and scalable cloud Domain Name System (DNS)
• DNS health checks to route traffic to healthy endpoints
• Private DNS for Amazon VPC
• Variety of routing types:
  • Latency Based Routing
  • Geo DNS
  • Weighted Round Robin
  • Failover
  • Simple

Route53

• Is a content delivery web service
• Support for POST/PUT and other HTTP Methods
• Support for Cookies
• Support for Query Strings
• Device detection
• Dynamic Content support
• GEO targeting

Cloud Front

• Allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define
• Auto Scaling can automatically increase the number of Amazon EC2 instances during demand spikes to maintain performance and decrease capacity to reduce costs
• Replace unhealthy or unreachable instances to maintain higher availability of your applications
• LC describes scaling instances

Auto Scaling Group (ASG) / Launch Configuration (LC)

• Secure, durable, highly-scalable object storage
• Unlimited storage per bucket
• REST API
• Low cost

• Cross-Region Replication

• Versioning

• Data Lifecycle Management

Simple storage service (S3)

• Memory based caching cluster
• Support for two engines
  • Memcached
  • Redis
• Fully managed
• Support multi zone replication
• Automatic fail over
• Backup and restore available                                  
• Detail monitoring

Elastic Cache

Relation Database Service (RDS)

• Makes it easy to set up, operate, and scale a relational database
• Scalable, failover, Multi-AZ
• Available and Durable storage
• Automatic backup and point in time restore
• Automatic patching and upgrade
• Support for different engines
  • Aurora (MySQL 5.6 compatible, amazon implementation)
  • MySQL
  • PostgresSQL
  • Oracle
  • SQL Server

Data separation

Data separation

• We want to move data from single instance in order to:
  • ensure capacity for growth
  • speedup performance
  • prepare for horizontal scaling
  • make it highly available

Data separation

• We will use CloudFront as CDN
• Static files will be hosted on S3 and served with CloudFront
• Dynamic content is served from EC2 instance and cached with CloudFront
• This will reduce hits to EC2 instance, optimize delivery and utilize browser cache

Data separation

• We need to put media files on S3
• Plugin level
  • W3 Total Cache
  • WP Offload S3
• System level
  • S3FS via fuse to mount S3 as local disk
• S3FS is not fast as local system, but there is no need for file synchronization like at plugin level and URL replacement

Data separation

• We will move database from single instance and use RDS MySQL / Aurora in Master-slave replication with Multi Availability Zone setup
• All read queries can be sent to one or more read only replicas in order to increase capacity
• We have automatic fail over from RDS in case of master failure or zone failure
• WordPress doesn't support Master-Slave setup natively
  • Use HyperDB plugin for advanced WPDB replacement

Data separation

• Database caching can significantly reduce latency and increase throughput 
• We will use WordPress object cache with ElasticCache Memcache cluster
• Plugins
  • W3 Total Cache
  • Memcached Object Cache
  • ...

Horizontal scaling

Horizontal scaling

• We will use elastic load balancing (ELB) for automatic traffic routing to our web servers instances
• ELB will do health checking of EC2 instances
• We will use Amazon Auto scaling free feature
• We need to create launch configuration, auto scaling group and alarms

Horizontal scaling

Launch configuration defines:

• Amazon machine image (AMI)
• Storage type and capacity
• Network configuration of instance
• Instance type
• Security group
• ...

Horizontal scaling

Alarms are various metrics, with given threshold

Sample metrics are:

• CPU utilization
• Network IN or OUT transfer
• Memory usage
• Disk IO
• Throughputs
• ...

In many cases CPU utilization is enough alarm, but this depends on website

Horizontal scaling

Auto scaling group defines:

• Desired launch configuration
• Minimum capacity
• Desired capacity
• Maximum capacity
• Up & down scaling actions and timing
• Alarm triggers

Horizontal scaling

• Auto scaling group automatically creates a new instance by specification in launch configuration once scale up alarm is triggered
• After instance become ready and pass health check, it's registered with ELB and starts receiving traffic
• ASG will not launch more then max instances
• After rush hours, scale down trigger will be emitted
• ASG will destroy instance by instance until desired capacity is meet

Horizontal scaling

• We need to create a WordPress stateless in order to launch and terminate instances in ASG
• We can't write files, because they aren't shared among servers
  • We have covered user generated files in data separation chapter
  • 3rd party plugins may use filesystem instead of database, so there is need for their workarounds
• Fortunately  WordPress doesn't use session storage
  • Users are authenticated with cookie and database check
  • Other plugins can misbehave and use session

Code deployment

Pre-backed AMI

• One "gold" instance outside of scaling group/ELB
• Gold instance is place where changes are made
• Crete a new AMI snapshoot
• Create a new launch configuration
• Update ASG
• Deploy the new image manuly or using Aws-ha-release/Ansible or similar tool
• Slow
• You can do system upgrades and not just code deploy

AWS CodeDeploy

• CodeDeploy uses a file and command-based install model
• Auto Scaling Integration
• Rolling Updates
• Stop and Rollback
• Deployment History
• GIT or S3 integration as source
• Faster
• Just code is changed between releases
• It's free

What's next ?

Instance types

• t2.* - development, staging
• m3.* & m4.* - small project
• c3.* & c4.* - production
• r3.* - database, caches

By my personal experience:

Automation

• Amazon BeanStalk
• Amazon Cloud Formation
• Amazon CodeDeploy
• Ansible
• Chef/Puppet
• In-house tools
• ...

Monitoring

• Amazon provides variety of metrics for every component
• Use one that fit you best and keep eye on them
• Use external tools for aggregation and big screen display in office
  • Personal choice Librato

Cost

• Can be expensive
• Hidden costs eg. requests count, network transfer
• Use reserved instances
• Enable billing alarms