Google Cloud Account Purchase: GoogleCloudCDN Acceleration Principle and Configuration Tutorial
In the sea circle and multinational SaaS teams, when talking about network acceleration, many people's first reaction is to buy various third-party CDNs. But if your own business, server (Compute Engine) or storage (Cloud Storage) is already on Google Cloud (GCP), give up the native
Google Cloud CDN
It is simply a waste of time.
Many brothers know nothing about the power of Google. Today we will tear up those obscure official documents and talk in plain language: why does Google Cloud CDN allow global users to access you as fast as in a local LAN? And how do we avoid those hidden charging pits in actual configuration.
Part I: Google Cloud CDN's Dimension Reduction Strike: Anycast Architecture
How does an ordinary CDN work? When you match the domain name, the CDN manufacturer will give you a CNAME address. When the user accesses, the user's request is "redirected" to the node closest to him through DNS resolution. This way is very traditional, but there is a hard injury:
DNS resolution takes time and often resolves to the wrong place across operators.
Google has taken a completely different path, using the ultimate black technology in the online world--
Global Anycast IP
.
You can look at the above architecture diagram, which is the ruthlessness of Google Cloud Network:
The world shares an IP: whether your users are in Los Angeles (LAX) or New York (NYC), when they visit your website, the public IP resolved is exactly the same.
Edge nodes directly intercept: as shown in the figure, the user in Los Angeles initiates a request, and the traffic is directly intercepted by Google's local edge node (Edge POP LAX) in Los Angeles at the network routing layer as soon as it goes out.
Terrible intranet back-to-origin: What if the edge cache (Edge Caches) does not have the data you want? If you switch to a normal CDN, you have to go through the congested public network back-to-origin. After Google's edge nodes intercept the traffic, they will directly plug it into Google's own private optical fiber backbone network (Google Network) spread all over the world, and the green light will flash back to your source station all the way.
Old Bird vernacular: With Google Cloud CDN, users have already downloaded the web page on the Google node a few kilometers away before they even start a long cross-border DNS path finding.
Part 2: How to Configure Google Cloud CDN
In GCP,
Cloud CDN cannot be created independently.
. It is directly "parasitic" in
GCP Global Load
Cloud Load Balancing (HttpClient/HTTPS LB)
on a switch.
Let's take the example of accelerating a website hosted on Compute Engine and go through the standard configuration process:
Step 1: Create a Server Load Balancer and turn on the CDN switch
Log in to the GCP console, find Network Service $\rightarrow $Load Balancing, and click Create.
Select HTTPS load balancing from the Internet to my virtual machines (global deployment mode).
When configuring the backend service (Backend Services), select the server instance group (Instance Group) where you put the page.
[Core Step]: At the bottom of the backend service configuration, you will see an inconspicuous checkbox: "Enable Cloud CDN. Without hesitation, put it on!
Step 2: Select your "Cache Mode"
After checking CDN, the system will let you choose
Cache mode
Here are the key options that determine your performance and wallet:
Mode 1: Use the source station response header (Default). GCP caches only if your back-end code (such as Nginx or Node.js) explicitly returns Cache-Control: public, max-age = 3600. If your back-end code is not matched, CDN will be useless and traffic will penetrate every day.
Mode 2: Cache all static content (RECOMMENDED). The most recommended independent station or App to choose this. Google will automatically identify images, videos, CSS, JS for caching.
Mode 3: Force Cache all content. No matter what the backend says, it will always be cached. [Big Pit] Unless your website is full of pure static dead pages, don't choose this! Once selected, the user's login status, shopping cart and background sensitive API will also be cached across the network, directly causing serious rogue serial number accidents.
Part III: A Guide to "Saving Money and Saving Life" for Operation and Maintenance of Old Birds
Google's things are easy to use, but "expensive" is also true. If it is not properly configured, the monthly traffic bill can make your flesh die. The following three points are the lessons learned from the old bird's use of real money:
1. Beware of double billing caused by "dynamic API back to source"
If your domain name (such
api.yourdomain.com
) all connected to the CDN load balancing, although you put
/api/
The path is set to not cache, but these dynamic traffic will still go through the network of CDN nodes.
After
Dynamic traffic that passes CDN nodes but misses (CDN Cache Misses)
, the network traffic fee charged is often a little more expensive than ordinary load balancing public network visits.
Correct approach: static resources (pictures, front-end files) go to an independent subdomain name (such as static.yourdomain.com) and open CDN; Pure dynamic API goes to another subdomain name, does not turn on CDN, and goes directly to load balancing, so the bill will look much better.
2. Make good use of "TTL coverage" to prevent the source station from being washed away
In the configuration, it is recommended to manually set a
"Maximum Cache Time to Expiration (Maximum TTL)"
. For example, set it to 7 days.
In this way, even if your back-end Nginx accidentally writes the wrong configuration file, resulting in some static pictures without cache headers, Google will force you to carry the traffic for 7 days at the edge node, and will never let the surging user requests directly overwhelm your fragile back-end server.
3. How to clean up the error cache in seconds (Cache Invalidation)
The code has a Bug online. What if the wrong JS has been cached by Google to the world?
Don't panic, go to your load balancing page, click to enter the CDN tab, and find
Invalidate Cache
.
Enter in Path
/*
(clear the whole station) or
/static/js/main.js
(Clean up a single file). Thanks to Google's global Anycast backbone, it refreshes extremely quickly and usually
Within 1 to 2 minutes
The error cache of the global node can be wiped out.
Summary
Google Cloud CDN is not a simple "bandwidth saving tool", it is Google over the past 20 years to invest trillions of dollars to build out
The world's top private network highway
, rented directly to you.
As long as you sort out the symbiotic relationship between it and load balancing, match the caching rules of dynamic and static separation, and carefully avoid the charging trap of dynamic traffic back to the source, it can use a simple single IP to help you easily handle the high concurrent and fast access of hundreds of millions of users around the world.
