G마켓 위기의 추억
36시간의 악몽
36시간의 악몽
G마켓의 성공을 계속해서 이야기해보고 있지만 G마켓의 위기가 없었는가 하면 그렇지 않았습니다.
앞서 적은 글에서 2003년에 비해서 2004년에는 무료 500배의 매출 상승이 있었습니다. 하루하루가 진짜 전쟁과 같았습니다. 늘어나는 트래픽과 유입량을 따라갈 수가 없어서 서버를 계속해서 증설하고 프로그램을 튜닝해야 했습니다.
당시 MS-SQL 서버를 쓰고 있었는데 시스템별로 분리되지 않고 그야말로 통 db로 사용하고 있었습니다. 상품등록, 주문, 결제, 배송, 고객센터, 마일리지 까지 모두 한 DB을 바라보고 있었습니다. 당연히 다른 시스템 쪽에 부하가 올라가면 다른 한쪽에 안되는 것이 부지기수였습니다.
이에 대한 해결 방안을 다양하게 적용되었습니다.
첫째, 서버 증설입니다. DB 서버의 경우 제 기억으로는 전 세계에서 가장 비싼 MS-SQL 서버를 구매했습니다. 10억으로 들었는데 슈퍼돔이라는 이름의 서버였고, 24 cpu가 달려 있다고 했습니다. db 서버의 경우 교체할 때 12시간 동안 사이트를 막고 작업을 했는데 다들 초 비상이었습니다. 1번 실패했고, 2번째로 성공한 기억이 납니다.
둘째, 여러 가지 부하를 줄이는 튜닝 작업이었습니다. 당시 ms-SQL 기반에 store procedure을 사용했는데 이 쿼리 튜닝을 정말 빡세게 했습니다. nolock 처리를 모든 쿼리에 붙였습니다. 트리거 이거 쓰면 욕먹습니다.
또한 메인 페이지, 상품 상세 페이지를 html 정적 페이지로 해서 캐시 기능을 극대화하여 최대한 DB 부하를 줄였습니다. 특히 조회용 DB 운영이 있었습니다. 실시간 조회가 필요 없는 어드민 및 서비스에 대해서 조회용 log을 이용해서 조회용 DB을 구축해서 사용했습니다. 한 시간에 한 번씩 2대의 서버에 backup/restore 하는 방식인데 MS에서도 이 기술은 와서 놀라곤 했습니다.
G마켓의 성공이 영업의 성공, 마케팅의 성공, HR의 성공이라고 말하는 사람들도 있지만 그 이면에는 IT 담당자들의 피땀도 있었습니다.
그런데 2004년 한 여름 일이 터졌습니다.
2004년 여름 G마켓 사이트 모습갑자기 DB 서버에 문제가 생기면서 멈춘 것입니다.
이런 화면이 G마켓 메인에 걸렸습니다. DB서버의 경우 당시에 여러 가지 백업을 하긴 했지만 대체할 수 있는 시스템이 있지 못했습니다. 급하게 하드웨어 업체를 불러 정비를 했지만 시간이 계속 흘렀습니다. 급하게 시스템을 업그레이드하고 전원을 넣었지만 시스템이 올라오지 않았습니다.
IT 담당자들은 전원 집에 가지 못하고 회사에 대기해 있었지만 할 수 있는 것이 없었습니다. 이렇게 저렇게 회의만 하고 있었습니다.
이런 상황으로 36시간이 흘렀습니다.
당시 저는 회사에서 모니터링을 하고 대기하고 있어서 IDC센터에 있지 않았지만 상황은 급박했습니다.
시스템을 다시 리부팅할 것인가 기다릴 것인가 사장님 이하 대책회의가 IDC센터에 있었다고 합니다.
결론은 전원 버튼 On!
결론적으로 DB 가 다 다시 살았고, 사이트는 정상화되었습니다. 네이버 뉴스에서 찾을 수 없었지만 G마켓 사이트 장애 난 것이 네이버 뉴스에 올라갔습니다. 그런 엄중한 상황에서도 직원들은 우리 사이트가 크긴 컸군 사이트 안 되는 게 뉴스에 나고 허허하고 몰래 웃었습니다.
직원들이 느끼는 지점은 정말 심각한 상황이었습니다. 다들 회사 망하는 것이 아닌가 하는 생각을 많이 했습니다. 당시 저는 큰 프로젝트를 혼자가 개발하고 있었고 오픈이 코 앞이라서 사이트 다운되는 상황에서도 개발을 멈추지 못했습니다. 사이트가 다시 오픈되고 저의 프로젝트도 오픈이 되어 한 시름 놓았습니다. 그 프로젝트가 해외 배송 시스템이었습니다. 오늘 미국은 블랙프라이데이라고 하고 직구가 보편화된 시대에서 G마켓 해외배송 시스템도 생각이 납니다.
