# 지속적인 혁신: AWS 블록 스토리지의 간략한 역사

> Clean Markdown view of GeekNews topic #16428. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16428](https://news.hada.io/topic?id=16428)
- GeekNews Markdown: [https://news.hada.io/topic/16428.md](https://news.hada.io/topic/16428.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-08-23T10:34:24+09:00
- Updated: 2024-08-23T10:34:24+09:00
- Original source: [allthingsdistributed.com](https://www.allthingsdistributed.com/2024/08/continuous-reinvention-a-brief-history-of-block-storage-at-aws.html)
- Points: 2
- Comments: 1

## Topic Body

##### 지속적인 혁신: AWS 블록 스토리지의 간략한 역사

- **소개**
  - Marc Olson은 Elastic Block Store(EBS) 팀에서 10년 이상 일해왔음.
  - EBS는 단순한 블록 스토리지 서비스에서 하루에 140조 이상의 작업을 처리하는 대규모 네트워크 스토리지 시스템으로 발전했음.
  - 이 글에서는 EBS의 진화 과정과 중요한 교훈을 공유함.

- **EBS의 초기 역사**
  - EBS는 2008년 8월 20일에 출시되었으며, EC2 인스턴스를 위한 네트워크 연결 블록 스토리지를 제공하는 간단한 아이디어로 시작됨.
  - 초기에는 공유 하드 디스크 드라이브(HDD)를 사용했으며, 현재는 단일 EC2 인스턴스에 수십만 IOPS를 제공할 수 있음.
  - EBS는 현재 분산 SSD 플릿을 통해 하루에 140조 이상의 작업을 처리함.

- **큐잉 이론**
  - 컴퓨터 시스템이 스토리지와 상호 작용하는 방식은 기본적으로 변하지 않았음.
  - CPU는 요청을 큐에 넣고, 스토리지 장치는 데이터를 CPU 메모리에서 가져와 내구성 있는 기판에 저장하거나 반대로 데이터를 CPU 메모리로 전송함.
  - 큐잉 이론은 이러한 프로세스를 이해하는 데 중요한 역할을 함.

- **HDD에서 SSD로의 전환**
  - 초기 EBS는 HDD를 사용했으며, 이는 물리적 한계로 인해 성능이 제한적이었음.
  - SSD가 등장하면서 랜덤 요청도 거의 순차적 요청만큼 빠르게 처리할 수 있게 되었음.
  - 2012년에 SSD를 사용한 새로운 스토리지 서버 타입과 Provisioned IOPS라는 새로운 EBS 볼륨 타입을 출시함.

- **측정과 관리**
  - 2012년 당시 EBS는 기본적인 텔레메트리만 가지고 있었음.
  - 시스템 성능을 개선하기 위해서는 무엇이 문제인지 알아내고, 이를 우선순위에 따라 해결해야 했음.
  - 여러 하위 시스템에서 IO를 측정하는 방법을 구축하고, 지속적인 모니터링을 통해 변화를 감지함.

- **조직의 분할과 정복**
  - EBS 스토리지 서버 팀을 데이터 복제, 내구성, 스냅샷 하이드레이션 등 특정 영역에 집중하는 작은 팀으로 재구성함.
  - 각 팀은 독립적으로 변경 사항을 반복하고 커밋할 수 있었음.

- **가정에 도전하기**
  - Xen 하이퍼바이저의 기본 설정이 성능을 제한하고 있었음을 발견함.
  - Nitro 오프로드 카드를 사용하여 네트워크 및 스토리지 처리 작업을 하드웨어로 오프로드함.

- **네트워크 튜닝 실험**
  - EBS를 Nitro로 이동시키면서 네트워크 자체의 오버헤드가 증가함.
  - TCP 대신 SRD(Scalable Relatable Diagram) 프로토콜을 개발하여 네트워크 성능을 개선함.

- **제약 조건이 혁신을 촉진함**
  - 모든 고객에게 SSD의 이점을 제공하기 위해 기존 하드웨어를 교체하지 않고도 SSD를 추가함.
  - SSD를 서버에 수작업으로 추가하고, 새로운 쓰기를 SSD에 저장한 후 비동기적으로 HDD로 플러시함.

- **성능 확장의 반성**
  - 개인적인 성장 이야기: 작은 회사 문화에서 대규모 조직으로의 전환.
  - 동료 디버깅 세션을 통해 문제를 해결하고, 팀의 효율성을 높임.

- **결론**
  - EBS는 단일 대규모 변경이 아닌 일련의 점진적인 개선을 통해 발전해왔음.
  - 고객의 요구는 계속 증가할 것이며, 이는 혁신과 반복을 지속하는 동기가 됨.

##### # GN⁺의 정리
- 이 글은 AWS의 EBS가 어떻게 진화해왔는지에 대한 내부자의 관점을 제공함.
- 큐잉 이론, SSD 도입, 네트워크 튜닝 등 다양한 기술적 도전과 해결책을 다룸.
- 성능 개선을 위한 지속적인 측정과 관리의 중요성을 강조함.
- 비슷한 기능을 가진 제품으로는 Google Cloud Persistent Disk와 Microsoft Azure Disk Storage가 있음.

## Comments



### Comment 28231

- Author: neo
- Created: 2024-08-23T10:34:24+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41321063) 
- 큰 시스템에 관심이 있다면 이 글을 읽어보는 것이 좋음
  - 하드 드라이브 성능은 큐에 있는 다른 트랜잭션에 따라 달라짐
  - 무작위 4kB 작업에서는 성능이 크게 떨어질 수 있음
  - 큐잉과 스케줄링이 도움이 되지만, 실제 성능은 작업 부하에 따라 100배 이상 차이날 수 있음
  - 다중 테넌트 시스템에서는 특히 읽기 작업에서 어려움이 있음

- 문제를 해결하려면 무엇이 잘못되었는지 알아야 함
  - Marc에게 배운 가장 큰 교훈은 시각화를 통해 팀의 관점을 바꾸는 것임
  - 성능 데이터를 여러 방식으로 분석하면 보이지 않는 효율성과 기회를 발견할 수 있음

- 2013년에 EBS 서버에 SSD를 설치한 프로젝트는 AWS의 흥미로운 이야기 중 하나임
  - 시스템을 처음부터 비파괴 유지보수 이벤트를 염두에 두고 설계했음
  - 분산 시스템을 구축하면 대규모 운영이 가능해짐

- AWS의 약 4일간의 장애는 EBS로 인해 발생했으며, 이는 AWS에 대한 신뢰를 흔들었음
  - 이로 인해 EBS에 대한 투자가 증가했음
  - Apple이 고객이 되던 시기와 맞물려 있었음

- Reddit은 2008년에 EBS의 초기 사용자 중 하나였음
  - 소프트웨어 RAID를 사용하여 IOPS를 증가시키려 했으나, 성능이 일관되지 않았음
  - RAID의 문제를 해결하는 데 시간이 걸렸음
  - Netflix는 EBS를 사용하지 않았음

- 무작위 지연을 추가하면 평균 지연과 이상치가 감소하는 효과가 있음

- 대규모 인터넷 회사에서 일하면서 많은 교훈을 얻었음
  - 견습 과정을 통해 중요한 지식과 기술을 빠르게 습득할 수 있음
  - 면접 시 경험과 멘토의 추천이 매우 유용함

- 2013년에 모든 EBS 유닛에 SSD를 수동으로 설치한 부분이 흥미로웠음
  - 2010-2012년 사이에 I/O 성능이 중요한 이슈였음

- 2009년에 Amazon S3 내부에 대한 강연을 했음
  - 이 강연은 EBS 개발에 영향을 미쳤음

- 클라우드 초기에는 범용 하드웨어를 사용했으나, 이제는 개별 서비스에 특화된 하드웨어를 사용함
  - AWS는 Graviton, Inferentia, Tranium 칩을 사용함
  - Google은 TPU와 Titan 보안 카드를 사용함
  - Azure는 FPGA와 Sphere를 사용함

- 첫 번째 다이어그램은 잘못되었거나 구식임
  - 현대 컴퓨터는 대부분의 PCIe 레인이 CPU로 직접 연결됨
  - 이는 I/O 처리량과 지연에 중요한 발전임

- 새로운 EC2 인스턴스에 빠른 256GB 데이터셋 디렉토리를 제공하는 가장 좋은 방법을 찾고 있음
  - EBS 볼륨을 사용하고 있지만 업데이트가 번거로움
  - EFS는 너무 느림
  - 인스턴스 스토리지 SSD는 일시적임
  - FSx Lustre는 아직 시도하지 않음