일본에서 날아온 보람찬 소식

저희 EXEM Japan이 일본에서 어떻게 지내고 있는지 가끔씩 소식을 전해드렸었습니다.

해외에서 얼마의 매출을 올리고 있는지도 참 중요한 이야기이지만,

그 곳시장에서 저희의 소프트웨어를 찾아주는 곳이 계속해서 늘어가고 있다는게 어찌나 보람찬지 모릅니다.

언젠가는 일본 시장에서도 DB성능관리하면 "한국의 맥스게이지"가 바로 떠오를 수 있는 그 날이 올 수 있도록 참 많은 분들이 열정을 다하고 있습니다.

그러던 와중 지난달, 정례회차 한국을 방문한 EXEM Japan의 고토사장님이 뜻깊은 소식을 전해주셨습니다.

고객사 중 레코쵸쿠라는 휴대폰 음악 전송 서비스를 제공하는 회사가 있는데, 데이타베이스 성능문제로 고민하다 지난해 MaxGauge를 도입했었습니다. 사실 도입하면서도 처음에는 커다란 기대는 없었었다고 나중에 말씀하셨었다고 합니다. 하지만 그 별로 기대를 받지 못했던 MaxGauge가 처음 기대치를 훨씬 뛰어넘은 40%이상의 개선효과를 가져왔고, 여기에 대한 레코쵸쿠사의 칭찬이 자자했다고 합니다.  

그리 큰 기대를 하지 않았던 해외 고객사를 깜작 놀라게 했다니, 바로 이런 것이 해외시장에서 얻을 수 있는 즐거움 중에 하나인 것 같습니다.

일본의 유명 데이터베이스 전문 잡지인 DBMagazine에도 소개된 레코쵸쿠 사례를 블로그를 통해 공유합니다.

“레코드회사 직영의 음악전송 서비스로 급성장”

2009년 2월1일에 레벨모바일(レーベルモバイル) 주식회사로부터 사명을 변경한 주식회사 레코초쿠(レコチョク)는, 2001년 창업한 이래로 착신멜로디 전송 서비스를 시작. 이후 2002년 12월에 착신멜로디(着うた)、2004년 11월부터 착신 멜로디 풀(full)() 서비스 등을 제공하고 있는 세계최대규모의 휴대전화용 음악배신(전송)회사이다. 서비스 명(名)으로 알려져 있던 레코초쿠(レコチョク)로 브랜드를 통일하고 동시에 사명을 변경했다.

시스템본부 본부장 이소가이씨는 [제공하고있는 서비스의 주력은 착신 멜로디 풀(着うたフル), 착신 멜로디(着うた)를 중심으로 하고 있는 컨텐츠전송입니다. 그런 까닭에 업무에 있어 IT 의존도가 높고 특히 전송서비스시스템이 중심입니다.] 라고 말했다.

현재의 시스템은 2001년의 서비스 론칭 후 세 번째로 구축된 것으로 2005년 11월부터 가동하고 있다. 단기간에 2회의 재구축이 진행된 이유의 하나로 이소가이씨는 [당초, 모바일 음악배신서비스가 이렇게까지 극단적으로 부하가 걸릴 거라고는 생각하지 못했다] 고 말했다.

전송서비스 시스템에 있어 엑세스 부하가 집중되어있는 곳은 유저의 검색을 받아들여 휴대기기에 화면표시데이터를 전송하는 [사이트표시 DB 군] 이다. 검색 DB 서버는 수십 대의 데이터베이스로 구성되어있다. 현행시스템은 현재의 엑세스 수를 상정해 설계되어있는 까닭에 어떤 사정으로 인해 급증하더라도 충분히 대응할 수 있었다.

“예상외의 접속 에러가 발생”

그러나 검색대상 곡은 계속적으로 증가하는 반면, 2008년 중반부터는 이제까지 전무했던 DB로의 커넥션 에러 등이 발생하게 되었다. 어림잡아 보았을 때 현재의 엑세스 량은 견딜 수 있는 정도였다. 시스템 본부 오퍼레이션 그룹 매니저 아사누마씨는 [ORACLE의 분석툴 등으로 CPU의 리소스량을 조사해보았더니, I/O 대기 부분이 극단적으로 부하가 걸려있는 것을 알았다. 그러나 그 부하를 가증시키고 있는 진정한 원인은 어디에 있는지, 예를들면 어떤 SQL이 장애를 일으키고 있는가 까지 깊게 파고들어 분석하는 것이 불가능했다.] 고, 당시의 상황을 돌아본다.

ORACLE 분석 툴로 접속 에러 발생의 요인을 찾아내는 것이 어려웠던 이유의 하나로, 레코쵸쿠 사이트 만의 특징으로 꼽는다. 이를테면 음악방송 등으로 인기  아티스트의 곡이 방영된 직후의 엑세스 급증이다. 한 순간에 수십 배가 되어, 10 ~ 15분 정도의 간격으로 데이터를 집계하는 표준 툴로는 결과가 평준화 되어버린다. 그런 까닭에 피크 시에 어떤 SQL의 부하가 높은가 등의 핀 포인트로 원인을 특정 짓는 것이 불가능했다. 당연히 에러발생시의 상세정보도 남아있지 않는다.

그때까지도 SQL튜닝 등의 대응은 계약벤더(vendor)의 엔지니어로부터 행해졌다. 다만 표준툴을 사용한 분석결과를 근거로 하고 있는 까닭에, [수상한] SQL 을 추정해 수정하고, 그 결과를 보고 수정부분을 바꾼다는 등의 TRIAL을 반복하게 된다. 또한 레코초크 사이트와 같이 24시간 365일 안정가동이 절대조건인 경우, 가능한 한 손을 대고 싶지 않은 사정도 있다.

그래서 벤더로부터 나온 개선안은 하드웨어의 증강이었다. 실제로 [하드웨어의 가격도 하락하고 있어 교체로 끝날 문제라면 해보자고 생각하는 사업자가 적지 않다](아사누마씨)가 실정인 듯 하다. 다만 이소가이씨는 [확실히 증강은 유력한 선택안이지만, 에러의 잠재적인 원인을 남겨둔 채로의 투입은 효력의 보증이 어려운데다, 지금 당장 상황에 대한 해결책이 되어도 미래에 비슷한 사태가 발생할 가능성이 있습니다.] 고 문제점을 지적했다.

“[기대치]를 큰폭으로 상회하는 MaxGauge 도입효과”

그 부분에서 효과적인 정보를 수집할 수단으로 주목했던 것이, EXEM JAPAN의 ORACLE DB 감시, 성능, 장애분석, 튜닝을 위한 종합 패키지, MaxGauge였다.  ORACLE 에서는, 프로세스의 리소스에 대해 대기상태와 실질적인 처리시간 등의 통계 데이터를 기록하고, 진단, 분석하기 위한 방법, 인터페이스 등을 OWI (Oracle Wait Interface) 라 부르며 제공하고 있다. MaxGauge는, 그 OWI 장점을 기반으로 개발되어, 표준툴로는 불가능한 소수의 데이터 취득이 가능한 이유로 핀 포인트의 해석이 기대 가능하다고 판단해, 시험적으로 도입을 결정했다.

 먼저 8월말, Oracle 검색 DB 서버를 대상으로 MaxGauge 를 사용해 정보를 수집하고, 9월 초순에 분석을 개시. 10월 상순에 걸쳐 분석한 결과, 문제 발생시점의 부하가 걸리는 패턴은 대략 5가지로 집약되는 것으로 판명되었다. 그리고 그 5가지 패턴 정도의 SQL 로 인해, I/O 전체의 60 ~ 70 %를 점유하고 있어, 이 부분을 개선하면 큰 효과를 기대할 수 있다.

 여기서 유효하다고 판단한 병목해소를 위해 실시한 튜닝방법은 INDEX의 최적화이다. 거기서 문제의 5종류의 SQL을 새로 작성한다면, 계산상으로 40%정도의 개선이 가능하다는 것을 알 수 있었다. 그리고 잠정적인 개선안의 검토를 실행, 좋은 결과를 받아 적용한 후, 에러가 발생하고 있지 않다.

이소가이씨도 아사누마씨도 당초, MaxGauge 에 의한 검토를 근거로 SQL 튜닝을 이렇게까지 효과가 있을거 라고는 기대하지 않았다. 거기서 도입시 [효과의 전망은 10% 정도의 개선]이란, 당시의 하드웨어 증강도 고려하고있었다. 그런데 40% 정도의 개선이 가능하다는 말을 듣고, 갑작스러워 믿을 수가 없었다고 한다. 더구나 튜닝을 실시한 효과를 계측해보니, 40%를 큰폭으로 넘어서는 효과가 있다는 것이 판명되었다. 튜닝으로 I/O 가 상정대로 개선된 만큼, 메모리에 여유가 생겨, 캐싱가능한 데이터가 증가한 것으로 상정치 이상의 결과가 나온 걸로 보인다. (화상)

“분석 툴의 활용으로 IT 투자의 최적화를”

이번 사이트 표시계 DB군 에 대한 검증, 검증, 개선작업은 에러발생부분에 대응해서 부분적으로 이루어졌다. 이후 제공서비스의 확장과 변경이 행해져, 어플리케이션의 구성이 변경된다면 다른 부분에 부하가 걸려, 새로운 에러가 발생할 가능성도 있다. 그렇기 때문에 문제점을 발견하고 개선하는 사이클을 이루기 위한 툴로써 효과가 실증된 MaxGauge를 계속적으로 활용해 나아갈 예정이다.

추가로 이소가이씨는 [이번, 튜닝으로 성능의 극적인 개선을 발견하였기 때문에 서버의 통합과 집약을 시야에 넣어 검토하고 있다]고 밝혔다. 그리고 [엔드유저의 IT 부문도 지식을 익혀 MaxGauge와 같은 툴을 활용하여 IT에 대한 투자를 최적화 해야 한다] 고 제시했다.