AWS Account Purchase: Optimize Global User Access with Amazon Route 53 Delayed and Fault Routing
To be a technical friend of multinational business, cross-border e-commerce or overseas independent station, Metropolis faces an extremely headache:
The access experience of global users is very different.
.
If your server is set up in the United States, users in Europe and the United States will have smooth access, but users in Asia or the Middle East will open the web page as slowly as an ox cart. However, if you spend money on piling up servers in every region, not only will the daily operation and maintenance budget go directly to off the charts, but how to accurately drain users from different countries to the servers closest to them is also a hard-core technology job.
In the AWS (Amazon Web Services) ecosystem, the ultimate commander for global drainage and network optimization is called
Amazon Route 53
.
Today we don't talk about empty official theories and reject rhetoric. We'll start straight from the field and teach you how to combine Route 53's two ace strategies--
Delayed routing (Latency Routing) and fault routing (Failover, also called failover routing)
, configure a set of intelligent shunt architecture that can not only accelerate global users, but also fully automatic disaster tolerance.
Phase 1: Delayed routing (Latency Routing)-let the network choose its own optimal path
Many people have a misconception that "geographic routing (Geolocation Routing)" should be used to divert users around the world ". For example, Chinese users go to Hong Kong servers and American users go to Oregon servers.
Geography is not the same as network speed. Due to submarine cable failures, cross-border gateway congestion and other reasons, sometimes European users even faster than servers in the United States.
The underlying logic of delayed routing is very clever
: AWS edge nodes around the world regularly measure the true network latency (Latency) of different IP segments to each AWS Region (Region).
When a Japanese user visits your website, Route 53 will check the current network market and find that his delay is 20ms even in the Tokyo Region and 150ms even in the US Region. Therefore, Route 53 will point the domain name resolution to the Tokyo server in seconds. This kind of drainage method of "speaking with real network speed" is the real intelligent shunt.
Actual Combat: Configure Global Delay Split Network
Let's assume: Your business is in Tokyo (ap-northeast-1)
and
Virginia (us-east-1) each deployed an identical set of Web servers.
Sign in to the AWS console and search for Route 53.
Click to go to your Hosted Zone and click Create Record ".
Create the first record (pointing to Tokyo): Record name: for example, api.yourdomain.com. Routing strategy: drop-down menu does not hesitate to select
"Delay (Latency)". Region: Select ap-northeast-1 (Tokyo). Value/Traffic Routing Destination: Enter the public IP of your Tokyo server (or the domain name of the Tokyo ALB load balancer). Record ID: A name that can be understood, such as Tokyo-Server.
Create a second record (pointing to the United States): The record name remains the same, still api.yourdomain.com. Also select Delay (Latency) for the routing policy ". Region: Select us-east-1 (Virginia). Value/Traffic Routing Destination: Enter the IP or ALB domain name of the US server. Record ID: Name US-Server.
Click Save. At this point, the global intelligent delay network is welded to death. Asian users get Tokyo IP when visiting, while American users get US IP when visiting. Both sides take their own highways without interfering with each other.
Phase II: Fault routing (Failover Routing)-double insurance for global traffic
With delayed routing, global user access speeds are up. But at this time, the operation and maintenance supervisor will definitely send out soul torture: "In case the entire computer room in Tokyo blows up one day, or the local optical cable is cut off, will Asian users not directly cut off the network and report errors?"
In order to prevent this region-level disaster, we must put a layer on the basis of delayed routing.
Fault Routing (Failover)
.
The logic of fault routing is
"Primary and secondary elimination system"
(Active-Passive). It stares at your server through a health check. As soon as the primary server lights up the red light, it immediately melts the traffic and cuts it all to the backup server.
Core Difficulty: How to perfectly blend delayed routing and fault routing?
If you match directly in the console, you will find that only one routing strategy can be selected for a record, and there is no way to select both "delay" and "fault".
big factory standard solution is:
Take advantage of Route 53's Traffic Flow visualization canvas or use the Multi-Level Nested Record approach
. Here I teach you the most intuitive, do not spend money
nested record method
.
Step 1: Create separate health checks for two regions
In the left menu of Route 53, click Health Checks-> Create Health Checks ".
Build a Tokyo-Health to stare at the port of the Tokyo server (e. g. 80 or 443); Build another US-Health and stare at the US server. Set to probe every 10 seconds.
Step 2: Assemble advanced nested logic
We want to create a logic:
Advanced "delay router" for global users ".
“
Delay Router "takes Asians to" Tokyo Fault Checkpoint ".
The "Tokyo Fault Checkpoint" check found that the Tokyo server was alive (Primary) and released. If Tokyo dies, people will be automatically diverted to the US backup disk (Secondary).
In order to achieve this, we need to assign a set of Failover records to each of the two regions. However, note that in order not to conflict with the global domain name, we can use the second-level private domain name for transit.
A simpler modern approach is to use Route 53 directly.
"Traffic Policy (Traffic Policies)"
Graphical interface:
Click "Traffic Policy"-> "Create Traffic Policy".
Rule Layer 1: Add a delay rule (Latency rule).
Under the Tokyo delay branch, do not directly fill in IP address, but click Add Failover Rule (Failover rule): Main (Primary): Fill in Tokyo server and bind Tokyo-Health. Minor (Secondary): Fill in the US server.
Under the US delay branch, also add a failover rule (Failover rule): primary (Primary): fill in the US server and bind US-Health. Secondary (Secondary): Fill in the Tokyo server.
What is the beauty of this structure? At ordinary times, everyone goes his own way by delaying. Once the Tokyo Region fell, the Failover rules of the Tokyo branch were immediately triggered, forcing Asian users who had been diverted to Tokyo to turn and send them to American machines.
Although the delay for Asian users to visit the United States will be slightly higher, because the American machine is still alive, your business will be preserved and will not be paralyzed on a large scale.
The third stage: on-line verification and real field exercise
After this set of doll structure is matched, don't throw it directly there. We must verify whether it is really working.
1. Verify Delay Smart Shunt
Find a few friends in different regions, or use global ping tools (such
ping.pe
or
itdog
):
Have nodes in Japan or Hong Kong ping api.yourdomain.com to see if the returned IP address is from the Tokyo computer room.
Let the nodes in new york and Los Angeles in the United States ping to see if they are returning to the American computer room. If it is right, it means that the delay route is on the precise guard.
2. Simulated disaster drill (highlight)
Pick a pick a few people late at night, let's physical test fault routing:
Log on to the Tokyo server and manually stop the Nginx or Apache service (stop), or directly block port 80/443 in the security group to actively trigger the health check failure.
Keep an eye on the health check console of Route 53. In about 30 seconds to 1 minute, Toky
The o-Health green light will turn red.
At this point, visit your site again at the Asian node. If the website can still be opened normally after a few seconds of loading, and the network request is checked and the traffic has quietly run to the server in the United States, it means that the fault route has won a big victory.
At the end of the drill, the service in Tokyo will be restarted immediately. After Route 53 detects the resurrection, it will automatically pick up the Asian traffic back, and the whole process will be seamless.
Phase IV: Costs under the global architecture and the history of avoiding the pit.
TTL (Time to Live) trade-off: DNS resolution is cached. When creating these advanced route records, the TTL must not be set too large (the default of 300 seconds or several hours is absolutely not acceptable). The standard TTL recommendation for Enterprise Smart Split is set to 60 seconds. If the setting is too large, after the Tokyo server is hung up, even if the Route 53 background is cut to the United States, the user's browser is still caching the old address, and the fault recovery time (RTO) will be lengthened indefinitely.
Synchronization overhead for multiactive databases: Front-end network and compute layer offloading is simple, but don't forget the data layer. Since both servers can pick up customers, how can the data written into the database on both sides be synchronized? You need to use Amazon Aurora Global Database (Global Database) or multi-master replication technology, otherwise the data will not match, and the front-end shunt will be a castle in the air no matter how beautiful it is.
Billing Abacus: The basic parsing fee of Route 53 is extremely cheap ($0.5 a month for a hosting area), but the advanced traffic policy (Traffic Flow) and the volume-based parsing bound with health check are calculated separately. However, this routing fee is almost negligible compared to the huge losses caused by a global business shutdown and customer churn due to a computer room outage.
Summary
The core of using Amazon Route 53 to play with global traffic is"
Pursue the ultimate speed with delayed routing, and hold the bottom line of high availability with fault routing.
”. By nesting these two underlying logics together, you are equivalent to arranging a group of tireless, binocular intelligent traffic police in the global network. No matter how strong the wind and waves are and the roads are blocked, they can also use the best and safest way to bring your users to the server's door safely.