IO 장치와 지연 시간

 (planetscale.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 비휘발성 저장장치는 테이프에서 HDD, SSD, 클라우드 네트워크 스토리지로 발전했지만, 데이터 위치와 배치는 여전히 IO 지연을 좌우함
  • 테이프 저장장치는 순차 읽기·쓰기에 강한 반면, 멀리 떨어진 데이터를 읽을 때 수십 초까지 걸릴 수 있어 고트래픽 트랜잭션 데이터베이스에는 맞지 않음
  • HDD는 테이프보다 지연을 크게 낮췄지만, 회전 플래터와 헤드 이동 때문에 무작위 읽기가 보통 1~3ms 수준이고 요청 순서에 따라 성능 차이가 커짐
  • SSD는 기계 부품 없이 NAND flash로 동작해 무작위 읽기가 16μs까지 빨라질 수 있으나, 병렬성 활용과 garbage collection 때문에 데이터 배치가 계속 중요함
  • 클라우드의 스토리지·컴퓨트 분리는 확장성과 장애 대응을 쉽게 만들지만 네트워크 왕복과 IOPS 제한을 추가하며, PlanetScale Metal은 직접 연결된 NVMe SSD와 복제로 이 비용을 줄이려 함

저장장치 지연을 좌우하는 기본 요소

  • 비휘발성 저장장치는 전원이 꺼져도 데이터를 보존하며, 사진, 이메일, 은행 잔고, 의료 기록 같은 데이터를 저장하는 기반임
  • CPU 레지스터, CPU 캐시, RAM 같은 휘발성 저장장치는 더 빠르지만 지속적인 전원이 필요함
  • 저장장치 성능은 용량만의 문제가 아니라, 데이터에 도달하는 방식, 읽기·쓰기 단위, 큐잉, 병렬성, 네트워크 왕복 여부에 따라 달라짐
  • PlanetScale은 PlanetScale Metal 출시와 함께, Metal이 네트워크 연결 스토리지 대신 로컬 NVMe 드라이브로 클라우드 데이터베이스를 실행한다고 밝힘

테이프 저장장치: 순차 접근에는 강하지만 무작위 접근에는 약함

  • 컴퓨터는 1950년대부터 테이프 드라이브를 비휘발성 디지털 저장장치로 사용함
  • 테이프 카트리지는 여러 트랙과 많은 셀로 구성되며, 각 셀의 자기 분극 상태가 이진 데이터를 표현함
  • 카트리지를 리더에 넣고 모터로 감아가면 IO head가 지나가는 데이터를 읽음
  • 읽기·쓰기 위치가 헤드에 가까우면 빠르지만, 멀리 있으면 지연이 커짐
    • 현대 테이프 시스템에서도 멀리 있는 데이터를 읽으려면 수백 미터를 감아야 할 수 있음
    • 이런 경우 읽기에 수십 초가 걸릴 수 있음
  • 같은 수의 읽기·쓰기라도 데이터가 흩어져 있으면 순차 배치보다 훨씬 오래 걸림
    • 글의 예시는 흩어진 읽기·쓰기가 같은 작업량에서 약 7배 더 오래 걸리는 상황을 보여줌
  • 테이프는 무작위 읽기·쓰기 지연이 나쁘지만, 긴 순차 읽기·쓰기에는 여전히 적합함
    • SSD와 HDD보다 GB당 비용이 낮고 보관 수명이 김
    • CERN은 400PB 이상의 데이터를 테이프 스토리지 데이터 웨어하우스에서 관리함
    • AWS도 테이프 아카이빙 서비스를 제공함
  • 고트래픽 트랜잭션 데이터베이스에는 테이프가 적합하지 않음

HDD: 회전 디스크와 명령 큐잉의 절충

  • HDD는 테이프 대신 원형 금속 디스크인 플래터에 데이터를 저장함
  • 플래터는 인클로저 안에서 빠르게 회전하며, 예시로 7200 RPM이 흔한 속도로 제시됨
  • HDD의 트랙은 원형이고, 하나의 디스크에 100,000개 이상의 트랙이 있을 수 있음
  • 각 트랙은 수십만 개 페이지를 포함하며, 각 페이지는 대략 4KB 데이터를 담음
  • HDD는 헤드 이동과 플래터 회전으로 읽기·쓰기 위치를 맞춤
    • 테이프와 달리 전체 표면의 비트가 항상 접근 가능함
    • 원하는 데이터가 드러날 때까지 테이프를 감을 필요는 없음
  • 일반적인 무작위 읽기는 1~3ms에 수행될 수 있음
  • 요청 순서가 성능에 큰 영향을 줌
    • 순차성이 높은 읽기·쓰기는 빠르게 끝남
    • 같은 6개의 읽기·쓰기라도 순서가 뒤섞이면 플래터가 올바른 위치로 올 때까지 기다리는 시간이 늘어남
  • 자기 디스크는 오래전부터 명령 큐잉을 지원함
    • SCSI는 1980년대부터, SATA는 2000년대부터 관련 기능을 제공함
    • OS는 여러 명령을 병렬 또는 순서와 다르게 실행되도록 보낼 수 있음
    • 디스크 컨트롤러는 작업 큐를 활용해 디스크 구조에 맞게 읽기·쓰기를 스케줄링할 수 있음
  • HDD는 테이프보다 개선됐지만, 특히 무작위 읽기·쓰기에서는 여전히 느린 경우가 있음

SSD: 기계 부품이 사라져도 남는 성능 변수

  • SSD 또는 flash 저장장치는 1980년대에 발명됐지만, 소비자 저장장치로 주류가 된 시기는 2000년대임
  • SSD는 데이터를 읽기 위해 기계 부품에 의존하지 않음
    • NAND flash라는 비휘발성 트랜지스터를 사용함
    • 1과 0은 물리 부품 이동 없이 전기 신호로 읽고, 쓰고, 지움
  • SSD는 하나 이상의 target으로 구성되고, 각 target은 여러 block을 포함하며, block은 여러 page를 포함함
  • SSD는 page 단위로 읽고 씀
    • 일부 데이터만 필요해도 드라이브 요청 단위는 page임
  • 예시 구성에서 page가 4096비트, block이 16K page, target이 16K block, 장치가 8 target이면 총 4k * 16k * 16k * 8 = 8,796,093,022,208비트, 즉 8TB가 됨
  • SSD 무작위 읽기는 모델에 따라 다르지만 16μs까지 빠를 수 있음
  • 기계 부품이 없어도 데이터 배치는 중요함
    • SSD 성능 요인에는 병렬성과 garbage collection이 포함됨

SSD 병렬성: target 분산이 처리량을 바꿈

  • 일반적으로 각 target에는 컨트롤 유닛과 연결되는 전용 line이 있음
  • 각 line은 읽기·쓰기를 처리하지만 한 번에 한 page만 전달할 수 있음
  • page 전달은 매우 빠르지만, 여전히 작은 시간이 걸림
  • 8개 write가 4개 target에 분산되면 4개 line을 병렬로 사용해 두 번의 시간 조각으로 쓸 수 있음
  • 8개 write가 모두 같은 target에 몰리면 한 line만 사용되고 나머지 line은 놀게 됨
  • 읽기·쓰기 순서와 데이터 배치는 SSD에서도 성능에 영향을 줌
  • MySQL 같은 소프트웨어를 설계할 때는 데이터가 어떤 구조에 저장되고 디스크에 어떻게 배치되는지 주의해야 함

SSD garbage collection: 쓰기 전 지우기의 비용

  • SSD page는 여러 번 읽을 수 있지만, 한 번 쓴 page는 기존 데이터를 명시적으로 지우기 전까지 새 데이터로 덮어쓸 수 없음
  • 개별 page는 지울 수 없고, block 전체를 지워야 함
  • SSD는 empty, in-use, dirty page를 관리하는 내부 알고리듬이 필요함
    • dirty page는 쓰였지만 더 이상 데이터가 필요 없고 지울 준비가 된 page임
  • 새 write를 받기 위해 데이터를 재배치해야 하는 경우가 있으며, 이를 관리하는 알고리듬이 garbage collector임
  • 충분한 unused page가 있으면 새 데이터를 바로 쓸 수 있음
  • unused page가 부족하고 dirty page가 많으면 garbage collection을 먼저 수행해야 함
    • 예시에서는 새 5 page를 쓰기 위해 non-dirty page 2개를 다른 위치로 옮김
    • 그 뒤 해당 target의 page를 모두 dirty 상태로 만들어 지울 수 있게 함
    • 이런 추가 단계가 write 성능을 크게 늦춤
  • 읽기, 쓰기, 삭제가 많은 바쁜 SSD에서는 garbage collection 때문에 다른 작업이 느려질 수 있음

클라우드가 추가한 변화: 스토리지와 컴퓨트 분리

  • 테이프에서 HDD, SSD로의 변화는 내구성 있는 IO 성능을 크게 높였음
  • 클라우드로의 이동은 IO 성능에 또 다른 변화를 만들었음
  • AWS는 2006년 출시 이후 클라우드 이동을 크게 확산시킨 서비스로 제시됨
  • 클라우드 환경에서는 사용자가 대형 데이터센터의 임의 하드웨어 위에서 가상화된 서버를 빌림
  • 서버는 하드웨어 고장, 교체, 네트워크 단절 등 여러 이유로 언제든 종료될 수 있음
  • 임대 클라우드 인프라 위에서 시스템을 만들 때는 더 잦은 장애를 견딜 수 있어야 함
  • 이런 조건과 동적으로 확장 가능한 스토리지 볼륨 요구가 storage와 compute 분리로 이어짐

네트워크 연결 스토리지의 장점과 비용

  • 전통적으로 서버, 데스크톱, 노트북, 휴대폰은 비휘발성 저장장치를 직접 연결함
    • SATA 케이블, PCIe 인터페이스, 또는 같은 SoC 내장 형태가 사용됨
  • 직접 연결 스토리지는 빠르지만 두 가지 제약이 있음
    • 서버가 내려가면 데이터도 함께 사용할 수 없게 됨
    • 스토리지 크기가 고정됨
  • 애플리케이션 서버는 보통 임시(ephemeral) 환경에 잘 맞고, 많은 작업이 메모리에서 일어나므로 이 문제가 크지 않음
  • 데이터베이스는 서버가 내려가도 데이터를 잃으면 안 되고, 데이터 크기가 빠르게 증가해 스토리지 한계에 도달할 수 있음
  • 많은 클라우드 제공자는 컴퓨트 인스턴스에 별도 구성 가능한 네트워크 연결 스토리지를 붙일 수 있게 함
    • EC2의 기본 구성은 보통 EBS 네트워크 스토리지 볼륨을 붙이는 방식임
    • Amazon RDS, Amazon Aurora, Google Cloud SQL, PlanetScale 같은 데이터베이스 서비스도 compute와 storage가 네트워크로 분리된 시스템에 의존함
  • 이 방식은 스토리지 볼륨을 데이터 증감에 따라 동적으로 조정할 수 있게 함
  • 서버가 내려가도 데이터는 안전하게 남아 다른 서버에 다시 붙일 수 있음
  • 대신 네트워크 왕복과 IOPS 제한이라는 성능 비용이 생김

로컬 NVMe와 네트워크 스토리지의 지연 차이

  • 직접 연결된 NVMe SSD는 비휘발성 메모리 호스트 컨트롤러 인터페이스 명세를 사용해 빠른 IO 속도와 대역폭을 제공하는 SSD임
  • CPU에서 RAM까지의 왕복은 약 100ns로 제시됨
  • CPU에서 로컬 연결 NVMe SSD까지의 왕복은 약 50,000ns, 즉 50μs임
  • 네트워크 연결 스토리지 볼륨은 데이터센터 내부의 짧은 네트워크 왕복이 필요함
  • EBS 같은 네트워크 연결 스토리지는 왕복 시간이 약 250,000ns, 즉 250μs 또는 0.25ms로 제시됨
  • 같은 최신 SSD를 사용하더라도 네트워크 연결은 개별 읽기·쓰기 요청 처리 시간이 한 자릿수 규모로 더 길어짐
  • 대량 순차 IO에서는 부정적 영향을 줄일 수 있지만 제거할 수는 없음
  • 네트워크 연결 스토리지는 매번 스토리지 시스템에 접근할 때 추가 지연을 만든음

IOPS 제한과 직접 연결 스토리지의 차이

  • AWS와 Google Cloud를 포함한 많은 클라우드 제공자는 네트워크 연결 스토리지 모델에서 wire를 통해 보낼 수 있는 IO 작업 수를 제한함
  • Amazon의 GP3 EBS 인스턴스는 기본적으로 초당 3000 IOPS를 허용함
    • 더 높게 설정할 수 있지만 추가 비용이 듦
  • 이전 GP2 EBS 볼륨은 가끔 burst를 허용하기 위해 IOPS pool을 쌓는 방식으로 동작함
  • 스토리지를 컴퓨트 인스턴스에 직접 연결하면 인위적인 IO 작업 제한이 없음
  • 직접 연결에서는 하드웨어가 허용하는 만큼 읽고 쓸 수 있음

내구성과 확장성을 유지하는 방식

  • 직접 연결 SSD에서 문제 1인 데이터 내구성은 복제로 해결할 수 있음
  • 일반적인 방식은 한 서버를 primary로 두어 모든 write 요청을 받고, 2개 이상의 추가 서버가 데이터를 복제받는 구조임
  • 데이터가 세 곳에 있으면 데이터 손실 가능성이 작아짐
  • 예시 수치로 월간 서버 장애 확률이 1%라고 가정하면:
    • 단일 서버에서는 매달 데이터 손실 확률이 1% 임
    • 세 서버에서는 1% × 1% × 1% = 0.0001%, 즉 100만 분의 1 확률로 낮아짐
  • PlanetScale은 실패한 노드를 자동 감지하고 교체하며, 데이터베이스 데이터를 자주 안정적으로 백업함
  • 문제 2인 드라이브 확장성은 더 많은 수동 개입이 필요함
    • 디스크가 용량 한계에 가까워질 때 모니터링과 알림이 필요함
    • 필요할 때 용량을 쉽게 늘릴 도구가 필요함

PlanetScale Metal의 접근

  • Metal은 직접 연결 NVMe SSD를 사용하는 데이터베이스 클러스터를 제공함
  • 각 데이터베이스 인스턴스는 direct-attached NVMe SSD로 실행됨
  • Metal 클러스터는 기본적으로 primary 1개와 replica 2개로 구성됨
  • 지원 데이터베이스 클러스터는 Vitess 또는 Postgres임
  • 스토리지 한계에 도달하면 몇 번의 클릭으로 더 큰 드라이브가 있는 서버로 크기를 조정할 수 있음
  • 내부적으로 새 노드를 띄우고 기존 인스턴스에서 새 인스턴스로 데이터를 마이그레이션하며, 이 과정은 zero downtime으로 처리됨
  • Metal 데이터베이스에는 인위적인 IOPS cap이 없음
  • 사용자는 낮은 지연으로 IO 작업을 수행할 수 있고, 클라우드 제공자의 비싼 IOPS 클래스 비용이나 throttle 없이 하드웨어가 허용하는 만큼 사용할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 블로그 작성자임. 이번 글을 쓰는 과정이 정말 즐거웠고, 지금까지 만든 글 중 단연 가장 복잡했음
    인터랙티브 시각화를 만들려고 말 그대로 수천 줄의 JavaScript를 작성했는데, 다들 재미있게 봤으면 함

    • 시각화가 훌륭하고, 특히 튀는 상자 애니메이션은 상대 지연 시간을 설명한 것 중 가장 좋게 봄
      다만 내구성에 대한 “100만 분의 1” 표현은 새 서버가 들어와 다시 복제하기 전까지의 장애 시간이 짧다는 점을 고려하면 너무 비관적인 것 같음
      예를 들어 복구가 10분이면, 세 서버가 한 달에 한 번씩 반드시 실패한다고 해도 겹쳐서 모두 실패할 확률은 이미 200만 분의 1쯤일 것 같고, 한 달 실패 확률이 1%라면 세 장애가 겹칠 가능성은 극히 낮아짐
      고객이 100만 명이면 100만 분의 1은 그리 좋은 수치가 아니라서 덧붙여 봄
    • 애니메이션이 환상적이고 상호작용 구현도 훌륭함. 업무에서 사람들에게 지연 시간을 설명할 일이 많은데, HDD와 SSD 같은 장치의 지연 시간 차이를 눈으로 보면 훨씬 이해하기 쉬워짐
    • 들인 노력이 확실히 드러남. 대략이라도 투입 시간이 얼마나 됐는지 궁금함
      키보드를 두드린 시간과 머릿속에서 굴린 시간이 꽤 다르다는 건 알고 있음
    • 절반쯤 주제와 관련된 질문인데, 애니메이션에 어떤 라이브러리를 썼는지 궁금함. 소스 페이지에서 바로 보이지는 않음
      이 주제는 매우 익숙해서 내용 자체에는 덧붙일 말이 없고, 훑어봐도 좋아 보임. 다만 내 블로그용 애니메이션을 구상 중인데 최근 써본 라이브러리 몇 개가 마음에 들지 않았음

  • 한동안 SQLite+NVMe 조합을 밀고 있었음. 개인적으로는 평소보다 훨씬 더 멀리 가볼 수 있게 해주는 새로운 패턴으로 보이고, 어떤 경우에는 수평 확장 없이도 끝까지 버틸 수 있음
    성능에서는 지연 시간이 왕이고, 특히 항목을 직렬로 처리해야 하는 경우 더 그렇다. NVMe 위에서 SQLite를 돌리면 다른 제공자가 줄 수 없는 지연 시간 이점이 생김
    대부분의 현실적 사용 사례에서는 메모리 실행이 NVMe 영속 저장보다 크게 낫다고도 생각하지 않음

    • 왜 Postgres 같은 전통적인 클라이언트-서버 데이터베이스 대신 SQLite인지 궁금함
      단일 호스트에서는 조금 빠를 수 있지만, 웹 서버가 1대에서 2대가 되고 둘 다 데이터베이스에 써야 하는 순간 스스로 더 어렵게 만드는 것 같음
      지연 시간이 중요하다는 말도 오해의 소지가 있음. 일관성이 없으면 성능은 의미가 없고, 웹 서버가 여러 대가 되는 순간 그 일관성을 직접 해결해야 함
      게다가 데이터베이스 지연 시간은 보통 인터넷 왕복 지연보다 훨씬 작고, 그 인터넷 지연도 이미지나 코드 라이브러리 같은 페이지 자산 로딩을 기다리는 “지연”에 비하면 작음
      애초에 직렬 데이터베이스 질의는 최대한 피해야 하고, 가능하면 조인을 쓰고, 불가능할 때도 가능한 한 비동기로 동시에 질의를 날려 병렬 실행되게 해야 함
    • SQLite 파일 시스템 배치는 HDD 조각 모음에 대비하는 형태라, SSD에 맞춘 더 현대적인 배치로 바꾸고 NVMe를 쓰는 것만큼 이득을 보지는 못할 듯함
    • SQLite는 쓰기 병렬성과 아주 잘 맞지는 않음. 지원은 하지만 좀 투박하고 여전히 실패할 수 있음
      병렬 쓰기 문제를 피하려면 특정한 투박한 동작 모드를 설정하는 것 외에, 애플리케이션에서 쓰기 전용 단일 스레드를 쓰는 꼼수가 가능함
      그러면 이미 복잡한 병렬 코드가 보통 조금 더 복잡해짐. 쓰기 스레드가 하나면 SQLite는 정말 훌륭하게 동작함
    • 데스크톱 컴퓨터에서 ext4 파일 시스템의 파일에 fsync()를 해보면 NVMe 디스크에서도 여전히 1~2ms 지연 시간이 측정됨
      더 최신 시스템에서는 약 800µs 정도였음
    • Coolify로 앱과 데이터베이스를 같은 머신에서 돌려보니 꽤 재미있었음. SQL 질의에서 거의 0에 가까운 지연 시간이 보이고, 사실상 엔진 비용만 남는 게 인상적이었음

  • 정보량이 워낙 좋아서 제품 홍보라는 사실을 완전히 잊고 읽었음. 시각화와 상호작용이 훌륭함

  • 디스크 입출력 애니메이션을 보니 Melvin Kaye가 떠올랐음
    Mel은 느린 Flexowriter가 출력 문자 사이에 지연을 필요로 할 때도 시간 지연 루프를 쓰지 않았음
    대신 드럼 위의 명령어 위치를 조정해서 다음 명령어가 필요해질 때마다 읽기 헤드를 막 지나간 상태가 되게 했고, 드럼은 다음 명령어를 찾으려고 한 바퀴를 더 돌아야 했음
    https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...

    • 나도 Mel이 떠올랐음. 못 봤다면 YouTube의 Usagi Electric이 1950년대 드럼 메모리 시스템을 거의 완전 동작 상태로 되살려 놓았음

  • Metal은 정말 멋져 보이지만, 이전 직장에서 GCP의 인스턴스 로컬 SSD를 써봤을 때는 장치 블록이 데이터를 잃는 등 심각한 신뢰성 문제가 있었음
    지금은 상황이 바뀌었는지, 어떤 머신 타입을 쓰는지 궁금함
    당시 우회책은 이것이었음: https://discord.com/blog/how-discord-supercharges-network-di...

    • 흥미로운 우회책임. 우리는 2024년에야 GCP Local SSD를 쓰기 시작했고, 테스트 중에는 불량 섹터로 인한 읽기/쓰기 실패를 겪지 않았음
      다만 우리는 MySQL 세미 동기 복제로 모든 쓰기가 클라이언트에 승인되기 전에 서로 다른 가용 영역의 두 머신에 영속화되도록 하는 중복 시스템을 운영함
      Kubernetes 오퍼레이터와 Vitess의 vtorc 프로세스가 함께 동작해서 실패했거나 의심스러운 복제본까지 적극적으로 감지하고 교체함
      GCP에서는 n2d-highmem 머신에서 가장 좋은 결과를 봤고, AWS에서는 인스턴스 스토리지가 있는 최신 세대 타입을 거의 전반적으로 사용함

  • 좋은 글임. 일반적으로 클라우드 스토리지가 유난히 느리다는 문제도 있음
    다른 곳에서도 이미 다뤄졌지만, 이 글이 문제를 잘 요약함: http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
    최근 https://github.com/feldera/feldera에서 증분 인덱스를 S3/객체 스토리지에 저장하는 지원을 추가했는데, NVMe는 앞 글에서 말한 명백한 성능 이점 때문에 더 오래전부터 지원했음
    누군가 더 나은 제공 방식으로 이 영역을 흔들어 주면 좋겠음

    • 그 Database Architects 블로그는 읽을 가치가 큼

  • 이 글에서 분산 스토리지에 대해 충분히 평가되지 않은 부분이 있음
    첫째, 어떤 시스템은 복제를 기본 제공하지 않음. Cassandra 클러스터나 MySQL은 마스터-슬레이브 복제가 가능하지만 많은 시스템은 그렇지 않음
    둘째, 클라우드에서 NVMe 스토리지를 쓰면 유지보수 구간과 클라우드가 시작하는 드레인을 신경 써야 해서 운영이 훨씬 어려워짐
    그런 시스템에 연동해서 데이터를 다른 노드로 빼내지 않으면 데이터가 사라짐
    스토리지와 컴퓨트를 분리하면 클라우드 운영자가 필요할 때 컴퓨트를 비우고 옮길 수 있고, 데이터는 컴퓨트와 독립적이며 클라우드 운영자가 그 데이터 시스템과 드레인도 관리하므로 고객 개입 없이 워크로드 배치를 조정할 수 있음

    • 좋은 포인트임. PlanetScale의 내구성과 신뢰성은 MySQL 복제와, 서버 출입·네트워크 분할·클라우드에서 마주치는 여러 장애 상황 속에서도 복제를 유지하려고 작성한 운영 소프트웨어 위에 구축되어 있음
      “로컬” 파일 시스템 API처럼 보이는 복제된 네트워크 연결 스토리지는, 우리가 가진 것처럼 내장 복제가 없는 시스템에 내구성을 부여하는 강력한 방법임
    • 이론적으로는 s2.dev가 이런 상황을 구해줄 수 있음. 스트리밍 대역폭을 따라가면서도 내구성을 제공할 수 있음
    • DRBD는 아직 존재할 것 같지만, EBS를 쓰는 쪽이 확실히 더 쉬움
    • 여기서 드레인이 무슨 뜻인지 궁금함

  • 정말 멋지고 PlanetScale Metal도 꽤 탄탄해 보임. 릴리스에서 지연 시간이 크게 떨어지는 걸 보는 걸 특히 좋아함: https://planetscale.com/blog/upgrading-query-insights-to-met...

  • 수년 동안 복제 데이터베이스가 왜 늘 EBS를 붙잡고 그 지연 시간을 감수하는지 이해하지 못했음. 이미 복제가 있는데 왜 과감하게 로컬 디스크를 쓰지 않는지 의문이었음
    이전 조직에서 Elasticsearch를 임시 로그/지표 저장소로 운영할 때, 신뢰성 요구도 크지 않았으니 그렇게 하자고 제안했지만 설득하지 못했고 결국 더 나쁜 AWS Elasticsearch를 쓰게 됨
    로컬 디스크 용량이 유한한 건 알지만, 코어/메모리/디스크 비율은 대부분의 사용 사례에 충분하지 않을까 싶음. 비율이 다른 로컬 디스크 인스턴스도 많으니 적당한 균형을 찾을 수 있음
    20TB 이상 로컬 하드디스크 인스턴스로 핫/콜드 스토리지를 구현할 수도 있음
    PlanetScale 팀은 마침내 말이 되는 일을 하고 있어서 크게 칭찬하고 싶음. AWS조차 Elasticsearch를 로컬 디스크에서 돌리지 않는다니, ClickHouse나 Cassandra 같은 것들을 모두 로컬 디스크에서 돌린다고 생각해보면 됨

    • Azure Las_v3 계열 VM의 테라바이트급 로컬 SSD에서 SQL Server Availability Groups를 돌리는 아이디어로 검토해본 적이 있음
      핵심 문제는 중지-시작 이벤트 후 디스크가 지워진다는 점이었음. 나머지 클러스터가 멀쩡하고 사용 가능한 복제본이 있어도 SQL Server가 이를 자동으로 처리하지 못함
      초기화된 노드를 자동 복구하지 않기 때문에, 이를 우회하기 위한 스크립팅과 테스트는 가장 대담하고 유능한 조직이 아니라면 프로덕션에서 감당하기 어려움
    • 이 훌륭한 글이 다루지 않은 스토리지 성능 축이 몇 가지 있음. 그중 하나는 EBS를 쓰면 디스크의 데이터를 처리할 CPU와 RAM을 바꾸기 위해 VM을 위아래로 확장할 수 있다는 점임
      우리는 이런 모델로 수백 개의 ClickHouse 클러스터를 운영함. 장애보다 성능 문제를 해결하려고 크기를 조정하는 일이 훨씬 더 흔함
      예를 들어 미국 시간 일요일 아침에 테넌트 성능 문제가 생기면, 가장 단순한 해결책은 주말 동안 더 큰 VM으로 올리고 월요일 아침에 핵심 팀이 근본 원인을 보게 하는 것임
      추가 비용은 작고, 훨씬 비싼 직원 번아웃을 피할 수 있음

  • 정말 훌륭한 글이고, 무작위 쓰기 시각화가 아주 잘 만들어졌음
    네트워크 연결 스토리지의 IOPS 제한에 대해 몇 가지 어쩌면 바보 같은 질문이 듦
    첫째, “IOPS” 제한은 특정 종류의 네트워크 트래픽, 즉 EBS 볼륨과 오가는 트래픽에 대한 속도 제한이 맞는지 궁금함. 결국 “IOPS”가 “EBS 볼륨 네트워크 트래픽”을 뜻하는 건지 묻고 싶음
    둘째, 이 방식이 비용을 아껴주는지도 궁금함. 그렇다면 이상한 AWS 가격 차익 때문인지, 아니면 EBS 네트워킹을 덜 하면서 생기는 효율성 이득 때문인지 궁금함
    스토리지와 컴퓨트를 같은 머신에 두는 것이 지연 시간 면에서 구조적으로 한 홉을 줄이는 이점이라는 건 분명해 보이지만, 달러당 처리량 측면에서도 이득인지 알고 싶음

    • EBS 볼륨 자체에는 프로비저닝된 IOPS와 처리량이 있고, 그 볼륨이 붙은 EC2 인스턴스에도 연결된 모든 EBS 볼륨을 통틀어 별도 한도가 있음
      나는 이를 다른 모델로 보는 편임. EBS 볼륨은 PCIe 버스에 붙은 물리 기판 일부가 아니라, 수많은 물리 드라이브로 구성된 대규모 분산 시스템의 지분이며 컴퓨트와 오가는 전용 네트워크 용량을 가진 SAN에 가까움
      비용은 절약될 수도 있지만, 결국 여러 절충의 묶음임
    • 네트워크 연결 스토리지의 IOPS 제한은 대역폭이 아니라 초당 패킷 수를 제한함. 입출력 작업은 4K나 16K 블록처럼 서로 다른 크기로 발생할 수 있기 때문임
답변달기