로그 테이블 설계 원칙

1년정도 지표처리 작업을 해오면서 느꼈던 나만의 로그 테이블 설계 원칙을 작성해본다.

 

1. LogDB에는 2차 가공 데이터는 없어야 한다.

-> DB에 박혀있는 값을 가공하여 DB에 INSERT 하는 것은 삼가야 한다.

-> 추가적인 가공이 필요한 데이터는 Tool 에서 진행하도록 한다.

 

2. 알아보기 쉽게. 간단하게 작성되어야 한다. 그렇지만 운영상에 필요한 정보는 반드시 존재하여야 한다.

-> 개발자가 LogDB를 SELECT 하는 것 만으로도 해당 로그가 어떠한 이유에서 발생한 것인지를 명확하게 알 수 있어야 한다.

-> 개발자가 생각하기에 비교적 필요없는 정보라고 할지라도, 운영상에 필요한 정보라면 반드시 남기도록 한다.

-> 특히나, 운영상에 필요한 정보가 Tool 에서 자주 요청되는 정보의 성격이라면 타협의 여지 없이 DB에 남겨야한다.

 

3. 공통 로그 포맷은 죄악이다.

-> 개발의 편의성을 위하여 모든 로그에 대해서 공통된 포맷을 사용하는 경우가 왕왕있다. 공통된 로그 포맷으로도 완벽히 제어할 수 있다면 문제는 없지만, 보통 그렇지 않다. 필요한 칼럼이 있으면 억지로 구겨넣지 말고 늘려야 한다.

 

4. 하나의 칼럼에는 하나의 정보만을 담는다.

-> 로그 시스템이 DW 이상급의 크기를 갖추지 않는다는 전제 하에, 하나의 칼럼에는 하나의 정보만을 담는 것이 좋다.

-> 개발자가 SELECT 하였을 때 WHERE 절로 바로 검색가능한 로그 포맷이어야 한다.