For 10+ years experience in system administration and DevOps engineering ITsyndicate has successfully completed and released pretty much projects of building AWS scalable WordPress Environment. Our team is willing to share our best practice of implementing some kind of scaling and load balancing.
You can use various types of AWS architectures for installing WordPress environment. Scaling and load balancing parameters are very flexible at AWS. You can achieve proper scalable environment by tuning special characteristics and scaling policy. This autoscaling setup will spin AWS scalable instances to handle traffic when load rises. At the same time we can configure environment to destroy additional instances when the load is not high. This approach is most cost effective and considered to be self-healing.
What does AWS scalable WordPress environment consists of ?
Proper AWS scalable environment will use various AWS features, we will discuss them separately. There are pretty lot of ways to build AWS scalable WordPress environment with load balancing web application and other features. However, the fundamental issue and set of challenges remain the same. The most common mistake while discussing scalable architecture is when you try to multiply something which is a priory just singe.
Thus, one is aiming to create multiple instances of one, to make them more than one, but still remain one. Too complicated, isn’t it? Luckily, no-one needs to solve the paradox how one can be two and two can be one. The AWS infrastructure does the magic to provide multiple instances of the one, so that each of them is separate, but still the same in a sense that the very same application can can host on each of the nodes.
The key feature when creating a scalable architecture is to create real-time synchronisation between separate nodes. Thus separate nodes, because due to instant replication of any changes to all of the nodes, they can act as one even being separate. The scalability feature is a very valuable asset since it surpasses the tiny performance decrease as a result of real-time replication.
By the way, I assume that you will need in secureness of your website and all it’s data. So I would recommend to read about our security approaches and best-practices in our recent article.
The most outer edge of any application in network world is the domain name system. That is the very first contact point a user hits when working with an application. The Amazon Route53 name service provides a unique set of domain registration features for the demanding customers. One of the most amazing features of Route53 is the ability to distribute users based on geographical location. Using this, web users that come from a certain known country-specific network block can route into dedicated application instances, for example into one running nearby.
After the client resolved the domain name of the service to an appropriate network address, the next point is load balancer. Load balancer will distribute traffic to a cluster of shared instances (nodes). Typically the traffic at this level distributes randomly to achieve equal load for the nodes.
Amazon infrastructure provides good load balancing features, as we can use IaaS (Infrastructure as Service) for WordPress installation. In addition to the distribution of the load, a load balancer provides up-time improvement, as you can add and remove nodes in a managed fashion. Thus potential downtime will only affect only particular group of users, as we will reorganize the instance pool.
The core of AWS scalable WordPress environment is the Amazon Auto Scaling. It provides basic worker node for the load balancer to be in touch with other nodes. We need this to synchronise any updates to the data and application across all nodes. Thus, there is virtually no limit to the amount of instances hosting the application. As we know, only the sky is the limit, and when we are already up in the cloud – it is easy to see the vastness of the space 🙂
To share the files between the instances we need some kind of shared file system. For such cases we usually use NFS. An essential thing for a file system cluster is proper performance and high availability. Since the application components, eg. php-scripts are read from the file system frequently, a slow file share could become a bottleneck of any well performing architecture. Anyway, it is important to mount all recent and equal set of files for all instances. A file system might also host user generated data, such as images and attachments. Consequently, having one of them missing from some of the nodes would cause application functionality issues for user.
Effective web application needs a good cache solution to ensure proper performance and user experience. Good choice will be Memcache or Redis, and they both are in the selection of tools in Amazon Web Services portfolio.
Caching is important to have for any high volume WordPress installation. It providers a fast and modern key-value store, available across the instance nodes. With shared cache all nodes are able to instantly retrieve the same information.
Cache is extremely important for networked and distributed application. The cache provides fast access as it is held in the memory, in contrast to a database or disk surface. All the instance nodes may benefit from the same contents of the cache.
Going to the essential component of the application, the database, leads us to the final part of the AWS scalable WordPress environment. Since the database is the core storage of any content in the web application, in our case WordPress, it is important that all nodes have the same data and that the integrity of the data is not compromised.
Complex databases usually grow in size during time, and the data structures require amazing tuning approach. Often the large portion of the database queries are reading rather than writing to the database in real-life web application scenarios. For that, MySQL and many other popular database clusters were designed form the conceptual approach of multiple “read-only” nodes and a single write-node. This architecture provides virtually unlimited scalability for the read-only transactions. But it cannot provide more than one write transaction at time.
For the WordPress architecture in AWS cloud we usually choose advanced and modern Master-Master replication architecture. This is common for modern NoSQL databases, where all the nodes share the same dataset. But due to the lack of transactions, the problem of concurrent writes does not surface. Using Master-Master replication in the AWS hosting architecture for WordPress, both nodes will be able to act as masters.
Usually all mature database engines provide configurable interface to cooperate with. The inherent problem is the same than it was when discussing scaling of the application instances. With the proper usage of SQL level functionalities, the application can be sure that some information written to the replicated database is available to other nodes at the proper moment of time. However as many nodes can write at the same time independently, there is still a theoretical possibility that updates may remain in conflict. All this solves on the database level by ensuring that writes are ordered in sequential order even when occurring in distributed independent cluster of nodes.
Master-master replication scheme ensures that the same committed data is readable on both of the nodes. This means that the architecture ensures that only things that could occurre in reality in sequential order, even independent of each other, are committed to the database.
The final component in the architecture is a plain disk for any static files the application needs. Amazon CloudFront service provides such stuff. This enables the effective delivery of static media files and other content which is embedded on the WordPress pages. Amazon Cloud Front content delivery service was designed to face the challenges of global businesses, so it will definitely suit 99% of websites.