How Discord Stores Trillions of Messages
Discord
Discord팀이 조 단위 메세지를 DB에 저장하는 방법
Discord는 매일 수백만의 유저가 작성하는 수십억의 메시지를 저장한다. 누적 조 단위의 메시지를 저장하기 위해 Discord 개발팀은 어떤 DB 기술을 사용할까?
→ Discord 개발팀이 처음 선택한 DB는 MongoDB였다. 하지만 시간이 지나 유저와 데이터 양이 가하급수적으로 늘며 MongoDB의 한계를 느끼고, Cassandra로 전환하게 되었다.
→ Cassandra 클러스터가 150개 이상의 노드로 커지면서 운영과 성능 문제가 많이 발생했다. 특히, 특정 노드에서 쿼리가 몰리는 문제 (hot partition)가 발생 시 개발자가 직접 노드를 조정해야 하는 번거로움이 생겼다.
→ 이런 상황에서 Discord 팀은 Cassandra와 호환되는 ScyllaDB의 발전을 주목하게 되었다. Discord 개발팀이 저장하는 메시지 이외의 다른 데이터를 새로운 ScyllaDB 클러스터로 이전하면서 그 성능과 안정성을 검증했고, 만족스러운 결과를 얻었다.
→ 하지만 가장 큰 데이터인 메시지를 ScyllaDB로 이전하기 위해서는 많은 준비 작업이 필요했다. 그 중 가장 중요한 요소는 "Data Service"의 개발이었다. Discord 팀이 선호하는 Rust로 작성된 이 서비스는 DB의 부하를 줄이기 위해 데이터 요청을 병합하는 (request coalescing)등 여러 기술을 적용했다.
→ "Data Service"의 개발로 hot partition 문제에 어느정도 보호를 받게 되었지만, Cassandra의 한계를 (예: GC 튜닝) 계속 느끼게 되었다. 700TB가 넘는 DB를 이전하기 위한 프로그램을 새로 작성하고(Rust!), 약 10일간의 작업 끝에 모든 데이터를 ScyllaDB 클러스터로 이전하는데 성공했다.
→ 170개가 넘는 노드를 가진 Cassandra 클러스터에서 70개 조금 넘는 노드를 가진, 더 효율적인 ScyllaDB 클러스터로 전환하며, 장애 발생 빈도가 줄었고 쿼리 성능도 개선되었다. 개발팀은 1년이 지난 지금까지도 아주 만족하고 있다고 한다.
https://discord.com/blog/how-discord-stores-trillions-of-messages
다음 내용이 궁금하다면?
이미 회원이신가요?
2023년 6월 23일 오전 2:59
댓글 6
안녕하십니까! 입사한지 2주된 완전초보신입개발자입니다.실례지만 궁금한게 있는데 700만개정도의 데이터를 조회해오는데 너무 길게 소요돼서 웹목록으로 보기까지 너무 48초가걸립니다. 혹시 많은 데이터를 빠르게가져오는 방법이 있을까요?.?
@찬민 700만! 정말 큰 데이터를 처리해야 하네요. 쿼리가 어떠냐에 따라서 다르겠지만 몇 가지 생각나는 게 있다면: 1. Index를 제대로 활용하고 있는지 확인 2. Paginate 해 웹 목록에는 순차적으로 ~20/50/100 아이템만 보여줄 것. 3. 데이터를 미리 가공해 (e.g. 밤에 Batch Job을 돌려) 700만 데이터 모두를 조회 할 필요가 없는는 데이터를 따로 만들어 둠 등 고려 해보시는 건 어떨까요?
감사합니다.! 말씀해주신 프라이머리키를 생성하면 자동으로 인덱스가 생성되는거라는 개념만 알고있지 제대로활용하는방법도 있는지 몰랐는데 한번 더 찾아보며.. 체크해보겠습니다. 데이터를 모두 조회할 필요가 없는 데이터를 따로 만들어두는 방식도 찾아보겠습니다! 답변감사합니다..ㅠㅠㅠ
몽고디비 샤딩 써도 문제인가요??
@박우석 클러스터링 및 샤딩도 당연히 했을거같다고 생각합니다 ScyllaDB 의 어떠한 특성으로 효율적으로 변경됐는지가 궁금하네요
@경섭 Cassandra와 ScyllaDB는 구조적으로 매우 비슷하게 동작하지만 I/O를 처리하는 방식이 다릅니다. Cassandra는 I/O를 linux page cache에 강하게 의존하는 방면 ScyllaDB는 page cache에 저장하지 않고 DMA를 방식으로 직접 메모리에 로드합니다. 이런 방식의 특성으로 더 빠른 I/O와 메모리를 효율적으로 사용하지만 그만큼 더 많은 disk IOPS를 요구합니다. 또한 JVM기반의 Cassandra와 달리 ScyllaDB는 C++ seastar라는 자체 개발한 프레임워크를 통해 개발하여 한 노드의 token range를 CPU core별로 샤드를 만들어 관리하기 때문에 context switching 적고 Cassandra에 비해 효율적 캐시(Row cache)를 관리합니다. 이렇게 놓고 보면 ScyllaDB가 무조건 좋아보이지만 Cassandra에 비해 비교적 최근에 만들어졌고 관리 측면에서 Cassandra에 비해 복잡하거나 감춰져 있는 영역들이 있어서 아직 어떤 것이 좋다라고 확실히 말하기 어려운 각자 장단점이 있습니다. 운영 관점에서 Cassandra가 더 운영하기는 편하지만 ScyllaDB가 발전하는 속도나 성능이 매우 빠르기 때문에 장기적으로는 ScyllaDB가 우세해질 시점이 올 것 같네요.
