|
|
|
|
|
|
 |
개발만담 - 개발,업무,우리의 밥벌이와 관련된 만담 게시판.
Loading...
|
|
중국의 어떤 서버 개발자의 디비 설계
|
|
|
* 탈퇴 imays
|
|
작성 : 2015-12-11 14:55:31 | 조회 : 29,819
|
|
|
|
|
|
|
|
| 제가 몇 년 전에 어떤 중국 서버 개발자와 나눈 대화 내용입니다.
----------------------------
중국 개발자: 우리는 가입자 1억명 들어가 있는 게임의 디비에 유저 정보를 바이너리로 시리얼라이즈해서 그냥 쌩으로 때려박는다. 트랜잭션 안 써.
나: 헐? 너 미쳤어?
중국 개발자: 안그러면 디비가 못 버팀.
나: 그렇게 하면 검색도 어렵고 트랜잭션도...
중국 개발자: 트랜잭션이 뭐하는데 쓰는건지는 아니?
나: 어쩌고 저쩌고
중국 개발자: 그건 피지컬 오류에 대한 롤백이고. 피지컬 오류 발생이 얼마나 나지?
나: 거의 안나지.
중국 개발자: 게임 서버 만들어봐서 알잖아. 로직은 어디서 다 일어나지?
나: 게임 서버 메모리 안에서지.
중국 개발자: 그래서 피지컬 오류가 거의 안나는거야. 트랜잭션은 로지컬 오류에서 효과적이지. 게임 서버 램 안에서 다 해먹는데 트랜잭션은 득보다 실이 상회한다.
나: ...! (뒷통수 맞는 느낌)
중국 개발자: 계속 이어서 말해주지. 바이너리로 저장하는 이유 말이지... 그것도 성능을 위해서야.
나: 그러면 캐릭터 정보 조금이라도 바뀌면 다 바이너리로 만들어서 저장해야 할텐데?
중국 개발자: 당연하지. 근데 그게 훨씬 빠르다. 너 디비에서 가장 느린게 어딘지 알아?
나: 응. 하드디스크.
중국 개발자: 더 정확하게 짚어서 말하자면, 하드디스크 중에서 헤드가 움직이는 순간이 가장 느려.
나: ...! (뒷통수 맞는 느낌) 이제야 이해된다. 그렇다면 당연히 캐릭터 정보 전체를 시리얼라이즈해서 매번 통으로 저장하는게 훨씬 빠르겠네. 헤드 움직임이 적을테니까.
중국 개발자: 그렇지. 하나 더 얘기하자면, 바이너리로 저장해서 최대한 압축하는게 좋아. 가능하면 4KB 안에 저장하는게 좋지.
나: 응? 그거는 섹터 하나의 크기 아니야? 그만큼 헤드가 안 움직여도 되고.
중국 개발자: 빙고. 잘 아네.
----------------------------
두줄 요약
트랜잭션은 피할 것. 바이너리에 캐릭터 정보를 압축해서 쌩으로 넣는 것도 효과적.
----------------------------
상기 대화 내용에 대한 저의 생각
1억명 계정 들어있는 디비를 직접 돌려본 경험이 없어서 저 말이 맞는지는 모르겠지만, 일단은 디비 과부하 상황에서 저런 방법도 고려는 해볼 필요가 있다고는 생각합니다.
|
|
|
|
|
|
|
오호~ 유레카~ 근데 1억명은 꿈~
|
2015-12-11
14:58:51
  |
물치
|
|
|
|
실제로 퍼블리셔에서는 트랜잭션을 가급적 걸지말라고들 하더라구요. 0.001% 확률로 에러 나는건 운영 이슈로 처리하는게 훨씬 효과적이라고 합니다. 단지 로그들만 충실히 남겨준다면 전부 해결이 가능하다는 얘기를 하더라구요.
그말 듣고 생각해보니 그 적은 확률에 트랜잭션을 매번하는것이 비효율적이라는 생각이 듭니다.
위 글 처럼 바이너리를 때려 박는 구조를 쓸빠엔 MongoDB를 쓰는게 훨씬 좋을 것 같습니다. MongoDB가 그런식이니깐요.
|
|
|
|
|
1
|
|
|
|
2015-12-11
16:35:51
|
 
MNLT
|
|
|
|
저번에 기회가 있어 한번 대화를 나눴던 내용이네요.
한가지 정보를 말씀드리면, 제가 있는 회사(중국)의 경우 자체 R&D및 서비스 하고 있는 DB솔루션의 스키마와 서버 프레임워크의 프로토콜이 동일한 포멧 및 기능을 사용합니다. 실제 DB에 때려박는 데이터도 시리얼라이징 된 데이터이고요. (프로토콜 설계하듯 DB스키마 짜서 문서 집어넣으면 테이블이 생성됩니다 / internally automatical sharding & scale-out)
그리고 하나 더... 랭크서버와 같은 폭팔적인 고성능 작업이 필요하지 않는 이상.. 여긴 모든 서버가 멀티쓰레드 사용 안합니다. @_@
|
2015-12-11
16:54:23
|
노코드
|
|
|
|
저도 트랜잭션안씁니다. 책에 나와있으니 쓰고야 말겠다는 사람이 아직도 많아서... 매번 설명/설득 하기 힘들어요. 그런데 간혹 필요해지는 경우가 있는데 [안쓰면 기능상 하자가 생길수 있는 경우] 필요할땐 씁니다.
|
2015-12-11
16:56:36
|
노코드
|
|
|
|
바이너리로 때려박겠다는 개발자는 한국에서도 몇명 보았는데... 게임 다만들고 오픈 준비하면서 운영이슈들이 들이닥치게 되면 초난감해집니다. 제발 잘 설계된 정식 테이블에 넣어주시길 ㅠㅠ 그냥 테이블에 몇억 넣어두 돼요. 샤딩하면 되자나요 ㅠㅠ
|
2015-12-11
17:00:50
|
|
|
|
바이너리를 때려박으라고 존재하는 DB는 아니지 않나요?
그거에 맞는 DB는 따로 있을텐데.....;;;
|
|
1
|
|
|
|
|
|
|
2015-12-11
17:15:09
|
smileeagle
|
|
|
|
ㄴ 몇전전 이야기라서 그분은 OLTP 고려없이 디스크 섹터 이야기를 한듯한데. 내용상 RDB를 운용하면서 트랜잭션처리를 하지 않는 다는 것으로 보여서요. 위 처럼 구성한다면 카우치베이스가 RDB보다는 더 좋은 솔루션일것 같아요. (트랜잭션 로그를 통한 텀단위의 장애복구는 어렵겠지만.) 실상 게임서비스에서의 부하는 유저(캐릭터?)데이터로 인한 부하보다는 아이템으로 인한 부하가 더 많은데 아이템은 어찌 처리할지도 궁금하네요 =_=
|
2015-12-11
17:16:22
|
|
|
|
저희는 운영툴 작업을 외부업체와 같이 진행하는데 유저정보가 한 컬럼에 다 들어가 있다고 생각하면 작업하기 굉장히 번거로울듯 하네요. 성능은 좋아도 협업면에서는 힘들겠군요.^^
|
2015-12-11
17:21:20
|
MNLT
|
|
|
|
국내 서비스만 한다면 쉽게 이해하기 힘든 처리 방식이라고 생각할 법도 합니다.... 상대적으로 인력도 많이 부족하고, 대한민국 유저 풀로는 사실 다르게 접근해야할 케이스라서요.. (글로벌 서비스하는 분들은 아시겠지만...)
중국의 경우 제가 들었던 어느 스튜디오는 모바일 게임서버 하나 개발하는데 15명씩 붙어서 했다고 합니다. 그리고 여기 R&D 센터의 경우 수십명의 DB/서버프레임워크 개발진이 있어서 우려하는 공용 운영툴 등의 문제도 인력으로(?) 커버해버리네요. (심지어 테스트팀도 잘 꾸려져있습니다.... 버전 패키징 및 유닛테스트 전용팀...)
어지간한 툴은 다 만들어져있고, 개발사나 스튜디오에 제공하다가 모지란것들 있으면 한달내로 뚝딱 만들어줍니다(....) 고로 이건... 뭐랄까 시장에 따른 각기 다른 양상 아닐까요...
근데 RDB에서 샤딩하게 되면 트랜젝션에 대한 고민은 똑같지 않나요? (제가 DBA는 아니라서...) 서버단 트랜젝션이니 뭐니 이런건 성능상의 문제 이슈가 상당하고요... 어짜피 이런 문제들로 고민할꺼라면 전자나 후자나 큰 차이가 없을 것 같기도 하네요...
|
2015-12-11
19:07:01
|
smileeagle
|
|
|
|
사실 뭐 장단점을 논하자면.. 끝이 없겠지만.
말씀하신 캐릭터 정보를 저장하는 DB스키마가 제가 이해한 아래 내용이고
| 캐릭터 UID | 직열화 된 캐릭터 정보 바이너리 데이터(레벨, 클래스, 위치정보, 스탯정보, 경험치정보 등등등) |
검색 이슈 및 운영상 캐릭터 정보에 대한 배치 업데이트 이슈가 거의 없다면, 차라리 백업을 위한 스토리지 서버 따로 놓고 디스크를 미러로 구성하고 파일로 저장하는데 낫다는 생각이 들어요.
괜히 DB에 넣어 구문분석 및 실행계획 절차를 거칠 이유가 없을것 같네요.
|
2015-12-11
19:25:21
|
ST파파
|
|
|
|
이게 효과적일 수도 있었던거군요 ㄷㄷㄷ
첫 MMORPG가 이렇게 개발되었었는데, 아이템 복사, 캐릭터 정보 통채로 복사 등등 수 많은 문제점을 일으켜서 다시는 저렇게 개발하지 않을꺼야 했는데 ㄷㄷㄷ
|
2015-12-11
19:54:19
|
노코드
|
|
|
|
제발...  
|
|
1
|
|
|
|
|
|
|
2015-12-11
20:12:53
|
노코드
|
|
|
|
ㄴ NoSQL 처럼 썼다기 보다는, 샤딩을 해서 디비서 조인 못하고 서버에 퍼와서 조인 한다는 내용 같아요. 바이너리로 때려박았다고 해석되기엔 근거가 부족합니다 ㅋ
|
2015-12-11
21:18:42
|
|
|
|
1. 저장만 할거라면 저게 젤 빠릅니다. 2. 요즘 HDD 안 쓰죠... 3. 저래 만들어놨으면 만든 놈이 몽땅 책임 지는겁니다. 4. 그냥 캐시 서버를 만들어도 될거같은데... 굳이 저래야할까... 득보다 실이 많을 것 같은데.. 5. 운영이슈 터지면 전체 롤백 뿐... (백업은 하니...?) 6. 저라면 @@@에 @@@@에다 @@ 구성 하겠습니다...
|
2015-12-12
00:39:43
|
|
|
|
5...는 상황에 따라 점검 잡고 바이너리 다 땡겨서 수정 볼 수는 있긴 하것네요... (그렇게 해봤으니..)그래도 그게 아름다울 것 같진 않...
과거 SQL 2000 쓰던 시절... 느려터진 37, 74GB SCSI로 서비스할 시절에는 바이너리 쓸 수 밖에 없었슴다. (제 첫 게임이 바이너리로 때려넣었어요. 디스크도 정말 느리고 메모리도 많이 꼽을 수 없었거든요.)
데이터 패치가 잘못 되거나, 이런 저런 운영이슈 터지면... 음 뭐 상상에 맡기겠... 1억의 회원 중 동접이 얼마나 되느냐에 따라 얘기가 다르겠지만... 스토리지랑 RDB 개발하는 사람들이 바보는 아니잖아요. - _-;;;
|
2015-12-12
00:50:32
|
|
|
|
중국넘들중에 그런 넘들이 있는가보다 하면 될거 같습니다
Imays님이 가끔 올리는 중국이야기는 톡특해서 올렷을뿐이라고 생각됩니다.
다만 제가 사장인데 RDB로 저런짓거리하고있었다면 바로 짤랐을거 같네요.
|
|
1
|
|
|
|
|
|
|
2015-12-12
08:31:17
|
|
|
|
속도좀 올려보겠다고 코드를 어셈블리로 다 바꾸는거와 뭐가 다른지 모르겠어요
|
|
2
|
|
|
|
|
|
|
2015-12-12
08:35:55
|
제오
|
|
|
|
디스크 헤드 걱정하는 건 좀... 어차피 메모리 버퍼에서 한참 놀다가 디스크에 들어가기 때문에 어플리케이션에서 write하는 순서와 디스크에 실제 write하는 순서와는 관계가 없을 텐데요. 현재 로그인 중인 모든 사용자의 데이터를 한꺼번에 저장하는 거라면 몰라도.
|
2015-12-12
10:08:08
|
MNLT
|
|
|
|
전반적으로 부정적인 시각이 많네요. 이래서 프레임이 무서운가봅니다. 현실적으로 보면 많은 분들의 경험이나 말씀들이 90%에 가까울만큼 맞는 말이지만... (저도 한 2년전까지만해도 그랬고요)
컬럼수의 한계로 인한 문자열 파싱 처리 라던가, 컬럼구조의 수정 이슈라던가 등등의... RDB의 고유기능만을 사용해서 처리하기 어려워 우회하는 기능들도 상당히 많이 존재할텐데요... 이를 위해 서버단에서 처리를 한다거나 성능의 일정 부분을 포기한다거나 하는 사례들이 많이 있을텐데, 서버단에서 처리하는거면 key-value냐 아니냐의 문제의 논점과는 벗어날꺼같고요.
이때 발생될 수 있는 파싱 비용, 버려지는 더미 컬럼, 데이터 버전처리 문제 등... 충분한 시간과 인력이 있다는 가정하에 개발 코스트는 별 차이 없을것 같긴 합니다. 운영툴의 경우에도 뭐... 쿼리 짜는거나 가져와서 시렬라이징 처리 하는거나... 백엔드 라이브러리만 잘 처리 되있다면 큰 차이 없을 것 같고요. (다만 적응의 문제가 있을 수 있겠네요. SQL에 적응되어 있는 상태...)
그냥 결론은 제 생각에 이 부분에 대한 정답은 없다고 보는데, 분위기가 저렇게 쓰면 짤린다, 책임져야한다 등의 무거운 내용들이 있어서, 기술적인 시각이 편향되지 않았으면 하는 바램에서 써봅니다. (충분히 생각해보고 연구해볼만한 가치 아닌가요?) 기술이란 상황에 따라 이렇게도 저렇게도 쓰일 수 있는거라 봅니다.
참고로 전민돌격(한국의 '백발백중')도 바이너리로 때려박습니다.
|
|
3
|
|
|
|
|
|
|
2015-12-12
17:27:05
|
|
|
|
DB 문외한인데요. 저런 걸 필요로 하는 사람도 실제로 꽤 존재하긴 하네요.
암튼 DB를 단지 데이터 저장용으로 쓴다는 건... 재밌네요. ㅋ
|
2015-12-13
12:44:20
|
|
|
|
역시나, 호불호가 갈리는 의견들이 나오네요. 당연하죠. 저도 쉽게 동의하기 어려운 방법, 아니 꼼수니까요.
참고로, 5년전에 저 대화를 나누었던 사람은, 중국에서 꽤 큰 게임회사의 서버팀장을 맡고 있었습니다. 제가 기억이 확실하다면, 미국 MIT 공과대학 출신입니다. 디비 설계에 대한 지식이 딸려서 저렇게밖에 못한거라고 보기는 어렵습니다.
|
|
3
|
|
|
|
|
|
|
2015-12-13
15:54:55
|
|
|
|
ㄴ 헐, 실제로 단순 파일에 서비스를 하는 업체가 있었군요. 어차피 검색 못할거면, 그냥 유저별로 파일에 저장하는게 훨씬 속도가 빠를거라고 짐작하고 있었는데요[1], 진짜로 그렇게 하기도 하는군요!
Cloud Wu의 영향 때문인지 제가 중국에서 만난 서버개발자들은 Lua를 많이 쓰더라구요. C++은 크래시 때문에 위험해서 안쓴다고 합니다.
---------
[1] 성능 테스트 결과 DB 테이블에 저장하는 것보다 파일 기록 속도가 약 10~100배 정도 빠릅니다.
|
2015-12-13
18:01:17
|
노코드
|
|
|
|
이런 느낌입니다.... 정원보다 10배 태우고도 굴러가긴 하겠죠....
|
2015-12-13
19:19:09
|
큐피리도
|
|
|
|
저도 비슷한 생각으로 BLOB로만 사용할거면 파일로 사용하는 게 편하지 않나 생각되네요.
예전에 머드게임들도 이런식의 파일 방식으로 많이 운영됐었는데 메모리 형태로 한 번에 밀어넣다보니 데이터 구조체를 중간에 변경하기가 힘들어 예약된 char 버퍼를 하나 크게 만든 후 padding bytes 계산해서 필요할 때마다 잘라 사용하니 데이터 필드 변경 이슈로부터도 크게 문제가 없었습니다.
하지만 I/O 속도가 서버에 바로 영향을 미쳐버리는 단점이 있기 때문에 요즘 같이 접속자가 많은 시대에는 별도의 캐시 서버를 만들어야 할 수도 있겠네요.
물론 필드 검색(이것은 BLOB인 이상 DB 형태로도 힘들죠)과 백업은 별도 툴을 만들어 사용해야 겠지만 키 검색은 폴더를 잘 나누는 방식으로 해결하면 되고 (파일 시스템에 따라 최대 개수를 고려하여) 위험 요소는 RAID 깨지는 것을 고려한다면 데이터베이스가 통째로 깨지는 것 보다 일부 파일들이 소실되는 게 오히려 더 빠른 복구가 가능하다는 장점이 있지 않을까 생각됩니다.
물론 위 모든 전제는 BLOB 형태로 통째로 밀어 넣는다는 전제입니다. :)
|
|
1
|
|
|
|
|
|
|
2015-12-14
01:32:46
|
|
|
|
참고로 중국은 대중교통이 엉망인데, 기차하나는 알아줘야하거든요 ㅎㅎㅎ https://namu.wiki/w/%EC%A4%91%EA%B5%AD%EC%B2%A0%EB%A1%9C%EA%B3%A0%EC%86%8D
|
2015-12-14
02:51:32
|
sophnim
|
|
|
|
제가 만들고 있는 게임이 메인 저장소로 redis를 씁니다. 복수개의 redis 인스턴스들을 Twemproxy로 샤딩하고 있습니다. 모바일의 경우 한번 게임 해보고 안돌아오는 유져가 상당한데 이런 유져의 데이터는 Redis로부터 백업용도의 MariaDB로 이전시키는 구조입니다(물론 이 유져가 오랜만에 돌아오는 순간 다시 Redis로 이동시킵니다).
주 저장소를 Redis를 쓰는 바람에 일체의 관계형 연산이 불가능하므로 통계자료의 추출이 힘든건 사실입니다만 이런 유져 데이터의 분석은 스플렁크나 기타 텍스트 로그 파일기반 빅데이터 분석 솔루션을 사용하는 방향으로 개발하고 있습니다.
|
|
1
|
|
|
1
|
|
|
|
2015-12-20
12:38:01
|
|
|
|
|
|
|
|
게임코디 GAMECODI , 게임 프로그래머 만담 커뮤니티
게임코디 소개 |
크라우드펀딩 후원자 |
관리실 연락처 |
|
|
|
|
|
새로운 댓글
