Hacker News 의견

• 대용량 테이블과 RDS IOPS 한계

  • 가장 큰 테이블이 수TB에 달하며, 곧 RDS가 지원하는 최대 IOPS를 초과할 것으로 언급됨.
  • PostgreSQL용 RDS는 64TB 볼륨에서 최대 256,000 IOPS에 도달.
  • 다중 AZ 설정의 경우, 이는 월 $70K의 비용 발생.

• 샤딩 결과와 비용

  • 최종적으로 각 샤드가 약 50,000 IOPS와 12TB 데이터를 지원하는 5-way 샤드를 가정.
  • 다중 AZ 설정의 경우, 이는 월 $100K의 비용 발생.

• 샤딩에 소요된 시간과 비용

  • 첫 테이블을 샤딩하는 데 9개월이 걸림.
  • 애플리케이션 변경도 필요했으므로, 9개월 * 20 근무일/월 * (3명의 DB 엔지니어 + 2명의 앱 엔지니어) = 900 근무일로 계산.
  • 엔지니어의 평균 연봉이 $100K라고 가정하면, 총 비용은 약 $400K.

• YugabyteDB와 비교한 비용

  • PostgreSQL 호환 NewSQL인 YugabyteDB는 RDS의 최고 성능을 맞추는 데 월 $15K 비용 예상.
  • Figma는 내부적으로 수평 샤딩을 구현하는 데 약 25배($400K/$15K)의 비용을 지출하고 여전히 RDS를 사용 중이며, 이는 약 6배($100K/$15K)의 비용.

• 고객별 데이터베이스 분리 제안

  • 각 고객을 별도의 (논리적) 데이터베이스에 넣는 것이 더 쉬울 수 있음을 제안.
  • 다른 고객 간의 트랜잭션이 필요하지 않으므로, 실제보다 더 어려운 문제를 해결하고 있는 것으로 보임.
  • PostgreSQL의 (논리적) 데이터베이스가 잘 확장될지는 불확실하지만, 원칙적으로 불가능하지는 않음.

• MySQL의 Vitess와 유사한 PG 버전 구축

  • 쿼리 재작성이 흥미로움.
  • DB와 애플리케이션 사이에 계층을 두면 다양한 ACL(액세스 제어 목록)도 가능.

• FoundationDB에 대한 고려

  • FoundationDB를 시도하지 않은 이유에 대한 궁금증.
  • PostgreSQL의 vacuuming(가비지 컬렉션)에 문제가 있었음.
  • 이전 버전에서는 vacuuming을 위해 두 배의 공간이 필요했으나, 최신 버전에서는 변경되었을 수 있음.

• 샤딩을 해킹처럼 다루는 접근

  • 저수준 I/O 버퍼링/캐싱을 직접 처리하지 않고 OS API에 의존하는 것이 좋음.
  • DB 샤딩을 위한 유사한 기술/인프라가 여전히 부족하다는 인식.

• Citus 확장 미사용에 대한 의문

  • Citus, 이미 성숙한 Postgres 확장인데, 기사에서 언급되지 않음.
  • Citus를 모르거나 특정 이유로 무시했을 수 있음.

• Aurora Limitless 사용 가능성

  • Amazon Aurora Limitless를 사용할 수 있는지에 대한 질문.

• NoSQL 데이터베이스에 대한 이해

  • NoSQL은 복잡한 관계형 모델이 필요하지 않은 무정형 데이터를 수용하는 백엔드에 적합.
  • Postgres는 jsonb 데이터 타입으로 이를 지원하지만, 이미 좋은 데이터 모델을 가지고 있어서 많이 사용할 필요가 없음.

• 샤딩의 성숙도와 NewSQL 솔루션 고려

  • 샤딩이 성숙해진 상황에서, 자동 샤딩과 다중 지역 지원을 위해 NewSQL 솔루션을 고려할 가치가 있는지에 대한 질문.
  • NewSQL 데이터베이스를 운영하는 방법을 배우는 것도 추가 비용.

• Google의 Spanner 기술과 Figma의 평가

  • Google에서는 Spanner가 무한 수평 샤딩과 트랜잭션을 지원하는 마법 같은 기술로, 거의 모든 프로젝트가 Spanner로 이동 중.
  • Figma가 Cloud Spanner를 어떻게 평가했는지, 그리고 그들의 수평적 Postgres 스키마로 실제 트랜잭션 지원을 포기했는지(임시적으로라도) 궁금증을 표함.