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

Made with Slides.com