Building Geographically Distributed Enterprise Applications — Part 2
In the first part of this article series, we discussed about some concepts of geographically distributed applications and ways of building such multi-regional application with an API layer. Main focus of the architecture discussed in part 1 is to support API traffic in all regions (i.e. active-active deployment).
In this article, we are discussing about extending that architecture to support failover regions. In order to support failover, one or more sub regions should contain all components of the deployment. Figure 1 shows such failover deployment with a main region (region 1) and one sub region (region 2).
Note that as with the part 1 of this series, we are focusing on WSO2 API Manager to provide more detailed content on this subject.
Below are the key points in this architecture:
- All components of the API layer are deployed in both regions.
- All API databases and user stores are deployed in both regions.
- API databases and user stores are replicated from region 1 (main region) to region 2.
- Back end systems have to be deployed in both regions and data replication has to be done where necessary.
- API calls can be directed to any region. However, API calls are usually directed to the local region to minimize network delays.
- User authentication and token generation requests can be directed to any region.
- API creations, application registrations, API subscriptions and user registrations (including self-sign up) have to performed ONLY in the main region. These data update operations are restricted to the main region in order to avoid the need of two-way data replication among regions.
As we discussed in part 1, main region’s traffic manager updates all gateways about API updates and subscriptions. Therefore, API calls can be made to gateways in any region.
Furthermore, this architecture also contains API Manager all-in-one cluster in both regions, which supports user authentication and token generation. As the database is replicated from region 1 to region 2, region 2’s all-in-one cluster also has access to API and user information. Therefore, user authentication and token generation requests can also be directed to any region. This can be become useful if an organization has a very large number of users who are frequently logging in to the system (e.g. online retail company with deployments in multiple countries).
As all components are deployed in both regions (including databases) and data is replicated, it is possible for any region to act as a failover region. In case of a failure in region 2, region 2’s API traffic and authentication requests can be directed to region 1. In case of region 1 failure, region 1’s API traffic, authentication requests as well as API creation, subscription and user registration traffic needs to be directed to region 2.
Applying multi-region patterns
This architecture can provide active-active multi-region deployment with failover support. However, as this architecture requires all components in each region, it has a higher licensing and infrastructure cost compared to the non-failover architecture discussed in part 1. Therefore, we can combine both this architecture and the part 1’s architecture to design large distributed deployments with failover support while reducing costs where applicable.
Below is the overall structure of such architecture:
- Deploy one main region with all components and databases.
- Deploy a failover deployment in one region (more than one failover regions can be used if necessary).
- Deploy non-failover deployments in all other regions that needs to be served.
Figure 2 illustrates such multi-region deployment with one main region, one failover region and two non-failover regions.
All regions in the above deployment can handle API traffic. This is an important property as API calls made by client application in a given region can be handled by the same region’s API layer. Therefore, possible performance issues due to network delays among regions can be avoided. Furthermore, API call payloads do not have to leave regional boundaries, which could be helpful in complying with certain data protection regulations.
Both region 1 and region 2 can handle authentication and token requests. Therefore, if a region expects a very large number of authentication requests, it is possible have a failover deployment in that region.
Main region’s API management plane will update all regional API data planes about API updates and subscriptions. Furthermore, all regional API data planes send API usage data to the main region’s management plane. Therefore, APIs of all regions can be governed and monitored by the main region, which is an important requirement for most business applications.
Either region 1 or 2 can act as the failover region for region 3 and 4. Region 1 (main region) can act as the failover region for region 2. Finally, region 2 can act as the failover region for the main region (i.e. region 1). Therefore, this architecture provides a highly available, geographically distributed, low latency, centrally managed API layer with a reduced licensing and infrastructure cost.
