- 실시간 대용량 데이터 입력. 이제 장비들도 기가비트 시대라 로그 나오는 양이 말도 못 한다. 좀 규모 있는 웹사이트 돌려보면 웹 로그만 해도 양이 장난이 아닌 것을 많이 봤을 것이다. DW 할 때처럼 일단 쌓아놓고 나중에 배치 처리 한다면야 어떻게든 가능하겠지만 관제시스템의 경우에는 실시간을 요구한다.
- 일반적인 응용과 달리 검색 쿼리의 비중이 매우 작음. 일반적인 DB들은 검색 쿼리 최적화 쪽에 집중한다. 하지만 로그는 실시간으로 대량으로 쏟아지는데 비해 검색은 주로 관제요원이 요청할 때만 이루어지기 때문에 입력 성능이 로그 관리 시스템의 성능을 좌우한다.
- 기간별 풀텍스트 검색 필요. 로그가 워낙 많으니 상세하게 조건을 걸어야 원하는 로그로 범위를 좁힐 수 있다. 그런데 상용 DB에서 풀텍스트를 지원하긴 하는데 풀텍스트 걸어놓고 입력 성능이 잘 안 나올거다. (이런 조건 하에서 테스트는 안 해봤지만 일반적인 inverted index 구조로 구현됐다면 나오기 어려울 것) 그렇다고 모든 컬럼에 인덱스를 걸 수도 없고 인덱스가 많을수록 입력 성능이 떨어진다. 주로 IP나 포트 등 가장 흔하게 사용되는 컬럼에만 인덱스를 걸게 된다. 다른 컬럼을 조건 걸어 검색하면 먹통된다. 이러니 차라리 텍스트 파일로 로그 쌓고 grep 쓰면 정규표현식이라도 먹지 않냐는 한숨이 나오는 것이다.
- 반정형(semi-structured) 포맷. RDBMS에서 쓰이는 테이블에 맞추려면 로그를 정규화하고 어쩔 수 없이 버리거나 비고 컬럼에 우겨넣어야 하는데 이것도 문자열 길이 제한이 있으니 잘리기도 하고 막상 나중에 로그 조회해보면 난감한 경우가 많이 발생한다. 게다가 컬럼의 추가/삭제가 발생하는 경우 기존에 이미 존재하는 방대한 양의 데이터를 변환해야 하는 문제가 발생한다.
- 수정이나 삭제 없음. 로그의 경우 수정이 불가능해야만 하고 (변조 가능성 때문에 WORM 미디어에 실시간으로 굽는 장비도 있다.) 삭제는 오래된 데이터에 한해서 기간별로만 이루어지지 중간에 한 두 줄만 지우는 경우는 없다.
DB별로 벌크/배치 로딩하는 방법들은 있으나, 오프라인 상태를 가정하고 밀어넣는 경우이거나 온라인이더라도 검색 같이 들어가면 망하거나 별다른 인덱스가 없는 상태에서 제시된 성능이라 실제로는 문서에서 얘기하는 성능이 나오지 않는다. 여기에 인덱스가 메모리에 못 올라갈 수준으로 커질 수도 있다. (이 경우 디스크 성능에 크게 영향 받는다.) 안타깝지만 예전에 SQL 서버를 기반으로 만들었던 시스템의 경우 방화벽 로그가 DB에 쌓아지긴 하는데 검색은 거의 불가능한 수준이었다.
로그 DB는 로그 관리에 특화된 데이터베이스로 위에서 열거한 문제들을 해결한다. 초당 수만 건 단위의 입력 성능 보장, 대용량 풀텍스트 검색 요청에 대한 초 단위 응답, 기간별 고속 삭제/백업 및 온라인 전환, 실시간 압축 저장 등의 기능을 제공한다. 인덱스 방식이나 데이터 레이아웃 등 전부 로그 관리에 맞추어져 있다. 풀텍스트 쿼리가 완료 될 때까지 무한정 차단되는게 아니라 비동기 콜백으로 검색 조건과 일치하는 로그를 실시간으로 받아낼 수 있다.
크라켄 기반에 로그 DB가 올라가는데 여기에 사용자 정의 모듈을 같이 올리게 되면, 마치 SQL 서버나 오라클에서 제공하는 기능처럼(예를 들어 닷넷 어셈블리를 스토어드 프로시저에서 호출) 물리적으로 데이터에 가장 가까운 위치에서 자바 기반으로 절차적 데이터 처리를 빠르고 쉽게 할 수 있다. 네트워크 통해서 자바로 데이터 로딩해다가 배치 처리해 본 사람은 얼마나 느린지 다 알 것이다. 로그 DB는 데이터를 원래 자바 객체로 다루기 때문에 별도로 변환하는 오버헤드도 없다.
덧글
Kevin 2010/03/22 18:51 # 삭제 답글
오... 그렇군요. 경험에서 우러나오는 이런 사골국물 같은 정보를 주셔서 고맙습니다. :)(네, 사골에 환장하는 인간입니다...ㅡ_ㅡ; )
로그 파일을 그렇게 대용량으로 수집해 본적이 없어서,
뭐 결국 로그 수집을 계속하다보면 언제가는 겪게 될 문제점일텐데,
그냥 미뤄둔것일뿐...
심각하게 고민해 보지 않았던 내용이 대부분이군요.
정말 좋은 내용입니다.
아, 그리고 지난번 DB글에서 하려고 했던말은,
꼭 필요하다면, 이미 있는걸 가져다 쓰는것만을 무조건 고집할것이 아니라
만들어서 쓸수도 있어야 하는거 아닌가 라는 그런 의미였습니다.
무작정 다 만들어 쓰는게 최고! 라는 뜻은 아니었구요. :)
그나저나 요즘은 NoSQL 인기가 많아지는거 같습니다.
최근 digg.com 과 Twitter가 MySQL을 버리고 Cassandra 를 쓰게된것도 그렇고...
뭐 Google 이야 원래 자기들이 개발한 BigTable을 쓰고 있고...
암튼 엔초비의 로그 DB, 멋집니다! :)