Upstash는 AWS Lambda 기능을 위한 최고의 데이터베이스 옵션이라는 사명으로 여정을 시작했습니다. 한편, 서버리스 기능을 구축할 수 있는 또 다른 훌륭한 옵션인 Cloudflare 작업자를 발견했습니다. 더 낮은 비용과 콜드 스타트 없이 전 세계적으로 더 나은 대기 시간을 약속하기 때문에 흥미로운 제품입니다. 그러나 AWS Lambda와 비교할 때 많은 제한 사항이 있습니다. 추가 제한 사항은 데이터베이스 옵션 목록을 더 짧게 만듭니다. 우리는 이것을 Upstash를 다음 질문에 대한 훌륭한 솔루션으로 포지셔닝할 기회로 보았습니다. CF Workers are stateless. Where should I keep my data then?
도전
접근성
Cloudflare 작업자는 더 폐쇄된 환경입니다. AWS 같지 않습니다. 자체 데이터베이스를 동일한 지역에 설정하고 VPC를 통해 액세스할 수 없습니다. 따라서 작업자 함수에서 데이터베이스에 액세스해야 합니다. Cloudflare 작업자는 V8 격리를 런타임으로 사용합니다. TCP 연결을 허용하지 않습니다. 따라서 데이터베이스는 HTTP를 통해 액세스할 수 있어야 합니다.
전역 복제
작업자는 어디에나 배치할 수 있는 이점이 있습니다. 전 세계에서 짧은 대기 시간으로 함수에 액세스할 수 있습니다. 데이터베이스에 액세스하는 데 수백 밀리초를 소비해서는 안 됩니다. 데이터베이스는 함수가 실행되는 위치와 가까워야 합니다. 이는 데이터를 여러 지역 및 대륙에 복제하여 가능합니다.
낮은 대기 시간
개발자는 모든 곳에서 낮은 대기 시간을 제공하기 때문에 에지 컴퓨팅 솔루션을 선호합니다. 데이터베이스가 병목 상태가 되어서는 안 됩니다. Redis와 같은 인메모리 데이터베이스는 밀리초 미만의 대기 시간을 제공합니다.
Upstash의 여정
REST API
네이티브 Redis API 지원으로 Upstash를 출시했습니다. 모든 Redis 클라이언트가 지원되며 이는 레거시 Redis 애플리케이션에 적합합니다. 그러나 곧 우리는 서버리스 기능에 대한 연결 문제가 있는 사용자를 보기 시작했습니다. 또한 Cloudflare 작업자에서 액세스할 수 없었습니다. 그래서 먼저 GraphQL API를 구현했습니다. 그러나 우리는 프록시 레이어로 인한 성능 오버헤드 때문에 GraphQL API에 만족하지 않았습니다. 또한 GraphQL은 Redis 명령을 실행하는 가장 쉬운 방법이 아닙니다. 성능 오버헤드를 최소화하기 위해 데이터베이스 엔진 내부에 REST 서버를 구축하기로 결정했습니다. REST가 Redis에 더 적합하다고 생각합니다. REST API를 출시했고 Cloudflare 작업자 및 Webassembly에서 Redis에 액세스하려는 개발자들 사이에서 꽤 인기가 있음을 확인했습니다.
에지 캐싱
REST API 덕분에 작업자에서 Upstash에 액세스할 수 있었지만 대기 시간이 이상적이지 않았습니다. 일부 개발자는 Redis 응답을 캐시하기 위해 Cloudflare의 자체 캐싱을 사용하려고 했습니다. 그러나 그것은 복잡한 해결책이었습니다. Redis는 이미 매우 빨라야 하므로 cache Redis하는 것이 좋지 않습니다. 다른 곳. 이것이 우리가 모든 엣지 로케이션에서 Redis REST 응답을 캐시하는 엣지 캐싱을 구축하기로 결정한 이유입니다. Redis 응답을 캐시하기 위해 CDN 제공자를 사용했습니다. 이는 에지 대기 시간에서 최대 80%의 성능 향상으로 상당한 개선이었습니다.
글로벌 데이터베이스
에지 캐싱은 전역 대기 시간 문제에 대한 훌륭한 솔루션이었지만 일부 사용 사례에는 몇 가지 단점이 있습니다. 먼저 캐시 무효화(purge)를 지원하지 않습니다. 캐시의 만료 시간이 30초인 경우 그러면 클라이언트가 오래된 데이터를 읽을 수 있는 30초 창이 있습니다. 이것은 많은 웹 사용 사례에서 허용될 수 있지만 전부는 아닙니다. 둘째, 에지 캐싱은 REST API에 대해서만 지원됩니다. Redis 클라이언트는 에지 캐싱의 이점을 누릴 수 없습니다. 그래서 우리는 데이터를 여러 지역에 복제하는 새로운 데이터베이스 유형을 설계하기로 결정했습니다. 가용성과 일관성이 충분하도록 설계하는 것은 매우 어려웠습니다. 현재 Upstash는 5개의 서로 다른 AWS 리전(북미 동부 및 서부, 유럽, 아시아, 남미)에 데이터를 복제하는 글로벌 데이터베이스 제품을 보유하고 있습니다. 전역 데이터베이스는 캐시가 아니므로 캐시 무효화 문제가 없습니다. 쓰기는 모든 복제본에 즉시 복제됩니다. 성능과 가용성을 위해 Global 데이터베이스는 최종 일관성을 갖도록 설계되었습니다.
에지 캐싱과 글로벌 데이터베이스(또는 둘 다)
에지 솔루션에 대한 캐시만 필요한 경우 에지 캐싱이 좋은 솔루션이 될 수 있습니다. 그러나 캐시를 즉시 무효화하기 위해 쓰기가 필요한 경우 글로벌 데이터베이스를 선호해야 합니다. 캐싱 외에도 글로벌 데이터베이스는 고가용성 글로벌 데이터 저장소로 사용할 수 있습니다. 또한 Edge 캐싱은 REST 호출에만 사용할 수 있습니다. Redis 클라이언트를 사용하는 경우 글로벌 데이터베이스가 에지에서 대기 시간이 짧은 유일한 옵션입니다.
Edge 캐싱과 전역 데이터베이스는 모두 읽기 대기 시간을 최소화하도록 설계되었습니다. 사용 사례가 90% 쓰기인 경우 단일 지역 설정이 더 적합합니다. 쓰기 대기 시간은 다중 및 단일 지역 데이터베이스 모두에 대해 동일하지만 전역 설정에서 5배 더 비쌉니다.
에지 캐싱이 활성화되면 Upstash는 오리진에서 첫 번째 요청을 가져온 다음 에지에 캐시합니다. 오리진이 근처에 없으면 대기 시간이 길어집니다. 모든 경우에 대해 최상의 대기 시간을 원하는 경우 전역 데이터베이스에서 Edge Caching을 활성화하여 둘 다 사용할 수 있습니다.
에지 캐싱과 글로벌 데이터베이스의 대기 시간을 비교하는 벤치마크 애플리케이션을 참조하십시오.
다음은 무엇입니까?
Upstash at Edge를 개선하기 위해 작업할 수 있는 몇 가지 사항은 다음과 같습니다.
- 낮은 쓰기 대기 시간:현재 글로벌 데이터베이스는 단일 리더 아키텍처로 읽기 대기 시간을 최적화하도록 설계되었습니다. 우리는 이것이 대부분의 사용 사례를 커버한다고 생각합니다. 하지만 여러분의 피드백과 새로운 사용 사례에 따라 쓰기 및 읽기 대기 시간이 짧은 아키텍처에서 작업할 수 있습니다.
- Kafka 지원:앞으로 몇 주 안에 Redis와 함께 Kafka를 출시할 예정입니다. Kafka는 클릭스트림 분석 또는 서버리스/에지 기능에서 kafka로 로그 푸시와 같은 에지에서 새로운 사용 사례를 지원합니다.
우리는 귀하의 피드백에 따라 Upstash를 계속 개선하고 개발합니다. Twitter나 Discord에서 여러분의 생각을 알려주세요.