part는 staging에만 두고 complete 검증 뒤에만 visible version을 만듭니다.
S3형 객체 저장소 설계
업로드된 조각의 존재와 완성된 객체의 공개는 다른 상태입니다. manifest 검증과 metadata CAS가 끝난 version만 보이게 하고 데이터 내구성과 게시 경계를 분리합니다.
개념 이해요구사항장애 대응진도 저장
30초 핵심 요약
multipart part는 staging에만 두고 순서·길이·checksum·정책을 통과한 불변 manifest만 metadata CAS로 공개합니다. complete 응답을 잃어도 같은 idempotency key는 기존 version을 반환합니다.
설계 가정 · 논리 저장500PB
cold EC 예시12 data + 4 parity
핵심 publish 단위manifest + version head
01 · REQUIREMENTS
# 요구사항바이트와 namespace를 함께 신뢰하게 한다
객체의 data plane은 높은 처리량·내구성을, metadata plane은 version·권한·삭제의 명확한 상태 전이를 책임집니다.
video·backup은 필요한 segment만 range GET으로 읽고 checksum을 유지합니다.
version, delete marker, restore, physical GC의 의미를 분리합니다.
signed URL은 object·method·만료가 제한된 bearer credential입니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처metadata publish와 durable data plane을 나눈다
upload가 성공했다는 것은 data shards가 존재한다는 뜻만이 아니라, 검증된 manifest가 현재 object version으로 publish되었다는 뜻이어야 합니다.
multipart ingest → placement → version publish → repair / lifecycle SVG DIAGRAM · 정책·수치는 설계 예시
정합성 경계: disk 또는 shard write의 ACK는 object publish가 아닙니다. client가 읽을 수 있는 version은 root checksum·part 순서·조건부 head mutation까지 끝난 metadata 결과이며, 실패한 staging 바이트는 TTL sweep 대상입니다.
multipart 조각을 언제 하나의 보이는 객체로 확정할 것인가?
예시 논리 저장량
500PB
설계 가정
예시 신규 유입
3PB/일
설계 가정
예시 피크 PUT
약 34,722/s
계산 결과
staging parts + verified immutable manifest + conditional head publish
part는 staging에 저장하고 전체 순서·길이·checksum·정책을 검증한 manifest만 metadata CAS로 공개합니다. complete 응답 유실은 같은 idempotency key로 기존 version을 조회합니다.
선택 이유
- 부분 업로드가 사용자 namespace에 노출되지 않습니다.
- complete 재시도가 중복 object version을 만들지 않습니다.
- 대용량 data path와 작은 metadata mutation을 독립 확장할 수 있습니다.
각 part 업로드 성공을 곧바로 같은 key의 현재 객체에 반영
누락·중복 part가 섞인 부분 객체를 GET이 볼 수 있고 complete 재시도와 rollback의 원자 경계가 사라집니다.
감수한 단점
- staging orphan scan과 manifest reference GC가 필요합니다.
- metadata publish와 data repair를 함께 대사해야 합니다.
- EC repair fan-in과 failure-domain capacity를 운영해야 합니다.
03 · REQUEST FLOW
# 요청 흐름재개 가능한 parts를 검증한 뒤 version을 전진한다
quota·policy를 확인하고 upload ID와 part size를 발급합니다.
각 range와 per-part hash를 검증하고 받은 part inventory를 저장합니다.
root checksum·part sequence·조건부 key version을 확인합니다.
immutable manifest와 version head를 확정하고 audit/outbox를 남깁니다.
04 · TRADEOFFS
# 트레이드오프replication과 EC는 복구 경로까지 비교한다
3-way replication은 빠르게 수리하지만 공간을 쓰고, EC는 효율적이지만 reconstruction fan-in이 큽니다. 객체 온도·크기·복구 시간에 따라 두 방식을 나눕니다.
선택
강점
제약
설계 판단
3-way replication
낮은 p99
raw overhead 큼
hot·small object, 간단한 repair
12+4 erasure coding
저장 효율
reconstruction fan-in·CPU
cold·large object, 충분한 zone/rack
versioning + marker
restore
보존·privacy workflow 필요
user data, audit·랜섬웨어 대응
direct signed URL
확장성
bearer URL·revoke 경계
large transfer, short TTL·세밀한 scope
05 · FAILURE MODES
# 장애 시나리오손상, 삭제, 지연을 서로 다른 실패로 복구한다
complete timeout
응답을 잃은 client가 새 upload를 만들어 동일한 bytes를 중복 저장합니다.
대응 · idempotency key·received parts·complete 결과를 조회해 같은 version을 반환합니다.
orphan staging
part는 썼지만 metadata publish가 실패해 invisible bytes와 비용이 쌓입니다.
대응 · publish marker, abort TTL, manifest 없는 segment sweep을 대사합니다.
shard loss
disk·rack·zone 장애가 under-replicated 또는 EC 부족 shard를 만듭니다.
대응 · scrub과 inventory로 감지, 다른 failure domain에 우선 repair합니다.
reconstruction storm
degraded read와 repair가 동시에 몰려 GET p99와 network가 포화됩니다.
대응 · repair priority·rate reservation·hot replica promotion으로 분리합니다.
delete policy race
stale lifecycle worker가 legal hold version을 삭제하거나 GC를 너무 일찍 실행합니다.
대응 · policy-version CAS, tombstone, grace period, restore drill을 둡니다.
signed URL leak
긴 만료의 bearer URL이 복사되어 권한 철회 뒤에도 download될 수 있습니다.
대응 · method/key/version/TTL 최소화와 issuance·use audit, 민감 객체 cache 금지를 적용합니다.
06 · OPERATIONS
# 운영 관점보안·관측·비용을 manifest 경계에 연결한다
bucket policy, tenant, object version과 method를 ticket에 결속하고 key·presigned query를 telemetry에서 redact합니다.
policy_version · signed_url_use
PUT 200보다 scrub coverage, checksum mismatch, under-EC count, repair lag와 placement violation을 분리해 봅니다.
scrub_age · repair_backlog
논리 바이트 외에 physical overhead, versions, abandoned parts, request, retrieval, egress와 repair traffic을 합산합니다.
bytes × overhead × retention
면접 모드 · 추가 질문06:00
“12+4 EC cold tier에서 한 zone의 여러 shard가 느려져 reconstruction queue가 폭증했습니다. GET p99를 지키면서 어떤 객체를 먼저 repair하고, replica promotion·rate limit·capacity 경보를 어떻게 적용하시겠습니까?”
failure domainmanifest publishscrub + repairversion / delete
답변 구조 보기 5단계
- bucket·key·version의 metadata plane과 immutable segment의 data plane을 분리한다.
- multipart part는 staging에 쓰고 전체 checksum·정책 검증 뒤 manifest를 원자 publish한다.
- complete 재시도는 idempotency key로 같은 version을 반환하며 다른 payload는 conflict로 격리한다.
- hot replica와 cold EC는 failure domain·repair bandwidth·용량 여유를 포함해 선택한다.
- delete marker·retention·physical GC와 checksum scrub·repair를 서로 다른 완료 상태로 추적한다. 이번 선택: 불변 data segment와 강한 metadata manifest를 결합해 부분 객체가 namespace에 나타나지 않게 한다. 깨지는 신호: head가 존재하지 않는 segment를 가리키거나 complete 재시도가 새 version을 만든다. 다음 검증: 응답 유실·part 중복·metadata failover·EC repair 폭주를 주입해 publish 원자성과 GET p99를 함께 측정한다.
multipart publish를 설명하고 orphan·repair·GC를 운영하기
part ACK와 visible object publish가 다른 성공이라고 답합니다.
- received-parts·checksum·root manifest 검증을 설명합니다.
- conditional head CAS와 idempotent complete를 말합니다.
- replica·EC·delete marker·retention 경계를 답합니다.
응답 유실과 metadata failover에서도 한 version만 공개되는지 확인합니다.
- head-to-segment 참조와 checksum error를 관측합니다.
- staging orphan이 grace 뒤 안전하게 수거되는지 검사합니다.
- repair queue가 GET p99와 failure-domain 여유를 침범하지 않는지 검증합니다.
이 문제와 이어지는 문서클라우드 파일 동기화
객체 저장 위에 수정·공유·동기화를 올립니다.
REAL PROJECT CASE
실제 구현 해설 보기 →
AI Systems Atlas에서 이 개념 보기
원본 Markdown, 파생 근거, 그래프 snapshot의 보존·버전·무결성 경계를 비교할 수 있습니다.
TECHNICAL DOCUMENTS & CONTACT
기술 규격·공식 문서
- AWS, Amazon S3 User Guide — What is Amazon S3? — bucket, object, key 중심 모델.
- AWS, Amazon S3 User Guide — Multipart upload overview — create/upload parts/complete 또는 abort 절차와 part 비용.
- AWS, Amazon S3 User Guide — Using versioning in S3 buckets — same key의 object version 보존.
- AWS, Amazon S3 User Guide — Sharing objects with presigned URLs — 제한된 시간의 signed access.
- AWS, Amazon S3 User Guide — Managing storage lifecycle — lifecycle transition과 expiration.
- Ceph, Ceph Architecture — RADOS, replication, erasure coding과 CRUSH 기반 배치 개념.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.