Roblox가 Kafka 플랫폼을 하루 18조 건 이상의 메시지 처리 규모로 확장한 방법

지난 2년 동안, 당사는 내부 메시지 큐 플랫폼을 매년 2.5배 이상 확장하여 현재 하루 18조 건 이상의 메시지를 처리하고 있습니다. 현재 우리는 99.995%의 가용성을 유지하면서 초당 3억 건 이상의 메시지를 처리하고 있습니다. Apache Kafka를 기반으로 구축된 이 메시지 큐 플랫폼은 회사 전체에 걸쳐 데이터를 전송하는 데 있어 핵심적인 역할을 하고 있습니다. 이 플랫폼은 분석 이벤트, 콘텐츠 검토 파이프라인, 매칭 시스템 등 다양한 워크로드를 지원합니다. 이러한 수치는 인상적이지만, 더 중요한 이야기는 우리가 어떻게 여기까지 왔는지에 있습니다. 

종단 간 최적화의 영향 

대규모 시스템에 대해 흔히 있는 오해 중 하나는 용량이 주로 하드웨어 문제라는 것입니다. 우리의 경험에 따르면, 확장성을 종단 간 엔지니어링 문제로 접근할 때 가장 큰 개선 효과를 얻을 수 있습니다.

Roblox 전사 팀들은 메시징 큐를 기반으로 AI 훈련 파이프라인, 스트림 처리 추상화, 텔레메트리 시스템 등 다양한 플랫폼을 구축했습니다. 이러한 플랫폼의 담당자들과 협력함으로써, 배치 처리 및 압축 활성화와 같은 모범 사례를 준수할 수 있도록 지원할 수 있습니다. 그 결과, 최종 사용자가 세부적인 구성 설정에 관여하지 않아도 효율적인 시스템을 구축할 수 있게 되었습니다.

비즈니스 우선순위, 성과 측정 및 성공 기준에 대해 플랫폼을 사용하는 팀들과 의견을 조율하는 것은 매우 중요하며, 팀 간 협업을 촉진하는 데 도움이 됩니다. 핵심 지표는 시스템 계층에 따라 다릅니다. 예를 들어, 우리는 더 적은 수의 서버로 대용량 데이터를 효율적으로 처리하도록 Kafka 서버를 최적화할 수 있지만, 최종 사용자는 엔드투엔드 지연 시간을 밀리초 단위로 줄이거나, 배치 작업이 데이터 쓰기를 완료하는 데 걸리는 총 시간을 최적화하기를 원할 수 있습니다. 

모든 트래픽이 동등한 것은 아닙니다

우리가 배운 핵심 교훈 중 하나는 대규모 플랫폼이 모든 트래픽을 동등하게 취급하지 않을 때 더 안정적이라는 점입니다. 일부 워크로드는 매우 낮은 지연 시간과 트래픽 급증 시 강력한 보호가 필요합니다. 예를 들어, 엔드투엔드 지연 시간이 10밀리초 미만으로 작동하는 매치메이킹 시스템이 그렇습니다. 반면, 분석 이벤트 수집 파이프라인처럼 트래픽 양은 극히 많지만 지연에 대한 허용 범위가 넓은 워크로드도 있습니다. 이 파이프라인은 엔드투엔드 지연 시간이 몇 초에 달하더라도 원활하게 실행될 수 있습니다. 두 유형을 동일하게 처리하면, 특히 피크 부하 시 가장 트래픽 양이 많은 트래픽이 비즈니스에 더 중요한 트래픽을 압도할 수 있습니다.

이 문제를 해결하기 위해, 우리는 각 트래픽이 적절히 지원될 수 있도록 사용 사례 요구 사항에 따라 트래픽을 그룹화합니다. Kafka에서 종단 간 지연 시간과 처리량 간의 균형은 새로운 사용 사례를 설정할 때 고려해야 할 주요 사항 중 하나입니다. 이는 프로듀서에서 서버, 컨슈머로 이어지는 데이터 경로 전반에 걸쳐 적용됩니다. 각 단계에는 처리량이나 지연 시간 중 하나를 최적화하도록 조정할 수 있는 구성 옵션이 있습니다. 클라이언트 측 구성은 개별 사용 사례에 맞게 조정할 수 있지만, 서버 측 구성은 각기 다른 사용 사례마다 전용 클러스터를 유지하는 것이 비현실적이기 때문에 유연성이 떨어집니다. 

우리는 스택 하단의 하드웨어 계층에 이르기까지, 각 클러스터가 담당하는 사용 사례에 맞춰 최적화하는 이러한 접근 방식을 적용합니다. 

하드웨어는 여전히 중요합니다

우리는 처음에 RAID10 HDD 서버에서 Kafka를 실행했습니다. 트래픽 양이 증가함에 따라, 서버당 Kafka 처리량을 제한하는 주요 병목 현상은 서버의 디스크 I/O 용량이 되었습니다. 이를 해결하기 위해 두 가지 최적화를 수행했습니다. 브로커를 가능한 한 SSD를 사용하도록 전환하여, 병목 현상을 디스크 I/O 용량에서 네트워크 처리량이나 디스크 공간(구입한 SSD의 디스크 용량이 적었기 때문)으로 옮겼습니다. 이를 통해 디스크 I/O 처리량이 10배 증가했습니다. 또한 남아 있는 HDD를 RAID10에서 RAID0로 전환하기 시작했습니다. RAID0에서는 각 쓰기 작업 시 두 개의 디스크가 아닌 하나의 디스크에만 쓰기 작업이 이루어지기 때문에, 디스크 I/O 용량이 대략 두 배로 늘어났습니다. 

단, 각 메시지 복제본이 브로커당 두 개의 디스크가 아닌 하나의 디스크에만 기록되기 때문에 RAID10에서 RAID0으로 전환할 경우 신뢰성 위험이 따를 수 있습니다. 신뢰성을 유지하기 위해, 우리는 중요한 사용 사례를 중심으로 확인 응답(ack) 횟수를 늘리고 데이터 복제를 강화했으며, 여기에는 여러 리전으로의 복제도 포함되었습니다.

각 머신의 스토리지 및 처리량 성능을 최대한 활용하기 위해서는 추가 작업이 필요했습니다. Kafka가 메시지를 버퍼링하고 메모리에서 읽기 요청이나 최근 데이터를 처리할 수 있도록 메모리 할당 및 페이지 캐시 관리 구성을 최적화하여, 과거 데이터를 읽을 때와 같이 필요한 경우에만 디스크에 접근하여 귀중한 IOPS를 소모하도록 했습니다. 

또한 하드웨어의 한계를 파악하고 소프트웨어 수준에서 설정해야 할 제한 사항을 결정하기 위해 성능 벤치마크를 수행했습니다. 실제로 이는 클러스터가 실행되는 하드웨어에 따라 달라지는 Kafka 브로커의 읽기 및 쓰기 스로틀을 설정하는 것을 의미합니다. SSD 머신은 브로커당 더 높은 처리량을 처리할 수 있는 반면, HDD 머신은 과거 데이터의 장기 보관이 필요한 사용 사례에 더 적합합니다. 

신뢰성 확보를 위한 구축

큐 플랫폼은 Roblox 인프라의 핵심 구성 요소이며, 신뢰성을 유지하는 것이 매우 중요합니다. 출시 전 테스트와 지속적인 장애 시나리오 테스트(때로는 ‘게임 데이 훈련’이라고도 함)는 단일 호스트 장애, 랙 장애, 네트워킹 문제 등 다양한 장애 모드에 대해 우리 인프라가 탄력적으로 대응할 수 있음을 검증하는 데 결정적인 역할을 했습니다. 저희 신뢰성 팀의 내부 카오스 테스트 플랫폼은 다양한 장애 시나리오를 시뮬레이션하는 과정을 가능하게 하고 간소화했습니다. 이러한 테스트는 시스템의 개선 사항이나 퇴화 현상을 파악하는 데 도움을 주며, 경보를 정기적으로 검증하고 운영자가 드문 문제를 포함해 다양한 문제를 처리하는 절차를 숙지하도록 함으로써 운영 우수성을 구축합니다.

또한, 의존적인 사용 사례에 대해 큐 기능을 신속하게 복구할 수 있는 장애 조치 프로세스를 설계하고 구현했습니다. 개별 클러스터가 완전히 고장난 경우에도, 충분한 용량을 갖춘 정상 클러스터로 클라이언트를 전환할 수 있습니다. 사용 가능한 여유 용량을 확보하기 위해 대기용 Kafka 클러스터를 유지하고 있습니다. 이를 통해 가동 중인 클러스터 간에 트래픽을 전환할 때 발생하는 ‘노이시 네이버(noisy neighbor)’ 문제의 위험을 제거할 수 있습니다.

아래 다이어그램은 페일오버 실행을 위한 개략적인 단계를 보여줍니다. 먼저, 운영자가 페일오버의 범위를 파악합니다. 그런 다음, 자동화된 일괄 작업을 통해 대기 클러스터에 토픽과 액세스 제어 목록(ACL)이 생성됩니다. 마지막으로, 운영자가 제어 플레인 서비스 구성을 업데이트하면, 클라이언트는 이를 폴링하여 재연결이 필요한지 여부를 판단합니다. 아래 그림은 일반적인 실시간 사용 사례를 위한 것입니다. Mirror Maker 2를 활용한 토픽 미러링, 데이터 백필 도구 등 다른 사용 사례 및 시나리오를 위한 추가 전략과 도구도 마련되어 있습니다.

Roblox는 보안에 대해 엄격한 요구 사항을 적용하고 있으며, 이는 신뢰성의 핵심 요소이기도 합니다. 당사는 전송 중 암호화(mTLS 사용), 저장 시 암호화(암호화된 디스크 사용), 데이터 보존 기간 요건, Kafka 주체 및 ACL을 통한 인증/권한 부여와 같은 표준 보안 기능을 구현했습니다. 또한 보안을 한층 더 강화하기 위해 사용자의 자격 증명을 자동으로 순환 갱신하고 있습니다.

이 외에도, 빠른 OS 패치 적용 및 랙 드레인(rack drain)을 용이하게 하기 위해 제어 플레인에 맞춤형 처리 기능을 구축했습니다. OS 패치 적용 중에는 디스크에 데이터를 보존하여, 패치가 완료된 머신이 Kafka 클러스터에 재가입한 후 신속하게 정상 상태를 회복할 수 있도록 합니다. 이를 통해 시스템 규모가 계속 확장되더라도 30일 이내에 전체 인프라인을 패치할 수 있습니다. Cruise Control과 같은 도구를 활용하여 랙 단위로 데이터를 복제하므로, 데이터 가용성에 영향을 주지 않고 유지보수 및 네트워크 패치 작업을 위해 전체 랙을 오프라인 상태로 전환할 수 있습니다.

앞으로의 방향

저희 큐 플랫폼의 다음 단계는 탄력성과 격리성을 지속적으로 개선하는 동시에 개발자에게 플랫폼을 더욱 간편하게 제공하는 것입니다. 저희는 프로듀서 및 컨슈머 프록시와 완전 관리형 커넥터를 포함한 새로운 추상화 기법에 투자하고 있습니다. 이러한 시스템은 애플리케이션 팀을 인프라의 복잡성으로부터 더욱 분리시켜 주고, 대규모 환경에서 플랫폼을 더 쉽게 도입하고 관리할 수 있게 해줄 것입니다. 예를 들어, 컨슈머 프록시는 경쟁 컨슈머 패턴을 가능하게 하여 플랫폼이 더 광범위한 사용 사례를 지원하고, 프로세서의 확장성을 Kafka 파티션의 확장성과 분리할 수 있게 해줍니다. 이는 순서가 필요하지 않고, 달성해야 할 엔드투엔드 전달 목표에 구애받지 않고 일시적으로 프로세서 수를 늘릴 수 있는 이점이 있는, 대량의 알림 급증 처리와 같은 사용 사례에 유용합니다.

카프카의 확장은 단순히 클러스터의 수와 규모를 늘리는 것만이 아닙니다. 이는 로블록스가 매일 10억 명의 사람들을 낙관적이고 예의 바른 태도로 연결해 나가는 여정을 지속할 수 있도록 하는 엔지니어링 체계, 추상화 기법, 운영 모델을 구축하는 것입니다.