▲

GN⁺: 모든 Durable Object에서 제로 레이턴시 SQLite 저장소

 (simonwillison.net)
2P by neo 1달전 | favorite | 댓글 1개

  • Zero-latency SQLite storage in every Durable Object

    • Kenton Varda는 Cloudflare의 Durable Object 플랫폼의 다음 버전을 소개함. 이 플랫폼은 최근 키/값 저장소에서 SQLite 기반의 완전한 관계형 시스템으로 업그레이드됨
    • Durable Objects의 첫 번째 버전에 대한 유용한 배경 정보는 Paul Butler의 Cloudflare의 durable multiplayer moat를 참조할 수 있음. 이는 WebSocket 기반의 실시간 협업 애플리케이션을 구축하는 데 인기가 있음
    • 새로운 SQLite 기반 Durable Objects는 대규모 애플리케이션을 설계하는 흥미로운 방법을 제안하는 분산 시스템 설계의 매력적인 요소임

  • Durable Objects의 핵심 아이디어

    • Durable Object는 데이터와 함께 애플리케이션 로직을 동일한 물리적 호스트에 배치하여 매우 빠른 읽기 및 쓰기 성능을 제공함
    • 단일 객체는 단일 머신의 단일 스레드에서 실행되므로 처리량이 제한적임. 더 많은 트래픽을 처리하기 위해 더 많은 객체를 생성함. 각 상태 단위가 단일 객체로 처리할 수 있을 만큼 낮은 트래픽을 갖는 경우에 가장 쉬움

  • 항공편 예약 시스템 예시

    • 각 항공편은 자체 SQLite 데이터베이스를 가진 전용 Durable Object에 매핑될 수 있음. 항공사당 매일 수천 개의 새로운 데이터베이스가 생성됨
    • 각 DO는 고유한 이름을 가지며, Cloudflare의 네트워크는 해당 객체가 전 세계 어디에 있든 요청을 라우팅함

  • 기술적 세부사항

    • Litestream에서 영감을 받아 각 DO는 객체 저장소로 WAL 항목의 시퀀스를 지속적으로 스트리밍함. 이는 16MB마다 또는 10초마다 배치됨
    • 10초 창 내에서 내구성을 보장하기 위해, 쓰기는 커밋되자마자 인근 데이터 센터의 다섯 개 복제본으로 전달되며, 세 개가 확인되면 쓰기가 인정됨

  • JavaScript API 디자인

    • 비동기식이 아닌 차단 방식으로 설계됨. 이는 빠른 단일 스레드 지속성 작업을 제공하기 위한 것임
    • SQLite가 잘 처리할 수 있는 N+1 쿼리 패턴을 의도적으로 보여주는 예시를 포함함

  • Storage Relay Service

    • Durable Objects의 기반 시스템이며, Cloudflare의 기존 D1 SQLite 시스템을 1년 이상 지원해옴

  • Durable Objects의 생성 위치

    • Durable Objects는 생성된 후 위치를 변경하지 않음. 기본적으로 초기 get() 요청이 이루어진 데이터 센터에서 인스턴스화됨
    • 다른 위치에서 Durable Objects를 수동으로 생성하려면 get()에 선택적 locationHint 매개변수를 제공함

  • where.durableobjects.live 사이트

    • Cloudflare 네트워크에서 DO가 생성되는 위치를 추적하는 사이트임

GN⁺의 정리

  • Cloudflare의 Durable Objects는 SQLite를 기반으로 하여 대규모 애플리케이션 설계에 새로운 가능성을 제시함. 이는 데이터와 애플리케이션 로직을 동일한 물리적 호스트에 배치하여 빠른 성능을 제공함
  • 이 시스템은 특히 실시간 협업 애플리케이션에 유용하며, 다양한 상태 단위를 처리할 수 있는 유연성을 제공함
  • Durable Objects는 데이터 내구성을 보장하기 위해 여러 데이터 센터에 복제본을 생성하며, 이는 안정성과 신뢰성을 높임
  • 이 기술은 대규모 분산 시스템 설계에 관심 있는 개발자에게 흥미로울 수 있음. 비슷한 기능을 제공하는 시스템으로는 Amazon의 DynamoDB와 Google의 Firestore가 있음
▲
neo 1달전  [-]
Hacker News 의견

  • 쓰기 API는 동기식이지만 숨겨진 비동기 대기 기능이 있음. 쓰기가 실패하면 런타임이 응답을 HTTP 실패로 대체하여 자동으로 쓰기를 일괄 처리하고 성공을 가정할 수 있게 함

    • 읽기 트랜잭션이 없어 특정 시점의 스냅샷을 얻기 어려움
    • 각 런타임 인스턴스는 128MB RAM으로 제한됨
    • Websockets는 하이버네이트할 수 있으며, 이때 비용이 발생하지 않음. 이는 클라이언트가 DO가 잠들어 있을 때도 연결을 유지할 수 있게 함
    • 자동 RPC 기능이 있어 다른 DO나 워커와 일반 JS 호출처럼 통신할 수 있음. 런타임이 직렬화 및 구문 분석을 처리함

  • 각 DO는 WAL 항목의 시퀀스를 객체 저장소로 스트리밍하며, 이는 16MB마다 또는 10초마다 일괄 처리됨

    • 전 세계적으로 쓰기를 읽기까지 10초가 걸릴 수 있음
    • 지역적으로 배치된 데이터베이스 클러스터를 대체하기 어려움

  • Durable Object 디자인을 좋아함. 내부 작동 방식을 이해하기 쉬움

    • DO는 빠르고 저비용의 실시간 경험을 구축하는 데 좋지만, 분석 및 개요 작성이 어려움
    • SQLite에 데이터를 넣으면 여러 작은 SQLite 인스턴스를 쿼리하고 결과를 병합해야 함

  • Durable Objects의 물리적 위치가 어디인지 이해하기 어려움

    • API 호출이 발생한 지역에 위치하는지 궁금함
    • DO가 자동으로 다른 위치로 이동할 수 있는지 궁금함

  • 새로운 클라우드 기술을 이해하기 어려움

    • 15년 이상의 웹 개발 경험이 있지만, 이러한 기술이 자신에게 맞지 않다고 느낌

  • 스키마 마이그레이션을 어떻게 처리할지 궁금함

    • 데이터베이스가 테넌트별로 존재하는 경우, 스키마 변경을 각 DO에 적용하는 것이 어려움

  • DO 디자인이 흥미롭지만, 고부하 시스템이나 장난감 프로젝트에만 적합하다고 생각함

    • 실무에서는 검증된 시스템이 필요하며, DO는 아직 성숙하지 않음

  • DO 디자인에 감명받음. 복잡한 작업을 낮은 규모로 처리하는 방식이 실제 제품 구조와 유사하다고 생각함

  • CF가 개발자들에게 DO 사용을 권장하는 것을 주목함

    • 워커의 웹소켓 연결이 30초 후에 타임아웃되며, DO 사용이 권장됨

  • DO가 MVC 아키텍처의 "모델"에 해당하는지 궁금함

    • DO를 테넌트별로 사용하고, 모든 DO를 쿼리하거나 조인하는 방법에 대해 궁금함
답변달기