전에 엘온 과금학개론 글 싼지가 이제 어엿 2년이 넘었네

https://gall.dcinside.com/m/eso/55358

[번외] 엘더스크롤 온라인의 과금 구조에 관하여 - 평가 - 엘더스크롤 온라인 마이너 갤러리

<목차>-1-컨텐츠 판매-2-ESO Plus 구독-3-크라운 스토어-4-크라운 상자 (가챠)-번외-필자의 평가짧은 서론전 글들을 쓰면서 필자의 의견은 배제하고 팩트중심으로 서술하려 했지만 엘온

gall.dcinside.com

거기 글에 "자세한 설명은 하지 않겠지만 한개 서버에 상주하는 유저들이 많고, 그 유저들의 인벤 크기가 클수록, 한번 유저가 인벤을 열때마다 서버에 오는 부하가 기하급수적으로 막심해진다는 정도만 알고 있으면 된다." 라는 말이 있었는데

그냥 심심해서 이걸 한번 풀어보려 함

(사실 컴공과, 코딩과면 대충은 알만한 내용임)

.

"인벤토리"란 무엇인가?

보통 사람들은 "서버 어딘가에 있는 데이터 쪼가리"라고 생각한다.

인벤토리는 대게 데이터베이스, 즉 DB상에 존재한다.

온라인 게임이던 싱글게임이던 보통 플레이어 인벤토리는 데이터 파일로 존재하고, 이 데이터 파일이라는건 보통 표로 존재한다. 쉽게말해 니들 인벤토리는 결국 엑셀파일이라는 소리다.

대신 엑셀은 쥔나 무겁다. 그리고 보통 DB에는 공식이나 스타일링은 필요없다. 그래서 딱 필요한 '아이템 ID', '값'(=니가 보유한 개수), 그리고 이걸 나눠주는 쉼표(,) 로만 구성해서 인코딩된 파일을 'CSV'(Comma-separated values, 쉽표로 나눠진 값들(의 모음))라고 부름. 이걸 자바스크립트 같은 스크립트 언어에 특화시킨게 JSON (이건 들어본놈 좀 있을거임).

보통 DB에 '어떤것이 몇개인가'를 표현할때, 일반적으로는 '어떤 것'을 하나의 열에 넣고, 그리고 각 아이템 별 보유 개수는 열에 맞춰 하나의 행에 기록된다. 이론적으로 니 인벤토리는 DB상에서 단 1줄로 찍힐수도 있다. 근데 엘온 같은 MMO는 아이템 종류와 장비 아이템 경우의 수가 너무나도 많기 때문에 이따구로 DB를 만들면 게임 서비스 못함.

그래서 보통 각 아이템 종류별로 고유 코드, 랜덤스탯이 있는 경우에는 아이템 유형값 + 랜덤생성기 시드값을 넣은 것을 '값'으로 잡고, 단 2열짜리 표에 니 인벤에 가지고 있는 아이템들을 그냥 병렬화 시켜서 때려박을...수는 있다. 하지만 엘온의 경우에는 아이템 등급 뿐만 아니라 장비템일 경우 해당템에 적용된 스타일과 제작템의 경우 제작한 캐릭터의 이름까지 기록해줘야 한다. 열이 두개를 넘을수밖에 없다는 뜻.

그리고 '각 케릭별로 인벤에 뭐가 뭐가 있어'라는 이 '표'들의 행의 숫자는 서버상에 존재하는 캐릭터 숫자만큼이다. (제작가방은 에소플 긁은적이 한번이라도 있는 계정 숫자만큼)

그리고 엘온에는 복병이 하나 더 있음. 리전도 플랫폼별로 두개밖에 없고, 한 계정이 팔 수 있는 캐릭터의 수도 최대 20개나 됨.

와! DB가 행이 도대체 몇게임? 얼마전에 엘온 계정 수 천만 찍었다고 했지? 북미섭에 계정 250만개라고 가정하고 계정 하나당 평균 캐릭터 수 3개라고만 계산해도 각 표 하나당 750만줄임. 엑셀이나 하물며 CSV도 한 1만행만 찍혀도 컴 버벅이고 지랄댄스 나는데 아무리 이딴거에 특화된 서버라고 버티겠음? 못버팀 ㅋㅋ

그래서 이런 초대형 DB를 운영할때는 크게 '트렁케이션'과 '색인'이라는 과정을 통해서 '최적화'를 해줌.

대충 설명해주자면 트렁케이션이란, 값을 지정해서 X개수만큼 잘라서 표를 따로따로 저장하는거고, '색인'은, DB에 모든 값에 대해서 1:1로 비교하지 않고, 특정 행들에 특정 값들에 대한 '목차'를 미리 뽑아놔서 이거만 대치해보고 값이 같으면 그안에서만 뽑으라고 미리 작업을 해놓는거임. 서버점검할때도 이런 작업도 보통 같이 해줌 ㅇㅇ.

하지만 그래도 결국 좆나게 큰 표들을 하나도 아니고 여러개씩에 대해 검색을 계속해서 실시간으로 수행한다는 사실 자체는 변하지 않음.

DB의 내용물을 보거나 바꿀때는 기본적으로 '쿼리'라는 작업을 수행하게 됨. 이 쿼리라는게 별거 아니고 일종의 집합 문제를 해결하고 그 값을 대령하라는 명령임. 니가 인벤을 열거나, 템을 먹거나, 버리거나, 아무튼 인벤과 관련된 뭔짓을 할때마다 클라이언트는 'ㅇㅇㅇ 표들에서 이 계정, 이 캐릭에 종속된 값들을 찾아내서 내놓으시오'(실제로는 더 복잡함)라는 명령을 서버에 날리고, 서버는 쿼리를 수행한 뒤 그 값을 다시 보내줘야 함. 인벤 한번 깔때마다 지구 반대편 서버에서 스프레드시트에다 대고 컨트롤+F를 여러번 쫘라락 수행하고 수십, 수백분의 1초 안에 결과를 대령한다는 뜻. 조회하는 DB 자체의 크기가 크면 클수록 아무리 최적화를 해줘도 CPU, 메모리와 저장장치가 해야 하는 일의 양 자체가 늘어나는건 물리법칙상 피할 수가 없음.

그리고 DB쿼리는 기본적으로 아무리 최적화를 쥐어짜봤자 결국 태생상 각 행/열을 쭈르륵 읽는 직렬연산임. (트렁케이션을 통해 어느정도의 병렬화는 이륙 가능하나 한계는 있음) 쉽게말해 게이머들 극혐하는 싱글쓰레드만 존나 갈구는 연산을 신나게 한다는거임. 에픽 CPU 두개박은 서버도 플레이어 좀 많이 붙으면 감당이 안됨.

보통 온라인 게임들이 서버 나누는 이유중 하나가 이 DB 관리 때문임. 보통 하나의 세션이나 인스턴스에 유저가 과다하게 많아서 랙 걸리는걸 먼저 연상하지만, 서버/채널로 나누는 한국식 MMO 방식이 제일 무식한 대처법이고 (대신 ㅇㅇ 서버, ㅇㅇ 채널, ㅇㅇ 맵 인스턴스에 입장하면 무조건 서로를 볼수 있다는 장점은 있음 ㅇㅇ) 대부분의 외산 현역 MMO들은 알아서 스마트하게 인스턴스를 나누기 때문에 이건 자원만 퍼부어주면 전~혀 문제가 안됨. 오히려 DB의 경우 규모가 어느정도 이상으로 커지면 실시간성이 생명인 게임 서비스에는 아무리 돈을 퍼부어도 문제가 해결이 안됨. 아까 누누이 말했듯이 태생이 직렬연산이여서 서버를 늘려도 한번에 받을 유저만 많아지지, 연산에 걸리는 시간을 단축시키는대에는 한계가 있거든. 엘온은 그럼 이짓을 어떻게 했냐고? 그건 진짜 개발진들밖에 모름. 감자서버라고 맨날 존나 욕하지만 사실 엘온 메가서버는 출범 당시 (소프트웨어) 기술적으로는 매우 굉장한 업적이였음. 저런 시도를 한적이 거의 없거든.

사실 하이아일때 서버 존나 터졌던것도 이거 도저히 감당 안되서 휴면계정들 백업시키고 실사용 계정 데이터는 고성능 스스디 기반 물리적 데이터베이스로 이주하는 작업이랑 겹쳐서 진단이 제대로 안됐던거임. (처음엔 서버 문제인줄 알았는데 알고보니 네트워크 문제였음)

그래서 나뿐만 아니라 컴붕이 엘붕이들은 오늘도 에소플만큼은 군말없이 긁는거임. 저짓을 무려 인하우스로 10년 가까이 운영을 하고 있거든. (요즘 AWS나 애져 클라우드 이관 안한 메이저 MMO는 엘온밖에 없는걸로 알고있음.)