"거대해진 DB를 감당하는 법" 데이터베이스 샤딩(Sharding) 입문

"데이터가 수십 억 건이 넘어가면 어떻게 관리해야 할까요?"
단일 데이터베이스의 한계를 극복하고 수평적 확장을 가능하게 하는 샤딩(Sharding)의 개념과 전략을 정리합니다.

1. 파티셔닝(Partitioning) vs 샤딩(Sharding)

데이터를 나누는 기법은 크게 두 가지입니다. 파티셔닝은 '한 대의 서버' 안에서 테이블을 쪼개는 것이고, 샤딩은 '여러 대의 독립된 서버'로 데이터를 분산 저장하는 것을 의미합니다. 트래픽과 데이터 용량이 한 대의 서버로 감당이 안 될 때 사용하는 최후의 수단 중 하나죠.

2. 주요 샤딩 전략

• Key Based Sharding (Hash Sharding): 샤드 키를 해시 함수에 돌려 나온 결과에 따라 서버를 지정합니다. 데이터가 균등하게 배분되지만 서버 증설 시 재배치 비용이 큽니다.
• Range Based Sharding: 특정 값의 범위(예: 날짜, 알파벳 순)로 나눕니다. 관리가 쉽지만 특정 범위에 데이터가 몰리는 '핫스팟' 문제가 생길 수 있습니다.
• Directory Based Sharding: 어떤 데이터가 어디에 있는지 별도의 로케이터 서비스를 둡니다. 유연하지만 추적 서비스 자체가 병목이 될 수 있습니다.

💡 실무 노트

샤딩은 양날의 검입니다. 시스템의 복잡도를 비약적으로 높이기 때문입니다.

팁: 샤딩을 도입하기 전에 반드시 인덱스 최적화, 캐싱(Redis), 수직적 확장(Scale-up), 읽기 전용 복제본(Read Replica) 도입을 먼저 검토하세요. 샤딩을 하면 여러 서버에 흩어진 데이터를 조인(Join)하기가 매우 힘들고, 트랜잭션의 일관성을 보장하기 위해 분산 트랜잭션을 구현해야 하는 고통이 따릅니다. "정말 샤딩 아니면 답이 없는가?"를 수십 번 자문한 뒤에 결정하는 것이 시니어급의 판단입니다.

"확장성은 공짜가 아닙니다. 관리 비용이라는 세금을 내야 얻을 수 있는 가치입니다."