With 15+ years of 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 environments. Scaling and load balancing parameters are very flexible at AWS. You can achieve a proper scalable environment by tuning special characteristics and scaling policy. This autoscaling setup will spin AWS scalable instances to handle traffic when the load rises. At the same time, we can configure the environment to destroy additional instances when the load is not high. This approach is the most cost-effective and is considered to be self-healing.
What does AWS scalable WordPress environment consist of?
A proper AWS scalable environment will use various AWS features, and 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 single.
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 of 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 the sense that the very same application can host on each of the nodes.
The key feature when creating a scalable architecture is to create real-time synchronization 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 to secureness of your website and all its data. So I would recommend reading about our security approaches and best practices in our recent article.
The most outer edge of any application in the 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 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 an equal load for the nodes.
Amazon infrastructure provides good load-balancing features, as we can use IaaS (Infrastructure as Service) for a WordPress installation. In addition to the distribution of the load, a load balancer provides an 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 Amazon Auto Scaling. It provides a basic worker node for the load balancer to be in touch with other nodes. We need this to synchronize any updates to the data and application across all nodes. Thus, there is virtually no limit to the number 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 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 sets 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 users.
Effective web application needs a good cache solution to ensure proper performance and user experience. A good choice will be Memcache or Redis, and they both are in the selection of tools in the Amazon Web Services portfolio.
Caching is important to have for any high-volume WordPress installation. It provides a fast and modern key-value store, available across the instance nodes. With a shared cache, all nodes are able to instantly retrieve the same information.
Cache is extremely important for networked and distributed applications. 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 over time, and the data structures require an amazing tuning approach. Often a large portion of the database queries is reading rather than writing to the database in real-life web application scenarios. For that, MySQL and many other popular database clusters were designed from the conceptual approach of multiple “read-only” nodes and a single write-node. This architecture provides virtually unlimited scalability for read-only transactions. But it cannot provide more than one written transaction at a 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 a configurable interface to cooperate with. The inherent problem is the same as 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 a 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 occur 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.