일회성 샌드박스를 위한 버전 관리 파일시스템

Tines의 3B는 실행 후 폐기하는 Linux 샌드박스에 영속 파일시스템을 연결. Git 저장소와 SQLite, DuckDB 등을 다음 실행에서도 이어 쓰면서, 성공한 실행의 변경만 일괄 반영 실행마다 고정된 스냅샷을 읽고, 실패하면 파일 변경을 폐기. 다른 실행이나 UI에는 반쯤 작성된 파일이 보이지 않도록 구성 수 GB의 데이터도 복사 없이 분기해 운영 데이터에 영향을 주지 않고 실험 가능. 같은 스냅샷을 가리키는 포인터만 추가하고, 이후 변경된 부분만 따로 저장 여러 실행이 동시에 작업해도 서로 다른 파일의 변경은 재적용하고, 같은 파일의 변경은 충돌 오류로 처리. 조용히 다른 실행의 결과를 덮어쓰는 일을 방지 gVisor 기반 로컬 입출력과 자체 Rust 스토리지 엔진을 결합. 로컬 디스크를 우선하고 S3는 복구와 오래된 데이터 보관에 활용해 지연 시간과 비용, 자체 호스팅 요구를 함께 맞춘 설계 실행은 폐기하고 데이터는 남기는 구조 Tines의 3B는 워크플로의 각 단계를 하나의 컴퓨터로 취급함 사람이나 에이전트가 작성한 코드를 새로운 Linux 샌드박스에서 실행하고, 프록시를 통해 자격 증명을 전달함 작업 후 샌드박스를 폐기해 남은 상태가 이후 보안 문제를 일으키지 않도록 함 고객은 이미 영속 상태가 필요한 작업을 수행하고 있음 저장소를 복제해 분석하고, Salesforce 리드를 SQLite 데이터베이스로 보관함 수신 웹훅을 DuckDB에 저장해 다른 워크플로에서 검색함 파일시스템은 샌드박스보다 오래 유지되며, 실행과 파일 변경을 전부 반영하거나 전부 버리는 단위로 묶음 에이전트와 초안 분기에서 작업해도 운영 분기의 데이터에는 영향을 주지 않음 다른 실행은 해당 단계가 성공적으로 끝나기 전까지 변경 사항을 볼 수 없음 구성은 샌드박스, Nest, Spongeblob의 세 계층으로 나뉨 샌드박스가 코드를 실행하고, 바로 바깥의 작은 gVisor gofer 확장인 Nest가 파일 작업을 처리함 Spongeblob은 Blobstore라고도 부르는 자체 스토리지 엔진으로, 모든 볼륨을 저장하고 S3가 있으면 복구와 로컬 데이터 축출을 위해 복사함 설계를 결정한 요구사항과 볼륨 인터페이스 실제 POSIX 파일시스템처럼 동작해야 함 Git, SQLite, 컴파일러, pip는 디렉터리와 mmap, fsync, 이름 변경에 의존하며 별도 SDK를 채택하지 않음 영속 상태를 단계를 실행하는 머신에 묶을 수 없음 ...