discord-blog

문제Discord는 2017년 구축한 Elasticsearch 검색 인프라가 200개 노드 이상으로 확장되며 Redis 큐 백업, Lucene 20억 메시지 한계, 노드 장애 시 배치 전체 실패 같은 문제에 부딪혔다.

접근200개 단일 클러스터를 40개 셀(Cell) 기반 다중 클러스터로 쪼개고 Elastic Kubernetes Operator로 운영을 자동화했다. Redis 큐는 Google Cloud PubSub로 전환했고, Rust MessageRouter로 동일 노드 대상 메시지를 묶어 배치 인덱싱한다.

결과인덱싱 처리량 2배 증가, 중앙값 쿼리 지연이 500ms에서 100ms 미만으로, p99는 1초에서 500ms 미만으로 줄었다. 트릴리온 규모 메시지를 무중단으로 운영한다.

문제Discord 데이터 팀은 100명이 넘는 개발자가 2,500개 이상의 dbt 모델을 동시에 작업하면서 컴파일 시간 20분, 테스트 테이블 충돌, 페타바이트 리프레시 비효율 같은 한계에 부딪혔다.

접근`generate_alias_name` 매크로로 개발자별 테이블 네이밍을 자동 분리하고, `is_incremental()` 대신 시간 기반 처리와 BigQuery 파티션 복사를 도입했다. 시맨틱 버저닝으로 백필 범위를 정밀 제어한다.

결과모델 빌드 속도가 5배 빨라지고 컴파일 시간이 수 초로 단축됐다. 프로덕션 장애가 줄고 저장·처리 비용도 함께 감소했다.

문제Discord는 수십억 개 이미지를 처리하지만 GIF의 256색 제한과 비효율적 압축, 이진 투명도만 지원하는 한계로 성능과 품질 모두 떨어졌다.

접근Lilliput 이미지 처리 라이브러리에 WebP·AVIF 지원을 추가하고, iOS는 Apple ImageIO 대신 libwebp를 사용했다. libyuv·aom·libavif 의존성을 더해 Web → Mobile 순서로 단계 배포했다.

결과응답 크기 중앙값이 31.3KB에서 22.1KB로 29% 줄고, p95는 228KB에서 131KB로 42% 줄었다. 애니메이션 이모지의 95% 이상이 WebP로 전환됐다.

문제많은 서버에 가입한 Discord 모바일 파워 유저는 메모리 사용량과 프레임 드롭, 채팅 스크롤 지연, 이모지 피커 블랭킹 같은 성능 문제를 겪었다.

접근서버 리스트를 가상화해 화면 밖 항목을 메모리에서 제거하고, Android 이모지 피커는 React Native에서 네이티브로 다시 만들었다. RecyclerView 기반 FastestList와 View Portaling 기법으로 블랭킹을 해소했다.

결과서버 100개 이상 유저의 메모리 사용 14%, 시작 시간 10% 줄었다. 느린 프레임이 60% 감소했고, 저사양 기기에서도 60fps WebP 애니메이션이 돌아간다.

문제Discord 데스크톱 앱은 2015년부터 32비트로 운영돼 4GB 메모리 상한에 걸렸고, 리소스가 큰 게임과 같이 실행될 때 메모리 부족 크래시가 잦았다.

접근64비트 빌드 자동화와 서명 파이프라인을 구축하고 C++·Rust 간 ABI 호환성을 맞췄다. 기존 업데이터에 아키텍처 감지 로직을 넣어 32비트 클라이언트가 자동 전환되고, 문제 시 32비트로 롤백한다.

결과Windows 64비트 머신 100%가 무중단으로 전환됐다. CPU 사용률과 크래시율이 떨어지고, 게임 등 다른 앱에 더 많은 자원을 양보할 수 있다.