데이터베이스와 클라이언트가 동일한 지역에 있는 경우 Redis에서 1ms 지연 시간은 쉽습니다. 그러나 클라이언트를 전 세계적으로 분산시키려면 대기 시간이 100ms 이상 증가합니다. 이를 극복하기 위해 Edge Caching을 구축했습니다.
에지 캐싱
에지 캐싱을 사용하면 REST 응답이 CDN과 마찬가지로 전 세계의 에지 위치에 캐싱됩니다. 에지 캐싱이 활성화된 경우 평균적으로 5ms의 전역 대기 시간이 표시됩니다. 10개의 다른 지역에 위치한 클라이언트의 대기 시간 수치를 기록하는 벤치마크 애플리케이션을 참조하십시오. edge url과 일반 REST url에 대한 요청 간의 지연 시간을 비교합니다. 서버와 클라이언트 사이의 거리가 멀어질수록 엣지 캐싱의 영향이 커집니다.
테스트를 직접 실행하려면 여기를 클릭하십시오.
사용 사례
웹/모바일(백엔드리스) 클라이언트
Upstash는 사용자가 백엔드 없이 데이터베이스에 액세스할 수 있도록 읽기 전용 인증 토큰을 제공합니다. 웹 또는 모바일 애플리케이션에서 Redis에 직접 액세스할 수 있습니다. 이 아키텍처에서 클라이언트는 어디에나 있을 수 있습니다. 사용자와 가장 가까운 위치에 데이터를 캐시하는 것이 좋습니다.
다중 지역 서버리스 아키텍처
여러 리전에서 AWS Lambda 함수를 실행하여 글로벌 지연 시간을 줄일 수 있습니다. Vercel/Netlify 기능은 일부 구성의 다른 지역에서 실행됩니다. 에지 캐싱이 포함된 서버리스 Redis는 서버리스 기능이 있는 곳이면 어디든지 빠른 데이터를 제공합니다.
에지 기능
에지 컴퓨팅(Cloudflare 작업자 등)은 전 세계적으로 빠른 애플리케이션을 구축하는 인기 있는 방법이 되고 있습니다. 에지 기능의 문제는 데이터를 유지할 수 있는 옵션이 많지 않다는 것입니다. 에지 캐싱이 포함된 Redis는 대기 시간이 짧고 가벼우므로 에지 기능에 매우 적합합니다.
시작하기
Upstash 콘솔에서 에지 캐싱을 활성화할 수 있습니다. 에지 캐싱에는 추가 비용이 든다는 점에 유의하십시오.
에지 캐싱이 활성화되면 REST API 대화 상자에서 에지 URL을 찾을 수 있습니다. 에지 캐싱은 GET 호출에만 사용할 수 있습니다. 업데이트(POST)의 경우 일반 REST API를 계속 사용할 수 있습니다.
기본적으로 캐시된 응답은 30초 후에 만료됩니다. Cache-Control: max-age=<seconds>로 이를 제어할 수 있습니다. 헤더.
예:
curl https://us1-smart-bunny-32732.edge-c.upstash.io/get/foo \
-H "Authorization: Bearer 2dfgf98elrg0w009c842z2adfdde9132"
-H "Cache-Control: max-age=50"
위 URL에 대한 첫 번째 요청은 원본에서 응답을 가져옵니다. 다음 요청은 엣지 로케이션에서 가져옵니다. 캐시된 응답은 각 엣지 로케이션에서 50초 후에 만료됩니다.
에지 캐싱과 글로벌 데이터베이스 비교
Redis를 여러 지역에 복제하여 글로벌 데이터베이스 구축(업데이트:릴리스됨, 자세히 알아보기)이 로드맵에 포함되어 있습니다. 글로벌 데이터베이스는 쓰기를 복제하여 더 나은 일관성을 보장하고 쓰기 대기 시간을 제공합니다. 그러나 데이터베이스를 모든 지역에 복제하는 것은 비용이 많이 들 수 있습니다. 그래도 모든 위치에서 대기 시간을 최소화하려면 캐싱이 필요할 수 있습니다. 따라서 에지 캐싱과 글로벌 복제는 경쟁이 아니라 서로를 완성하는 솔루션입니다. 사용 사례에서 최종적으로 일관된 읽기를 허용한다면 에지 캐싱은 이미 글로벌 고속 데이터를 제공하는 훌륭한 솔루션입니다.
서버리스 및 에지 데이터에 대한 당사의 노력에 대한 귀하의 의견을 기대합니다. 트위터와 디스코드에서 이야기하세요.