|
잉여스멜 : 5%  |
|
|
|
|
|
|
|
 |
개발만담 - 개발,업무,우리의 밥벌이와 관련된 만담 게시판.
Loading...
|
|
[re] 중국의 어떤 서버 개발자의 디비 설계
|
|
 coolspeed
|
|
작성 : 2015-12-14 02:40:19 | 조회 : 6,751
|
|
|
|
|
|
|
|
| 철광석도 거뜬히 나르는 표준 궤도와 기차에 있어서 휴먼 정원 * 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!
그래픽 프로그래머들은 말합니다: 나에게 점을 그리는 함수 하나만 주면 난 전체 우주를 다 그려낼 수 있어.
서버 프로그래머들은 유사한 문구를 만든다면 아마 이런 말을 하겠죠? 나에게 자료형과 알고리즘을 주면 난 모든 문제를 풀어낼 수 있어.
짤방은 사례를 설명하는 정확성에 강한 것이 아니라 다만 표현력에 강한 것이라고 생각하며,
이런 짤방을 올려봅니다.
|
|
|
뿌요뿌요
|
|
|
|
애초에 RDB가 만능이라고 한 토론이 전혀아닌거 같은데요
RDB에 통짜 저장하는게 제대로 된 DB 활용이냐는 의문인걸로 압니다
RDB가 안맞으면 NO_SQL를 쓰던 , 맞는 걸 쓰면 되지 , RDB로 자꾸 통짜 저장하고 연결시키는지 모르겠네요.
 |
|
|
 |
1
|
|
|
|
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대 초반? 일까? 도데체 어느시대적 이야기를 하는건지.
게다가 그걸 압축까지 한다는둥..... 듣자 듣자하니 , 어설프게 배운 지식으로 도가 지나치다고나 할까요?
|
|
1
|
|
|
2
|
|
|
|
2015-12-14
11:05:30
|
|
|
|
|
최대한 데이터를 작게 해야 HDD를 연속방문해서 성능이 잘나온다, HDD에 압축된 데이터를 저장한다. 다 잘못된 점 없는 것 같은데요?
|
2015-12-14
11:25:54
|
 
smileeagle
|
|
|
|
이 쓰레드의 문제는 Goal 의 문제가 아닌것 같네요.
|
2015-12-14
11:49:08
|
|
|
|
|
음... 뭐 그 중국인 서버 프로그래머가.. 얼마만큼의 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
|
|
|
|
|
글구 솔루션 마이그레이션...은..
잘 안될 바쁠 당시엔 아 이거 꼭 바꾸고만다~ 하고 이 바득바득 갈지만.. 막상 안정화 시키고나면... 개고생 해가며 서비스 안정화 시켰는데 돌아오는 돈은 쥐꼬리만한 월급이고 이걸 바꿔봐야 나 좋은거 하나 없고... blablabla~ 해서 그냥 뭍어버리는게 대부분이라능...
성과, 실적에 대한 보상이 합리적이였다면 진작 바꿨쥬.... ㅋㅋㅋ 해도 바뀔게 없는거 뻔히 보이니까 이건 뭐...ㅋㅋㅋㅋ
|
2015-12-14
13:21:06
|
|
|
|
|
SQL Server 사용하고 테이블 하나 2TB 넘는데 DB 1대로 잘만 운영되고 있는 서비스도 있어유.. 초당 2만 배치 발생... 개발자님들... 그냥 너도나도 큰 서비스들 쓴다고 NoSQL의 망상에 사로잡히면 곤란합니다. 아키텍처를 이해하고 어따 쓰면 좋겠다를 생각해두고 자신의 환경에 맞는 솔루션을 도입하는거고.. 그 솔루션을 선택함으로 발생할 수 있는 사이드이펙트 역시 전부 고려되어야 해요. (서비스 규모는 키울 수 있더라도 비즈니스 복잡도를 못 높인다거나.. 두 마리 토끼를 다 잡아야한다거나 등등...)
페이스북도 MySQL 씁니다... -_ -a RDB 성능 안 나빠유~ 잘 만들면 되는거에유~~~
|
2015-12-14
13:30:58
|
큐피리도
|
|
|
|
** 작성자(또는 관리자)에 의해 삭제된 댓글입니다 **
|
2015-12-14
13:34:02
|
노코드
|
|
|
|
일반적인 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차원적으로 문제를 파악하니까 이런 말도 안되는 결론들이 나오는겁니다
|
|
1
|
|
|
2
|
|
|
|
2015-12-14
13:50:03
|
노코드
|
|
|
|
ㄴ 데이터가 글로벌메모리에 올라와 있으면 캐시히트로 디스크IO 안일어나쥬. 디비튜닝 제대로 했으면 캐시히트 99%가 정상아닌가유 그렇게 되면 그냥 메모리 디비 성능과 비교해볼만;;;;
|
2015-12-14
13:50:06
|
|
|
|
|
@큐피리도 헤더 움직임은 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
|
|
|
|
|
|
ㄴ 사랑합니다. ㅋㅋ
|
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
|
smileeagle
|
|
|
|
@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로 수용했다면, 대단한것 같아요.
|
|
1
|
|
|
|
|
|
|
2015-12-14
16:39:51
|
smileeagle
|
|
|
|
4K 내에 데이터를 수용하기 위해 유지보수성 포기도 있었을 것 같구요. (c++로는 왠만한 데이터는 char형으로 저장. 시간 데이터는 int32로 저장 요런것들?)
뭐 아직 2038년은 멀었으니.. 아마 압축화한 데이터형들에 대한 볼륨이 커졌을 때 라이브 개발자들의 선조에 대한 원성이 들리는듯 합니다 뭐 아닐수도 있구요.=_= 사실 결과가 좋으면 자잘한 과정에서의 어려운 점들은 무시할수 있겠죠..
|
2015-12-14
16:45:31
|
smileeagle
|
|
|
|
아잉 ㅠ 오타...
|
2015-12-14
16:56:30
|
|
|
|
|
아... 그러고보니 일례로...
스스디가 막 나오기 시작한 시기에 iodrive bmt도하고 뭐 그랬는데.
시기적으로 대중화 되지 못한 타이밍에 io니즈가 쩌는 게임 만들어야 한다 위에서 강압하고 막을 제간은 없고 해서 그러면 장비빨이지!
하고 추진한 게임도 있었슴다. (본래 sql ent요청도 했었는데 그건 까임. 스토리지만 몇 억 짜리 삼)
저는 어플 레벨에서 풀자 강력히 주장했는데 플머들이 배째라 나오고 뭐 어쩔 수 없었어요.
그래서 통짜 디비 한놈으로 동접 47만 받을 수 있게 돈으로 발랐었....
이 사건이 넥슨 전설급이라던데... 뭐 평가는 개개인의 몫이지만 당시 상황엔 이 결과가 최선였...
|
2015-12-15
00:10:50
|
|
MNLT
|
|
|
|
헛... 답글을 늦게 이제 봤네요. 원글에 댓글지우고 이쪽으로 이주를...
---------------------------
위에 언급된 데이터베이스의 서브테크닉 이슈는 당연히 고려되어야 하는거고, 일반적으로 국내에서 서비스하는 유저풀로는 이러한 기술들로 충분히 커버가 가능합니다. 정확한건 데이터를 어떻게 꺼내쓰고 어떻게 저장하고의 문제가 아니고요. 중국의 경우엔 관점이 아예 우리랑 다릅니다. 우리는 얼마나 더 많이 받을까, 어떻게 해야 데이터 관리가 수월할까(운영 이슈등의), 어떻게 해야 좀더 빠른 개발이 가능할까 등을 고민하죠 (뭐 나열하자면 수도 없겠지만...) 반대로 중국애들은 주요 포커싱이 데이터 버저닝과 (매우)플렉시블한 스케일 인아웃입니다. 점검걸고 이런거 웬만해선 용납 안하고요, 서비스 상용전 필수 항목중 하나가 5분내에 스케일 아웃이 가능한 구조를 선호(사실상 강제)합니다. 모든 프로토콜은 무제한(되도록) 하위버전 호환을 중요시 하구요. 단일 프로세스 속도가 조금 느려도 상관없어요(라지만 성능 테스트도 엄청 깐깐하게 합니다)
한국에서 최초 서비스 시작할때 퍼포먼스 테스트를 진행하면서 유입 유저수를 예측하고 진행하죠. 모바일의 경우 이를테면 동접 5만 10만 이런식으로요. 이 수치는 사실 매우 잘됐을때 나올 수 있는 수치입니다. 유입량에 한계가 있다는거죠. 잠깐 점검걸고 기기 때려박고 푸는식으로 연명할 수 있습니다. 유저 이탈률은 미미하구요(별다른 장애가 없다는 가정하에).
문제는 중국은 순간적인 유입량/폭팔력이 한국과는 비교가 되지 않는다는겁니다(페북이니 뭐니 이런것들은 폭팔적인 사용자 증가에 대한 우려를 고려할 만한 시기도 지났을 뿐더러, SNS특성상 그 영향력이 게임보단 덜합니다). 마케팅 한번 띄우면 동접 100~200만 그냥 치고 들어오는데, 그 순간 점검걸고 장비 넣고 이럴 수 없는거죠. 서비스는 계속 돌아가는 와중에 장비는 기하급수적으로 늘려가야하는겁니다. 여기서 생각해볼 수 있는건 "아니 그럼 처음부터 기기 이빠이 때려박고 시작하면 되잖아?" 인데, 폭팔력이 어마무시한만큼 이탈률도 정말 상상을 초월합니다. 자... 그럼 다시 장비 뺄때... 수백대의 장비로부터 데이터 마이그레이션을 어떻게 해야할까요? 문제가 여기서 발생하는 겁니다. RDB 스키마를 사용하는 상태에서 로우마다 각기 다른 버전데이터를 가지고 마이그레이션을 수백대의 장비와 함께 진행해야할때, 기존의 우리가 사용하던 방식으로 최소한의 시간만 가지고 진행해야 한다면 어떻게 하시겠습니까. 이게 더 지옥이 되는거죠. 그냥 서비스 접고 싶을지도 모릅니다. 그래서 배대표님이 듣고 말씀해주신거처럼 저런 솔루션이 빛을 볼 수 밖에 없는 시장인거고요. 그래서 처음부터 그들의 리그에서 필요한 모든 경우의 수를 열어놓고 가기 위한 최고의 솔루션이 저렇게 된게 아닐까 생각이 듭니다.
그래서 얘들은 어떻게 처리하느냐... 저장소 앞단엔 당연히 프록시(캐시)가 떠있습니다. 모든 서버 프로세스, 프록시, 저장소 머신은 직접 컨트롤하지 않습니다. SE단 운영툴을 통해 머신 증축/감축 + 프로세스 실행/종료/배포/데이터 리로드 이런것들이 다 자동화 되어있어야 서비스가 가능합니다. 모든 서비스에는 동시접속 제한이 있습니다(서버 장애로 인한 이탈률 방지). 추가된 머신은 LVS(얘들 L4잘 안씁니다)를 통해 즉각 추가 접속 대응이 됩니다. 저장소는 주로 파일을 사용하고, 특이한 경우 MySQL을 별도 저장소로 같이 사용합니다. (풀어서 얘기했지만 이 기능들을 솔루션화 시켜서 자체 DB로 사용합니다)
그냥 기억나는데로 막 끄적인거라 충분한 설명이 되었을런지 모르겠지만, 시장 형태가 이렇다보니 추구하는 기술과 그 기술의 한계점을 끌어내기 위해 생각하는 방법은 다를 수 밖에 없다는걸 말씀드리고 싶었구요, 본인의 프레임 안에서 '이게 곧 정답이오' '그건 틀렸소' 하는 등의 의견은 배제되었으면 좋겠습니다. 뭐 국내서비스만 할꺼라면 사실 무시해도 상관없지만... 중국에서 국내 시장 점령하고 있는 요즘 형세를 아신다면 이런 기술적인 문제들로 괴롭힘 당할날들이 충분히 곧 오겠지 예상하고 계시리라 생각합니다.
마지막으로 제가 쭉 얘기한 내용과 관련된 중국의 회사는 텐센트 얘기입니다.
|
|
5
|
|
|
|
|
|
|
2015-12-15
03:46:25
|
|
MNLT
|
|
|
|
ㄴ 텐센트가 cache로 redis를 권장하는 이유는 딱 한가지입니다. 국내의 모바일 서비스가 대부분 RDBMS(특히 MSSQL)기반으로 서비스 되고 있는게 많은데, 과거 국내 서비스가 텐센트와의 퍼블리싱에서 기존의 구조를 변경하지 않고(로컬라이징 코스트 최소화) 텐센트 서비스 정책에 합당한 대안을 제시하시오 했을때 넷마블에서 밀어붙였던게 redis입니다. 텐센트에서는 자체 개발한 프레임워크를 사용하여 재개발(?) 하길 권했지만 시장이 그것을 기다려줄 여유도 없을 뿐더러 국내 개발자의 큰 반발로 그것이 성사될 이유가 없죠.
그러다보니 선례가 작용한 케이스로 인해 처음에 한번 물어봐주고, 개발사에서 마땅한 대안을 제시못하거나 서비스 경험이 부족한 기술로의 접근이 이루어질때 '예전에 어떤어떤 게임이 redis 썼으니 너네도 이거 써라' 가 되는겁니다. TDR을 진행해보셨다면 아시겠지만, 텐센트가 좀 자체적으로 답을 정해놓고 퀘스쳔을 던지는 스타일입니다(기술 협의만 몇개월 이루어지기도 합니다). 기술적으로 자신들이 이미 우위에 서있다고 당연히 생각하고 있기 때문인것도 있고요. 일이년전 국내 모바일 게임이 중국시장에 와서 맥도 못추고 사라졌기 때문에 최근엔 관심사에서 벗어난 이유도 있습니다.
(그리고 전 하드디스크 섹터 돌아가는 얘기 한적 없어요...)
|
|
5
|
|
|
|
|
|
|
2015-12-15
10:21:22
|
smileeagle
|
|
|
|
** 작성자(또는 관리자)에 의해 삭제된 댓글입니다 **
|
2015-12-15
10:58:06
|
뎐삼
|
|
|
|
MNLT님 글 잘읽었습니다
책으로 쓰시면 살의향이 있을정도로 유익하네요 ㅎㅎ
|
2015-12-15
11:55:41
|
smileeagle
|
|
|
|
간만에 댓글질 좀 했더니만 -ㅅ-; 여기저기서 왜 그러냐고 카톡이.. 제가 했던건 아니지만 요기도 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
|
smileeagle
|
|
|
|
긍께요.. 텐센트 플랫폼팀에 잘하는 사람 많은건 인정하지만 가끔 tlog 라이브러리 업데이트 해서 오는거 보면 멀티쓰레드에서 팍팍 디지고, "멀티쓰레드였어요?" 이러는거 보면 -ㅅ- 솔직히 멀티쓰레드 개발자 많지 않아서 싱글쓰레드 기반으로 막 가는거 아닌가요 기술력 쩐다지만.. 요샌.. 돈으로 많이 바르더만..-ㅅ-
|
2015-12-15
16:23:55
|
|
|
|
|
후끈후끈하네요. 많은 분들이 열띤 토론이 있을거라 예상했는데, 역시나네요. 5년전에 안 것을 이제서야 말씀드린 이유는, 이것이 검증되는 과정이 나오기 전에는 함부로 발설하기가 애매해서였습니다. 원피스 노랜드 선장
대화는 대화이고, 제가 생각하는 바를 말씀드리자면,
1. 바이너리에 때려박느니 그냥 json이나 bson이나 메타데이터 포함 자체포맷으로 저장 후 압축하자. 4KB 용량 맞추기 힘들더라도. 2. 트랜잭션 안 쓴다는 것은 정말 맞음. 국산 게임에서도 트랜잭션 남용하다가 바보되는 경우를 여럿 봐서.
입니다.
결론은, 저희가 만든 게임서버엔진이 중국에서 계정1억 찍은 후에 낼 수 있을 것 같습니다.
|
|
1
|
|
|
|
|
|
|
2015-12-16
10:58:07
|
|
새로운 댓글
