MMORPG 서버 유지 보수

대부분의 MMORPG 게임은 매일 정기적으로 서버를 유지 관리하는 것으로 보입니다. 그들이 실제로해야 할 일은 무엇이며 왜 필요한가?

그러한 프로젝트로 시작한다면 이것을 피하기 위해 무엇을 할 수 있습니까?

나는 그들이 코드의 최신 버전을 배포하고 있다고 생각합니다. 이러한 관점에서 볼 때 StackOverflow 문제가 많고 ServerFault 문제가 적습니다.

핫 패칭 시스템을 만드는 것이 가능하다고 생각하지만 필연적으로 복잡 할 것입니다. 내가 이해 한 바에 따르면 MMO 서버 "응용 프로그램"은 여러 구성 요소로 구성됩니다.

• 로그인 서버 -인증을 처리하고 게임 플레이 서버 간의 "허브"역할을합니다. 클라이언트가 게임에 들어가면 더 이상 로그인 서버와 상호 작용하지 않습니다. 이러한 시스템에서는 게임 플레이를 방해하지 않고 패치를 적용하고 로그인 서버를 다시 시작할 수 있습니다 (사람들이 로그인 할 수없는 시간이 있음).

• 게임 플레이 서버 -논리적 독립 유닛 ( "월드"등)으로 그룹화 된 머신 클러스터. 각 게임 플레이 클러스터는 어떤 종류의 내부 통신 프로토콜을 사용하여 상태를 서로 일치시키는 것으로 가정합니다. 각 클러스터를 한 번에 패치해야 할 것입니다. 이를 수행 할 수있는 한 가지 방법은 warm-failover를 패치하는 것입니다. 그러면 둘 다 할 수 있어야합니다

  1. 클라이언트에게 웜 페일 오버에 연결하고 이전 클러스터와의 연결을 끊도록 신호를 보냅니다.
  2. 모든 클라이언트가 전송되는 동안 장애 조치와 오래된 Application Server간에 상태를 동기화 된 상태로 유지하십시오.

• 데이터베이스 서버 -RDBMS와 같은 일종의 영구 데이터 저장소 다행히 데이터 저장소를 자주 변경하지 않기를 바랍니다. 아마도 각 게임 플레이 서버 / 클러스터에는 독립적 인 데이터 저장소가 있습니다. 따뜻한 장애 조치와 동일한 트릭을 사용할 수 있으며 게임 플레이 서버에 연결을 끊고 이전 데이터베이스와 장애 조치 데이터베이스가 동기화 될 때까지 기다렸다가 장애 조치에 다시 연결하도록 지시 할 수는 있지만 꽤 위험합니다.

위의 모든 경우는 이미 복잡한 시스템에 엄청난 양의 복잡성을 추가하고 코드 오류로 인해 데이터가 손실되거나 손상 될 수있는 곳을 소개합니다.

또 다른 해결책은 100 % 가동 시간을 위해 설계된 언어를 사용하는 것입니다. 실행 코드 핫 패칭을위한 내장 기능이 있습니다. Erlang 은 좋은 선택 ( 핫 패칭 예제 )이며 Java는 비슷한 기능을 가지고 있습니다 .

실제로 다른 사람과 같은 경험을 한 사람이 있습니까? 허.

코드와 시스템을 모두 연결하는 데는 몇 가지 이유가 있습니다. 첫째, 현재의 '큰'MMO 엔진의 대부분은 몇 년 전에 프로그래밍되었으며, 그래픽 및 기술 업그레이드에도 불구하고 2000 년 정도에 이러한 시스템이 작성된 방식에 따라 달라집니다. 예를 들어, Eve-Online은 여전히 ​​하나의 거대한 Microsoft SQL Server 인스턴스에서 실행되므로 하드웨어를 업그레이드하여 항상 더 많은 것을 끌어 내려고 노력하고 있습니다.

WoW 및 EVE가 시작된 이후 개선 된 예는 Google의 MapReduce (및 오픈 소스 구현, Hadoop)와 같은 분산 키 / 값 데이터베이스, 매우 빠른 긍정적 인 응답 처리 대기열 서비스 (Amazon SQS) 및 기타 " 클라우드 중심 기술.

나는 EVE에 대해 가장 많은 경험을 가지고 있습니다. (전투기보다 레이저가 더 많습니다)이 중 일부는 더 EVE 지향적입니다.

시스템 이유가있는 한 :

• 물리적 노드는 일관되게 실패합니다. 노드가 실패하면 일반적으로 노드의 활동이 여러 수단을 사용하여 다른 곳으로 마이그레이션됩니다. 그러나 가능한 빨리 노드를 서비스 상태로 되돌려 야합니다. EVE의 경우에는 스택리스 처리 언어와 가상 서버를 모두 사용합니다. 블리자드의 아키텍처가 무엇인지 잘 모르겠습니다.
• 데이터베이스 일관성을 확인하고 로그를 비워야하며 인덱스 및 데이터 캐시를 다시 작성해야합니다. 이는 "실시간"데이터베이스 인스턴스가 하나만있는 EVE와 같은 시스템에서 특히 중요합니다.
• 다른 곳으로 마이그레이션하는 데 너무 많은 활동을하지 않고도 노드를 재부팅 할 수있는 운영 체제 패치를 한 번에 적용해야합니다. 마이그레이션은 온라인 처리에 전념 할 수있는 많은 네트워크 리소스를 사용합니다.
• RDBMS 기반 MMO에는 데이터 잠금 및 참조 무결성에 큰 문제가 있습니다. 가동 중지 시간은 활동 로그에서 오래된 잠금 및 무결성 중단을 정리하는 데 사용됩니다.
• 대부분의 게임은 사용량이 많은 지역, 즉 미국 동부 해안과 서해안에서 정적 또는 반 정적 (아래의 요약 데이터 캐싱 참조) 정보에 대해 지리적으로 위치 된 데이터 캐시를 구현합니다. 이러한 캐시는 가동 중지 시간 동안 수동으로 업데이트됩니다.

소프트웨어의 이유는 다음과 같습니다.

• 게임을 운영 할 때는 많은 OLTP (온라인 트랜잭션 처리)를 사용합니다. 데이터베이스에 대한 읽기 / 쓰기 유형입니다. 그러나 때로는 지난 3 년간의 연삭에서 죽인 특정 짐승의 수와 같은 요약 보고서를 원할 수도 있습니다. 그것은 거대한 데이터 세트의 많은 행을 기반으로 한 요약 정보를 포함하는 OLAP 보고서 (온라인 분석 처리)에서 가장 잘 처리됩니다. 실제로 게임은 OLAP을 사용하여 캐시를 작성하여 읽어야하는 쿼리 수를 제한하는 시스템을 구현합니다. 즉, 특정 날짜를 기준으로 총계를 구축 한 다음 질문을하면 행만 읽습니다. 특정 날짜 이후의 기간을 요약 한 OLTP 저장소에서 둘을 합치면 실제로 당신의 인생이 얼마나 가치 없는지 계량화 할 수 있습니다.
• 앞서 언급 한 핫 패치는 소프트웨어 문제로 보지만 소프트웨어 개발자는 시스템 문제로 간주합니다. ;)
• 품목 상점 보충-이브에서는 소행성 벨트가 매일 밤마다 새로 고침되고 특정 복합물도 재활용됩니다. 이것은 온라인 상태에서 어느 정도까지 수행 할 수 있지만 일부 알고리즘은 너무 복잡하여 전날의 경제 활동을 요약하는 동안 데이터베이스를 무릎으로 가져 오기 때문에 오프라인 모드에서 수행해야합니다.

폐쇄 루프와 개방 루프로 경제를 운영하는 것은 MMO 운영자에게는 하나의 문제입니다. 저를 믿지 않는다면 게임 경제에 관한 저술 논문과 Ultima Online과 같은 오래된 게임에 대한 연구를 읽으십시오. 상대적으로 원시 경제가있었습니다. 개방형 루프를 보충하고 부정 행위 및 기타 부정적인 경제 활동을 식별하기 위해 수행해야하는 분석은 데이터 스냅 샷을 사용하여 오프라인에서 수행해야하며, 때로는 데이터베이스가 완전히 잠겨있는 동안에 만 수행 할 수 있습니다.

참고로, Eve의 기본 유지 보수는 기본 데이터 센터가있는 영국의 정오에있을 때 발생합니다.

유지 보수에 대한 블리자드 (귀하가 화요일 아침에 질문을 게시한다고 가정 함)를 인용하는 총 시간은 전체 클러스터에 해당한다고 생각합니다. 모든 서버가 작업을 수행하는 데 시간이 오래 걸리는 것은 아닙니다.

개별 서버를 더 빨리 백업 할 수는 있지만, 일정이 일찍 시작된 영역에 대해서는 플레이어에게 유리한 호기심을 불러 일으킬 수 있습니다. 따라서 모든 작업이 완료 될 때까지 모든 것을 유지합니다. 수백 개의 영역이 작동하므로 아마도 많은 작업을 병렬로 수행하지만 온라인 상태로 되돌리기 전에 최종 점검을 직렬화합니다. 하드웨어 업그레이드를 수행하는 경우 아마도 많은 데이터 센터에서 직렬화 될 수 있습니다.

유지 관리를 수행하는 이유는 성능 재부팅 일 수 있습니다. 재부팅이 필요하지 않으면 좋을 것입니다. 그렇게하는 데 드는 비용과 그렇지 않은 경우의 영향이 여기에서 선택을 지시 할 수 있습니다.

프로세스를 클러스터링 할 수없고 롤링 유지 관리를 수행 할 수없는 이유를 살펴보면 WoW 인프라에 대해 아는 사람들은 여러 시스템이 각 영역 (예 : 전 세계, 인스턴스 및 공격대, 전장, 하나)에 서비스를 제공한다는 사실을 알고 있습니다. 등) 상태 공유 활성-활성 프로세스 설정을 사용하지 않습니다. 라이브 상태 공유는 없으며 데이터베이스를 통한 영구 데이터 만 공유합니다.

결국, 대규모 가입자 기반에 상태 기반 온라인 서비스를 제공하는 메커니즘은 웹 사이트 나 다른 전통적인 인터넷 기반 서비스에 대해 이야기 할 때 우리가 옹호 할 수있는 모범 사례에 도전합니다.

EvE Online에서 최근에 확장 된 다운 타임 중 일부는 더 빠른 SAN과 같은 새 하드웨어를 설치하는 것이 었습니다. 새 드라이브에 새 파일 그룹을 만든 다음 주 파일을 비우면 기술적으로 대량의 데이터를 이동할 수 있지만, 지속적인 I / O로 인해 성능이 크게 저하 될 수 있습니다. 그래서 그들은 선택했습니다 1.1TB 데이터베이스를 분리하고 한 번에 이동할 수 있습니다.

이 질문에 대한 답변은 특정 응용 프로그램에 의존합니다. 예를 들어, 특정 스타 시스템을 처리하는 서버는 게임 플레이를 방해하지 않으면 서 핫스왑 할 수 없으므로 다운 타임은보다 강력한 서버를 잠재적 인 핫스팟에 재 할당하는 데 사용됩니다. 또한 스타 시스템의 소유권 계산 (주권)이 계산됩니다. 이것은 수십 가지 변수에 따라 달라지며, 모두 플레이어 행동에 따라 바뀔 수 있습니다. 말할 것도없이, 라이브를 수행하면 과도한 잠금 및 / 또는 다른 동시성 문제가 발생할 수 있습니다. 하지만 그는 최고의 왼쪽으로 주소 지정 에 유래 .

아마도 주요 DB 스키마 변경과 같은 클러스터링 /로드 밸런싱을 통해 처리 할 수 ​​없었던 것으로 추정됩니다.

최근 주제 리눅스 서버를 얼마나 자주 재부팅해야하는지에 대한 또 다른 좋은 점이 언급되었습니다.

MMORPG 게임에서는 하드웨어의 간단한 업그레이드 (또는 하드웨어 교체)도 "서버 유지 관리"로 표시됩니다. 그래서 우리는 종종 그것을 잊어 버립니다.

Erlang에서 핫 코드 업그레이드 및 배포를 지원하는 MMO 아키텍처를 구현했습니다. 예를 들어, 하나의 "GamePlay Server"는 임의의 수의 머신에서 실행될 수 있습니다. 하드웨어 업그레이드가 필요한 경우 해당 오브젝트를 다른 머신으로 (실시간으로) 전송할 수 있습니다. 따라서 다운 타임없이 소프트웨어 하드웨어를 업그레이드 할 수 있습니다.

http://www.next-gen.cc 에서 내 사이트를 확인할 수 있습니다 .

유지 관리 기간을 통해 정기적 인 하드웨어 교체를 통해 구성 요소가 고장 나지 않도록 할 수 있다고 생각합니다.