brief introduction
In-game resources include materials such as player equipment/ammunition/materials. The release and update of in-game resources is a routine business process for game operators, and the frequency of use will be very high. Therefore, game operators hope that the process can be simplified and improved. controllable. In response to this requirement, we designed 3 architectures, oriented to 3 typical scenarios of in-game resource update release, to optimize the in-game resource update release process. The 3 scenarios are:
Grayscale update of in-game resources
In-game resources are distributed by channels
In-game resource black and white list
The three architectures are implemented around the Amazon CloudFront service of Amazon Cloud Technology - CloudFront edge computing service - WAF service.
Scenario 1: Grayscale update of in-game resources
During the operation of the game, there will be resource update requirements, which are described by a simple model: old resource A needs to be replaced with new resource B. However, there is a pain point here. Before the B resource is promoted to all CDNs, the correctness of the resource needs to be confirmed internally or in a small area. Therefore, a way is needed to ensure that resource B has only limited access even if it is updated at the source; most players still access resource A in the CDN cache. After the B resource is verified, it will be promoted to all nodes through CDN refresh.
The difficulty in realizing this requirement lies in: without any modification on the client side, use the same URL to direct a small number of user requests to resource B; resource A and resource B cannot share caches, so as not to cause resource access conflicts. We use CloudFront Continuous Deployment to achieve this requirement:
The configuration steps are as follows:
Create a Staging Distribution
Functional Verification
Scheduling traffic
officially launched
CloudFront's continuous deployment function is intuitive to implement, and users can implement canary-style resource updates by controlling the request ratio; the cost is lower than deploying CloudFront's edge script CloudFront Function.
Create a Staging Distribution
▪Under the CloudFront production distribution, click "create staging distribution"
▪You can enter the description of Staging Distribution, then click "Next"
▪Create a new origin site. Users can correspondingly create a new source site to deploy resource B (using the same directory structure); they can also deploy resource B to another directory on the existing source site, then create a new Host container, and create it on the DNS server A record pointing to the new Host container
*Note: We have rewritten the origin path in the new origin, so that the client does not need to make changes.
▪Traffic configuration select "header-based" ratio first select 0
▪Create Staging Distribution
▪At this point, the Staging Distribution is created, wait for about 10 minutes for the deployment to complete
Functional Verification
This can be verified using the command line tool curl:
resource_b download:
curl -H 'aws-cf-cd-resource:b' -v -o /dev/null 'https://www.company.com/resource'Swipe left to see more
resource_a Download:
curl -H -v -o /dev/null 'https://www.company.com/resource'Swipe left to see more
By observing the characteristics of the downloaded file, such as the number of bytes or ETAG, it is judged whether resource objects with different contents have been downloaded.
Scheduling traffic
▪Click on 'Edit Policy'
▪Modify the traffic scheduling strategy in the pop-up window, and schedule 1% of the traffic for gray release
officially launched
After the user officially overwrites Resource A with Resource B at the origin site, the user needs to refresh the cache on CloudFront and delete the Staging Distribution
Scenario 2: In-game resources are delivered by channels
During the operation of the game, there will be requirements for putting in different resources for different channels. A simple model is used to describe: For resource A and resource B, players who come in from different channels will see different resources. The pain point here is that customers need to quickly match the corresponding resources for a certain field in the header or a certain keyword in the url.
content overview
In the construction of this solution, we will use CloudFront Function to check the fields in the request header, and replace the source URL Path according to the matched fields. The advantage of this solution is that URL Path Rewrite is imperceptible to end users and conforms to Players coming in from different channels will get different content for the same resource (such as resource A).
The configuration steps are as follows:
Create a CloudFront Function
Create a Behavior to match URL Paths that exist in different channels
Experimental verification and conclusion
Create a CloudFront Function
In this requirement, the content obtained by different channels is different, which means that the path information on the source server side (such as S3) is different. For example, the file path requested by the user is unified as /sample.file, while different channels are on the source server. The real path of the corresponding file is /a_vendor/sapme.file
Or /b_vendor/sample.file, we can extract the request header value according to different channels (carrying different request header information), and replace the return URL. The specific CloudFront Function reference code is as follows:
function handler(event) {
// 获取请求头
var request = event.request;
var headers = event.request.headers;
var originUrl = event.request.uri;
// 检查 x-vendor-type 请求头是否存在
if (headers['x-vendor-type']) {
var targetObject = headers['x-vendor-type'].value
//修改回源 URL Path
event.request.uri = '/' + targetObject + originUrl;
}
return request;
}Swipe left to see more
*Note: The reason why the value of the header here is not directly taken but judged first is that some clients may not carry the x-vendor-type header, if the value is directly taken without adding judgment, then the header does not exist It will cause the CloudFront Function to report an error, and you can also consider it when you deploy the code.
After the CloudFront Function code is saved, we can debug it on the debugging interface and observe the effect:
After submitting the debugging information, you can see that the back-to-source path has been successfully modified, as shown in the figure below:
Deploy the CloudFront code after debugging is correct:
Create Behavior matches
There are URL Paths for different channels
Here, for the convenience of displaying the effect, we use Behavior in CloudFront to perform path matching according to requirements, and the matching here is displayed as "/abtest-demo*".
Since only URL rewriting is done here, different channels will get different content for the same URL. Here you also need to differentiate the cache for different request headers in Behavior. You can customize the Cache Policy and set x The -vendor-object request header is used as part of the Cache Key for cache distinction:
After customizing Cache Policy, apply it in Behavior:
In the origin policy, the custom request header needs to be transparently transmitted so that CloudFront Function can check the request header. You can customize the Origin Policy, or choose AllViewer to transparently transmit the custom request header.
Since the event type that the override logic runs is Viewer Request, you need to apply the CloudFront Function logic deployed above in the correct event in the Behavior definition.
Experimental verification and conclusion
On the source service side, we store different versions of files for channels A and B for debugging. Here, the corresponding relationship between the sample files is as follows:
Channel A: a_vendor
Channel B: b_vendor
Carry the corresponding request header, and observe the effect after multiple requests:
//在请求头中携带 A 渠道特殊标识，回源真实路径为/a_vendor/example.file
% curl -v http://cloudfront-function.xxxxxxx.com/example.file -H 'x-vendor-type: a_vendor' 2>&1 | egrep 'X-Cache|This content'
< X-Cache: Hit from cloudfront
This content is for a vendor!
//在请求头中携带 B 渠道特殊标识，回源真实路径为/a_vendor/example.file
% curl -v http://cloudfront-function.xxxxxxx.com/example.file -H 'x-vendor-type: b_vendor' 2>&1 | egrep 'X-Cache|This content'
< X-Cache: Hit from cloudfront
This content is for b vendor!
//在请求头中不携带渠道特殊标识，回源真实路径为/example.file
% curl -v http://cloudfront-function.xxxxxxx.com/example.file 2>&1 | egrep 'X-Cache|This content'
< X-Cache: Hit from cloudfront
This content is for general usage without vendor!Swipe left to see more
Through the above demonstration, we have successfully verified the following three setting requirements:
You can clearly see that for the same URL path as /example.file, we have successfully rewritten the back-to-source URL through different x-vendor-type specified content, and obtained the content corresponding to different channels.
If the client does not initiate the request through a channel and does not carry a special identification header, the content can also be obtained successfully.
In the case of a cache hit, since the Cache Policy uses x-vendor-type as part of the cache, requests can still hit their corresponding caches as expected when the URLs are the same.
Scenario 3: black and white list of in-game resources
scene description
During the operation of the game, different players have different access behavior requirements, which are described by a simple model: Player A needs to be placed in the whitelist, and player B needs to be placed in the blacklist.
Use a more specific scenario description: Assume that WAF web ACL needs to be used to match the request containing "PostmanRuntime/x.xx.x" in the user-agent , and deny access to the request.
For the above scenario, it can be realized by checking the User-Agent with heavy request header. For requests, there are usually several links: client → public network → Amazon CDN access point → origin site. Then it is a better choice to put the pressure of checking the header on the CDN, which can effectively reduce the pressure on the original site. There are also several ways to detect on the CDN side. The first thing that comes to mind is to use edge function/lambda on CDN. The challenge here is the need to maintain the code. Another better way is to use WAF to check the rules. When WAF configures Web ACL, it needs to configure the conditions of allowing and blocking. Typically included conditions are:
Whether the request appears to contain malicious script Allow or block the request → Cross-site scripting match condition
The IP address the request originates from Allow or block the request → IP Match Condition
The country from which the request originates allows or blocks the request → Geographic match criteria
Whether the request exceeds the specified length to allow or block the request → size constraints
Whether the request appears to contain malicious SQL code Allow or block the request → SQL injection matching condition
The string present in the request allows or blocks the request → string matching condition
The regex pattern present in the request allows or blocks the request → regex match condition
By default, Amazon WAF filters do not check for the presence of HTTP request parameters. To check for the presence of HTTP request parameters, either of the following two custom rules can be used:
Use string matching rules
Use regular expression matching rules
Environmental preparation
Before testing, we need to do the following steps:
1. Enter the Amazon Website Service Console interface, select WAF service, and then select WAF ACLs in the left navigation bar.
2. Create a Rule and name it according to business requirements. Then the object of protection can be CDN or external services such as load balancer. The resource part can be filled in now, or you can wait for the rule to be created before binding.
3. After completing the information entry of the Web ACL, in the second part we select custom rules.
4. In custom rules, we select Rule Builder. And set the name of the Rule.
5. In inspect, select All headers, and select all default keys and values for header content. Of course, you can only monitor specific headers and content according to business needs.
string matching rules
For string matching rules, Web ACL provides the following methods:
Exact matches string: strict match string
Start with string: match the beginning of the string
Ends with string: match the end of the string
Contains string/word: contains a certain string
According to the requirement, just use Start with string, set as follows:
Correct Expression Matching Rules
For regular expression rules, Web ACL provides two matching methods:
▪ regex pattern set: a set of regular expressions, which can be set in advance and can be selected in the panel
▪ regular expression: regular expression, temporary setting
Here we choose the second method, and its setting reference is as follows
Json Format Reference for Final Rules
{
"Name": "StringMatch",
"Priority": 0,
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "StringMatch"
},
"Statement": {
"OrStatement": {
"Statements": [
{
"ByteMatchStatement": {
"FieldToMatch": {
"Headers": {
"MatchScope": "ALL",
"MatchPattern": {
"All": {}
},
"OversizeHandling": "CONTINUE"
}
},
"PositionalConstraint": "STARTS_WITH",
"SearchString": "PostmanRuntime",
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
]
}
},
{
"RegexMatchStatement": {
"FieldToMatch": {
"Headers": {
"MatchScope": "ALL",
"MatchPattern": {
"All": {}
},
"OversizeHandling": "CONTINUE"
}
},
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
],
"RegexString": "/PostmanRuntime[ \\/]+([0-9\\.]+)/gi"
}
}
]
}
}
}Swipe left to see more
rule test
Once the rules are established, we need to apply them to the protected resources. Assuming the origin site is a website with a CDN in front, it just returns a text=ok.
The test is as follows (the value of User-Agent is X-UnrealEngine-Agent):
When the request header contains
PostmanRuntime/x.xx.x , you can see that the request is blocked
In the background interface, you can also count the performance of WAF in the past 5 minutes
Through the above experiments, WAF provides very flexible configuration rules for CDN protection, which can meet the needs of various scenarios. Furthermore, it frees the CDN from the pressure to do rule matching and checking, and lets the CDN do what it is better at.
Summarize
Through Amazon cloud technology CloudFront service - CloudFront edge computing service - WAF service, game operators can complete the update and release of in-game resources under preset conditions without changing the client, improving the agility and simplicity of business deployment .
Amazon Cloud Technology CloudFront
Deployment mini-guide series
Amazon CloudFront Deployment Guide (1) - Quickly build CDN content distribution:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-one/
Amazon CloudFront Deployment Guide (2) - Advanced Deployment:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-two/
Amazon CloudFront Deployment Guide (3) - Continuous Deployment:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-three/
Amazon CloudFront Deployment Guide (4) - CloudFront Function Basics and Diagnosis:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-four/
Amazon CloudFront Deployment Guide (6) - Lambda@Edge Basics and Diagnosis:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-six/
The author of this article
Ye Ming
Amazon cloud technology edge product architect, responsible for the market expansion of CloudFront and Global Accelerator services in China and the world, focusing on the optimization of Internet users' experience of accessing cloud services and data insights. He has extensive practical experience in the field of Internet infrastructure.
Wan Xi
Amazon cloud technology solution architect, responsible for consulting and architectural design . Solid embracer of the Amazon Builder culture. With more than 12 years of experience in game development, he has participated in the management and development of several game projects, and has a deep understanding and insight into the game industry.
Wang Junxing
Amazon Cloud Technology Edge Product Architect, responsible for the technical promotion of Amazon Cloud Technology Edge services in China. He has many years of practical experience in CDN content distribution and WAF field, focusing on edge service design and experience optimization.
I heard, click the 4 buttons below
You will not encounter bugs!
