디스코드는 어떻게 Elixir로 500만명의 동시 접속자를 처리했을까?

이 글은 디스코드 블로그의 'How Discord Scaled Elixir to 5,000,000 Concurrent Users?'를 읽고 정리한 글입니다. 저의 이해를 위해 원문에는 없는 추가적인 내용이 포함되어 있으며, 잘못 해석한 부분이 있을 수 있습니다.

 

0. 들어가기에 앞서

• 디스코드란?
  • 실시간 채팅 애플리케이션. 음성 채팅, 텍스트 채팅 등이 가능
  • 높은 동시성이 필요한 실시간 시스템 → Elixir와 Erlang VM을 선택
• Elixir와 Erlang VM이란?
  • Elixir(엘릭서): 프로그래밍 언어의 일종으로, 대용량 분산 시스템을 만드는 데 적합하다.
  • Elixir는 동시성을 지원하며, 오류가 발생해도 시스템이 멈추지 않고 동작한다.
  • Java가 JVM 위에서 실행되는 것처럼, Elixir는 Erlang VM 위에서 실행된다.
  • 디스코드는 수백만명이 동시에 접속해도 빠르게 메세지를 주고받을 수 있어야 하기 때문에, 동시성 프로그래밍에 강점을 가진 Elixir를 선택한 것으로 보임

---

1. 메세지 팬아웃(Message Fanout)

• 디스코드에서 대부분의 핵심 로직은 발행/구독(pub/sub) 모델을 기반으로 동작
• 사용자가 WebSocket을 이용하여 연결되면 세션 프로세스가 생성된다.
  • 세션 프로세스는 원격 Erlang 노드와 통신하는데, 이 노드 안에는 GenServer로 만들어진 길드 프로세스가 존재한다.
  • 길드란 디스코드에서 말하는 '서버'로, 1명의 사용자는 여러 길드에 속할 수 있다.
  • 디스코드는 길드 프로세스를 사용해서 각 길드를 관리한다.

💡GenServer란?
  - Elixir의 OTP(Open Telecom Platform) 프레임워크에서 제공하는 동시성 프로그래밍 모듈
  - Elixir에서는 각 프로세스가 독립적으로 실행되며 메세지를 주고받는데, GenServer는 프로세스 생성, 메세지 처리 등의 구현을 도와준다.
  - 레스토랑의 서빙 로봇과 비슷한 느낌. 서빙 로봇이 주문을 받아 주방에 전달하고 요리가 나오면 알아서 서빙해주듯이, GenServer는 Elixir에서 데이터 저장 등의 작업을 처리해준다.
  - GenServer를 사용하면 여러 명이 동시에 요청했을 때 요청 순서 등을 관리하기 용이하다.

• 사용자는 온라인 상태가 되면 길드에 연결되고, 길드는 해당 사용자가 접속했음을 연결된 세션에 알린다.
  
  • 디스코드 초기, 25명 이하의 소규모 그룹을 위해 개발할 때는 문제가 없었던 로직

# 세션에 연결된 모든 사용자에게 message를 전달하는 함수
def handle_call({:publish, message}, _from, %{sessions: sessions}=state) do
	Enum.each(sessions, &send(&1.pid, message))
	{:reply, :ok, state}
end

• 그러나 디스코드가 대규모 그룹을 위한 서비스로 발전하면서 문제 발생
  • /r/Overwatch 서버에는 최대 3만명의 동시 접속자 발생
  • 피크 타임에는 프로세스가 메세지 큐를 감당하지 못하기 시작
  • 어느 순간부터는 서버 과부하를 막기 위해 메세지를 생성하는 일부 기능을 수동으로 비활성화
  • 수동으로 기능을 비활성화하는 것이 일시적 작업이 아닌 풀타임 잡이 되기 전에 근본적인 해결책을 찾아야 했음
• 길드 프로세스 내에서의 핫 패스(hot path, 성능 병목이 발생하는 핵심 코드 경로)를 벤치마킹하며 문제 원인 탐색
  • 문제: Erlang 프로세스 간 메세지를 보내는 비용이 생각보다 비쌈
  • 프로세스가 send/2 함수를 호출할 때마다 해당 프로세스를 비활성화(de-scheduling)했다가 다시 활성화(scheduling)함
    • 프로세스는 blocked될 때마다 대기열의 맨 끝으로 감 → 프로세스의 작업 수행 속도 저하
  • 각 send/2의 호출 실행 시간이 30μs ~ 70μs에 달함
  • 피크 타임에 대형 길드에서 이벤트를 발행하면, 메세지 팬아웃 때문에 전체 전송 시간이 최대 900ms ~ 2.1초까지 소요
  • Erlang 프로세스는 기본적으로 싱글 스레드 → 병렬 처리를 위해서는 프로세스를 샤딩(sharding)해야 함
• 프로세스 샤딩은 복잡하므로, 대신 메세지 전송 작업을 분산하기로 결정
  • Erlang에서 프로세스를 생성하는 작업은 저렴하기 때문에, 처음에는 각 메세지 발행을 개별 프로세스로 실행하는 방법을 고려
    • 각 메세지 발행이 서로 다른 시점에 실행되면 이벤트 순서 보장(linearizability)이 깨질 위험이 있었음
    • 길드 서비스의 전체 작업량도 지속적으로 증가하는 상황 → 해당 방법은 확장성이 떨어짐
      • 사용자가 많아지면 프로세스 개수도 함께 증가 → 관리 어려움, CPU/메모리 사용량 증가
      • 각 프로세스가 개별적으로 메세지를 보냄 → 네트워크 트래픽 증가
• 결론: 노드 간 메세지 전송 성능을 향상시키는 블로그 포스팅에 착안하여, Manifold를 개발함
  • Manifold는 같은 노드에 있는 PID끼리, 즉 같은 서버에 있는 프로세스를 기준으로 그룹을 만든다.
  • 예를 들어 A 노드에 30명, B 노드에 20명, C 노드에 50명이 있다고 가정
    • 이전에는 send/2 함수를 30 + 20 + 50 = 100번 호출
    • 하지만 이제는 각 노드별로 한 번씩만 send/2 함수 호출 → 3번 호출. 네트워크 부하 감소
    • 각 노드들은 자신이 받은 메세지를 내부 프로세스에게 전송함
    • 같은 노드 내에서는 프로세스 간 통신에 네트워크가 아닌 Erlang VM을 이용 → 메모리에서 처리될 뿐 네트워크 트래픽 발생 X
  • 각 노드에서는 Manifold.Partitioner가 PID들을 코어 수에 맞게 분배
    • 모든 메세지를 한 프로세스가 처리하면, 해당 프로세스만 과부화됨
    • Manifold.Partitioner는 코어 수에 맞게 PID를 나눠주어 각 프로세스의 메세지 처리량을 고르게 분배 

    Manifold.send([self(), self()], :hello)

• 도입 효과
  • CPU 부하 감소: 메세지 팬아웃 비용을 여러 프로세스로 분산
  • 네트워크 트래픽 감소: 노드 간 불필요한 데이터 전송 줄임
    • 기존에는 각 유저의 프로세스(PID)마다 send/2 호출 → 100명의 유저에게 100번 메세지 전송
    • Manifold 도입 후에는 노드 단위로 메세지 전송 → 원격 노드를 기준으로 3번 호출
  • 대체 용이: send/2 함수 호출을 Manifold로 대체하기만 하면 됨

---

2. 공유 데이터에 빠르게 접근하기

• 디스코드는 안정 해시(Consistent Hashing)을 사용해 요청을 각 노드에 고르게 분배하는 분산 시스템을 구축
  • 해시 링 구조를 이용해 데이터를 저장할 노드를 결정하는 방식
  • 초반에는 빠른 처리를 위해 Erlang C 포트를 이용한 라이브러리를 사용
  • 하지만 디스코드가 확장되면서 성능 이슈가 발생함
• 유저가 갑자기 많이 접속하는 순간, 해시 링을 관리하는 Erlang 프로세스가 너무 바빠져서 요청을 처리하지 못하고 전체 시스템이 느려지는 문제 발생
  • 처음에 고안한 해결 방법: 시스템 코어를 이용해서 해시 링 관리 작업을 여러 프로세스로 나눠 처리하면 되지 않을까?
  • 하지만 해당 부분은 hot path였기 때문에 성능이 충분히 개선되지 않았음
• 문제: 사용자가 자신이 속한 서버 정보를 조회하는 작업이 너무 오래 걸림
  • 사용자는 평균적으로 5개의 길드(디스코드 서버)에 속해 있음
  • Erlang VM 1개는 최대 50만 개의 세션을 관리할 수 있음
  • 세션이 연결될 때마다 사용자가 속한 모든 길드의 원격 노드를 조회해야 함
  • 사용자가 속한 길드 데이터가 들어있는 원격 노드를 찾는 작업을 최대 50만개의 세션이 동시에 진행하면 부하가 급증
  • Erlang 프로세스 간 커뮤니케이션 비용은 12μs
  • 세션이 재시작되면 해시 링을 조회하는 데만 30초가 소요됨
• 첫 번째 해결 방법: ETS 사용하기
  • ETS(Erlang Term Storage): C로 구현된 빠르고 수정 가능한 딕셔너리
  • 문제점: ETS에 데이터를 저장할 때마다 데이터를 복사해야 함 → 성능 개선 미미
  • 해시 링 자료구조가 꽤 커서 ETS에 데이터를 저장하기 위해 데이터를 복사하는 비용이 컸음
  • ETS에서의 조회 속도는 약 7μs였지만, 해시 링 조회에는 여전히 17.5초 소요 → 성능이 충분히 개선되지 않음
• 두 번째 해결 방법: mochiglobal 모듈 사용하기
  • mochiglobal은 Erlang VM의 기능을 활용하여 데이터를 read-pnly shared heap에 저장해줌
  • mochiglobal을 사용하면 프로세스들은 데이터 복사 없이도 데이터에 접근할 수 있음
  • mochiglobal은 데이터를 변수가 아니라 함수로 만들어서 공유 메모리에 저장하는 방식이기 때문
  • 데이터 탐색 비용을 0.3μs로 절감 → 전체 조회 시간이 750ms로 단축됨
  • 단점: 자료구조가 너무 크면 해당 함수를 갖는 Erlang 모듈을 생성하는 데 최대 1초 소요
  • 해시 링을 자주 수정하지는 않기에 감당 가능한 단점이었음
• mochiglobal을 Elixir로 포팅하고, atom이 생성되지 않도록 기능을 추가하여 FastGlobal 개발
  • mochiglobal은 Erlang을 기반으로 만든 기술이었기에, Elixir에서 사용하려면 포팅이 필요했음
  • 아톰이란?
    • Erlang과 Elixir에서 사용하는 특수한 타입으로, 일종의 고정된 이름을 가진 값
    • :ok, :error, :start 등
  • 아톰은 한번 생성되면 절대 삭제되지 않기 때문에, 너무 많이 만들면 메모리가 다 차서 프로그램이 죽어버림

---

3. 제한된 동시성 (Limited Concurrency)

• 노드 조회(lookup)에서 발생하는 hot path 문제를 해결한 뒤, 각 길드 노드의 PID를 찾는 프로세스들이 지연되고 있음을 발견함
• 이전에는 길드 노드를 찾는 속도가 느려서 요청이 천천히 들어왔지만, 노드 조회 속도가 빨라지면서 문제가 드러난 것
• 새로운 문제: 약 500만 개의 세션 프로세스가 한꺼번에 10개의 길드 조회 프로세스에 요청을 보내기 시작함
  • 길드 조회 프로세스는 길드 노드 당 1개씩 존재
  • 근본적인 문제 원인
    • 세션 프로세스가 길드 레지스트리에 요청을 보냄
    • 길드 레지스트리는 바빠서 제때 응답하지 못하고, 요청을 보낸 세션 프로세스는 timeout됨
    • 세션 프로세스는 backoff 후 요청을 다시 보내지만, 요청이 지속적으로 길드 레지스트리의 큐에 쌓여 복구할 수 없는 상태가 됨
    • 세션프로세스는 길드 레지스트리의 응답을 기다리며 block되므로 다른 서비스로부터 온 메세지도 처리할 수 없음
    • 세션 프로세스의 메세지 큐가 점점 커져서 결국 Erlang VM 전체가 Out Of Memory로 다운됨 → 연쇄적인 서비스 장애가 발생
• 이상적인 해결책
  • 요청 실패가 불가피한 경우, 길드 레지스트리에 아예 요청을 보내지 않도록 프로세스를 더 똑똑하게 만들기
  • 서킷 브레이커를 사용할 수도 있었지만, 디스코드 팀은 서킷 브레이커를 사용하고 싶지 않았음
  • timeout 발생이 급증하는 경우, 일정 시간 동안 모든 요청이 차단되는 상태를 원치 않았기 때문
  • 다른 언어에서는 이러한 문제를 어떻게 해결하는지 알고 있었지만, Elixir에서는 어떻게 해결하는지 알아내야 했음
    • 다른 언어에서는 atomic 카운터를 사용하여 현재 처리 중인 요청 수를 추적하는 방식을 이용
    • 현재 처리 중인 요청 수가 너무 많으면 미리 요청을 취소하는 방식으로 semaphore를 구현했음
    • 보통 semaphore는 공유 메모리 기반으로 구현
    • 하지만 Elrang VM은 프로세스 간 통신을 중심으로 동작하기 때문에, 현재 진행중인 요청 개수를 공유하기 위해 별도의 메세지 통신이 필요했음
• Elrang VM에서도 프로세스 간 메세지 통신을 기반으로 세마포어를 구현할 수 있었지만, 디스코드 팀은 요청 개수 조정을 위해 프로세스를 과부하시키고 싶지 않았음
  • 각 프로세스는 독립적으로 실행되므로, 서로 공유하는 메모리가 없고 모든 데이터는 메세지를 통해 전달됨
  • 따라서 Elrang VM에서 세마포어를 구현하려면 진행중인 요청 개수를 확인하는 작업을 담당하는 프로세스가 필요함
  • 이 작업을 하나의 프로세스가 담당하면 너무 많은 요청이 몰려 해당 프로세스가 과부하될 수 있음
  • 세션 프로세스는 수백만 개가 존재하고, 세션 프로세스가 길드 정보를 요청할 때마다 '현재 진행중인 요청 개수'를 확인해야 하기 때문
• 디스코드 팀은 중앙 프로세스 대신, ETS같은 인메모리 데이터베이스에서 요청 개수를 관리하는 방법을 선택
  • :ets.update_counter/4 기능 이용
  • 해당 기능은 ETS 내의 값을 원자적으로 증가시키는 연산을 수행하는 동시에 현재 값을 반환함
  • 추가적인 읽기 연산 없이 카운터 값을 바로 확인할 수 있어 다중 프로세스 환경에서도 안정적으로 사용할 수 있음
  • 또한 ETS를 write_concurrency 모드로 실행하여 높은 동시성을 확보 → 여러 프로세스가 하나의 데이터에 동시 접근해도 내부적으로 최적화되어 병렬 처리 가능
• 위 방법을 기반으로 세마포어(semaphore) 라이브러리 제작
  • 쉽게 사용할 수 있고, 높은 처리량 환경에서도 뛰어난 성능을 발휘함
  • 연쇄적인 장애로부터 디스코드의 Elixir 인프라를 보호해줌
  • 실제로 접속 상태 관리 서비스가 관련없는 이슈로 인해 중단되었지만, 세션 서비스는 영향을 받지 않았으며 접속 상태 관리 서비스도 몇 분 내로 재시작됨

semaphore_name = :my_semaphore
semaphore_max = 10
case Semaphore.call(semaphore_name, semaphore_max, fn -> :ok end) do
	:ok ->
		IO.puts "success"
	{:error, :max} ->
		IO.puts "too many callers"
end