Vitess - 0. why?
Vitess는 왜 만들어졌을까??
위 글이 기존 MySQL 단일 인스턴스에서 운영하는 서비스의 문제점과 vitess의 필요성에 대해서 잘 설명해주고 있다.
가파르게 성장치를 보인 TubeYou를 예시로 설명하여 더 이해하기 쉽다.
1 단계. 단일 인스턴스
당연 초기 서비스를 구축할 때는 데이터베이스를 단일 인스턴스로 구축하여 여러 서비스를 연결한다. 점점 서비스들이 성장하면서 트래픽 양도 늘어나고 단일 인스턴스에서 모두 감당하기 힘들어진다.
2단계. Replication
따라서, Read 요청을 분산할 수 있도록 노드를 여러개로 늘린다. 모든 노드는 거의 동일한 데이터를 가지고 있으며 Leader와 Follwer(Replica)로 나뉜다. 하지만 여전히 Write 요청은 Leader에서만 처리하고 있기에 Write 트래픽에 대한 부담은 여전하다. Leader, Follower에 대해 더 알고 싶다면 Raft 알고리즘(https://seongjin.me/raft-consensus-algorithm/) 혹은 몽고디비의 문서( https://www.mongodb.com/docs/manual/replication/)를 읽어도 괜찮아보인다.
3단계. 샤딩
결국 Write에 대한 부담은 분산되지 않고 커지는 점, 결국 Replica들 하나하나가 가지는 데이터의 크기는 줄어들지 않았다는 점(어쨌든 단일 노드에 저장되는 데이터 용량은 한계가 있을테니) 등 여러 한계점에 부딪혀 물리적으로 데이터베이스를 쪼개기로 결정한다. 샤딩은 여러 데이터베이스들에 동일한 스키마를 가지고 데이터를 균일하게 저장하는 방법이다. 샤딩에 대해서 더 자세한 내용은 우아한형제들의 기술 블로그(https://techblog.woowahan.com/2687/ )를 참고하고,
샤딩에는 여러 허들이 존재한다.
우선 데이터를 샤딩 전략에 맞게 적절하게 나눠서 넣는것과 찾아오는 것이 프로그래밍 복잡도를 증가시킨다. 위 기술블로그에서의 설명과 예시에서도 애플리케이션 단에서 직접 어디로 저장할지, 어디에서 읽어올지 코드로 관리하는 것을 볼 수 있다.
비즈니스에 따라 데이터가 한 쪽 샤드로 몰릴 수도 있다. 인스타 그램의 인플루언서가 저장된 디비를 상상해보면 이해된다
샤딩을 하면서 복잡해진 부분으로 인해 개발 비용을 증가시키고 단일 인스턴스든 레플리케이션 구조든 샤딩으로 마이그레이션할 때 많은 시간과 비용을 요구한다.
레플리케이션은 그저 리더 노드를 복제하면 되고 (간단하기에 디비 자체가 회복성을 갖추고 있을 수도 있다) 관리 포인트가 적다.
레플리케이션과 달리 샤딩에서는 리더만 볼게 아니라 각 노드마다 데이터가 다르기 때문에 실패 지점(노드)까지 찾아가야 하고 그로 인해 유지보수 비용이 높아진다.
4단계. 멀티 리전
그래도 샤딩으로 인해 많은 트래픽을 감당할 수 있다. 하지만 서비스가 글로벌화 되면서 유저가 전 세계에 존재하기 시작했고 단일 지역에 존재하는 데이터베이스로는 불안하다. 단순하게 물리적인 거리의 한계로 인해 네트워크 응답속도가 느리기도 하고 단일 지역 서버가 외부적 요인으로 인해 다운되는 경우도 발생할 수 있다. 따라서 여러 지역으로 분산시키는데 이 또한 애플리케이션 복잡도를 높인다.
스키마를 변경하면 모든 지역의 모든 샤드에 걸쳐 스키마를 적용해야 한다.
리더 노드의 위치를 추적하고 사용자의 쿼리를 올바른 위치로 라우팅하기 위한 조치가 필요하다.
이 정도까지 복잡도가 높아졌으면 개발 비용은 엄청나게 높아진다. 또한 유저가 늘어남에 따라 다시 샤딩해야 하는 경우는 상상도 하기 힘들다.
Vitess는 이러한 복잡성을 처리하기 위해 만들어진 대규모 MySQL 클러스터 운영 솔루션이다.
Reference:
Andrew Dawson
