일주일 전 저는 Prism의 에지 레이어 (edge layer)를 출시했고, 무엇이 좋았고 무엇이 잘못되었는지 설명하는 블로그 포스트를 작성했습

일주일 전 저는 Prism의 에지 레이어 (edge layer)를 출시했고, 무엇이 좋았고 무엇이 잘못되었는지 설명하는 블로그 포스트를 작성했습니다. 좋았던 점: 잘못된 키 (bad keys)가 이제 가장 가까운 Cloudflare PoP에서 거부되므로, Mumbai까지 왕복할 필요가 없습니다. 잘못된 점: 캐시 히트 (cache hits)가 여전히 300~500밀리초 (milliseconds)가 걸렸는데, 이는 캐시 자체인 Upstash Redis가 Mumbai에 위치한 단일 리전 (single-region)이기 때문입니다.

저는 설계 문서 (design doc)에서 50밀리초 (milliseconds)를 약속했습니다. 하지만 저는 300~500밀리초를 출시했습니다. 저는 그 사실을 말씀드렸고, v1.6.5가 그 격차를 줄일 것이라고 말했습니다. 오늘이 바로 v1.6.5입니다.

제가 출시한 것

Cloudflare Workers KV는 전 세계적으로 복제되는 키-값 저장소 (key-value store)입니다. Cloudflare API를 통해 한 번 쓰면, 몇 초 이내에 그 값이 전 세계 모든 Cloudflare 데이터 센터 (datacenter)에 저장됩니다. 읽기 (Reads) 작업은 요청이 도달하는 PoP에서 로컬로 수행되며, 일반적으로 어디서든 30~80밀리초 (milliseconds)가 소요됩니다.

v1.6.5는 두 가지 변경 사항이 있습니다:

1. Mumbai 백엔드 (backend)가 새로운 캐시 항목을 Upstash에 저장할 때, Workers KV에도 병렬 쓰기 (parallel write)를 실행합니다. 두 쓰기 작업 모두 파이어 앤 포겟 (fire-and-forget) 방식이며, 고객의 응답은 어느 쪽도 기다리지 않습니다.
2. Cloudflare Worker는 캐시 가능한 요청을 받으면 먼저 Workers KV를 확인합니다. 만약 KV에 항목이 있다면, 거기서 응답을 제공합니다 — Mumbai까지 갈 필요가 없습니다. 만약 KV에서 미스 (miss)가 발생하면, v1.6과 정확히 동일하게 Upstash로 넘어가며, 백그라운드에서 KV로 쓰기 처리 (writes-through)를 수행하여 전 세계 어디에서든 다음 요청이 KV에서 제공될 수 있도록 합니다.

Upstash가 신뢰할 수 있는 원천 (source of truth)으로 유지됩니다. KV는 읽기 처리 캐시 (read-through cache)이며, 대략 60초의 타임스케일 (timescale) 내에서 최종 일관성 (eventually consistent)을 가집니다. 폴백 경로 (fallback path) 덕분에 정확성은 결코 위협받지 않습니다. 어떤 이유로든 KV가 오래되었거나 비어 있다면, 워커 (worker)는 Upstash를 읽으며 고객은 해당 요청에 대해 v1.6 시대의 지연 시간 (latency) 프로필을 보게 됩니다. 고객이 두 번째 요청을 보낼 때쯤이면 KV는 동기화되어 있을 것입니다.

수치

어제 싱가포르(제 뭄바이 노트북에서 curl을 날려 흉내 내는 것이 아닌, 실제 Cloudflare PoP)에서 3회 요청 스모크 테스트 (smoke test)를 실행했습니다. 동일한 요청을 세 번 연속으로, 동일한 API 키와 동일한 모델로 보냈습니다. 새로운 X-Prism-Edge-Cache-Layer 응답 헤더를 통해 어떤 레이어에서 히트 (hit)가 발생했는지 확인할 수 있습니다.

요청 1 (캐시 미스 (cache miss)):                    6.52s   뭄바이로 패스스루 (passthrough)
요청 2 (Upstash 히트, KV가 아직 워밍업되지 않음):  0.48s   x-prism-edge-cache-layer: redis
요청 3 (write-through 후 KV 히트):             0.18s   x-prism-edge-cache-layer: kv

요청 3은 해외 고객을 위한 정상 상태 (steady-state) 수치입니다. 184밀리초 (milliseconds). 여기에는 요청 파싱 (parse), 분류기 (classifier) 실행, 캐시 핑거프린트 (cache fingerprint) 생성, KV 읽기, 그리고 응답 직렬화 (serialize)에 소요되는 시간이 모두 포함되어 있습니다. 실제 KV 읽기 시간은 약 40밀리초이며, 나머지는 워커 오버헤드 (worker overhead)입니다.

비교를 위해: 싱가포르에서 동일한 요청을 보냈을 때 v1.6의 수치는 요청 2 라인인 484밀리초였습니다. 에지 레이어 (edge layer)가 아예 존재하지 않았던 v1.5의 수치는 약 700밀리초였습니다. 따라서 v1.6.5는 v1.5보다 약 3.8배 빠르고, v1.6보다 2.6배 빠릅니다.

샌프란시스코에서는 수치가 훨씬 더 극적일 것입니다. 왜냐하면 샌프란시스코에서 v1.6을 사용할 경우 뭄바이 왕복 시간 (round-trip)이 1초에 가깝지만, 미국 PoP에서의 KV는 여전히 ~50밀리초이기 때문입니다. 아직 실제 미국 머신에서 curl을 실행해 보지는 못했지만, 지리적 계산상 속도 향상 비율은 5배에 더 가까울 것으로 보입니다. 합성 스모크 테스트 (synthetic smoke tests) 대신 대시보드에서 읽어낼 수 있을 만큼 충분한 고객 트래픽이 발생하면 제대로 측정해 보겠습니다.

내가 이틀을 할당했던 작업

나는 v1.6.5 작업에 이틀이 걸릴 것으로 예상했습니다. 이 포스트를 쓰는 시간을 포함해도 대략 4시간 정도 걸렸습니다. 세 가지 요소 덕분에 비용을 아낄 수 있었습니다.

v1.6의 핑거프린트 포트(fingerprint port)는 이미 완료된 상태였습니다. v1.6에서 엣지(edge)에 캐시 조회(cache lookup)를 배치한다는 것은 Python의 exact-cache 핑거프린트를 TypeScript로 포팅하고

• v1.4 정책 및 거버넌스 (Policy + Governance) — 고객은 감사 로그 (audit log)와 함께 모델을 거부하거나 프로젝트별로 예산을 제한할 수 있습니다.
• v1.5 라우터 강화 (Router Hardening) — 다운된 제공업체는 이동 평균 윈도우 (rolling-window) 상태 게이트를 통해 자동으로 등급이 낮아집니다. 장애 발생 기간에는 헤드 오브 라인 블로킹 (head-of-line blocking)을 방지하기 위해 투기적 병렬 라우팅 (speculative parallel routing)이 수행됩니다.
• v1.6 엣지 라우팅 (Edge Routing) — 인증 (auth) 및 캐시 조회 (cache lookup)가 고객과 가장 가까운 PoP (Point of Presence)에서 발생합니다. 잘못된 키는 뭄바이 (Mumbai)까지 도달하지 않습니다.
• v1.6.5 Workers KV 복제 (Workers KV replication) — 캐시 히트 (cache hit) 시 인도 고객뿐만 아니라 어디에서나 약 30~80ms 내에 서비스됩니다.

남은 격차는 인프라가 아닌 제품의 폭에 관한 것입니다. 엣지에서의 시맨틱 캐시 (Semantic cache)가 그중 하나입니다 (임베딩 (embedding)을 위해 Workers AI가 필요할 것입니다). 뭄바이 콜 패스 (Mumbai cold-paths)를 위한 두 번째 리전 (region) 구축이 또 다른 과제입니다 (Caddy와 두 번째 EC2를 사용하는 것이 명확한 형태입니다). 두 가지 모두 몇 시간이 아닌 몇 주가 걸리는 작업입니다.

이 모든 여정을 시작하게 만든 샌프란시스코의 고객 — 제가 이 엣지 포스트들의 프레임워크로 계속 사용하고 있는, 뭄바이까지의 250ms RTT (Round Trip Time)를 겪고 있는 그 고객 — 에게 v1.6.5는 제가 실제로 그들의 눈을 똑바로 바라보며 "Prism을 사용하세요, OpenAI를 직접 호출하는 것보다 나쁜 선택이 아닙니다"라고 말할 수 있는 첫 번째 릴리스입니다. 그것이 제가 도달하고자 했던 기준이었습니다. 저는 우리가 그 기준에 도달했다고 생각합니다.

직접 확인하고 싶다면: api.ssimplifi.com의 임의의 /v1/chat/completions 엔드포인트에 동일한 페이로드 (payload)로 두 번 요청을 보낸 뒤, 몇 초 후에 세 번째 요청을 보내보세요. 세 번째 응답의 X-Prism-Edge-Cache-Layer 헤더를 확인하십시오. 만약 kv라고 표시되어 있고, 뭄바이 이외의 지역 어디에서든 총 소요 시간이 200ms 미만이라면, v1.6의 약속은 이행된 것입니다.