Mozilla의 Rust가 어떻게 (새 탭에서 열림)
Figma는 TypeScript 기반 멀티플레이어 서버의 예측 불가능한 지연 문제를 해결하기 위해 성능에 민감한 부분을 Rust로 재작성했다. Rust 프로세스를 문서별로 분리하고 병렬 처리한 결과, 메모리 사용량을 크게 줄이고 직렬화 성능을 10배 이상 개선했다. 다만 Rust 생태계와 언어 자체의 성숙도가 낮아 전체 서버를 Rust로 전환하지 않고 핵심 성능 영역에만 적용했다. ## TypeScript 서버의 확장성 문제 - Figma의 멀티플레이어 서버는 고정된 수의 머신과 워커로 구성되며, 각 문서는 하나의 워커에 전적으로 할당됐다. - 기존 서버는 TypeScript와 Node.js 기반의 단일 스레드 구조였다. - 문서 인코딩처럼 오래 걸릴 수 있는 작업이 실행되면 해당 워커 전체가 차단됐다. - 일부 대형 문서만 문제를 일으켰지만, 같은 워커에 연결된 다른 모든 문서의 동기화도 지연됐다. - 하드웨어를 추가해도 단일 워커 내부의 작업 차단 문제는 해결되지 않았다. - 문서마다 별도의 Node.js 프로세스를 실행하는 방식은 JavaScript VM의 메모리 오버헤드가 커서 현실적이지 않았다. ## 임시 대응과 한계 - Figma는 문제가 큰 문서를 별도의 “heavy worker” 풀로 수동 이동했다. - 이 방식으로 서비스 장애를 방지할 수는 있었지만, 문제가 되는 문서를 계속 찾아서 재배치해야 했다. - 문서 특성에 따라 운영자가 직접 관리해야 하므로 확장성과 자동화 측면에서 한계가 있었다. ## Rust 기반 아키텍처 - 성능에 민감한 멀티플레이어 서버 일부를 별도의 자식 프로세스로 분리했다. - 자식 프로세스는 Rust로 작성했으며, 기존 호스트 프로세스와 표준 입력(stdin)·표준 출력(stdout)으로 통신했다. - Rust 프로세스는 기존 시스템보다 메모리를 훨씬 적게 사용했다. - 그 결과 문서별로 별도의 프로세스를 실행해 모든 문서를 완전히 병렬화할 수 있었다. - 특정 대형 문서의 느린 작업이 다른 문서의 동기화를 차단하지 않게 됐다. - 문서 직렬화 시간은 기존보다 10배 이상 빨라졌다. ## 운영 성능 개선 - 점진적 배포를 통해 Rust 기반 시스템을 단계적으로 확대했다. - 전체 배포가 완료된 시점에 서버 성능 지표가 크게 개선됐다. - 개선 효과는 주로 서버 내부 성능에 해당하며, 클라이언트 기능 자체가 빨라졌다기보다 서버가 부하 상황에서도 안정적으로 동작하도록 만든 것이다. - 결과적으로 대형 문서나 느린 작업 때문에 전체 사용자가 겪던 동기화 지연과 서비스 품질 저하가 완화됐다. ## Rust를 선택한 이유 - Rust는 C++에 가까운 성능과 낮은 수준의 메모리 제어 능력을 제공한다. - 가비지 컬렉터가 없어 메모리 사용량과 지연을 더 세밀하게 제어할 수 있다. - 타입 시스템이 C++에서 흔한 여러 종류의 버그를 자동으로 방지한다. - 저수준 성능과 서버 언어 수준의 안전성을 함께 확보할 수 있다는 점이 선택의 핵심이었다. - 특히 기존 서버의 성능 문제 중 일부가 가비지 컬렉터와 관련되어 있었기 때문에 낮은 메모리 사용량이 중요했다. ## Rust 도입의 장점과 한계 - 장점 - 메모리 사용량이 매우 낮았다. - 가비지 컬렉터 없이 메모리 레이아웃을 세밀하게 제어할 수 있었다. - 문서별 Rust 프로세스 실행이 가능할 정도로 프로세스 비용이 작았다. - 높은 성능과 병렬 처리 구조를 구현할 수 있었다. - 한계 - 당시 Rust는 일반적인 서버 언어보다 훨씬 새로운 언어였다. - 언어와 생태계가 충분히 성숙하지 않아 여러 거친 부분이 있었다. - 처음 계획했던 전체 서버의 Rust 재작성은 포기했다. - 대신 성능에 가장 큰 영향을 주는 부분에만 Rust를 제한적으로 적용했다. Figma의 사례는 새로운 언어를 전면 도입하기보다, 병목이 명확한 핵심 컴포넌트만 별도 프로세스로 분리해 적용하는 전략이 현실적임을 보여준다. 특히 메모리 사용량과 지연 시간이 중요한 서비스에서는 Rust가 효과적이지만, 언어의 성숙도와 팀의 운영 역량을 고려해 점진적으로 도입하는 것이 바람직하다.