성동찬의 ‘어쩌다 DBA’ (1회) : 살아남기 위해 DB 공부를 시작하다

성동찬의 ‘어쩌다 DBA’ (1회)

살아남기 위해 DB 공부를 시작하다

성동찬
카카오뱅크 DBA. 성동찬은 개발자로 사회에 첫발을 내디뎠다가 ‘어쩌다가’ 전사 서비스 담당 DBA가 됐다. 자기 스스로를 국내 금융권 최초의 ‘오픈소스 DBA’로 보고 있다. 금융 서비스에서 ‘규모 있게’ MySQL을 활용하는 DBA로서 독자들과 그 경험을 나누기를 원한다. (페이스북: dongchan.sung)

몇 년 전, 포털 서비스 DBA로 일할 때다. 서비스를 오픈하는 날이었는데 크게 걱정되지는 않았다. 며칠 간 서비스에서 사용할 쿼리들을 취합-검토해 봤는데 전체적으로 문제가 될 만한 지점이 보이지 않았다. 오픈 후 성능이 나지 않는 쿼리들만 손보면 괜찮겠지, 하며 애써 안도했다. 서비스가 드디어 오픈됐다.

여기저기 커넥션이 불안정하다.
애플리케이션의 응답도 늘어지고 있다.
거의 서비스 불능 상태에 이르렀다.
하지만 유입중인 쿼리를 봤을 때 전체적으로 큰 문제는 없어 보인다.

서울-부산 간 네트워크 지연 7ms
서울에서 부산 서버로 ping을 날려 보면 대략 7ms 정도 지연이 나온다. 서울에는 데이터 노드들, 이 속에는 DB뿐 아니라 캐시 레이어도 같이 있었다. 문제는 이 데이터를 이용하는 애플리케이션 서버들이 부산에 위치한다는 점이었다. 대형 혹은 트래픽이 많은 서비스의 경우, 자주 사용되는 데이터를 상대적으로 느린 DB로부터 매번 읽기보다는 바로 원하는 데이터에 접근할 수 있도록 2차 캐시, 예를 들면 레디스 혹은 멤캐시를 애플리케이션과 DB 사이에 두곤 한다. 문제는 2차 캐시에 ‘자주 사용하는 데이터 질의(query)’를 했을 때, 이 질의 시점에 매번 7ms 네트워크 지연이 관여하면서 전체적으로 서비스 속도가 나지 않고 있었다.

DB 얘기를 하는데 갑자기 웬 네트워크 지연? 하지만 이 시점에 한번쯤 고민해봐야 할 이야기이기에 다소 뜬금없지만 ‘지연’이라는 단어를 꺼냈다.

어쩌다가 DBA
필자는 아마도 국내 금융권 최초의 ‘오픈소스 DBA’일 거다. 금융 서비스에서 ‘규모 있게’ 오픈소스 DB인 MySQL을 활용하기 시작했는데, 이런 환경 속에서 내 역할은 무엇일까?

필자의 태생은 개발자다. 대학 졸업 후 첫 회사에 들어가 애교로 넘길 수 있는 수습 기간을 마치고 처음 맡았던 서비스, 얘기는 여기부터 시작된다.

‘기술 내재화와 비용 절감’이 유행처럼 번져 나갔던 시기였다. 사실 지금 생각을 해봐도, 엔지니어의 역량을 과연 어떠한 방법으로 제대로 ‘수치화할 수 있을까? 하는 의문이 든다. 그래도 아무튼 당시에 ‘기술 내재화’라는 목표를 향해 ‘외주로 개발-관리’하던 사이트들을 하나둘 가지고 들어와 내부 직원들이 맡아가는 과도기였다.

살아남기 위해 DB 공부를 시작하다
필자가 입사 직후 맡았던 서비스는 그해 처음으로 기술 내재화하기로 결정됐던, 가입 고객에게 포인트로 ‘혜택’을 주던 서비스였다. 회사 매출에서 꽤 높은 비중을 차지하고 있는 서비스였던 만큼, 개발자 사이에서도 굉장히 고된 업무로 정평이 나 있었다. 고된 업무 기준으로는 회사 톱2에 드는 서비스였다. 아무튼 기술 내재화를 목표하며, 10년 전 이 핫한 서비스는 ‘그랜드 오픈’을 했다.

오픈 직후부터 장애가 끊임없이 이어졌다. 그때만 해도 필자는 경험이 부족했으므로 말그대로 머리가 하얘졌다. 크게 무슨 대책이라도 내놓을 수도 없던 상황 속에서 난생 처음 무한 장애 속에서 허덕일 수밖에 없었다.

어찌 됐든 장애는 이어지고 있었고, 문제의 지점을 찾아내 반드시 해결 ….

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다