How many zones are required in single region
In cloud, Region defines specific geographic location. In which all apps will get deployed and run their services.
Region consists of multiple zone. Each apps and their entire stacks gets deployed on each zone. Basically each app stacks gets replicated to each zones.
Single region focus on specific geographic location for example single country it can be united states or UK. This is used for various reasons To optimize the latency, where users are served from the same region they reside in , provide data sovereignty or location requirements, where user data is kept and served from a single country or region. To further increase availability and reliability, some applications may have a secondary standby region with an asynchronous copy of the data, where the application can failover to the secondary region in case the primary region is not available.
What exactly Single region is ?
Running an application in a region means running an application deployed across multiple zones within that region, where each zone is treated as an independent failure domain.
The best practice is to replicate the application across all of the zones within that region and keep the size of each deployment approximately the same across zones.
This will make sure the application always has capacity available in other zones when there is a zonal failure.
Let’s take complex application architecture . In this example, we have a service named “FE front end” that contains the interface the end-users interact through, a service “BE BackEnd” that contains the business logic of the application, and a Cloud-managed database (e.g., MYSQL) that holds the application’s data. In addition, there are load balancers in front of each service to load-balance requests across them.
So the request flow will be user→(FE)Front-End→(BE)Back-End→MYSQL and the response in the opposite order.
In reality, applications consist of a large number of services and microservices, ranging from tens to hundreds in the same application.
The single-region application should try to achieve higher availability by replicating data as well as compute workloads across multiple zones within the region.
To achieve this for data has to replicated, most Clouds support replicating MYSQL synchronously across the zones within a region.
writes and reads go to the primary zone for the MYSQL instance even though the data is replicated across zones for durability. There can also be read replicas configured across all zones, where read requests are served from the closest zone.
When a request comes into Load Balancer 1, the request may be forwarded to any healthy replica of the FE service in any of the zones in the region, and then the request path is latency-optimized to keep the request flow within the same zone as the request traverses multiple services.
A request arriving at FE(A) will be sent to BE(A) to optimize latency by keeping the request within the same zone. Then the request to the MYSQL database may be across zones. The MYSQL(primary) is running in one of the zones, and communication with the MYSQL(primary) may happen across the zones, as writes are always sent to the primary.
If one zone become unhealthy due to software failure, such as bad binary rollout for the FE or BE service, or due to infrastructure failure such as a power outage event, the requests destined to that zone will be routed to another zone.
If the zone where the primary instance of SQL fails, then automatic failover is initiated for the MYSQL(primary) and a standby replica now becomes the new primary. To achieve availability during failover, applications should retry requests or re-establish a new connection to the database.
Example, assume that the MYSQL(primary) is in zone B and assume the BE microservice in zone B becomes unhealthy. For a request that comes into FE(B), the Load Balancer 2 will know that BE(B) is unhealthy and choose a different back-end to route the traffic to.
In this case, the traffic flow coming into zone B is now FE(B)→BE(C)→MYSQL(B) or FE(B)→BE(A)→MYSQL(B).
By this approach the load balancers can route the traffic around failures within a specific zone at a specific service layer.
For a single-region deployment, a question that comes up is how many zones is required to run the application. By default it three zone as per standard topology in Cloud. This make clear State application is run across all three zones and it uses the Cloud provider managed regional storage and database services to manage the data.
The reason for using three zones instead of two zones is because the loss of one zone means losing one-third of the serving capacity instead of half of the capacity.
Not having enough serving capacity left after the loss of the zone can impact availability as it takes time for auto scaling to kick in.
Another reason is to survive the unlikely but possible event of two simultaneous failures across two zones
One caused by the application and the other by the Cloud provider.
1. Issue in the application causes a single zone outage (e.g., as the application is incrementally updated one zone at a time and an outage is potentially found after the first zone is updated)
2. Cloud provider has an issue that results in one zone having an outage. With three zones, an application can still be available even if two zones have issues (one due to the application update and one due to the Cloud provider).
