월99만엔 파견 현장(SES) 신규 프로젝트 참여한 이야기. TiDB Migration

영상버전 : https://youtu.be/OaDuZvE1ViQ

7월 1일부터 참여한 젊은 화장품 판매 기업의 DB이전 프로젝트 입니다. 

연매출 2000억엔에 

오프라인 제휴 매장 포함 26개 라던가요?

사원은 200명.. 

온라인 구치코미를 분석해서 잘팔리는 제품의 순환이 

이 기업의 핵심가치 같네요. 

때문에 가장 중요한 것은 구치코미 데이터인 듯 합니다. 

여기서 

구치 는 입이고 

코미는 코뮤니티의 앞글자 입니다. 

그래서 

사람들의 말을 모아놓은 커뮤니티를 말하는 것이지요. 

우리말로 하면 평점 같은 느낌이려나요?

일본의 구치코미는 한국만큼 오염되진 않아서

돈으로 매수한 것도 좀 있긴 하지만, 

지나치지 않게 하는 것 같습니다. 

때문에 구치코미에 대한 신뢰는 아주 크구요. 

이 프로젝트의 가장 큰 문제는 

회의가 너무 많다! 

그냥 하루에 세 번 미팅은 기본이고, 

전 서너번이 보통인데, 

정사원들은 작업 시간이 하루에 한 두시간이고 

나머진 전부 미팅인 거 같네요.. 

그리고 티켓 시스템이 다섯 종류.. 

각 부서마다 자기네 티켓 시스템을 따로 쓰기 때문에 

레드마인에서 처음보는 시스템까지 골고루 사용 중입니다. 

가장 크리티컬한 것은.. 

SQL 서버를 사용하고 TiDB 이관을 하기로 했는데, 

모든 멤버가 SQL 서버와 TiDB를 잘 모르는 것입니다. 

유저의 급증으로 인해 SQL서버가 자주 뻗는대요.. 

그래서 TiDB로 변경하면 대규모 OLSP랑 OLAP 처리가 가능하다는 영업(?)에 넘어가서 

TiDB TF팀을 결성해서 순차적으로 이동 중이라고 합니다. 

현재 가장 부하가 적은 MySQL의 테이블 두 개를 이동하고, 

조금 용량이 큰 데이터를 이동 중에 성능 이슈가 있어서 해결 중이라고 하네요. 

DBRE팀이라고 하여 DB관련 이슈를 해결하는 팀에 

기존 정사원 2 명중 한 명은 DB를 잘 아는 편은 아니지만 그나마 알고 있고, 

또 한명은 작년에 입사한 신입사원입니다. 

그리고 저 포함 세 명이 외부에서 들어왔는데

한 명은 TiDB전문가라면서 0.2 MM으로 들어왔다는데 별로 실무를 할 거 같지 않고, 

TiDB찬양만 한는데 실제로 엔진 구조를 모르는 듯 하구요, 

또 한 명은 원래 고등학교 선생님이었다가 TiDB좀 배워서 첫 프로젝트 들어온 거 같습니다. 

PC설정하는거 거의 못해서 제가 옆에서 알려줬는데.. 

IT 툴 자체를 처음 쓰는 듯 합니다. 

그리고 저.. 이렇게 5명 체제인데…

첫 날은 PC를 받으로 롯뽕기 1쵸메의 아크힐즈에 갔습니다. 

PC세팅하고 히스토리 설명 듣다가 8시간이 지나가 버렸고, 

아, 점심은 고객사에서 사주어서 2000엔짜리 햄버거 먹었구요.. 

둘 째 날엔 TiDB교육자료를 제게 공유해주어서 그걸 좀 봤습니다. 

미팅은 네 개… 사이사이에 자료 정리.. 

셋째 날은 9시부터 총회였다는데.. 

암것도 모르고 10시에 로긴해보니 이미 시작..;;;

모른척 다음 미팅부터 들어갔는데도 다섯 개.. 

그 담날 5개….

뭐 이런 느낌이에요.. 

미팅 사이사이에 티켓 확인하고 처리하는 건데.. 

전 아직 첫 주다보니 제가 담당하기 보다는 다른 사람들이 담당하면서

제게 물어보면 제가 대답해주는 식이 메인인 거 같습니다. 

그래도 프로젝트 메인은 TiDB라서 좀 설명 드리자면, 

TiDB는 TiDB와 TiKV, TiFlash라는 영역으로 나뉘어

TiKV가 실제로 데이터가 저장되는 곳, 

TiFlash는 redis같은 메모리 캐시 영역, 

그리고 TiDB가 단순 엔진으로 되어 있네요. 

TiKV는 이름 그대로 Key Value 스토어란 이야기 이구요, 

이 이야기는 Hadoop에 HBase를 올리고 SQL on Hadoop을 올린 뒤에 redis를 묶은 느낌입니다. 

이 이야기를 듣고 뭔가 눈치 채신 분이 계시다면 DBA자격이 있습니다.  

RDBMS와 NoSQL은 완전히 다른 시스템이고 

절대 NoSQL에 대규모 OLTP던지지 말라고 그러잖아요?

Twitter나 facebook은 대규모 OLTP던진다구요?

데이터간 연관성이 없는 단순 인서트는 OLTP의 Transaction의 의미에 포함은 되지만, 

우리가 보통 이야기 하는 것은 다양한 insert, update, delete를 포함한 전체적인 데이터 라이프사이클 모두를 이야기 합니다. 단순 인서트는 NoSQL이 구조만 잘 짜놓는다는 전제하에 빠를 수 있지만, 이건 특수한 구조에 한해서 입니다.  

왜 RDBMS가 지금까지 군림하고 NoSQL은 일부 영역은 뺏어먹었지만 메인 데이터는 뺏어먹지 못하는 것일까요? 만약 여기서 우리는 메인데이터도 NoSQL이에요! 라고 하시는 환경에 계시는 분이 있으면 터지기 전에 나오시기 바랍니다. 아니, 트랜잭션 자체가 적다면 터지지 않으니 걱정 안하셔도 되구요..  

이전 콘텐츠에도 이야기 했지만, 

대량의 인서트, 대량의 셀렉트는 NoSQL을 잘 만들면 RDBMS의 성능을 압도적으로 넘어설 수 있습니다. 

하지만, 특수한 상황 이외에는 전반적으로 RDBMS를 이길 수가 없습니다. 

어떤 이야기냐 하면요.. 

이 업체의 데이터베이스는 12개 정도

그리고 각 데이터베이스별 테이블은 60개 정도 됩니다. 

즉, 720개 정도의 테이블에 여러 데이터들이 얽혀있지요. 

매일 돌아가는 배치만 해도 200라인이 넘는 SQL에 

6300만 row를 매핑해서 배치처리 합니다. 

NoSQL은 RDBMS와는 달리 JOIN을 최대한 피해야 한다고 했었죠?

그런데 지금 TiDB전문가라는 작자가 와서는 

그냥 있는 그대로 테이블을 TiDB로 옮기면 된다고 하고 있는 것이지요. 

정말로 NoSQL을 잘 아는 사람이라면 테이블을 통합해서 최소한으로 하고 그걸 어떻게 정합성을 유지할지 등을 고민했어야 하는데 말이죠. 

그냥 그대로 TiDB에 올려진 데이터는 많은 JOIN을 해야 하고, 

JOIN의 개수가 늘어날 수록 성능 저하에 죽어나게 될 겁니다. 

1000만 로우가 넘어가면 RDBMS는 효율적인 튜닝을 하지 않으면 

성능저하가 일어나게 되구요, 

NoSQL은 1000만 정도는 쉽게 처리가 가능하지요.. 

이러면 NoSQL이 좋은거 아닌가요? 

하지만 결정적인 차이는, 

1000만 데이터를 어떻게 연결하느냐에 따라서

RDBMS는 조금 느려도 쓸 수 있지만, 

NoSQL은 수 배에서 수십배 느려지게 되지요. 

물론 RDBMS는 샤딩이나 레플리카의 효율적인 분산으로 커버 됩니다. 

NoSQL은 JOIN을 없애는 select를 만들기 위한 구조를 재설계 해야만 빨라집니다.

이미 세 번째 옮기는 작업에서 

MySQL의 데이터를 AWS Aurora에 던질 때보다 TiDB에 던질 때 서너배 느린데 

그 원인을 찾아달라는 의뢰가 왔습니다. 

물론 TiDB전문가라는 사람의 담당이니 전 구경만 하겠지만요.. 

TiDB 공식 홈페이지의 벤치마크 결과 입니다. 

400쓰레드까지 동지 처리가 가능한데 58000 tpmC 만 처리되고 있습니다. 

AWS SQL Server의 벤치마크를 볼까요? 

170만에서 200만 정도를 처리하고 있죠. 

TiDB공식은 왜 58000까지만 했을까요? 

ORACLE도 200만짜리 벤치마크 자료를 내기도 하고, 

PostgreSQL에서도 50만짜리 벤치마크 자료를 내는데 말이죠. 

즉, TiDB는 tpmC 표준의 부하 처리에는 충분히 따라오기 힘들기 때문일 겁니다. 

음… 너무 들어갔는데요.. 

TiDB에 대한 이야기는 다음 번에 좀더 자세히 손대기로 하구요.. 

그 외에 성능 이슈나 쿼리 체크 등을 DBRE팀에서 하고 있는데, 

이 작업들 마다 전 첫 주이기 때문에 들어가서 구경만 했는데요.. 

두 사람이 너무 버벅거려서, 

쿼리 성능 보는 법과, 

슬로 쿼리 잡는 법, 

그리고 캐시 메모리를 보면서 잘못 만들어진 쿼리들이 캐시 메모리를 덮은 부분을 보여주고, 이들 때문에 성능이 떨어진 거 같다고 이야기를 했지요. 

그리고 Replication도 열심히 마스터의 부하를 줄이기 위해 조정을 했는데, 

오히려 마스터에 부하를 주는 구조라서 그 구조도 변경하는 방법이랑 가볍게 설명해 주었습니다. 

그러면서 보니까 

그냥 이런 부분들 조정만 해도 충분히 SQL Server에서 커버 되는거 아닐까 싶기도 하네요. 

고객사의 정사원 두 명은 제 지적에 완전히 저를 신뢰하게 되었고, 

TiDB전문이라고 해서 들어온 두 명은

잘 하고 있는지 모르겠습니다. 

전 모른척 구경만 하고 있어야지요. ^^

예전에도 결정적인 문제를 지적했다가 

그 프로젝트에서 잘린 적이 있으니까요.. 

여긴 회의는 많지만 

어렵지 않게 월 100만엔은 가져갈 수 있는 프로젝트라 

모나지 않게 살살 맞춰만 줄까 하고 있습니다, 

이미 TiDB 엔진 구조의 문제는 DBRE 팀 멤버에게 교육 시켜줘서 

DBRE팀은 TiDB로 넘어가지 않았으면 하는 바램을 가지고 있긴 하지만.. 

정치란 것은 회사를 위한 방향으로만 움직이지는 않는다는건 

어디가나 똑같은거 같아요.. 

그럼, 이 정도로 이번 주 정리를 하구요.. 

오랜만에 미팅을 많이 해서 너무 피곤하네요.. 

제 현장 이야기가 일본 IT 프로젝트에 도움이 되었길 바랍니다! . 

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