Scaling WordPress with Amazon cloud

Miljenko Rebernišak

@miljenkor

WordCamp Norrköping 2015

Who am I ?

  • My name is Miljenko Rebernišak
  • I live and work in Belgrade, Serbia
  • I have built my first website at age of 13th
  • Today I am Software engineer at Devana Technologies,  a company behind ManageWP

Text

What I do daily ?

  • Build applications with
    • WordPress
    • Symfony / Doctrine
  • Build infrastructure with
    • Amazon Cloud
    • Ansible
    • DBs: MySQL, MongoDB, Redis...

Why I am here ?

I want to ask you:

What will happen with your site, while you are enjoying on your vacation?

What I will cover ?

  • Amazon Components
  • Data separation
  • Horizontal scaling
  • Code deployment
  • This will be architectural overview and not step by step setup tutorial

+

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
  • CloudFront CDN supports dynamic content
  • Cache configuration based on URL pattern or Headers
  • 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
  • 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

 

Schema

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

Horizontal scaling

Code deployment

There is a few ways, but a common is that you can’t:

  • install plugins/themes on the server
  • update plugins/themes on the server
  • change anything on the server without it first being changed locally

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

Cost

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

Thank you !

Send me feedback :)

miljenko.rebernisak (at) devana.rs

Scaling WordPress with Amazon cloud

By Devana Technologies

Scaling WordPress with Amazon cloud

What will happen to your website when it gets hit by a huge traffic spike? It will almost certainly go down if you are not prepared. Discover how to set up WordPress on Amazon cloud, covering vertical and horizontal scaling. Amazon offers many different components, but testing them can be time consuming and exhausting. Learn how to choose the right instances’ types and sizes, how to separate web server and database tier, and how to make them highly available with auto-scaling.

  • 2,231
Loading comments...

More from Devana Technologies