Home > 열린마당 > 공개SW 소식

공개SW 소식

2013년 8월호

ⓒ 마이크로소프트웨어



우리가 지금까지 읽어 왔던 인터뷰 기사의 주인공은 상당수가 성공한 경영인이었다. 그런데 개발자인 우리들은 사무실 안에서 묵묵히 일하고 있을 뿐이다. 필자는 우리 스스로가 ‘스타 개발자’가 돼야 한다고 생각한다. 연예인처럼 화려한 스포트라이트를 받고자 하는 건 아니다. 사람들에게 개발자로서의 ‘나’를 알리자는 것이고, 그로 인해 ‘나’라는 존재에 가치가 부여된다고 믿는다. 예를 들어 회사의 제품 개발 프로젝트에서 중요한 역할을 수행해도 그 제품을 누가 만들었는지 모른다. ‘내’가 만든 제품이 시장에서 높은 가치를 갖고 있음에도 불구하고 정작 만든 ‘나의 가치’는 인정받지 못하고 있다.‘개발자가 만난 사람’의 주인공은 바로 ‘우리’다. 누구나 주인공이 될 수 있다. 여러분의 이야기이고 여러분 동료의 이야기다. 그리고 우리 곁에서 말없이 IT 산업을 이끌고 있는 ‘숨은 고수’의 이야기다.

용영환 xenonix@gmail.com|넥스트브레인(www.nextbrain. com)을 이끌고 있고, 행복한 삶을 꿈 꾸며 글 쓰기를 좋아하는 개발자다. 다르다는 것이 틀린 것은 아니기에 다양한 사람들 속에서 많은 것을 보고 듣고 경험하려고 노력한다.


이성욱
|프로필|
현재 카카오에서 DBA로 일하고 있다. 위치기반 AVL(Automatic Vehicle Location) 시스템, 금융권 CRM 등의 개발 경험을 갖고 있으며, NHN과 네이버재팬에서 DBA로 근무했다. 삼성SDS 소프트웨어 공모전에서 동메달을 수상하기도 했다.


AVL(Automatic vehicle location)은
2001년에 자동으로 자동차의 위치를 파악하고 관리하는 시스템을 만들었다. SK에서 넷트럭이라는 서비스를 제공하는데, 트럭으로 화물을 운반할 때 가장 중요한 건 공차, 즉 비어 있는 차에 대한 관리다. 예를 들어 모래를 싣고 서울에서 지리산까지 갔는데 공차로 돌아오면 여러모로 낭비가 생긴다. 이때 지리산 근처의 공차를 확인하고 그 지역의 특산물 등을 싣고 서울로 돌아오게 한다면 회사나 트럭 운전사에게도 좋을 것이다. 그 당시에는 스마트폰이 없었기 때문에 CDMA 휴대전화기에 GPS 단말기를 연결해서 위치 정보를 전송했다.

DBA가 된 계기는
NHN에 입사해서 DB팀에 들어갔다. 사내 DBMS 관리 시스템과 모니터링 시스템 등 DBMS 관리 솔루션을 개발했다. NHN 표준 데이터베이스 모델링 작업도 참여했다. 그 후 일본에 있는 네이버 재팬에서 DBMS 운영을 담당하면서 자연스럽게 DBA로서의 길을 가게 됐다. 

DBA로서 힘든 점은
개발은 개발환경을 따로 구성해서 작업을 한다. 반면 DBA는 서비스 환경에서 직접 작업하는 경우가 많다. 그만큼 정신적인 스트레스가 심하다. 자칫 잘못된 쿼리를 입력하면 치명적인 장애가 발생할 수 있다. 그래서 쿼리를 작성한 후 이게 정말 맞는지를 의심하면서 지우고, 다시 쓰기를 두세 번씩 반복한다. 세 번 이상 다시 썼음에도 불구하고 같은 쿼리를 작성했을 때 비로소 그 명령을 실행한다. 그리고 늘 준비된 상태로 일해야 한다. 늘 위급 상황에 대처할 준비를 하고 있어야 하며 예상되는 많은 상황에 대한 연구와 학습을 하고, 경험을 계속 쌓아야 한다.

DBMS 운영에 대해
웹서버들은 평소 CPU 사용률이 60~70% 이상 올라가기도 한다. 하지만 DBMS는 평소 서버 자원을 매우 낮게 사용해야 한다. 왜냐하면 웹서버는 자원이 부족하거나 장애가 발생했을 때 서버를 추가하거나 제거하기가 쉽지만, DBMS는 운영 중에 관련 장비를 새로 투입하거나 교체할 수 없기 때문이다. 그래서 CPU 사용률, 디스크 용량, 메모리 상태 등 전체 서버 자원을 계속 모니터링하고 안정된 상태를 유지하는 데 많은 노력을 기울인다. 그러기 위해서는 쿼리, DBMS, 운영체제, 하드웨어, 네트워크 등 모든 부분이 최상의 상태로 튜닝돼야 한다.

쿼리 작성할 때 주의할 점은
<대용량 데이터베이스 솔루션>(엔코아컨설팅)의 저자 이화식 님은 “쿼리를 한 문장으로 모아서 쓰면 성능이 좋다”고 강조했다. 그래서인지 일부 사람들은 쿼리는 무조건 한 문장으로 써야 한다고 생각하는 듯 했다. 저자의 본래 의도는 최대한 쿼리를 모으되, 최대한 데이터 읽기를 작게, 최적화해서 쓰라는 의미였다. 그러나 쿼리를 한 문장으로 최적화해서 작성하는 건 매우 많은 경험과 지식이 필요하므로, 일반적으로는 쿼리를 적절하게 나눠서 수행하는 게 좋다.

그리고 오라클과 MySQL은 내부적으로도 많이 다르다. 예를 들어 MySQL의 쿼리 분석기는 오라클의 쿼리 분석기에 비해 성능이 낮기 때문에 복잡한 쿼리를 수행할 때 느리다. 대신 가벼운 쿼리 하나하나를 수행할 때에는 오라클보다 성능이 좋다. 그러므로 DBMS에 따라 알맞은 쿼리를 쓰는 게 중요하다.

MariaDB for Kakao
MariaDB는 MySQL 개발자 몬티 와이드니우스가 만든 오픈소스 DBMS이다. 아무래도 MySQL에 기반한 제품이다 보니 백그라운드 작업에서 MySQL의 문제점을 그대로 가지고 있는데, 카카오에서는 그 문제점을 직접 튜닝해서 MariaDB For Kakao라는 이름으로 쓰고 있다. 성능이 향상된 MariaDB for Kakao를 카카오 내부에서만 사용하기보다는 모두와 함께 나누고 싶었고 현재 MariaDB 재단과 소스 커밋에 대한 절차를 진행하고 있다. 조만간 선보일 수 있길 기대한다.

MySQL에서 MariaDB로 마이그레이션하려면
MySQL과 MariaDB는 100% 호환이 되므로 MySQL에서 리플리케이션을 MariaDB로 하면 된다. 그러면 실시간으로 데이터를 마이그레이션할 수 있으므로 매우 쉽다. 반대로 MariaDB에서 MySQL로 돌아오는 것도 마찬가지다. 그리고 만약 응용프로그램에서 JDBC로 MySQL을 연결하고 있었다면 아무런 변경 없이 MariaDB로 연결을 바꾸기만 하면 된다.

추천하고 싶은 책은
회사에서 업무적으로 다뤄볼 수 있는 DB 기술들은 제한적이다. 어떤 것들은 자주 접해서 매우 잘 알지만, 그렇지 않은 건 잘 모를 수밖에 없다. 어떻게 하면 MySQL에 대해 더 많이, 깊게 알 수 있을지 고민하던 차에 <High Performance MySQL>(O’Reilly Media)이란 책을 공부하는 셈 치고 번역했다. 영문판으로 세 번 이상 읽었는데, 많은 분들께 추천하고 싶은 책 중 하나다. 국내에는 <MySQL 성능 최적화>(위키북스)로 번역 출간됐다.

DBA에게 필요한 소양은
소프트웨어 개발에 대한 경험이 있는 게 좋다. 프로그램 내에서 데이터가 어떻게 쓰이는지 알아야 DBA로서 쿼리를 튜닝해줄 수 있기 때문이다. 회사에 따라서는 DBA가 직접 개발에 참여하는 곳도 있다. 기본적으로 DBA는 개발자와 밀접하게 소통해야 하므로 개발 경험이 풍부할수록 좋다. 또한 디스크, 메모리, 여러 가지 IO 관련된 기술 지식이 필요하다. 특히 운영체제의 IO에 대해서는 깊게 알아야 한다. 운영체제 버전, DBMS 버전에 따라 성능이 다르기도 하고, 하드웨어 펌웨어에 따라서도 성능 차이가 나타날 수 있기 때문이다.

만약 DBA를 희망하는 독자라면 다양한 벤치마킹 툴을 사용해서 임의로 데이터를 생성한 후 연습하면 된다. 같은 쿼리가 데이터 용량 1GB 정도에서는 어느 정도 성능이 나오는지, 그리고 10GB, 100GB 등에서는 어떤지를 계속 확인하고 더 좋은 성능이 나오도록 최적의 쿼리나 옵션 등을 꾸준히 찾는 노력이 필요하다. 여러 개의 데이터 셋을 마련하기 힘들다면 최대한 큰 데이터 셋을 마련해서 연습하는 게 좋다.



※ 본 내용은 (주)마소인터렉티브(http://www.imaso.co.kr/)의 저작권 동의에 의해 공유되고 있습니다.
    Copyright ⓒ Maso Interactive Corp. 무단전재 및 재배포 금지


[원문출처 : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=43389]

맨 위로
맨 위로