2026. 7. 17 (금) · 약 9분
서울의 사용자가 사이트를 열었는데, 캐시를 거친 요청이 시카고를 들렀다가 싱가포르 원본으로 가는 상황을 떠올려 보자. 원본 IP는 가까워 보이지만 실제 서버 위치를 말해 주지 않는 anycast 주소라면 이런 우회가 가능하다. Cloudflare가 AWS·GCP·Azure·Oracle Cloud 원본에 리전 힌트를 받기 시작한 이유와, 켜기 전에 확인할 조건을 경로·설정·한계 순서로 살펴본다.
오늘의 핵심뉴스
심층 분석 · Cloudflare Blog · 2026. 7. 10
Cloudflare, 퍼블릭 클라우드 원본용 Smart Tiered Cache 리전 힌트 지원
AWS·GCP·Azure·Oracle Cloud의 anycast 또는 리전 unicast 원본에 클라우드 리전을 알려 주면, Cloudflare가 원본에 더 가까운 주 상위 캐시와 대체 경로를 고를 수 있다.
같은 IP인데 원본 위치를 모를 때
계층형 캐시는 모든 엣지 센터가 원본으로 직접 요청하지 않게 한다. 하위 캐시에 없을 때 먼저 상위 캐시 한 곳을 확인하고, 거기에도 없을 때만 원본으로 간다. 상위 계층을 한 곳에 모으면 같은 객체의 캐시가 흩어지지 않아 적중률이 높아지고 원본 연결도 줄어든다. Smart Tiered Cache는 평소 원본까지의 지연 시간을 보고 이 상위 지점을 자동으로 고른다.
문제는 퍼블릭 클라우드의 로드 밸런서나 전면 서비스가 anycast IP 또는 리전 unicast를 쓰는 경우다. 하나의 IP가 여러 Cloudflare 센터에서 비슷하게 가깝게 보이면, 측정값만으로 실제 백엔드가 있는 리전을 특정하기 어렵다. 이때 Cloudflare는 잘못된 단일 지점을 고르기보다 여러 상위 캐시로 분산하는 안전한 경로를 쓴다. 기능은 계속 작동하지만 캐시가 나뉘어 원본으로 가는 요청이 늘 수 있다.
리전 힌트가 바꾸는 것은 경로 선택
이번 지원 대상은 AWS, GCP, Azure, Oracle Cloud다. 대시보드의 Caching > Tiered Cache > Origin Configuration에서 anycast로 감지된 원본 IP를 찾아 실제 리전을 지정한다. 예를 들어 `aws:us-east-1`이나 `gcp:europe-west1`처럼 제공자와 리전을 함께 준다. Cloudflare는 이 정보를 바탕으로 해당 클라우드 리전에 가까운 주 상위 캐시를 고르고, 장애에 대비한 다른 위치의 대체 경로도 둔다.
| 상황 | 리전 힌트 없음 | 리전 힌트 있음 |
|---|---|---|
| 고정 unicast 원본 | 지연 측정으로 가까운 상위 캐시 선택 | 대체로 별도 조치 불필요 |
| anycast·리전 unicast 원본 | 여러 상위 캐시로 안전하게 분산될 수 있음 | 실제 클라우드 리전 근처의 주 상위 캐시와 대체 경로 선택 |
| 기대 효과 | 원본 보호는 유지하지만 캐시 효율이 낮아질 수 있음 | 상위 캐시 집중으로 원본 요청과 우회 가능성을 줄이는 방향 |
설정은 켜기 전에 원본 네트워크부터 확인한다
리전 힌트는 모든 원본에 넣는 일반적인 성능 스위치가 아니다. 먼저 원본 도메인이 어떤 클라우드 제공자 앞단을 쓰는지, 실제 워크로드가 어느 리전에 있는지 확인해야 한다. 대시보드에서 힌트를 입력할 수 있는 대상은 Cloudflare가 anycast로 감지한 원본 IP다. 고정 unicast 원본이라면 지연 측정만으로 위치를 충분히 판단할 수 있으므로 힌트가 필요하지 않을 수 있다.
리전 힌트는 Free·Pro·Business·Enterprise 전 요금제에서 추가 비용 없이 사용할 수 있다. 다만 Custom Tiered Cache를 구성했다면 그 토폴로지가 리전 힌트보다 우선한다. 이 경우 힌트만 바꿔도 상위 캐시 경로가 달라질 것이라고 기대하면 안 된다.
확인 순서
1. 원본 IP가 anycast 또는 리전 unicast 앞단인지 확인
2. 실제 백엔드가 있는 클라우드 제공자와 리전 확인
3. Caching > Tiered Cache > Origin Configuration으로 이동
4. 해당 원본 IP에서 Set Region Hint 선택
5. http_requests 로그의 CacheTieredFill로 Tiered Cache 사용 확인
6. 설정 전후 같은 기간의 MISS·원본 요청·사용자 지연 비교
`CacheTieredFill`은 해당 요청에 Tiered Cache가 사용됐는지 확인하는 값이다. 이 값만으로 성능 개선을 단정하지 말고, 같은 기간의 `MISS`, 원본 요청 수, 실제 사용자 지연 시간을 함께 비교해야 한다.
DNS나 IP를 바꾸면 캐시도 다시 워밍업된다
공식 문서는 Smart Tiered Cache를 켠 상태에서 원본 IP나 DNS 레코드를 바꿀 때 주의하라고 안내한다. 기존에 선택된 상위 캐시가 달라지면 새 상위 계층이 캐시를 다시 채우는 동안 `MISS`가 증가할 수 있다. 이는 리전 힌트가 틀렸다는 증거가 아니라, 경로와 캐시 저장 위치가 바뀐 뒤의 자연스러운 재가열 과정일 수 있다. 변경 시간, TTL, 배포량을 함께 기록하지 않으면 효과를 잘못 읽기 쉽다.
또한 주 상위 캐시가 가까워져도 모든 응답이 빨라진다고 단정할 수는 없다. 동적 응답 비중, 캐시 제어 헤더, 원본 애플리케이션 지연, 사용자와 엣지의 거리도 결과에 영향을 준다. 힌트의 목적은 anycast 주소 때문에 생긴 위치 추론의 빈칸을 메우는 것이며, 애플리케이션 자체의 병목을 해결하지는 않는다.
바로 적용하기 전 체크리스트
- 원본이 AWS·GCP·Azure·Oracle Cloud 중 하나이며, 실제 백엔드 리전을 알고 있는가?
- 해당 원본 IP가 anycast 또는 리전 unicast 앞단인지 확인했는가?
- Cloudflare가 대시보드에서 그 IP를 anycast 원본으로 감지했는가?
- 원본 IP·DNS 변경 직후의 MISS 증가를 별도 이벤트로 기록할 수 있는가?
- 적중률뿐 아니라 원본 요청 수와 실제 사용자 지연 시간을 같은 기간으로 비교할 수 있는가?
캐시 경로는 사용자에게 보이지 않지만, 원본에 요청이 집중되는 순간 비용과 장애 여유에 드러난다. 퍼블릭 클라우드 앞단의 IP가 실제 위치를 숨기는 구성이라면, 리전 힌트는 복잡한 경로 최적화보다 먼저 확인할 수 있는 작은 설정이다.
참고한 자료
리전 힌트는 캐시를 더 많이 만들거나 원본을 옮기는 기능이 아니다. anycast IP가 숨긴 실제 클라우드 리전을 알려 주어, 상위 캐시의 선택을 더 정확하게 만드는 보정값이다. 원본의 네트워크 형태와 리전을 확인하고, 변경 뒤에는 `MISS`와 원본 요청을 함께 관찰해야 효과를 제대로 판단할 수 있다.
'최신 IT·개발 소식' 카테고리의 다른 글
| Hugging Face 보안 공지 뒤 해야 할 일: 토큰 회전과 최소 권한 점검 순서 (1) | 2026.07.19 |
|---|---|
| WordPress 7.0.2 보안 업데이트: Cloudflare WAF가 있어도 패치해야 하는 이유 (0) | 2026.07.18 |
| Dependabot 3일 쿨다운: 일반 업데이트와 보안 업데이트 차이, 설정법까지 (0) | 2026.07.16 |
| 낮 3시간의 전기부터 패키지 업데이트까지, 자동화를 기다리게 하는 이유 (0) | 2026.07.16 |
| 250억 원 청구서부터 AI 보안 경고까지, 자동화 결과를 다시 보는 법 (0) | 2026.07.15 |
