금융 오픈소스 DBA 30일 생존기
"30일 생존기?"
뭐 일단은 사고 없이 잘 돌고 있다는 의미로 받아주기를..
장황하다. 힘들었다. 몇 마디로 지난 한달간의 심경을 토로하기에는 글재주가 미흡하다.
누가 들으면, 사막 한가운데 버려져서, 도마뱀 먹고 선인장 마시며 발악하면서 살아온 줄 알겠다. 그런데, 실상으로 (굉장히 여유있는 척 했지만) 발악을 하며, 긴장하며 지내왔다.
죽으려 하면 살 것이고,
살려고 하면 죽을 것이다.
가진것이라고는 몸뚱이, 얕은 지식 그리고 알량한 경험정도로, 벼랑 끝에 몰린 쥐와 같다.
바로 얼마 전 금융 x86 리눅스 성공리에 도입했다는 기사를 보았다. 굳! 쾌거~! 짝짝짝.
그런데 알고있으려나? 오픈소스 DBMS인 MySQL이 바로 그 x86리눅스 위에서 돌고 있다는 사실을.. 게다가 스케일아웃이 가능한 유연한 구조로.. (신이시여..)
믿거나 말거나겠지만.. 은행에서 가장 큰 변화가 있던 분야 중 한 곳은.. 데이터 구조가 자체가 통째로 흔들린 MySQL이라고 생각한다.
제 3자의 입장에서 MySQL을 쓰든 안쓰든 차이가 없다. 예를 들어, DBMS가 Oracle이든, Postgres든, MySQL이든 그들이 제공하는 원초적인 기능 측면에서는 똑같다~ 그렇다면 보통은 레퍼런스 가득한 시스템으로 구성하는 것을 제일 선호한다.(당연하겠지만)
레퍼런스가 없다는 것?
만들어진 것 없다는 것?
스스로 모든 것을 해결해야 한다는 것?
OTL=3
거대 은행과 동일한 규제를 받는 소규모 뱅킹 서비스 조직에서, 가진 것 하나 없이 "처음 시도"만 하는 입장에서 느끼는 심리적인 압박은 상상 외로 거대했다.
어찌어찌 최근 꽤나 "핫하고 핫한 하태하태" 은행에 들어와서, 지금껏 사례없는 오픈소스 DBMS를 도입을 했고 운영을 하고 있고.. 궁시렁궁시렁~ 자랑도 하고 싶고, 칭찬도 받고 싶고, 울분도 표하고 싶고.. 복잡한 심경을 토로해본다.
MySQL
값비싼 스토리지를 끼지 않는다. 상용 DBMS처럼 그들이 제품을 보장하지도 않는다. 멋있어 보이지도 않는다. 게다가 기능도 부족하다. 마치 어플리케이션 서버로 인식될 듯한, 싸구려 DBMS로 느껴질만한 네이밍의 가난한 포털(?)에서만 쓰일 것 같은 돌고래 이미지.. (점프 돌고래~)
mysql database누군가는 장난감 같고 작은 DBMS를 어떻게 은행에 쓰냐고 우스개 소리도 했었다.
그만큼 시작은 편하지 않았다. 겪어온 경험과 문화가 달랐기 때문이다.
캐시 없는 서비스는 상상해본 적이 없다.
내 입장이다. 캐시 없이 어떻게 엄청난 트래픽을 효율적이고 유연하게 대응을 할 수 있을까? 워낙 리소스에 한계가 있는 상황에서 테라급 트래픽을 견뎌내야 했었기에, 자연스럽게 굳어진 생각같다.
그렇지만, 반대의 입장으로 돌아보자.
조인할 테이블이 보이지 않는 것은 재앙이다
마스터라는 제한된 리소스 속에서 최대의 효과를 일궈내야 하는 현실에서, 자연스럽게 분산 레벨이 테이블 수준까지 내려갈 수밖에 없다.
즉, 기존과 완벽하게 다르다.
데이터 구조가 완벽하게 틀어졌다.
아키텍쳐가 파격적으로 바뀌었다.
그럼에도 문제없이 잘 돈다.
먼나라 이웃나라 중국에서는 수억 유저를 위한 은행 데이터 처리에 이미 MySQL을 사용하고 있다. 페북에서는 수십억 사용자의 트래픽를 MySQL로 서비스 중이다. 가장 가까운 예로는 대한민국 1등 sns 서비스의 모든 것은이 MySQL로 되어 있다.
이정도면 솔루션 자체의 성능과 안정성에 의심을 가질 필요 없어보인다.
쓰이는 곳
곁다리가 아니다. 생각보다 중요한 곳에 위치한다.
우선 은행 창구의 데이터 창고이다.
새로운 고객이 들어오면, 인사도 하고 신원 파악도 해본다. 고객이 방문하면, 고객을 응대하고 인증하고 거래해주는 커뮤니케이션의 시작에 위치한다. 돈을 찾을때도, 돈을 빌릴때도 거래의 과정에 MySQL이 껴있다. 여기가 붕괴하면, 모든 창구의 은행원들이 식중독으로 출근못한 것과 같은 대 혼돈이 찾아올 것이다.
고객의 요구사항을 은행에 요청한다.
내 계좌를 조회해줘, 내 계좌에 입금해줘, 다른데로 이체해줘.. 등등 은행 서비스에 필요한 모든 요청들을 은행 시스템에 하나하나 전달한다. 이 과정에 지연이 생기면 서비스도 같이 지연된다. 지연이라면.. 마치 3G에서 화상통화한다는 상황이려나?
고객에게 말을 건다.
은행이 고객에게 말을 한다. 은행 업무 처리 이후 결과를 고객에게 통보한다. 은행이 전달해야하는 모든 것들 처리는 MySQL이 담당한다. 여기에 문제가 생기면, 고객은 처리 결과를 통보받을 수 없다. (물론 거래 화면에서는 정상적으로 보여지겠지만..)
기타 내부 개발 솔루션은 일단 MySQL로 시작한다. 무엇인지는 각각의 상상에 맡기겠다.
생각보다 중요한 부분에 MySQL이 들어가있고, 문제가 발생하면 꽤나 심각한 여파가 찾아온다. 무엇보다, 앞에서 나열했던 모든 부분들이 100% 상용 DBMS로 구성되어 있는 것이 금융 솔루션 현실이었다.
물론, MySQL 들어간 부분의 반 이상은 처음부터 만들기는 했지만, 도입된 솔루션 영역은 어쩔 수 없이 그 솔루션에 스케일아웃이 가능한 철학으로 변경해야 했었다. 완벽하지는 않지만.. 일단은 시도했다.
감회 속에 눈물을 흘려본다. ㅠ_ㅠ
30일 생존 보고서
지금 현황이다. 물론.. 많은 부분 비효율을 제거한 상태에서의 유입량이다. (개발자들 짱짱짱!)
5,000 ~ 10,000 dml / sec
10,000 ~ 20,000 quries / sec
여전히 비효율 부분이 있기에, 하나하나 해결하다 보면, 앞으로도 수치는 쭈~욱 하향 조정 예정이다.
사실 오픈 이후 예상치 3배~4배 이상의 트래픽이 유입되었다. 몇달 후 계획을 할 것이라 생각했던 서버 확장을 했다. 물론.. 새벽이긴 했지만.. 무중단 온라인 확장!! 쾌거~
과거 카카오 서비스를 (개인적으로) 미루어봤을때.. 트래픽 양이 지금보다 딱 절반 수준으로 오를 것으로 예측했었기에 그 정도까지는 여유있을 정도로만 준비를 했었다. (그래봤자 어차피 초기 예상치의 2배 이상이지만..)
현재의 리소스 사용률은 아래 이미지로 대체하겠다.
CPU Usage서비스 본격 이후로도 여전히 무장애 상태이다.
하드웨어 이슈가 아닌 한, 한동안 이 상태로 지속될 것으로 보인다. 아.. 튜닝할때마다 쿼리량도 줄어들고, 비효율도 걷어낼 것이니.. 더 좋아질라나. -_-;;
본격 서비스 30일! 장애 없음
앞으로도 문제 없을 예정
우선은 30일 생존 결과 보고서를 이렇게 간단하게 두 줄로 정리해 본다. (뭐.. 약간의 해프닝은 있었지만.ㅎㅎ)
생존 전략
원칙(끼워 맞춘듯한)은 별 것 없다. 몇가지 목표를 세우고 정글 속 대 자연과 맞서보았다.
인간과 기계의 분리
나는 게으른 사람이다.
귀찮은 것 참 싫어하고, 재미를 추구한다. 단순 반복 업무는 95% 기계에게 미룬다. 나머지 5%는 사람인 내가 한다. 적어도 자동화를 제어하는 영역은 인간이 해야하지 않는가!!
Data & Automation구축/모니터링/장애대응/튜닝/트러블슈팅.. 모든 처리를 두명이서 한다. 전 회사에서 하던 일과 바뀐 것은 없지만.. 조금 더 주의 깊게 서비스를 바라보고 있다. 뭐.. 장비도 전 회사 대비 대략 5%도 안되는 수준이니 뭐.. 나름의 디테일..쿨럭
신뢰 속의 무한 확장
가장 좋아하는 단어이다. 무한 확장.
그러나, 데이터 입장에서, 특히나 관계형 데이터베이스 입장에서 바라본다면, 쉬운 컨셉은 아니다. 데이터가 이동한다는 것은 서비스가 동작하는 "기준점"이 이동한다는 것과 마찬가지이다.
Extreme Scale-Out지금에야 고백하지만, "무한 확장"을 지향하지만, 현재는 "유한 확장" 구조이기는 하다. 다만, 트래픽 임계치를 예측하고 있고, 그런 땡큐 상황이 올지라도 얼마든지 확장할 수 있는 전략이 있다.
그렇기에, 무한 확장이라고 주장해본다.
다양한 접근 방법
MySQL을 좋아하는 이유 중 하나는 유연성에 있다. 그리고 애초에 제공하는 기능이 워낙 미미했기 때문에.. 굉장히 뛰어난 선구자들이 멋진 툴들도 많이 만들어놨다.
백만 데이터 전문 검색이든, 온라인구조 변경이든.. 효율성 입장에서 접근한다.
문제가 발생하면 고민한다.
만들어진 것 활용해본다.
없으면 필요하면 만든다.
그리고 해결한다.
뱅크 속 오픈소스 DBA는 데이타베이스 관리만 하지 않는다. 서비스를 같이 고민하고 같이 발전하는 것을 선호한다. 필요하면 당연한 이야기지만, 개발도 한다. (이쯤되면 정체성이..ㅎㄷㄷ)
아쉬운 점
하나.
은행 서비스인지라 엄격함은 당연한 일이지만... 작은 이슈에서도 서버에 붙어서 모니터링/작업을 하던 과거와는 다른 세상이다. 물론 이렇다보니, 자연스럽게 업무와 생활의 분리가 이루어졌다만..
회사 밖을 향하면, 걱정이 우선 앞선다.
둘
전체 서비스 데이터 흐름 파악이 미흡했다. 오픈 이후 유입되는 트래픽을 실제로 보고서야, 알게된 점이 참으로 많다. 은행 서비스를 처음 접한 것도 이유였겠지만.. "데이터" 기준에서 조금 더 깊이 고민해보지 못한 자신을 자책한다.
그래서, 요새는 여기저기 참견하고 다닌다. 이러다가 은행 속 "공공의 적"이 되버리릴까 걱정이다.
셋
오픈 전에 안정성에 필요한 대부분의 것들은 구조화해놓아서, 오픈 이후 사실 큰 작업이 거의 없었다.
그래서 한가해보인다. -_-;;
내세울만한 대규모 작업이라고는..
온라인 무중단 스케일 아웃한 것과..
1300만 건 데이터 온라인 스키마 변경 작업 정도?
http://gywn.net/2017/08/small-talk-pt-osc
기계가 일을 하는 대신 나는 사람이 할 일을 꾸준히 보이지 않은 곳에서 수행한다.
서비스 비효율스러운 부분을 찾아내서, 매일매일 최적화를 한다.
포커스가 데이터베이스이든, 어플리케이션 레벨이든.. 짧은 역량으로 할 수 있는 최대한 힘내본다.
나름 바쁜 사람이다.
포부
포부는 포부일 뿐, 현실로 이어진다. 우움? -_-;;
60일 후에도 여전히 문제없을 것이다.
특정 장애로 전체가 마비되지 않을 것이다.
여전히 사람의 일을 하고 있을 것이다.
"문제 생기면 퇴출 당할 각오"는 여전히 유효하다. 그렇다고 짤리기에 너무 어린(?) 나이를 탓하며 "시도"를 피하고 싶지도 않다.
60일, 90일, 365일 이후?
여전히 생존 중일 것이고, 오히려 진화된 형태로 잡초보다 더한 생명력으로 뿌리를 내릴 것이다.
30일 생존 보고서는 여기서 마무리한다.
