기본 콘텐츠로 건너뛰기

재밌는 DB 스페셜리스트가 되어보지 않겠어요?

재밌는 DB 스페셜리스트가 되어보지 않겠어요? 

이번에는 제 자랑 이야기가 메인이니 재미 없으신 분들은 피해주셔도 됩니다. ^^;;

제 삼자의 입장에서 한국을 보면, 
누가 뭔가로 돈을 벌었다 하는 소문이 나면 전 국민이 그거 밖에 없는 듯이 움직이는 모습을 보면 
가끔은 웃음이 나와요.. 레밍스 보는 느낌이랄까.. 




전국민의 개발자화 하려는 나라는 한국 밖에 없지 않을까요? 

지금이야 수요가 있으니까 대우를 받는다 해도, 
충분한 공급이 나오면 개발자들은 헐값에 넘어가잖아요.. 

예전에 일본에 IT인력을 넘길 때도 마찬가지 였거든요.. 




한국에서 자바 개발자가 최고라느니 하는 이상한 소문이 나서 
모두 자바 개발을 시키니까 포화상태가 되버려, 
국가가 나서서 그걸 풀려고 일본으로 대거 보냈지요. 
그러다가 일본에서 경험 부족한 한국인이 대거 오면서 품질이 안좋아져 한국인 금지를 내린 기업들이 늘었고.. 
그 때문에 다시 한국으로 돌아간 자바 개발자들이 떨이가 된 적이 있었죠.. 

뭐랄까.. 다양성이 없다고나 할까.. 

일본에선 아직도 코볼로 먹고 사시는 분도 계시구요.. 일본 디지털 방송 시스템 내에서도 광고 송출 스크립트는 시퀄셜 처리이기 때문에 아직도 코볼을 쓰는데 효율적이거든요.. 

전 지금도 classic asp로 제가 필요한거 그때그때 만들어서 제공하는데 아무 문제 없거든요.. 
Skynet을 classic asp로 짜고 있습니다! 요건 나중나중에... 

한국에선 자바가 붐 이었을 때 전 세계가 자바밖에 없는 줄 아시는 분도 계셨는데.. 
이 때 제가 W3Tech라고 하는 전 세계 1000만 상용 웹 사이트의 서버 사이드 개발 언어 통계를 보여드린 적이 있지요. 그 때는 php가 90%가 넘었는데 지금은 그래도 많이 줄었네요.. 


전제를 어디에 두느냐에 따라 Python이 1등일 수도 있고 Java가 1등일 수도 있으니 그런거에 휘둘리지 않기 바랍니다.

아뭏든 주변에서 이거 안하면 죽는다는 듯이 말을 하더라도 자기가 좋아하는 것을 일관해서 장인이 되는 분들이 많이 나왔으면 좋겠습니다. 
사실 이렇게 분위기에 휩쓸리지 않는 분들 중에 세계적인 장인들이 한국에서 꽤 나오고 계시거든요.. 




전세계 오라클 튜닝의 교과서를 만드신 엔코아의 이화식 대표님이라던가.. 
저도 그쪽 라인에서 DB튜닝 기법을 배워서 지금도 대기업이나 대규모 시스템의 퍼포먼스 분석 및 튜닝을 할 수 있는 힘을 가진 계기가 되었습니다. 
현재 일본에서도 아직 누군가 최적화 한걸 더 빠르게 튜닝을 해준 적이 많으나 제 튜닝을 더 빠르게 하신 분은 못봤거든요.. 참고로 전 DBMS가리지 않습니다. MySQL에서 오라클, NoSQL까지 튜닝이 필요하시면 말씀하셔요.. 

예전에 한국에 있었을 때 지인이 누가 저를 보고 싶다고 해서 만나러 카페에 갔는데요.. 
모르는 분이 계셔서 명함을 주고 받았습니다. 
명함을 보니 낮익은 브랜드였는데요.. 




디씨 인사이드의 김유식 대표님이셨더라구요.. 
제가 명함을 드리자 갑자기 저를 아시듯이 말씀을 하시더라구요.. 

과거에 시스템에 장애가 생겼을 때 장애 해결을 계속 못하고 있었는데.. 
그 때 누군가 넥슨 출신의 신 모씨를 찾으면 된다고 연락처를 주었는데 
때마침 연락이 안되서 아쉽게 지나간 적이 있다고 하셨더라구요.. 

제가 여기저기서 장애난 서비스 많이 살려드린 적이 있긴 하지만, 
이렇게 알아주시는 분이 계시니 기분이 왠지 좋네요.. 

하지만 전 너무 유리 멘탈이라서 
절 막 압박을 주면서 이용을 하는 분들이 계시면 핸드폰을 해지하고 잠수를 잘 탑니다. 
그러다보니 핸드폰 번호 하나로 오래 가지 않아서 이렇게 연락이 끊기곤 한답니다. 
대부분 한 쪽으로 특출난 사람들은 다른 한 쪽이 비 정상적으로 안좋잖아요? 전 멘탈쪽이었습니다.


이세돌 사태도 있었죠.. 




갑자기 온국민이 바둑 열품이 들었을 때, 
어디서 갑자기 모르는 전화가 왔습니다. 
이세돌 때문에 자기네 바둑 서비스가 뻗었다고.. 

aws에 vm으로 올린 서비스 였는데, 
그 동안은 2~3000명 정도 유저로 잘 돌아갔는데.. 
3000명만 넘으면 뻗는데 리부팅을 해도 금방 차버리고 해서 일 주일째 해결을 못하니까 
여기저기 수소문을 하던 중에 누군가 제 연락처를 줬다는 군요.. 
이 분은 운이 좋아 제가 바로 찾아가서 상태를 보자마자 진단을 드리고 해결을 해 드렸습니다. 
유저가 3000명 전후에서 서버가 뻗으면 거의 DB병목 아니면 IO병목이거든요.. 
딱 보니까 디스크의 IO병목이었습니다. 
Disk 가 160IOPS를 넘기지 못하고 있었습니다. 
이세돌 때라면 꽤 오래 되었기 때문에 그 때의 AWS는 VM스펙당 IOPS를 충분히 주지 못해서 
평균이 80IOPS였거든요.. 
그래서 원인 말했더니 바로 AWS에 전화해서 4000IOPS까지 올려 바로 해결을 했습니다. 

대부분 간단한 거라도 원인을 못찾아 해결을 못하는게 문제지요.. 

이 얘길 하다보니 또 있었는데요.. 
지인이 들어간 회사의 게임 서비스를 오픈했는데 유저가 100명이 들어오면 웹 서버가 뻗어서 게임에 로그인이 안된다고 연락이 왔습니다. 밤 6시 즈음 이었는데.. 




제가 달려가서 상태를 보니 공지 게시판에 금칙어 계산을 하려는데 각 라인 별로 금칙어를 루프 돌려서 DB를 콜 하고 있었습니다. 
그렇게 되니 한 페이지 로딩할 때 144번 DB를 부르고 있었는데요.. 
이게 무슨 이야기냐 하면.. 
페이지를 한 번 호출 할 때 DB를 1 번 호출한다면 대부분 동시 접속자 4000명까진 MySQL에서 받아줄 수 있습니다. 그런데 144번 부르면 1/144 의 유저밖에 못받게 되지요.. 
DBMS와의 접속시 쿼리보다 handshaking이 가장 DB에 시간을 많이 뺏는 건데 완전히 간과하고 만들었더라구요.. 쿼리가 0.01초 보다 느리다구요? 쿼리 다시 짜십시요! 뭐, 아닌 경우도 있지만;;;
암튼, 그래서 이거 고치시면 되요 하고 개발자에게 얘기했더니,
갑자기 개발자가 자긴 대형 공공 프로젝트에서 15년이나 일했는데 이런 일이 일어난 적 없다고 시스템 잘못이라고 방방 뛰더라구요.. 그러니까 공공 기관은 하루에 150명도 안들어오는데 수십억 들여서 시스템 만드는 곳이고, 게임 서비스는 최소한의 비용으로 수천명은 받는거라니까 공공기관 비용이 비싸다고 그걸 크다고 생각하시는 분들이 계시는데.. 말을 너무 안들어서 비키라고 하고 제가 바로 그자리에서 수정해서 바로 서버 오픈을 시켰습니다. 
그러자 그 회사 대표님이 너무 화가 나셔서 그 분을 바로 해고 했더라구요.. 

뭐 이거 뿐이겠어요? 
일본에 어떤 MMORPG게임을 런칭했는데.. 
유저가 플레이중 아이템이 떨어지면 클릭하는데 3초 걸려서 게임이 안된다는 불만이 쏟아지는데 개발사도 원인을 계속 못 찾고 있어서 운영회사 대표님이 저에게 찾아달라고 부탁을 하셔서 찾아 드린 적이 있습니다. 
한국에서도 어느정도 매출이 나서 나름 괜찮았지만, 
일본 서비스는 한국에서의 약 10배의 액션이 난무하더라구요.. 
보통 게임로그는 세세하게 남겨야 해서 파일로 남기는데 여긴 DB에 때려 넣고 있었는데.. 
나름 최적화를 한다고 로그 디비도 분리하고 고스펙으로 돌렸지만 느리더라구요.. 
그래서 분석해서 결과를 알려주었습니다. 

DB의 로그테이블의 PK를 날짜 역순으로 잡으셨는데요.. 이거 Serial을 추가하고 그 시리얼을 PK ASC로 잡으시면 됩니다. 

라고 말해서 끝난 줄 알았는데 개발회사 CTO분이 제게 전화를 하셨더라구요.. 
그래서 자세히 왜 그런지 설명을 드렸죠.. 
PK는 물리적 소팅을 하기 때문에 날짜 역순으로 잡게 되면 로우수가 많아지면 모든 로우를 쉬프팅 해야 하므로 전 데이터를 물리적으로 읽은 다음 소팅 해야해서 IO부하가 엄청나 집니다. 게다가 PK는 바이트가 적은게 좋기 때문에 datetime보다는 incremental로 잡으셔야 부하가 경감 됩니다. 

CTO분은 어느정도 이해하신 듯이 전화를 종료 했는데요.. 
다음날 또 모르는 한국 전화가 와서 받았더니.. 
갑자기 어떤 여자분이 다짜고짜 
자기가 이 서비스를 3년이나 DB튜닝하고 최적화 했는데 갑자기 뭘 안다고 난리냐.. 고 대뜸 소리를 지르네요.. 
그래서 당신이 누군지 모르겠지만 전 퍼포먼스 분석 결과만 드린 것이니 자세한 얘기는 여기 대표님과 하시죠. 하고 넘겨 드렸습니다. 한참후 그 쪽 CTO님이 좀더 알기 쉽게 설명 해 줄 수 있냐고 해서 
그 데이터 그대로 예비기에 덤프 후에 같은 insert처리를 시키고 profiling한 결과를 보여줬습니다. 
제가 PK설정한 테이블은 물리 소팅이 없어 단순 append로 한줄 넣고 끝나지만, 
기존 테이블은 모든 키를 읽고 데이터를 넣은 뒤에 물리소팅 하고 다시 라이팅을 하고 있는걸 보여줬습니다. 
그렇게 보여주자 마자 모든게 종료.. 된 줄 알았는데.. 
뭔 문제인지 일본 서비스를 종료 해버렸네요.. 
아마도 그 쪽 DBA가 배를 쨴 거 같습니다. 

이렇게 콧대만 세고 실력없는 엔지니어라고 해도 한국에서는 잘 살 수 있는거 같더라구요.. 
뭐.. 유저 규모가 다르고 데이터량이 다르니.. 

아니.. 일본에서도 재밌는 일이 있었습니다. 
일본의 대규모 게임 DB를 이관해서 5년간 20억원 정도 줄여준 적이 있는데요.. 
여기의 도쿄 본사 CTO가 MongoDB가 RDBMS를 대처할 수 있으니 앞으로 만드는 모든 게임은 MongoDB를 쓰라고 하더라구요.. 
혹시 이렇게 믿고 계신 분들은 MongoDB와 RDBMS의 엔진 구조를 다시 공부하고 오시기 바랍니다. 
전 Hadoop에 HBase올린 1.76PB짜리 시스템도 설계하고 구축 운영을 했는데요.. 
NoSQL은 기존 파일 시스템과 로직이 같습니다. 
때문에 JOIN을 하게 되면 미치도록 느립니다. 
Data Relation이무지 약하단 이야기 입니다. 그리고 대부분의 데이터는 릴레이션을 가지고 있지요. 
처음부터 비정규화를 정교하게 설계하지 않는한 RDBMS를 이길 수 없구요, 
정교하게 설계 한다 하더라도 업데이트는 칠 수 없다 생각하셔야 합니다. 
이건 고 부하시에 업데이트 쳐보시고 나서 제게 말씀 해 주시면 됩니다. 

RDBMS도 똑같이 파일아니냐 하고 말씀 하시는 분들이 계시다면 모든 RDBMS엔진 만드시는 분들꼐 사과하십시요. RDBMS가 괜히 비싼게 아닙니다. 아무리 저라도 이런 엔진 알고리즘 만들라면 못만듭니다. 음.. 만들 수 있... 나?

그런데 어떻게 NoSQL이 뜬거냐구요? 
로그는 Relation 필요 없잖아요? NoSQL은 단어의 counting이 RDBMS보다 비약적으로 빠릅니다. 즉 검색은 훨씬 나을 수 있다는 얘기지요. 그런데 검색엔진 서비스가 아닌 이상 데이터와의 상관관계가 중요한 서비스가 많지요.. 
그리고 머신러닝 같은거 할 때 한번에 수십 테라씩 읽어서 돌리는 경우가 많습니다. 
이런 경우는 무거운 RDBMS엔진 위에서 올리면 속도도 안나는데다가 그 만큼의 용량이면 라이선스 비용이 엄청 납니다. 그러니까 데이터 타입에 따라서 가성비 좋게 구축하기 위해서는 RDBMS와 NoSQL을 적절히 구성하는게 좋습니다. 혹시 cassandra는 컬럼형이니까 RDBMS로 좋지 않느냐? 라던지 깊이 있게 태클 거실 분들은 제게 직접 걸어주시죠. 모두 논리적으로 커트해 드리겠습니다. 전 RDBMS신봉자도 아니고 모든 데이터는 적절한 장소에 보관하고 효율적으로 쓰기를 바라는 사람입니다. 

하지만 동접 3000명 도 경험해 보지 못한 CTO라면 그럴 수도 있지요.. 
저 성능에서는 그냥 파일DB를 쓰든 Excel을 ODBC로 연결해서 쓰든 전혀 상관 없거든요.. 
하지만 그런 환경에서 10년 이상 해왔다고 해서 과신하는건.. 위험합니다. 

너무 잘난척 하는 제가 밉죠? 

그래도 하나 더 말씀 드릴께요.. 
일본 본사가 된 온라인 게임회사인 N모사에 DBA로 들어갔을 때,
들어간 첫날 원래 인프라 전부 담당하던 전임 디비 담당자가 운영팀이랑 통화하는 내용을 들었습니다. 
이벤트 결과는 양이 너무 많아서 3일 이상 검색 못해요.. 
응? 뭔소리야.. 이벤트를 3일 밖에 검색 못하다니??
구조를 뜯어보니 여러 게임 DB에서 데이터를 가져와서 콜라보 이벤트 결과를 추출하느라 시간이 오래걸려 타임아웃이 나고 있더라구요.. 
참고로 여긴 DBMS가 MySQL, SQL Server 두 종류로 64대 정도가 하루 300만명이 과금을 하고 순간 60만 클릭이 집중하기도 하면서 서로 엮여서 서비스 되고 있는 대규모 부하가 늘상 집중하는 곳입니다. 
이걸 실시간으로 보고 싶은 이벤트 통계는 R-OLAP으로, 과거 데이터는 M-OLAP화 해서 볼 수 있는 페이지를 만들어 주고 얘기했지요.. 
이제부턴 창립 이래 모든 데이터를 실시간으로 검색하시면 됩니다. 

얘기하다보니 끝도 없어지네요.. 

다른 재미난 이야기는 또 틈틈히 해보겠습니다. 

여러분! DB 스페셜리스트가 되면 정말 재밌습니다! 지망생 분들은 연락주셔요!



giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...