기본 콘텐츠로 건너뛰기

라벨이 TiDB인 게시물 표시

월99만엔 TiDB SES 파견 프로젝트.. 이지만 운영 효율화... 일본IT

영상버전 :  https://youtu.be/F-KO_D694pQ 벌써 3주차가 끝났네요..  하루에 5시간 이상을 이야기하면서 진행하는건 체력을 너무 소모시키는 것 같습니다.  하지만, 기존 멤버들이 경험이 너무 없어서 제가 알려주면서 해야 하다보니 거의 상시 미팅 모드로 이것저것 알려주게 되네요..  새로 들어온 두 명중 한 명은 0.2 MM이니 미팅만 하고 일도 시킬 수 없는 상태이고,  또 다른 한 명은 열심히 마이그레이션 프로젝트를 분석하면서 문서화를 하고 있는 것 같습니다.  정작 신규 멤버 중 실무에 투입가능한 사람이 저 뿐이라  제가 풀 가동 되는 느낌이네요..  그래서 미팅 사이에 작업시간이나 다음 미팅 준비 시간에는 거의 누워서 쉬고 있습니다.  리모트 프로젝트의 메리트랄까요..  눈치 안보고 틈틈히 드러누워 쉴 수 있다는.. ----------------------- 얼마전 고객사와 파견회사와의 중간 평가가 있었고,  그 결과를  제게 공유를 해주더라구요..  내용을 해석하자면..  - 처음 면담시 기대했던 만큼 스페셜리스트로서 기술적인 지식이 너무나 풍부 - 참가 멤버들로부터의 평가도 좋음 - 엄청나게 우수한 분이라서 이후 멤버 쪽에서 따라지 못할까봐 걱정 (불만이라는 뜻은 전혀 아니고 [도와주면 아주 고맙다]라는 늬앙스 입니다. 라고 피드백을 받았다네요..  이제 2주차 보여준건 거의 없는데..  하면서 제자랑도 한 번 해주구요..  ------------------------------------------------------ 아뭏든..  3주차에 했던 것 들 중에는  눈에 띄는 것들이 운영 효율화 입니다.  꽤 오래전 내용 중에  대기업은 Azure를 많이 쓰고 스타트업은 AWS를 많이 쓴다고 하였죠? 한국에선 AWS만 생각하시는 분들이 많아서  이 내용을 모르시는 분들을 위해 다시 한 번 말씀 드리자면,  일본 뿐 아니라 전 세계적으로 대기업은 Azure를,  스타트업은 AWS를 많이 씁니다.  스타트업의 문화를 좋아하

월99만엔 TiDB프로젝트 2주째. 기존 디비의 튜닝

영상버전 :  https://youtu.be/VO7eNgFAGDA 2주 째에 들어왔습니다.  업무시간 8시간 중에 거의 5~6시간은 화상회의를 켜놓고 하게 되네요.  너무 지치는군요..  지난 번 프로젝트가 너무 널럴해서 그랬나봐요..^^;;;  한국과 조금 다른 것은  모두들 발언을 신중히 하기 때문에 말은 많지 않으나,  그 사람들의 말이 정말 이런 이유인지 아니면 다른 원인으로 인한 것인지를 찾는데 신경을 쓰다보니  더 빨리 피곤해지는데요..  지금은 TiDB 잘한다는 사람이 앞단의 교통정리를 헤주고 있으니 잘 하겠죠.  정말 잘할지는 모르겠으나 월권은 귀찮으니.. 하다가 폭탄 만들면 프로젝트를 뜨는 걸로..  SES는 SI와는 달리 프로젝트가 맘에 안들면 언제든 뜰 수 있는게 부담 없어 좋습니다.  리더를 해도 내가 합당한 이유를 우리쪽 영업에게 이야기 하면 빼주거든요..  요즘처럼 사람이 부족한 시기는 고를게 많아서  아무리 비수기라 해도 사람이 부족해 뒤늦게 가격 올려서 구인 하는 경우도 있어요.    첫주엔 27분기 총회가 있어서 참여를…  잊어먹고, 나중에 녹화방송을 봤습니다.  사원은 지금 마구 뽑아서 200명이 되었는데.. 3년 전에 수십억엔 매출이 2년전에 850억, 작년에 1850억엔이었네요..  레드오션이라는 화장품 시장에서 스타트업이 이 정도 수직상승이 가능…하네요..  여기 정사원들은 나중에 스톡 받겠네요…좋겠다…^^;;;  그건 그렇고..  이번주에 기억나는게 두 가지 있었는데요..  하나는 sql server의 리플리케이션이 끊어져 다시 걸어달라는 내용이었습니다.  얘네들은 부하가 너무 커져서 8대의 리플리케이션용 디스트리뷰터 조차 따로 두어서 마스터의 부하를 최소한으로 운영한건 좋었는데.. 마스터의 HA구성으로 대기용 마스터에서 가져오면 될 걸 액티브 마스터에서 가져가는 방식이네요.   레플리카는 보통 5대가 최적이고 그 이상 늘리면 데이터 동기 타이밍에 지연이 생기기 시적합니다. 그렇다고 8대는 안되요가 아니고, 영점 몇 초

월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전

TiDB Migration Project(타이 디비 마이그레이션 프로젝트)

영상 버전 : https://youtu.be/M4RfSiQfVlI TiDB 마이그레이션 프로젝트에 참여 합니다.  아직도 100만엔 넘는 프로젝트가 하루에 수십개 씩 쏟아지고 있습니다.  한국의 SI는 지금 시기가 완전 비수기잖아요.. 사고가 아닌 이상 이 시기에는 좋은 프로젝트는 나오지 않을 겁니다. 연초에 시작된 프로젝트에 다들 들어가서 열심히 달리고 있겠죠..  일본 역시 연말 연초 처럼 프로젝트가 많아지는 무렵이 있긴 하지만,  이렇게 비수기라도 최소한 수십개 정도는 언제나 사람을 찾고 있습니다.  물론 눈높이만 낮추면 수백개도 볼 수 있지만,  기본 월 100만엔 위만 찾느라 이 정도인 거죠..  그렇게 보던 중에  단가는 조금 적지만 DB 마이그레이션 프로젝트가 있어서 한 번 인터뷰를 봤죠.  현재는 SQL Server를 사용하지만,  수 년전에 TiDB이관을 검토했다가 드랍 되었다가  다시 이관을 적극 검토하는 것으로 이야기가 되었다고 합니다.  고객사는 연매출이 2000억엔이 넘어가면서  대규모 유저 처리에 고심을 하고 있다고 합니다.  그런데 연매출 2000억엔이 넘는 홈페이지 수준이… =ㅅ=;;; 이거 한국에선 있을 수 없겠죠? 물론 나름 대규모 처리를 위해 불필요한 거 다 배제하고  최소한의 리소스로 최대 처리를 하고 있을지도 모르겠지만요.. TiDB는 도대체 뭐야? 저도 20여년 DB를 만져왔지만 처음 듣는 DB네요..  공식 홈페이지에서 찾아보니  대규모 OLTP에 특화된 MySQL호환 클라우드 DB라고 하네요..  https://pingcap.co.jp/ 뭐, 기존 RDBMS보다 뛰어나다면 왜 아직도 안알려졌지?  생각보다 문제가 있는거 아냐? 라는 걱정이 드네요.. https://db-engines.com/en/ranking 한국의 자랑인 Tibero도 클라우드화 하면서 알수 없는 속도 저하로 포기했었는데..  티베로도 병목을 막기 위해 브로커라는게 부하를 효율적으로 분산해주어 고성능 처리가 된다고 선전을 했지만, CLoud의 인프라