〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3

<야생의 땅: 듀랑고>
서버 아키텍처 Vol. 3
넥슨 • 왓 스튜디오 • 이흥섭
• 지난 이야기
• 서버 아키텍처
• 초반 서버장애
• 회고
• 앞으로

SlideShare에 슬라이드 300장 제한이 생겨서
부득이하게 3부로 나눠서 올렸습니다. 보는 데
불편하시겠지만 양해를 부탁드립니다.

• 회고
• 앞으로
안녕하세요.

• 회고
• 앞으로
〈야생의 땅: 듀랑고〉의
서버 아키텍처를 주제로 발표하는

이흥섭
넥슨 • 왓 스튜디오
sublee
넥슨 왓 스튜디오의
이흥섭입니다.

이흥섭
sublee
반갑습니다.

이흥섭
sublee
이렇게 듀랑고 프로젝트에
관심을 가져주시고

이흥섭
sublee
이 발표에도 많이 참석해 주셔서
정말 감사합니다.

2011-2013 <카트라이더 대시 & 코인러시>
2013-2018 <야생의 땅: 듀랑고> 개발
2018- <야생의 땅: 듀랑고> 라이브
저는 2011년에
넥슨에 입사해서

2013-2018 <야생의 땅: 듀랑고> 개발
처음엔 〈카트라이더 대시 & 코인러시〉
시리즈를 맡았습니다.

2013-2018 <야생의 땅: 듀랑고> 개발
이후 2013년 듀랑고의
프리프로덕션 단계 직후에

2013-2018 <야생의 땅: 듀랑고> 개발
왓 스튜디오에 합류해서

2013-2018 <야생의 땅: 듀랑고> 개발
지금까지 듀랑고 서버를
만들고 있습니다.

NDC14 <야생의 땅: 듀랑고> 서버 아키텍처
NDC16 <야생의 땅: 듀랑고> 서버 아키텍처 Vol. 2
그동안 전 2년 주기로
NDC에 참여해서

〈야생의 땅: 듀랑고〉의
서버 아키텍처 발표를 진행해 왔습니다.

앞선 두 발표에는 저희의
꿈과 야망을 많이 담았었는데

이번 세 번째 발표는 혹독했던 출시와
라이브 경험을 토대로 준비해봤습니다.

저희가 출시하는 과정에서 겪었던
다양한 일들에 대해서

궁금해 하셨던 분들이
많을 것 같은데

공개할 수 있는 선에서
여러분께 저희의 속사정을

자세히 공유하기 위해서
이 발표를 진행하게 됐습니다.

다룰 내용
•지난 이야기
•서버 아키텍처
•초반 서버장애
•회고
•앞으로
오늘 발표에선
이런 내용을 다룹니다.

다룰 내용
•지난 이야기
•회고
•앞으로
우선 그동안 저희가 만들어온
서버 아키텍처의 최종 모습을

다룰 내용
•지난 이야기
•회고
•앞으로
자세히 살펴볼 겁니다.

다룰 내용
•지난 이야기
•회고
•앞으로
그러고 나서
출시 직후에 겪었던

다룰 내용
•지난 이야기
•회고
•앞으로
서버장애의 내용과
대응 과정

다룰 내용
•지난 이야기
•회고
•앞으로
그 배경에 있었던
원인에 대해서 짚어봅니다.

다룰 내용
•지난 이야기
•회고
•앞으로
마지막으론 앞으로
듀랑고의 서버가

다룰 내용
•지난 이야기
•회고
•앞으로
어떤 방향으로 나아갈지
말씀드리겠습니다.

“서버”
본격적인 발표로 넘어가기에 앞서
이 발표의 주제가 서버인 만큼

“서버”
여러가지 용도로
모호하게 쓰일 수 있는

“서버”
"서버"라는 단어를 좀 더
세부적으로 정의해볼까 합니다.

“서버”
클라이언트 서버
"서버"란 클라이언트가
서비스를 이용하기 위해

“서버”
클라이언트 서버
접속하는 프로그램입니다.

“서버2”
아시아 알파(혼잡) 아시아 브라보 아시아 찰리
하지만 온라인게임에서
가장 대중적으로는

“서버2”
가입할 때 고르는
"1서버", "2서버" 같이

“서버2”
서로 격리된 세계를
"서버"라고 부르곤 합니다.

“서버2”
이걸 "월드"나 "세계"라고
따로 표현할까 고민하기도 했는데

“서버2”
잘 와닿지 않아서 그냥
"서버"로 표현하기로 했습니다.

“서버2”
장르에 따라서는 서버 구분을 두지 않는
온라인게임도 있긴 하지만

“서버2”
통신 속도나 서버 성능 상의 이유로
나눠 두는 경우를 많이 볼 수 있습니다.

“서버2”
플레이어들끼리 서로 상호작용하는
멀티플레이어 요소는

“서버2”
한 서버 내에서만 이뤄지기 때문에
서버가 다른 친구와는

“서버2”
직접적인 상호작용을 할 수 없거나
상당히 제한되게 됩니다.

“서버2”
듀랑고에서는 현재
알파/브라보/찰리/델타/에코

“서버2”
이렇게 5개의 서버를
운영하고 있습니다.

“노드”
노드클라이언트
(서버 프로세스)
"노드"는 서버 프로그램을
구동하는 프로세스입니다.

“노드”
트래픽이 적고
목표가 간단한 서버일 경우

“노드”
단일 노드로
처리되는 경우도 있지만

“노드”
노드 노드
노드
클라이언트
트래픽이 많거나
목표가 복잡한 서버에선

“노드”
노드 노드
노드
클라이언트
보통 클라이언트와 직접
통신하는 노드 외에도

“노드”
노드 노드
노드
클라이언트
다양한 노드가 서로 연결돼서
협력하는 구조를 갖는 경우가 많습니다.

“호스트”
노드
10.123.4.56
이런 노드를 돌리는 컴퓨터를
"호스트"라고 부릅니다.

“호스트”
노드
10.123.4.56
호스트는 데이터센터에 직접 구축한
물리적인 컴퓨터일 수도 있고

“호스트”
노드
10.123.4.56
클라우드 인프라에서 돌아가는
가상컴퓨터일 수도 있습니다.

“호스트”
노드
10.123.4.56
한 호스트엔 사양에 따라서
여러 개의 노드를 띄울 수 있죠.

“게임서버”
게임서버데이터베이스 메시지큐
하나의 서버에는
게임서버 애플리케이션 이외에도

“게임서버”
DB나 MQ 같은 여러가지 부품이
유기적으로 맞물려서 돌아갑니다.

“게임서버”
그중 저희가 직접 개발하는
게임서버 애플리케이션을 따로 지칭할 땐

“게임서버”
"게임서버"라고 명시하겠습니다.

서버 서버2 노드
10.123.4.56
호스트 게임서버
"서버"라고 부를 수 있는
많은 것들 중에서

10.123.4.56
5가지를 구별하고
이름을 정해봤는데요

10.123.4.56
이후 발표 내용에선 이 용어들을
맞춰서 사용하겠습니다.

지난 이야기
우선 지난 두 발표를
간단히 요약해보겠습니다.

2014년
2014년 첫 발표에선

SPOF 없는 MMORPG 서버를
만들겠다는 야망을 드러냈습니다.

"SPOF"는
"Single Point of Failure"의 약자인데요

하나라도 고장나면 전체 서비스가
망가지는 요소를 가리킵니다.

우리말로는 "단일 장애점"이라고
번역하는 것 같아요.

저 개인적으론
이전 게임 프로젝트를 운영할 때

2012년 AWS의 버지니아
데이터센터에서 벌어졌던

폭풍에 의한
정전사고를 겪으면서

다음에 만들 프로젝트에선

노드 하나하나가
어떤 이유로 망가지더라도

서비스 전체의 장애로
이어지진 않도록

만들어야겠다는
꿈을 갖고 있었습니다.

그래서 듀랑고 서버를
구성하는 모든 요소를

빠짐 없이 이중화해서
SPOF를 없애는 데에 도전하게 됐죠.

당시 발표에선 듀랑고 서버의
초기 설계를 엿볼 수 있었습니다.

이중에 많은 구조와 원칙이

출시하기까지 갈아 엎어지지 않고
잘 유지되고 있습니다.

2016년
2016년 두 번째 발표에선

듀랑고의 서버사이드 게임플레이를
어떻게 만들고 있는지 소개해드렸습니다.

듀랑고의 핵심시스템인 부동산과

보이는 곳만 시뮬레이션하는
기술 등을 다뤘었죠.

발표자료 조회수
출시
듀랑고 서버에
장애가 있을 때마다

SlideShare에 올렸던 두 발표자료의
조회수가 폭발했었는데요
출시

이번 발표자료의 조회수는
많이 안 올라가면 좋겠습니다.
출시

2018년
다시 2년이 흘러
2018년 NDC가 됐습니다.

Vol. 1
Vol. 2
Vol. 3
이 시리즈가
3부작으로 끝날지

Vol. 1
Vol. 2
Vol. 3
아니면 2년 후에 볼륨 4를
다시 준비하게 될지는 모르겠지만

Vol. 1
Vol. 2
Vol. 3
3은 마무리하기에
좋은 숫자니까요

Vol. 1
Vol. 2
Vol. 3
이번이 마지막 듀랑고 서버 아키텍처
발표가 될 수도 있을 것 같습니다.

서버 아키텍처
이제 듀랑고의 서버 아키텍처를
자세히 살펴보겠습니다.

서버 아키텍처
1. 대규모 샌드박스
2. 고가용성
3. 데이터베이스
4. 섬
5. 청크
6. 클러스터링
7. 무중단 패치
8. 인프라
내용이 꽤 많은데
이렇게 8가지 주제를 다룹니다.

서버 아키텍처
2. 고가용성
4. 섬
5. 청크
6. 클러스터링
7. 무중단 패치
8. 인프라
이전 발표에서 이미
다룬 내용도 있지만

서버 아키텍처
2. 고가용성
4. 섬
5. 청크
6. 클러스터링
7. 무중단 패치
8. 인프라
그걸 보셨더라도 개발 중의 모습과
출시 후의 모습을 비교해보는 건

서버 아키텍처
2. 고가용성
4. 섬
5. 청크
6. 클러스터링
7. 무중단 패치
8. 인프라
충분히 의미 있을 것 같습니다.

대규모 샌드박스1
첫 번째 주제는
대규모 샌드박스입니다.

대규모 샌드박스1
듀랑고는 전례없이 거대한 규모의
샌드박스 MMORPG입니다.

영속적 세계
게임 세계에 보이는 거의 모든 요소가
서버사이드에 저장돼 있고

영속적 세계
그 요소들과의 상호작용으로
플레이어의 행동 하나하나가

영속적 세계
게임세계에 영구적인
영향을 남깁니다.

부동산
플레이어들은 눈앞에 보이는
땅을 사유화하고

부동산
자기만의 집을 짓거나
마을을 설립할 수 있죠.

부동산
저희는 이
"대규모 샌드박스"라는 컨셉을

부동산
개발 초기부터 지금까지
끈기 있게 이어왔습니다.

한 번 라이브에서 마을이
생겨나는 모습을 담아봤는데요

듀랑고의 자연이 파괴되고
문명화되는 모습을 볼 수 있습니다.

채널?
MMORPG에선 한 곳에
너무 많은 플레이어들이

채널?
모여 있을 때 생기는
여러가지 문제를 풀기 위해서

채널?
"채널"이란 장치를
도입하는 경우가 많습니다.

채널1
채널1
채널1
채널1 채널2 채널2
수많은 플레이어들이 게임 속 세계에서
같은 장소에 있다고 해도

채널1 채널2
이렇게 채널 별로 나뉘어서

채널1 채널2
같은 채널에 있는
플레이어끼리만 서로 동기화되고

채널1 채널2
상호작용할 수 있도록
제한하는 장치죠.

채널
게임세계의 메타포론 설명되지 않는
다소 인위적인 장치이긴 해도

채널
대규모 멀티플레이어 플레이가
가능하도록 해주는

채널
굉장히 중요하고
오랫동안 검증된 장치입니다.

채널
하지만 듀랑고 서버엔
채널을 도입할 수 없었습니다.

채널1 채널2
듀랑고 세계에선
대부분의 상호작용이

채널1 채널2
땅에 대해서 이뤄집니다.

채널1 채널2
내가 보고 있지 않은
다른 채널에서

채널1 채널2
내가 있는 위치에 원격으로
어떤 변화를 가한다면

채널1 채널2
인과관계 파악이 안 되고
그 상황을 쉽게 납득할 수 없을 겁니다.

단일 채널
대규모 샌드박스란
목표를 위해

단일 채널
저희는 채널을 도입하지 않고
단일 채널을 추구하게 됐습니다.

단일 채널
내가 어떤 곳에 있다면
그곳은 고스란히

단일 채널
내게 보여야 하는 거죠.

단일 서버
거기에 한 걸음
더 나아가서

단일 서버
서버도 하나만 운영하길
추구했습니다.

알파
브라보
찰리
델타
에코
폭스트롯
골프
호텔
인디아
줄리엣
킬로
리마
마이크
노벰버
오스카
파파
케벡
로미오
시에라
탱고
유니폼
빅타
위스키
엑스레이
양키
줄루
파편화된 서버는 플레이어 간의
높은 장벽이기 때문입니다.

알파
브라보
찰리
델타
에코
폭스트롯
골프
호텔
인디아
줄리엣
킬로
리마
마이크
노벰버
오스카
파파
케벡
로미오
시에라
탱고
유니폼
빅타
위스키
엑스레이
양키
줄루
처음 가입할 때 서버 고르는
고민을 없애주고 싶었고

알파
브라보
찰리
델타
에코
폭스트롯
골프
호텔
인디아
줄리엣
킬로
리마
마이크
노벰버
오스카
파파
케벡
로미오
시에라
탱고
유니폼
빅타
위스키
엑스레이
양키
줄루
친구랑 게임을 같이 하려 할 때도
서로 어떤 서버인지

알파
브라보
찰리
델타
에코
폭스트롯
골프
호텔
인디아
줄리엣
킬로
리마
마이크
노벰버
오스카
파파
케벡
로미오
시에라
탱고
유니폼
빅타
위스키
엑스레이
양키
줄루
물어보지 않아도 되게
하고 싶었습니다.

단일 서버
물론 이 목표는 다들 아시다시피
달성하는 데에 실패했습니다.

단일 서버
하지만 단일 서버를
추구한 노력 덕분에

한 서버 고용량
한 서버의 수용량은
기존 MMORPG에 비해서

한 서버 고용량
제법 높은 수준으로
만들 수 있었죠.

대규모 샌드박스
•영속적 세계
•부동산
•단일 채널
•단일 서버
듀랑고 프로젝트는
대규모 샌드박스라는

•영속적 세계
•부동산
•단일 채널
•단일 서버
달성하기 어려운 아이디어에서
출발했습니다.

•영속적 세계
•부동산
•단일 채널
•단일 서버
영속적 세계와 부동산

•영속적 세계
•부동산
•단일 채널
•단일 서버
그리고 그로 인한
단일 채널이란 제약과

•영속적 세계
•부동산
•단일 채널
•단일 서버
단일 서버라는 욕심

•영속적 세계
•부동산
•단일 채널
•단일 서버
저희가 서버를
개발하는 데 있어서는

•영속적 세계
•부동산
•단일 채널
•단일 서버
이런 목표를 이루는 데에
초점을 맞춰왔습니다.

고가용성2
서버 개발엔 높은 가용성이라는
또 하나의 목표가 있었는데요

고가용성2
동접이 치솟거나
인프라에 장애가 발생하더라도

고가용성2
서비스가 멈추는 일은
아예 벌어지지 않거나

고가용성2
아니면 적어도
빨리 복구되길 바랐습니다.

늘려서 해결하기
수평확장
저희는 우선 수평확장이
잘 되게 만드는 데에

수평확장
많은 노력을 기울였습니다.

수평확장
서버에 과부하가 걸렸을 때

수평확장
가능하면 동급의 노드를
추가하는 걸로 해결하고 싶었죠.

그런데 수평확장은
공짜가 아닙니다.

노드가 많아질 수록 그에 따른
확장성 문제도 생기게 마련이죠.

저희도 여러 차례
베타테스트를 거치면서

이런저런 확장성 문제를
겪어 왔는데요

지금은 모두 해결돼서
한 서버에 노드가 수만 개가 되더라도

서로 문제없이
협력할 수 있게 됐습니다.

몇 대 죽어도 버티기
노드가 많으면 그만큼
장애가 발생할 곳도 많아집니다.

몇 대 죽어도 버티기
몇몇 노드가 죽더라도
서비스에 큰 지장이 없게 만들려면

SPOF 자동복구
SPOF가 단 하나도
없도록 설계하거나

SPOF 자동복구
그렇지 못하더라도
최소한 장애가 났을 때

SPOF 자동복구
자동으로 신속하게 복구되게끔
만들어야 합니다.

SPOF 자동복구
게임서버 데이터베이스
저희의 접근은
게임서버에선 SPOF를 없애고

SPOF 자동복구
DB는 장애로부터
빠르게 복구될 수 있는 방향으로

SPOF 자동복구
기술을 선택하는 것이었습니다.

• 늘려서 해결하기
• 몇 대 죽어도 버티기
높은 가용성을 위한 두 수단

• 늘려서 해결하기
• 몇 대 죽어도 버티기
늘려서 해결하는 것과
몇 대 죽어도 버티는 데에 성공한다면

무중단 패치
서버 코드를 패치할 때도
전체 서비스를 내렸다 올리는 대신에

무중단 패치
일부 노드부터 새 버전을
확산시키는 방법으로

무중단 패치
무중단 패치도
할 수 있을 것 같았습니다.

자동 증설/감축
나아가
부하에 따라

자동 증설/감축
서버 증설과 감축도
자동으로 할 수 있겠죠.

중단시간 최소화
그러고 나면 마침내는
서비스 중단시간을

중단시간 최소화
극단적으로 줄이는 것도
가능할 거라고 생각했습니다.

무중단 패치 자동 증설/감축
현재 듀랑고에선

정기적인 콘텐츠 패치와
일부 난해한 경우를 제외하곤

무중단 패치가 가능합니다.

하지만 아직 자동으로 서버 규모를
조정하는 것까지 도입하진 못 했습니다.

고가용성
•늘려서 해결하기
•몇 대 죽어도 버티기
•중단시간 최소화
높은 가용성은 듀랑고 서버를 개발하면서
한결같이 추구해온 목표입니다.

고가용성
완벽하진 않지만
어느 정도는 이룬 상태인데요

고가용성
대규모 샌드박스와 고가용성,
두 가지를 추구하는 과정에서

고가용성
듀랑고만의 독특한 분산 서버 아키텍처가
만들어지게 됐습니다.

출시 직후
하지만 그런 목표와는 반대로

출시 직후
출시 직후 듀랑고에는 길고 잦은
서비스 중단 시간이 발생했습니다.

출시 직후
그 이유를 이해하려면 서버 아키텍처를
좀 더 깊게 살펴봐야 합니다.

데이터베이스3
저희는 여러가지
DB를 쓰고 있습니다.

Couchbase
그중 가장 중요한 건
Couchbase인데요

게임 세계를 저장
•플레이어
•인벤토리
•부족
•동물
•자연물
•건물
•섬
•부동산
•사유지
Couchbase의 용도는
주요 게임DB로

게임 세계를 저장
•플레이어
•인벤토리
•부족
•동물
•자연물
•건물
•섬
•부동산
•사유지
게임 세계를 구성하는 거의 모든
영속적인 정보들이 여기에 저장됩니다.

Couchbase게임서버
게임서버는 이런 정보를
별도의 캐시 계층 없이

Couchbase에서 직접
읽고 쓰고 있습니다.

그래도 괜찮을 정도로 Couchbase의
읽기/쓰기 성능은 굉장히 좋죠.

•높은 확장성
•읽기/쓰기 부하 분산
•캐시 급 속도Couchbase
Couchbase는 뛰어난 확장성을 가진
NoSQL DBMS입니다.

•높은 확장성
노드를 추가하는 만큼
읽기/쓰기 부하가 정직하게 분산되죠.

•높은 확장성
게다가 디스크에 접근하기 전에
메모리를 우선적으로 써서

•높은 확장성
별도의 캐시계층 없이 DB에
직접 접근하더라도

•높은 확장성
캐시만큼 빠른 속도를
누릴 수 있습니다.

초당 170만 번
Couchbase
저희의 경우
초당 170만 번의 요청을

초당 170만 번
Couchbase
지연 없이 처리하는 걸
직접 겪어 보기도 했습니다.

복제/자동복구
Couchbase에 저장하는 데이터는
여러 노드에 나뉘어서 저장되는데

복제/자동복구
이 노드 하나하나가
SPOF이긴 합니다.

복제/자동복구
노드에 장애가 나면 바로
서비스 장애로 이어지죠.

복제/자동복구
복제
하지만 각 노드가 이웃 노드의
데이터를 복제해두고 있어서

복제/자동복구
어떤 노드에
장애가 생기더라도

복제/자동복구
서비스 장애는 금방
자동으로 복구될 수 있습니다.

{키:밸류}
Couchbase의 데이터모델은
Memcached처럼

{키:밸류}
아주 단순한
키-밸류 방식입니다.

{키:밸류}
기본적으론 반드시 키를 알아야만
원하는 문서를 찾을 수 있죠.

{키:밸류}
키-밸류는 복잡한 로직을 만들기엔
너무 원시적인 모델이지만

{JSON}
Couchbase에선 저장하는 문서가
JSON 형식인 경우에 한해서

{JSON}
키-밸류 저장소 이외에도
부가적인 기능을 몇 가지 쓸 수 있습니다.

•{키:밸류} 저장소
•문서 부분 조회/편집
•색인/쿼리(N1QL)
•맵리듀스
예컨대 데이터를 읽고 쓸 때
문서를 통째로 다루는 대신

•맵리듀스
내용의 일부분에만
접근할 수도 있고

•맵리듀스
문서의 내용으로
키를 찾을 수 있게 해주는

•맵리듀스
여러가지 색인과
검색 기능을 쓸 수도 있습니다.

•맵리듀스
그런데 저희가 경험하기론

•맵리듀스
저장과 조회 쪽 기능이
쓰임새도 좋고 성능도 좋은데 반해

•맵리듀스
색인과 검색 쪽 기능은
무겁게 쓰면

•맵리듀스
치명적인 성능 문제로
이어지는 경우가 많았습니다.

•맵리듀스
실제로 이 문제가
출시 직후 장애에서

•맵리듀스
큰 지분을 차지했죠.

BEGIN;
COMMIT;
Couchbase는 NoSQL인 만큼

BEGIN;
COMMIT;
여러 문서에 걸친 트랜잭션을
지원하지 않습니다.

BEGIN;
COMMIT;
꼭 필요한 경우
트랜잭션 처리를

BEGIN;
COMMIT;
게임서버가 대신 하게끔
구현해야 했는데요

BEGIN;
COMMIT;
그 과정에서 종종 데이터 관련 버그가
야기되기도 했습니다.

NoSQL 위에서 MMORPG 개발하기
최호영, NDC18
이런 난관을 딛고
Couchbase라는 NoSQL을 이용해서

최호영, NDC18
샌드박스 MMORPG를 만든
저희의 경험은

최호영, NDC18
게임플레이 프로그래머 최호영 님이
자세히 다뤘습니다.

최호영, NDC18
NoSQL로 온라인 게임플레이 로직을
어떻게 만들었는지

최호영, NDC18
궁금하신 분들에게
이 발표를 추천해드립니다.

MySQLRedis Elasticsearch
저희는 Couchbase 이외에도
Redis와 MySQL, Elasticsearch를 함께 쓰는데요

게임DB인 Couchbase에 비하면
훨씬 좁은 영역에 쓰이고 있습니다.

세션이나 접속 대기열, 장터와 결제 영수증
같은 게 이쪽에 저장되죠.

•Amazon ElastiCache
•Amazon Aurora
•Amazon Elasticsearch Service
이 DB들은 모두
직접 구축하는 대신

•Amazon Aurora
AWS의 관리형 서비스로
운영하고 있습니다.

•Amazon Aurora
덕분에 관리하는 데에
큰 노력을 들이지 않고도

•Amazon Aurora
필요할 때 쉽게 증설할 수 있었고
장애가 발생했을 때에도

•Amazon Aurora
신속하게 자동으로
복구할 수 있었습니다.

•Amazon Aurora
DB 얘기는 이쯤 해 두고
이제 게임서버로 넘어가 볼게요.

〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3

Ähnlich wie 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 (20)

〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3