수조개 메시지 스케일링하기: Discord가 Cassandra에서 SyllaDB + Rust로 전환한 이유

(itnext.io)

26P by xguru 10달전 | favorite | 댓글 3개

Discord는 성장하면서 메시징 저장소 DB를 계속 교체하였음
초기에는 단일 MongoDB. 2015년 11월에 메시지 수가 1억개로 늘어나면서 MongoDB 한계가 드러남
2017년에 12노드 클러스터 Cassandra로 전환하여 수십억개의 메시지를 저장
2022년에는 메시지가 수조개로 급증하면서 인프라가 177개 노드로 엄청 늘어났고, 대기시간 예측이 불가능하고 유지보수 비용이 엄청 비싸짐
카산드라 에서 디스코드의 문제는 Hot Partition이었음. DB의 특정 부분이 과부하 되어 전체 어플리케이션의 성능이 저하
- 카산드라 내부 데이터 구조가 LSM트리를 활용하므로 쓰기보다 읽기 비용이 더 많이 들고, 단일 서버에서 여러 사용자의 동시 읽기는 핫스팟을 만들고 성능 저하로 이어짐
- SSTable 압축과 같은 유지 관리 작업이 전체 성능에 영향을 미쳐서 문제를 가중 시킴
그래서 다양한 구성요소를 통합하여 아키텍처 재설계에 들어감
- 모놀리식 API, Rust로 구현된 데이터 서비스, ScyllaDB에 기반한 스토리지 시스템(C++로 개발된 Cassandra 호환 DB)등을 활용
ScyllaDB를 채택하면서 상당한 개선이 이루어짐
- p99 read latency 는 카산드라의 40~125ms 에 비해 15ms로 감소
- p99 write latency 는 카산드라의 5~70ms 에 비해 5ms로 감소
디스코드 엔지니어는 Rust로 데이터 서비스를 작성
- Rust의 Feareless Concurrency 기능을 이용하여 핫 파티션에 대한 동시 트래픽을 제어
- Rust의 라이브러리와 동시성 기능은 Discord 의 요구사항에 매우 적합했음
- 데이터 서비스는 API 모노리스와 데이터베이스 클러스터사이의 중개 서비스 역할을 수행