[DataBase] 분산 처리 Sharding 기법

시나브로·2021년 8월 30일
0
post-thumbnail

샤드(Shard)

  • 부하 분산을 위해 Application/DB Level에서 다수의 데이터베이스에 데이터를 분산 저장하는 기법
  • 데이터베이스 분야에서 성능, 확장성 및 I/O 대역폭을 개선하는데 사용하는 분산처리 기법

데이터의 폭발적인 증가로 수많은 빅데이터를 처리하기 위해서는 데이터를 모두 동일하게 복제하는 방식이 아닌 수평적인 서버들에 분산 저장하여 처리를 하는 방식으로 가게 되었다.

물론 샤드의 문제를 방지하기 위해서 리플리카(replica)의 방식을 섞어서 실제로는 둘 중 하나의 방식이 아닌 여러대의 노드에 혼합하여 처리한다.


개념도


구성요소

  • vertical Partitioning
    • 테이블 별로 서버를 분할하는 방식
    • 샤딩 구현이 쉽지만 데이터가 늘어나면 추가 샤딩이 필요함
  • Range Based Partitioning
    • 하나의 테이블이 거대해질 경우 서버를 분리하는 방식
    • 증설에 재정렬 비용이 들지 않는다
    • 일부 DB에 데이터가 몰릴 수 있다
  • Key or Hash Based Partitioning
    • 키와 같은 값을 해쉬함수(Hash)에 넣어 나오는 값으로 서버를 지정하는 방식
    • 특정 영역으로 데이터 값이 몰린 경우 성능 저하
    • Hash 결과가 균등하게 분포되도록 Hash 함수 선정 필요
    • DB를 추가 증설하는 과정에서 이미 적재된 데이터의 재정렬 필요
  • Directory Based Partitioning
    • 파티셔닝 매커니즘을 제공하는 추상화된 서비스 생성

잘못 사용되는 경우

서비스를 사용하는 고객의 사용량이 증가하게 되었을 경우

객은 애플리케이션 사용량이 증가하면 더 많은 스토리지를 사용하고 더 많은 리소스를 소비하기 시작한다.

어느 순간 샤드 중 하나에 과도하 부하가 걸려 한 샤드의 고객 일부를 다른 샤드(부하가 상대적으로 낮은)로 옮겨야 한다.

해당 고객의 모든 데이터를 새 샤드에 복사한 다음 고객 ID가 새 샤드를 가리키도록 해야 한다.


# 고려사항 - 데이터 재분배 : 서비스 정지 없이 데이터베이스 스키마 및 서버 설계 필요 - 샤딩 조인 : 역정규화를 어느정도 감수해야 함 - 샤딩 알고리즘 : 정수값 등으로 샤딩을 처리할 때 데이터의 비율 고려 - 장애처리 : 장애처리를 전혀 하지 않고 샤딩처리만 할 경우 데이터의 크기는 분산처리한 만큼 줄어들겠지만, 장애가 발생할 경우 치명적이 될 수 있음 - 샤드 설정 시기 : 필요한 시점보다 훨씬 이전에 샤드 설정 필요. - 낙관적인 관점에서 샤딩의 필요성을 예측하고 실제 사용량이 샤딩이 필요한 정도로 커지기 전에 샤딩해야함 - 샤딩 키 선정 : 샤드는 독립적인 동시에 균형도 맞아야 한다. - 샤드 툴 구축 : 샤딩을 프로덕션에 구현하기 전에 샤드를 관리하기 위한 툴 구축. - 툴은 샤딩된 개별 요소(고객 등)를 샤드에서 다른 샤드로, 투명하고 빠르고 효율적으로 옮길 수 있어야 한다. - 툴은 확장 사고 중에 여러 리소스를 신속하게 리밸런싱할 수 있어야 한다. - 또한 샤드 크기 조정이 잘못될 경우 알리기 위한 분석이 필요하다. - 다른 방법으로 데이터를 분할하는 방법 고려 - 데이터를 중앙 데이터 저장소가 아닌 개별 서비스 및 마이크로서비스 내에 저장하는 방법을 고려 - 데이터 집합이 작을수록 샤딩의 필요성은 낮아지며 필요할 때 샤딩을 더 간편하고 효율적으로 관리 가능하다.









Reference

profile
Be More!

0개의 댓글