Vitess를 활용한 Slack의 데이터스토어 스케일링
(slack.engineering)- 슬랙이 Active-Active 클러스터 구조에서 MySQL 수평 확장 시스템인 Vitess로 변경한 이야기
- 2017년부터 이관시작해서 이제 Vitess가 전체 쿼리의 99%를 처리중, 년말까지 완전 이전 예정
ㅤ→ 현재 피크시 230만 QPS(200만은 읽기, 30만은 쓰기)
ㅤ→ 쿼리 레이턴시 중간값은 2ms, p99 쿼리 레이턴시 11ms
- 슬랙은 LAMP 스택으로 시작(Linux,Apache,MySQL,PHP)
- 3개의 DB 클러스터
ㅤ→ 샤드 : 모든 메시지,채널,DM 등 사용자 데이터. 워크스페이스ID로 파티셔닝되어 한 워크스페이스는 한 샤드에
ㅤㅤ즉 슬랙앱은 한개의 DB에만 접속하면 됨
ㅤ→ 메타데이터 클러스터 : 워크스페이스를 샤드에 연결하기 위한 룩업테이블
ㅤ→ 키친 싱크 클러스터 : 특정 워크스페이스용이 아닌 모든 데이터 저장. App 디렉토리등
- 샤딩은 모노리스인 "webapp" 이 관리하고 조정
- 각 클러스터들은 한개이상의 샤드로 되어있고, 각 샤드는 다른 데이터센터에 있는 적어도 2개 이상의 MySQL인스턴스로 프로비져닝
- Active-Active 설정의 장점
ㅤ→ 고가용성
ㅤ→ 빠른 제품 개발 속도
ㅤ→ 쉬운 디버깅
ㅤ→ 쉬운 확장
하지만, 조직이 커지고 제품팀들이 새로운 기능을 만들게 되면서 개발속도가 느려짐
- Active-Active 의 단점
ㅤ→ 확장의 한계 : 더 큰 고객들이 들어오면서 고성능의 호스트가 수용할 수 있는 한계에 도달
ㅤ→ 한개의 데이터모델에 고착 :
ㅤㅤㅤEnterprise Grid 와 Slack Connect 같은 기능이 들어가면서 한개의 서버에만 접속하는 패러다임에 반하게 됨
ㅤ→ 핫스팟 : 데이터베이스 플릿을 잘 활용하지 못함. 샤드를 분할하고 팀이동이 어려웠고 슬랙 사용량을 예측하기 어려워 대부분의 샤드를 과도하게 프로비져닝해서 롱테일을 활용하기 어려움
ㅤ→ 워크스페이스와 샤드 가용성 문제 : 샤드에 문제 생기면 그 샤드에 있는 모든 고객이 슬랙 사용 불가
ㅤ→ 운영: 일반적인 MySQL 구성이 아니어서 많은 내부도구를 작성했음.
- 2016년 가을, 초당 수십만개의 MySQL쿼리와 수천개의 샤딩된 MySQL 호스트를 관리했음
- 정기적으로 확장 및 성능문제를 겪어서 새로운 접근방식에 대해 고민
- 기존것을 발전 또는 새로운 제품을 도입에 대해 고민했으나
ㅤ→ 자체 클라우드에서 실행되는 MySQL을 계속 사용하고 싶음
ㅤ→ 수천개의 고유쿼리가 있고, 그중 일부는 특별한 MySQL 구성을 이용
ㅤ→ 배포,백업,데이터하우스 ETL,컴플라이언스등이 모두 MySQL 에 기반
- 왜 Vitess인가 ? : 대부분의 앱/운영 요구사항을 충족
ㅤ→ MySQL Core : Vitess는 MySQL 기반
ㅤ→ Scalability : MySQL의 주요기능과 NoSQL DB의 확장성을 결합. 내장 샤딩으로 특별한 로직 추가없이 유연하게 확장이 가능
ㅤ→ Operability : 기본 장애 조치 및 백업등을 자동으로 처리. 클러스터 설정에 대한 메타데이터를 추적해서 일관성을 유지
ㅤ→ Extensibility : Go기반 오픈소스. 광범위한 테스트커버리지와 개방된 개발자 커뮤니티
- 작은 기능부터 Vitess 로 실무적용
ㅤ→ 2017년 RSS피드를 슬랙채널에 통합하는 기능을 만들어 봄
ㅤ→ 2018년에는 새 테이블은 다 Vitess에서만 만듬
ㅤ→ 2019년 중반에는 레거시DB보다 Vitess에 더 많은 쓰기가 발생
ㅤ→ 그리고 Vitess 오픈소스에 슬랙이 계속해서 기여
ㅤ→ 3년에 걸쳐서 99%를 Vitess 로 이전. 올해안에 나머지 1%도 완료
- Slack의 Vitess 도입은 성공이었나 ?
ㅤ→ 전세계 여러지역에서 여러개의 Vitess 클러스터가 수십개의 키스페이스를 운영중
ㅤ→ 키스페이스는 사용자/팀/채널수에 따라 확장되는 논리적 컬렉션
ㅤ→ 유연한 샤딩으로 Slack을 확장할 수 있게 됨
ㅤ→ COVID-19로 슬랙의 쿼리 갯수가 일주일만에 50%증가함
ㅤ→ 가장 바쁜 키스페이스를 Vitess의 분할 워크플로우를 이용해서 수평으로 확장
ㅤ→ 예전 같았으면 스케일링 불가능해서 다운타임이 발생 했을 것.
https://vitess.io/
Vitess : "Sharding Middleware for MySQL"
- MySQL과 MariaDB를 쉽게 클라우드에서 배포/스케일/관리 할수 있도록 만들어진 솔루션
- Docker(로컬)Kubernestes 위에서 MySQL샤드를 운영하고 관리
- 어플리케이션은 VTGate라는 프록시와 MySQL과 통신하듯이 사용하면, 내부에서 gRPC로 다른 서버들에 연결하는 방식