영상버전 : https://youtu.be/mV7uoGQlm5g
이번엔 기술 vlog입니다.
제 기술 관련 이야기를 기다리시다가
쓸데없는 바이크 이야기 같은거 자주 올리니
구독 취소를 하시는 분들이 급증 했네요 ㅠㅡㅠ
사실 처음부터 자기 미래를 설계하는데 도움되는 정보를 찾으시는 분들이
들어오시는 곳이었으니 그렇겠지요..
그래도 일본에서 IT하는 사람이
이렇게 놀기도 하는 구나 하고
일본에서의 취미 생활에 참고도 해주셨으면 합니다. ^^;;;
아뭏든 기다리시던 이야기를 해드릴께요~
7월부터 참가했던 SQL Server를 TIDB로 전환하는 프로젝트가
어느덧 많은 준비를 마치고
최종 PoC를 진행하고 있습니다.
제가 초기에는 TiDB가 더 느릴걸요? 등등의 가벼운 반박 정도를 하면서
어짜피 회사의 70명이 넘는 인원이 이 프로젝트에 연관되어
이전이 결정이 된 상태였습니다.
지난 번 DNP(대일본 출판, 일본 최대의 출판회사) 사건도 있었다보니
사실을 이야기하면 안되겠다 싶어서 그냥
시키는대로만 도와주려고 슬렁슬렁 하고 있었습니다.
그렇게 열심히 WBS도 만들어서 많은 부서에서 체크하고 2차 PoC까지 끝내던 어느날 이었습니다.
PoC결과 표를 보면서 리포트를 작성하는 회의를 했는데,
저도 초대 받아서 참여를 했지요.
1TiDB + 3TiKV에서 2TiDB + 6TiKV까지 4가지 패턴으로 테스트를 한 결과를 바탕으로 스파이크에 대한 이유와 해결 방법 등을 적으려고 TiDB쪽 사람이랑 이야기를 하던 중이었습니다.
2TiDB + 6TiKV만 스파이크가 없고
1TiDB + 3TiKV, 1TiDB + 6TiKV나 2TiDB + 3TiKV가 모두 스파이크가 존재했는데요.
TIDB담당자는 이 이유에 대해서는 그 떄 마침 무거운 쿼리가 들어왔을 거라고 몰아가고 있었습니다.
그런데 테스트 한 사람은 그냥 같은 쿼리를 반복해서 돌렸는데… 라면서 반신반의로 받아들이더라구요..
그도그럴게 그 대답만으로는 고객이 명쾌하게 OK를 내지 못할 거 같더랍니다.
갑자기 PoC결과 회의에서 CTO에게 전제 조건이 맞는지에 대한 문의가 왔다고 제게 연락이 왔네요.
이 때까진 전 SQL Server운영 효율화만 도와주고 있었거든요..
그래서 지금 서비스에서 운영 중인 SQL서버의 상황을 어느정도 파악을 한지라,
이번 PoC결과랑 적용한 데이터를 달라고 했습니다.
PoC결과를 보고 리포트를 봤습니다.
리포트는 2TiDB + 6TiKV가 스파이크가 없으니 이를 채택해야 한다 라는 내용 뿐이었습니다.
그리고 스파이크의 원인에 대해 기재해 달라는 CTO의 질문이 있어서
그걸 이번에 TiDB쪽으로 들어온 사람은
스파이크가 있는 부분이 우연히 무거운 쿼리가 왔다고 이야기를 했네요..
그런데, 쿼리는 40종을 추출 해서 랜덤으로 던진거 거든요..
그러니 테스트를 4번 했는데 세 번이 우연으로 무거운 쿼리가 들어왔다는게
일단 좀 이상하구요..
40종의 쿼리를 초당 2000번 15분간이나 던졌는데,
왜 우연히 세 번이나 마지막에 무거운 쿼리가 몰렸다고 자신있게 말할 수 있는 것일까요?
오히려 전 다른 지표에 주목을 했습니다.
1번을 보면 QPS의 Duration이 점점 늘어나는 것이 확연하게 보였다가 마지막에 튀어 올랐지요.
아마도 쿼리 처리량 보다 쿼리 요청 수가 많아서 chain lock에 의해 점점 지연되다가 마지막에 튀어 오른 것으로 보입니다.
그럼 2, 3은 들쑥날쑥 하잖아요?
2번은 TiDB를 2대로 두 배 늘리고 TiKV를 3그대로 두었을 떄입니다.
Duration이 조금 들쑥날쑥 하지만 그래도 마지막까지 어느 선을 유지하다가 나중에 갑자기 터졌죠..
TiDB로 인해 받아들인 쿼리 수와 나가는 쿼리수는 어느정도 안정을 취했지만,
TiKV 수가 부족하여 저장소 캐시가 바닥을 드러내는 순간 튀어 오른 것으로 판단됩니다.
3번은 처음부터 Duration이 어느 정도 올라갔죠..
아마 1번 테스트로 인한 캐시가 정리 안된 상태라서 처음부터 조금 올라간 상태로 시작한 듯 보이는데,
TiKV가 6으로 설정된 덕분에
마지막에 TiKV의 캐시가 바닥을 드러내기 전에 끝이 나서 어느 정도 높은 부하에서 엄청나게 튀지 않은 것이라 봅니다.
4번은 당연히 TiDB도 충분히 여유가 있어 들어오는 쿼리와 결과의 리턴이 여유가 있던 것이고,
TiKV도 충분히 여유가 있어 IO퍼포먼스가 따라온 덕분이겠지요.
그래서 결론은
이 걸로 테스트 끝이 아니라
TiDB가 1 대 일 때 QPS를 점점 늘려가면서 피크치는 타이밍을 체크하고,
TiKV가 3대일 떄 QPS를 점점 늘려가면서 체크
그리고 TiDB가 2대가 될 때 안정적인 한계 QPS를 테스트하고,
TiKV역시 6대 일 떄 안정적인 한계 QPS를 찾아서
몇 QPS에서 TiDB를 또는 TiKV를 늘리는게 좋은지를 계산하는 공식을 만들어
서비스에 제공해야 하지 않을까요?
퍼포먼스 테스트라는 것은
현재 상태의 퍼포먼스 한계를 측정해서
한계를 벗어나는 포인트를 찾고,
그 한계의 몇 %에 도달 했을 떄에
어떤 노드를 늘려야 하는지를 찾는데에 있다고 보는데,
이번 테스트 결과는 엄청 이쁘게 잘 만들었음에도
이런 내용이 하나도 없어서 CTO도 답답했던게 아닐까요?
저야 토요타를 비롯해서 여러 프로젝트에
퍼포먼스 튜닝 및 인프라 확장 프로젝트를 중심으로 들어가다보니
인프라 확장의 당위성과 예산 편성, 사이징 등을 리포팅 해봤기 때문에
이렇게 대답이 가능했던 것 같습니다.
하지만, 이번 프로젝트에 모인 사람들은
그냥 TiDB측에서 조금 교육해주고 부른 사람들 같더라구요..
그 때문에 TiDB를 왜 적용해야 하는지에 대한 당위성 없이
영업으로만 끌고가다보니
CTO에게는 만족스러운 리포트를 하지 못하는게 아닐까 싶습니다.
지금도 전 SQL서버 그대로 놔두고 TiDB를 버리는 쪽에 손을 들고 있지만,
이미 영업으로 TiDB로 이전이 확정된 상태이다 보니
할 수 없이 따라가 주고는 있는데요..
TiDB를 이딴 식으로 구성해서 운영했다간
SQL서버일 때보다 퍼포먼스가 안나오면서 비용만 비싼
애물단지가 될 수가 있을 거 같네요..
물론 TiDB라는 NoSQL엔진 특성을 잘 알고
설계하고 튜닝한다면 SQL서버보다 좋은 결과를 낼 수도 있지만
현재로선 그렇게 할 수 있는 인재는 없어 보입니다.
제가 몇 번이나 NoSQL의 한계에 대해서 콘텐츠로 설명했었지요?
NoSQL은 특정 영역에서는 RDBMS에서는 넘볼 수 없는 능력을 가졌지만,
일반적인 릴레이셔널 데이터에서는
NoSQL의 한계는 명확합니다.
제대로 설계하지 않으면 RDBMS보다 수십배가 느려지던지
아니면 정합성 체크에 엄청난 개발 코스트를 감당하던지 해야 합니다.
이걸 보신 여러분은
이제 퍼포먼스 분석 방법을 알게 된 것이고
무엇을 테스트해서 무엇을 정리해야 하는지를 알게 되신 겁니다.
그리고 RDBMS와 NoSQL의 특성에 대해서도 조금은 더 깊이 있게 아셨겠지요..
MySQL의 SQL만 사용한다고 RDBMS와 같아질 수 없습니다.
RDBMS란 것은 JOIN이 특화된 작은 데이터의 집합입니다.
NoSQL은 JOIN이 가장 느린 직렬형 대규모 데이터의 집합입니다.
이걸 머릿속에 두시고
들어간 프로젝트에서 안전하게 사용하시길 바랍니다!
댓글
댓글 쓰기