중국의 어떤 서버 개발자의 디비 설계

 

 

 

=======================

=======================

=======================

 

 

 

 

 

 

 

출처: http://www.gamecodi.com/board/zboard.php?id=GAMECODI_Talkdev&page=1&sn1&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=3715

 

 

제가 몇 년 전에 어떤 중국 서버 개발자와 나눈 대화 내용입니다. ---------------------------- 중국 개발자: 우리는 가입자 1억명 들어가 있는 게임의 디비에 유저 정보를 바이너리로 시리얼라이즈해서 그냥 쌩으로 때려박는다. 트랜잭션 안 써. 나: 헐? 너 미쳤어? 중국 개발자: 안그러면 디비가 못 버팀.  나: 그렇게 하면 검색도 어렵고 트랜잭션도... 중국 개발자: 트랜잭션이 뭐하는데 쓰는건지는 아니? 나: 어쩌고 저쩌고 중국 개발자: 그건 피지컬 오류에 대한 롤백이고. 피지컬 오류 발생이 얼마나 나지? 나: 거의 안나지.  중국 개발자: 게임 서버 만들어봐서 알잖아. 로직은 어디서 다 일어나지? 나: 게임 서버 메모리 안에서지. 중국 개발자: 그래서 피지컬 오류가 거의 안나는거야. 트랜잭션은 로지컬 오류에서 효과적이지. 게임 서버 램 안에서 다 해먹는데 트랜잭션은 득보다 실이 상회한다. 나: ...! (뒷통수 맞는 느낌) 중국 개발자: 계속 이어서 말해주지. 바이너리로 저장하는 이유 말이지... 그것도 성능을 위해서야. 나: 그러면 캐릭터 정보 조금이라도 바뀌면 다 바이너리로 만들어서 저장해야 할텐데? 중국 개발자: 당연하지. 근데 그게 훨씬 빠르다. 너 디비에서 가장 느린게 어딘지 알아? 나: 응. 하드디스크. 중국 개발자: 더 정확하게 짚어서 말하자면, 하드디스크 중에서 헤드가 움직이는 순간이 가장 느려.  나: ...! (뒷통수 맞는 느낌) 이제야 이해된다. 그렇다면 당연히 캐릭터 정보 전체를 시리얼라이즈해서 매번 통으로 저장하는게 훨씬 빠르겠네. 헤드 움직임이 적을테니까. 중국 개발자: 그렇지. 하나 더 얘기하자면, 바이너리로 저장해서 최대한 압축하는게 좋아. 가능하면 4KB 안에 저장하는게 좋지. 나: 응? 그거는 섹터 하나의 크기 아니야? 그만큼 헤드가 안 움직여도 되고. 중국 개발자: 빙고. 잘 아네. ---------------------------- 두줄 요약   트랜잭션은 피할 것. 바이너리에 캐릭터 정보를 압축해서 쌩으로 넣는 것도 효과적. ---------------------------- 상기 대화 내용에 대한 저의 생각   1억명 계정 들어있는 디비를 직접 돌려본 경험이 없어서 저 말이 맞는지는 모르겠지만, 일단은 디비 과부하 상황에서 저런 방법도 고려는 해볼 필요가 있다고는 생각합니다.

 

-------------------------------------------------------------------------------------------------------------------------------------------------

 

 

오호~ 유레카~ 근데 1억명은 꿈~

2015-12-11 14:58:51

와..... 1억명..

2015-12-11 15:02:57

검색하지 않을 데이터라면야.. 그나저나 1억명.. 부럽~

2015-12-11 15:29:00

허허... 그렇겠네요

2015-12-11 15:51:44

극한 상황이 최상의 해결법을 찾게 해주는군요.

2015-12-11 16:31:12

실제로 퍼블리셔에서는 트랜잭션을 가급적 걸지말라고들 하더라구요.0.001% 확률로 에러 나는건 운영 이슈로 처리하는게 훨씬 효과적이라고 합니다. 단지 로그들만 충실히 남겨준다면 전부 해결이 가능하다는 얘기를 하더라구요.   그말 듣고 생각해보니 그 적은 확률에 트랜잭션을 매번하는것이 비효율적이라는 생각이 듭니다. 위 글 처럼 바이너리를 때려 박는 구조를 쓸빠엔 MongoDB를 쓰는게 훨씬 좋을 것 같습니다. MongoDB가 그런식이니깐요.

2015-12-11 16:35:51

저번에 기회가 있어 한번 대화를 나눴던 내용이네요.  한가지 정보를 말씀드리면, 제가 있는 회사(중국)의 경우 자체 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

좋은 내용이네요. ㅎ

2015-12-11 17:01:52

-ㅅ-; 운영이나 데이터분석은 안하나요?

2015-12-11 17:08:27

ㄴ 하겠죠. 아마 데이터분석을 위한 것을 별도로 저장한다던지, 즉 DW화 하지 않을까요?

2015-12-11 17:09:12

바이너리를 때려박으라고 존재하는  DB는 아니지 않나요? 그거에 맞는 DB는 따로 있을텐데.....;;;

2015-12-11 17:15:09

ㄴ 몇전전 이야기라서 그분은 OLTP 고려없이 디스크 섹터 이야기를 한듯한데. 내용상 RDB를 운용하면서 트랜잭션처리를 하지 않는 다는 것으로 보여서요. 위 처럼 구성한다면 카우치베이스가 RDB보다는 더 좋은 솔루션일것 같아요. (트랜잭션 로그를 통한 텀단위의 장애복구는 어렵겠지만.) 실상 게임서비스에서의 부하는 유저(캐릭터?)데이터로 인한 부하보다는 아이템으로 인한 부하가 더 많은데 아이템은 어찌 처리할지도 궁금하네요 =_=

2015-12-11 17:16:22

그리고 -ㅅ- 트랜잭션을 쓰지 않는다는 것은 ACID를 포기한다는 소리인데..NO-SQL 만으로 게임 서비스를 하기 애매한 부분들이 가지는 단점을 그대로 가지지 않을지 -ㅅ-;

2015-12-11 17:21:01

저희는 운영툴 작업을 외부업체와 같이 진행하는데유저정보가 한 컬럼에 다 들어가 있다고 생각하면 작업하기 굉장히 번거로울듯 하네요. 성능은 좋아도 협업면에서는 힘들겠군요.^^

2015-12-11 17:21:20

동접은 실전이야 **아 라고 제머리속에 요약 되는 이기분은 뭐죠 뭐라 섯불리 말을 못꺼내겠습니다

2015-12-11 17:42:17

요즘 느끼는게 ... DB는 데이타 저장만 하는 곳 같아요. 게임 서버단에서 처리 다 하고 원인 + 결과만 DB에 저장 끝. 운영쪽은 "원인이 이랬는데 결과는 이랬다"만 알려주고 끝. 그리고 ... 계속 게임 쪽은 DB 모델링을 모르는게 사랑 받겠구나 ... 라는 생각이 듭니다 ㅜㅜ

2015-12-11 17:59:11

제가 잘 몰라서 그러는데, 살짝 언급된 DB에서 데이터 검색...일경우는요? 트랜잭션이야 그렇다 치더라도..

2015-12-11 18:56:40

특정상황에서 성능을 위해서는 괜찮은 방법. 그러나 협업이나 관리차원에서는 좋은지 모르겠습니다. 상황에따라 다르므로 무조건적으로 적용하면 안되겠습니다;;

2015-12-11 19:05:25

검색자체는 elastic search같은곳에 별도로 데이터를 퍼올려서 하지 않을까 싶은데요..

2015-12-11 19:06:16

국내 서비스만 한다면 쉽게 이해하기 힘든 처리 방식이라고 생각할 법도 합니다....상대적으로 인력도 많이 부족하고, 대한민국 유저 풀로는 사실 다르게 접근해야할 케이스라서요.. (글로벌 서비스하는 분들은 아시겠지만...) 중국의 경우 제가 들었던 어느 스튜디오는 모바일 게임서버 하나 개발하는데 15명씩 붙어서 했다고 합니다. 그리고 여기 R&D 센터의 경우 수십명의 DB/서버프레임워크 개발진이 있어서 우려하는 공용 운영툴 등의 문제도 인력으로(?) 커버해버리네요. (심지어 테스트팀도 잘 꾸려져있습니다.... 버전 패키징 및 유닛테스트 전용팀...) 어지간한 툴은 다 만들어져있고, 개발사나 스튜디오에 제공하다가 모지란것들 있으면 한달내로 뚝딱 만들어줍니다(....) 고로 이건... 뭐랄까 시장에 따른 각기 다른 양상 아닐까요... 근데 RDB에서 샤딩하게 되면 트랜젝션에 대한 고민은 똑같지 않나요? (제가 DBA는 아니라서...) 서버단 트랜젝션이니 뭐니 이런건 성능상의 문제 이슈가 상당하고요... 어짜피 이런 문제들로 고민할꺼라면 전자나 후자나 큰 차이가 없을 것 같기도 하네요...

2015-12-11 19:07:01

사실 뭐 장단점을 논하자면.. 끝이 없겠지만. 말씀하신 캐릭터 정보를 저장하는 DB스키마가 제가 이해한 아래 내용이고 | 캐릭터 UID | 직열화 된 캐릭터 정보 바이너리 데이터(레벨, 클래스, 위치정보, 스탯정보, 경험치정보 등등등) | 검색 이슈 및 운영상 캐릭터 정보에 대한 배치 업데이트 이슈가 거의 없다면, 차라리 백업을 위한 스토리지 서버 따로 놓고 디스크를 미러로 구성하고 파일로 저장하는데 낫다는 생각이 들어요.  괜히 DB에 넣어 구문분석 및 실행계획 절차를 거칠 이유가 없을것 같네요.

2015-12-11 19:25:21

모조리 한 컬럼에 때려박는게 아니라 최소한의 entity 구분은 하겠죠?  사실 지표만 별도의 플랫폼에 잘 쌓아준다면 직접 DB에서 데이터 뒤적거리며 추출할 일이  지금까지는 별로 없어서 일견 이해는 갑니다만, 저렇게 바이너리 쌩으로 직렬화해서 때려박았을때  포멧에 오류가 있거나 업데이트로 인해서 변경이 일어났을때는 배치처리를 어떻게 해야할까요?  DB 설계하는 부분은 단순해 지는 느낌인데 운영을 어떤식으로 해나갈지는 저는 감도 안오네요 ㅠㅠ...

2015-12-11 19:53:46

이게 효과적일 수도 있었던거군요 ㄷㄷㄷ 첫 MMORPG가 이렇게 개발되었었는데, 아이템 복사, 캐릭터 정보 통채로 복사 등등 수 많은 문제점을 일으켜서 다시는 저렇게 개발하지 않을꺼야 했는데 ㄷㄷㄷ

2015-12-11 19:54:19

운영툴이 예술일것 같은데요. 사용자 정보 / 아이템 지급&회수를 한다면 툴서버에서 DB에 저장된 바이너리 읽어서 파싱 -> 업데이트 -> 다시 직렬화 저장 ... ㅋㅋㅋ 구조 변경되면 점검 걸겠지만... 배치 서버에서 똑같은짓을... ㅋㅋㅋ .... 도전 욕구가 -_-;;

2015-12-11 20:08:25

제발...

2015-12-11 20:12:53

상황에 따라 그게 나을 수도 있겠죠. http://eincs.com/2012/06/nosql-is-not-useful/ 오래전 글이지만 이런 걸 보면 페북도 MySQL 을 key-value 의 NoSQL처럼 사용하고 있다고 나오니까요.

2015-12-11 21:09:27

ㄴ NoSQL 처럼 썼다기 보다는, 샤딩을 해서 디비서 조인 못하고 서버에 퍼와서 조인 한다는 내용 같아요. 바이너리로 때려박았다고 해석되기엔 근거가 부족합니다 ㅋ

2015-12-11 21:18:42

바이너리까지의 이야기는 아니고, 일반적이지 않은 방법으로도 쓴다는 의미라서요. ^^

2015-12-11 21:33:14

요즘 누가 디스크를 쓴다고...

2015-12-12 00:27:30

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

ps. 만든 놈이 세계에서 몇 안 되는 초 천재급에 그가 만든 코드는 0과 같이 절대적인 완벽함을 보장하고, 데이터 패치 등도 절대 실수가 나올 수 없는 프로세스를 가진 조직이라면 좋은 방법이라 생각합니다.(물론 업무 관련 툴도 전부 만든 놈이 제공해야 함.)

2015-12-12 00:52:22

양날의 검이네요 만약 서버 개발자가 학력이 낮다거나 한다면 무식하다며 독박쓸수도

2015-12-12 06:48:17

중국넘들중에 그런 넘들이 있는가보다 하면 될거 같습니다 Imays님이 가끔 올리는 중국이야기는 톡특해서 올렷을뿐이라고 생각됩니다. 다만 제가 사장인데   RDB로 저런짓거리하고있었다면   바로 짤랐을거 같네요.

2015-12-12 08:31:17

속도좀 올려보겠다고  코드를 어셈블리로 다 바꾸는거와 뭐가 다른지 모르겠어요

2015-12-12 08:35:55

드립치기전에 찾아봤는데 진짜 있어서 놀라운 http://w.hankyung.com/news/app/newsview.php?aid=2008091045371&sid=01184004&nid=254<ype=1&q= 고속에서 사이드미러를 접으면 차가 받는 공기저항을 줄여 연비를 높일 수 있다... 내리막길에 기어 중립(N) 두기... 와이퍼나 전조등 같은 전기장치를 끄면 제너레이터 가동을 줄여 연료의 2~3% 정도를 줄일 수 있다... 아침엔 기온이 낮아 휘발유 등 연료의 밀도가 높아져 연비가 높아진다는 얘기가 있지만 ... 기름을 적게 채우면 차량 무게가 가벼워져 그만큼 연비가 좋아진다...

2015-12-12 09:48:00

근데 'RDBMS를 쓰면서 트랜잭션을 안 건다'는 건 무슨 뜻이죠?해당 DB의 설정을 바꿔서 트랜잭션 로그 기능을 꺼 놓는다는 얘긴가요?

2015-12-12 10:05:07

디스크 헤드 걱정하는 건 좀...어차피 메모리 버퍼에서 한참 놀다가 디스크에 들어가기 때문에 어플리케이션에서 write하는 순서와 디스크에 실제 write하는 순서와는 관계가 없을 텐데요. 현재 로그인 중인 모든 사용자의 데이터를 한꺼번에 저장하는 거라면 몰라도.

2015-12-12 10:08:08

중국에서 초대박 게임이 나오면 동접1억일텐데 그런 게임의 서버는 어디 사막에 빌딩이 있고 그 빌딩은 모든층이 서버로 가득찬 상상을 하네요.

2015-12-12 10:40:12

@노코드

2015-12-12 12:28:06

저도 사용자의 특정 정보(아이템, 파티) json 으로 저장해본적이 있어요. 완전히 통으로 넣을 용기는 없었고요 ㅋㅋ

2015-12-12 15:55:00

전반적으로 부정적인 시각이 많네요. 이래서 프레임이 무서운가봅니다. 현실적으로 보면 많은 분들의 경험이나 말씀들이 90%에 가까울만큼 맞는 말이지만... (저도 한 2년전까지만해도 그랬고요) 컬럼수의 한계로 인한 문자열 파싱 처리 라던가, 컬럼구조의 수정 이슈라던가 등등의... RDB의 고유기능만을 사용해서 처리하기 어려워 우회하는 기능들도 상당히 많이 존재할텐데요... 이를 위해 서버단에서 처리를 한다거나 성능의 일정 부분을 포기한다거나 하는 사례들이 많이 있을텐데, 서버단에서 처리하는거면 key-value냐 아니냐의 문제의 논점과는 벗어날꺼같고요. 이때 발생될 수 있는 파싱 비용, 버려지는 더미 컬럼, 데이터 버전처리 문제 등... 충분한 시간과 인력이 있다는 가정하에 개발 코스트는 별 차이 없을것 같긴 합니다. 운영툴의 경우에도 뭐... 쿼리 짜는거나 가져와서 시렬라이징 처리 하는거나...  백엔드 라이브러리만 잘 처리 되있다면 큰 차이 없을 것 같고요. (다만 적응의 문제가 있을 수 있겠네요. SQL에 적응되어 있는 상태...) 그냥 결론은 제 생각에 이 부분에 대한 정답은 없다고 보는데, 분위기가 저렇게 쓰면 짤린다, 책임져야한다 등의 무거운 내용들이 있어서, 기술적인 시각이 편향되지 않았으면 하는 바램에서 써봅니다. (충분히 생각해보고 연구해볼만한 가치 아닌가요?) 기술이란 상황에 따라 이렇게도 저렇게도 쓰일 수 있는거라 봅니다. 참고로 전민돌격(한국의 '백발백중')도 바이너리로 때려박습니다.

2015-12-12 17:27:05

DB 문외한인데요. 검색 좀 해보니 바이너리 데이터 타입도 존재하고 ( http://ra2kstar.tistory.com/82 => BLOB ) 저런 걸 필요로 하는 사람도 실제로 꽤 존재하긴 하네요. 암튼 DB를 단지 데이터 저장용으로 쓴다는 건... 재밌네요. ㅋ

2015-12-13 12:44:20

전 GAE쓸때 파일시스템 없이 그냥 BLOB으로 때려박는거 정말 적응못하겠던데 ㅋ

2015-12-13 12:47:20

http://stackoverflow.com/questions/2693081/does-google-app-engine-allow-creation-of-files-and-folders-on-the-server

2015-12-13 12:48:49

실제로 존재하는걸 떠나서 구글앱엔진에서는 강제합니다 ㅋㅋ이거 처음에 받아들이기 정말 힘들었어요

2015-12-13 13:01:42

역시나, 호불호가 갈리는 의견들이 나오네요. 당연하죠. 저도 쉽게 동의하기 어려운 방법, 아니 꼼수니까요. 참고로, 5년전에 저 대화를 나누었던 사람은, 중국에서 꽤 큰 게임회사의 서버팀장을 맡고 있었습니다. 제가 기억이 확실하다면, 미국 MIT 공과대학 출신입니다. 디비 설계에 대한 지식이 딸려서 저렇게밖에 못한거라고 보기는 어렵습니다.

2015-12-13 15:54:55

저는 전혀 놀라지 않았는데요. 저도 게임 규묘만 좀 있었으면 이 아키텍쳐 사용했을겁니다. 게임쪽이라 그렇지 대형 웹사이트들에서는 흔할뿐만 아니라 거의 표준동작입니다. 레딧을 예로 달랑 postgresql테이블 두장입니다. 실제로 많은 대형웹사이트들의 메인 디비는 키밸류엔진으로만 사용되는 mysql입니다. 데이터 분석? 하둡마저 가끔만 이용하고 postgresql쓴다더라구요. 일예로,주어들은 텐센트얘기입니다.

2015-12-13 16:02:19

적재적소. 딱 그것 뿐.  동접이 몇이 되었든, 회원이 얼마나 되든 주어진 돈과 시간에 적합한 솔루션을 쓰면 됩니다.

2015-12-13 16:30:31

@배대표님. 스탠포드 칼텍 엠아티 출신들 중에도 바보들 많으니 너무 신뢰하심 이니됨미다... ㅜㅠ

2015-12-13 16:33:05

방금은 게임이 아닌쪽 얘기를 했으니까 이젠 다시 게임으로 돌아와볼까요? 넷이즈의 몽환서유는 중국의 MMORPG 인데 누적 유저수가 2.5억이라고 합니다. 이 게임의 데이터 저장 솔루션은 무엇인지 아십니까? 파일입니다. 유저 하나당 파일 하나입니다. 물론 더 많은 기술적 디테일을 보태야 완정한 형태설명이나 완정한 스토리가 되겠지만, 어쨌든 핵심은 이것입니다. 더 기상천외한 솔루션을 얘기해볼까요? 중국의 COC 비슷한 게임인데 역시 넷이즈 당시의 CTO, 몽환서유 메인개발자가 나와서 만든 게임입니다. 이 게임의 데이터 저장 솔루션은 샤딩된 redis입니다. 각 redis인스턴스가 데이터 랜딩(landing, 착륙) 로직을 책임집니다. 데이터 랜딩은 redis자체의 save나 bgsave를 사용하지 않고 해당 노드(기기)에 있는 서비스(프로세스)가 책임집니다. 스토리지 엔진은 unqlite입니다(C언어 버전의 LevelDB라고 보시면 됩니다). 이 개발자의 이름은 Cloud Wu이고 중국에가 제일 유명한 게임 개발자입니다. 중국쪽이랑 혹은 중국 개발자랑 많이 접촉해보신 게임개발자분들은 아마 다 이분을 아실겁니다. p.s. 이상 내용은 다 인터넷에 공개된 자료에 근거한겁니다. 링크들은 첨부하지 않겠습니다. 정말 증명하거나 부증하고싶으신 분들은 분명 다 출처를 스스로 찾을 수 있으실겁니다.

2015-12-13 17:28:33

ㄴ 헐, 실제로 단순 파일에 서비스를 하는 업체가 있었군요.  어차피 검색 못할거면, 그냥 유저별로 파일에 저장하는게 훨씬 속도가 빠를거라고 짐작하고 있었는데요[1], 진짜로 그렇게 하기도 하는군요! Cloud Wu의 영향 때문인지 제가 중국에서 만난 서버개발자들은 Lua를 많이 쓰더라구요. C++은 크래시 때문에 위험해서 안쓴다고 합니다. --------- [1] 성능 테스트 결과 DB 테이블에 저장하는 것보다 파일 기록 속도가 약 10~100배 정도 빠릅니다.

2015-12-13 18:01:17

이런 느낌입니다.... 정원보다 10배 태우고도 굴러가긴 하겠죠....

2015-12-13 19:19:09

ㄴ 가끔 사람하나 떨어져도 운영이슈로 커버하구요? ㄷㄷ

2015-12-13 22:51:42

ㄴㄴ관리자도 저정도 기세로 붙어 있을테니 문제X일려나요 ㄷㄷ

2015-12-13 23:06:09

저도 비슷한 생각으로 BLOB로만 사용할거면 파일로 사용하는 게 편하지 않나 생각되네요. 예전에 머드게임들도 이런식의 파일 방식으로 많이 운영됐었는데 메모리 형태로 한 번에 밀어넣다보니 데이터 구조체를 중간에 변경하기가 힘들어 예약된 char 버퍼를 하나 크게 만든 후 padding bytes 계산해서 필요할 때마다 잘라 사용하니 데이터 필드 변경 이슈로부터도 크게 문제가 없었습니다. 하지만 I/O 속도가 서버에 바로 영향을 미쳐버리는 단점이 있기 때문에 요즘 같이 접속자가 많은 시대에는 별도의 캐시 서버를 만들어야 할 수도 있겠네요. 물론 필드 검색(이것은 BLOB인 이상 DB 형태로도 힘들죠)과 백업은 별도 툴을 만들어 사용해야 겠지만 키 검색은 폴더를 잘 나누는 방식으로 해결하면 되고 (파일 시스템에 따라 최대 개수를 고려하여) 위험 요소는 RAID 깨지는 것을 고려한다면 데이터베이스가 통째로 깨지는 것 보다 일부 파일들이 소실되는 게 오히려 더 빠른 복구가 가능하다는 장점이 있지 않을까 생각됩니다. 물론 위 모든 전제는 BLOB 형태로 통째로 밀어 넣는다는 전제입니다. :)

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

이런 글이 너무 좋습니다.잘 배우고 갑니다!

2015-12-14 03:44:52

바이너리는..수정이 극악..입니다 ㅠㅠㅠ..관련 툴이나 부가 작업이 가능하게 서포팅이 되어야함...

2015-12-14 08:55:31

이럴바엔 그냥 IMDG 를 쓰고 백업으로 RDBMS 등을 연동하는게 낫겠네요. 그리고 위에서 잠깐 언급된 BLOB 같은 바이너리 DB 저장 타입은 매우 느립니다. 그래서 실제로는 File System 에 저장하고 경로만 varchar 로 저장하는 형태로 쓰지, BLOB 에 바이너리를 넣어두고 쓰는 경우는 없다고 봐도 무방합니다.

2015-12-14 10:31:56

 

 

 

반응형

 

728x90

 

 

 

아...IMDB 이야기 나와서...좀 더 하자면, IMDG 는 말 그대로 메모리에 저장하는 형태이기 때문에 속도가 당연히 빠르고 Data Grid 라는 말 답게 Cluster, Sharding 을 지원하는 놈들이 대부분이며, DBMS 나 NoSQL 와는 달리 Game Server Logic 이 있는 곳에 통합되어 있기 때문에 서버의 대수가 늘어나는 문제도 줄어드는 장점이 있죠. 이 말은 DB 가 있는 서버와 네트워크 통신을 해야하는 문제가 줄어든다(물론 IMDG 들끼리의 통신은 여전하지만)는 장점이 있습니다. 돈만 있으면 코히어런스(Oracle Coherence) 같은 놈의 도입을 추천해봅니다.

2015-12-14 10:36:14

그럴바에는 redis에 던지고 말죠. 실제로 요즘 이렇게들 한다고 합니다. 위에서도 소개해드렸듯이.

2015-12-14 11:32:34

ㄴ 공감합니다. 위 제약사항을 허용하면 그게 베스트겠네요.

2015-12-14 11:45:28

제가 만들고 있는 게임이 메인 저장소로 redis를 씁니다. 복수개의 redis 인스턴스들을 Twemproxy로 샤딩하고 있습니다. 모바일의 경우 한번 게임 해보고 안돌아오는 유져가 상당한데 이런 유져의 데이터는 Redis로부터 백업용도의 MariaDB로 이전시키는 구조입니다(물론 이 유져가 오랜만에 돌아오는 순간 다시 Redis로 이동시킵니다).  주 저장소를 Redis를 쓰는 바람에 일체의 관계형 연산이 불가능하므로 통계자료의 추출이 힘든건 사실입니다만 이런 유져 데이터의 분석은 스플렁크나 기타 텍스트 로그 파일기반 빅데이터 분석 솔루션을 사용하는 방향으로 개발하고 있습니다.

2015-12-20 12:38:01

Redis 는 용량 압박이... 그래서 Redis + MongoDB 조합도 많이 쓰시죠. 차라리...병이 도져서 Couchbase 같은걸 고민하게 되고...그런거죠.

 

 

 

 

 

=======================

=======================

=======================

 

 

 

 

출처: http://www.gamecodi.com/board/zboard.php?id=GAMECODI_Talkdev&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=3719

 

철광석도 거뜬히 나르는 표준 궤도와 기차에 있어서 휴먼 정원 * 10 은, 임팩트가 속력에 미치는것이 아니라 유저경험에 미치는거겠죠? 소프트웨어에 있어서 정원 * 10 은 굴러가지 않습니다. (이 결론에 놀라움을 표하지는 않으시겠죠?) 반면에 코앞에 부딪치는 성능병목을 풀어내지 못하면 10%도 더 못태우겠죠? 실제로 몽환서유의 유저경험은 어땠을까요? 음 유저경험은 주관적인 것이니까 판단근거가 없겠네요. 그럼 대충 성적만 봐볼까요? 위에서 누적 유저수가 2.5억이라고 했는데 구 데이터더라구요, 제가 본 최근 데이터는 3.1억이라고 하더라구요. MMORPG인데 최고동접은 271만이라고 합니다. 솔루션이 불합리적이면 막 녹아내리는 "철도"였을텐데 그걸 풀어낸게 장하다고 생각됩니다. 스레드에서 언급 안된게 있는 것 같은데 바로 MyISAM같은 "트랜잭션 지원하지 않는" 스토리지 엔진도 하나의 도큐멘트마다에는 원자성을 제공합니다. 이는 현대 No-SQL솔루션들과 다를바 없습니다. (MongoDB, Couchbase, Riak, Cassandra....) 특히, MMORPG라서 게임 상태가 다 메모리에서 굴러가는 아키텍쳐에서, key-value 아키텍쳐에서, 분산이 무엇보다도 쉬웠을텐데! 파일이 아니라, MyISAM, 나아가서 InnoDB 심지어 자체개발 스토리지엔진 일지언정, 분산만 더 하면 됬을텐데 말입니다. Key-Value아키텍쳐의 진정한 어드반티지가 바로 여기에 있는 것이 아니겠습니까? 그럼에도 안했다는건 안해도 된다는 확신과 안하겠다는 의지에서였겠죠? 그럼 파일을 이용한 "낙후하고 미련하고 우둔한 솔루션" 말고, 현대적인 RDBMS솔루션, 보다 더 현대적인 Node.js + MongoDB를 사용했다는, 최고 동접 86만 기록을 찍은 FIFA 온라인 3는 어땠을까요? 고부하에서 여기저기 깨진 (분산식) 트랜잭션을 사후 스캐닝해서 복구해줬다고 합니다. 이건 무상태 프로그램으로서 게임 상태가 전부 DB에 있는데도 말입니다. 트랜잭션을 메모리에서 처리하는 MMORPG에 있어서, 디스크는 백업용일 뿐인데, 그걸 파일로 저장한게 그렇게 우둔했을까요? 저는 아니라고 봅니다. 반면에 파일까지 사용할 수 있는, 틀을 과감히 깰 수 있는 기술력과 패기, 그걸 추진시킬 수 있는 추진력(진행과정에 포로토타입 더미 데이터 벤치마킹도 했겠죠?), 최종 성사시킬 수 있는 능력, 이 모든것들을 저는 개인적으로 모두 아주 높게 삽니다. "교과서 방식"을 (성공적으로) 깨는 사람이야말로 정말 "교과서"를 통달한 것이라고 생각합니다. 나아가 일부 "현대적인 방식"을 무모하게 굳게 믿고있는 사람들이 우러러 보는 솔루션들도 파일로 데이터 랜딩을 합니다: Redis, GemFire, LevelDB, 심지어 그들이 굳게 믿고 있는 RDBMS! 그래픽 프로그래머들은 말합니다: 나에게 점을 그리는 함수 하나만 주면 난 전체 우주를 다 그려낼 수 있어. 서버 프로그래머들은 유사한 문구를 만든다면 아마 이런 말을 하겠죠? 나에게 자료형과 알고리즘을 주면 난 모든 문제를 풀어낼 수 있어. 짤방은 사례를 설명하는 정확성에 강한 것이 아니라 다만 표현력에 강한 것이라고 생각하며, 이런 짤방을 올려봅니다.

 

----------------------------------------------------------------------------------------------------------------------------------------------------

 

 

어머, "답글달기"를 눌렀더니 새로운 스레드가 시작되네요. 게임코디 초보의 실수를 양해해 주십시오ㅠ 글은 삭제가 안되나요? 그나저나 코멘트 달기에서는 이미지 첨부가 안되는것 같던데요? ㅠㅠ

2015-12-14 02:43:57

충분히 답글로 쓸만한 글이었던거 같습니다 ㅋ

2015-12-14 09:38:54

레이더스의 저 명장면은 원래 채찍으로 제압하는 거였는데, 해리슨 포드가 식중독에 걸려 힘들어 하자 권총으로 바꿨다는...'궁하면 통한다.'

2015-12-14 10:03:10

애초에 RDB가 만능이라고 한 토론이 전혀아닌거 같은데요 RDB에 통짜 저장하는게 제대로 된 DB 활용이냐는 의문인걸로 압니다 RDB가  안맞으면 NO_SQL를 쓰던 , 맞는 걸 쓰면 되지 ,  RDB로 자꾸 통짜 저장하고 연결시키는지 모르겠네요.

2015-12-14 10:07:33

ㄴ 실은 그냥 key-value로 쓸꺼냐 아니냐의 차이인데, key-value모델로 갈바에는 rdbms접근이 결코 흔히 언급되는 MongoDB나 Dynamo등 NoSQL솔루션보다 덜 우아하거나 낙후한 솔루션이 아니라는 점을 얘기하고 싶었습니다. 실제로 많은 아키텍트들이 rdbms를 더 믿는 것도 사실이고, 많은 탑 IT기업들에서 이 모델을 사용하고 있는 것도 사실이입니다. 원 스레드에서 쟁점이 되던 것들은 그어떤 특정 점이라기 보다는 원문에서 소개한 여러개의 기술선택이 아니었나 싶습니다.

2015-12-14 10:41:44

애초에 중국 서버 프로그래머가 말한 RDB에 통짜 저장과     하드디스크 읽을때 헤드가 떨어질때 이야기와 4k 운운 할때부터 사실 그 프로그래머의 상식이 대단히 의심스러웠습니다 애초에 코드 명령과 하드디스크의 읽기 자체가 동기화 되어 있지도 않고,  하드의 헤드는 계속 하드 디스크를 읽고 있기때문에 어차피 붙어 있어 있을건데 ,  헤드가 붙어있는지 떨어져 있는지 타이밍 자체가 뭔 의미가 있으며,  하드 디스크 읽기단위도 4k 단위가 아니라  훨씬 큰 단위입니다.  64k인가?  하튼간 무슨 말도 안되는 이야기인지....... [ 요즘은 아마 몇백 k 단위일지도? ]   통짜를 4k 단위로 짠다는건 애초부터, 가정이 잘못되어 있습니다. 문서화되어 있지 않는 캐쉬 단위에 의존한다?   설사 완벽히 그걸 알아냈다쳐도, 하드디스크가 바뀌거나 OS가 바뀌거나  할때마다 다시 4k 블럭단위를 바꾸어야까요? OS책 한권 읽어봐도 물리적 읽기 단위가 4k인 시절은 2000대 초반? 일까? 도데체 어느시대적 이야기를 하는건지.   게다가 그걸 압축까지 한다는둥.....  듣자 듣자하니 , 어설프게 배운 지식으로 도가 지나치다고나 할까요?

2015-12-14 11:05:30

최대한 데이터를 작게 해야 HDD를 연속방문해서 성능이 잘나온다, HDD에 압축된 데이터를 저장한다. 다 잘못된 점 없는 것 같은데요?

2015-12-14 11:25:54

이 쓰레드의 문제는 Goal 의 문제가 아닌것 같네요.

2015-12-14 11:49:08

4k는 웬만한 하드웨어는 2의 n승을 단위로 사용하는데 어떤 플랫폼이든 4k 이하는 잘 없으니다양하게 만족시키면서 최대로 한번에 기록하는 단위로 4k를 선택하고 그 이상은 어차피 4k의 배수라는 생각으로 결정한 것이 아닐까 싶습니다. 그리고 결론적으로 그 개발진의 그 노하우 안에서 저 결정이 가장 적합한 결정이었겠죠.

2015-12-14 12:03:11

음... 뭐 그 중국인 서버 프로그래머가.. 얼마만큼의 HW지식과 OS 지식을 가졌는진 모르겠으나..Quantum Time, OS Scheduling 등등 깊은 수준까지 이해하고 있는 엔지니어이길 바라고요... (짧은 글 읽어본 소감으론 아닐 것 같아서..)   한정된 자원과 시간으로 적당히 잘 풀어서 서비스 만들면 됩니다. 그래서 저라면 저라면 @@@에 @@@@에다 @@ 구성 하겠습니다... 라고 썼던거고요.   뭐든지 적재적소... 쓰라고 만든 기술들이고 잘 쓰면 좋은겁니다. 비즈니스 복잡도에 따라 저장 솔루션 선택해야 하는게 맞고요.   저는 CS(Customer Service)를 수행한다는 가정 하에. 거래, 시장, 경매장 등등도 존재해버리는 복잡도 쩌는 MMORPG라면 절대적으로 RDB 써야한다 맹신하는 바이고...   사실 피파온3이 동접 80만 넘었다지만... RDB로도 받을 수 있어요 그런건..  장애 해결한다고 수개월 밤새가며 여럿 개고생한거 생각하면.. 그리고 직접 그 상황에 있는 현업 담당자라면... 절대 비추할만한 시츄에이션이라 확신합니다.. ㅋㅋㅋㅋㅋㅋ   동접 80만을 받았다!! 가 중요한게 아니라 얼만큼 안정적으로 원하는 비즈니스 니즈를 해소할 수 있는가가 중요하니까요. 기술은 도구일 뿐...   그리고 4K 4K 하는데... RAID 구성된 IO Subsystem에서의 IO패턴은 어떻게 움직일까요?!!

2015-12-14 12:53:34

비즈니스 복잡도가 낮고 스토리지 엔지니어나 DBA가 부족한 반면, 개발능력이 높다면 NoSQL류 사용이 용이할 수 있고요.스토리지 엔지니어나 DBA가 있는 환경이라면 섞어 쓰기도 가능하고.. RDB와 캐시서버만으로도 가능하고.. 뭐 주어진 환경에 따라 구성할 수 있는 아키텍처가 천차 만별입니다. 개발, 스토리지(DBA) 두 마리 토끼 다 가진 조직이라면 젤 좋은 방향으로 골라 쓰면 됩니다...ㅋㅋㅋ

2015-12-14 13:02:27

피파3온라인 이 3년전 12월에 오픈했죠.. 1주일만 더 있으면 만으로3년 출시후 여러가지 서버 이슈들을 해결하면서, 그내용으로 비공개 강연을 했었다고 합니다. 대부분 몽고디비에 대한 내용이고, (몽고디비가 문제가 아니라 몽고디비의 특징 때문에 발생한) 현업 DBA님들 그냥 RDB로 했으면 그냥 잘됐을 텐데..라는 반응이 있었고. 마지막엔 디비를 mysql로 전환 할 계획이라는 내용도 있었다고. 그러나 현재는 여전히 몽고디비? 같아요.. 한번 오픈한건.. 못바꾸죠;;;

2015-12-14 13:17:38

ㄴ ㅋㅋㅋ 당시 아무도 insert 웅쾅쾅 때리면 그지랄 나는 줄 몰랐음요....ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

2015-12-14 13:19:01

글구 솔루션 마이그레이션...은.. 잘 안될 바쁠 당시엔 아 이거 꼭 바꾸고만다~ 하고 이 바득바득 갈지만.. 막상 안정화 시키고나면... 개고생 해가며 서비스 안정화 시켰는데 돌아오는 돈은 쥐꼬리만한 월급이고 이걸 바꿔봐야 나 좋은거 하나 없고... blablabla~ 해서 그냥 뭍어버리는게 대부분이라능... 성과, 실적에 대한 보상이 합리적이였다면 진작 바꿨쥬.... ㅋㅋㅋ 해도 바뀔게 없는거 뻔히 보이니까 이건 뭐...ㅋㅋㅋㅋ

2015-12-14 13:21:06

http://www.slideshare.net/blahstyle/jwkim-ndc-mongodbfinal http://ndcreplay.nexon.com/NDC2015/sessions/NDC2015_0029.html#k%5B%5D=%ED%94%BC%ED%8C%8C 타산지석!

2015-12-14 13:28:07

SQL Server 사용하고 테이블 하나 2TB 넘는데 DB 1대로 잘만 운영되고 있는 서비스도 있어유.. 초당 2만 배치 발생...개발자님들... 그냥 너도나도 큰 서비스들 쓴다고 NoSQL의 망상에 사로잡히면 곤란합니다. 아키텍처를 이해하고 어따 쓰면 좋겠다를 생각해두고 자신의 환경에 맞는 솔루션을 도입하는거고.. 그 솔루션을 선택함으로 발생할 수 있는 사이드이펙트 역시 전부 고려되어야 해요. (서비스 규모는 키울 수 있더라도 비즈니스 복잡도를 못 높인다거나.. 두 마리 토끼를 다 잡아야한다거나 등등...) 페이스북도 MySQL 씁니다... -_ -a RDB 성능 안 나빠유~ 잘 만들면 되는거에유~~~

2015-12-14 13:30:58

ㄴㄴ ㅋㅋㅋㅋㅋㅋ라이브러리 버그 정말 꿀잼였... ㅋㅋㅋ

2015-12-14 13:44:49

일반적인 RDBMS의 아키텍처를 대강이라도 알면, HDD를 사용해도 헤더 움직임과 상관없이 성능을 뽑아내는 구조라는 것을 알 수 있어요. SSD안써도 원래 졸빠름요. 세팅이 문젠거져. 대부분 걍설치된 디비는 1단놓고 60달리는거져.

2015-12-14 13:44:53

하드 디스크 헤더 움직임은 디스크 포맷 시 정하는 Cluster Size에 의존하지 않을까요? 파일이 디스크를 점유하는 최소 단위이기 때문에 이 크기 미만의 Bytes를 기록하면 불필요한 헤더 움직임 없이 한 번에 파일을 기록할 수 있다는 주장은 어느정도 신뢰성 있지않나 싶습니다. 말씀하신대로 요즘 파일 시스템은 64KB 내로 늘릴 수 있으나, OS의 기본값은 보통 4KB로 정해지고 위 MMORPG의 경우 플레이어 하나 당 파일 한 개를 사용했을테니 확장은 쉽지 않았을 것으로 보입니다. 유저를 3.1억명으로 가정하면 Cluster Size를 4KB 로 잡으면 디스크를 1182 GB만을 사용할 수 있지만, 64KB로 늘려서 사용한다면 18,920 GB. 즉 시중에 나와있는 디스크 하나로 사용하기가 어려워지고 그렇다면 여기서 또 물리적인 Loss가 발생할 수도 있어 이러한 선택은 쉽지 않았을 것입니다. 전 위에서 언급된 MMORPG는 잘 모르지만 우리가 그네들의 정확한 상태를 모르는 입장에서 전해들은 말로만 가지고 극히 부정적이거나 극히 긍정적인 결론을 지을 필요는 없다고 봅니다. 전 글쓰신분의 요지에 전적으로 동감합니다. 어떠한 형태로든 저 많은 인구를 소화할 수 있는 서버 아키텍쳐를 구성하는 능력이 가장 핵심이며 그것을 이뤄낸 성과는 비록 상식적인 기술이 아닐지라도 충분히 박수받아야 할 일이라고 생각합니다.

2015-12-14 13:45:25

@노벅.액세스 패턴에 따라 성능 이슈가 생기것죠. seek냐 scan이냐. 최대 성능 뽑아내도록 똘똘이 수백명이 20년 넘게 만든 잘 설계된 제품들이니까 저는 그냥 씁니다. ㅋㅋ

2015-12-14 13:47:15

기술이 무슨 퇴보하는것도 아니고.......  토론내용이 아예 파일 시스템을 쓰는게 더 낫다까지 가면 막장까지 가는게 아닌가 싶어서하는 말입니다 데이타 베이스라는 시스템이 몇십년된 기술입니다.  파일 시스템이나 통짜 데이터의 단점을 극복하고자 나온 기술이고요. 애초에 중국인이 말했던 내용은 이미 DB에서 모두 지원하는 내용입니다. 심지어 압축기능도 있을겁니다 그는 추측으로  클러스터링 단위나 뭐 캐쉬 단위 어쩌고 하지만 DB에서는 실제로 그걸 파악해서 시스템을 구성해줍니다.  심지어 하드디스크 헤더 읽기에 관한 내용도 DB가 더 잘 파악할겁니다. 뭔짓을해도 프로그래머가 사용하는 단순 read write 함수보다 훨씬 더 명확하고 효율적으로 처리가능한겁니다. 다시 말해 이미 몇십년전부터 , 파일 시스템 및 통짜 데이터     그  모든 그 불합리하것을 극복하고자 나온게  DB라는겁니다 프로그래머가 어설프게 파일 시스템이나 통짜 데이터시스템을 DB처럼 쓴다고  진짜 DB보다 절대 나을수 없는거고요 만약 DB가 더 느리다면 DB를 제대로 구성하지 못하고 매우  비효율적으로 구성했기때문일겁니다. DBA급은 아니더라도 DB에 대해 좀더 배우면 이런 , 아니 대학때 배운 DB 책 몇권 읽은 내용만으로도 지금 거론 대는 문제는 DB의 문제가 아니라 사람의 문제라는 걸 직감적으로 알수 있습니다 시대가 어느때인데 이렇게 퇴보적인 이야기가  이슈가 된다는 자체가 정말 놀랍네요 뭔가 잘못되면 단순하게 1차원적으로 문제를 파악하니까 이런 말도 안되는 결론들이 나오는겁니다

2015-12-14 13:50:03

ㄴ 데이터가 글로벌메모리에 올라와 있으면 캐시히트로 디스크IO 안일어나쥬. 디비튜닝 제대로 했으면 캐시히트 99%가 정상아닌가유 그렇게 되면 그냥 메모리 디비 성능과 비교해볼만;;;;

2015-12-14 13:50:06

역시 똑똑한 억대연봉의 수백명의 훌륭하신 분들이 만들어 놓은 걸 그냥 쓰는 게...저는 코드도 살짝 그렇게 짜요. "그냥 쉽게쉽게 짜는게 컴파일러가 내가 고민하는 거보다 최적화 더 잘해 주니까.."

2015-12-14 13:53:52

@큐피리도헤더 움직임은 seek냐 scan이냐 뿐이고... 그걸 지시하는건 스토리지 레벨이니. (어플리케이션과 OS영역 밖..) 어떤 스토리지 시스템을 쓰느냐, chunk가 몇으로 쪼개지느냐, 그 매니저는 어케 움직이느냐, 캐시 구성이 어떻게 되어있느냐. HBA를 쓰냐 infiniband를 쓰느냐, 쓴다면 구성이 어케 되어있느냐 등등으로 성능이 천차 만별일거라.. 어떤 제품은 한번 IO할 때 128~256k씩 퍼올리기도 하고 어떤놈은 1GB 씩 퍼올리기도 해요.   그리고 반드시 RAID를 구성한다는 전제 하라... 저장 공간은 넉넉할거라 생각됨미다. (OLTP 라이브 서버에 3TB짜리 단일 디스크 쓰는 일은 없으니까요.) 저도 저 업체의 상황에 맞는 대응은 잘 했다고 생각해요. 주어진 돈과 시간으로 최적의 결과를 얻으면 되는 것 뿐. 다만, 멋진 스토리지 엔지니어와 DBA가 있는 조직이였다면 그냥 RDB 썼었을 것 같아요. (저런 정보가 맹신을 야기하기도 하니까요...) 누적 회원 1~2억은 많은게 아니라능... - _-a

2015-12-14 13:58:08

@뿌요뿌요님 사랑흔... 응?!

2015-12-14 14:00:15

@노벅근데 콜드 상태에서 디스크로부터 퍼올리는걸 최적화 시키는건 이런 저런 잡기술이 필요한지라... 그냥 잘 만들면 되요... ㅋㅋㅋ 아키텍처에 따른 물리적 한계가 얼마다!! 만 잘 이해하고 있으면 되니까유 ㅋㅋ

2015-12-14 14:03:47

@뿌요뿌요 저는 파일 시스템이 DB 보다 낫다라는 극단적인 의견을 제시한 것은 아닙니다. 저 역시 DB가 좋고 빠르기에 서비스에 항상 사용하고 있습니다. 다만 우리가 잘 모르는 상황에서 3억명이나 소화한 게임이 더 신기술인 DB를 사용하지 않은 이유를, 단순히 그들의 지식과 경험 부족으로만 판단할 필요까지는 없다고 생각되어 그들의 말도 어느정도 신뢰성이 있지 않을까하고 다른 시각으로 제시해본 의견이었습니다. 오해 없으셨으면 좋겠습니다. @Alucard반문은 아니고 이 분야에 대해서 잘 아시는 것 같아서 제가 잘못된 정보를 가지고 있으면 고치고 싶은 마음에 몇 가지만 여쭤보고 싶습니다.   1. 디스크에 기록과 삭제가 어느정도 일어나다보면 저장할 블록이 디스크 한 공간에 나란히 저장할 수 없게 되지만 클러스터 단위는 보장된다고 알고 있었습니다. 지금 좀 혼동이 와서 그러는데 말씀하신 내용이 4kb 상태의 클러스터에 64kb 데이터를 밀어넣게 되어 이곳저곳 블록이 나뉘어 저장되더라도 I/O 속도 차이가 없을 수도 있는 것인가요? 2. 디스크 1개를 미러링하는 레이드와 디스크 n개를 미러링하는 레이드의 I/O 속도 차이 또한 없는 것인지요?

2015-12-14 15:07:46

1. 클러스터는 OS와 스토리지간 통신할 때 OS가 '나는 이만큼 씩 끊어 읽을거야!'라고 해버리는거라...OS가 4k라 해도 스토리지는는 스토리지의 최소 IO단위로 움직입니다. 4k짜리를 64k에 뙇 던져놓는다거나.. 4k 클러스터에 64k 데이터를 밀어넣게 되믄 os는 4k로 쪼개서 넣어줘~ 하고 스토리지한테 요청할테고(클러스터도 여러개 쓸테고.) 스토리지는 본인의 io단위에 맞춰서 최대한 시리얼하게 밀어넣으려 노력할거고요. 이는 벤더마다 달라유~ @.@ 그래서 성능이 같을 수도 다를 수도 있을겁니다. 2. 읽기는 같거나 빠릅니다. 쓰기는 보통 같습니다.

2015-12-14 15:30:10

http://cappleblog.co.kr/137 요거 설명 잘 되어있네염. https://technet.microsoft.com/en-us/library/dd758814(v=sql.100).aspx 이건 partition start offset 관련된 아티클.

2015-12-14 15:36:35

저였다면 MySQL사용했을겁니다. 그것도 MyISAM도 아닌 InnoDB를 사용했을 겁니다. 값싼 수평확장을 활용하기 위해서죠. 지금 위에 보면 뭔가 노 트랜잭션 얘기도 섞여있고 파일 얘기도 섞여있어서 다소 혼잡하거든요. 좀 나눠서 한번 볼까요? 1. 노 트랜잭션 사실 key-value모델로 갔을 때 InnoDB나 MyISAM이나 비슷합니다. 다시 한번 강조: 트랜잭션은 다 메모리에서 한다고 했죠? DB는 뭐다? 백업이다. 여기서 다시 한번 토론군들이 유상태 서비스와 무상태 서비스를 섞어서 토론을 전개하는걸 반대합시다. 트랜잭션으로 묶은 SQL묶음을 지원하지 않는다 뿐이지 MyISAM이나 MongoDB나 도큐멘트 원자성은 있다없다? 있다. 그리고 실제로 많은 성공한 웹사이트나 게임들에서 이런 접근을 합니다 (이것도 다시 강조하는 것이지만). 일예로 reddit 의 소스 코드를 보십시오. 2. raw 파일 저장 아무도 현대 RDBMS를 부정하기 위해 이 솔루션을 선택하지는 않았을겁니다. 그걸 위해서라면 No-SQL DB를 만들거나 차세데 RDBMS 개발을 했겠죠? 모르긴 몰라도 이런 기술결정을 하게 된데는 당시 문제의 조건과 제한들이 있었을겁니다. 조건과 제한을 떠나서 문제풀이를 평가하기는 어렵겠죠? 다만 특정된 조건과 제한에서 약간 뜻밖의 초이스들이 생겨나는 것이 가능합니다. 모르긴 몰라도 기술담당자가 "이거 굳이 RDBMS가 필요한 경우가 아니네? 증명해보여야겠어." 라는 마인드가 아닐까 싶습니다. 몽황서유는 2003년 출시한 게임이고 사업적으로 굉장히 성공했으며 롱런까지 했습니다. 몽환서유가 성공한 후에 그당시도 많은 분들이 Cloud Wu 에게 몽환서유의 디비 솔루션을 물었을 때 Cloud Wu가 파일로 저장한다고 하면 미쳤다고 평가했다고 합니다. 아마 지금도 비슷하지 않을까 싶습니다. 그리고 제가 최초 포스트에서도 언급했듯이 그건 다만 핵심만 고농도 추출해 전달한 내용이고 기술디테일까지 보태야 완정한 스토리가 된다고 했었죠. 그리고 다시 한번, 여기서 파일은 뭐다? 백업이다 - 정기 백업 및 유저 로그아웃시 랜딩용이다. 트랜잭션은 다 어디에 있다? 메모리에. 로직은 다 어디에 있다? 메모리에. 유상태다 무상태다? 유상태다. 3. 아무도 RDBMS없던 시대로 돌아가자는 주장은 안했습니다. 얼마나 반지식주의적(반과학주의? 반발전주의?)이여야 그런 주장을 할 수 있을까요? 4. 무엇이든 필수는 없다. 깰 수 없는 틀은 없다. 이런 정신을 반대하는 정신을 저는 반대합니다. - 단지 요거일뿐입니다. 동의하면 끝이고 동의하기 어려우면 뭐 어쩔 수 없고, 하는거죠.

2015-12-14 15:58:27

ㄴ 사랑합니다. ㅋㅋ

2015-12-14 16:01:21

@Alucard 와우 친절한 답변 감사드립니다 ^^  그렇다면 단지 DB를 사용한다고해서 64KB든 4KB든 알아서 해결되는 문제는 아니라 저 중국 개발자가 주장했던 4KB에 맞추라는 내용은 벤더에 따른 가장 최선의 선택이 아니었을까요? ^^;; 아니면 DB를 사용하면 마치 디스크 정리와 같은 기능이 있어서 물리적 데이터 위치를 바꿔주고 그러는 것일까요? 그렇다면 또 이야기가 달라질 수 있겠네요.. ㄷㄷ :)

2015-12-14 16:04:38

ㄴ 보통느 4k 권장이니까~ 정도인데... 것도 사실 os에 따라 다를 수가 있기도 하고.. 설정하기 나름에... '무조건 그래!!'라고 단정지으면 곤란한 값이라서요. @.@

2015-12-14 16:23:47

가령 DW같은 대용량 시리얼 IO를 처리해야 한다면 큼직할 수록 좋을 수 있을 것이고... 뭐 상황에 맞게 설정해야 함돵.

2015-12-14 16:24:27

@coolspeed 시점의 문제인듯 한데 2003년에 선택한 솔루션이라면, 대단하네요. 리니지 같은것을 개발한 개발자분도 팬티엄급 CPU에서 1개의 linworld zone에 동시접속 2000명 한번 수용해보려고, 캐릭터 데이터를 통짜로 캐싱해서 1분에 한번 Write-Back 하다가 서버 크래시 발생 시 약 1분가량의 플레이 데이터가 날아가는 문제로 CacheD라는 이름으로 데이터 캐시를 서버로 분리하고 인스턴스 재시작에 대한 Cache Worm Up 문제로 On-Demand 로 캐싱하는 방식 넣고 그래도 CacheD는 죽고, 물리 장비도 죽고, MMO를 이중화 하려니 이건 진짜 빡세고.. 하지만 2015년인 지금에서 그러한 방식이 좋은 솔루션이라고 이야기 하긴 어렵다는 생각은 드네요. 저 시점에는 저도 동시접속 수십만이라고 얘기해도 Zone으로 나누어서 처리했기 때문에 저 시점이 2003년이고 동시접속 100만 이상을 One World로 수용했다면, 대단한것 같아요.

2015-12-14 16:39:51

4K 내에 데이터를 수용하기 위해 유지보수성 포기도 있었을 것 같구요.(c++로는 왠만한 데이터는 char형으로 저장. 시간 데이터는 int32로 저장 요런것들?) 뭐 아직 2038년은 멀었으니.. 아마 압축화한 데이터형들에 대한 볼륨이 커졌을 때  라이브 개발자들의 선조에 대한 원성이 들리는듯 합니다 뭐 아닐수도 있구요.=_= 사실 결과가 좋으면 자잘한 과정에서의 어려운 점들은 무시할수 있겠죠..

2015-12-14 16:45:31

아잉 ㅠ 오타...

2015-12-14 16:56:30

아... 그러고보니 일례로... 스스디가 막 나오기 시작한 시기에 iodrive bmt도하고 뭐 그랬는데. 시기적으로 대중화 되지 못한 타이밍에 io니즈가 쩌는 게임 만들어야 한다 위에서 강압하고 막을 제간은 없고 해서 그러면 장비빨이지! 하고 추진한 게임도 있었슴다. (본래 sql ent요청도 했었는데 그건 까임. 스토리지만 몇 억 짜리 삼) 저는 어플 레벨에서 풀자 강력히 주장했는데 플머들이 배째라 나오고 뭐 어쩔 수 없었어요. 그래서 통짜 디비 한놈으로 동접 47만 받을 수 있게 돈으로 발랐었.... 이 사건이 넥슨 전설급이라던데... 뭐 평가는 개개인의 몫이지만 당시 상황엔 이 결과가 최선였...

2015-12-15 00:10:50

헛... 답글을 늦게 이제 봤네요. 원글에 댓글지우고 이쪽으로 이주를... --------------------------- 위에 언급된 데이터베이스의 서브테크닉 이슈는 당연히 고려되어야 하는거고, 일반적으로 국내에서 서비스하는 유저풀로는 이러한 기술들로 충분히 커버가 가능합니다. 정확한건 데이터를 어떻게 꺼내쓰고 어떻게 저장하고의 문제가 아니고요. 중국의 경우엔 관점이 아예 우리랑 다릅니다. 우리는 얼마나 더 많이 받을까, 어떻게 해야 데이터 관리가 수월할까(운영 이슈등의), 어떻게 해야 좀더 빠른 개발이 가능할까 등을 고민하죠 (뭐 나열하자면 수도 없겠지만...) 반대로 중국애들은 주요 포커싱이 데이터 버저닝과 (매우)플렉시블한 스케일 인아웃입니다. 점검걸고 이런거 웬만해선 용납 안하고요, 서비스 상용전 필수 항목중 하나가 5분내에 스케일 아웃이 가능한 구조를 선호(사실상 강제)합니다. 모든 프로토콜은 무제한(되도록) 하위버전 호환을 중요시 하구요. 단일 프로세스 속도가 조금 느려도 상관없어요(라지만 성능 테스트도 엄청 깐깐하게 합니다) 한국에서 최초 서비스 시작할때 퍼포먼스 테스트를 진행하면서 유입 유저수를 예측하고 진행하죠. 모바일의 경우 이를테면 동접 5만 10만 이런식으로요. 이 수치는 사실 매우 잘됐을때 나올 수 있는 수치입니다. 유입량에 한계가 있다는거죠. 잠깐 점검걸고 기기 때려박고 푸는식으로 연명할 수 있습니다. 유저 이탈률은 미미하구요(별다른 장애가 없다는 가정하에). 문제는 중국은 순간적인 유입량/폭팔력이 한국과는 비교가 되지 않는다는겁니다(페북이니 뭐니 이런것들은 폭팔적인 사용자 증가에 대한 우려를 고려할 만한 시기도 지났을 뿐더러, SNS특성상 그 영향력이 게임보단 덜합니다). 마케팅 한번 띄우면 동접 100~200만 그냥 치고 들어오는데, 그 순간 점검걸고 장비 넣고 이럴 수 없는거죠. 서비스는 계속 돌아가는 와중에 장비는 기하급수적으로 늘려가야하는겁니다. 여기서 생각해볼 수 있는건 "아니 그럼 처음부터 기기 이빠이 때려박고 시작하면 되잖아?" 인데, 폭팔력이 어마무시한만큼 이탈률도 정말 상상을 초월합니다. 자... 그럼 다시 장비 뺄때... 수백대의 장비로부터 데이터 마이그레이션을 어떻게 해야할까요? 문제가 여기서 발생하는 겁니다. RDB 스키마를 사용하는 상태에서 로우마다 각기 다른 버전데이터를 가지고 마이그레이션을 수백대의 장비와 함께 진행해야할때, 기존의 우리가 사용하던 방식으로 최소한의 시간만 가지고 진행해야 한다면 어떻게 하시겠습니까. 이게 더 지옥이 되는거죠. 그냥 서비스 접고 싶을지도 모릅니다. 그래서 배대표님이 듣고 말씀해주신거처럼 저런 솔루션이 빛을 볼 수 밖에 없는 시장인거고요. 그래서 처음부터 그들의 리그에서 필요한 모든 경우의 수를 열어놓고 가기 위한 최고의 솔루션이 저렇게 된게 아닐까 생각이 듭니다. 그래서 얘들은 어떻게 처리하느냐... 저장소 앞단엔 당연히 프록시(캐시)가 떠있습니다. 모든 서버 프로세스, 프록시, 저장소 머신은 직접 컨트롤하지 않습니다. SE단 운영툴을 통해 머신 증축/감축 + 프로세스 실행/종료/배포/데이터 리로드 이런것들이 다 자동화 되어있어야 서비스가 가능합니다. 모든 서비스에는 동시접속 제한이 있습니다(서버 장애로 인한 이탈률 방지). 추가된 머신은 LVS(얘들 L4잘 안씁니다)를 통해 즉각 추가 접속 대응이 됩니다. 저장소는 주로 파일을 사용하고, 특이한 경우 MySQL을 별도 저장소로 같이 사용합니다. (풀어서 얘기했지만 이 기능들을 솔루션화 시켜서 자체 DB로 사용합니다) 그냥 기억나는데로 막 끄적인거라 충분한 설명이 되었을런지 모르겠지만, 시장 형태가 이렇다보니 추구하는 기술과 그 기술의 한계점을 끌어내기 위해 생각하는 방법은 다를 수 밖에 없다는걸 말씀드리고 싶었구요, 본인의 프레임 안에서 '이게 곧 정답이오' '그건 틀렸소' 하는 등의 의견은 배제되었으면 좋겠습니다.  뭐 국내서비스만 할꺼라면 사실 무시해도 상관없지만... 중국에서 국내 시장 점령하고 있는 요즘 형세를 아신다면 이런 기술적인 문제들로 괴롭힘 당할날들이 충분히 곧 오겠지 예상하고 계시리라 생각합니다. 마지막으로 제가 쭉 얘기한 내용과 관련된 중국의 회사는 텐센트 얘기입니다.

2015-12-15 03:46:25

ㄴ좋은 말씀입니다. 전에 말씀하신 하드디스트 섹터 돌아가는 소리보다는 낫네요.그리고 제가 아는 텐센트의 TDR3 내용이랑 좀 많이 다르네요. 텐센트는 Cache 도 Redis 캐시를 권장합니다.

2015-12-15 09:28:51

ㄴ 텐센트가 cache로 redis를 권장하는 이유는 딱 한가지입니다. 국내의 모바일 서비스가 대부분 RDBMS(특히 MSSQL)기반으로 서비스 되고 있는게 많은데, 과거 국내 서비스가 텐센트와의 퍼블리싱에서 기존의 구조를 변경하지 않고(로컬라이징 코스트 최소화) 텐센트 서비스 정책에 합당한 대안을 제시하시오 했을때 넷마블에서 밀어붙였던게 redis입니다. 텐센트에서는 자체 개발한 프레임워크를 사용하여 재개발(?) 하길 권했지만 시장이 그것을 기다려줄 여유도 없을 뿐더러 국내 개발자의 큰 반발로 그것이 성사될 이유가 없죠.  그러다보니 선례가 작용한 케이스로 인해 처음에 한번 물어봐주고, 개발사에서 마땅한 대안을 제시못하거나 서비스 경험이 부족한 기술로의 접근이 이루어질때 '예전에 어떤어떤 게임이 redis 썼으니 너네도 이거 써라' 가 되는겁니다. TDR을 진행해보셨다면 아시겠지만, 텐센트가 좀 자체적으로 답을 정해놓고 퀘스쳔을 던지는 스타일입니다(기술 협의만 몇개월 이루어지기도 합니다). 기술적으로 자신들이 이미 우위에 서있다고 당연히 생각하고 있기 때문인것도 있고요. 일이년전 국내 모바일 게임이 중국시장에 와서 맥도 못추고 사라졌기 때문에 최근엔 관심사에서 벗어난 이유도 있습니다. (그리고 전 하드디스크 섹터 돌아가는 얘기 한적 없어요...)

2015-12-15 10:21:22

좋은 내용입니다. 덕분에 틀을 조금이나마 깨고 갑니다.유익하네요~!!

2015-12-15 11:55:10

MNLT님 글 잘읽었습니다 책으로 쓰시면 살의향이 있을정도로 유익하네요 ㅎㅎ

2015-12-15 11:55:41

간만에 댓글질 좀 했더니만 -ㅅ-; 여기저기서 왜 그러냐고 카톡이..제가 했던건 아니지만 요기도 20년전에는 586급 CPU올라간 서버에서  동접 1000 수용하고, 100 vs 100 공성전을 MMO 백그라운드에서 처리한다고 지금 보면 천인공노(?)할 기법들이 많이 사용되었는데,  그런 접근들이 나쁘다는 것은 아닙니다 -ㅅ-; 회사돈으로 RnD한 내용을 말할수도 없고 -_-.. 하지만 코어수십개씩 달린 CPU를 블레이드 서버에 팍팍 꼽고 MS-SQL 2014 엔터프라이즈 Full Core 라이센스로 설치해서 TPS 나오는거 보면 가끔 다른생각은 들더라구요. 요즘에는 암묵적으로 Redis 는 완벽하다는 가정하에 개발하는 곳들도 있다는데, 사실 HW장애는 없다고 가정하고 개발한다면(저는 동의하지 않습니다), 여러 제약사항을 벗어날 수는 있겠지요..

2015-12-15 14:30:49

ㄴ 고렇게 쓰는데 몇 없는데!! +ㅅ +ㅋㅋㅋ 잡설...텐센트 인프라가 현재 모습을 가지는데 가장 큰 역할을 한 것은 상용 솔루션의 라이센스 비용이라는... - _-;; 개발력만 받쳐주면 mysql or 자체 or nosql등등 되는대로 쓰면 됩니다. - _-a 관련 기술 스페셜리스트 몸값 비싸봐야 연 3억도 안 되요. @.@a 1~3억짜리 다섯명 정도 사다 쓰면 3조 씩은 아낄 수 있으니까 돈 있음 뭐든 됩니다! *그런 텐센트도 오라클 엑사데이터 쓰고있죵... 다 이유가 있고 적재적소에 필요한 솔루션 쓰는검미다.

2015-12-15 16:00:12

3조는 너무 나갔나...? 300~3천억 정도 될라나요... 한참 오랜 몇년 전에... 들었던게.. mysql이 대충 20만대 넘는다 했으니까..

2015-12-15 16:01:51

긍께요.. 텐센트 플랫폼팀에 잘하는 사람 많은건 인정하지만가끔 tlog 라이브러리 업데이트 해서 오는거 보면 멀티쓰레드에서 팍팍 디지고, "멀티쓰레드였어요?" 이러는거 보면 -ㅅ-  솔직히 멀티쓰레드 개발자 많지 않아서 싱글쓰레드 기반으로 막 가는거 아닌가요  기술력 쩐다지만.. 요샌.. 돈으로 많이 바르더만..-ㅅ-

2015-12-15 16:23:55

ㄴ 회사니까 똑같죠 뭐.. 어딜가나 구녕(?)은 있습니다. 그리고 멀티쓰레드는 단일 프로세스에서 극한의 성능을 끌어내야만 하는 프로젝트가 아닌이상 사용 안합니다. 어짜피 호리즌탈 스케일 아웃하기 때문에 단일 머신에서 코어당 프로세스 1개씩 물립니다. 이게 더 안정적이고 어줍짢은 버그투성이의 멀티쓰레드 프로세스보다 성능이 더 잘나오죠. (한때 멀티쓰레드 프로그래밍에 목매었었던 시절이 있었던 만큼.. 이건 처음에 저도 적응이 잘 안됐었...) 대신 프로세스간 통신을 이용하는거구요.  생각해보면 참 지극하게도 현실적인 애들이네요... 첨언해서 TSF4G BASE는 멀티쓰레드 지원을 안합니다.

2015-12-15 16:43:09

후끈후끈하네요. 많은 분들이 열띤 토론이 있을거라 예상했는데, 역시나네요.5년전에 안 것을 이제서야 말씀드린 이유는, 이것이 검증되는 과정이 나오기 전에는 함부로 발설하기가 애매해서였습니다. 원피스 노랜드 선장 대화는 대화이고, 제가 생각하는 바를 말씀드리자면, 1. 바이너리에 때려박느니 그냥 json이나 bson이나 메타데이터 포함 자체포맷으로 저장 후 압축하자. 4KB 용량 맞추기 힘들더라도. 2. 트랜잭션 안 쓴다는 것은 정말 맞음. 국산 게임에서도 트랜잭션 남용하다가 바보되는 경우를 여럿 봐서. 입니다. 결론은, 저희가 만든 게임서버엔진이 중국에서 계정1억 찍은 후에 낼 수 있을 것 같습니다.

 

 

 

=======================

=======================

=======================