为什么 Cloudfront 会在几个小时内从缓存中驱逐对象? [英] Why is Cloudfront evicting objects from cache within mere hours?

问题描述

Cloudfront 配置为缓存来自我们应用程序的图像.我发现图像很快从缓存中被逐出.由于图像是动态生成的，这对我们的服务器来说非常重要.为了解决这个问题，我设置了一个测试用例.

Cloudfront is configured to cache the images from our app. I found that the images were evicted from the cache really quickly. Since the images are generated dynamically on the fly, this is pretty intense for our server. In order to solve the issue I set up a testcase.

图像从我们的原始服务器提供，带有正确的 Last-Modified 和 Expires 标头.

The image is served from our origin server with correct Last-Modified and Expires headers.

由于该站点仅支持 HTTPS，因此我将 Viewer Protocol Policy 设置为 HTTPS.Forward Headers 设置为 None，Object Caching 设置为 Use Origin Cache Headers.

Since the site is HTTPS only I set the Viewer Protocol Policy to HTTPS. Forward Headers is set to None and Object Caching to Use Origin Cache Headers.

我在 11:25:11 请求了一张图片.这返回了以下状态和标题:

I requested an image at 11:25:11. This returned the following status and headers:

• 代码:200(正常)

• 缓存:否

• Code: 200 (OK)

• Cached: No

到期:格林威治标准时间 2016 年 9 月 29 日星期四 09:24:31

Expires: Thu, 29 Sep 2016 09:24:31 GMT

稍后重新加载 (11:25:43) 返回图像:

A reload a little while later (11:25:43) returned the image with:

• 代码:304(未修改)

• 缓存:是

• Code: 304 (Not Modified)

• Cached: Yes

到期:格林威治标准时间 2016 年 9 月 29 日星期四 09:24:31

Expires: Thu, 29 Sep 2016 09:24:31 GMT

将近三个小时后(在 14:16:11)我转到了同一页面并加载了图像:

Nearly three hours later (at 14:16:11) I went to the same page and the image loaded with:

• 代码:200(正常)

• 缓存:是

• Code: 200 (OK)

• Cached: Yes

到期:格林威治标准时间 2016 年 9 月 29 日星期四 09:24:31

Expires: Thu, 29 Sep 2016 09:24:31 GMT

由于图像仍被浏览器缓存，因此加载速度很快.但我无法理解 Cloudfront 如何无法返回缓存的图像.因此应用程序不得不重新生成图像.

Since the image was still cached by the browser it loaded quickly. But I cannot understand how the Cloudfront could not return the cached image. Therefor the app had to generate the image again.

我了解到 Cloudfront 会在几天处于非活动状态后从其缓存中驱逐文件.如上所述，情况并非如此.怎么会这样?

I read that Cloudfront evicts files from its cache after a few days of being inactive. This is not the case as demonstrated above. How could this be?

推荐答案

我了解到 Cloudfront 会在几天处于非活动状态后从其缓存中驱逐文件.

I read that Cloudfront evicts files from its cache after a few days of being inactive.

你有官方消息来源吗?

官方回复:

如果不经常请求边缘站点中的对象，CloudFront 可能会逐出该对象(在其到期日期之前移除该对象)，以便为最近请求的对象腾出空间.

If an object in an edge location isn't frequently requested, CloudFront might evict the object—remove the object before its expiration date—to make room for objects that have been requested more recently.

http://docs.aws.amazon.com/AmazonCloudFront/最新/DeveloperGuide/Expiration.html

缓存对象的保留时间没有保证，需求低的对象更有可能被驱逐……但这并不是您可能没有考虑的唯一因素.驱逐可能不是问题，也可能不是唯一的问题.

There is no guaranteed retention time for cached objects, and objects with low demand are more likely to be evicted... but that isn't the only factor you may not have considered. Eviction may not be the issue, or the only issue.

CloudFront 缓存的对象就像薛定谔的猫.这是一个松散的类比，但我正在使用它:在任何给定时刻，对象是否在云端缓存中"并不是一个是或否的问题.

Objects cached by CloudFront are like Schrödinger's cat. It's a loose analogy, but I'm running with it: whether an object is "in the cloudfront cache" at any given instant is not a yes-or-no question.

CloudFront 有大约 53 个边缘位置(您的浏览器连接的地方，内容在物理上存储)在 37 个城市.一些主要城市有 2 或 3 个.每个到达 cloudfront 的请求都被路由(通过 DNS)到理论上最理想的位置——为简单起见，我们将其称为最接近"的边缘.

CloudFront has somewhere around 53 edge locations (where your browser connects and the content is physically stored) in 37 cities. Some major cities have 2 or 3. Each request that hits cloudfront is routed (via DNS) to the most theoretically optimal location -- for simplicity, we'll call it the "closest" edge to where you are.

Cloudfront 的内部运作不是公开信息，而是基于观察和大概权威来源是这些边缘位置都是独立的.他们不共享缓存.

The internal workings of Cloudfront are not public information, but the general consensus based on observations and presumably authoritative sources is that these edge locations are all independent. They don't share caches.

例如，如果您在德克萨斯州(美国)，并且您的请求通过并缓存在德克萨斯州达拉斯/沃思堡，并且如果您的任何请求都可能到达达拉斯边缘的任何一个位置，然后直到您两次未命中同一个对象，您的下一个请求将是未命中的几率约为 50/50.如果我从我的位置请求同一个对象，我从经验中知道它倾向于通过南本德，印第安纳州，那么我的第一个请求失败的几率是 100%，即使它缓存在达拉斯.

If, for example, your are in Texas (US) and your request routed through and was cached in Dallas/Fort Worth, TX, and if the odds are equal that you any request from you could hit either of the Dallas edge locations, then until you get two misses of the same object, the odds are about 50/50 that your next request will be a miss. If I request that same object from my location, which I know from experience tends to route through South Bend, IN, then the odds of my first request being a miss are 100%, even though it's cached in Dallas.

因此一个对象既不在缓存中也不在缓存中，因为没有该"(单个、全局)缓存.

CloudFront 对最接近"浏览器边缘的确定也可能会随着时间的推移而改变.

CloudFront 确定最近边缘的机制似乎是动态和自适应的.Internet 拓扑结构的整体变化可能会改变边缘位置倾向于接收从给定 IP 地址发送的请求的转变，因此在几个小时的过程中，您连接到的边缘可能会发生变化.影响特定边缘的维护或中断或其他问题也可能导致来自给定源 IP 地址的请求被发送到与典型边缘不同的边缘，这也可能给您一种对象被驱逐的印象，因为新边缘的缓存会与旧的不同.

CloudFront's mechanism for determining the closest edge appears to be dynamic and adaptive. Changes in the topology of the Internet at large can change shift which edge location will tend to receive requests sent from a given IP address, so it is possible that over the course of a few hours, that the edge you are connecting to will change. Maintenance or outages or other issues impacting a particular edge could also cause requests from a given source IP address to be sent to a different edge than the typical one, and this could also give you the impression of objects being evicted, since the new edge's cache would be different from the old.

查看响应标头，无法确定哪个边缘位置处理了每个请求.但是，此信息在CloudFront 访问中提供日志.

Looking at the response headers, it isn't possible to determine which edge location handled each request. However, this information is provided in the CloudFront access logs.

我有一个获取并调整大小的图像服务，每天处理大约 750,000 张图像.它在 CloudFront 后面，我的命中/未命中率约为 50/50.这当然不全是 CloudFront 的错，因为我的图像池超过 800 万，观众遍布世界各地，而且我的 max-age 指令比你的短.自从我上次分析日志以确定哪些未命中"以及如何未命中"似乎出乎意料以来已经有一段时间了(尽管当我这样做时，肯定有一些，但它们的数量并非不合理)，但这很容易完成，因为日志会告诉您每个响应是命中还是未命中，以及识别边缘位置...因此您可以对其进行分析以查看此处是否真的存在模式.

I have a fetch-and-resize image service that handles around 750,000 images per day. It's behind CloudFront, and my hit/miss ratio is about 50/50. That is certainly not all CloudFront's fault, since my pool of images exceeds 8 million, the viewers are all over the world, and my max-age directive is shorter than yours. It has been quite some time since I last analyzed the logs to determine which and how "misses" seemed unexpected (though when I did, there definitely were some, but their number was not unreasonable), but that is done easily enough, since the logs tell you whether each response was a hit or a miss, as well as identifying the edge location... so you could analyze that to see if there's really a pattern here.

我的服务将它的所有输出内容存储在S3中，当有新的请求进来时，它首先向S3存储桶发送一个快速请求，看看是否有可以避免的工作.如果 S3 返回结果，则该结果将返回到 CloudFront，而不是再次执行所有获取和调整大小的工作.请注意，由于 CloudFront 未命中的数量，我没有实现该功能......我从一开始就设计了它，在我什至在 CloudFront 后面测试它之前，因为——毕竟——CloudFront 是一个缓存，根据定义，缓存的内容几乎是易变的和短暂的.

My service stores all of its output content in S3, and when a new request comes in, it first sends a quick request to the S3 bucket to see if there is work that can be avoided. If a result is returned by S3, then that result is returned to CloudFront instead of doing all the fetching and resizing work, again. Mind you, I did not implement that capability because of the number of CloudFront misses... I designed that in from the beginning, before I ever even tested it behind CloudFront, because -- after all -- CloudFront is a cache, and the contents of a cache are pretty much volatile and ephemeral, by definition.

更新:我在上面说过，似乎无法通过检查来自 CloudFront 的请求标头来识别转发特定请求的边缘站点...通过检查传入请求的源 IP 地址来确定准确度.

Update: I stated above that it does not appear possible to identify the edge location forwarding a particular request by examining the request headers from CloudFront... however, it appears that it is possible with some degree of accuracy by examining the source IP address of the incoming request.

例如，如果我从家里访问我的站点，则通过 CloudFront 发送到我的一个源服务器的测试请求从 54.240.144.13 到达，或者当我从办公室访问该站点时从 205.251.252.153 到达——这些位置只是一个相距几英里，但位于州界的两侧，并使用两个不同的 ISP.这些地址的反向 DNS 查找显示这些主机名:

For example, a test request sent to one of my origin servers through CloudFront arrives from 54.240.144.13 if I hit my site from home, or 205.251.252.153 when I hit the site from my office -- the locations are only a few miles apart, but on opposite sides of a state boundary and using two different ISPs. A reverse DNS lookup of these addresses shows these hostnames:

server-54-240-144-13.iad12.r.cloudfront.net.
server-205-251-252-153.ind6.r.cloudfront.net.

CloudFront 边缘站点以最近的主要机场命名，并加上一个任意选择的数字.对于 iad12 ... "IAD" 是华盛顿特区杜勒斯机场的国际航空运输协会 (IATA) 代码，因此这很可能是弗吉尼亚州阿什本的边缘位置之一(它有三，大概最后有不同的数字代码，但我无法仅从这个数据中确认).对于 ind6，IND"与印第安纳州印第安纳波利斯的机场匹配，因此这强烈表明此请求来自南本德，印第安纳州，边缘位置.此测试的可靠性取决于 CloudFront 维护其反向 DNS 条目的一致性.没有记录在任何给定的边缘位置可能有多少独立的缓存；假设只有一个，但可能不止一个，这会增加极少量请求的未命中率，但会消失在大量请求的混合中.

CloudFront edge locations are named after the nearest major airport, plus an arbitrarily chosen number. For iad12 ... "IAD" is the International Air Transport Association (IATA) code for Washington, DC Dulles airport, so this is likely to be one of the edge locations in Ashburn, VA (which has three, presumably with different numerical codes at the end, but I can't confirm that from just this data). For ind6, "IND" matches the airport at Indianapolis, Indiana, so this strongly suggests that this request comes through the South Bend, IN, edge location. The reliability of this test would depend on the consistency with which CloudFront maintains its reverse DNS entries. It is not documented how many independent caches might be at any given edge location; the assumption is that there's only one, but there might be more than one, having the effect of increasing the miss ratio for very small numbers of requests, but disappearing into the mix for large numbers of requests.

这篇关于为什么 Cloudfront 会在几个小时内从缓存中驱逐对象?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！