본문 바로가기

DevStory

로그 분석기를 Oracle+Lucene에서 Hadoop+MySQL로 변경하면서

처음 이 회사에 입사하여 매일 손으로 작업하던 업무들을 정리해가던 중 개인적인 시간을 내어

개발을 했던 것이 검색 로그분석기이다. 단순히, 인기검색어등의 분석만이 아니라

쿼리별 평균응답시간부터, remote client ip, 호출 클래스, 정렬조건, 페이지, 색인시간등 

검색 운영에 필요한 전반적인 정보들을 모두 분석해서 웹으로 보려고 했던 것이 이 개인 프로젝트 시작이었다.


제일 초기버전은 로그를 분석 할 파서를 개발하고

이렇게 분석된 정보들을 Java Programm에서 Map을 사용하여 일별로 집계하는 방식이었다.

그리고, 이렇게 집계된 데이터는 Lucene으로 색인하여 저장하고, 조회 또한 Lucene으로 검색하여

조회하는 방식이었다.


이렇게 약 1년을 사용하다보니 이 프로그램을 유지보수해야하는 다른 파트원들이 접근하기가 쉽지 않은 부분이 있었다.


Lucene 라이브러리 자체도 생소하고

통계를 내는 방식도, select sum group by~ 가 아니라 왠 Map에다 넣어놓고 loop로 돌면서 열개가 넘는 항목을 계산하고 있었으니... 


그래서 1년 후에 이 부분을 고쳐보았다.

우선 파서로 로그를 분석하여, 하나의 로그에 대한 모든 정보 (키워드,정렬조건,페이지,아이디,IP,캐시히트여부..)를 Oracle에 저장한다. 그러면 검색로그의 라인수 만큼의 데이터가 생성된다.


그리고 이것을 SQL을 사용하여 각 항목별로 데이터를 select하고 이 데이터를 Lucene으로 색인 - 조회하는 형태였다.


색인하는 부분의 인터페이스만 수정하였고, 데이터를 만드는 것 자체는 익숙한 SQL을 사용하여 마음대로 추가 할 수 있는 구조였다.


이러한 구조로 또 한 2년을 넘게 사용하였는데.. 이제 다른곳에서 좀 문제가 되기 시작했다.


일단 가장 중요한 것이 Lucene으로 색인된 데이터에 대한 핸들링이 어려운 부분이 가장 컸다.


일단 기본적인 CRUD만 해도 각각의 케이스에 대해서 Lucene 라이브러리로 개발하고

서버에 올려서 이걸 사용해서 java로 실행해야 하는 형태였고..

저장된 데이터를 보는 것도 어려웠다. 데이터가 많지 않을때는 인덱스 파일을 로컬로 내려서 

Luke를 사용하기도 했지만 기본적으로 인덱스 파일 자체가 서버에 있다보니, 이걸 local로 내리기도 쉽지 않았다.


전반적으로 관리할 수 있는 페이지를 만들려고도 했지만 왠지 배보다 배꼽이 더 큰 느낌이었다.


그리고 이러한 문제점은 최근에 한번 만들어보려고 했던 실시간 급상승 인기검색어를

추출하는 프로그램을 개발하는데도 많은 제약이 생겼다. 데이터를 좀 바꿔가면서 테스트하는 것 자체가 너무

어려운 상황..


그래서 한번 바꿔야겠다... 하고 생각하던 중 개발그룹에서 Hadoop Infra를 구축해주었고

마침 관심이 있던차에 이걸 한번 고쳐봐야겠다... 싶었다. 그래서 손을 댄것이 3주째.. 중간에 한 3번 정도 '아 내가 이걸 왜 손댔지...' 하고 심각히 고민했었음.. --;


큰 틀은 하둡으로 로그를 파싱하고 Map-Reduce를 사용해 분석한 다음 이걸 sqoop을 사용하여

MySQL DB에 각 분석 항목을 테이블별로 밀어넣는 방식으로 잡았고, 조회 페이지 또한 MySQL DB에 접근하여 

조회하는 형태로 잡았다.


현재 상태는 분석->MySQL까지 구현 및 셋팅은 다 되어서 분석을 하고 있고

조회페이지 및 원래 이 수정의 목적이었던.. (하마터면 까먹을뻔한 --) 실시간 급상승 인기검색어 로직을 만들고

구현하면 되는 상황..


작년에 하둡관련 서적을 한권 읽어보긴 하였으나 제대로 사용해보지 못하여 거의 머리에서 날아가 있는 상태에서 

1월에 3일동안 Hadoop 책 한권 읽고 개발을 진행한것이라 거의 초보적인 수준의 Map-Reduce 프로그램이고 

성능 또한 고려하지 않아.. 튜닝의 여지도 많은 상태임에는 분명..

그리고, 일별 데이터가 뭐 수백기가까지는 안되는 상황이라 분석 속도가 크게 빨라지지는 않았지만

일별,월별 그리고 사용자가 임의로 요청한 기간동안의 집계를 하둡을 사용해서 가져오도록 (정확히는 Pig나 뭐 그런거겠지만..) 고려를 하고 있어서 일단 Hadoop의 사용은 괜찮은 것 같다.


초보적인 관점에서 AS-IS, TO-BE의 느낌을 보면..


AS-IS (Oracle+Lucene)

1. 보관된 데이터의 핸들링이 어려움 (CRUD)

2. 일별로 집계되는 데이터를, 특정 기간동안 혹은 월별/ 년도별로 만들기가 조금 난해.

3. 특정 키워드등에 대한 검색은 굉장히 좋음 (원래 검색엔진이니..ㅋㅋ)

4. 스킴이 자유로워서 항목을 추가하기 쉬우나, 그만큼 관리도 어려워짐 (이건 설계가 잘못된 문제일수도..)

5. 파싱된 RAW 데이터가 Oracle DB에 있다보니, 운영을 위한 다른 데이터를 얻기가 쉬움 (N초 이상 쿼리등)

6. 분석되어 있는 데이터로부터 2차 가공된 데이터 혹은 2차 가공을 위한 데이터를 얻어내기가 번거로움


TO-BE (Hadoop+MySQL)

1. 분석 - 조회가 완전히 나눠짐.

2. 분석 항목이 약 2배정도 늘어남 (기존에는 성능문제등으로 하지 못 했던.. 의미있는 데이터인지에 대한 검증은 필요)

3. 하둡으로의 분석 속도도 괜찮으나, 분석된 항목이 많아 MySQL로 데이터를 export 할 때 Sqoop의 효율성이 좀 떨어짐. 분석은 몇분 안걸리는데 export 시간이..--; (다소 데이터가 작고 많은 테이블에 대해서는 효율이 좀 떨어지는듯.. 대량 데이터 전송은 속도가 아주 좋았음. 이건 각 sqoop 실행 shell을 백그라운드로 돌리면 좀 더 나을지 테스트 해보려고 함)

4. 조회 페이지에 대한 유지보수가 간단해짐 (일반적인 DB를 사용한 웹어플리케이션)

5. Map-Reduce 프로그래밍이 처음이라서 로그를 보거나 디버깅하는데 상당히 헤맸음.. 


개발자 입장에서는 꼭 필요한 업무를 사용하고 싶었던 라이브러리등을 사용하여 구축해봤던 부분에서는 만족...