28월 31일부터 73월 XNUMX일에 완전히 해결된 Roblox는 XNUMX시간 동안 중단되었습니다.¹ XNUMX천만 명의 플레이어가 매일 정기적으로 Roblox를 사용하며 플레이어가 기대하는 경험을 만들기 위해 수백 개의 내부 온라인 서비스가 포함됩니다. 다른 대규모 서비스와 마찬가지로 때때로 서비스 중단이 발생하지만 이 중단 기간이 길어 특히 주목할 만합니다. 다운타임으로 인해 커뮤니티에 진심으로 사과드립니다.
우리는 커뮤니티에 문제의 근본 원인, 해결 방법 및 유사한 문제가 앞으로 발생하지 않도록 방지하기 위해 무엇을 하는지에 대한 이해를 제공하기 위해 이러한 기술적 세부 정보를 공유하고 있습니다. 사고가 발생하는 동안 사용자 데이터가 손실되거나 권한이 없는 당사자가 정보에 액세스하지 않았음을 다시 한 번 강조합니다.
Roblox 엔지니어링과 HashiCorp의 기술 직원은 Roblox를 다시 서비스하기 위해 노력했습니다. 우리는 문제가 해결될 때까지 엄청난 자원을 투입하고 우리와 지칠 줄 모르고 함께 일한 HashiCorp 팀에 감사를 표하고 싶습니다.
정전 요약
정전은 기간과 복잡성 모두에서 독특했습니다. 팀은 근본 원인을 이해하고 서비스를 다시 시작하기 위해 여러 문제를 순서대로 해결해야 했습니다.
- 정전은 73시간 동안 지속되었습니다.
- 근본 원인은 두 가지 문제였습니다. 비정상적으로 높은 읽기 및 쓰기 부하에서 Consul에서 비교적 새로운 스트리밍 기능을 활성화하면 과도한 경합과 성능 저하가 발생했습니다. 또한 특정 부하 조건으로 인해 BoltDB에서 병리학적 성능 문제가 발생했습니다. 오픈 소스 BoltDB 시스템은 Consul 내에서 리더 선출 및 데이터 복제를 위한 미리 쓰기 로그를 관리하는 데 사용됩니다.
- 여러 워크로드를 지원하는 단일 영사 클러스터는 이러한 문제의 영향을 악화시켰습니다.
- 영사 구현 깊숙이 묻혀 있는 이 두 가지 기본적으로 관련 없는 문제를 진단하는 데 어려움이 있었기 때문에 가동 중지 시간이 연장되었습니다.
- 정전의 원인에 대한 더 나은 가시성을 제공했을 중요한 모니터링 시스템은 영사관과 같은 영향을 받는 시스템에 의존했습니다. 이 조합은 분류 프로세스를 심각하게 방해했습니다.
- 우리는 Roblox를 확장된 완전 다운 상태에서 끌어올리는 접근 방식에 대해 사려 깊고 주의를 기울였습니다. 이 작업에도 상당한 시간이 걸렸습니다.
- 모니터링을 개선하고 관찰 가능성 스택에서 순환 종속성을 제거하며 부트스트랩 프로세스를 가속화하기 위한 엔지니어링 노력을 가속화했습니다.
- 우리는 여러 가용 영역과 데이터 센터로 이동하기 위해 노력하고 있습니다.
- 이 이벤트의 근본 원인이었던 영사 문제를 해결하고 있습니다.
서문: 클러스터 환경 및 HashiStack
Roblox의 핵심 인프라는 Roblox 데이터 센터에서 실행됩니다. 우리는 자체 하드웨어는 물론 해당 하드웨어 위에 자체 컴퓨팅, 스토리지 및 네트워킹 시스템을 배포하고 관리합니다. 18,000개 이상의 서버와 170,000개 이상의 컨테이너로 배포 규모가 상당합니다.
여러 사이트에서 수천 대의 서버를 실행하기 위해 우리는 일반적으로 "하시스택. " 유목민, 영사 과 둥근 천장 우리가 전 세계의 서버와 서비스를 관리하는 데 사용하는 기술로 Roblox 서비스를 지원하는 컨테이너를 오케스트레이션할 수 있습니다.
유목민 일정 작업에 사용됩니다. 액세스 가능한 노드와 포트에서 실행할 컨테이너를 결정합니다. 또한 컨테이너 상태를 확인합니다. 이 모든 데이터는 IP:Port 조합의 데이터베이스인 Service Registry로 중계됩니다. Roblox 서비스는 서비스 레지스트리를 사용하여 통신할 수 있도록 서로를 찾습니다. 이 프로세스를 "서비스 검색"이라고 합니다. 우리는 사용 영사 서비스 검색, 상태 확인, 세션 잠금(상단에 구축된 HA 시스템용) 및 KV 저장소로 사용됩니다.
Consul은 두 가지 역할의 머신 클러스터로 배포됩니다. "투표자"(5대의 머신)는 클러스터의 상태를 권위 있게 보유합니다. "비투표자"(추가 머신 5대)는 읽기 요청 확장을 지원하는 읽기 전용 복제본입니다. 주어진 시간에 투표자 중 한 명이 클러스터에서 리더로 선출됩니다. 리더는 데이터를 다른 유권자에게 복제하고 작성된 데이터가 완전히 커밋되었는지 여부를 결정할 책임이 있습니다. Consul은 다음과 같은 알고리즘을 사용합니다. 뗏목 지도자 선출과 클러스터의 각 노드가 업데이트에 동의하도록 하는 방식으로 클러스터 전체에 상태를 배포합니다. 리더가 하루에 몇 번씩 리더 선출을 통해 바뀌는 것은 드문 일이 아니다.
다음은 사건 이후 Roblox의 영사 대시보드의 최근 스크린샷입니다. 이 블로그 게시물에 언급된 많은 주요 운영 메트릭은 정상 수준으로 표시됩니다. 예를 들어 KV Apply 시간은 300ms 미만에서 정상으로 간주되며 이 순간에는 30.6ms입니다. 영사 리더는 최근 32ms 동안 클러스터의 다른 서버와 접촉한 적이 있습니다.
1. Roblox 영사의 정상적인 업무
1.9월 사건이 일어나기 몇 달 동안 Roblox는 Consul XNUMX에서 영사 1.10 활용하기 위해 새로운 스트리밍 기능. 이 스트리밍 기능은 Roblox와 같은 대규모 클러스터에 업데이트를 배포하는 데 필요한 CPU 및 네트워크 대역폭을 크게 줄이도록 설계되었습니다.
초기 탐지 (10/28 13:37)
28월 XNUMX일 오후, Vault 성능이 저하되었고 단일 Consul 서버의 CPU 부하가 높았습니다.디. Roblox 엔지니어가 조사를 시작했습니다. 이 시점에서 플레이어는 영향을 받지 않았습니다.
조기 분류(10/28 13:37 – 10/29 02:00)
초기 조사에서는 Vault 및 기타 여러 서비스가 의존하는 영사 클러스터가 비정상인 것으로 나타났습니다. 특히 Consul 클러스터 메트릭은 Consul이 데이터를 저장하는 기본 KV 저장소에 대해 쓰기 대기 시간이 증가한 것으로 나타났습니다. 이러한 작업의 50번째 백분위수 대기 시간은 일반적으로 300ms 미만이었지만 이제는 2초입니다. 하드웨어 문제는 Roblox의 규모에서 드문 일이 아니며 Consul은 하드웨어 오류에서 살아남을 수 있습니다. 그러나 하드웨어가 실패하는 것이 아니라 단지 느린 경우 전체 영사 성능에 영향을 미칠 수 있습니다. 이 경우 팀은 하드웨어 성능 저하를 근본 원인으로 의심하고 Consul 클러스터 노드 중 하나를 교체하는 프로세스를 시작했습니다. 이것은 사건 진단을 위한 우리의 첫 번째 시도였습니다.. 이 즈음에 HashiCorp의 직원이 Roblox 엔지니어와 합류하여 진단 및 치료를 도왔습니다. 이 시점부터 "팀" 및 "엔지니어링 팀"에 대한 모든 언급은 Roblox와 HashiCorp 직원을 모두 나타냅니다.
새 하드웨어를 사용하더라도 Consul 클러스터 성능은 계속해서 저하되었습니다. 16시 35분에 온라인 플레이어 수가 평소의 50%로 떨어졌습니다.
2. 16:35 PST 플레이어 드롭 중 CCU
이 하락은 시스템 상태의 심각한 저하와 일치하여 궁극적으로 완전한 시스템 중단을 초래했습니다. 왜요? Roblox 서비스가 다른 서비스와 통신하기를 원할 때 Consul에 의존하여 통신하려는 서비스의 위치에 대한 최신 정보를 얻습니다. 그러나 Consul이 비정상이면 서버 연결에 어려움을 겪습니다. 또한 Nomad와 Vault는 Consul에 의존하므로 Consul이 비정상인 경우 시스템은 새 컨테이너를 예약하거나 인증에 사용되는 프로덕션 비밀을 검색할 수 없습니다. 요컨대 Consul이 단일 장애 지점이었고 Consul이 건강하지 않았기 때문에 시스템이 실패했습니다.
이 시점에서 팀은 무엇이 잘못되었는지에 대한 새로운 이론을 개발했습니다. 바로 트래픽 증가입니다. 아마도 우리 시스템이 티핑 포인트에 도달했고 Consul이 실행되고 있던 서버가 더 이상 로드를 처리할 수 없었기 때문에 Consul이 느렸을까요? 이것은 사고의 근본 원인을 진단하기 위한 두 번째 시도였습니다.
사고의 심각성을 고려하여 팀은 Consul 클러스터의 모든 노드를 새롭고 더 강력한 시스템으로 교체하기로 결정했습니다. 이 새로운 머신에는 128개의 코어(2배 증가)와 더 빠르고 더 빠른 NVME SSD 디스크가 있습니다. 19:00까지 팀은 대부분의 클러스터를 새 시스템으로 마이그레이션했지만 클러스터는 여전히 정상적이지 않았습니다. 클러스터는 대다수의 노드가 쓰기를 따라잡을 수 없었고 KV 쓰기의 50번째 백분위수 대기 시간이 일반적인 2ms 이하가 아닌 여전히 약 300초라고 보고했습니다.
서비스 복귀 시도 #1 (10/29 02:00 – 04:00)
영사 클러스터를 정상 상태로 되돌리려는 처음 두 번의 시도는 실패했습니다. 우리는 여전히 상승된 KV 쓰기 대기 시간과 우리가 설명할 수 없는 새로운 설명할 수 없는 증상을 볼 수 있었습니다. 영사 리더는 정기적으로 다른 유권자와 동기화되지 않았습니다.
팀은 전체 영사 클러스터를 종료하고 정전이 시작되기 몇 시간 전의 스냅샷을 사용하여 상태를 재설정하기로 결정했습니다. 이로 인해 잠재적으로 약간의 시스템 구성 데이터 손실이 발생할 수 있음을 이해했습니다(지원 사용자 데이터 손실). 가동 중단의 심각성과 필요한 경우 이 시스템 구성 데이터를 수동으로 복원할 수 있다는 확신을 감안할 때 우리는 이것이 수용 가능하다고 느꼈습니다.
시스템이 정상일 때 찍은 스냅샷에서 복원하면 클러스터가 정상 상태가 될 것으로 예상했지만 한 가지 추가 문제가 있었습니다. 이 시점에서 Roblox에는 시스템을 통해 흐르는 사용자 생성 트래픽이 없었지만 내부 Roblox 서비스는 여전히 활성 상태였으며 성실하게 영사에게 연락했습니다. 의존성의 위치를 배우기 위해 그리고 그들의 건강 정보를 업데이트하기 위해. 이러한 읽기 및 쓰기로 인해 클러스터에 상당한 부하가 발생했습니다. 클러스터 재설정이 성공한 경우에도 이 로드로 인해 클러스터가 즉시 비정상 상태로 돌아갈 수 있다는 점을 우려했습니다. 이 문제를 해결하기 위해 구성했습니다. iptables에 클러스터에서 액세스를 차단합니다. 이를 통해 제어된 방식으로 클러스터를 백업할 수 있으며 사용자 트래픽과 무관하게 Consul에 가하는 부하가 문제의 일부인지 이해하는 데 도움이 됩니다.
재설정은 순조롭게 진행되었으며 처음에는 지표가 좋아 보였습니다. 우리가 제거했을 때 iptables에 블록, 서비스 검색 및 내부 서비스의 상태 확인 로드가 예상대로 반환되었습니다. 그러나 Consul 성능이 다시 저하되기 시작했고 결국 우리는 처음 시작했던 위치로 돌아갔습니다. KV 쓰기 작업의 50번째 백분위수는 2초로 돌아갔습니다. 영사에 의존하는 서비스는 스스로를 "비정상"으로 표시하기 시작했고 결국 시스템은 이제 익숙한 문제 상태로 되돌아갔습니다. 지금은 04:00시였다. 문제를 일으키는 영사의 부하가 분명히 있었고 사건이 발생한 지 14시간이 지난 후에도 우리는 그것이 무엇인지 알지 못했습니다.
서비스 복귀 시도 #2 (10/29 04:00 – 10/30 02:00)
우리는 하드웨어 오류를 배제했습니다. 더 빠른 하드웨어는 도움이 되지 않았으며 나중에 알게 되듯이 안정성이 손상될 수 있습니다. 영사의 내부 상태를 재설정하는 것도 도움이 되지 않았습니다. 들어오는 사용자 트래픽은 없었지만 Consul은 여전히 느렸습니다. 우리는 활용했다 iptables에 트래픽이 클러스터로 천천히 돌아오도록 합니다. 다시 연결을 시도하는 수천 개의 컨테이너로 인해 클러스터가 단순히 비정상 상태로 되돌아간 것입니까? 이것은 사고의 근본 원인을 진단하기 위한 세 번째 시도였습니다..
엔지니어링 팀은 영사 사용량을 줄이고 신중하고 체계적으로 다시 도입하기로 결정했습니다. 깨끗한 출발점을 보장하기 위해 나머지 외부 트래픽도 차단했습니다. 우리는 Consul을 사용하는 서비스의 전체 목록을 수집하고 필수가 아닌 모든 사용을 비활성화하기 위해 구성 변경 사항을 출시했습니다. 이 프로세스는 대상 시스템 및 구성 변경 유형이 매우 다양하기 때문에 몇 시간이 걸렸습니다. 일반적으로 수백 개의 인스턴스를 실행하던 Roblox 서비스가 한 자리 숫자로 축소되었습니다. 클러스터에 추가 호흡 공간을 제공하기 위해 상태 확인 빈도를 60초에서 10분으로 줄였습니다. 정전이 시작된 지 16시간이 지난 00월 29일 24:02에 팀은 Roblox를 다시 온라인 상태로 만들기 위한 두 번째 시도를 시작했습니다. 다시 한 번, 이 재시작 시도의 초기 단계는 좋아 보였으나 00월 30일 XNUMX:XNUMX까지 Consul은 다시 비정상 상태가 되었으며 이번에는 이에 의존하는 Roblox 서비스의 부하가 훨씬 적었습니다.
이 시점에서 전반적인 영사 사용량이 28일에 처음 발견한 성능 저하에 기여한 유일한 요인이 아님이 분명했습니다. 이러한 깨달음을 바탕으로 팀은 다시 방향을 틀었습니다. 팀은 Consul에 의존하는 Roblox 서비스의 관점에서 Consul을 보는 대신 Consul 내부에서 단서를 찾기 시작했습니다.
경합 조사 (10/30 02:00 – 10/30 12:00)
다음 10시간 동안 엔지니어링 팀은 디버그 로그와 운영 체제 수준 메트릭을 더 자세히 조사했습니다. 이 데이터는 Consul KV 쓰기가 오랜 기간 동안 차단되었음을 보여줍니다. 즉, 경합. 경합의 원인이 바로 밝혀지지는 않았지만, 정전 초기에 CPU Core 서버를 64개에서 128개로 변경하면 문제가 더 악화되었을 수 있다는 이론이 있습니다. 아래 스크린샷에 표시된 htop 데이터 및 성능 디버깅 데이터를 살펴본 후 팀은 중단 전에 사용된 것과 유사한 64 Core 서버로 돌아갈 가치가 있다고 결론지었습니다. 팀은 하드웨어 준비를 시작했습니다. Consul이 설치되고 운영 체제 구성이 세 번 확인되었으며 기계는 가능한 한 자세하게 서비스를 받을 준비가 되었습니다. 그런 다음 팀은 Consul 클러스터를 64개의 CPU 코어 서버로 다시 전환했지만 이 변경은 도움이 되지 않았습니다. 이것은 사고의 근본 원인을 진단하기 위한 네 번째 시도였습니다.
3. 그런 다음 위와 같이 성능 보고서와 함께 이를 표시했습니다. 대부분의 시간은 스트리밍 구독 코드 경로를 통해 커널 스핀 잠금에 소비되었습니다.
4. 128개 코어의 CPU 사용량을 보여주는 HTOP.
근본 원인 발견(10/30 12:00 – 10/30 20:00)
몇 달 전에 우리는 서비스의 하위 집합에서 새로운 Consul 스트리밍 기능을 활성화했습니다. Consul 클러스터의 CPU 사용량과 네트워크 대역폭을 낮추도록 설계된 이 기능은 예상대로 작동했기 때문에 앞으로 몇 달 동안 더 많은 백엔드 서비스에서 이 기능을 점진적으로 활성화했습니다. 정전 하루 전인 27월 14일 00:50에 트래픽 라우팅을 담당하는 백엔드 서비스에서 이 기능을 활성화했습니다. 이 롤아웃의 일환으로 일반적으로 연말에 볼 수 있는 증가하는 트래픽에 대비하기 위해 트래픽 라우팅을 지원하는 노드 수도 15% 늘렸습니다. 시스템은 사건이 시작되기 하루 전에 이 수준에서 스트리밍과 잘 작동했으므로 처음에는 성능이 변경된 이유가 명확하지 않았습니다. 그러나 Consul 서버의 성능 보고서 및 플레임 그래프 분석을 통해 스트리밍 코드 경로가 높은 CPU 사용량을 유발하는 경합의 원인이라는 증거를 확인했습니다. 트래픽 라우팅 노드를 포함하여 모든 Consul 시스템에 대해 스트리밍 기능을 비활성화했습니다. 구성 변경은 51시 50분에 전파를 완료했으며 이 시점에서 Consul KV 쓰기에 대한 300번째 백분위수는 XNUMXms로 낮아졌습니다. 마침내 돌파구가 생겼습니다.
스트리밍이 왜 문제였나요? HashiCorp는 스트리밍이 전반적으로 더 효율적이었지만 구현 시 긴 폴링보다 적은 수의 동시성 제어 요소(Go 채널)를 사용했다고 설명했습니다. 매우 높은 로드, 특히 매우 높은 읽기 로드와 매우 높은 쓰기 로드 모두에서 스트리밍 설계는 단일 Go 채널에서 경합의 양을 악화시켜 쓰기 중에 차단을 일으켜 효율성을 크게 떨어뜨립니다. 이 동작은 코어 수가 많은 서버의 효과도 설명했습니다. 이러한 서버는 NUMA 메모리 모델을 사용하는 이중 소켓 아키텍처였습니다. 따라서 공유 리소스에 대한 추가 경합은 이 아키텍처에서 더 악화되었습니다. 스트리밍을 끄면 Consul 클러스터의 상태가 크게 향상되었습니다.
돌파구에도 불구하고 우리는 아직 숲에서 나오지 않았습니다. 우리는 Consul이 간헐적으로 새로운 클러스터 리더를 선출하는 것을 보았지만 정상적이지 않은 스트리밍을 비활성화하기 전에 보았던 것과 동일한 대기 시간 문제를 나타내는 일부 리더도 보았습니다. 느린 리더 문제의 근본 원인을 가리키는 명백한 단서가 없고 특정 서버가 리더로 선출되지 않는 한 클러스터가 정상이라는 증거와 함께 팀은 문제를 방지하여 문제를 해결하기로 실용적인 결정을 내렸습니다. 선출된 상태를 유지하는 지도자. 이를 통해 팀은 Consul에 의존하는 Roblox 서비스를 정상 상태로 되돌리는 데 집중할 수 있었습니다.
그러나 느린 지도자들은 어떻게 되었습니까? 우리는 사고 중에 이것을 알아내지 못했지만 HashiCorp 엔지니어들은 정전 이후 며칠 동안 근본 원인을 파악했습니다. Consul은 BoltDB라는 인기 있는 오픈 소스 지속성 라이브러리를 사용하여 Raft 로그를 저장합니다. 그것은 지원 Consul 내에서 현재 상태를 저장하는 데 사용되지만 적용되는 작업의 롤링 로그입니다. BoltDB가 무한정 커지는 것을 방지하기 위해 Consul은 정기적으로 스냅샷을 수행합니다. 스냅샷 작업은 Consul의 현재 상태를 디스크에 기록한 다음 BoltDB에서 가장 오래된 로그 항목을 삭제합니다.
그러나 BoltDB의 설계상 가장 오래된 로그 항목을 삭제하더라도 BoltDB가 디스크에서 사용하는 공간은 절대 줄어들지 않습니다. 대신, 삭제된 데이터를 저장하는 데 사용된 모든 페이지(파일 내의 4kb 세그먼트)는 대신 "사용 가능"으로 표시되고 후속 쓰기에 재사용됩니다. BoltDB는 "freelist"라는 구조에서 이러한 무료 페이지를 추적합니다. 일반적으로 쓰기 대기 시간은 여유 목록을 업데이트하는 데 걸리는 시간에 의해 의미 있는 영향을 받지 않지만 Roblox의 워크로드는 자유 목록 유지 관리 비용이 매우 많이 드는 BoltDB의 병리학적 성능 문제를 노출했습니다.
캐싱 서비스 복원 (10/30 20:00 – 10/31 05:00)
정전이 시작된 지 54시간 만이었다. 스트리밍이 비활성화되고 느린 리더가 선출 상태를 유지하는 것을 방지하는 프로세스가 있기 때문에 Consul은 이제 일관되게 안정적이었습니다. 팀은 서비스 복귀에 집중할 준비가 되었습니다.
Roblox는 백엔드에 일반적인 마이크로서비스 패턴을 사용합니다. 마이크로 서비스 "스택"의 맨 아래에는 데이터베이스와 캐시가 있습니다. 이러한 데이터베이스는 정전의 영향을 받지 않았지만 일반 시스템 작동 중에 여러 계층에서 정기적으로 초당 1억 요청을 처리하는 캐싱 시스템은 비정상적이었습니다. 캐시는 기본 데이터베이스에서 쉽게 다시 채울 수 있는 임시 데이터를 저장하므로 캐싱 시스템을 정상 상태로 되돌리는 가장 쉬운 방법은 다시 배포하는 것입니다.
캐시 재배포 프로세스에서 일련의 문제가 발생했습니다.
- 이전에 수행된 영사 클러스터 스냅샷 재설정으로 인해 캐시 시스템이 영사 KV에 저장하는 내부 일정 데이터가 잘못되었을 수 있습니다.
- 작은 캐시의 배포는 배포하는 데 예상보다 오래 걸리고 큰 캐시의 배포는 완료되지 않았습니다. 작업 스케줄러가 비정상이 아니라 완전히 열린 것으로 간주하는 비정상 노드가 있는 것으로 나타났습니다. 이로 인해 작업 스케줄러가 이 노드에서 캐시 작업을 적극적으로 예약하려고 시도했지만 노드가 비정상이어서 실패했습니다.
- 캐싱 시스템의 자동화된 배포 도구는 대규모 클러스터를 처음부터 부트스트랩하려는 반복적인 시도가 아니라 이미 대규모로 트래픽을 처리하고 있는 대규모 배포에 대한 증분 조정을 지원하도록 구축되었습니다.
팀은 이러한 문제를 식별 및 해결하고 캐시 시스템이 올바르게 배포되었는지 확인하고 정확성을 확인하기 위해 밤새도록 작업했습니다. 정전이 시작된 지 05시간 후인 00월 31일 61:XNUMX에 우리는 건전한 영사 클러스터와 건전한 캐싱 시스템을 갖추었습니다. 나머지 Roblox를 가져올 준비가 되었습니다.
선수들의 귀환 (10/31 05:00 – 10/31 16:00)
최종 서비스 복귀 단계는 05일 00:31에 공식적으로 시작되었습니다. 캐싱 시스템과 유사하게 실행 중인 서비스의 상당 부분이 초기 중단 또는 문제 해결 단계에서 종료되었습니다. 팀은 올바른 용량 수준에서 이러한 서비스를 다시 시작하고 올바르게 작동하는지 확인해야 했습니다. 이것은 순조롭게 진행되었고 10:00까지 플레이어에게 문을 열 준비가 되었습니다.
콜드 캐시와 시스템에 대해 여전히 불확실한 상황에서 우리는 잠재적으로 시스템을 불안정한 상태로 되돌릴 수 있는 트래픽 폭주를 원하지 않았습니다. 홍수를 피하기 위해 DNS 조정을 사용하여 Roblox에 액세스할 수 있는 플레이어 수를 관리했습니다. 이를 통해 무작위로 선택된 플레이어의 특정 비율을 허용하고 다른 플레이어는 계속해서 정적 유지 관리 페이지로 리디렉션할 수 있었습니다. 비율을 높일 때마다 데이터베이스 로드, 캐시 성능 및 전체 시스템 안정성을 확인했습니다. 작업은 하루 종일 계속되었으며 약 10% 증분으로 액세스가 증가했습니다. 우리는 가장 헌신적인 플레이어 중 일부가 우리의 DNS 조정 체계를 파악하고 Twitter에서 이 정보를 교환하기 시작하여 서비스를 백업할 때 "조기" 액세스 권한을 얻을 수 있는 것을 보는 것을 즐겼습니다. 정전이 시작된 지 16시간 후인 일요일 45:73에 100% 플레이어가 액세스할 수 있었고 Roblox가 완전히 작동했습니다.
정전으로 인한 추가 분석 및 변경 사항
플레이어는 31월 XNUMX일에 Roblox로 돌아갈 수 있었지만 Roblox와 HashiCorp는 다음 주 내내 중단에 대한 이해를 계속 수정했습니다. 새 스트리밍 프로토콜의 특정 경합 문제가 식별되고 격리되었습니다. HashiCorp가 있는 동안 벤치마킹된 스트리밍 Roblox 사용과 유사한 규모로, 그들은 많은 수의 스트림과 높은 이탈률의 조합에서 나타나는 특정 동작으로 인해 이전에 이러한 특정 동작을 관찰하지 못했습니다. HashiCorp 엔지니어링 팀은 특정 경합 문제를 재현하고 추가 규모 테스트를 수행하기 위해 새로운 실험실 벤치마크를 만들고 있습니다. HashiCorp는 또한 극단적인 부하에서 경합을 피하고 이러한 조건에서 안정적인 성능을 보장하기 위해 스트리밍 시스템의 설계를 개선하기 위해 노력하고 있습니다.
느린 리더 문제에 대한 추가 분석은 XNUMX초 Raft 데이터 쓰기 및 클러스터 일관성 문제의 주요 원인도 밝혀냈습니다. 엔지니어들은 BoltDB의 내부 작동을 더 잘 이해하기 위해 아래와 같은 Flame 그래프를 살펴보았습니다.
5. BoltDB 자유 목록 작업 분석.
앞서 언급했듯이 Consul은 BoltDB라는 지속성 라이브러리를 사용하여 Raft 로그 데이터를 저장합니다. 사고 중에 생성된 특정 사용 패턴으로 인해 16kB 쓰기 작업이 대신 훨씬 더 커졌습니다. 다음 스크린샷에 설명된 문제를 볼 수 있습니다.
6. 분석에 사용된 자세한 BoldDB 통계.
앞의 명령 출력은 다음과 같은 많은 정보를 알려줍니다.
- 이 4.2GB 로그 저장소는 489MB의 실제 데이터만 저장합니다(모든 인덱스 내부 포함). 3.8GB는 "빈" 공간입니다.
- XNUMXD덴탈의 여유 목록은 7.8MB입니다. 거의 백만 개의 무료 페이지 ID가 포함되어 있기 때문입니다.
즉, 모든 로그 추가(일부 일괄 처리 후 각 Raft 쓰기)에 대해 추가되는 실제 원시 데이터가 7.8kB 이하이더라도 새로운 16MB 여유 목록이 디스크에 기록되고 있었습니다.
이러한 작업에 대한 역압은 또한 전체 TCP 버퍼를 생성하고 비정상 리더의 쓰기 시간을 2-3초로 단축했습니다. 아래 이미지는 사건 중 TCP Zero Windows에 대한 연구를 보여줍니다.
7. TCP 제로 윈도우에 대해 조사하라. TCP 수신기의 버퍼가 채워지기 시작하면 수신 창을 줄일 수 있습니다. 채워지면 창을 XNUMX으로 줄여 TCP 발신자에게 전송을 중지하도록 지시할 수 있습니다.
HashiCorp와 Roblox는 기존 BoltDB 도구를 사용하여 데이터베이스를 "압축"하는 프로세스를 개발 및 배포하여 성능 문제를 해결했습니다.
최근 개선 사항 및 향후 단계
정전 이후 2.5개월이 지났다. 우리는 무엇을 하고 있었나요? 우리는 이 시간을 사용하여 정전에서 최대한 많은 것을 배우고 학습한 내용을 기반으로 엔지니어링 우선 순위를 조정하며 시스템을 공격적으로 강화했습니다. Roblox의 가치 중 하나는 Respect Community이며 무슨 일이 일어났는지 설명하기 위해 더 빨리 게시물을 게시할 수 있었지만 게시하기 전에 시스템의 안정성을 개선하는 데 상당한 진전을 이루도록 하는 것은 커뮤니티인 여러분에게 빚지고 있다고 느꼈습니다.
완료 및 진행 중인 안정성 개선의 전체 목록은 이 글을 쓰기에 너무 길고 상세하지만 핵심 항목은 다음과 같습니다.
원격 측정 개선
원격 측정 시스템과 Consul 사이에는 순환 종속성이 있었습니다. 즉, Consul이 건강하지 않았을 때 무엇이 잘못되었는지 쉽게 파악할 수 있는 원격 측정 데이터가 부족했음을 의미합니다. 이 순환 종속성을 제거했습니다. 당사의 원격 측정 시스템은 더 이상 모니터링하도록 구성된 시스템에 의존하지 않습니다.
Consul 및 BoltDB 성능에 대한 더 나은 가시성을 제공하기 위해 원격 측정 시스템을 확장했습니다. 이제 시스템이 이러한 중단을 일으킨 상태에 접근하고 있다는 징후가 있는 경우 고도로 표적화된 경고를 수신합니다. 또한 Roblox 서비스와 Consul 간의 트래픽 패턴에 대한 가시성을 높이기 위해 원격 측정 시스템을 확장했습니다. 여러 수준에서 시스템의 동작 및 성능에 대한 이러한 추가 가시성은 시스템 업그레이드 및 디버깅 세션 동안 이미 도움이 되었습니다.
여러 가용 영역 및 데이터 센터로 확장
하나의 Consul 클러스터에서 모든 Roblox 백엔드 서비스를 실행하면 이러한 특성의 중단에 노출되었습니다. 우리는 백엔드 서비스를 호스팅할 지리적으로 다른 추가 데이터 센터를 위한 서버와 네트워킹을 이미 구축했습니다. 이러한 데이터 센터 내에서 여러 가용 영역으로 이동하려는 노력이 진행 중입니다. 이러한 노력을 가속화하기 위해 엔지니어링 로드맵과 직원 배치 계획을 크게 수정했습니다.
영사 업그레이드 및 샤딩
Roblox는 여전히 빠르게 성장하고 있으므로 여러 Consul 클러스터를 사용하더라도 Consul에 가해지는 부하를 줄이고 싶습니다. 우리 서비스가 Consul의 KV 저장소 및 상태 확인을 사용하는 방법을 검토하고 일부 중요한 서비스를 자체 전용 클러스터로 분할하여 중앙 Consul 클러스터의 부하를 더 안전한 수준으로 줄였습니다.
일부 핵심 Roblox 서비스는 Consul의 KV 저장소를 데이터를 저장하기 위한 편리한 장소로 직접 사용하고 있습니다. 비록 우리가 더 적절할 가능성이 있는 다른 저장소 시스템이 있기는 하지만 말입니다. 이 데이터를 보다 적절한 스토리지 시스템으로 마이그레이션하는 중입니다. 완료되면 Consul의 부하도 줄어듭니다.
많은 양의 쓸모없는 KV 데이터를 발견했습니다. 이 오래된 데이터를 삭제하면 영사 성능이 향상되었습니다.
우리는 HashiCorp와 긴밀히 협력하여 BoltDB를 비볼트 무제한 자유 목록 성장과 동일한 문제가 없습니다. 연말 트래픽이 가장 많을 때 복잡한 업그레이드를 피하기 위해 의도적으로 이 작업을 새해로 연기했습니다. 업그레이드는 현재 테스트 중이며 1분기에 완료될 예정입니다.
부트스트랩 절차 및 구성 관리 개선
Roblox 서비스에 필요한 캐시 배치 및 워밍업을 비롯한 여러 요인으로 인해 서비스 복귀 노력이 느려졌습니다. 우리는 이 프로세스를 더 자동화하고 오류가 덜 발생하도록 하기 위해 새로운 도구와 프로세스를 개발하고 있습니다. 특히 캐시 배포 메커니즘을 재설계하여 캐시 시스템을 처음부터 신속하게 시작할 수 있도록 했습니다. 이를 시행하고 있습니다.
우리는 HashiCorp와 협력하여 오랜 기간 사용할 수 없는 대규모 작업을 더 쉽게 시작할 수 있도록 하는 몇 가지 Nomad 개선 사항을 확인했습니다. 이러한 개선 사항은 이번 달 말에 예정된 다음 Nomad 업그레이드의 일부로 배포될 예정입니다.
더 빠른 기계 구성 변경을 위한 메커니즘을 개발 및 배포했습니다.
스트리밍의 재도입
우리는 원래 Consul 클러스터의 CPU 사용량과 네트워크 대역폭을 낮추기 위해 스트리밍을 배포했습니다. 새로운 구현이 워크로드와 함께 대규모로 테스트되면 이를 시스템에 신중하게 다시 도입할 예정입니다.
퍼블릭 클라우드에 대한 참고 사항
이와 같은 가동 중단의 여파로 Roblox가 퍼블릭 클라우드로 이전하고 제XNUMX자가 기본 컴퓨팅, 스토리지 및 네트워킹 서비스를 관리하도록 할 것인지 묻는 것은 자연스러운 일입니다.
Roblox의 또 다른 가치 중 하나는 장기적 관점에서 보는 것이며 이 가치는 우리의 의사 결정에 많은 영향을 미칩니다. 우리는 현재 규모에서, 더 중요하게는 플랫폼이 성장함에 따라 도달하게 될 규모에서 자체적인 기반 인프라를 온프레미스로 구축하고 관리합니다. 이것이 우리 비즈니스와 커뮤니티를 지원하는 가장 좋은 방법이라고 믿기 때문입니다. 특히 백엔드 및 네트워크 에지 서비스를 위한 자체 데이터 센터를 구축 및 관리함으로써 퍼블릭 클라우드에 비해 비용을 크게 제어할 수 있었습니다. 이러한 절감액은 플랫폼에서 크리에이터에게 지불할 수 있는 금액에 직접적인 영향을 미칩니다. 또한 자체 하드웨어를 소유하고 자체 에지 인프라를 구축함으로써 성능 변동을 최소화하고 전 세계 플레이어의 대기 시간을 신중하게 관리할 수 있습니다. 일관된 성능과 짧은 대기 시간은 반드시 퍼블릭 클라우드 공급자의 데이터 센터 근처에 위치하지 않아도 되는 플레이어의 경험에 매우 중요합니다.
우리는 이념적으로 특정 접근 방식에 얽매이지 않습니다. 우리는 플레이어와 개발자에게 가장 적합한 사용 사례에 퍼블릭 클라우드를 사용합니다. 예를 들어, 버스트 용량, DevOps 워크플로의 많은 부분 및 대부분의 사내 분석에 퍼블릭 클라우드를 사용합니다. 일반적으로 퍼블릭 클라우드는 성능과 대기 시간이 중요하지 않고 제한된 규모로 실행되는 애플리케이션에 적합한 도구입니다. 그러나 대부분의 성능 및 지연 시간이 중요한 워크로드의 경우 자체 인프라를 온프레미스에서 구축하고 관리하기로 결정했습니다. 우리는 시간, 돈, 재능이 필요하지만 더 나은 플랫폼을 구축할 수 있다는 것을 알고 이 선택을 했습니다. 이는 Take Long View 가치와 일치합니다.
정전 이후 시스템 안정성
Roblox는 일반적으로 XNUMX월 말에 트래픽이 급증합니다. 우리는 해야 할 안정성 작업이 훨씬 더 많지만 Roblox는 XNUMX월 급증 기간 동안 단 한 건의 중대한 생산 사고가 없었으며 이 급증 기간 동안 Consul과 Nomad 모두의 성능과 안정성이 우수했음을 보고하게 된 것을 기쁘게 생각합니다. 즉각적인 안정성 개선이 이미 성과를 거두고 있는 것으로 보이며 장기 프로젝트가 완료되면 더 나은 결과를 기대합니다.
생각을 폐쇄
이해와 지원을 아끼지 않은 글로벌 Roblox 커뮤니티에 감사드립니다. Roblox의 또 다른 가치 중 하나는 책임을 지는 것이며 여기서 일어난 일에 대해 전적으로 책임을 집니다. HashiCorp 팀에 다시 한 번 진심으로 감사드립니다. 그들의 엔지니어들은 이 전례 없는 정전이 시작될 때 우리를 돕기 위해 뛰어들었고 우리 곁을 떠나지 않았습니다. 몇 주 뒤에 정전이 발생한 지금도 Roblox와 HashiCorp 엔지니어는 계속 긴밀하게 협력하여 유사한 정전이 다시 발생하지 않도록 우리가 할 수 있는 모든 일을 다하고 있습니다.
마지막으로 이곳이 일하기 좋은 곳인 이유를 확인해 준 Roblox 동료들에게 감사드립니다. Roblox는 예의와 존중을 믿습니다. 일이 잘 풀릴 때 예의 바르고 예의를 갖추는 것은 쉽지만 실제 시험은 일이 어려울 때 서로를 어떻게 대하느냐 입니다. 73시간의 정전 중 시간이 촉박하고 스트레스가 쌓이는 동안 누군가가 냉정을 잃거나 무례한 말을 하거나 이 모든 것이 누구의 잘못인지 큰 소리로 궁금해하는 것을 보는 것은 놀라운 일이 아닙니다. 그러나 그것은 일어난 일이 아닙니다. 우리는 서로를 지원하고 서비스가 건강해질 때까지 XNUMX시간 한 팀으로 함께 일했습니다. 물론 우리는 이 정전과 그것이 우리 커뮤니티에 미친 영향을 자랑스럽게 생각하지 않지만, are Roblox에 생명을 불어넣기 위해 한 팀으로 뭉친 것을 자랑스럽게 생각하며, 그 과정에서 매 단계마다 예의와 존중으로 서로를 대하는 방법을 자랑스럽게 생각합니다.
우리는 이 경험을 통해 엄청나게 배웠고 앞으로 Roblox를 더욱 강력하고 안정적인 플랫폼으로 만들기 위해 그 어느 때보다 헌신하고 있습니다.
다시 한번 감사드립니다.
¹ 이 블로그 게시물의 모든 날짜와 시간은 태평양 표준시(PST)를 기준으로 합니다.
Source: https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/
