Amazon S3에 객체가 저장되기까지

PUT 하나가 프런트엔드 플릿 → 소거 부호화 → 3개 가용 영역의 ShardStore → 키맵 인덱스를 지나 '11 나인' 내구성을 얻는 전 과정을, AZ 장애와 복구까지 21단계로 따라간다.

1 / 21클라이언트가 객체 키와 데이터로 PUT 요청을 준비하고, 요청 전체를 SigV4로 서명합니다.서명에는 요청 시각·리전·페이로드 해시가 들어가므로 가로채서 변조하면 서명이 깨집니다.

단계 목록 · 키보드 ←/→ 이동, Space 재생

출처: Building and operating a pretty big storage system called S3 (Andy Warfield, 2023) · Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3 (SOSP 2021) · Amazon S3 Strong Consistency 공식 문서

S3의 내구성은 좋은 디스크가 아니라 구조에서 나온다 — 소거 부호화 × 가용 영역 분산 × 상시 체크섬 감사 × 플릿 단위 복구.

왜 헷갈리는가

'S3는 그냥 큰 하드디스크'라는 심상이 흔하지만, 실제로는 요청 경로(프런트엔드 플릿), 메타데이터(키맵 인덱스), 데이터(ShardStore)가 분리된 분산 시스템이다. 또 2020년 12월 이후 강한 읽기 일관성이 보장되는데도 '최종적 일관성이라 방금 쓴 게 안 보일 수 있다'는 옛 지식이 아직 널리 돈다.

애니메이션이 보여주는 것

객체 하나가 저장될 때 실제로 지나는 컴포넌트를 공개 자료에 나온 이름 그대로 배치했다. 프런트엔드 웹 서버 플릿이 SigV4 서명과 권한을 검사하고, 스토리지 프런트가 객체를 데이터 조각 k개와 패리티 조각 m개로 부호화해 세 가용 영역의 ShardStore 노드에 뿌린다. 충분한 조각이 fsync까지 끝나야 200 OK가 나간다.

후반부는 사람들이 가장 궁금해하는 두 시나리오다 — 가용 영역 하나가 통째로 죽으면 어떻게 되는가(남은 조각 k개로 즉시 복원, 가용성 무손실), 그리고 그 뒤 시스템이 어떻게 스스로 원래 내구성 여유로 돌아가는가(복구 플릿의 재부호화·재배치).

소거 부호화가 복제를 이긴 이유

3벌 복제는 저장 비용이 3배지만 1개 노드 손실까지만 여유가 있다. k+m 소거 부호화는 저장 비용 (k+m)/k배로 m개 손실까지 버틴다. 예컨대 5+3이면 비용 1.6배로 3중 손실을 견딘다 — 같은 돈으로 더 높은 내구성이다.

대가는 계산이다. 쓰기마다 부호화, 조각 손실 시 복호화가 필요하다. S3 규모에서는 이 CPU 비용이 저장 비용 절감보다 훨씬 싸다.

복제 3벌: 비용 3.0배, 2개 손실까지
부호화 5+3: 비용 1.6배, 3개 손실까지
읽기는 아무 조각이나 k개면 된다 — 꼬리 지연 흡수에도 쓰인다

내구성 수학이 성립하는 조건

'11 나인'은 확률 계산이고, 그 계산에는 숨은 전제가 있다 — 조각이 하나 죽었을 때 다음 조각이 죽기 전에 복구가 끝난다는 것. 그래서 복구 속도가 내구성의 실질 변수다. S3가 복구를 플릿 단위로 병렬화하고, 평시에도 체크섬 감사를 도는 이유가 이것이다.

디스크는 죽었다고 말해주지 않는 경우가 있다(조용한 손상, bit rot). 감사 프로세스가 능동적으로 읽어 체크섬을 대조해야 이 손상이 발견된다.

기억할 것

S3 = 프런트엔드 플릿(요청) + 키맵 인덱스(메타데이터) + ShardStore(데이터)의 분리 구조.
내구성은 소거 부호화 × AZ 분산 × 상시 감사 × 빠른 복구의 곱이다.
2020-12 이후 강한 읽기 일관성 — 쓰기 성공 후 읽기는 항상 최신을 본다.
ack은 fsync 이후에만 — '받았다'와 '남겼다'는 다르다.
복구 속도가 느리면 내구성 수학 자체가 무너진다.