최근에 회사 다니면서 로그을 남겨야하는 어느 시점에 남겨야 좋은 로그에 대해서 공부하고 있다
'좋은 로그'가 무엇인가?
좋은 로그 설명하기 전에 '로그'에 대해서 용어 정의 할려고 합니다.
로그란 이벤트에 대한 기록이고 이번 작성한 글에서는 '서비스 로그'를 대상으로 합니다
서비스 수준에서 일어나느 상태변화나 유저의 행동에 대한 기록
즉 다시 말해 유저의 CS에 대응하기 위해 남기는 서비스 로그라고 생각하시면 됩니다.
예시) 유저의 입장 및 퇴장, 아이템 구매 , 획득 및 사용
좋은 로그 3가지 사항이 있습니
- 필요한 정보가 있다.
- 의미가 명확하다.
- 편리하게 데이터를 얻을 수 있다.
위에 3가지 사항 간단해 보일 수 있는데 현실은 그렇지 않은 경우가 많습니다.
하지만 겪어 봤을 만한 문제들
- 필요한 정보가 없다
예) 꼭 필요하면 없더라 , 왜 이 이벤트에는 있는데 저 이벤트에는 없지? - 의미를 파악하기 어렵다
예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? - 편리하게 데이터를 얻을 수 없다
예) 값에 여러 데이터가 함계 포함되어 있어서 매번 가공 처리를 해야하는 경우
왜 항상 비슷한 문제를 겪을까?
- 로그에 대한 작업 우선순위가 일반적으로 높지 않음
- 설계에 대한 충분한 고민 없이 일단 남기는데 집중
- 무엇을 고려해야 할지 모름
- 합의된 규약이 없음
- 로그 품질을 지속적으로 관리하지 않음
문제가 발생하는 시점
- 필요한 데이터를 얻지 못하거나 , 큰 비용이 들게 됨
이미 지나간 시간의 정보를 차는 것은 불가능하거나 힘듦
- 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생
기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적
초기 '좋은 로그'의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움
대부분 공유된 자료는 여기까지의 이야기
- 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음
- 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦
- 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함계 고민해야 달성할 수 있는 가치
공유가 필요하다
'좋은 로그'를 위해 고려해야 할 사항
- 필요한 정보가 있는 로그
- 목표가 있는 로그
- 목표를 한문장으로 정의
예) 재방문율 집계가 필요하다 - 하나의 지표에 대해서 다양한 각도의 고민
예) 후추 재방문율 집계시 '국가별', '레벨별','직업별' 필터링이 필요할 것이 - 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의
예) 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려
- 목표를 한문장으로 정의
- 일관성(같은 구성요소에 대하여 같은 항목들을 가지는것)
- 믿을 수 있는 로그
- 로그가 의도한 시점에서 발생했을 것이라는 믿음
- 의도한 대로 데이터가 남았을 것이라는 믿음
- 의도한 것과 다른 데이터가 남을 수 있는 가능성
- 어뷰징에 의한 변조 가능
- 100%는 아니더라도 납득할 수 있는 수준의 믿을 위한 노력이 필
- 목표가 있는 로그
2. 의미가 명확한 로그
- 의미를 충분히 표현할 수 있어야 함
- 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음
- 때문에, 길더라도 구체적인 이름을 사용
- 다른 의미와 혼동될만한 가능성을 피할 수 있다
- 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다
- 이름을 정의하기 위한 취소 규약 정
3. 편리하게 데이터를 얻을 수 있는 로그
4. 그 외 다른 관점에서 고려해봐야 할 것들
앞으로 나올 단어들
- 로그 - 이벤트에 대한 기록
- 항목 - 로그에 포함될 각각의 데이터
이벤트를 구별하는 기준
1. <상태>의 시작,<상태>의 종료
- 상태의 시작과 종료를 이벤트로 분류하는 구조
- 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음
- 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합
2. <상태> 업데이트
로그 항목에서 상태변화의 종류를 알 수 있는 구조
아래의 경우에 좀 더 편리하게 분석할 수 있음
1. 같은 구성요소에 대해 상태만 변한다.
2. 항목 구성이 거의 비슷하다.
3. 이력의 변화가 중요하다.
이벤트를 구별하는 기준
한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함
특정 이벤트에 대한 내용이 변경될 수 있음
이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음
데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있
표현력
약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다
- 저장 비용은 크지않고, 경우에 따라 압축이 가능하다
- 득보다 실이 많을 수 있다
경우에 따라 데이터 타입에 대한 고려 또한 필요
- 소수점 표현, 숫자 범위
빈 값의 의미를 명확하게
1. 빈 값은 다양하게 해석될 수 있음
- 해당 항목에 대한 정보가 아예 존재하지 않은 경우
- 실제 값이 빈 값이 경우
2. 명확하게 하는 것에 의의
로그 품질 관리를 위해 해야 할 사항
로그 형식
1. 서비스 로그는 특정 항목에 대한 접근이 필요한 경우가 많음
2. 필요한 요소
- 컴퓨터가 읽기 쉽도록 구조화된 형식
- 사람이 읽을 수 있는 형식
3. 일반적으로 많이 쓰이는 형식
- JSON, key/value
로그의 문서화
다음 내용에 대한 기록이 필요하다
- 로그의 목표와 의미
- 로그의 정확한 발생 시점
- 각 항목들의 의미와 데이터 타입
- 항목의 추가/변경/삭제 이력
- 특이사항 기록(발생 일시 , 내용)
- 로그가 사용되는 곳
- 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음
- 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음
로그 유실 모니터링
- 믿을 수 있는 로그
- 로그 유실에 대한 빠른 대응
- 특이사항 기록
- 버그 또는 시스템 인해 유실된 경우
- 언제, 얼마나, 어떤 데이터가 유실되었는지 기록
로그 추가 및 변경의 프로세스화
1. 목표 정의
- 추가(또는 변경ㅇ)의 목표를 구체적으로 정의
- 어떤 데이터가 필요한 것인지 정의
2. 관계자들의 의견을 종합하여 로그를 설계
- 관계자?
- 지표를 보는 사람들 / 만드는 사람들(분석가)
- 개발자(실제 로그에 대한 코드를 작성
- 이벤트 정의
- 지표를 어떻게 볼것인지 다양한 각도로 고민
- 필요한 항목들을 더 구체적으로 정의
- 추가 가능 여부, 한계 , 대안
- 우선순위
- 가까운 미래에 발생할 수 있는 다른 가능성 고민
- 합의된 내용을 기반으로 문서
3. 로그 추가 또는 변경 작업
4. 테스트 / QA
- 의도한 시점에 제대로 발생하는지 확인
- 의도한 형태로 남는지 확인
- 값이 정확한지 확인
5. 배포
효율적인 프로세스 진행을 위해
- 로그 설계 방식에 대하여 미리 합의된 최소한의 규약이 필요
- 자칫하면 비효율적으로 작동할 수 있는 프로세스
- 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요
- 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요