왜 Discord는 스택을 계속 재작성하는가

Source: Dev.to

Discord는 스택을 여러 번 재작성했습니다.
잘못된 것이 아니라, 구축한 것이 한계에 다다랐기 때문입니다.

2013 — 시작 스택

• Elixir – 실시간 메시징
• Python – API
• Go – 마이크로서비스
• MongoDB – 스토리지
• Electron – 데스크톱

표준 스타트업 선택. 빠르게 배포하고, 나머지는 나중에 해결.

2017 — MongoDB를 포기해야 했음

• 5 백만 명의 사용자; MongoDB가 감당하지 못함.
• Cassandra (12노드)로 전환 – 문제 없이 동작.
• 2022년에는 클러스터가 177노드로 성장; 유지보수가 어려워지고 비용이 상승.
• ScyllaDB로 이전.

한 문제. 9년. 3개의 데이터베이스.

2019 — Elixir가 모든 작업에 충분히 빠르지 않음

Elixir에서 대용량 데이터 세트를 정렬하는 데 170 ms가 걸렸습니다.
Discord 규모에서는 이는 받아들일 수 없었습니다.

• 해당 컴포넌트를 Rust로 재작성.
• 지연 시간이 1 ms로 감소.

이것이 전환의 전부 이유였습니다.

2020 — Go의 가비지 컬렉터가 적이 됨

Discord의 Read States 서비스는 사용자가 읽은 모든 메시지를 추적하며, 모든 앱 상호작용 시 호출됩니다.

• Go의 가비지 컬렉터가 2 분마다 실행되어 전체 메모리를 스캔.
• 수백만 명의 사용자를 캐시하고 있으면 스캔으로 인해 지연이 급증.

튜닝과 Go 업그레이드 시도는 실패.

• 서비스를 Rust로 재작성 (GC 없음, 즉시 메모리 해제).
• 지연 시간이 밀리초에서 마이크로초 수준으로 감소.

팬데믹으로 월간 활성 사용자가 1억 명에 달하면서 Rust 재작성은 운이 아니라 필수가 되었습니다.

절대 바꾸지 않은 것들

• Elixir는 여전히 실시간 메시징을 담당; BEAM VM은 수백만 개의 동시 프로세스와 즉각적인 재시작에 강점.
• Python은 여전히 API를 구동.
• Electron은 여전히 데스크톱 클라이언트를 실행.
• React Native는 수년간 별도 코드베이스를 유지한 뒤 iOS와 Android를 통합.

모든 것이 바뀔 필요는 없습니다.

그 뒤에 숨은 패턴

각 전환은 특정 트리거—임계값을 초과한 메트릭—에 의해 이루어졌으며, 튜닝만으로는 해결할 수 없었습니다.

• 유행 때문에 전환한 적은 없습니다. 일찍 전환한 적도 없습니다.

교훈은 어느 언어나 데이터베이스가 최고인지가 아니라, 작동하는 것을 사용하고, 수치가 요구할 때 전환하며, 왜 전환하는지를 이해하는 것입니다.

Discord는 첫날에 5억 사용자를 위해 구축하지 않았습니다. 그들은 오늘을 위해 만들고 내일을 위해 고쳤습니다.

또한 Medium에도 게시되었습니다.