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

지속적인 혁신: 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가 있음.

[neo]

Hacker News 의견

• 큰 시스템에 관심이 있다면 이 글을 읽어보는 것이 좋음

  • 하드 드라이브 성능은 큐에 있는 다른 트랜잭션에 따라 달라짐
  • 무작위 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는 아직 시도하지 않음