많은 트래픽이 몰리는 경우 가장 중요한것중 하나는 병목 지점을 방지해야한다.
특히 데이터베이스의 잦은 접근이 병목 지점이 될 수 있다.
이때 재고와 같은 공용 데이터의 경우 락을 통해 동시성 문제를 해결하는것도 중요한데
만약 대용량 트래픽에서 개인 데이터 접근시에는 어떻게 개선할 수 있을까?
요지는 "개인"데이터다. 즉 공용으로 사용될일은 없다.
데이터베이스 접근에 대한 트래픽을 어떻게 분산시킬것인가?
샤딩
샤딩은 데이터베이스 트래픽을 분산할 수 있는 중요한 수단이다.
나아가 특정 db 장애가 시스템 전반의 장애로 이어지지 않도록 방지하는 수단이기도하다.
물론 시스템의 규모가 커짐에따라 테이블의 크기도 커지고 성능 저하가 발생할때 테이블을 분리시켜
성능 개선의 방법도 될 수 있다.
여기서 생각해볼건 트래픽 분산 관점에서의 샤딩
파티셔닝과 샤딩의 가장 큰 차이점은 테이블을 분할할때 동일 db에서하느냐, db 서버를 분리하느냐이다
무엇보다 지금 내가 고려해보고 싶은 문제는 대용량 트래픽에서 샤딩을 통해 병목을 개선하는 방법이다.
예를들어 데이터를 적절히 디비에 분리하여
- 한국 요청은 a디비
- 일본 요청은 b디비
등으로 분배하는 방법을 통해, 즉 샤딩을 통해 디비 접근 트래픽을 분산할 수 있는지 중점으로 살펴보고자한다.
모듈러 샤딩
키 값(PK)을 모듈러 연산한 결과로 디비를 라우팅하는 방식이다
레인지 샤딩에 비해 데이터가 비교적 균등하게 분배된다.
다만 db 추가 증설시 이미 적재된 데이터의 재정렬이 필요하다.
왜? 3으로 나누던걸 4로 나누면 그 결과가 바뀌니까
따라서 데이터의 양이 일정한 경우 굉장히 효율적일것.
일정한 데이터라면 키 값을 모듈러 연산할 대상 여기선 %3의 3이 일정하니까
⭐️ 이건 내가 원하는 방법이 아니다
왜? 트래픽은 유동적이라고 생각한다
순간 피크치고 쭉 빠지는등
개요 :
샤딩
모듈러 샤딩
따라서 데이터의 양이 일정한 경우 굉장히 효율적일것. 일정한 데이터라면 키 값을 모듈러 연산할 대상 여기선 %3의 3이 일정하니까
⭐️ 이건 내가 원하는 방법이 아니다 왜? 트래픽은 유동적이라고 생각한다 순간 피크치고 쭉 빠지는등
따라서 모듈러 샤딩은 적합하지 않다고 생각한다.
키 값(PK)이 속하는 범위에 따라 분배하는 방식
모듈러 연산에 비해 재정렬 문제는 거의 없다.
다만 특정 데이터베이스에 데이터가 몰릴 수 있다. 즉 균등 분배가 어렵다 왜?
물론 적절한 range를 기준으로 잘 분배한다면 문제를 개선할 수 있다.
트래픽은 유동적이라고 생각한다. 예측이 어렵고 쉽게 변한다. 변화에 유연한 대응이 가능하려면 레인지 샤딩이 조금 더 효과적이지않을까한다. 다만 그럴려면 요청이 몰리지 않도록 range를 잘 고려해야겠다.