분산 SQLite의 12년

2014년 rqlite는 SQLite 앞에 Raft 로그를 두고 모든 쓰기를 클러스터에 복제하는 방식으로 출발했으며, 이제 분산 SQLite는 약 12개 프로젝트가 속한 분야로 성장함 설계는 합의, 스트리밍, 병합이라는 세 갈래로 발전함. 각각 강한 일관성의 클러스터, 단일 노드의 저비용 복구, 여러 쓰기 주체의 최종 일관성이라는 서로 다른 요구를 해결함 rqlite는 CP 시스템으로, 리더와 과반수의 승인을 거쳐 쓰기를 처리하고 네트워크 분할로 고립된 소수 노드의 쓰기를 거부함. 장애 후 복원을 기다릴 수 없는 경우를 겨냥함 Litestream은 합의 없이 SQLite WAL을 S3로 스트리밍해 단일 노드의 재해 복구를 지원하며, 많은 애플리케이션에는 클러스터보다 한 대의 머신과 복구 수단이면 충분하다는 접근을 확산시킴 분산 SQLite는 직접 실행하는 소프트웨어에서 관리형 서비스로도 확장됨. 투자와 인수는 복제 SQLite를 유료 서비스로 만든 플랫폼에 집중됐고, rqlite, dqlite, Litestream은 무료 오픈소스로 남아 있음 2014년: rqlite의 출발과 일관성 모델 2014년 9월 rqlite의 첫 공개 글과 같은 주말에 소스 코드가 공개됨 SQLite 앞에 Raft 로그를 두고 모든 쓰기를 클러스터에 복제해, 노드 하나를 잃어도 데이터가 사라지지 않도록 설계함 개발자가 아는 범위에서는 Raft와 SQLite를 결합한 최초의 오픈소스 시스템이었음 출발점은 jut.io의 클러스터 시스템에 필요한 소규모 관계형 저장소였음 어느 노드에 데이터를 둘지 마땅한 답이 없었고, 합의 프로토콜로 SQLite를 복제하면 해결할 수 있었음 회사에서는 다른 방식을 택했지만, 범용적인 문제를 작은 해법으로 해결할 수 있어 rqlite 개발을 이어감 초기에는 당시 InfluxDB와 etcd도 사용하던 goraft를 사용함 2016년 초 Hashicorp의 Raft 구현으로 교체했고, 현재도 이를 사용함 가장 중요한 설계 결정인 CP 시스템 이라는 성격은 바뀌지 않음 쓰기는 리더를 거쳐 과반수의 승인을 받아야 하며, 네트워크 분할로 고립된 소수 노드는 쓰기를 거부함 HTTP API, 읽기 일관성 수준, 스냅샷도 이 결정에 따라 설계됨 선행 사례와 동시대의 시도 Expensify는 수년 전부터 내부 인프라에서 Paxos) 계열 프로토콜로 SQLite를 복제했으며, 이를 2016년 Bedrock으로 공개함 Actor...