Global cloud architecture and it’s relationship with Anycast LB
What is global cloud architecture?
In today’s world business wants to serve their cached and dynamic content as close to the users as possible no matter where users is located. (They can be traveling or staying on another location) Adding to this global business, Application owner or SRE need to struggle with global events that produces traffic spikes or DDOs attack around the globe.
Core diffrence between Region/Multi region and global based deployment model is that Multi region architecture creates deployment from regional building blocks so that application is aware of what region it is running in. Coming to global based architecture deployments builds on globally available it can be fabric of network, data storage and databases this makes application code to be location unaware.
When we build global architecture, have to ensure data should be replicated to all region where service runs. This is will be load balanced across regions, so Multiple region will need to have access to read and write the same data. This can be achieved by using Cassandra, cockroachDB or Google spanner. Application can be accessed from any region around the world to execute MYSQL statement. With this Approach and strong consistency it can achieve 99.99999% availability.
Again this is totally business requirements they may not able to achieve strong consistency but they may achieve 99.99999% availability with asynchronous replication and to have consistent data systems.
Global Anycast
There is alternative solution for DNS LB which is Global Anycast to create a deployment capable of instantaneous failover of internet traffic should a multi regional application becomes unavailable in one of its region.
Global anycast uses single IP for the application to route the traffic from user to closest destination IP address for a group of crucial or potential receivers in an cloud provider language we define as edge load balancer.
Anycast based architecture or Global anycast architecture which eliminates DNS LB with multiple domain VIP’s since application only needs a single Global anycast VIP.
Two problems that we may encounter.
- Too many close-by users can overwhelm or over load an edge site where traffic is being sent.
- BGP (border gateway protocol) route calculation might reset the connection because of “route flap".This usually happens where repeated route withdrawal and re-announcement.It can be frequent problems for particular link or misconfiguration and mis management of routers.
To address this issues Google has built own Network Load balancer by stabilizing anycast using Maglev.
This has solved problems like route flap by redirecting a flapped request to a peer Maglev that is responsible of connection.
Maglev is deployed at the edge location. If any edge location is down BGP will re route the traffic to Maglevs in the next closest location.
Adding to this Google has developed own Global load balancer for the global anycast LB. This will distributes traffic to edge sites to ensure an edge site is not overloaded.
The core Global Load balancer algorithm should be incoming request per second load and the capacity of edge proxies and on top of it optimising user latency.
