KV 작동 방식

Cloudflare Workers KV가 어떻게 동작하는지, 쓰기·읽기 흐름, 성능, 일관성, 그리고 어떤 워크로드에 적합한지 알아봐요. 전역 저지연 키-값 저장소의 내부 원리를 이해하면 올바른 사용 사례를 고르는 데 큰 도움이 돼요.

출처: 문서

본문

KV는 전역적이고 저지연인 키-값 데이터 저장소예요. 적은 수의 중앙 데이터 센터에 데이터를 저장한 다음, 접근된 후에는 Cloudflare의 데이터 센터에 그 데이터를 캐시해요.

KV는 매우 높은 읽기 볼륨을 낮은 지연으로 지원해요. KV의 내장 캐싱과 전역 배포 덕분에 확장되는 동적 API를 구축할 수 있어요. 캐시에 없고 중앙 저장소에 접근해야 하는 요청은 더 높은 지연을 경험할 수 있어요.

KV에 데이터 쓰기 및 KV에서 데이터 읽기

KV에 쓸 때 데이터는 중앙 데이터 저장소에 쓰여져요. 데이터가 모든 위치의 캐시에 자동으로 전송되지는 않아요.

한 위치에서의 초기 읽기는 캐시된 값이 없어요. 데이터는 가장 가까운 리전 티어에서 읽혀야 하고, 그 다음 중앙 티어, 마지막으로 완전히 콜드한 전역 읽기를 위해 중앙 저장소로 내려가야 해요. 첫 접근은 전역적으로 느리지만, 이후의 요청은 특히 요청이 단일 리전에 집중된다면 더 빨라져요.

핫 읽기와 콜드 읽기 — 핫 읽기는 CDN ↗︎을 사용해 데이터가 Cloudflare의 에지 네트워크에 캐시된다는 뜻이에요 (로컬 캐시든 리전 캐시든). 콜드 읽기는 데이터가 캐시되지 않아 중앙 저장소에서 가져와야 한다는 뜻이에요.

같은 위치에서 자주 읽으면 캐시된 값을 다른 어디에서도 읽지 않고 반환해 가장 빠른 응답 시간을 제공해요. KV는 캐시가 만료되기 전에 백그라운드에서 상위 티어 캐시와 중앙 데이터 저장소에서 새로고침해 캐시된 값을 부지런히 업데이트해요.

상위 티어와 중앙 데이터 저장소에서 백그라운드로 새로고침하는 작업은, 접근 중인 에셋이 중단 없이 계속 캐시에서 제공되도록 신중하게 수행돼요.

KV는 높은 읽기 애플리케이션에 최적화되어 있어요. 데이터를 중앙에 저장하고 하이브리드 푸시/풀 기반 복제를 사용해 데이터를 캐시에 저장해요. KV는 상대적으로 드물게 쓰지만 빠르고 자주 읽어야 하는 사용 사례에 적합해요. 드물게 읽히는 값은 다른 데이터 센터나 중앙 저장소에서 풀링되는 반면, 더 인기 있는 값은 요청된 데이터 센터에 캐시돼요.

성능

KV 성능을 개선하려면 기본값 60초인 cacheTtl 매개변수를 올려 보세요.

KV는 캐싱 ↗︎을 통해 높은 성능을 달성하며, 이로 인해 읽기가 쓰기에 대해 최종적으로 일관되게(eventually consistent) 만들어진다.

변경 사항은 일반적으로 변경이 이루어진 Cloudflare 글로벌 네트워크 위치에서 즉시 보여요. 다른 글로벌 네트워크 위치에서는 캐시된 버전의 데이터가 타임아웃되므로 변경이 보이는 데 최대 60초 이상 걸릴 수 있어요.

키가 존재하지 않음을 나타내는 네거티브 조회(negative lookup)도 캐시되므로, 값이 만들어졌음을 알아차리는 데에도 값이 변경되었을 때와 같은 지연이 존재해요.

일관성

KV는 최종적으로 일관되도록 동작해서 높은 성능을 달성해요. 변경이 이루어지는 Cloudflare 글로벌 네트워크 위치에서는 일반적으로 즉시 보여요. 하지만 이것은 보장되지 않으므로 이 동작에 의존하는 것은 권장하지 않아요. 다른 글로벌 네트워크 위치에서는 캐시된 버전의 데이터가 타임아웃되므로 변경이 보이는 데 최대 60초 이상 걸릴 수 있어요.

변경의 가시성은 주어진 키의 이전 버전을 최근에 읽은 위치 (키가 존재하지 않음을 나타낸 읽기도 포함하며, 이 또한 로컬로 캐시됨) 에서 더 오래 걸려요.

원자적 연산을 지원하거나 값이 단일 트랜잭션에서 읽고 쓰여져야 하는 애플리케이션에는 KV가 이상적이지 않아요. 더 강한 일관성 보장이 필요하다면 Durable Objects를 고려해 보세요.

쓰기-후-쓰기(write-after-write) 일관성을 달성하는 한 가지 접근 방식은 주어진 KV 키에 대한 모든 쓰기를 해당 Durable Object 인스턴스를 통해 보낸 다음, 다른 Workers에서 그 값을 KV에서 읽는 것이에요. 이는 쓰기에 대한 더 많은 제어가 필요하지만 위에서 설명한 KV의 읽기 특성에 만족할 때 유용해요.

가이드

Workers KV는 최종적으로 일관된 에지 키-값 저장소예요. 따라서 다음과 같은 읽기 위주(read-heavy) 이고 캐시 가능성이 높은 워크로드에 이상적이에요:

• 정적 에셋 제공하기
• 애플리케이션 설정 저장하기
• 사용자 기본 설정 저장하기
• 허용 목록/차단 목록(allow-lists/deny-lists) 구현하기
• 캐싱

이러한 시나리오에서 Workers는 사용자와 가장 가까운 데이터 센터에서 호출되고, Workers KV 데이터는 후속 요청을 위해 해당 리전에 캐시되어 지연을 최소화해요.

같은 키를 초당 수십 번 또는 수백 번 업데이트하는 쓰기 위주(write-heavy) 의 Redis ↗︎형 워크로드가 있다면 KV는 이상적인 선택이 아니에요. 애플리케이션이 단일 키-값 쌍에 쓰는 방식을 재고하고 여러 개의 개별 키에 쓰기를 분산할 수 있다면, Workers KV가 요구에 맞을 수 있어요. 또는 Durable Objects는 키당 더 높은 쓰기 속도 제한을 가진 키-값 API를 제공해요.

보안

Workers KV가 데이터를 어떻게 보호하는지 이해하려면 데이터 보안 문서를 참조하세요.

더 알아보기 (Learn more)

KV의 읽기/쓰기 API와 바인딩 사용법은 KV 바인딩, KV 네임스페이스, 그리고 읽기/쓰기 문서에서 확인할 수 있어요.