timeout 뒤 서버가 받은 range를 확인하고 미수신 byte만 다시 보냅니다.
클라우드 파일
동기화 설계
대용량 바이트는 객체 저장소에서, 이름·폴더·공유 권한은 metadata namespace에서, 기기 간 수렴은 cursor 기반 delta feed에서 다룹니다. 업로드 완료와 동기화·권한·복구를 같은 성공으로 섞지 않는 것이 핵심입니다.
개념 이해요구사항면접 질문장애 대응진도 저장
30초 핵심 요약
파일 sync는 바이트 저장, metadata publish, 변경 전파가 다른 실패 모드를 갖습니다. resumable session으로 chunk 범위를 재개하고, immutable object manifest를 검증한 뒤 base version CAS로 새 revision과 delta event를 commit합니다. notification은 힌트이며, 기기는 cursor 이후 delta를 멱등 적용해 수렴합니다.
바이트 정본Immutable object + manifest
동기화 정본Cursor + delta feed
충돌 기준Base version CAS
01 · REQUIREMENTS
# 요구사항파일 바이트와 사용자 namespace를 함께 다룬다
같은 파일 ID에 콘텐츠 수정, rename, move, 공유 권한 철회가 겹칠 수 있습니다. 경로가 아닌 안정된 file ID를 기준으로 revision·ACL을 묶고, 현재 버전이 사용자에게 보이는 단일 commit 경계를 정의합니다.
기기는 저장 cursor 이후 변경을 가져오며 notification만 믿지 않습니다.
stale base version은 덮어쓰지 않고 merge 또는 conflict copy로 보존합니다.
파일 ID와 URL을 알아도 현재 ACL·policy version을 통과해야 읽습니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처불변 바이트와 가변 metadata를 commit으로 잇는다
object write의 성공은 아직 파일 publish가 아닙니다. staging object를 검증한 뒤 metadata namespace의 current version과 change log를 같은 publish 경계에서 확정하고, downstream projection은 outbox에서 재시도합니다.
업로드 재개부터 다기기 delta sync까지 SVG DIAGRAM · data plane / control plane
정합성 경계: Google Cloud Storage의 object replacement가 원자적이어도, object store·metadata DB·change log 전체가 한 transaction이 되는 것은 아닙니다. 이 설계는 publish marker, transactional outbox, reconciliation으로 그 경계를 명시적으로 관리합니다.
03 · REQUEST FLOW
# 요청 흐름세션 재개, CAS commit, cursor pull을 분리한다
ACL·quota·base version을 확인해 resumable upload ID를 발급합니다.
클라이언트는 chunk hash와 byte range를 보내고, timeout 뒤 수신 범위를 조회합니다.
validator 후 current version·revision·change event를 base-version CAS로 확정합니다.
다른 기기는 notification을 힌트로 cursor 이후 feed를 끝까지 적용합니다.
04 · TRADEOFFS
# 트레이드오프재전송 절감과 운영 복잡도의 교환
선택
강점
제약
판단 기준
파일 단위 resumable
간단
작은 수정도 큰 객체 재전송
초기 제품, binary 중심 workload
fixed-size chunk
예측 가능
중간 삽입 뒤 재사용률 낮음
streaming·range download 우선
content-defined chunk
dedup
CPU·manifest·GC·side-channel 비용
절감량이 운영 비용을 넘는지 계측
conflict copy
원본 보존
사용자 namespace clutter
이진·암호화 파일의 기본값
05 · FAILURE MODES
# 장애 시나리오바이트, cursor, ACL의 실패를 따로 복구한다
upload timeout
모바일 연결이 끊겨 client가 이미 수신된 chunk를 모른 채 재전송합니다.
대응 · session의 received range를 조회하고 final size·root hash로 완료를 검증합니다.
orphan object
staging object는 성공했지만 metadata publish가 실패해 보이지 않는 byte가 남습니다.
대응 · publish marker와 idempotent finalize, TTL sweep으로 object/manifest를 대사합니다.
cursor gap
오래 offline인 기기가 retention 밖 cursor를 써서 rename·delete를 놓칩니다.
대응 · compacted snapshot + waterline 이후 replay, namespace hash 비교를 사용합니다.
동시 편집
오래된 local base 위에 commit하면 다른 사용자의 content가 조용히 사라질 수 있습니다.
대응 · base-version CAS와 three-way merge 또는 conflict copy로 두 revision을 보존합니다.
stale ACL
권한 철회와 cache/token 갱신이 경합하면 잘못된 allow 또는 deny가 생깁니다.
대응 · policy version을 token에 결속하고 짧은 TTL·revoke audit로 검증합니다.
GC 오판
늦은 replica의 manifest가 참조하는 chunk를 garbage collector가 삭제할 수 있습니다.
대응 · mark-and-sweep grace와 two-phase delete, restore drill을 둡니다.
06 · OPERATIONS
# 운영권한·관측·비용을 각 경계에 붙인다
upload·download·delta마다 resource와 policy version을 검사하고, filename·OCR·thumbnail도 민감 데이터로 취급합니다.
policy_cache_age · revoke_latency
API 200뿐 아니라 finalize p99, cursor lag, rescan rate, conflict rate, manifest read miss를 분리해 봅니다.
cursor_lag · finalize_p99
원본·revision·staging·replica·egress·index·GC mark set을 더한 비용을 retention과 함께 계산합니다.
bytes × replicas × retention
면접 모드 · 추가 질문06:00
“오프라인 상태의 두 기기가 같은 5GB 파일을 수정했습니다. 전송을 처음부터 다시 하지 않게 하면서도, 한 사용자의 바이트와 공유 권한 변경이 조용히 사라지지 않게 하려면 어떤 데이터 모델·commit 경계·cursor 복구 정책을 제시하시겠습니까?”
immutable manifestbase-version CAScursor + snapshotconflict copy
NEXT CASE STUDY분산 메시지 큐 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- Google Drive API — Retrieve changes: start page token, pagination, `newStartPageToken`, change notification이 상세를 담지 않는다는 계약.
- Google Drive API — Upload file data: `uploadType=resumable`, session URI, range upload, 308 응답과 중단 업로드 재개 절차.
- Google Drive API — files resource: files resource의 `version`, binary content `md5Checksum` 등 metadata 필드.
- Google Drive API — revisions resource: revision ID, `keepForever`, binary revision retention 동작.
- Google Cloud Storage — Objects: object name/generation, 객체 불변성 및 원자적 교체의 범위.
- Dropbox Developer — Content Hash: 4MB block SHA-256 기반 content hash 알고리즘의 참고 사례.
- 위 출처의 계약은 해당 제품에 한정된다. DAU, 파일 크기, chunk 정책, storage layout, multi-store commit, conflict policy, SLO 및 비용은 이 학습 문서의 **설계 가정 또는 선택**이다.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.