Discord가 수조 개 메시지를 저장하는 방식 (2023)

 (discord.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Discord는 메시지 저장량이 수십억 개에서 수조 개로 커지면서, 2022년 초 177개 노드 Cassandra 클러스터의 운영 부담과 예측하기 어려운 지연을 더는 감당하기 어려워짐
  • channel_id와 시간 버킷 중심의 Cassandra 설계는 대형 서버의 집중 읽기 트래픽에서 핫 파티션을 만들었고, quorum 읽기·쓰기 때문에 지연이 더 넓은 사용자 영향으로 번짐
  • API와 데이터베이스 사이에 Rust 기반 데이터 서비스를 두고, 같은 행에 대한 동시 요청을 병합하며 채널 ID 기반 일관 해시 라우팅으로 데이터베이스 부하를 줄임
  • ScyllaDB 전환은 새 클러스터 구성과 Rust 마이그레이터로 진행됐고, Spark 기반 예상 3개월 작업을 9일 수준으로 줄이며 최대 초당 320만 개 메시지를 이전함
  • 2022년 5월 전환 뒤 노드는 177개 Cassandra에서 72개 ScyllaDB로 줄었고, 과거 메시지 조회 p99는 40~125ms에서 15ms로, 메시지 삽입 p99는 5~70ms에서 5ms로 개선됨

Cassandra에서 커진 운영 부담

  • Discord는 2017년에 수십억 개 메시지를 저장하는 방식을 공개하며 MongoDB에서 Cassandra로 이전한 과정을 공유했음
  • 당시 목표는 확장 가능하고 장애에 강하며 유지보수가 비교적 적은 데이터베이스였지만, 저장량이 늘면서 Cassandra 클러스터 자체가 큰 운영 부담이 됨
  • 메시지 저장용 cassandra-messages 클러스터는 2017년 12개 노드에서 2022년 초 177개 노드로 늘었고, 수조 개 메시지를 저장함
  • 운영팀은 데이터베이스 문제로 자주 호출됐고, 지연 시간은 예측하기 어려웠으며, 비용이 너무 커진 유지보수 작업을 줄여야 했음

메시지 스키마와 핫 파티션

  • 단순화된 메시지 스키마는 channel_id, bucket, message_id, author_id, content를 포함했고, 기본 키는 ((channel_id, bucket), message_id)였음
  • Discord의 ID는 Snowflake 기반이라 시간순 정렬이 가능했고, 메시지는 채널과 정적 시간 창인 bucket으로 파티션됨
  • Cassandra에서는 특정 채널과 bucket의 모든 메시지가 함께 저장되고, 복제 계수에 따라 여러 노드에 복제됨
  • 작은 친구 그룹 서버와 수십만 명 규모 서버는 메시지 양이 여러 자릿수 차이를 보였고, 이 차이가 파티션 단위 부하 차이로 이어짐
  • 쓰기는 커밋 로그와 메모리 구조인 memtable에 append된 뒤 디스크로 flush되지만, 읽기는 memtable과 여러 SSTable을 조회할 수 있어 비용이 더 컸음
  • 대형 서버에서 동시 읽기가 몰리면 특정 파티션이 핫 파티션이 되고, 해당 노드의 지연이 증가하며 다른 쿼리까지 영향을 받음
  • 읽기와 쓰기에 quorum consistency level을 사용했기 때문에, 핫 파티션을 담당하는 노드의 지연 증가는 더 넓은 사용자 영향으로 번짐

Cassandra 유지보수 병목

  • Cassandra의 compaction도 반복적인 장애 대응 원인이 됨
    • SSTable을 디스크에서 compact해야 읽기 성능이 좋아지지만, compaction이 밀리면 읽기 비용이 커짐
    • 노드가 compaction을 수행하는 동안 지연이 연쇄적으로 증가할 수 있었음
  • Discord는 “gossip dance”라고 부른 작업을 자주 수행함
    • 노드를 트래픽에서 제외해 compaction을 진행함
    • 다시 투입해 Cassandra hinted handoff의 hint를 따라잡게 함
    • compaction backlog가 없어질 때까지 이 과정을 반복함
  • JVM 가비지 컬렉터와 heap 설정 튜닝에도 많은 시간이 들었고, GC pause는 큰 지연 스파이크를 만들었음

ScyllaDB로 옮긴 이유

  • Discord는 메시지 외에도 여러 Cassandra 클러스터를 운영했고, 각 클러스터에서 유사한 문제가 나타남
  • 이전 글에서 관심을 보였던 ScyllaDB는 Cassandra 호환 데이터베이스이며 C++로 작성됐고, 더 나은 성능, 빠른 repair, shard-per-core 아키텍처 기반 워크로드 격리, 가비지 컬렉션이 없는 구조를 제공함
  • ScyllaDB에도 문제가 없지는 않았지만, Java가 아니라 C++로 작성돼 가비지 컬렉터가 없다는 점이 Cassandra 운영 문제와 직접적으로 대비됨
  • 실험과 테스트에서 개선을 확인한 뒤 Discord는 모든 데이터베이스를 ScyllaDB로 이전하기로 했고, 2020년까지 cassandra-messages를 제외한 모든 데이터베이스를 이전함
  • 메시지 클러스터는 수조 개 메시지와 거의 200개 노드를 가진 큰 클러스터였기 때문에 마지막까지 남음
  • ScyllaDB의 역방향 쿼리 성능은 초기 테스트에서 요구사항에 부족했음
    • 역방향 쿼리는 테이블 정렬 반대 방향으로 스캔하는 경우이며, 예시는 메시지를 오름차순으로 스캔하는 작업임
    • ScyllaDB 팀이 성능 개선을 우선순위로 구현하면서, 마지막 데이터베이스 마이그레이션을 막던 요인이 제거됨

Rust 기반 데이터 서비스

  • Discord는 데이터베이스만 바꿔서는 모든 문제가 자동으로 해결되지 않는다고 보고, 데이터베이스 상위 계층도 함께 바꿈
  • API 모놀리스와 데이터베이스 클러스터 사이에 데이터 서비스를 둬 데이터베이스로 향하는 동시 요청을 제어함
  • 데이터 서비스는 Rust로 작성됨
    • Discord는 이전에도 Rust를 몇몇 프로젝트에 사용했음
    • Rust는 안전성을 포기하지 않으면서 C/C++ 수준의 속도를 제공함
    • Tokio ecosystem은 비동기 I/O 시스템 구축 기반으로 쓰였고, Cassandra와 ScyllaDB 드라이버 지원도 있었음
  • 데이터 서비스는 데이터베이스 쿼리당 대략 하나의 gRPC 엔드포인트를 갖고, 의도적으로 비즈니스 로직을 담지 않음
  • 핵심은 요청 병합임
    • 여러 사용자가 동시에 같은 row를 요청하면 데이터베이스는 한 번만 조회됨
    • 첫 요청이 서비스 안에서 worker task를 만들고, 이후 요청은 그 task의 존재를 확인한 뒤 구독함
    • worker task가 데이터베이스를 조회하고 결과 row를 모든 구독자에게 반환함

라우팅으로 병합 효과를 높임

  • 데이터 서비스 앞단에는 일관 해시 기반 라우팅을 적용함
  • 각 데이터 서비스 요청에는 routing key가 제공되며, 메시지의 경우 routing key는 채널 ID임
  • 같은 채널의 모든 요청이 같은 서비스 인스턴스로 가기 때문에 요청 병합이 더 잘 작동함
  • 예를 들어 대형 서버에서 @everyone 알림이 발생하면 많은 사용자가 앱을 열고 같은 메시지를 읽으면서 데이터베이스 트래픽이 급증할 수 있음
  • 이전 구조에서는 이런 상황이 핫 파티션으로 이어져 운영팀 호출이 필요할 수 있었지만, 데이터 서비스는 데이터베이스로 향하는 트래픽 스파이크를 크게 줄임
  • 이 개선이 Cassandra 클러스터의 핫 파티션과 지연을 완전히 없애지는 못했지만, 새 ScyllaDB 클러스터 준비와 마이그레이션을 진행할 시간을 벌어줌

수조 개 메시지 마이그레이션

  • 마이그레이션 요구사항은 명확했음
    • 수조 개 메시지를 이전해야 함
    • 다운타임이 없어야 함
    • Cassandra가 여전히 잦은 장애 대응을 만들고 있어 빠르게 끝내야 함
  • Discord는 먼저 super-disk storage topology를 사용하는 새 ScyllaDB 클러스터를 구성함
    • Local SSD로 속도를 확보함
    • RAID로 데이터를 persistent disk에 미러링함
    • 로컬 디스크의 속도와 persistent disk의 내구성을 함께 얻는 구성이었음
  • 초기 계획은 cutover time을 기준으로 새 데이터는 ScyllaDB를 사용하고, 과거 데이터는 뒤에서 이전하는 방식이었음
  • 새 데이터는 Cassandra와 ScyllaDB에 이중 쓰기를 시작했고, 동시에 ScyllaDB의 Spark migrator를 준비함
  • Spark migrator는 많은 튜닝이 필요했고, 설정 뒤 완료 예상 시간은 3개월이었음
  • 이후 Discord는 기존의 빠른 데이터베이스 라이브러리를 확장해 Rust로 데이터 마이그레이터를 다시 작성함
    • 데이터베이스에서 token range를 읽음
    • SQLite로 로컬 checkpoint를 기록함
    • 데이터를 ScyllaDB로 대량 전송함
  • 새 Rust 마이그레이터의 예상 완료 시간은 9일로 줄었고, 이 속도 덕분에 복잡한 시간 기반 접근 대신 전체 전환을 한 번에 수행할 수 있었음

전환과 검증

  • 마이그레이션은 최대 초당 320만 개 메시지 속도로 진행됨
  • 진행률이 99.9999%에서 멈췄는데, 마지막 몇 token range에 Cassandra에서 compact되지 않은 거대한 tombstone 범위가 있었기 때문임
  • 해당 token range를 compact하자 몇 초 뒤 마이그레이션이 완료됨
  • Discord는 작은 비율의 읽기 요청을 두 데이터베이스 모두에 보내 결과를 비교하는 방식으로 자동 데이터 검증을 수행했고, 결과는 문제없었음
  • ScyllaDB 클러스터는 전체 프로덕션 트래픽에서도 잘 버텼고, Cassandra는 점점 더 잦은 지연 문제를 겪고 있었음
  • 팀은 현장에서 ScyllaDB를 primary database로 전환함

전환 이후 성능과 규모

  • 메시지 데이터베이스 전환은 2022년 5월에 이뤄짐
  • 이후 운영은 조용하고 안정적이었으며, 주말 내내 장애 대응을 하거나 uptime 유지를 위해 클러스터 노드를 계속 조정하는 상황이 없어짐
  • 노드 수는 177개 Cassandra 노드에서 72개 ScyllaDB 노드로 줄어듦
  • ScyllaDB 노드당 디스크 공간은 9TB였고, Cassandra 노드 평균 4TB보다 컸음
  • tail latency도 크게 개선됨
    • 과거 메시지 조회 p99: Cassandra 40~125ms → ScyllaDB 15ms
    • 메시지 삽입 p99: Cassandra 5~70ms → ScyllaDB 5ms
  • 성능 개선 덕분에 Discord는 메시지 데이터베이스에 대한 신뢰를 바탕으로 새로운 제품 사용 사례를 열 수 있었음

World Cup 트래픽에서 확인된 부하 처리

  • 2022년 말 World Cup 기간에 전 세계 사용자가 경기를 보면서 Discord의 메시지 전송 그래프에도 골 장면이 나타남
  • World Cup Final의 메시지 전송 그래프에는 경기 이벤트에 대응하는 여러 spike가 나타남
    • Messi의 페널티킥과 Argentina의 1-0 리드
    • Argentina의 추가 득점
    • 하프타임 동안 지속된 15분 plateau
    • Mbappe가 France를 위해 득점하고 90초 뒤 다시 득점해 동점을 만든 spike
    • 정규시간 종료와 연장전 진입
    • 연장 전반 하프타임 채팅
    • Messi의 추가 득점
    • Mbappe의 동점골
    • 연장 종료와 승부차기 진입
    • France의 실축과 Argentina의 우승
  • 메시지 전송량이 크게 증가한 상황에서도 Rust 기반 데이터 서비스와 ScyllaDB가 트래픽을 처리함
  • 최종 시스템은 수조 개 메시지를 처리할 수 있는 구조로 정리됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글은 가비지 컬렉션을 크게 탓하는 듯하지만, 이전 글 [0]을 보면 Cassandra 사용 방식이나 Cassandra의 대량 삭제 처리, 혹은 둘 다의 한계에 가까워 보임
    사용자가 API로 수백만 개 메시지를 지워 채널에 메시지 1개만 남겼고, Cassandra는 삭제를 tombstone으로 처리하기 때문에 사용자가 그 채널을 열 때 실제 메시지는 1개뿐이어도 수백만 개 tombstone을 스캔해야 했음. 그 과정에서 JVM이 수거할 수 있는 속도보다 더 빨리 가비지가 생겼다는 설명임
    또한 GC 튜닝 이야기가 나오지만 [1]을 보면 튜닝을 많이 한 것도 아니고, Cassandra와 아마 JVM도 오래된 버전을 쓰고 있었던 듯함. 방금 CMS에서 넘어온 상태였다는 점도 큼
    0) https://discord.com/blog/how-discord-stores-billions-of-messages

    1. https://news.ycombinator.com/item?id=33136453
    • 그래도 지금은 ScyllaDB를 쓰니 그 문제가 아예 걱정거리가 아니게 된 건 좋음
      원래 해법을 잘못 쓰고 있었다 해도, 잘못 쓰기 어려운 해법이 더 낫다고 봄
    • CMS에서 막 넘어왔다는 점이 꽤 흥미로움. CMS는 Java 9에서 G1GC로 대체된 뒤 Java 14에서 제거됐음
      2022년에 Java 11이라면 4년 된 런타임, Java 8이라면 8년 된 런타임을 쓰고 있었던 셈이라 성능을 꽤 많이 놓치고 있었을 가능성이 큼

  • Needs (2023)
    이 서비스 계층은 크고 화려한 분산 Varnish Cache처럼 보였음. 캐싱을 언급하지 않고 “coalesce”라는 단어를 고른 걸 보면 실제 캐싱은 많이 하지 않는 듯하지만, Varnish의 “grace mode”와 stampede를 막는 용도, 즉 내가 처음 ‘요청 병합(request coalescing)’을 들었던 맥락이 떠올랐음 https://varnish-cache.org/docs/6.1/users-guide/vcl-grace.htm...
    또 일관 해싱이 계속 등장하는 것도 반가움. 비슷한 상황에서 유용성이 입증된 훌륭한 덕트테이프 같은 기술임. 어떤 것이 어디 있어야 하는지 알면, 모두가 어디로 찾으러 올지도 알 수 있음

    • 그런 개념은 보통 요청 병합이나 “origin shielding”이라는 표현이 더 흔한 듯함. “grace”는 오늘 처음 들어봄
    • grace mode 자체가 stampede를 막지는 않음. Varnish는 모든 요청을 자동으로 병합하고, grace mode는 클라이언트가 캐시된 응답을 받을 가능성을 높이는 데 쓰임. 다만 그 응답은 오래된 것일 수 있음
    • Nginx는 언제나 더 사무적임
      proxy_cache_use_stale updating;

  • ScyllaDB 공동창업자가 덧붙인 내용이 몇 가지 있음: Discord는 Cassandra로 repair를 완료할 수 없었지만 Scylla에서는 그렇지 않았고, Scylla는 LSM 트리와 compaction 등 Cassandra와 공통점이 많지만 고유한 CPU/IO 스케줄러로 질의에 compaction보다 높은 우선순위를 줄 수 있음
    유휴 대역폭이 충분한 반 밀리초에 compaction을 미룰 수 있고 관련 글도 많다고 함. Scylla에는 1.5년 된 tombstone_gc=repair라는 더 안전한 모드가 있으며, 최근 출시된 Raft와 tablets 기반 새 아키텍처가 사용자들에게 다음 큰 변화라고 함

  • 이런 문제는 40년 넘게 존재해 온 분산 채팅 프로토콜인 IRC를 썼다면 애초에 없었을 것임
    공개 명세와 여러 구현체가 있다는 장점도 있음. 벽으로 둘러친 정원도 아님. IRC가 현대에 너무 낡았다고 생각한다면 Matrix나 XMPP를 보면 됨. Discord가 어떻게 장악하게 됐는지 이해하기 어렵고, 차라리 비극에 가까움

    • IRC는 메시지를 저장하지 않고 클라이언트로 중계만 함. 채팅 기록을 저장하려면 별도 해법이 필요하고, 이는 약 30년 동안 당연하게 여겨 온 기능임
      IRC는 여러 기기에서 대화를 따라가려면 사실상 바운서를 요구함. 메시지를 암호화하지도 않고, 선택적으로 클라이언트와 서버 연결만 암호화함. 종단 간 암호화가 없으면 서버나 운영자에 대한 프라이버시가 없고, 그 서버는 쉽게 표적이 되는 단일 장애점임
      Matrix 프로토콜은 아직 변하는 중이고 구현체는 명세를 따라가지 못함. Element를 쓰지 않으면 기능과 보안에서 뒤처짐. XMPP도 IRC처럼 종단 간 암호화 같은 기본 기능을 선택적 확장에 의존하고, 클라이언트가 이를 완전하고 올바르게 지원하지 않을 수 있음
      soatok의 분석을 읽어보는 걸 추천함: https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
      2013년 Snowden 사건은 11년 전 일임. 이제 종단 간 암호화는 기본 기능이자 상품처럼 취급되어야 하고, HTTPS를 요구하던 것만큼 끈질기게 요구해야 함. 물론 Discord는 종단 간 암호화를 구현하지 않음
    • Discord가 왜 장악했는지 이해 못 한다는 사실 자체가 Discord가 장악한 이유임. 사용자 경험이 10배는 더 좋고, 일반 비기술 사용자에게 적합하다는 점을 인정하지 못하는 것임
    • IRC를 아주 좋아하고 Discord는 싫어하지만, 다른 서비스들은 너무 투박하고 IRC도 요즘은 그나마 괜찮은 모바일 앱이 있는 IRCCloud를 통해서야 쓸 만함
      최근 내가 속한 매우 기술적인 그룹이 Telegram에서 Matrix로 옮겼는데 사용자 경험이 좋지 않음. 앱은 버그가 있고 보기에도 별로이며, 새 “Element” 앱에서는 SSO가 지원되지 않아 계정을 쓸 수 없었음. 나처럼 직접 파고드는 사람에게는 괜찮은 작은 불편들이지만, 친구들에게 쓰라고 설득할 수는 없겠음
    • 당시 경쟁 제품보다 몇 자릿수는 더 나은 제품이었기 때문임
    • 사용성 때문임
      exe를 내려받고 설치하고 계정을 만들면 바로 실행됨. 누구나 할 수 있음. 유용하고 훌륭한 소프트웨어는 많지만 대부분은 일반 대중에게 쉽지 않고, 일부 혹은 대부분은 GUI조차 없음. 사람들은 너무 많은 단계를 견디기보다 자신의 신원을 팔고 심지어 돈도 내는 쪽을 택함

  • 이 글에서 내가 얻은 결론은 저자 의도와 조금 다를 수 있음
    “마지막 하나? 우리의 친구 cassandra-messages. [...] 시작부터 큰 클러스터였다. 수조 개 메시지와 거의 200개 노드가 있었으니 어떤 마이그레이션도 복잡한 작업일 수밖에 없었다.”
    Discord 규모를 생각하면 메시지 저장소에 노드 200개 미만은 놀라울 정도로 작아 보임. 훨씬 더 빠른 확장성을 목표로 하고 움직이는 부품이 더 많은 복잡한 아키텍처를 예상했음. 실제 복잡도는 글에 나온 것보다 높겠지만, 내가 더 적은 일을 하는 200대 넘는 물리 노드를 부분적으로 책임졌던 경험을 떠올리면 현대 클라우드 아키텍처가 얼마나 과잉 설계되는지 궁금해짐

    • 여기서 말하는 건 데이터베이스 노드 177개이고, 이 숫자만으로 아키텍처 복잡도를 판단할 수는 없음. 여러 지역에 걸쳐 고가용성 노드 여러 개로 구성된 서비스가 수십에서 수백 개 있을 것이라 봄
      훨씬 작은 Cassandra 노드 집합으로 수십억 개 레코드를 저장해 본 입장에서, Cassandra는 온콜에 정말 고통스러운 존재였고 몇 차례 큰 장애의 원인이었음
    • 현대 클라우드 아키텍처 대부분은 과잉 설계일 가능성이 크다고 봄. 이와 반대쪽 예시로는 Stack Overflow 아키텍처[0]가 떠오름
      [0] https://news.ycombinator.com/item?id=34950843
    • 이제는 같은 일을 72개 노드만으로 하고 있다는 점도 고려해야 함

  • 글이 아주 잘 쓰였음. 해법의 일부가 완전히 다른 무언가를 도입하는 게 아니라, Cassandra의 대체품처럼 쓸 수 있는 ScyllaDB로 바꾸는 것이어서 다행임

  • Discord는 예전 메시지를 삭제하는 걸 사실상 불가능하게 만듦. 프라이버시 악몽이고, EU가 왜 개입하지 않았는지 의문임

    • 균형이 필요하다고 봄. 직접 전달되는 커뮤니케이션에서는 오래된 메시지의 수신자도 이해관계자이고, 기본적으로 일관된 기록을 유지하는 것이 그들이 제공하는 “서비스”의 근본적인 부분이기 때문임. 메시지 내용은 클릭 패턴을 몰래 긁어모으는 것과는 다름. Matrix도 같은 질문을 마주했을 때 고민한 내용이 있음
      핵심 질문은 Matrix를 이메일에 더 가깝게 봐야 하는지, 아니면 Facebook에 더 가깝게 봐야 하는지로 압축됨. 이메일이라면 보낸 사람이 내 메일 스풀에서 자기 메시지를 지울 수 있다는 데 사람들이 경악할 것이고, Facebook이라면 삭제권을 행사한 뒤에도 게시물이 어딘가에 보인다는 데 사람들이 경악할 것임
      이를 해결하려면 판단이 필요하고, GDPR의 정신이 실제로 무엇을 달성하려는지 먼저 고려하는 방식으로 접근했다는 설명임
      https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix...
    • Discord 문화에서는 사용자가 “소개” 메시지에 이미지, 구체적 취미, 의료 정보 같은 개인식별정보를 엄청나게 많이 올리는 편임. 예를 들면 “지원” 커뮤니티 같은 곳임
      GDPR 관점의 문제는 Discord가 이를 삭제하기 어렵게 만든다는 것임. 계정 데이터 삭제 의도를 감지하면 “익명화” 쪽으로 유도하고, 공개적으로는 사용자명이 메시지와 분리되지만 여전히 특정 인물로 추적될 수 있음. 서버 쪽에서도 이렇게 처리된다면, 사용자의 개인식별정보 삭제 요구를 집행하려면 엄청난 메시지를 훑거나 과거 메시지를 대량 삭제해야 하는 상황이 됨
      EU 의회는 새 법안을 위원회만 제안할 수 있고 선출된 의회는 대체로 표결만 한다는 점에서 진짜 의회가 아니며, 위원회를 통제하는 것은 대중이 아니라 미국 국무부라고 봄. Newsguard와 Musk가 아닌 미국 빅테크, Discord도 같은 정치·금융적 기득권 네트워크에 있으며 전직 국무부 인력이 많음
      대중적 분노가 없으면 EU 차원의 기관은 장악될 가능성이 높고, 여론도 불법 Discord 데이터로 LLM을 훈련하고 선거 광고를 겨냥하는 사이버펑크식 기득권이 통제한다고 봄. 결국 영구적인 기득권에서 벗어날 수 없는 Orwell식 상태가 올 수 있다는 점을 걱정해야 한다고 봄
      다만 이 대부분은 넓은 의미에서 맞을 확률을 50% 이상 정도로만 보고 있으니 많이 걸러 들어야 함
    • 수집·처리되는 사용자 데이터의 규모와 범위를 생각하면 EU가 조용히 큰 사건을 준비하고 있을 수도 있음

  • Cassandra는 본질적으로 대부분 추가만 하는 분산 내결함 해시 테이블에 가까움. 높은 쓰기 처리량으로 정확히 그런 것이 필요하다면 좋은 선택임
    사람들이 왜 이를 데이터베이스처럼 쓰는지 이해가 안 됨. 한계에 바로 부딪히고, 데이터베이스처럼 쓰려는 고통은 규모가 커질수록 더 심해짐

    • 글에 “Cassandra에서는 읽기가 쓰기보다 비싸다”고 되어 있음
      이러면 채팅 서버의 메시지 저장소로는 말이 안 된다고 봄. 분산 시스템의 로그 수집 목적지, 즉 많은 클라이언트가 데이터를 쏟아 넣지만 대부분은 로그를 감사할 필요도 없어서 특정 항목의 읽기 횟수가 1보다 적은 경우에는 적합해 보임. Discord 메시지는 명백히 그렇지 않음
    • Cassandra 문서와 웹사이트는 모두 이를 데이터베이스라고 말함. 사람들이 헷갈리는 걸 탓할 수는 없음
      내 경험상 Cassandra를 쓰기 시작한 프로젝트가 1년쯤 지난 뒤에도 계속 쓰는 걸 본 적이 없음. 한계에 부딪히는 데 1년 정도 걸리고, 결국 Postgres 같은 데이터베이스로 교체하게 됨

  • 왜 그냥 샤딩을 못 하는지 모르겠음. Discord의 각 ‘서버’는 서로 격리되어 있지 않나? 서로 메시지를 보낼 수 없다면, 수조 개 메시지를 수천 개 샤드로 나눠 각 샤드가 수십억 개씩 처리하게 하면 안 되는지 궁금함

    • 파티션 키에 채널 ID가 포함되어 있었고, 그렇게 세분화된 샤딩을 했어도 핫 파티션 문제가 계속 있었음
    • 마지막으로 Discord 봇 API를 봤을 때는 명시적으로 샤딩 관련 조항이 있었음

  • “ScyllaDB 팀은 개선 작업을 우선순위에 두고 성능 좋은 역방향 질의를 구현해, 마이그레이션 계획의 마지막 데이터베이스 장애물을 제거했다”고 되어 있음
    ScyllaDB를 쓰기도 전에 이걸 해달라고 얼마나 지불했을지 궁금함

    • 글에 따르면 메시지 저장소 마이그레이션을 하기 2년 전부터 이미 메시지 저장소를 제외한 모든 곳에서 ScyllaDB를 쓰고 있었음
답변달기