GN⁺: S3라고 불리는 꽤 큰 저장 시스템 구축 및 운영
(allthingsdistributed.com)S3의 구축과 운영
- S3는 Amazon Simple Storage Service의 약자로, 대규모 스토리지 시스템을 의미함.
- Andy Warfield는 S3에서 근무하며 시스템에 대한 광범위한 이해를 갖게 됨.
- S3는 고객의 성능 경험부터 하드 디스크 메커닉까지 다양한 분야를 아우르는 서비스임.
17년 전, 멀고 먼 대학 캠퍼스에서...
- S3는 2006년 3월 14일에 출시되어 올해로 17주년을 맞이함.
- Warfield는 캠브리지 대학에서 박사학위를 마치고 Xen 프로젝트에 참여했으며, 이후 XenSource라는 스타트업을 창업함.
- XenSource는 성장하여 Citrix에 인수되었고, Warfield는 사업 성장과 팀 관리에 대해 많은 것을 배움.
S3의 작동 방식
- Warfield는 Amazon에 합류한 후 S3의 초기 엔지니어 중 한 명인 Seth Markle로부터 S3의 작동 원리를 배움.
- S3는 HTTP REST API를 가진 오브젝트 스토리지 서비스로, 프론트엔드, 네임스페이스 서비스, 하드 디스크가 있는 스토리지 플릿, 백그라운드 작업을 수행하는 플릿으로 구성됨.
- S3는 수백 개의 마이크로서비스로 구성되어 있으며, 각 팀 간의 상호작용은 API 수준의 계약으로 이루어짐.
초기 관찰
- S3는 소프트웨어를 넘어서 하드웨어와 사람을 포함한 지속적으로 진화하는 생태계임.
- S3의 규모는 각 구성 요소가 스케일 아웃된 서비스의 집합으로 구성되어 있어, 시스템의 규모를 이해하는 데 시간이 걸림.
기술적 규모: 스토리지의 물리학
- S3는 수백만 개의 하드 디스크를 사용하는 매우 큰 시스템임.
- 하드 드라이브는 기술과 혁신의 경이로움을 담고 있으며, 비용 효율성이 뛰어남.
열 관리: 데이터 배치와 성능
- S3에서는 '열 관리'라는 문제를 해결하기 위해 I/O 요청을 다수의 하드 드라이브에 균등하게 분산시키는 최적화 작업을 수행함.
복제: 데이터 배치와 내구성
- S3는 데이터의 내구성을 보장하고 열을 관리하기 위해 복제와 이레이저 코딩과 같은 중복 스키마를 사용함.
규모의 영향: 데이터 배치 전략
- 데이터를 가능한 한 많은 디스크에 넓게 배치함으로써 고객의 데이터가 각 디스크에 매우 적은 양을 차지하게 하여 워크로드 격리를 달성함.
인간 요소
- S3의 복잡성은 기술적 요소뿐만 아니라 인간 요소에도 기인함.
- Amazon은 엔지니어와 팀이 빠르고 안전하게 실패하고, 높은 내구성의 스토리지를 제공하는 데 집중하도록 장려함.
나 자신의 확장: '소유권'으로 시작하고 끝나는 어려운 문제 해결
- Warfield는 Amazon에서 개인적인 규모의 확장을 경험하며, 소프트웨어, 사람, 비즈니스의 규모에 대해 배움.
- Amazon에서는 '소유권'에 중점을 두며, 이는 조직 구조와 엔지니어링 접근 방식을 이해하는 데 도움이 됨.
GN⁺의 의견
- S3는 단순한 스토리지 서비스를 넘어서, 하드웨어, 소프트웨어, 인간 요소가 결합된 복잡한 생태계임.
- 이 글은 S3의 규모와 복잡성을 이해하고자 하는 초급 소프트웨어 엔지니어에게 통찰력을 제공함.
- Amazon의 '소유권' 문화는 팀과 개인이 더 큰 책임감을 가지고 혁신을 추구하도록 동기를 부여하는 중요한 요소임.
Hacker News 의견
-
오류율이 10^15 요청당 1인 것은 실제 세계에서는 자주 발생하는 일이며, S3에서 고려해야 할 사항이다.
- AWS에서 근무할 때, S3 규모에서는 10억 분의 1 사건이 매일 발생하며, 평소에는 걱정할 필요가 없을 정도로 낮은 확률의 사건도 고려하고 처리해야 한다는 점을 기억한다.
- ShardStore에 대해 읽게 되어 기쁘며, 특히 정형 검증, 속성 기반 테스팅 등이 인상적이다. 이전 세대의 서비스는 유명하게 버그가 많았지만, 적어도 안전하게 실패하여 데이터 손실을 방지하는 데 집착하는 S3 엔지니어들 덕분에 잘 설계되었다.
-
유전체학 분야에서 일하면서 지난 10년간 많은 페타바이트 데이터 저장소를 다뤄왔다.
- AWS S3, GCP GCS, Ceph, Gluster, HP 시스템 등 다양한 저장 시스템을 사용해본 경험으로, 이러한 시스템을 운영하는 데 드는 노력을 높이 평가한다.
- 수많은 다른 고객과 디스크 IOPS를 공유하는 것의 이점은 매우 크며, 단일 시스템에서 이를 완화하는 것은 매우 어렵다.
- 공동 위치 하드웨어 클러스터의 경우, 대규모 작업에서 IO를 RAM이나 CPU처럼 할당 가능한 자원으로 처리하기 위해 배치 시스템을 맞춤 설정해야 했다.
- S3와 GCP는 비싸지만, 그 성능이 그만한 가치가 있다.
-
S3가 OAuth2 기반 프로토콜을 사용하여 읽기/쓰기 접근을 위임할 수 있다면 우리가 구축할 수 있는 것들.
- 사용자를 대신하여 앱이 데이터에 접근할 수 있는 HTTP 기반 프로토콜이 필요하다.
- Google Drive가 이에 가장 가까우나 단일 제공업체 문제가 있으며, remoteStorage가 인기를 얻지 못한 것이 아쉽다.
- Solid가 성공하기를 바라지만 복잡하게 느껴진다.
- 문제에 대한 나만의 해결책은 gemdrive.io이지만, 현재는 자체 호스팅 스택의 다른 부분에 집중하고 있다.
-
IBM RAMAC 하드 드라이브의 1956년 스펙에 대한 설명.
- 저장 용량: 3.75 MB, 비용: 테라바이트당 약 $9,200이라는 스펙은 정확하지 않을 수 있다.
- 다른 사이트에서는 메가바이트당 약 $10,000의 구매 가격으로, 스펙은 메가바이트당 $9,200이어야 한다고 제안한다.
-
분산 시스템에서 인증을 처리하는 것은 매우 어렵다.
- AWS 규모에서 인증은 마법과 같으며, AWS는 풍부한 권한 모델을 가지고 있어 인증 변경이 인프라를 통해 서브밀리초 속도로 전파된다.
- S3는 다른 서비스와 달리 권한이 리소스에 있어 속도를 위한 것일 수 있다.
-
기술적 의제를 가진 매우 경험 많은 엔지니어로서, 아이디어를 제공하기보다는 문제를 개발하고 명확하게 설명하는 데 더 많은 시간을 할애한다.
- 성공적인 역할을 수행하기 위해서는 문제를 명확히 하고 해결책을 지지하는 것에 초점을 맞추며, 강력한 엔지니어링 팀이 해결책을 소유하도록 지원하는 방법을 찾는다.
-
Amazon 직원들이 S3의 내부 작동 방식에 대해 공개적으로 이야기하는 것을 보는 것은 좋다.
- Glacier의 작동 방식에 대해 더 듣고 싶으며, 사용되는 저장 매체에 대해 아직 공개되지 않아 많은 추측이 있다.
-
하드 드라이브 헤드를 747 비행기에 비유하여 설명하는 부분.
- 비행기가 지구를 25,000번 돌 때 한 번의 실수로 풀 한 포기를 놓칠 정도로 정밀한 작업이다.
-
S3 KeyMap 시절로 돌아가서, 가장 뜨거운 객체/파티션/버킷을 식별한 후에도 단순히 이동해서 해결될 수 없음을 배웠다.
- 실제 해결책은 호스트의 파티션 부하를 사분위수로 나누고 두 번째 사분위수 파티션을 가장 부하가 적은 호스트로 이동하는 것이었다.
- 이로 인해 오류율이 안정적인 약 1%에서 오류가 없는 날로 바뀌어 경고를 훨씬 엄격하게 업데이트했다.
-
S3는 단순한 저장소가 아니라 표준이다.
- 몇몇 곳에서 S3 호환 저장소를 제공하며, 표준이 얼마나 개방적인지, "S3 호환"이라고 말하기 위해 Amazon에 지불해야 하는지는 확실하지 않지만, 이는 매우 멋진 일이다.