MMORPG가 여전히 여러 서버를 사용하는 이유는 무엇입니까?


18

MMORPG, League of Legends 또는 StarCraft 2와 같은 일부 MOBA는 일반적으로 서버를 선택하도록합니다. 일반적으로 위치 당 MMORPG에서 미국, EU 및 SEA입니다. 몇 년 전에 필요했지만 이제는 "서버 성능"을 원활하게 확장 할 수있는 AWS 및 이와 유사한 제품이 등장하면서 왜 별도의 서버가 있습니까?

내 생각의 기차는 다음과 같습니다 (스타 워즈 : 구 공화국을 예로 사용) :-당신은 항상 한 행성에 있으며, 다른 행성과는 격리 된 "인스턴스"입니다. -한 행성에 사람이 너무 많으면 SW : TOR는 새로운 세계를 만들어 플레이어를 그곳에 넣습니다. -월드 / 스위치 인스턴스를 떠나면 로딩 화면이 나타납니다.

게임이 왜이 행성의 인스턴스를 만들 수 없습니까? 이 인스턴스 (및이 인스턴스 만)는 데이터베이스에 현재 데이터가 있으며 x 플레이어를 관리합니다. 이 인스턴스에 x-50 명의 플레이어가 참여하자마자 새 서버가 시작되고 새 인스턴스가 그 인스턴스에 생성됩니다. 그룹 등으로 전환하기 위해 50 개의 지점이 예약되어 있습니다.

대기 시간을 낮게 유지하기 위해 3 개 주요 지역 모두에 대한 인스턴스가있을 수 있지만 140ms 지연 (여전히 아무것도 아님)으로 살 수 있다면 SEA의 다른 플레이어와 계속 플레이 할 수 있습니다.

인스턴스를 전환하거나 다른 세계로 여행 할 때마다 현재 서버는 모든 데이터를 다음 서버에 제공하므로 하나의 큰 중앙 집중식 데이터베이스가 필요하지 않습니다. 분석 목적으로 정기적으로 업데이트되는 업데이트가있을 수 있습니다.

로그 오프하거나 서버의 연결이 끊어지면 데이터 저장에 최적화 된 대규모 데이터베이스로 데이터를 전송할 수 있습니다. 그런 다음 인스턴스 서버를 높은 처리량에 맞게 최적화 할 수 있습니다.

이것이 작동하지 않는 특별한 이유가 있습니까? 누락 된 다른 문제가 있습니까?


많은 게임들이이를 지원하기 위해 엔진의 중간에서 큰 부분을 다시 작성해야한다는 사실은 어떻습니까? 그리고 그 시간과 돈은 더 많은 콘텐츠를 추가하는 데 소비 될 수 있습니다.
Xavon_Wrentaile

기존 게임의 변경을 제안하지는 않았지만 디자인이 처음 시작된 방식으로 선택된 이유는 훨씬 더 많았습니다.
mmlac

답변:


12

MMORPG, League of Legends 또는 StarCraft 2와 같은 일부 MOBA는 일반적으로 서버를 선택하도록합니다. 일반적으로 위치 당 MMORPG에서 미국, EU 및 SEA입니다. 몇 년 전에 필요했지만 이제는 "서버 성능"을 원활하게 확장 할 수있는 AWS 및 이와 유사한 제품이 등장하면서 왜 별도의 서버가 있습니까?

AWS는 그다지 명백한 해결책이 아닙니다. 경우에 따라 사내 데이터 센터를 사용하는 것보다 비싸고 비용이 많이들 수 있습니다 (예 : 게시자의 경우 여러 제품에서 비용이 상각 될 수 있음). 또한 민감한 바이너리와 로그를 자신이 통제 할 수없는 하드웨어에 저장하는 것에 대한 우려가있을 수 있습니다. 마지막으로, 실제 계산 능력이 MMO에서 "서버"모집단을 분리하는 이유는 아닙니다.

내 생각의 기차는 다음과 같습니다 (스타 워즈 : 구 공화국을 예로 사용) :-당신은 항상 한 행성에 있으며, 다른 행성과는 격리 된 "인스턴스"입니다. -한 행성에 사람이 너무 많으면 SW : TOR는 새로운 세계를 만들어 플레이어를 그곳에 넣습니다. -월드 / 스위치 인스턴스를 떠나면 로딩 화면이 나타납니다.

실제로 Guild Wars 2는 이와 매우 유사한 기능을 수행합니다. 맵은 개별 서버 프로세스로 시뮬레이션되며 맵 채우기 제한 및 맵 성능에 대한 일부 추론에 따라 필요에 따라 오버 플로우 인스턴스가 작성됩니다.

Guild Wars 2에는 미국과 유럽에 각각 2 개의 주요 데이터 센터가 있습니다.이 데이터 센터 사이에는 교차 거래가 있지만 (주로 거래소 및 상거래 시스템의 경우) 일반적으로 해당 구성에 존재합니다. 독일, 프랑스 등은 미국 게임 서버에 더 높은 대기 시간을 겪을 필요가 없습니다. 데이터 센터 내에서 플레이어는 "가정 세계"(또는 고유 한 용어로 "샤드")로 분류됩니다. 그러나 이것이 수행되는 이유 중 하나는 클라이언트가보고 할 수있는 플레이어의 수를 최소화하기위한 것입니다. 더 많은 서버 하드웨어로 확장해도이 문제의 클라이언트 측 측면은 해결되지 않습니다. 추가보고 경로의 서버 측 조합 폭발은 다음과 같습니다.

이것이 작동하지 않는 특별한 이유가 있습니까? 누락 된 다른 문제가 있습니까?

당신은 꽤 많은 것들을 잃어 버렸지 만 그것들은 대부분 세부 사항입니다 (그리고 나는 영업 비밀로 간주되기 때문에 어떻게 처리하는지 설명하지 않을 것입니다). 이러한 수준의 개요 유형 질문과 관련이 없습니다. 귀하의 제안에서 가장 큰 결함은 플레이어가 이전 할 때 플레이어 데이터를 새 서버로 전달하는 것입니다. 이는 확장 성이 좋지 않은 복잡한 문제이므로 실제로는 중앙 집중식 서버 시스템에 해당 플레이어 데이터를 보유하는 것이 좋습니다. 해당 데이터베이스와 데이터에 기본 런타임 레코드 저장소를 사용하지 않으면 가능합니다.


@Josh, 배포 권한도 전 세계의 개별 지역에 대해 별도의 서버를 만들고 유지하기로 결정한 데 큰 영향을 미칩니다.
Trevor Powell

무슨 뜻인지 잘 모르겠습니다. 가격 조정을 위해 EU 버전을 다른 SKU로 제시하는 것에 대해 이야기하고 있습니까?

7

대부분 대기 시간에 관한 것입니다.

첫째, 지리적으로 가까운 곳에 서버를두면 대기 시간이 줄어 듭니다. 서버가 세계의 다른쪽에 있다면 서버가 몇 홉 떨어져있는 것보다 대기 시간이 길어집니다.

둘째, AWS와 같은 서비스는 실시간 작업을 위해 설계되지 않았습니다. 약간의 대기 시간을 희생하면서 높은 처리량을 제공하도록 설계되었습니다. 한 번에로드하는 데 웹 페이지가 평소보다 250ms 더 오래 걸리더라도 아무도 신경 쓰지 않지만 메시지를 처리하는 데 평소보다 250ms 더 오래 걸리면 게임 플레이에 심각한 영향을 줄 수 있습니다. 이것이 바로 MMO가 거의 항상 전용 하드웨어에서 호스팅되는 이유입니다.

그러나 그것은 또한 게임 디자인에 관한 것입니다. 모든 사람이 같은 세상에있는 것처럼 보이지만 너무 가득 차면 영역을 분할해야하는 경우 사람들은 지정된 모임 장소에서 친구를 찾을 수 없다는 것에 좌절하게됩니다. 이런 종류의 문제는 길드, 대규모 PvP 전투 등으로 확장 될 수 있습니다. 요즘 플레이어는 인스턴스에 익숙하지만 공유해야 할 특정 영역이 있습니다. 서버가 완전히 분리되어 있다면 적어도 여기에 놀라움이 없습니다.

마지막으로 고려해야 할 다른 기술적 문제가 있습니다. 각 인스턴스가 다른 인스턴스와 상당히 격리되어 있더라도 일반적으로 인스턴스간에 통신해야하는 다양한 서비스가 있습니다. 서버 간 통신은 실시간 소프트웨어에서 잘 수행하기 어려우며 과거 MMO에 대한 다양한 악용 및 버그로 이어졌습니다. 특히 권위있는 플레이어 데이터를 서로에게 넘겨주는 것은 위험합니다. 따라서 개발자는 종종주의를 기울이지 않고 서버 간 경계를 명확하게 지정하여 서버 간 트래픽 양을 줄입니다.


"완전히 분리 된 서버가 있다면 적어도 여기에 놀라움이 없습니다." 글쎄, 당신은 단지 친구들과 놀 수 없습니다. SW : TOR에서는 그룹 리더가 어떤 인스턴스인지 알려주며 즉시 전환 할 수 있습니다. 나는 (개인적으로) 이것으로 충분하다고 생각합니다. 기술적 인 통찰력에 감사드립니다. 이것은 당면한 문제를 이해하는 데 정말로 도움이됩니다!
mmlac

1
물론 일부 게임에서는 인스턴스를 전환 할 수 있지만 공유 미팅 및 소셜 영역보다 던전 및 퀘스트 영역에서 훨씬 더 효과적입니다. 궁극적으로 기술적 인 문제는 더 중요합니다.
Kylotan

필립에 대한 나의 의견에서 언급했듯이, 당신이 인스턴스없이 수도와 주요 도시를 운영 할 수 있다고 생각하지 않습니다.
mmlac

3

실제로 나는 대답은 생각 하지 일반적으로 이벤트가 게임의 이러한 종류, 관련 네트워크 또는 관련 구조가 아니라 게임,이 이벤트는 서버에서 연주하는 사람들을위한 가장 편안한 시간대에 따라 시간이 초과되어, 그것은 일반적으로 사람들이 사는 시간대, 따라서 EU 및 미국 등과 관련이 있습니다.

또 다른 이유는 너무 강한 그룹이 있으면 모든 사람이 게임을 엉망으로 만들지 않고 항상 "도전이 덜한"세상으로 옮길 수 있도록 세계를 구분하는 것입니다.

서버 CPU 기능 측면에서 오늘날의 머신은 상당히 강력하지만 한 머신이 처리 할 수있는 기능에는 항상 제한이 있으므로 게임 과부하를 방지하고 사람들이 원하는 월드를 선택할 수 있도록하려면 월드를 구분해야합니다. 친구들과 놀 수 있도록 수평으로 확장하는 것은 기계를 만드는 것의 문제가 아니라 수평으로 확장 된 아키텍처에서 작업 할 수있는 응용 프로그램이 필요하며 수천 개의 "작업"이 서로 영향을 줄 수있는 동시에 쉽지 않은 일입니다. 모든 것을 동기화해야합니다. 여러 컴퓨터에서 그렇게하는 것이 매우 어려울 것이라고 생각합니다.


적어도 SW : TOR에서는 현재 인스턴스에 영향을 미칩니다. 즉, 인스턴스 1에서 죽인 월드 보스는 인스턴스 2에서 여전히 피해를 입지 않고 생성됩니다. 따라서 분리가 이미 완료되었습니다. 파워 측면에서 다른 서버의 이유를 알 수 있지만 벨트 아래에서도 확장이 가능하므로 인위적인 인구 제한이 없습니다. 현지 사람들이 현지 행사에 참석하기 때문에 시간은 걱정할 필요가 없습니다. 온라인 상태 인 경우 왜 가입 할 수 없습니까? 시간대에 맞지 않습니다.
mmlac

나는 EU 시간대 (EU 서버를 만들기 전에)에있는 동안 미국 서버에서 리니지 2를 플레이 했었습니다. 내가 습격과 성 포위에 참여하고 싶다면 오전 3시에 일어나야했습니다. 따라서 시간은 분명히 관심사입니다.

그렇습니다. 잘못된 시간대에 하나의 서버 만있는 경우 시간이 문제가됩니다. 제 생각에는 전 세계 사람들이 온라인에 있습니다. 3am 습격에 참여하고 싶다면 계속하십시오! 지금, 당신은 SOL이고 "당신의"서버 공격이 일어날 때까지 기다려야합니다 – 당신은 시간이없는 오후 10시에 모든 Saturady 일 수 있습니다 – 그러니 오후 3시에 EU 공습에 가십시오. 말이 돼?
mmlac

2

자동 인스 턴싱에 어떤 문제가 있습니까? 위치가 너무 채워지면 1000 명의 플레이어를 10 개의 다른 인스턴스에 넣습니다.

문제는 온라인 게임이 모두 커뮤니티에 관한 것입니다. 전에 만난 사람들과 회의를 예약했다고 가정 해 봅시다. 주어진 시간에 모두있을 때 서로 다른 경우에 서로를 볼 수 없습니다. 그것은 성가 시며 침수를 깨뜨립니다.

어떻게 방지 할 수 있습니까? 각 플레이어를 항상 같은 인스턴스에 두어 다른 플레이어를 한 번 만났을 때 같은 위치에있을 때이 플레이어를 다시 만날 수 있습니다. 다른 인스턴스에 배정 된 플레이어는 절대 만나지 않습니다.

하지만 게임 밖에서 누군가를 만나고 싶을 때는 어떻게해야합니까? 당신이 게임을하도록 초대 한 실제 친구처럼? 그렇게하려면 캐릭터를 만들 때 인스턴스를 선택할 수 있어야합니다. 이름을 기억하기 쉬운 인스턴스 목록과 같습니다. 불행히도, "인스턴스"라는 이름은 일반 사용자와 혼동되는 것 같습니다. 그들은 그 단어에 익숙하지 않습니다. 익숙한 용어를 사용하는 것이 낫지 않습니까? 같은 용어 ... 서버 ?


1
인스턴스와 서버라는 용어를 혼동하지 마십시오. 인스턴스를 사용하면 서로 전환 할 수 있습니다. 서버는 일반적으로 원자 적입니다. 안팎으로 사람들을 만나기 위해 : 모든 사람들을 한 곳에 모으십시오. 그러면 당신의 수도에는 20.000 명의 사람들이있을 것입니다. 동시에. 그것은 작동하지 않거나 바람직하지 않으므로 어쨌든 인스턴스를 만들어야합니다. 내 생각의 기차는 이러한 인스턴스를 서버로 제한하지 않고 전역으로 만드는 것이 었습니다.
mmlac

그러나 요점은 일반적으로 사람들이 의도적으로 공유 된 영역에서 예측 가능한 경험을 갖기를 원한다는 것입니다. 성능상의 이유로 파티션을 분할해야하지만 '모두'와 공유해야하므로 변수 (예 : 인스턴스)가 아닌 고정 파티션 (예 : 서버)이 이상적입니다. 내가 아는 소수의 MMO는 이러한 유형의 영역을 대표 할 것입니다. 커뮤니티와 그룹화 이유로 모든 사람이 모든 사람을 볼 수 있기 때문에 중요합니다.
Kylotan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.