로드를 쉽게하기 위해 단일 샤드 또는 영역에 대한 처리를 여러 서버에서 수행 할 수 있어야한다는 것이 MMO의 일반적인 요구 사항이라고 생각합니다. 모든 플레이어와 모든 NPC가 상호 작용할 수있는 통합 된 일관된 세계를 유지하면서 어떻게이 작업을 수행 할 수 있는지 궁금합니다.
내 질문은 MMO에서로드 밸런싱이 어떻게 이루어 집니까?
이 주제에 대한 나의 지식을 향상시키는 방법에 대한 모든 링크, 서적 또는 일반 정보도 높이 평가됩니다.
로드를 쉽게하기 위해 단일 샤드 또는 영역에 대한 처리를 여러 서버에서 수행 할 수 있어야한다는 것이 MMO의 일반적인 요구 사항이라고 생각합니다. 모든 플레이어와 모든 NPC가 상호 작용할 수있는 통합 된 일관된 세계를 유지하면서 어떻게이 작업을 수행 할 수 있는지 궁금합니다.
내 질문은 MMO에서로드 밸런싱이 어떻게 이루어 집니까?
이 주제에 대한 나의 지식을 향상시키는 방법에 대한 모든 링크, 서적 또는 일반 정보도 높이 평가됩니다.
답변:
이것을 가능한 한 단순하게 유지 하고 인터페이스를 잘 정의하고 문서화하십시오. 프로덕션 환경에서 복잡한 시스템을 유지 관리하고 디버깅하면 쉽게 지옥으로 변합니다. 따라서 간단하고 복잡한 접근 방식이 있다면 복잡한 방법을 사용하기 전에 두 번 생각하십시오.
첫 번째 단계는 정적 콘텐츠, 인증, 로컬 채팅, 글로벌 채팅 채널, 지역 채팅 채널, 친구 목록, 길드, 가방 / 인벤토리, 경매장, 세계지도, 세계 등 서비스와 그 종속성 을 식별하는 것입니다 .
그런 다음 각 서비스에 대해 고객 이 직접 대화 할 수 있는지 결정했습니다 . 예를 들어, 클라이언트가 글로벌 채팅 채널을 담당하는 서버와 직접 대화하게하는 것은 매우 쉽습니다. 월드 서버는 채팅 메시지에 전혀 관여하지 않아도됩니다. 지역 채팅은 같은 방식으로 구현할 수 있지만 월드 서버는 플레이어가 지역을 변경할 때 채팅 서버에 알려야합니다. 다시, 그들은 메시지에 신경 쓸 필요가 없습니다.
세 번째 단계는 서비스 내에서로드 밸런싱 에 대해 생각하는 것 입니다. 예를 들어 글로벌 및 지역 채팅 채널은 이름을 기준으로 여러 서버로 나눌 수 있습니다. 이 분할을 클라이언트로 하드 코딩하지 않고 조회 서비스를 제공하는 것이 좋습니다.
가장 어려운 부분은 일반적으로 세계 서버 이므로 간단한 접근 방식으로 시작합니다. 클라이언트가 자신이 속한 지역을 담당하는 서버와 직접 대화하게하는 것이 좋습니다. 따라서 로그인 또는 교차하는 지역에서는 클라이언트에게 연결할 서버를 알려 주어야합니다.
간단한 접근법은 세계를 독립된 지역 으로 나누는 것입니다 . 독립적 인 지역을 사용하면 플레이어가 한 부분에서 다른 부분을 볼 수 없으며 괴물은 부분을 교차 할 수 없습니다. 이러한 지역은 외부 세계의 풍경과 이야기를 바탕으로 플레이어가 보는 지역과 다릅니다. 일반적으로 대부분의 몬스터는 지하 감옥에 있으며 플레이어는 지하 감옥에 들어가기 위해 출입구를 걸어야한다는 것을 받아들이는 경향이 있습니다. 특히 해당 던전이 플레이어 그룹별로 인스턴스화되는 경우. 외부 세계의 다른 예는 높은 산으로 둘러싸인 다른 대륙과 계곡입니다.
연속 세계 가 잘 계획하는 의미가 있으므로 접근 방식은 정말 빠르게 복잡한 가져옵니다 정보가 클라이언트의 필요성을 무엇? 서버는 어떤 정보를 공유해야합니까? 플레이어는 대부분 같은 지역에있는 개체 (몬스터와 NPC 포함) 와만 상호 작용합니다. 영역 경계에서 클릭 범위를 벗어난 개체를 배치하여 속임수를 쓸 수 있습니다. 이는 클라이언트가 주로 주변 영역에 대한 읽기 전용 정보에 관심이 있음을 의미합니다. 이러한 경우 영역 서버는 플레이어가 인접 영역에 연결할 수있을만큼 근접한 권한 검사를 제외하고는 아무것도 조정할 필요가 없습니다.
따라서 개체 또는 작업이 서버 경계를 넘어야하는 매우 어려운 경우 가 거의 없습니다 . 화살이나 주문과 같은 경우 성능이 중요하기 때문에 좋은 것입니다. 전투를 공격과 방어로 나누는 것이 좋습니다. 따라서 주문 캐스터의 서버는 캐스터의 위치를 포함한 공격 매개 변수를 정의합니다. 방어자의 서버는 공격에 대한 메시지를 받고 영향을 계산합니다. 침입자의 서버는 그 영향에 대해 알 필요가 없습니다. 클라이언트는 그의 읽기 전용 연결을 사용하여 그것에 대해 배울 것입니다.
플레이어 모델이 얼마나 복잡한 지에 따라 다른 서버로 전송하는 데 몇 초가 걸릴 수 있습니다 (Second Life에 큰 문제가 있음). 플레이어가 가상 경계에 가까워 질 때 전송 을 미리 준비하면 문제를 완화 할 수 있습니다 . 따라서 실제 핸드 오버가 발생할 때 대부분의 플레이어 데이터가 대상 서버에 이미 캐시되어 있습니다.
거의 의존하지 않고 여러 서버로 나눌 수있는 다른 서비스를 정의하여 문제를 나눕니다. 다음 단계로 중요한 서비스 내에서로드 밸런싱을 수행하는 방법을 살펴보십시오. 클라이언트가 관련 서버에 직접 연결하도록 지시하여 클라이언트에 대한 밸런싱 작업을 위임합니다 (물론 서버가 권한을 확인해야 함). 가능한 간단하게 유지하고, 다양한 서비스 및 서버의 책임을 잘 문서화하고, 디버그 출력을 가능하게하는 옵션을 제공하십시오.
PS : 이러한 기술 중 일부는 신뢰성을 향상시키는 데 사용될 수 있습니다. 많은 서버를 사용하면 문제가 발생할 위험이 훨씬 높아 지므로이 점을 명심해야합니다. 소프트웨어뿐만 아니라 하드웨어 수준에서도 마찬가지입니다.
일반적으로 세계는 여러 개의 작은 지역으로 나뉩니다. 이러한 각 지역은 일반적으로 독립 서버 프로세스 (WoW의 세계 서버 또는 Eve의 Sol 노드)이며 여러 시스템에서 실행될 수 있습니다. 일부 게임에서는 맵 (Eve, STO, Guild Wars) 사이에 명시적인 문이있는 반면, 다른 게임에서는이를 더 많이 가리려고합니다 (WAR, Free Realms). 보다 원활한 접근 방식을 선택하는 사용자는 일반적으로 두 서버 사이의 경계에 근접하고 두 프로세스가 핸드 오프를 협상 할 때이를 감지합니다. 아마도 이것에 대한 설명을 찾는 가장 좋은 곳은 셀 타워가 움직이는 핸드셋의 핸드 오프를 수행하는 방법입니다. 단일 맵 (Jita, Ironforge, Earth Space Dock)의로드가 실제로 커지면 개별 기능을 다른 서버 (AI, 플레이어 관리의 특정 부분)) 그러나 이것은 처음부터 내장되어 있거나 심각한 개조가 필요합니다. 적은 수의 맵에 전용으로 더 나은 하드웨어를 구입하는 것이 거의 항상 비용 효과적입니다.
로드를 쉽게하기 위해 단일 샤드 또는 영역에 대한 처리를 여러 서버에서 수행 할 수 있어야한다는 것이 MMO의 일반적인 요구 사항이라고 생각합니다. 모든 플레이어와 모든 NPC가 상호 작용할 수있는 통합 된 일관된 세계를 유지하면서 어떻게이 작업을 수행 할 수 있는지 궁금합니다.
생각만큼 일반적이지 않을 수도 있습니다. 적어도 하나의 끊김없는 세계가 여러 서버에서 동시에 관리된다고 생각하는 경우에는 그렇지 않습니다.
완전히 별개의 샤드를 세지 않고 온라인 게임을 분할 할 수있는 두 가지 방향이 있습니다.
분명히 이러한 접근 방식은 직교하며 두 가지를 결합 할 수 있습니다. 실제로 게임 서버와는 별도로 별도의 데이터베이스 서버를 사용하는 것이 필수적이며, 게임 세계와 관계없이 채팅 및 기타 중요하지 않은 통신을 차단하는 것이 일반적입니다. 분할됩니다.
그러나 전체적으로 지리적 분할이있을 경우 대부분의 게임은 이러한 경계를 넘어 상호 작용할 수 없습니다. 대신, 실제로는 그렇지 않을 때 모두 동일한 샤드와 동일한 서버에있는 것처럼 보이게 하는 다른 방법을 사용합니다 . 예. -영역 간 또는 한 대륙에서 다른 대륙으로 전환 할 때 서버 변경 사항을 다루는 화면 또는 기타 애니메이션로드 -다른 사람과 격리 된 별도의 던전이나 레이드 인스턴스. 이들은 샤드 내의 샤드와 같으며 별도의 서버에서 쉽게 실행할 수있어로드 균형 조정에 도움이됩니다.
나는 WoW에 대한 권위와 대화 할 수는 없지만, 거의 모든 것을 수행하고 있다고 생각합니다. 와우 (WoW) 영역에는 특정 영역에서 한 번에 1000 명에서 10000 명의 플레이어가 온라인에있는 것으로 들었습니다.
그러나 하나의 거대한 세계가 있고 한 서버의 플레이어가 인접한 서버의 플레이어와 상호 작용할 수 있어야한다고 가정 해 봅시다. 이론 상으로는 쉽게 할 수 있습니다.-먼저 서버는 경계를 따라 객체의 세부 정보를 공유하기 위해 협력해야합니다 (따라서 한 서버의 객체가 다른 서버의 프록시 표현을 가질 수 있음). 필요한 경우 프록시에서 신뢰할 수있는 소스로 다시 라우팅되는 메시지 메시지는 서버간에 또는 서버 내에서 상당히 투명하게 전달 될 수 있으므로 한 가지 접근 방식이 모든 시스템에 적합합니다.
여기서 문제는 이전의 간단한 로직이 메시지로 변환 될 때 매우 복잡해질 수 있다는 것입니다. 두 명의 플레이어가 한 서버에있을 때 안전하고 원자 적으로 발생할 수있는 2 플레이어 거래는 메시지를주고받을 때, 각 보내기에서 다시 확인해야 할 때, 그리고 한 플레이어가 악용 할 수 없도록 보호 수단을 마련 할 때 더 긴 프로세스가됩니다. 메시지가 여행하는 동안 거래를 변경하여 다른 하나. 메시지가 도착할 때까지 (죽거나 로그 아웃하는 등) 다른 플레이어가 여전히 존재한다고 가정 할 수 없으므로 코드가 매우 복잡해집니다. 그리고 이것은 거래, 전투, 그룹화, 경매, 전리품 공유, 훈련 등 2 개 이상의 단체가 상호 작용하거나 협력 할 수있는 거의 모든 시스템에 적용됩니다.
이러한 문제는 극복 할 수 없지만 대부분의 게임에서는 다른 수단을 통해 부하를 공유하고 모든 게임 논리를 한 서버에 유지할 수있을 때 시도해 볼 가치가 없습니다. 따라서 거의 모든 현재 게임이 대신 해당 경로로 내려갑니다.
처리 할 데이터의 범위가 매우 넓기 때문에 MMO 서버의로드 밸런싱 방법에는 여러 가지가 있습니다. 프로세스 빈 트리 방법을 선호합니다.
글로벌 서버는 여러 사용자를 한 번에 처리 할 수있는 프로세스 저장소로 사용자 연결을 전달합니다. 프로세스 빈은 모든 복잡한 처리를 수행하며 글로벌 채팅 및 위치 지정과 같이 전 세계적으로 관련된 데이터로만 글로벌 서버에 응답합니다. 이 방법은 지역 서버에 비해 훨씬 균형이 잘 잡 힙니다. 지역은 인구에 따라 크게 다를 수 있지만 전체 사용자 처리는 자연스럽게 균형을 잡을 수있을 정도로 다양합니다.
프로세스 빈이 특정 메모리 / CPU 사용량에 도달하면 새 프로세스 빈 서버를 시작하므로 전역 서버를 통해 기본로드 밸런싱을 수행하십시오.