[DB] 파티셔닝(Partitioning), 샤딩(Sharding)

데이터 분산?

데이터를 한 곳에 보관하면 정보 관리 측면에선 좋을 수 있지만, 여러 가지 문제가 발생할 수 있다.

 

데이터가 늘어나면 데이터 베이스의 용량 이슈도 생기고, 느려지는 CRUD는 자연스레 서비스 성능에 영향을 주게 된다.

 

때문에 전략적으로 데이터를 분산화해서 관리해야한다.

 

데이터베이스 분산 전략은 몇 가지 있다.

 

1. 복제(Replication) : 전체 데이터베이스 또는 그 하위 집합을 여러 서버에 복사하여 각 서버가 읽기 요청을 독립적으로 처리할 수 있도록 분산. 한 서버의 데이터에 대한 모든 변경 사항은 다른 서버로 전파하여 처리한다.
2. 페더레이션(Federation) : 사용자 기반의 서로 다른 부분을 제공하는 여러 개의 작은 데이터베이스로 구성된 데이터베이스 생성
3. 파티셔닝(Partitioning), 샤딩(Sharding) : 데이터베이스를 작은 부분으로 나누어 분산 저장하는 방식

위 두 가지는 일반적으로는 잘 사용되지 않는다.

 

파티셔닝과 샤딩이 자주 사용되는 전략인데, 단일 DB에서는 파티셔닝도 자주 사용되고, 물리적으로 분리된 환경에서는 샤딩이 주로 사용된다.

 

가장 흔히 사용되는 두 가지에 대해 정리해 보려고 한다.

 

파티셔닝(Partitioning)

파티셔닝은 더 쉬운 관리와 더 빠른 액세스를 위해 데이터베이스를 더 작은 부분으로 나눈다.

그러나 샤딩과 달리 행이 아닌 데이터 열을 구분하는 수직 분할이 포함된다.

수직 파티셔닝과 수평 파티셔닝

예를 들어 고객 데이터베이스는 가장 자주 액세스되는 열(예: 이름, 이메일, 전화 번호)을 한 파티션에 유지하고 덜 액세스되는 열(예: 주소, 주문 내역)을 다른 파티션에 유지하여 분할할 수 있다.

 

수평 파티셔닝은 샤딩과 유사하지만, 파티셔닝은 단일 DB에서 주로 사용된다는 점에서 차이가 있다.

 

샤딩(Sharding)

데이터베이스 샤딩은 대규모 데이터베이스를 샤드(Shard)라고 하는 더 작고 관리하기 쉬운 조각으로 수평 분할해 데이터를 보관하는 방식이다.

 

각 샤드는 별도의 물리적 서버에 저장되며 데이터의 하위 집합을 포함한다.

 

그림을 잘 보아야하는게 한 DB에 있는 데이터가 두 DB로 분리되었다.

 

분리된 DB에 저장된다는 점이, 수평 파티셔닝은 한 DB 내에서 처리되는 것과의 차이다.

 

샤딩의 주요 목표는 대규모 데이터베이스의 성능과 확장성을 개선하는 것이다.

 

여러 서버에 데이터를 분산하면 쿼리를 병렬로 실행할 수 있으므로 응답 시간이 빨라지며, 각 샤드의 크기가 작기 때문에 데이터를 더 쉽게 관리하고 백업할 수 있다는 장점도 있다.

 

그럼 분산 환경을 사용하면 무조건 좋나요?

은빛 총알은 없다.

 

슬프게도, 무조건적인 장점을 가진 시스템은 없다.

 

복잡성 증가(Increased complexity): DB 분산은 데이터베이스 인프라에 복잡성을 추가하여 유지 및 관리가 어려워진다. 데이터가 적절하게 분산 및 복제되도록 관리자가 분산 전략을 잘 수립해야한다.

 

데이터 일관성(Data consistency): 데이터가 여러 경로로 분할되기 때문에 데이터 일관성 문제를 일으킬 수 있다. 애플리케이션은 데이터 수정이 모든 DB에서 적절하게 동기화되도록 해야 하며 이는 어려울 수 있다.

 

제한된 유연성(Limited flexibility): 수정된 스키마가 모든 분산환경에 동시에 반영되어야 하므로 새로운 기능을 추가하기 어렵게 만듭니다. 스키마를 변경하려면 분산 전략을 수정해야 할 수 있으며 이는 시간이 많이 걸리고 복잡할 수 있다.

 

전반적으로 데이터베이스 분산 전략은 확장성과 성능 측면에서 상당한 이점을 제공할 수 있지만 추가적인 복잡성과 관리 오버헤드도 발생하므로, 장단점을 신중하게 평가하여 필요에 맞는 솔루션인지 판단해서 적용해야한다.

 

마치며

데이터 분산화의 어려운 점은 대부분 사후에 적용하게 된다는 점이다.

 

인프라를 중간에 추가하거나 변경하는 작업은 고된 작업이거나 물리적으로 불가능할 수 있므로, 적절한 수요 예측과 사전 설계가 매우 중요하다.

 

그러나, 클라우드 환경에서는 이러한 제약에서 조금 자유롭다. 서버의 인프라가 온프레미스 환경에서 클라우드로 넘어가고 있기 때문에, 이제는 이러한 전략들에 대해 유연하게 고려해 봄직하다.