📦 Dropbox 시스템 설계

원격 저장소에 파일을 업로드/다운로드하고 여러 기기 간 자동 동기화하는 클라우드 스토리지 서비스

---

📋 기능 요구사항

파일 업로드

• 사용자가 파일을 원격 저장소에 업로드

파일 다운로드

• 사용자가 원격 저장소에서 파일 다운로드

파일 공유

• 사용자가 다른 사용자와 파일 공유 및 접근 가능

자동 동기화

• 여러 기기 간 파일 자동 동기화

---

📊 시스템 규모

• 일일 활성 사용자: 1억 명 (100M DAU)
• 최대 파일 크기: 50GB

---

📋 비기능 요구사항

TPS (Transactions Per Second)

가정

• 1억 명의 유저 (10^8)
• 하루에 10번 앱 접속
• Download:Upload 비율 = 3:1 ~ 5:1
• 하루 ≈ 10^5 초

계산

총 request = 10^8 × 10 = 10^9 request/일

다운로드 TPS = (10^9 × 0.75~0.8) / 10^5 = 7,500~8,000 TPS
업로드 TPS = (10^9 × 0.25~0.2) / 10^5 = 2,000~2,500 TPS

---

🎯 시스템 설계 목표

Scalability & CAP

분산 처리

• 수평적 확장(Horizontal Scaling) 필요
• 다중 서버 구성으로 트래픽 분산

CAP 정리

• AP 우선 (Availability + Partition Tolerance)
• Eventual Consistency 허용
• 파일 동기화는 즉시 반영되지 않아도 됨
• 고가용성을 통한 서비스 안정성 확보

---

응답 시간 & 사용자 경험

다운로드/업로드 시간

• 파일 크기에 따라 가변적
• 진행 상태 표시로 사용자 대기 인내심 향상
• 예상 완료 시간 제공

네트워크 장애 처리

• 대용량 파일 전송 중 네트워크 파티션 발생 가능
• 재시작 방지: 중단된 지점부터 재개(Resume) 기능 필수
• 청크(Chunk) 단위 전송으로 안정성 확보

파일 동기화

• 여러 기기 간 합리적인 시간 내 동기화 완료
• 실시간 동기화보다 최종 일관성 보장

---

🔑 핵심 요구사항 정리

항목	값
다운로드 TPS	7,500~8,000 TPS
업로드 TPS	2,000~2,500 TPS
최대 파일 크기	50GB
CAP 우선순위	AP (Availability)
일관성 모델	Eventual Consistency

핵심 기술적 과제

• 대용량 파일 전송 안정성
• 네트워크 장애 복구 (Resume 기능)
• 다중 기기 동기화
• 고가용성 보장

---

🗄️ 도메인 모델

📈 가정

• 외부 시스템 (S3, Azure Storage, ..)
• 외부 시스템에 실제 파일을 저장
• 외부 시스템에서 block 단위의 감지, 다운로드, 업로드 기능 제공

1. FileMetadata

Table: file_metadata

Column	Type	Description	Constraints
id	BIGINT	Primary key	NOT NULL, PRIMARY KEY
file_name	TEXT	파일 이름	NOT NULL
file_type	VARCHAR	파일 타입 (확장자)	NOT NULL
file_key	TEXT	외부 스토리지 경로/키	NOT NULL, UNIQUE
file_size	BIGINT	파일 크기 (bytes)	NOT NULL
user_id	BIGINT	소유자 ID	NOT NULL, FOREIGN KEY
created_at	TIMESTAMP	생성 시간	NOT NULL
updated_at	TIMESTAMP	최종 수정 시간	NOT NULL

2. Chunk

Table: chunks

Column	Type	Description	Constraints
id	BIGINT	Primary key	NOT NULL, PRIMARY KEY
file_id	BIGINT	파일 ID	NOT NULL
hash_value	TEXT	파일 hash 값	NOT NULL
created_at	TIMESTAMP	생성 시간	NOT NULL
updated_at	TIMESTAMP	최종 수정 시간	NOT NULL

3. User

Table: users

Column	Type	Description	Constraints
id	BIGINT	Primary key	NOT NULL, PRIMARY KEY
name	VARCHAR(255)	사용자 이름	NOT NULL
email	VARCHAR(255)	이메일	NOT NULL, UNIQUE
hashed_password	VARCHAR(255)	암호화된 비밀번호	NOT NULL
created_at	TIMESTAMP	계정 생성 시간	NOT NULL
updated_at	TIMESTAMP	최종 수정 시간	NOT NULL

등등 필요에 따라 더 여러개의 도메인이 사용될 수 있으며, RDBMS가 아니라 MongoDB 등의 NoSQL 사용도 가능

---

🔌 API 설계

1. 파일 다운로드

GET /api/v1/files/{fileId}

Response

200 OK

{
  "presigned_url": "https://s3.amazonaws.com/bucket/file.pdf?X-Amz-Signature=...",
  "file_name": "presentation.pdf",
  "file_size": 5242880,
  "expires_in": 3600
}

설명

• Presigned URL을 통해 S3에서 직접 다운로드
• 서버 부하 없이 클라이언트가 S3와 직접 통신

---

2. 파일 업로드

POST /api/v1/files

Request

{
  "file_name": "presentation.pdf",
  "file_type": "pdf",
  "file_size": 5242880
}

Response

201 Created

{
  "file_id": 1000001,
  "presigned_url": "https://s3.amazonaws.com/bucket/upload?X-Amz-Signature=...",
  "expires_in": 3600
}

설명

• 메타데이터만 서버에 저장
• Presigned URL로 클라이언트가 S3에 직접 업로드
• 업로드 완료 후 webhook으로 서버에 알림

---

3. 파일 공유

Endpoint

POST /api/files/{fileId}/share

Request

{
  "user_ids": [1, 32, 22],
  "permission": "read"  // "read" or "write"
}

Response

201 Created
{
  "file_id": 1000001,
  "shared_with": [
    {
      "user_id": 1,
      "email": "user1@example.com",
      "permission": "read",
      "shared_at": "2025-01-09T15:30:00Z"
    },
    {
      "user_id": 32,
      "email": "user32@example.com",
      "permission": "read",
      "shared_at": "2025-01-09T15:30:00Z"
    },
    {
      "user_id": 22,
      "email": "user22@example.com",
      "permission": "read",
      "shared_at": "2025-01-09T15:30:00Z"
    }
  ],
  "share_url": "https://app.dropbox.com/s/abc123/presentation.pdf"
}

설명

• N:N의 관계를 가지는 새로운 table shared_files 도입가능
• 파일 공유 기록을 저장

---

4. 파일 동기화 (SSE)

Endpoint

GET /api/v1/sync/connect/{userId}

Response

200 OK
Content-Type: text/event-stream

data: {"event": "file_updated", "file_id": 1000001, "updated_at": "2025-01-09T14:20:00Z"}

data: {"event": "file_deleted", "file_id": 1000002}

data: {"event": "file_created", "file_id": 1000003, "file_name": "new_document.pdf"}

설명

• Server-Sent Events로 실시간 동기화
• 서버에서 클라이언트로 변경 사항 푸시
• 연결 유지로 즉각적인 동기화 알림

---

요약

Method	Endpoint	Description	인증 필요
GET	/api/v1/files/{fileId}	파일 다운로드 URL 생성	✅
POST	/api/v1/files	파일 업로드 URL 생성	✅
GET	/api/v1/sync/connect/{userId}	실시간 동기화 연결	✅

---

⚙️ 시스템 구조

시스템 아키텍처 개요

외부 객체 스토리지 활용

• S3, Azure Storage 등 검증된 분산 시스템 활용
• 실제 파일 저장 및 전송은 외부 서비스가 담당
• 우리 시스템은 파일 메타데이터만 관리

청크 기반 처리

• 외부 서비스의 청크 단위 기능 활용
• 청크 변경 감지, 업로드, 다운로드 기능 제공
• 효율적인 증분 동기화 가능

등을 고려하고 또 이미 잘 설계 된 CDN, S3 같은 서비스들을 알맞게 사용하면 대부분의 요구되었던 TPS 처리를 아래와 같이 Third Party Service 에 위임할 수 있습니다:

그리고 추가로 로컬환경에서의 변화를 감지하여 클라우드환경 반영하거나 반대로 클라우드환경에서의 변화를 로컬에 반영하여야 한다면 몇가지 컴포넌트들이 더 추가 될 수 있습니다:

---

🌤️ 대용량 파일 시스템 핵심 포인트

📦 파일 청킹 (Chunking)

대용량 파일 업로드의 재개와 효율적인 변경 감지로 발생한 업로드, 다운로드를 위해서는 chunk를 활용하는게 핵심

프로세스

50GB 파일
  ↓
클라이언트에서 5-10MB 청크로 분할
  ↓
각 청크마다 SHA-256 지문 생성
  ↓
전체 파일 지문 생성 (fileId)
  ↓
병렬 업로드 시작

왜 클라이언트에서?

❌ 서버 청킹: 전체 파일을 일단 서버로 전송 (의미 없음)
✅ 클라이언트 청킹: 작은 조각으로 나눠서 전송 시작

장점

✅ 진행률 표시 가능 (3/10 청크 완료)
✅ 네트워크 끊김 시 이어받기
✅ API Gateway 10MB 제한 우회
✅ 병렬 업로드로 속도 향상
✅ 파일 변경 시 변경된 청크만 재업로드 (델타 동기화)

---

✅ 업로드 검증 (Trust but Verify)

업로드 플로우

1. 클라이언트: 파일 지문 계산
   ↓
2. GET /files/{fileId} → 이미 업로드 중인지 확인
   ↓ (없으면)
3. POST /files → S3 Multipart Upload 시작
   ↓
4. 각 청크 업로드 to S3 Presigned URL
   ↓
5. PATCH /files/{fileId}/chunks → ETag + 상태 업데이트
   ↓
6. 서버에서도 S3 ListParts API와 ETag로 상호검증
   ↓
7. 모든 청크 완료 → CompleteMultipartUpload

검증 전략

클라이언트 측
├─ 청크 업로드 즉시 PATCH 요청
├─ 빠른 UI 업데이트 (진행률 표시)
└─ 사용자 경험 향상

서버 측
├─ 청크 업로드 확인 요청시 S3 ListParts API 호출
├─ ETag 비교로 실제 상태 확인
└─ 데이터 무결성 보장

FileMetadata 스키마

{
  "fileId": "sha256-hash",
  "name": "video.mp4",
  "size": 50000000000,
  "uploadedBy": "user123",
  "status": "uploading",
  "uploadId": "s3-multipart-id",
  "chunks": [
    {"id": "chunk-1", "etag": "abc123", "status": "uploaded"},
    {"id": "chunk-2", "etag": "def456", "status": "uploaded"},
    {"id": "chunk-3", "etag": null, "status": "pending"}
  ]
}

---

🗜️ 압축 전략

의사결정 프로세스

압축 고려
  ↓
압축시간 + 압축후 Network IO
  vs
원본 Network IO
  ↓
빠른 쪽 선택

압축 대상 파일

✅ 텍스트 (.txt, .log, .json): 5GB → 1GB (80% 감소)
✅ CSV, XML: 압축률 높음
✅ 코드 파일 (.js, .py, .java)
✅ JSON/XML API 응답

압축 제외 파일

❌ 이미지 (.jpg, .png): 이미 압축됨
❌ 비디오 (.mp4, .mov): 효과 거의 없음
❌ 압축 파일 (.zip, .gz): 이미 압축됨
❌ 암호화된 파일: 압축 효과 없음

보안 고려사항

올바른 순서
압축 → 암호화 ✅
(압축률 최대화)

잘못된 순서
암호화 → 압축 ❌
(랜덤 데이터는 압축 불가)

---

🔄 실시간 동기화

Hot File 전략

자주 사용되는 파일 (상위 20%)
  ↓
WebSocket 실시간 연결 유지
  ↓
변경 즉시 푸시
  ↓
협업 경험 향상

Cold File 전략

가끔 사용되는 파일 (나머지 80%)
  ↓
Polling (30초마다 확인)
  ↓
리소스 절약
  ↓
비용 최적화

판단 기준

파일 접근 패턴
├─ 최근 7일간 접근 횟수
├─ 마지막 접근 시간
└─ 접근 빈도 (일 단위)

협업 지표
├─ 동시 편집자 수
├─ 공유 범위 (개인/팀/전사)
└─ 댓글/수정 활동

파일 특성
├─ 파일 타입 (문서 > 미디어 > 아카이브)
├─ 파일 크기 (작은 파일 우선)
└─ 편집 가능 여부
등등

Hot/Cold 전환 로직

Hot → Cold 전환
├─ 7일간 접근 없음
├─ 협업자 모두 오프라인
└─ 읽기 전용 모드

Cold → Hot 전환
├─ 편집 시작
├─ 새 협업자 참여
└─ 3회 이상 연속 접근

리소스 최적화

Hot Files (20%)
├─ WebSocket: 10,000 동시 연결
├─ 메모리: 파일 메타데이터 캐싱
└─ 비용: 높음

Cold Files (80%)
├─ HTTP Polling: 필요시에만
├─ 메모리: 디스크 기반 조회
└─ 비용: 낮음
등 고려 가능

---

📚 참조

Hello Interview