[Review] 시스템 디자인 스터디 후기 - S3와 유사한 객체 저장소

1. 저장소 시스템의 종류

스터디에서는 세 종류를 구분하면서, 분산 환경이 일반화되며 객체 저장소가 사실상 기본값처럼 자리잡게 된 이유를 이야기했다. 블록 저장소는 단일 서버에 강하게 묶이는 반면, 객체 저장소는 어디서든 글로벌 접근이 가능하다는 점이 분산 환경에서의 선택을 자연스럽게 만든다는 의견이 나왔다.

2. 용어 정리

스터디에서는 이와 관련해 버킷 이름 하이재킹이나 버킷 스쿼팅(Bucket Squatting) 같은 보안 이슈가 언급되었다. 계정이 삭제된 이후 해당 버킷 이름을 다른 사람이 선점하는 방식의 공격 사례가 실제로 보고된 바 있다고 한다. 

3. 규모 추정

- 20%: 1MB 미만 소형 객체
- 60%: 1MB ~ 64MB 중형 객체
- 20%: 64MB 이상 대형 객체

4. 개략적 설계안

 
개략적 설계는 크게 로드 밸런서, API 서비스, IAM 서비스, 데이터 저장소, 메타데이터 저장소로 구성된다.

1. 로드 밸런서: RESTful API 요청을 API 서버들에 분산한다.
2. API 서비스: IAM 서비스, 메타데이터 서비스, 데이터 저장소에 대한 호출을 조율하는 역할을 한다. 사용자의 요청을 받으면 인증/인가를 확인하고 각 서비스를 호출해 처리한다.
3. IAM 서비스: 인증(Authentication), 권한 부여(Authorization), 접근 제어(Access Control)를 중앙에서 처리한다.
4. 데이터 저장소: 실제 객체 데이터를 보관한다. 내부적으로 데이터 라우팅 서비스, 배치 서비스, 데이터 노드로 구성된다.
5. 메타데이터 저장소: 객체 메타데이터를 보관한다.

5. 객체 업로드 / 다운로드 흐름

객체 업로드 흐름

1. 클라이언트가 버킷 생성 HTTP PUT 요청을 보낸다.
2. API 서비스가 IAM을 호출해 WRITE 권한 여부를 확인한다.
3. 확인 완료 후 메타데이터 저장소에 버킷 정보를 등록한다.
4. 버킷 생성 후 클라이언트가 객체 업로드 HTTP PUT 요청을 보낸다.
5. API 서비스가 신원 및 WRITE 권한을 재확인한다.
6. 문제가 없으면 객체 데이터를 데이터 저장소로 전달한다.
7. 데이터 저장소가 객체를 저장하고 UUID를 반환한다.
8. API 서비스가 메타데이터 저장소에 object_id(UUID), bucket_id, object_name 등을 등록한다.
9. 200 OK 응답을 반환한다.

1. 클라이언트가 GET /bucket-name/object-name 요청을 보낸다.
2. API 서비스가 IAM을 통해 READ 권한을 확인한다.
3. 메타데이터 저장소에서 해당 객체의 UUID를 조회한다.
4. UUID로 데이터 저장소에서 실제 데이터를 가져온다.
5. 객체 데이터를 HTTP 응답으로 반환한다.

6. 데이터 저장소 상세 설계

데이터 저장소는 데이터 라우팅 서비스, 배치 서비스, 데이터 노드로 구성된다.

데이터 라우팅 서비스
데이터 노드 클러스터에 접근하기 위한 RESTful 또는 gRPC 서비스를 제공한다. 무상태 서비스라 서버를 추가해 쉽게 규모를 확장할 수 있다. 배치 서비스를 호출해 데이터를 저장할 최적의 노드를 결정하고, 데이터 노드에서 데이터를 읽어 API 서비스에 반환하는 역할을 한다.

배치 서비스
어느 데이터 노드에 데이터를 저장할지 결정하는 역할을 한다. 내부적으로 가상 클러스터 지도를 유지하며, 클러스터의 물리적 형상 정보를 바탕으로 데이터 사본이 물리적으로 다른 위치에 놓이도록 결정한다. 아주 중요한 서비스이기 때문에 5~7개 노드를 갖는 클러스터를 Paxos나 Raft 같은 합의 프로토콜로 구축하는 것이 권장된다.

데이터 노드
실제 객체 데이터가 보관되는 곳이다. 여러 노드에 데이터를 복제함으로써 안정성과 내구성을 보증하는데, 이를 다중화 그룹이라고 한다. 데이터 노드에는 배치 서비스에 주기적으로 박동 메시지(heartbeat)를 보내는 서비스 데몬이 동작하며, 부착된 드라이브 수, 각 드라이브에 저장된 데이터 양 등의 정보를 함께 전달한다.

데이터 저장 흐름

1. API 서비스가 객체 데이터를 데이터 라우팅 서비스로 전달한다.
2. 데이터 라우팅 서비스가 UUID를 할당하고 배치 서비스에 저장할 데이터 노드를 질의한다.
3. 배치 서비스가 가상 클러스터 지도를 확인해 주 데이터 노드를 반환한다.
4. 데이터 라우팅 서비스가 UUID와 함께 데이터를 주 데이터 노드에 전송한다.
5. 주 데이터 노드가 데이터를 자신에게 저장하고, 두 개의 부 데이터 노드에 다중화한다.
6. 모든 부 노드에 다중화가 완료되면 UUID를 API 서비스에 반환한다.

7. 데이터는 어떻게 저장되는가

스터디에서는 하둡을 사용하는 환경에서 임시 파일이 과도하게 생성되어, 실제 용량은 몇십 KB에 불과한데도 파일 개수 한도에 걸려 담당자에게 긴급 알림이 왔던 경험담이 공유되었다.

스터디에서 4KB라는 블록 크기 기준에 대한 이야기도 나왔다. 리눅스와 윈도우 모두 메모리 페이지 크기가 4KB이기 때문에, 이 단위에 맞춰 블록 크기가 설정된 것으로 보인다는 의견이 나왔다.

- object_id: 객체의 UUID
- file_name: 객체를 보관하는 파일의 이름
- start_offset: 파일 내 객체의 시작 주소
- object_size: 객체의 바이트 단위 크기

8. 데이터 내구성

99.9999% 수준의 내구성을 달성하는 방법으로 책에서는 두 가지를 제시한다.

다중화(Replication)
데이터를 여러 노드에 복제하는 방식이다. 3중 복제 기준 내구성은 약 99.9999%이다. 저장 용량 오버헤드는 200%이다. 한 노드에서 읽으면 되므로 읽기 성능이 좋고 추가 계산이 필요 없다.

소거 코드(Erasure Coding)
데이터를 작은 단위로 분할하고, 일부가 소실되었을 때 복구하기 위한 패리티(parity) 정보를 함께 저장하는 방식이다.

예를 들어 (4+2) 소거 코드라면,
- 데이터를 d1, d2, d3, d4 네 조각으로 분할한다.
- 패리티 p1, p2를 수학 공식으로 계산한다.
- d3, d4가 노드 장애로 소실되어도 d1, d2, p1, p2로 복원할 수 있다.

8+4 소거 코드 기준 내구성은 99.9999999999%(트웰브 나인)까지 올라가며 저장 오버헤드는 50%로 줄어든다. 단, 읽기 시 여러 노드에서 조각을 모아야 하므로 응답 지연이 증가한다.

클라우드 환경에서는 (4+2), (8+4), (12+4) 같은 조합이 주로 사용된다. AWS가 초기에 다중화 방식을 쓰다가 이후 소거 코드로 전환했다는 이야기도 나왔다. 

9. 메타데이터 모델

메타데이터 스키마는 세 가지 질의를 지원해야 한다.

1. 객체 이름으로 객체 ID 찾기
2. 객체 이름에 기반해 객체 삽입 또는 삭제
3. 같은 접두어를 갖는 버킷 내 모든 객체 목록 확인

10. 멀티파트 업로드(Multipart Upload)

스터디에서는 AWS가 단순히 파일을 쪼개는 것을 넘어, 각 파트 요청마다 다른 서버가 매핑되어 병렬로 처리되도록 설계되어 있다는 이야기가 나왔다. 

S3에서 여러 파일을 웹 브라우저로 한꺼번에 다운로드할 수 없는 이유도 함께 이야기되었다. Google Drive는 앞단 서버가 여러 파일을 zip으로 묶어서 제공하지만, S3는 각 객체 자체가 엔드포인트이기 때문에 그런 레이어가 없다는 점, HTTP 1.1 기준 브라우저의 동시 커넥션 제한(6개) 같은 브라우저 정책 문제도 복합적으로 작용한다는 이야기가 나왔다.