Chapter 7. Caching
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Caches and Advertising
If you’ve made it this far, you’ve realized that caches improve performance and reduce traffic. You know caches can help users and give them a better experience, and you know caches can help network operators reduce their traffic.
-
여기까지 읽으셨다면 캐시가 성능을 향상시키고 트래픽을 감소시킨다는 점을 알게 되었을 것입니다.
-
또한 캐시가 더 나은 사용자 경험을 제공하고 있으며 네트워크 사업자가 트래픽을 감소시킨다는 점을 알게 되었을 것입니다.
The Advertiser's Dilemma
You might also expect content providers to like caches. After all, if caches were everywhere, content providers wouldn’t have to buy big multiprocessor web servers to keep up with demand—and they wouldn’t have to pay steep network service charges to feed the same data to their viewers over and over again. And better yet, caches make the flashy articles and advertisements show up even faster and look even better on the viewer’s screens, encouraging them to consume more content and see more advertisements. And that’s just what content providers want! More eyeballs and more advertisements!
-
콘텐츠 제공업자도 캐시를 선호하리라는 것을 예상할 수 있습니다.
-
캐시가 어디에나 존재한다면, 콘텐츠 제공업자가 수요를 따라잡기 위해 거대한 멀티프로세서 웹 서버를 구매할 필요가 없습니다.
-
동일한 데이터를 소비자들에게 몇 번이고 실어나르기 위해 비싼 네트워크 비용을 지불하지 않아도 됩니다.
-
캐시는 화려한 기사와 광고를 훨씬 더 빠르고 보기 좋게 사용자의 화면에 노출하여 그들이 더 많은 콘텐츠와 광고를 소비하도록 할 수 있습니다.
-
이것이 바로 콘텐츠 제공업자들이 바라는 바입니다.
-
더 많은 시선과 더 많은 광고 말입니다.
But that’s the rub. Many content providers are paid through advertising—in particular, they get paid every time an advertisement is shown to a user (maybe just a fraction of a penny or two, but they add up if you show a million ads a day!). And that’s the problem with caches—they can hide the real access counts from the origin server. If caching was perfect, an origin server might not receive any HTTP accesses at all, because they would be absorbed by Internet caches. But, if you are paid on access counts, you won’t be celebrating.
-
하지만 그게 좋은 것만은 아닙니다.
-
많은 콘텐츠 제공업자들이 광고를 통해 수익을 얻습니다.특히 광고가 사용자에게 노출될 때마다 금전적 보상을 받습니다.
-
아마 그 금액은 한두 푼에 불과하겠지만 하루에 수백만 개의 광고가 노출된다면 합산된 금액은 어마어마할 것입니다.
-
그리고 이것은 캐시와 연관된 문제를 발생시킵니다.
-
콘텐츠 제공업자는 원본 서버의 실제 접근 횟수를 숨길 수 있습니다.
-
만약 캐싱이 완벽하다면 원본 서버는 HTTP 요청을 전혀 받지 않을 것입니다. 모든 리소스가 인터넷 캐시에 의해 제공될 테니까요.
-
그럼에도 접근 횟수만큼 수익을 얻게 된다면 전혀 좋은 일이 아닌 것입니다.
The Publisher's Response
Today, advertisers use all sorts of “cache-busting” techniques to ensure that caches don’t steal their hit stream. They slap no-cache headers on their content. They serve advertisements through CGI gateways. They rewrite advertisement URLs on each access.
-
오늘날 광고주들은 온갖 종류의 "cache-busting(캐시 차단)" 기술을 활용합니다. 캐시가 Hit Stream을 훔치지 못하도록 보장하는 것입니다.
-
그들은 no-cache 헤더를 콘텐츠의 삽입하여 CGI 게이트웨이를 통해 광고를 전달합니다.
-
그리고 매번 접근할 때마다 광고의 URL을 다르게 작성합니다.
And these cache-busting techniques aren’t just for proxy caches. In fact, today they are targeted primarily at the cache that’s enabled in every web browser. Unfortunately, while over-aggressively trying to maintain their hit stream, some content providers are reducing the positive effects of caching to their site.
-
이러한 캐시 차단 기술이 프록시 캐시에 대한 것만은 아닙니다.
-
캐시 차단 기술은 오늘날 모든 웹 브라우저에서 이용 가능한 캐시를 주요 타겟으로 동작하고 있습니다.
-
안타깝게도 일부 콘텐츠 제공업자들은 Hit Stream을 지키기 위해 지나치게 공격적으로 캐싱을 사용하면서 캐싱의 긍정적인 효과를 감소시키고 있습니다.
In the ideal world, content providers would let caches absorb their traffic, and the caches would tell them how many hits they got. Today, there are a few ways caches can do this.
-
이상적으로 콘텐츠 제공업자는 캐시가 트래픽을 제공하고, Hit 횟수를 원본 서버에 전달하기를 원할 것입니다.
-
최근에는 캐시가 이를 수행할 수 있는 몇 가지 방식이 등장했습니다.
One solution is to configure caches to revalidate with the origin server on every access. This pushes a hit to the origin server for each access but usually does not transfer any body data. Of course, this slows down the transaction.
-
한 가지 솔루션은 캐시가 매번 접근할 때마다 원본 서버에 재검증을 요청하도록 구성하는 것입니다.
-
이는 접근이 발생할 때마다 Hit 정보를 원본 서버에 전달하지만 보통 어떠한 본문 데이터도 전달하지 않습니다.
-
물론 당연히 트랜잭션의 속도는 감소합니다.
Log Migration
One ideal solution wouldn’t require sending hits through to the server. After all, the cache can keep a log of all the hits. Caches could just distribute the hit logs to servers. In fact, some large cache providers have been know to manually process and hand-deliver cache logs to influential content providers to keep the content providers happy.
-
또 하나의 이상적인 솔루션은 원본 서버로 Hit 정보를 전송할 필요가 없는 것입니다.
-
무엇보다도 캐시는 모든 Hit 정보에 대한 로그를 가지고 있습니다.
-
캐시는 Hig 로그를 선별하여 서버에 전송하기만 하면 됩니다.
-
실제로 일부 대규모 캐시 제공업자들은 콘텐츠 제공업자의 만족도를 유지하기 위해 캐시 로그를 수동으로 처리하여 영향력 있는 콘텐츠 제공업자에게 전달하기도 합니다.
Unfortunately, hit logs are large, which makes them tough to move. And cache logs are not standardized or organized to separate logs out to individual content providers. Also, there are authentication and privacy issues.
-
안타깝게도 Hit 로그는 크기가 커서 전송하기가 까다롭습니다.
-
그리고 캐시 로그는 표준화, 조직화되어 있지 않아 각각의 콘텐츠 제공업자에 대한 로그를 분리해내기 어렵습니다.
-
여기에는 인증과 개인정보 보호 문제도 있습니다.
Proposals have been made for efficient (and less efficient) log-redistribution schemes. None are far enough developed to be adopted by web software vendors. Many are extremely complex and require joint business partnerships to succeed.* Several corporate ventures have been launched to develop supporting infrastructure for advertising revenue reclamation.
-
효율적인 로그 재분리 체계에 대한 제안사항이 있었지만, 지금까지 웹 소프트웨어 제공업자에 의해 채택될 만큼 충분히 개발된 것은 없습니다.
-
로그 재분리 체계는 지나치게 복잡하고, 개발에 성공하기 위해 여러 회사들간의 제휴가 필요합니다.
-
광고 수익 재창출을 위한 지원 인프라를 구축하기 위해 몇몇 벤처 기업들이 등장하기도 했습니다.
Hit Metering and Usage Limiting
RFC 2227, “Simple Hit-Metering and Usage-Limiting for HTTP,” defines a much simpler scheme. This protocol adds one new header to HTTP, called Meter, that periodically carries hit counts for particular URLs back to the servers. This way, servers get periodic updates from caches about the number of times cached documents were hit.
-
RFC 2227 "Simple Hit-Metering and Usage-Limiting for HTTP)에서는 보다 간단한 체계를 정의하고 있습니다.
-
이 프로토콜은 HTTP에 "Meter"라고 하는 새로운 헤더를 하나 추가합니다.
-
Meter는 특정 URL에 대한 Hit 횟수를 주기적으로 원본 서버에 전달하는 작업을 수행합니다.
-
이러한 방식으로 서버는 캐싱된 문서의 Hit 횟수를 주기적으로 업데이트할 수 있게 되었습니다.
In addition, the server can control how many times documents can be served from cache, or a wall clock timeout, before the cache must report back to the server. This is called usage limiting; it allows servers to control how much a cached resource can be used before it needs to report back to the origin server.
-
추가로, 서버는 캐시가 서버에 다시 보고하기 전에 캐시에서 문서를 제공할 수 잇는 횟수나 타임아웃을 조절할 수 있게 되었습니다.
-
이것을 Usage Limiting이라고 합니다.
-
캐시가 원본 서버에 보고해야 하는 시점까지 캐싱된 리소스가 얼마나 사용될 수 있는지를 서버 측에서 제어할 수 있게 합니다.
We’ll describe RFC 2227 in detail in Chapter21.
- RFC 2227은 Chapter 21에서 자세히 설명합니다.
✏️ 요약
Advertising with Caches
- 장점
- 비용 감소(웹 서버 비용, 동일 데이터 전송에 의한 네트워크 비용 등)
- 더 많은 광고 노출
- 단점
- 원본 서버가 캐시의 Hit 횟수를 제대로 반영하지 못하면 노출 건수만큼 수익을 얻지 못함
- 해결 방안
- Cache-busting(캐시 차단)
- no-cache 헤더를 사용하여 캐시가 Hit Stream을 훔치지 못하도록 한다
- 캐시의 장점 감소
- Must-revalidate
- 캐시에 접근할 때마다 원본 서버에 재검증을 요청하도록 구성한다
- 1보다는 효율적이지만 여전히 트랜잭션 속도 감소
- Log Migration
- 특정 URL에 대한 캐시의 Hit 로그를 선별하여 콘텐츠 제공업자에 전달한다
- 로그가 표준화되어 있지 않아 매우 복잡 + 개인정보 보호 문제 발생
- RFC 2227
- Meter 헤더를 통해 주기적으로 원본 서버에 Hit 횟수를 전달한다
- 가장 효율적
- Cache-busting(캐시 차단)
✏️ 감상
광고 수익을 극한으로 창출하기 위한 묘수
이 책은 꽤 오래 전에 작성되었기 때문에 지금은 책에 언급된 것과 전혀 다른 기술을 사용하고 있을지도 모른다. 요즘에도 Meter 헤더를 사용하고 있는지, 그게 아니라면 어떤 식으로 광고 수익을 극대화하고 있을지가 문득 궁금해졌다.
찾아보니 최근에는 클라이언트 측에서 서버로 이벤트를 전송하는 방식이 주로 활용되는 것 같다. Hit 횟수를 토대로 광고의 노출 건수를 판단하는 것이 아니라 클라이언트에서 전달된 이벤트만큼 수익을 계산하는 것이다. 이 방식은 캐시의 장점을 그대로 살리면서도 노출 건수를 누락시키지 않을 수 있어 효과적이다.
오늘날에는 CPC(Cost Per Click) 방식 외에도 CPA(Cost Per Action), CPV(Cost Per View) 등 다양한 광고를 활용하고 있다. 때문에 노출 건수만을 고려한 위의 방식들에 비해 클라이언트 측에서 이벤트를 전송하는 방식이 주류가 되었다. 이벤트 기반 방식은 물건을 구매하거나, 홈페이지를 클릭하거나, 동영상을 재생하는 등 사용자의 특정 행동을 감지하여 수익을 창출하는 데 유리하다.
이걸로도 모자라 요즘에는 광고 수익을 극한으로 끌어올리기 위해 사용자 기반으로 광고를 추천하는 등 인공지능까지 활용하는 추세다. 역시 모든 기술은 돈을 벌기 위해 시작하는 법이다. 금전적인 문제가 결부되어 있으면 기술은 빠르게 성장할 수밖에 없다. 다 먹고 살자고 하는 짓 아니겠냐~!~!
