샤딩하지 말아야 하는 경우

샤딩은 운영 복잡성을 크게 높입니다. 대부분의 앱에는 샤딩이 필요하지 않습니다. 먼저 더 간단한 방법을 모두 검토하십시오.

더 큰 서버를 사용합니다. 최신 클라우드 인스턴스는 다음을 쉽게 처리합니다:

• 128개 코어
• 1 TB RAM
• 50,000 IOPS NVMe

단일 PostgreSQL 노드에서 100k-500k QPS를 처리할 수 있다는 뜻입니다. 대부분의 앱은 충분히 처리할 수 있습니다.

읽기가 대부분이라면 replica를 추가합니다. primary 하나와 replica 3개로 읽기 요청을 10배 처리할 수 있습니다.

자주 실행되는 query 앞에 Redis/memcached를 둡니다. 가장 저렴하게 얻을 수 있는 효과인 경우가 많습니다.

PG의 기본 선언적 파티셔닝은 단일 서버 안에서 “테이블이 너무 큰” 문제를 해결합니다. 샤딩보다 100배 쉬운 경우가 많습니다.

서로 다른 도메인을 서로 다른 데이터베이스로 이동합니다. 주문 DB, 사용자 DB, 분석 DB처럼 구성할 수 있습니다. 각 데이터베이스를 독립적으로 확장할 수 있습니다.

OLTP query는 PostgreSQL로 보내고, 분석 query는 ClickHouse / BigQuery / Snowflake로 보냅니다. “샤딩이 필요하다”는 많은 사례는 실제로 “분석 작업이 OLTP를 과도하게 사용하고 있다”는 문제입니다.

OLTP 전용 데이터가 50TB에 이르렀는데도 여전히 한 서버가 처리할 수 없는 쓰기량이 필요하다면 샤드를 계획하기 시작합니다.

• 모니터링하고 패치해야 할 서버가 늘어납니다.
• 샤드 전체의 백업을 조정해야 합니다.
• 샤드 간 query 처리가 앱 코드로 넘어옵니다.
• 재샤딩이 어렵습니다.
• 트래픽 집중 샤드에는 적극적인 재분산이 필요합니다.

나중에 샤딩할 수 있도록 샤딩을 고려한 패턴으로 구축합니다(항상 tenant_id를 포함하고, 전역 자동 증가 카운터는 사용하지 않습니다). 하지만 꼭 필요해질 때까지는 샤딩하지 않습니다.

단일 노드를 유지하더라도 샤딩할 가능성을 고려하여 설계합니다:

• 모든 행에 tenant_id를 포함합니다.
• UUID 또는 분산 ID를 사용합니다(자동 증가 방식은 사용하지 않음).
• 전역 고유 시퀀스를 사용하지 않습니다.
• 외래 키를 테넌트 범위 안에 둡니다.

샤딩은 기능을 대가로 용량을 늘립니다. JOIN, 트랜잭션, query가 더 어려워집니다. 얻는 이점이 그만한 가치가 있는지 확인해야 합니다.

샤딩은 실제 문제를 해결하지만, 그 대가가 큽니다.

• 먼저 수직 확장을 사용합니다.
• 읽기 replica와 캐싱을 사용합니다.
• 샤딩 전에 파티셔닝을 사용합니다.
• 분석 작업을 OLTP에서 분리합니다.
• 샤딩할 수 있도록 설계하되 실제 샤딩은 미룹니다.

OLTP query가 느려서 샤딩을 고려하고 있습니다. 샤딩하기 전에 어떤 단계가 가장 도움이 될 가능성이 높습니까?