LEGO® for the Cloud: Architecting Complex Solutions with Simple AWS Patterns (Part-2 covering Patterns for High Availability)

Patterns for High Availability

Multi-Server Pattern

The Multi-Server pattern in AWS is a fundamental design approach for building increased availability and fault tolerance within your application architecture. It achieves this by deploying multiple servers to handle incoming requests and distribute the workload.

Server Redundancy

Problem : Materials required for providing redundancy, such as server machines and load balancers, involve considerable expense, sometimes when you take cost effectiveness into consideration, the best action is no action.

Solution :

• Launch an EC2 instance and set up the operating system, and the like.
• Apply the Stamp Pattern, to launch multiple EC2 instances.
• Launch ELB and bind the multiple EC2 instances.
• Set up the options so as to use the health check function to check the bound EC2 instances.

Here’s a breakdown of the key characteristics of the Multi-Server pattern:

• Redundancy: The core principle is to have multiple servers running identical copies of your application. This redundancy ensures that if one server fails, the others can continue processing requests, minimizing downtime and impact on user experience.
• Load Balancing: To distribute incoming traffic efficiently across these servers, you typically use an Elastic Load Balancer (ELB) in AWS. The ELB acts as a single point of entry, directing requests to healthy instances within the server pool.
• Scalability: The Multi-Server pattern provides a degree of horizontal scalability. By adding more servers to the pool, you can increase the overall processing capacity of your application to handle growing traffic demands.
• Simplicity: This pattern is relatively straightforward to implement compared to more complex scaling strategies. You can manage individual server instances and leverage existing tools like ELB for load distribution.

However, there are some limitations to consider:

• Manual Scaling: Scaling typically involves manually adding or removing servers from the pool, which can be time-consuming for dynamic workloads. Auto Scaling groups can help automate this process based on predefined metrics.
• Increased Management Overhead: Managing multiple servers requires additional effort for configuration management, updates, and monitoring. Infrastructure as Code (IaC) tools can help streamline these processes.

In essence, the Multi-Server pattern in AWS is a well-suited approach for:

• Improving application availability by providing redundancy and minimizing downtime.
• Handling moderate traffic volumes by distributing workload across multiple servers.
• Building a foundation for scaling as your application grows by adding more servers to the pool.

It’s important to consider its limitations, particularly for highly dynamic workloads or situations requiring extensive automation. For such scenarios, exploring options like Auto Scaling groups or containerized deployments with tools like Amazon ECS might be more suitable.

Multi-Data Center Pattern

The Multi-Data Center Pattern in AWS goes beyond the scope of a single Availability Zone (AZ) and utilizes geographically separated data centers, also known as Regions, to achieve even higher levels of fault tolerance, disaster recovery, and data residency compliance.

Redundancy on Data Centre level

Problem : Multi-Server Pattern cannot handle a case where one envisions a data center-level failure (such as when there is a power outage, an earthquake, a network failure, or the like).

Solution : Use Availability zones and enable cross zone loading in ELB (by default it is enabled)

Here’s a breakdown of the key aspects of the Multi-Data Center Pattern:

• Geographic Distribution: This pattern focuses on deploying your application and data across multiple AWS Regions in different geographical locations. This redundancy ensures that outages or disruptions in one Region will not affect the entire system. Users in unaffected Regions can still access your application through the healthy data center.
• Disaster Recovery: The Multi-Data Center Pattern excels in disaster recovery scenarios. If a major disaster strikes a specific region, your application and data remain available in other Regions, minimizing downtime and data loss.
• Data Residency: This pattern can be crucial for adhering to data residency regulations. By storing data in a specific Region, you can comply with local laws or organizational policies that dictate where data must be kept.
• Implementation Considerations:

Here are some AWS services that can be leveraged with the Multi-Data Center Pattern:

• Amazon Route 53 Application Load Balancer: Routes traffic to healthy instances across your geographically distributed application deployments.
• AWS Global Accelerator: Improves performance for globally-distributed applications by directing users to the nearest healthy Region.
• AWS Aurora Global Database: Provides a geographically distributed database solution with automatic failover capabilities.
• AWS S3 Replication: Enables replicating data objects across S3 buckets in different Regions for redundancy and disaster recovery.

In summary, the Multi-Data Center Pattern in AWS is a powerful approach for building highly resilient and geographically dispersed applications. It offers significant advantages in terms of disaster recovery, data residency compliance, and improved availability for users in different locations.

However, it’s crucial to carefully consider the increased complexity, potential latency issues, and cost implications before implementing this pattern.

Floating IP Pattern

The Floating IP pattern is a technique used in AWS to achieve high availability (HA) for applications. It works by assigning a static public IP address, also known as an Elastic IP (EIP) in AWS, to a single active server at a time. This EIP acts as a virtual IP (VIP) that clients use to connect to the application.

New machine with old IP

Problem : Domain Name System (DNS) to swap the server along with TTL makes system unavailable for longer duration.

Solution : Prepare a machine image that will enable you to start up the required virtual server whenever you need it.

Moreover, because an API for specifying the IP address is also available, you can write a script to automate all the processes from starting up the server through setting the IP address.

Here’s a breakdown of how it works:

1. Active/Standby Servers: You deploy two EC2 instances, one designated as the primary (active) and the other as the secondary (standby).
2. Elastic IP Allocation: An EIP is allocated and associated with a secondary private IP address on the primary server. This private IP serves as the endpoint for external connections.
3. OS Configuration: The primary server’s operating system is configured to treat the secondary private IP as an alias on its network interface.
4. Monitoring and Failover: A health monitoring mechanism continuously checks the health of the primary server. If the primary fails, the monitoring script triggers a failover process.
5. EIP Re-association: During failover, the EIP is disassociated from the failing primary server and re-associated with the standby server. The standby server then takes over the application’s active role.

This approach ensures that even if the primary server fails, clients can continue to access the application through the EIP, which is now attached to the healthy standby server. The EIP “floats” between the active servers, providing a single point of access for clients regardless of which server is currently handling requests.

Here are some of the common use cases for the Floating IP pattern in AWS:

• Stateful applications: For applications that maintain critical data on the server itself, the Floating IP pattern can provide HA without requiring complex data replication strategies.
• Simple web applications: For basic web applications where load balancing isn’t a primary concern, the Floating IP pattern offers a simpler approach to achieving failover.

It’s important to note that the Floating IP pattern has limitations. For instance, it doesn’t provide load balancing capabilities, and it might not be suitable for highly scalable applications. However, for specific scenarios, it can be a cost-effective way to implement basic HA for your AWS applications.

Deep Health Check Pattern

The Deep Health Check Pattern in AWS extends the functionality of standard health checks used with Elastic Load Balancers (ELBs).

System Health Check

Problem : The Load Balancer can evaluate the status of the web server and cut off the web server if it is malfunctioning.

However, the Load Balancer is unable to discern the status of the back-end servers, such as the proxy server, the AP server, and the DB server.

Solution : Set the destination for the health check to a dynamic page

Here’s a breakdown of how it works:

Standard vs. Deep Health Checks:

• Standard Health Checks: These basic checks performed by the ELB itself typically involve pinging the instance or sending an HTTP request to a specific path on the instance. They only assess the health of the instance itself, not its dependencies.
• Deep Health Checks: This pattern goes beyond the limitations of standard checks. The application running on the EC2 instance performs the deep health check. It allows the instance to signal the ELB about the health of critical dependencies that the ELB can’t directly access or monitor.

Implementation:

The specific implementation of a deep health check can vary, but here’s a general idea:

1. Health Check Endpoint: The application on the EC2 instance exposes a dedicated endpoint (e.g., a specific URL path) specifically for health checks.
2. Health Check Logic: This endpoint performs actions to verify the health of dependencies like databases, external services, or internal application components.
3. Health Status Reporting: Based on the health check results, the application endpoint returns a success or failure code to the ELB.

Benefits:

• Improved Availability: By monitoring dependencies, deep health checks enable the ELB to take instances out of service if they can’t access critical components, preventing them from serving potentially failing traffic.
• Enhanced Monitoring: Deep health checks provide a more comprehensive view of application health by incorporating dependency health alongside instance health.

Considerations:

• Implementation Complexity: Setting up deep health checks requires additional code within your application to perform the health checks and report results.
• Increased Load: These checks introduce additional load on the application instances. Careful design and optimization are necessary to minimize performance impact.
• Fail Open vs. Fail Closed: Deep health checks can be configured with either “fail open” or “fail closed” behavior. Choose the approach that aligns with your application’s requirements.

In summary, the Deep Health Check Pattern in AWS allows applications to inform the ELB about the health of critical dependencies, leading to improved application availability and more comprehensive health monitoring. However, it requires additional development effort and introduces some load considerations.