본문 바로가기
Database/MYSQL

Mysql Shard 관련 참고 자료

by 반화넬 2018. 1. 15.
반응형




- ADT 활용 예제1: MySQL Shard 데이터 재분배

http://tech.kakao.com/2016/07/01/adt-mysql-shard-rebalancing/

 - 빌드하기 (Build)
https://github.com/kakao/adt/blob/master/README_ko.md#빌드하기-build

- 실행하기
https://github.com/kakao/adt/blob/master/README_ko.md#실행하기



Range 방식의 한계

특정 ID값을 기준으로, ID 범위에 따라 샤드를 나누는 방식입니다. ID값이 증가하는 추이를 보고서 새로운 샤드 추가가 쉽다는 장점이 있습니다. 반면에 디스크 사용량이나 쿼리 처리량의 밸런스가 많이 안 맞는 경우가 발생하기도 합니다.

아래 그림과 같이 User ID 기준, Range 방식으로 샤딩을 적용한 어떤 서비스가 있다고 가정하겠습니다. 초창기 샤드는 데이터량이 아주 많고 최근에 추가된 샤드는 다른 쿼리 처리량이 매우 많습니다. 그리고 간혹 초창기 사용자들의 충성도가 높은 서비스의 경우, 초기에 추가한 샤드들도 쿼리량이 적지 않은 경우가 있습니다.

Range-based 샤딩


Modulus 방식의 한계

[ID값] % [샤드 개수]의 결과 값으로 샤드 위치를 결정하는 방식입니다. Range 방식에 비해 리소스 사용 밸런스가 잘 맞다고 알려져 있습니다. 그러나 이 방식은 샤드 추가가 어렵습니다.

아래 그림과 같이 3개의 샤드에서 4개의 샤드로 확장을 하려면 기존의 각 샤드마다 데이터 재배치가 필요합니다. 현재 샤드 개수의 배수로 확장하면 그나마 쉽게 샤드 추가를 할 수 있지만, 만약 현재 샤드 개수가 수십~수백이라면 적지 않은 낭비가 발생할 수도 있습니다.

Modulus-based 샤딩


그 외: Shard Scale-in/out

클라우드 서비스에서 제공하는 DB를 사용하는 서비스 경우, 간혹 이런 경우가 있습니다.

피크 타임의 수많은 UPDATE 쿼리를 버티기 위해 shard 수를 늘렸습니다. 그런데 새벽에는 DB 머신이 거의 놀고 있어서 낭비가 발생하고 있습니다. 자유롭게 shard scale in/out할 수 있는 방법은 없을까요?

이러한 기존 문제들을 해결하기 위해서는 각 샤드들의 데이터를 재분배가 필요합니다.

반응형