오리진을 지키는 캐시 한 겹 더: 오리진 실드와 계층형 캐시의 원리

엣지가 늘수록 오리진이 시달린다: 중복 요청 문제

CDN의 기본 원리는 단순합니다. 사용자와 가까운 엣지에 콘텐츠를 캐시해 두고, 캐시에 있으면 오리진까지 가지 않고 바로 돌려주죠. 그런데 엣지 노드가 전 세계로 많아지면 뜻밖의 문제가 생깁니다. 어떤 콘텐츠가 처음 요청되거나 캐시가 만료된 순간, 여러 지역의 엣지가 각자 오리진에 같은 콘텐츠를 요청하는 상황이 벌어져요.

인기 있는 콘텐츠일수록 이 중복은 커집니다. 전 세계 엣지가 동시에 하나의 오리진을 두드리면, 정작 콘텐츠를 보관한 원본 서버가 트래픽 급증에 흔들릴 수 있죠. 캐시를 앞에 두어 오리진을 보호하려던 CDN이, 엣지가 늘어난 탓에 오히려 오리진에 중복 요청을 몰아주는 셈입니다. 여기서 필요한 것이 엣지와 오리진 사이에 캐시를 한 겹 더 두는 발상입니다.

엣지와 오리진 사이 한 겹: 오리진 실드란

오리진 실드(Origin Shield)는 이름 그대로 오리진 앞을 지키는 캐시 계층입니다. AWS는 오리진 실드를 두고 "캐싱 인프라의 추가 계층"으로, 오리진의 부하를 최소화하고 가용성을 높이며 운영 비용을 줄여 준다고 설명합니다. Fastly는 같은 개념을 실딩(Shielding)이라 부르며, "전 세계 요청이 하나의 지정된 실드 POP으로 모인다"고 정리하죠.

핵심은 모든 엣지 요청이 이 한 계층을 거치도록 만든다는 데 있습니다. 기존에는 여러 엣지가 각자 오리진으로 향했다면, 실드를 두면 엣지들의 요청이 먼저 실드에 모입니다. 실드에 콘텐츠가 있으면 거기서 응답하고, 없을 때만 오리진으로 넘어가죠. 결국 오리진 입장에서는 자신을 마주하는 창구가 여러 엣지에서 하나의 실드로 좁혀지는 셈입니다. 엣지, 실드, 오리진으로 이어지는 계층형(티어드) 캐시 구조가 만들어집니다.

요청을 하나로 모은다: 캐시 적중과 요청 병합

계층을 하나 더 두면 두 가지가 좋아집니다. 첫째는 캐시 적중률이에요. AWS 문서 기준 여러 캐싱 계층의 요청이 모두 오리진 실드를 거치므로 캐시 적중 가능성이 높아지고, 오리진에서는 객체당 한 번의 요청으로 가져올 수 있습니다. Fastly도 실딩이 캐시 적중률(CHR)을 높인다고 같은 취지로 설명하죠.

둘째는 요청 병합입니다. 인기 콘텐츠가 캐시에 없는 찰나에 동시 요청이 몰리면 오리진이 위험한데, AWS 문서는 실드 캐시에 없는 콘텐츠 요청이 같은 객체의 다른 요청들과 통합되어 오리진으로는 최소 한 건만 간다고 밝힙니다. 덕분에 트래픽이 갑자기 튀는 순간에도 오리진의 가용성을 지키기 쉬워지죠. 캐시 수명(TTL)을 어떻게 잡느냐도 오리진 부하에 영향을 주는데, 그 설계는 Cache-Control TTL 설계 글에서 다뤘습니다.

언제 쓰고 언제 피하나: 트레이드오프

오리진 실드가 늘 정답은 아닙니다. AWS 문서는 오리진 실드에 추가 요금이 든다고 분명히 밝히고, 오리진으로 그대로 전달되는 동적 콘텐츠나 캐시 적합성이 낮은 콘텐츠, 요청이 드문 콘텐츠에는 잘 맞지 않을 수 있다고 설명합니다. 또 오리진과 같은 리전에서 오는 요청은 실드를 우회하죠. 계층을 하나 더 두는 만큼, 캐시가 잘 먹히는 콘텐츠일 때 효과가 큽니다.

반대로 잘 맞는 상황도 뚜렷합니다. AWS는 시청자가 여러 지역에 흩어져 있거나, 라이브 스트리밍의 실시간 패키징이나 이미지 처리처럼 오리진 연산이 무거운 경우, 용량·대역폭이 제한된 온프레미스 오리진, 여러 CDN을 함께 쓰는 멀티 CDN 환경을 대표적인 유스케이스로 꼽습니다. 콘텐츠 성격과 트래픽 분포를 보고, 계층을 하나 더 두는 값이 그만한 효과를 낼지 따져 보는 것이 핵심입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)