기본 콘텐츠로 건너뛰기

TiDB 프로젝트 4주차… 여전히 잡일 중




요즘 38도까지 올라가는 무더위가 계속 되는데요.. 
지인은 집에 고양이 때문에 온도를 맞춰줘야 한대서 24시간 에어콘을 켜놨는데, 
그 때문에 전기세가 한 달에 4만5천엔이 나왔다고 합니다. 
초등학교 자녀를 둔 다른 지인도 4만엔이 넘게 나왔다고 하네요.. 

제가 사는 집은 키치죠지 근처인데요.. 
운이 좋게 주인 아저씨가 자기네가 살 집을 3층짜리로 만들어 놓고 
1, 2층을 세를 주는 식으로 해서 설비는 최고급인데 집세가 그다지 높지 않습니다.
수익을 목적으로 만든 집이 아닌거 같아요..  
게다가, 
태양광 패널을 세대별로 3KW짜리를 달아줘서 세대 별로 알아서 도쿄 전력에 등록하고 처리하게 해 주었다는 건데요.. 보통 이렇게 지은 집은 주인집에서 전부 팔아서 쓰지 않나요?
세대 별로 각자 관리하게 되어 있어서, 
저희 집은 24시간 에어컨 가동하고 한 달에 6천엔 나오는데다가 
여름에는 5천엔이 전기 판 돈으로 다시 들어오네요.. 

첫 입주에 굉장히 고급형 인버터 에어컨 3기가 설치 되어 있고, 
수납도 많고, 내부 건축 자재도 최고급만 썼다고 주인 아저씨가 자랑하던데.. 
층간 소음 방지용 소음재도 최고급이라고 하고.. 
그런데 2LDK에 14만엔 입니다. 
다른데선 없는 가격이지요.. 

요즘 도쿄에서도 가격이 너무 올라 이 정도 퀄리티보다 못한게 25만엔 하곤 했는데요.. 
언제나 주인 아저씨한테 감사하면서 살고 있습니다. ^^

바이크로 일본 여행하시는 분들 영상을 요즘 많이 보고 있는데요.. 
키치죠지 근처에 오시면 가까운 거리는 안내해 주면서 같이 다녔으면 해요.. 
바이크로 오실 분들은 연락 주세요~ ^^
사사즈카에 1박에 200엔, 대형은 300엔 짜리 바이크 주차장도 있고, 
저렴하게 바이크를 놓고 다닐 수 있는 정보도 알려드리구요.. 
도쿄를 돌아다니실 때 숙박은 사사즈카 근처로 하시면 
신주쿠까지 두 정거장이라 시내 구경도 쉽구요.. 
며칠 묵는다면 바이크 주차 비용을 줄일 수 있을 겁니다. 
아, 사사즈카에는 남자 사우나랑 여성 전용 스파를 경영하는 지인도 있어서 
타이밍만 맞다면 초대권도 드릴 수 있어요. 
남자 사우나는 TV에도 나올 정도로 좋은 곳인가 봐요.. 
제가 갔을 때는 뭔가 작고 그냥 그랬는데.. 
그래도 전철과 고속도로를 조망하면서 온천처럼 즐길 수 있다는 건
매니아 층에게는 유명한가봐요.. 
여성 전용 스파는 멘즈데이가 있어서 남자 전용일에 이용 해 봤는데, 
굉장히 고급스러운 모래 암반 스파인데 서비스랑 인테리어가 훌륭 하더라구요.. 

본론으로 들어가서 … 

벌써 이 프로젝트에 들어온 지 한 달이 되었네요.. 
여전히 잡일을 도와주고 있는데요.. 
그래서 콘텐츠를 만들 만한게 없어요!

그래도 이번 주에 있었던 일을 정리하자면 
이번 주에 역할 분담을 재정비하게 되었는데요.. 
기존 정사원 두 명중에 한 명을 TiDB쪽으로 비중을 빼면서 
신입 2년차인 사람의 보조를 제가 하기로 했습니다. 

요즘은 거의 PMO로만 들어가다 보니 
이렇게 정사원 보조를 많이 하는 편이고, 
그게 전 편하고 좋더라구요.. 

경력을 쌓고 싶어하시는 분들이야 큰 프로젝트에 들어가고 싶어하시겠지만, 
전 여기서 더 경력을 적는 것도 귀찮고.. 
이 대로 제 경험으로 남을 도와주는게 편하니까 이런 프로젝트가 더 맞는거 같더라구요.. 

그래서 이번 주에는 좀더 자동화에 힘을 썼답니다. 
이번에 한 작업은.. 

SQL서버에서 만들어진 어카운트를 다른 서버에 복사하고 권한을 조정하기도 하고, 
그렇게 만든 어카운트를 필요할 떄 삭제하는 스크립트 입니다. 

아직 만드는 중이라서 전부 분해해서 잘게 쪼갰는데요.. 
나중에는 하나의 시트에서 다 관리 가능하게 해야겠지요.. 

일단 설명을 드릴께요.. 
엑셀에 소스 서버와 타겟 서버를 지정하면
소스 서버에 가서 게정 추가 SQL을 생성해서 파일에 저장합니다. 
이 때 생성문에 password가 있는데 이걸 암호화 해서 출력해 주더라구요.. 
이대로 다른 서버에 계정을 생성하면 
나는 패스워드를 모르지만, 
이 계정 주인은 새로운 서버에서도 같은 계정에 패스워드로 로그인이 가능하게 되는 거지요. 

이 기능에 대해서는 MS의 공식 문서에 있는 어카운트 복제 SP를 개량해서 만들었는데요.. 
이렇게 하면 개발 서버에서 테스트가 끝난 운영자 어카운트를 그대로 본 서버에 가져올 수 있다는게 장점인 거 같아요.. 
이건 고객이 신규 생성보다 복사 안건이 많다고 해서 만들어준 것이구요.. 
삭제는 지난 주에 만든 삭제 스크립트를 쓰면 됩니다. 

사실 MS의 내용도 내용이지만, 
이 스크립트의 대부분을 chatgpt에게 도움을 받았습니다. 
Chatgpt가 sql서버 접속 스크립트를 만들면 ssl인증 에러가 무조건 나오는데요, 
그 에러 메시지를 다시 첨부해서 이런 에러가 나와 라고 하면 
알아서 그 에러가 안나도록 수정을 해준답니다. 

그리고 내가 하고 싶은 흐름을 정확히 적을 수록 
정확하게 파일을 만들어 주니까 
많이 연습하면 거의 모든것을 해주는 것 같습니다. 

게다가 AIEXE라는 툴이 있는데 
이걸 활용한다면 
스크립트를 짤 게 아니라면 
그냥 내 피씨에서 모든 작업을 할 수 있을 거 같네요. 
작업 베이스로 AIEXE를 활용한 매뉴얼을 만들것인지, 
툴화를 시켜서 모두에게 공유할 지에 따라서 선택하면 좋을 것 같습니다. 
AIEXE를 아주 잘 사용하신 분의 유큐브 링크는 상세에 올려 놓겠습니다. 

어케어케 만들다보니 이전에 어카운트 생성과는 항목이 달라서 엑셀을 두 개를 쓰게 되었지만, 
이걸 통합하려면 통합도 될 거 같아서 머릿속에 고민을 하고 있어요.. 
물론 금방 만들지만, 

너무 빡시게 하면 안될 거 같아 다음주에 하는걸로… 
미팅은 여전히 많지만, 
미팅 시간에 미팅 켜놓으면서 작업하다보니 
두 배 이상의 효율이 나기 때문에
미팅 외의 시간에는 놀 수 있는 거 같습니다. 

그래도 미팅이 10시 11시반, 13시, 15시 등등 
하루에 4~5개가 애매하게 걸쳐 있어서 장시간 비울 수 없다는건 귀찮긴 합니다. 
그래도 재택이라는 매리트가 이럴때 더욱 빛나는 것이 

파견이라면 그 사이사이 시간에는 자리에 앉아서 뭐라도 했어야 했지만, 
리모트다 보니 미팅 들으면서 작업하고, 
사이사이 시간엔 침대에서 뒹굴 거려도 되니까 좋네요.. 
이젠 현장 파견은 못할 거 같아요.. 

그리고 튜닝 관련으로도 몇 개 들어와서 처리를 해주었는데요.. 
생각해보면 이 고객은 정말 저렴하게 절 쓰고 있는게.. 

보통 SI업체를 통해서 고급 튜닝 들어가면 2주에 1000만엔 정도거든요.. 
제가 엔코아에서 배운 튜닝 기법이다 보니 
저 가격에 들어가는 튜닝이랑 같은 레벨의 튜닝을 해주고 있어요.. 

개발자들과 dbre팀에서 고민고민 해서 만든 최적이라는 sql이 57초 걸렸는데.. 
데이터의 증가에 따라 이젠 9분 정도 걸린다고 합니다. 
이걸 제가 튜닝 해서 0.5초에 나왔거든요.. 

이번 주에도 쿼리 튜닝이 두 건 있었는데.. 
이 역시 쿼리를 완전 분해해서 최적화 시키고, 
모든 케이스를 시간 분석해서 가장 최적이 되는 쿼리를 이렇게 했습니다. 
하고 말해줬더니, 
전혀 달라 보이는 세 종류의 쿼리가 동일 결과가 나온다는 사실에 놀라 하더라구요.. 
그래서 
AND랑 OR가지고 논리식 만드는 수학도 동일 결과를 내는 다른 논리식을 만들 수 있잖아요?
그것과 같은 식으로 만드는 겁니다.
그렇게 했을 때 RDBMS의 엔진 구조상 어떤 RDBMS에서는 full scan을 어떤 RDBMS는 index scan후 hash match를 쓸지가 달라진다고, 그래서 현재 사용중인 RDBMS가 어느 타이밍에 인덱스를 다르게 탈지는 하나하나 던져가면서 체크해야 된다고 했죠. 
어떤건 index가 있음에도 불구하고 전체 행수가 상대적으로 적어서 결과가 1/10을 넘어가버리면 
full scan이 효율이 난다고 판단해서 억지로 full scan으로 가는 경우가 있거든요.. 

그렇게 얘길 했더니 
갑자기 어수선 해지더라구요.. 뭔가 지금까지 경험하지 못했던 세상을 보는 듯한 분위기랄까..
DB담당자가 갑자기 제게 무슨 책을 보면 저 정도까지 할 수 있냐고 해서.. 
책은 기본을 알려주고 나머진 계속 경험할 수 밖에 없지만, 
그래도 제가 가장 영향을 받았던 책이 마침 일본어로 나와 있는걸 알아서 그걸 안내해 주었죠.. 

아마 DB를 전공하고자 하시는 분들은 필수로 거치게 되는
엔코아 이화식 씨의 대용량 데이터베이스 솔루션 이란 책인데요.. 
사실 책이 어렵기도 하지만, 
그 속에는 하드웨어적으로 메모리가 부족할 때, CPU가 부족할 때에 따른 튜닝 방법도 다르다는 내용까지 들어 있는지는 잘 모르겠어요.. 
제가 배울 때에는 하드웨어의 한계까지 튜닝하는 방법을 배웠거든요.. 

예를 들어 메모리가 적다면 
쿼리를 전부 합쳐서 하지 말고 최소한으로 데이터를 끌어서 연산하게 한다거나.. 
일단 from 뒤에서 인라인 뷰를 만들면 만들어진 뷰는 인덱스를 안타기 때문에 CPU부하가 있지만, 
메모리가 부족한 상황이라면 이렇게라도 해서 메모리를 줄이고 CPU에 의존을 해야 하거든요.. 

한국같으면 돈도 많은데 스펙을 올리라고 하잖아요?
하지만, 일본의 프로젝트를 보면 주어진 인스턴스의 한계까지 쓰려는 노력을 참 많이 볼 수가 있습니다.
때문에 튜닝 방식도 일본은 리소스의 한계까지 쓰는 방법을  알려주면 아주 좋아하더라구요.. 

이렇게 튜닝도 하면서 튜닝 순서를 문서로 남기고 교육까지 해주는걸 현재 하고 있습니다. 
이런 교육 프로그램은 엔코아에서도 한 기당 800만원 넘는 교육비를 내는건데… 
뭐, 고객이 일반 dba금액보다 높은 금액으로 절 불렀을테니 
이 정도 해주면 좋아하지 않을까요? 

이렇게 4주차도 스고이 연발을 들어가면서 흐뭇하게 종료하게 되었습니다. 

제가 거기에서 이런 얘기도 했지요.. 
전세계에서 가장 인지도가 높은 RDBMS가 오라클이잖아요?
오라클에서 정식 튜닝 지침으로 선정한 것이 엔코아의 이화식씨의 튜닝 기법이구요, 
전세계 오라클 컨퍼런스에서 한국 오라클에서도 사람을 초청해서 가지만, 
한국 오라클과 별개로 이화식씨는 초청되어 가는 사람이라구요.. 

이렇게 말하면
한국인에 대한 기대가 너무 높아질 거 같긴 하지만, 
그래도 뭔가 자부심이 생기지 않나요?
뭐, 그러다가 노력 안하는 한국 분들이 다시 떨굴 지도 모르겠지만 말입니다..

다들 열심히 하셔서 
한국인은 원래 뛰어나를 
각인 시켰으면 합니다. 


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을 걸지 않으면 NoSQL처럼 느려터져 죽습니다.  양이 많은 DB에서 양이 적은 테이블을 가져와서 JOIN을 해야겠지요..  이렇게 해서 동접 10만명까지 커버를 했다 칩시다.  여기서 일반적인 동접의 기준도 서비스마

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 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만