Joinc Wiki: RRD를 이용한 웹로그 분석

Facebook Joinc 그룹 Joinc QA 사이트

joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.

대량 웹로그 데이터분석의 어려움

많은 통계정보들은 대게 시간축이 기준이 되는 경우가 많다. 특히 웹서비스의 경우가 더욱 그렇다. 웹서버스의 경우 웹로그를 이용해서 통계정보를 내는 경우가 많은데, 이때 문제가 되는 것은 로그의 양이 될 것이다.

로그의 양이 그리 많지 않다면야 RDBMS에 그냥 insert 한다음에 주기적으로 select해서 통계 데이터를 만들면 되겠지만, 하루에 쌓이는 로그의 양이 기가바이트쯤 된다고 하면, 로그를 저장하고 꺼내는 것 자체가 문제가 된다. 분석은 더 말할 필요도 없을 것이다. 로그 분석을 위한 데이터 마이닝 기법들은 그 자체가 하나의 연구분야이기도 하다.

혹시라도 빠른 분석정보의 출력을 원한다고 하면, 해야할 일이 보통 많은게 아니다. 임의의 페이지에 대한 1년간의 방문추이정보, 임의의 유저의 1년동안의 활동정보, 검색어의 사용추이 등의 통계정보를 만들어야 한다고 생각해보라. 경험많은 개발자라면, 방법이야 생각해낼 수 있겠지만, 매우 복잡하고, 많은 시스템자원과 시간이 소비되는 일일 거라는 건 미루어 짐작할 수 있을 것이다.

RRD의 사용

RRD(Round Robin Database)는 다양한 범위의 시간을 축으로 가지는 (한정된 크기를 가진)환영큐로 이루어진 형식의 데이터 베이스다.

예를들어서 PV에 대한 통계정보를 만드는 RRD는 다음과 같이 구성될 것이다.

5분간의 PV를 가지는 한시간짜리 테이블 : 단지 12개의 저장공간만 가지고 있으면 된다.
만약 12개의 공간을 다채우게 되면, 12개의 평균을 낸다음.. 1시간짜리의 평균데이터를 가지는 RRD 테이블에 값을 채워 넣는다. 이제 다시, 테이블의 처음으로 가서 5분 데이터를 써넣기 시작한다. 즉 테이블의 크기는 12개로 제한된다. 말그대로 테이블 형 테이터베이스
한시간이 최소간격이 되는 이 테이블을 24의 크기를 가지게 하면, 하루의 평균데이터를 가지게 될 것이다.

대략 다음과 같은 형식이다.

최소한의 크기로 1시간 평균, 하루 평균, 한달의 평균의 통계데이터를 유지할 수 있음을 알 수 있다. 시간간격을 다르게 한다면, 하루, 일주, 월, 분기, 년 등 다양한 주기의 통계정보를 생성할 수 있다.

물론 RRD 방식의 테이블이 가지는 단점도 있다. Round Robin방식을 취하게 됨으로써, 원본데이터가 손실되며, 연산이된 통계정보만 쌓인다는 점이다.

하지만 이정도로도 거의 대부분의 경우에 충분한 수준의 정보를 제공해 준다.

BitTable의 사용

BigTable은 고려대상이 아니다. BigTable은 거대한 저장공간영역을 준비해서 모든 로그를 저장하고, 강력한 (분산 컴퓨터의)연산능력을 이용해서 데이터를 분석하겠다. 라는 취지에서 만들어진 데이터 저장 방식이다. 이 문서는 간단하고 필요한 정보를 얻을 수 있는 실용적로그 분석시스템의 제안을 목적으로 하고 있다. 이 목적에서 봤을 때, Bigtable은 오버 테크놀러지다.

RRD 툴의 이용

이제 위에서와 같이 테이블이 꽉차면, 자동으로 필요한 통계연산을 한다음에 다음 테이블에 적도록 하는 애플리케이션을 만들면 된다. 아주 복잡한 애플리케이션이라고 할 수는 없겠지만, 상당히 귀찮은 일임에 틀림 없다. 그렇지만 걱정할 것 없다. 이미 그러한 구현이 있다. 이름도 RRD 이다.

이 RRD툴을 이용하면 간단하게, RRD 테이블을 구성할 수 있다. 뿐만 아니라 그래프까지 그려준다.

RRD를 이용한 페이지별 통계정보

현실적인 웹로그 분석의 예를 들어보자. 만약 페이지뷰의 통계정보를 제품별로 만들어 내고 싶다면 어떻게 해야 할까. ? 가장 간단한 방법은 제품의 갯수만큼 RRD테이블을 만드는 것이다. 100만개면 100만개의 파일을 만들면 된다.

100만개라고 하면, 굉장히 많은 양 같은데, 어느 정도의 크기를 가질지 계산해보자.

하나당 5k의 크기를 가진다고 가정한다.

테이블구성에 따라 다르겠지만, 대략 5k라면, 일,주,월,년,5년 의 평균데이터를 저장할 수 있다. 최소 시간간격을 1시간으로 하는 등의 방법으로, 최적화 시킨다면 3k미만으로도 할 수 있다.
5k * 100만 하면 대략 4Gbyte 정도가 된다.

고작 5Gbyte로 100만개의 상품의 통계정보를 저장할 수 있다. 거기다가 이미 통계된 정보가 전부 들어가 있기 때문에, 매우 빠른시간 (0.수초내)에 원하는 정보를 얻어올 수 있다.

천만이라고 해도 40G밖에 안된다.

유저 & 페이지 통계 정보

단 유저별로 페이지 통계정보 혹은 검색어통계정보등을 만들려고 한다면, 문제가 약간 달라진다. 100만 유저이고 만들어질 수 있는 페이지가 10만개라고 하고, 모든 정보를 RRD로 남길려고 한다면, 280000 G의 공간이 필요하다.

이 경우에는 TOPN개의 정보만 RRD 테이블로 구성할 필요가 있다. 검색어를 예로 한다면 다음과 같다.

하루동안의 TOPN의 검색어를 남긴다. 이 테이블의 크기는 7이다.
테이블의 크기 7을 다채우면, TOPN에 대한 TOPN을 만들어서 일주일치 데이터를 만든다.
일주일치의 TOPN을 저장하는 테이블의 크기는 8개다. 즉 두달동안 각 주의 TOPN 검색어의 통계정보를 저장할 수 있다.

이렇게 할때 필요한 디스크 공간을 대략 계산해 봤다. 시간간격을 어떻게 둘것인지와 TOPN의 크기를 어느정도로 할 것인지에 따라 다를 것이다. 여기에서는 TOPN의 크기를 10으로 잡아서 계산을 했다. 검색어의 크기를 20byte로 하고, 하루, 일주일, 한달, 일년, 5년의 정보를 남긴다고 하면..

필드 하나의 크기 : 20 * 10 = 200 
(7*200)+(4*200)+(12*200)+(5*200) = 5600

약 6K로 유저의 5년치의 TOP10 검색어 정보를 남길 수 있다. 100만유저가 남긴다고 하면, 5G, 1000만 유저라고 해도 50G 정도면 된다.

물론 데이터의 손실이 필연적으로 발생한다는 TOPN 통계방식의 문제점이 있기는 하다. 그러나 유저활동의 대부분이 롱테일구조, 즉 상위 10%가 전체활동의 90%를 차지한다고 볼 수 있으니 문제될게 없다고 본다. 데이터를 몽땅남길 수도 있겠지만, 내상각에 이건 '90%의 완성도에서 1%의 완성도를 높일려고, 90%를 만들기 위해서 들였던 비용의 수백배를 소비하는 그닥 가치없어 보이는 행위로 보이기 때문이다.

구글의 웹사용 서비스

구글 서비스 중에 웹사용이란 서비스가 있다. 개인의 검색어와 검새어를 통해서 방문한 페이지의 대한 통계정보를 보여주는 서비인데, RRD 스타일의 데이터베이스 환경을 구축한걸 알 수 있다. 관심있으면 한번 사용해 보기 바란다.

얻을 수 있는 장점

단점은 대략 알고 있을테니 넘어가고.

빠르다.

유저별로 100만개의 테이블을 만들었다고 가정해도, 0.1초내에 데이터,를 읽어 올 수 있다는 걸 보장할 수 있을 것이다.
작은 용량

위에서 계산했던 것처럼, 작은 용량으로 충분한 효과를 얻을 수 있다.
관리성

사이즈가 작으니 관리하기도 편하다. 간단하게 그룹화, 나누기, 백업 작업을 할 수 있다.

실제 구현 테스트는 다음번 문서에서

이글은 joinc 블로그로 발행되었습니다. 댓글은 블로그에서 입력할 수 있습니다.

뇌자극 QA 뇌자극 에러 및 수정목록 총 페이지 수 : 3224 전체 함수/용어사전 구글검색방법 구글 맞춤검색	Facebook Joinc 그룹 Joinc QA 사이트 현재위치 : 미니사이트>RRD>BigLog_Analy_RRD Tweet joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다. 대량 웹로그 데이터분석의 어려움 많은 통계정보들은 대게 시간축이 기준이 되는 경우가 많다. 특히 웹서비스의 경우가 더욱 그렇다. 웹서버스의 경우 웹로그를 이용해서 통계정보를 내는 경우가 많은데, 이때 문제가 되는 것은 로그의 양이 될 것이다. 로그의 양이 그리 많지 않다면야 RDBMS에 그냥 insert 한다음에 주기적으로 select해서 통계 데이터를 만들면 되겠지만, 하루에 쌓이는 로그의 양이 기가바이트쯤 된다고 하면, 로그를 저장하고 꺼내는 것 자체가 문제가 된다. 분석은 더 말할 필요도 없을 것이다. 로그 분석을 위한 데이터 마이닝 기법들은 그 자체가 하나의 연구분야이기도 하다. 혹시라도 빠른 분석정보의 출력을 원한다고 하면, 해야할 일이 보통 많은게 아니다. 임의의 페이지에 대한 1년간의 방문추이정보, 임의의 유저의 1년동안의 활동정보, 검색어의 사용추이 등의 통계정보를 만들어야 한다고 생각해보라. 경험많은 개발자라면, 방법이야 생각해낼 수 있겠지만, 매우 복잡하고, 많은 시스템자원과 시간이 소비되는 일일 거라는 건 미루어 짐작할 수 있을 것이다. RRD의 사용 RRD(Round Robin Database)는 다양한 범위의 시간을 축으로 가지는 (한정된 크기를 가진)환영큐로 이루어진 형식의 데이터 베이스다. 예를들어서 PV에 대한 통계정보를 만드는 RRD는 다음과 같이 구성될 것이다. 5분간의 PV를 가지는 한시간짜리 테이블 : 단지 12개의 저장공간만 가지고 있으면 된다. 만약 12개의 공간을 다채우게 되면, 12개의 평균을 낸다음.. 1시간짜리의 평균데이터를 가지는 RRD 테이블에 값을 채워 넣는다. 이제 다시, 테이블의 처음으로 가서 5분 데이터를 써넣기 시작한다. 즉 테이블의 크기는 12개로 제한된다. 말그대로 테이블 형 테이터베이스 한시간이 최소간격이 되는 이 테이블을 24의 크기를 가지게 하면, 하루의 평균데이터를 가지게 될 것이다. 대략 다음과 같은 형식이다. 최소한의 크기로 1시간 평균, 하루 평균, 한달의 평균의 통계데이터를 유지할 수 있음을 알 수 있다. 시간간격을 다르게 한다면, 하루, 일주, 월, 분기, 년 등 다양한 주기의 통계정보를 생성할 수 있다. 물론 RRD 방식의 테이블이 가지는 단점도 있다. Round Robin방식을 취하게 됨으로써, 원본데이터가 손실되며, 연산이된 통계정보만 쌓인다는 점이다. 하지만 이정도로도 거의 대부분의 경우에 충분한 수준의 정보를 제공해 준다. BitTable의 사용 BigTable은 고려대상이 아니다. BigTable은 거대한 저장공간영역을 준비해서 모든 로그를 저장하고, 강력한 (분산 컴퓨터의)연산능력을 이용해서 데이터를 분석하겠다. 라는 취지에서 만들어진 데이터 저장 방식이다. 이 문서는 간단하고 필요한 정보를 얻을 수 있는 실용적로그 분석시스템의 제안을 목적으로 하고 있다. 이 목적에서 봤을 때, Bigtable은 오버 테크놀러지다. RRD 툴의 이용 이제 위에서와 같이 테이블이 꽉차면, 자동으로 필요한 통계연산을 한다음에 다음 테이블에 적도록 하는 애플리케이션을 만들면 된다. 아주 복잡한 애플리케이션이라고 할 수는 없겠지만, 상당히 귀찮은 일임에 틀림 없다. 그렇지만 걱정할 것 없다. 이미 그러한 구현이 있다. 이름도 RRD 이다. 이 RRD툴을 이용하면 간단하게, RRD 테이블을 구성할 수 있다. 뿐만 아니라 그래프까지 그려준다. RRD를 이용한 페이지별 통계정보 현실적인 웹로그 분석의 예를 들어보자. 만약 페이지뷰의 통계정보를 제품별로 만들어 내고 싶다면 어떻게 해야 할까. ? 가장 간단한 방법은 제품의 갯수만큼 RRD테이블을 만드는 것이다. 100만개면 100만개의 파일을 만들면 된다. 100만개라고 하면, 굉장히 많은 양 같은데, 어느 정도의 크기를 가질지 계산해보자. 하나당 5k의 크기를 가진다고 가정한다. 테이블구성에 따라 다르겠지만, 대략 5k라면, 일,주,월,년,5년 의 평균데이터를 저장할 수 있다. 최소 시간간격을 1시간으로 하는 등의 방법으로, 최적화 시킨다면 3k미만으로도 할 수 있다. 5k * 100만 하면 대략 4Gbyte 정도가 된다. 고작 5Gbyte로 100만개의 상품의 통계정보를 저장할 수 있다. 거기다가 이미 통계된 정보가 전부 들어가 있기 때문에, 매우 빠른시간 (0.수초내)에 원하는 정보를 얻어올 수 있다. 천만이라고 해도 40G밖에 안된다. 유저 & 페이지 통계 정보 단 유저별로 페이지 통계정보 혹은 검색어통계정보등을 만들려고 한다면, 문제가 약간 달라진다. 100만 유저이고 만들어질 수 있는 페이지가 10만개라고 하고, 모든 정보를 RRD로 남길려고 한다면, 280000 G의 공간이 필요하다. 이 경우에는 TOPN개의 정보만 RRD 테이블로 구성할 필요가 있다. 검색어를 예로 한다면 다음과 같다. 하루동안의 TOPN의 검색어를 남긴다. 이 테이블의 크기는 7이다. 테이블의 크기 7을 다채우면, TOPN에 대한 TOPN을 만들어서 일주일치 데이터를 만든다. 일주일치의 TOPN을 저장하는 테이블의 크기는 8개다. 즉 두달동안 각 주의 TOPN 검색어의 통계정보를 저장할 수 있다. 이렇게 할때 필요한 디스크 공간을 대략 계산해 봤다. 시간간격을 어떻게 둘것인지와 TOPN의 크기를 어느정도로 할 것인지에 따라 다를 것이다. 여기에서는 TOPN의 크기를 10으로 잡아서 계산을 했다. 검색어의 크기를 20byte로 하고, 하루, 일주일, 한달, 일년, 5년의 정보를 남긴다고 하면.. 필드 하나의 크기 : 20 * 10 = 200 (7200)+(4200)+(12200)+(5200) = 5600 약 6K로 유저의 5년치의 TOP10 검색어 정보를 남길 수 있다. 100만유저가 남긴다고 하면, 5G, 1000만 유저라고 해도 50G 정도면 된다. 물론 데이터의 손실이 필연적으로 발생한다는 TOPN 통계방식의 문제점이 있기는 하다. 그러나 유저활동의 대부분이 롱테일구조, 즉 상위 10%가 전체활동의 90%를 차지한다고 볼 수 있으니 문제될게 없다고 본다. 데이터를 몽땅남길 수도 있겠지만, 내상각에 이건 '90%의 완성도에서 1%의 완성도를 높일려고, 90%를 만들기 위해서 들였던 비용의 수백배를 소비하는 그닥 가치없어 보이는 행위로 보이기 때문이다. 구글의 웹사용 서비스 구글 서비스 중에 웹사용이란 서비스가 있다. 개인의 검색어와 검새어를 통해서 방문한 페이지의 대한 통계정보를 보여주는 서비인데, RRD 스타일의 데이터베이스 환경을 구축한걸 알 수 있다. 관심있으면 한번 사용해 보기 바란다. 얻을 수 있는 장점 단점은 대략 알고 있을테니 넘어가고. 빠르다. 유저별로 100만개의 테이블을 만들었다고 가정해도, 0.1초내에 데이터,를 읽어 올 수 있다는 걸 보장할 수 있을 것이다. 작은 용량 위에서 계산했던 것처럼, 작은 용량으로 충분한 효과를 얻을 수 있다. 관리성 사이즈가 작으니 관리하기도 편하다. 간단하게 그룹화, 나누기, 백업 작업을 할 수 있다. 실제 구현 테스트는 다음번 문서에서 이글은 joinc 블로그로 발행되었습니다. 댓글은 블로그에서 입력할 수 있습니다.