High-Availability and Scalability

Keeping your site up is critical for you business. To accomplish this we need to understand scalability and high-availability. Theses concepts go hand-in-hand, however they are separate things to consider so let's take a look.

Scaling Up High-Availability is a set of techniques and architectures that allow your site to remain up and fully functional even if there's a failure of some sort in part of the stack. This goes for all of the tiers of your site, including networking gear, database servers, and even power. This could be a simple as having a spare Web server ready to serve traffic if the primary goes down.

Scalability is the handling of increases and decreases, normal or unexpected, in traffic or load to your site. Generally you want to scale in such a way so 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 you application and the availability needs.

The more complicated your availability and capability needs are, the more it can cost so you'll need to determine those ahead of time. Maybe your company blog can stand some downtime while the e-commerce site can't.

Highly-Available and Scalable Web App on AWS

Highly Available and Scalable Web App

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.

Web servers

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 a complicated process that's better handled by using RDS.

Code

Each Web server will not only need access to the code for your site, but have access to that code when a new instance starts up. There are a few ways this can be accomplished, but we'll look at only two:

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 your app code. EFS does have performance issues and can get quite expensive though.

You'll stil need some method to copy your app the EFS directory. This could be as simple as rsync'ing, or using some other deploy tool.

Auto-Scaling Group

An Auto Scaling Group (ASG) will allow our app to scale automatically based on some CloudWatch metric. As long as your CodeDeploy deployment is associated with the ASG, new instances will also get the current app deployed to it.

Load Balancer

You'll need to direct incoming traffic to our fleet of Web servers. A LoadBlancer will give you that single endpoint. You can then create a DNS record to hide the endpint behind a freindly DNS name.

Types of load balancers

Appliction Load Balancer (ALB) - For Web apps an ALB provides a lot of flexibility in routing requests based on Hostname, Request Method, or URL (amongst 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.

Database server

Amazon RDS is 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).

RDS support MySQL, MariaDB, PostgreSQL, Oracle, AND MS SQL Server. Amazon Aurora is a MySQL or PostgreSQL compatible DB that offers better replication, failover, and up to 5 times the throughput of MySQL and 3 times the throughput of PostgreSQL.

Be sure to contact us for help getting your sites or apps Highly Available and Scalable!