오픈소스 디비로 행원이 되어보다.
은행에 오픈소스 디비 일을 하며 겪은 쫄깃한 자랑질을 늘어놔보자
국내 두 번째 인터넷은행,
그러나 "첫 번째 x86 리눅스" 및 국내 "오픈소스 DBMS도입" 첫 사례. 게다가 단순히 들러리라기 보다는.. 은행 거래에 굉장히 중요한 분야에, 탄력있게 언제든지 "트래픽을 분산할 수 있는 구조"로 "절대 장애"가 없는 아키텍쳐(?)로 시작해볼까?
(물론 얘긴 먼 훗날 다시..ㅋ)
사실 나는 지금도 실험을 하고 있다.
오픈소스가 가져다주는 가장 현실적인 가치는..?
"비용"이라고 일단 나는 생각한다. 물론 모든 이들이 동조하는 것은 아니지만..
그렇지만.. 오픈소스 DBA로써 금융업을 막 일년 넘겨가는 입장에서.. 과거를 회기하며 우리가 나름(?) 기여했던 몇 가지 사례에 대해서는 반드시 자랑질을 해보고 싶었다. 그래서 몇가지만 얘기해본다.
오픈소스와 함께 했다
그렇다. 국내 1인 기업인 웹 기반의 오픈소스 DB 협업 툴인 테드폴(일명 올챙이)를 전격 도입 했다. 게다가 레거시 접근제어 솔루션을 서버to서버로 품어보았다. 온갖 이슈를 경험하면서 오라클 클라 핸드쉐이크 시 패킷 분석도 미친듯이 해봤다. 11G만 엄청난 특이점이 있더군.. ㅋㅋ
사용자는 데이터베이스에 있는 의미있는 글귀를 조회하기 위해 더이상 CS프로그램을 설치하지 않아도 된다. 그냥 웹 브라우저에 접속하여 인증을 받고 바로 디비로 쿼리를 날리면 된다. "엄격한" 인증 이후 모든 접근제어는 "백그라운드"에서 이루어진다.
물론 아직 갈 길은 멀다. 버그도 늘 발생하고, 익숙치 않기에 불편하다는 불만도 듣기도 하고. 그렇지만 이전부터 오픈소스 기업과 동반성장을 기대해왔던 입장에서 쾌거이다. 무엇보다 오랫동안 함께 할 수 있는 나이 많으신 벗(?ㅋㅋ)을 얻은 느낌 ㅋㅋ
잘한 일 일지, 의미없는 일일지는 훗날 평가를 받겠지만, 적어도 새로운 시도이고 레퍼런스이며 분명 어떤 의미에서는 좋은 의미의 트리거라 확신한다.
솔루션 연동? 그냥 만들었다.
모든 것은 솔루션이었다. 돈없는 가난한 회사에서 대부분 만들어 쓰는 환경에 익숙한 나로써는 낯설고 아쉬움이 많았다.
무엇보다 솔루션이 기능을 제공하지 않으면 아무것도 할 수 없는 현실이다. 그런데 어쩌나.. 오픈소스를 그것도 데이터베이스를 도입한 사례는 전무한데.. 게다가 꽤나 대용량 트래픽을 미리 대비하고자 마련한 샤딩 구조는 특히나..
솔루션이 샤드 혹은 데이터 복제 환경에 맞는 기능을 제공 못하겠단다. 수동으로 관리하란다. 몇달간 이런 이슈로 꽤나 논쟁아닌 논쟁을 했었다. 얻은 것이 없고 진척도 없었다.
그래서 만들었다.
짜증도 나고, 이런 의미없는 논쟁에 소요되는 시간이 아까워서.. 딱 내게 필요한 기능만 생각해서.
그리고 잘 쓰고 있다. 만들기 전 버그/이슈/불일치 등으로 인한 문제 상황이 사라졌다.
그래서 이제 다시 디비일을 할 수 있다 ㅋㅋ
(뭥미)
언젠가 이런 내용을 최소화해서 오픈할 시기가 올 것이다. 오픈 지식으로 영감을 얻은만큼 이 산출물은 역으로 다시 기여해서 다른 누군가의 잉여력을 이끌어내야한다!
필요했다. 그래서 그냥 고쳐버렸다.
소소한 버그 픽스이기는 하다만, 일단 이상한 부분은 알던 고쳤고, 정식 버전으로 배포하라고 협박(?) 아닌 공손함으로 요청했다.(2년에 걸쳐서..)
아래 참고
http://gywn.net/2016/09/pt-online-schema-change-pk-change-problem/
어찌됐건 스키마 변경 시 리스크 요소는 해결해내었다. 예전 K사 시절 ADT 프로토타입을 만들면서 고민을 했던 데이터 처리가 솔루션 도출에 굉장한 도움이 되었다.
https://github.com/gywndi/percona-toolkit/commit/7c3c5c9a8e7bdc9fadf047757182f44d6aef4f53
일단 질러보았다.
심장이 쫄깃쫄깃했다. 서비스 어딘가에 MySQL5.7에 New Feature로 도입이 되는 n-gram 전문 검색 엔진을 사용해본다.
n-gram? ㅋㅋ 짧은 브런치에 무엇인지를 설명하기에는 난해하다.
그렇지만 단순하게 설명해보자면, MeCab처럼 스페이스 기준으로 단어가 파싱되는 전문검색은 CJK(차이니즈, 제페니즈, 코리언 - 왜 한국말이 젤 마지막인겨. -_-)에는 적합하지 않다. 최소 글자 수(기본2글자)로 토크나이징하여 인덱싱 관리를 하고, 검색어가 들어오면 이 인덱스를 활용하여 문서를 찾아낸다.
http://gywn.net/2017/04/mysql_57-ngram-ft-se/
데이터 사이즈가 크지도 않고, 성능에 직접적이지 않은 부분에 일단 사용을 가이드 해보았다.
시작은 이랬지만..
젝슨길. 생각보다 꽤나 큰 테이블에 도전하게 되어부렸다. 200만건 정도.. 기존 성능이 만족스럽지 않아서 ngram 알고리즘으로 로직이 이사옴.
사실. 바로 전 K사에서 mroonga(groonga)풀텍을 쓰며 꽤 많은 인상을 받았고, 적당한 데이터 사이즈에선 단순하지만 강력하다 생각을 했었다만..
늘 걸리는 것이 백업/복구. 스냅샷을 안쓰는
이상 이슈가 있었다. 그런데 ngram이 InnoDB로 들어오면서 일단 질러보았다. (간단한 레퍼런스삼아)
근데 일이 커져부렸네그랴.
지금 생각하면 무슨 부귀 영화를 누리려고 뭔 배짱으로 그랬는지 모르겠다. 몇달간 버그로 쫄깃한 심장에 지옥을 오갔다.
http://gywn.net/2017/06/mysql_57-ngram-ft-bug-and-learn/
일단 써보고 좋은 레퍼런스로 나온다면.. 뭐.. 좋겠지?!.. 좋은게 좋은것이니.. 아마..도.. 쿨럭
제대로 징징대다
욕심 같아서는 다 해보고 싶지만.. 사실 크리티컬한 버그 경우에는 핫픽스가 굉장히 중요하다.
금융 첫 사례라.. 왜이리도 크래시 버그가 많이 보이는지. 몇달간 10년은 더 늙은 듯.
https://bugs.launchpad.net/mysql-server/+bug/1660591
https://bugs.launchpad.net/percona-server/+bug/1679025
https://bugs.launchpad.net/percona-server/+bug/1657941
오픈된 소스이고, 그만큼 버그도 많다.
(위에껀 크래시 버그~~)
그렇지만. 오픈된 소스이기에 함께 문제 요소를 해결해주고 고민해줄 절대 잉여력을 가진 사람들이 많다. 위 세 가지 내용은 아마도 조만간 Percona에서는 GA버전으로 픽스되어 나올 리스트이다. 오픈된만큼 문제 해결도 오픈 마인드(?)로 원활하다. 다만 GA 적용이 더딜뿐.. 젝슨길
버그는
지금도 레포팅되고 있다.
사실 나는 지금도 실험을 하고 있다.
지금도 하고 있고, 적극적으로 공유할 것이다.
국내 금융 첫 오픈소스 DBMS 도입으로... 사실 걱정도 많이하고, 고민도 많이했고, 다양한 측면으로 협박아닌 협박도 하고있다. 아무래도 상용디비에 비해 리퍼런스가 없는만큼 장애 시 여파는 생각보다 임팩이 크다.
"장애나면 대한민국 금융권에서 오픈소스 디비는 나와 함께 아웃입니다" 내 협박 멘트다.
지난 일년을
돌아본 내 후기?
무슨 부귀영화를 누릴라고.. 허허허
얻은것도 잃은것도 참으로 많은 시간이었던 것 같다. 생전 처음 겪어보는 다른 의미의 어려움도 느껴보았고.
패기도 부려봤고, 만들어 보았고, 고쳐보았고, 감히 질러보았고, 징징대보았다.
자 이제 남는 시간 쪼개서 그동안 못했던 겅부도 하고. 겅유도 하고. 괴기도 먹고. 엥??! (3일을 못먹었어 ㅠㅠ)
