How Blitz scaled their game coaching app with lower latency and leaner operations League of Legends, Valorant 및 Fortnite와 같은 게임에 대한 개인화 된 코칭을 제공하는 빠르게 성장하는 스타트업입니다.그들은 게임 플레이어가 실시간 통찰력과 경기 후 분석을 통해 League of Legends의 전설이되도록 돕는 것을 목표로합니다. 플래시 플레이어가 플레이하는 동안 앱은 꽤 많은 작업을 수행합니다.이 앱은 라이브 경기 데이터를 캡처하고 신속하게 분석하고 실시간 게임 스크린 커버레이션과 개인화 된 게임 후 코칭을 위해 사용합니다.이 가이드는 각 플레이어의 현재 및 역사적 게임 활동을 기반으로하며 수십억 명의 사용자를 포함한 수십억 경기에서 수집 된 데이터를 기반으로합니다. Blitz의 인기 통계 및 게임 코칭 앱에 대한 인식이 커지면서 지속적으로 증가하는 사용자 기반은 원래의 Postgres 및 Elixir 기반 아키텍처를 한계로 밀어 넣었습니다.이 블로그 게시물은 최근 League of Legends 데이터 백엔드를 Rust 및 ScyllaDB를 사용하여 어떻게 개조했는지 설명합니다. - 성장하는 사용자 기반에 낮은 지연, 높은 가용성 및 수평 확장성을 제공하기 위해, 그들은 궁극적으로 : TL;DR Elixir에서 Rust로 마이그레이션된 백엔드 서비스. Postgres를 ScyllaDB Cloud로 교체했습니다. Redis 발자국을 크게 줄였습니다. 그들의 Riak 클러스터를 제거했습니다. 실시간 처리로 대체된 꼬리 처리. 100개가 넘는 마이크로 서비스 코어에서 4개의 n4‐standard‐4 Google Cloud 노드까지의 통합된 인프라(에이지 캐시를 위한 작은 Redis 인스턴스) 추가 보너스로서 이러한 변경은 Blitz의 인프라 비용을 절감하고 엔지니어링 직원의 데이터베이스 부담을 줄였습니다. Blitz 배경 Naveed Khan (Blitz의 엔지니어링 책임자)는 "우리는 게임 출판사와 게임 플레이 중에 많은 데이터를 수집합니다. 예를 들어, 당신이 League of Legends를 플레이하는 경우, 우리는 Riot의 API를 사용하여 경기 데이터를 추출하고, 당신이 우리의 앱을 설치하면 우리는 또한 실시간으로 게임 플레이를 모니터링합니다. 스케일링 과거 Postgres 블리츠의 시스템의 핵심 부분은 플레이 스타일 API로, 팀 동료와 상대방 모두에 대한 사전 게임 데이터를 분석합니다.이 집중적 인 프로세스는 플레이어 당 최대 20경기를 평가하고 게임 당 9 개의 개별 경기를 실행합니다 (게임 중 각 플레이어에 대해 한 번). 팀은 전략적으로 수많은 마이크로 서비스를 재구성하고 성능을 향상시키기 위해 통합했습니다.하지만 데이터 볼륨은 강렬했습니다.Brian Morin (Blitz의 주요 백엔드 엔지니어)에 따르면 "이 쿼리 볼륨을 처리 할 수있는 데이터베이스 솔루션을 찾는 것이 중요했습니다." 그들은 처음에는 Postgres를 사용했는데, 그것은 그들을 아주 일찍 섬겼다.그러나 글쓰기 힘든 워크로드가 확대되면서 Google Cloud의 운영 복잡성과 비용이 크게 증가했습니다.또한 Postgres를 확대하는 것이 상당히 복잡해졌습니다.Naveed는 "우리는 모든 종류의 일을 확대하려고 시도했습니다.Postgres를 둘러싸고 우리가 필요로하는 규모를 얻기 위해 여러 서비스를 구축했습니다 : Redis 클러스터, Riak 클러스터, 그리고 때때로 과도한 Elixir Oban 차례. 스타트업이 확장되면서, 그들은 종종 "Postgres를 사용하십시오"에서 "NoSQL을 사용하십시오"로 전환합니다. 적절하게, Blitz 팀은 MongoDB로 이동을 고려했지만 결국 그것을 배제했습니다. "우리는 팀에서 많은 MongoDB 경험을 가지고 있었고 우리 중 일부는 정말로 그것을 좋아했습니다.그러나 우리의 작업 부하는 매우 쓰기 힘들며 수천 명의 동시 플레이어가 데이터의 끊임없는 흐름을 생성합니다. 그들의 특정 작업량과 예상되는 성장을위한 병아리를 만듭니다. MongoDB의 Primary-Secondary 아키텍처 테스트는 그들의 지연 요구를 충족시킬 것임을 보여주었으므로 필요한 데이터 (re) 모델링을 수행하고 Postgres에서 RocksDB로 몇 개의 소규모 게임을 마이그레이션했습니다.그러나 RocksDB는 규모와 높은 가용성 우려 때문에 RocksDB에 반대하기로 결정했습니다. "우리의 테스트에서 사용할 수있는 데이터를 바탕으로 RocksDB는 더 큰 게임의 부하를 처리 할 수 없을 것이 분명했습니다. 왜 ScyllaDB 그들의 백엔드 엔지니어 중 한 명은 ScyllaDB를 제안했으므로 그들은 접근하고 컨셉의 증거를 실행했습니다.그들은 주로 쓰기 통과량을 처리 할 수있는 솔루션을 찾고 있었고, 수평적으로 규모를 규모하고 높은 가용성을 제공했습니다. 그들은 먼저 자신의 하드웨어에서 테스트 한 다음 ScyllaDB 클라우드로 이동했습니다. Naveed에 따르면 "비용은 자체 호스팅에 상당히 가깝고, 우리는 무료로 전체 관리를 받았으므로 무의미했습니다.우리는 이제 Redis 클러스터를 크게 줄였고 Riak 클러스터와 Oban 차례에 대한 의존성을 제거했습니다.그냥 ScyllaDB에 글을 쓰고 모든 것이 작동합니다.인프라 관리에 소비하는 시간은 상당히 감소했습니다." 브라이언은 “ScyllaDB는 최적화 후에 저장할 수 있는 강력한 성능을 제공함으로써 뛰어난 성능을 보였습니다. 우리의 리그 제품은 약 5K 오프스/초의 수준을 달성했으며 클러스터가 20 % 부하로 보고했습니다. 우리의 가장 큰 제한은 디스크 사용이었으며, 이를 완화하기 위해 여러 가지 업데이트를 도입했습니다. 새로운 시스템은 이제 캐시된 데이터에 의존하는 대신 즉시 결과를 반환할 수 있으며, 다른 플레이어에 대한 최신 정보를 제공하고 심지어 종종 팀 동료를 식별할 수 있습니다. 이 마이그레이션의 결과는 인상적이었습니다: 100개 이상의 마이크로 서비스 코어가 4개의 n4-standard-4 노드와 최소한의 Redis 인스턴스로 대체 High-Level Architecture of Blitz Server with Rust and ScyllaDB Rust에 Elixir Services를 다시 쓰기 주요 백엔드 개혁의 일환으로 Blitz 팀은 이전에 설명한 Postgres에서 고성능 및 분산 ScyllaDB로의 전환을 넘어 전체 인프라를 재구성하기 시작했습니다.이 데이터베이스 마이그레이션과 함께, 그들은 또한 Elixir 기반의 서비스를 더 현대적인 언어를 위해 태양을 선택했습니다.주의 깊은 평가 후, Rust는 명확한 선택으로 나타났습니다. “Elixir는 훌륭하고 그것은 그 목적을 잘 섬겼습니다.”라고 Naveed는 설명했습니다. “그러나 우리는 더 광범위한 채택과 더 강력한 시스템 수준의 생태계를 향해 움직이기를 원했습니다. Rust의 첫 번째 배치가 생산 중이므로 Naveed와 팀은 뒤돌아보지 않습니다: “Rust는 환상적입니다. 그것은 빠르고 컴파일러는 나중에 쓰레기 수집 문제를 디버깅하는 대신 메모리 안전 코드를 미리 작성하도록 강요합니다.
