High Availability and Scalability
Keeping your Web site up and responsive is critical for your business. To accomplish this we need to understand both scalability and high availability. These concepts go hand-in-hand; however, they are separate things to consider, so let's take a look:
This is a set of techniques and architectures that allow your site to remain up and fully functional in the event of a failure. This goes for all tiers of your site, including networking gear, database servers, or even power. High availability could be a simple as having a spare Web server ready to serve traffic or as complicated as load-balanced fleet.
This is the handling of increases and decreases, normal or unexpected, in traffic or load to your site. Generally you want to scale in a way that you are not paying for spare resources if they're not needed.
Scaling up. You could scale up a single server by increasing its size to handle the extra load or scale out by adding more server nodes. You could even do both! The exact scaling strategy depends on the specifics of your application and the availability needs.
The more complicated your availability and capability needs are, the more it costs.
Highly Available and Scalable Web App on AWS
Since the advent of public "cloud” providers like Amazon Web Services (and whole host of others) building a highly available and scalable site is easier than ever. You don't need to worry about redundant network switches, routers, power, Internet connections, or even the whole data center anymore, as those things are take care of for you.
COG - LAMP/LEMP Makes a great pre-configured Web server image to get you started since it has everything you need pre-installed and configured. However, you won't need the local MariaDB services since scaling database servers is a complicated process that's better handled by using RDS.
Each Web server will not only need access to the code for your site, but also have access to that code when a new instance starts up. There are a few ways this can be accomplished:
- Amazon CodeDeploy
- A CodeDeploy deployment is a compressed archive (zip, tar.gz) of your code (with a few extra config files). You can create this archive manually, or with an automated build system. Once an updated archive has been created, you can deploy it from the command-line, an SDK, or the AWS Web console.
- Amazon EFS
- EFS is a shared Network File System (NFS) that can be mounted on any number of instances and provide file-system level access simultaneously to all instances. Linux has the ability to mount EFS shares without the need for additionsl software. This makes it easy to setup and use and requires little if any modifications to your app code. EFS does have performance issues and can get quite expensive.
You'll stil need some method to copy your app to the EFS directory. This could be as simple as rsync'ing, or using some other deploy tool.
An Auto Scaling Group (ASG) will allow our app to scale automatically based on one or more CloudWatch metrics. As long as your CodeDeploy deployment is associated with the ASG, new instances will also get the current app deployed to it.
You'll need to direct incoming traffic to our fleet of Web servers. A LoadBlancer will give you that single endpoint that you can point your Web address at.
Types of load balancers
- Appliction Load Balancer (ALB)
- For Web apps, an ALB provides flexibility in routing requests based on Hostname, Request Method, or URL (among others). You can attach SSL/TLS certificates (up to 25) to terminate and offload TLS traffic onto the ALB.
- Network Load Balancer (NLB)
- For other, arbitrary network traffic, an NLB can be used.
- Amazon RDS
- A fully managed Relational Database Service that can be used to store persisted data. There's a lot of replication and redundancy capabilities available with RDS, so you'll need to decide how much replication and redundancy you'll need (and are willing to pay for).
Contact us for help getting your sites or apps Highly Available and Scalable!