거대한 단일 MMORPG 서버

2019년 9월 21일에 데브루키 521회에서 발표한 자료입니다.

거대한 단일 MMORPG 서버

marsettler.com


이야기할 내용

  1. 거대한 단일 MMORPG 서버
  2. 기획 고려사항
  3. 서버 고려사항과 해법
  4. 데이터베이스 고려사항과 해법
  5. 마무리하며

1. 거대한 단일 MMORPG 서버

는 정확히 무엇을 말하는 건가요?


MMORPG를 먼저 정의해 봅시다

대규모 다중 사용자 온라인 롤플레잉 게임

World of Warcraft, EVE Online, 듀랑고, 검은사막,


엔지니어링 측면에서 MMORPG 서버

한 지역 내에서 X명의 유저가 상호작용

X가 어느 정도이면 MMORPG 일까요?

이 발표는 수백에서 수천명으로 가정합니다


그러면 거대한 단일 MMORPG 서버란?

일반적인 서버와 가장 큰 차이는

서버들 사이에 있는 물리적인 격리


일반적인 MMORPG는

성능한계 해소를 위해 물리적으로 격리된 서버를 운영

서로 다른 서버의 유저는 상호작용할 수 없음


거대한 단일 MMORPG 서버는

이런 상호작용의 한계를 극복한 서버


잠깐 용어 정리

  • 월드: 게임이 구현한 세상 전체
  • 노드: 단일 물리서버
  • 클러스터: 노드의 모음
  • 지역: 노드 안에 있는 일정 지역

사례 1.

  • 동시에 한 노드에서 플레이 가능한 유저 수: 10,000여명
  • 노드간 데이터를 공유하여 언제든지 옮겨 다닐 수 있음

사례 2.

  • 동시에 한 지역에서 플레이 가능한 유저 수: 100명
  • 이벤트가 발생할 때마다 100명의 유저를 모아줌
  • 가까운 관계의 유저는 이벤트 발생 시 같은 지역을 선택 가능

사례 3.

  • 동시에 한 노드에서 플레이 가능한 유저 수: 거의 무한대?
  • 좁은 지역에 많은 유저가 모이면 해당 지역의 시간이 느리게 감

사례 4.

  • 한 노드에서 플레이 가능한 유저 수: 100여 명
  • 유저가 늘어나면 노드가 늘어나고 노드간 이동이 어느정도 자유로움

이 사례 모두를

거대한 단일 MMORPG 서버로 정의하고

일반적인 고려사항

해결법들을 알아보겠습니다.


2. 기획 고려사항


늘어나는 유저에 따른 인구밀도 증가

  • 채널 방식
    • 다수의 게임이 쉽게 채용하고 있는 방식
    • 한 지역을 유저들이 직접 상호작용할 수 없는 여러 채널로 분리
  • 절차적 지역 생성
    • 지역을 정해진 규칙에 따라 절차적으로 생성

특정 자산(부동산, 랭킹 등)의

희소성이 너무 높아짐


기존의 운영 노하우 적용 불가

신규유저의 격차를 줄이기 위한 신서버 오픈 등


기획 고려사항은

기본만 알아보고 넘어갑니다


3. 서버 고려사항과 해법


매우 단순화된 서버 구조

클라이언트 🤝 서버 🤝 데이터베이스


서버를 확장할 때 선택지

  • 스케일 업 (단일장비 성능 개선 / 물리적 한계 명확)
  • 스케일 아웃 (여러 장비를 사용해서 부하분산)

거대한 단일 MMORPG 서버는

궁극적으로 스케일 아웃을 필요로 함


HTTP 기반의 서비스들은 게임에 매우 자연스럽게

스케일 아웃을 합니다. 왜 그럴까요?


HTTP 기반의 서버는 기본적으로

스테이트리스(상태가 없음)

엄밀히 따지면 다른 무언가에게 위임
(데이터베이스, 캐시 등)

TCP 기반의 MMORPG 서버도

스테이트리스하게 만들 순 없을까요?

상태를 매우 자주 변경하기 때문에 쉽지 않음


그렇다면 상태변경이 자주 일어나는 부분과

그렇지 않은 부분을 분리하면 어떨까요?


상태변경이 자주 일어나는 부분

  • 현재 HP
  • 지역 내에서 이동중인 발사체
  • 남은 총알의 수
  • 등등등…

상태변경이 자주 일어나지 않는 부분

  • 나의 모든 아이템 목록
  • 나의 모든 퀘스트 목록
  • 하루에 한 번 변경되는 이벤트 목록
  • 등등등…

사실 우리는 근 몇 년간의 개발에서

이미 많은 경험을 쌓음

인게임

아웃게임


그렇다면 스테이이트풀한 부분(지역)은

어떻게 관리할까요

지역이 다르면 물리적으로 분산된 장비에서 동작


지구 지역에서 화성 지역으로의 이동은

어떻게 처리할까요?


게임의 특성에 따라 달라지지만

일반적으로 둘 중 하나를 선택해야 함

  1. 특정 서버가 다운되면 유저 플레이 불가
  2. 한 유저가 동시에 두 지역에 있는 것을 허용

월드의 구성

  • 심리스가 아닌 월드
  • 심리스 월드

심리스가 아닌 월드

  • 지역 간 이동시 멈춤과 로딩이 발생

  • 다른 지역 유저끼리 직접적인 상호작용 불가능


심리스 월드

  • 지역 간 이동시 멈춤과 로딩이 없음

  • 다른 지역 유저끼리 직접적인 상호작용 가능


심리스 월드 사례를 찾아보면

단일 물리장비에서

여러 코어를 효율적으로 사용하는 것에 초점

여러 물리장비를 이용한 심리스 월드 구현?


적용범위를 물리엔진으로

한정해서 고민


물리엔진 동작(매우 간략화한)

  1. 오브젝트를 수집(이 부분만 공유하면?)
  2. 물리 데이터를 계산
  3. 데이터 기반으로 오브젝트를 업데이트

데모

https://github.com/hueypark/marsettler/tree/0.1


예상되는 고려사항

  • 네트워크 부하
  • 멀티쓰레드 환경에서 발생하는 이슈의 극대화

4. 데이터베이스

고려사항과 해법


데이터베이스의 스케일아웃의 경우

이미 여러 도메인에서 많은 연구가 진행됨


많이 사용되는 옵션은 크게 두 가지

  • RDBMS 사용하며 스케일아웃(샤딩)과, 분산 트랜잭션 직접 처리
  • NoSQL 사용(이벤츄얼 컨시스턴시 고려 필요)

RDBMS의 사용하며 스케일아웃(샤딩)과, 분산 트랜잭션 직접 처리


샤딩은 같은 테이블 스키마를 가진 데이터를

다수의 데이터베이스에 분산하여 저장하는 방법


고려사항

  • 유저의 데이터를 어떤 데이터베이스에 저장?
  • 특정 데이터베이스에 부하가 몰리지 않게 하는 방법?
  • 등등…

그래도 스케일아웃의 경우

범용적인 해법이 어느정도 정해져 있음

스케일인이 필요한 상황? (빠르게 도주합니다.)


분산 트랜잭션

트랜잭션은 논리적 묶여진 단위작업으로

데이터베이스가 제공하는 기능이지만,

2개 이상의 물리장비에서는 직접 구현 필요


예: 유저간 거래

  1. A 유저 아이템 지급 (직후에 장애가 발생하면?)
  2. B 유저 아이템 제거
  3. A 유저 돈 감소
  4. B 유저 돈 증가

이런 방법은 어떨까요?

  1. BEGIN: 작업시작
  2. END: 작업종료
  3. PREPARE: 준비
  4. COMMIT: 커밋

예: 유저간 거래 2

  1. BEGIN
    • A 유저 아이템 지급하고 비활성화
    • A 유저 아이템 활성화 로그 추가
    • B 유저 아이템 비활성화
    • B 유저 아이템 삭제 로그 추가
    • A 유저 돈 감소용 로그 추가
    • B 유저 돈 증가용 로그 추가
  2. END
  3. PREPARE
    • 로그가 정상적으로 기록되었는지 확인
  4. COMMIT
    • 관련 데이터를 락하고 적용
    • 중도에 실패시 로그 기반으로 모두 롤백

동작할까요?

실제 서비스에는 더 많은 예외상황이 있음

개발 난이도 급상승


NoSQL 사용

  • NoSQL을 한 마디로 정의하긴 어려움
  • 일반적인 특징으로 수평 확장이 가능하지만 이벤츄얼 컨시스턴시에 대한 고려가 필요

이벤츄얼 컨시스턴시?

한국어로는 최종 일관성이나,

궁극적 일관성으로 불리기도 함

뭔가 멋져보이는 이름이지만 사람 잡는 동작방식


극단적인 예

  1. 보유 골드 1000
    • 1번 서버의 사냥으로 골드 100을 획득 1100
    • 2번 서버의 유저에게서 100원짜리 검 구매 900
  2. 음?

이처럼 단순한 예는 프로그래머가 통제할 수 있겠지만

MMORPG는 매우 다양한 컨텐츠를 가지고 있음


이벤츄얼 컨시스턴시 풍자


어떤 방식을 사용하던

이 문제들을 모두 해결해야 함

누가? 프로그래머가!

그러면 기능은 누가?


또 다른 해법


카크로치디비!

오픈소스로 작성된, 클라우드 기반의 SQL 데이터베이스

스케일 아웃, ACID 트랜잭션의 강한 일관성, SQL 제공

https://github.com/cockroachdb/cockroach


NewSQL이라고 불리는

유사한 제품이 여러 개 있음

선택은 당신의 몫

NoSQL이라고 불리는 데이터베이스들이 얼마나 서로 다른지 고려해보기 바랍니다.


마무리하며

  1. 거대한 단일 MMORPG 서버
  2. 기획 고려사항
  3. 서버 고려사항과 해법
  4. 데이터베이스 고려사항과 해법

누구나 그럴싸한 계획을 가지고 있다. 얼굴에 한방 쳐맞기 전까지는.


감사합니다.

marsettler.com