로그 보관 기간(Retention)을 1년에서 6개월로 줄이면 저장 비용을 낮출 수 있다. 삭제한 로그는 복구할 수 없다.
하루 수백 TB를 수집하는 환경에서는 보관 기간이 비용에 직접 영향을 준다. 비용과 조사 가능성을 함께 보고 기간을 정해야 했다.
먼저 어떤 로그를 누가 왜 찾는지 확인했다. 그 답이 있어야 1년을 유지할 로그와 6개월 뒤 지워도 되는 로그를 나눌 수 있었다.
오류 로그는 문제가 발생한 사용자의 흐름을 추적할 때 필요하다. 시간이 지난 뒤 접수된 문제라면 오래된 로그를 다시 볼 수도 있다.
정보성 로그는 달랐다. 운영 상태를 설명하기 위해 반복해서 남기는 로그가 많았다. 짧은 기간에는 장애 분석에 도움이 되지만 시간이 지날수록 다시 조회할 이유가 줄어들었다.
접속 기록과 감사 로그도 별도로 봐야 했다. 이 로그의 보관 기간은 장애 분석의 필요만으로 정할 수 없다. 보안 정책과 감사 요건이 함께 적용될 수 있다.
모든 로그를 1년간 보관하면 정책은 단순해진다. 대신 목적이 다른 데이터에 같은 비용을 지불하게 된다. 반대로 전체 보관 기간을 6개월로 줄이면 비용은 줄지만 오래 남겨야 하는 로그까지 함께 사라진다.
오래된 로그가 거의 조회되지 않는다는 이유만으로 삭제해도 된다고 결론 내릴 수는 없다. 자주 찾지 않아도 한 번의 감사나 사용자 문제를 확인하는 데 꼭 필요한 로그가 있다.
6개월이 지난 로그를 누가 조회했고 어떤 문제를 해결했는지 확인했다. 조회 건수는 보관 기간을 검토하는 근거로 썼다. 건수가 적어도 감사나 사용자 문제를 확인하는 데 필요하다면 남겨야 했다.
다음 질문을 함께 확인해야 했다.
- 같은 사실을 메트릭이나 트레이스로 확인할 수 있는가
- 원본 로그가 없으면 사용자 문제를 재구성할 수 없는가
- 법무와 보안 및 감사 기준에서 요구하는 기간이 있는가
- 오래 보관할 로그를 더 작은 범위로 분리할 수 있는가
보관 기간
전체 로그에 같은 기간을 적용하지 않기로 했다.
오류가 난 사용자를 추적하는 데 필요한 로그는 오래 보관한다. 반복해서 쌓이는 정보성 로그는 더 짧게 보관한다. 접속 기록은 정해진 보안 기준을 따르고 감사 로그의 보관 기간은 담당 조직과 별도로 합의했다.
Loki에서는 조회에 쓰는 라벨로 로그를 구분할 수 있다. 이 라벨을 기준으로 보관 기간을 다르게 적용할 수 있어 로그별 보관 정책을 나누기 쉬웠다.
6개월이라는 숫자보다 비용을 줄여도 되는 로그와 오래 남겨야 하는 로그를 나누는 기준이 필요했다.
보안과 감사 요건
보관 기간을 바꾸면 데이터가 영구적으로 삭제된다. 저장소 설정만 바꾸고 끝낼 수 없었다.
그래서 변경 전에 보안 담당 조직과 보존 대상을 확인해야 했다. 어떤 로그를 얼마나 남길지 합의한 내용도 티켓으로 기록해야 했다. 나중에 감사 기준을 확인할 때 당시의 판단 근거가 남아 있어야 했기 때문이다.
이 과정 없이 플랫폼 팀이 비용만 보고 기간을 줄이면 문제가 생겼을 때 결정을 설명할 수 없다. 반대로 보안 요구를 이유로 모든 데이터를 무기한 남기면 비용을 검토할 기회가 사라진다.
로그를 오래 보관하면 조사할 수 있는 시간은 늘어난다. 그렇다고 보관 기간이 길수록 Reliability가 같은 비율로 좋아지는 것은 아니다.
Reliability에 필요한 것은 장애가 발생했을 때 원인을 확인할 수 있는 데이터다. 감사에 필요한 것은 정해진 기간 동안 변경과 접근의 흔적을 증명할 수 있는 데이터다. 두 목적을 구분하지 않으면 가장 긴 요구사항이 모든 로그에 적용된다.
그래서 오래된 로그의 조회 이력과 보안·감사 요건을 함께 확인했다. 조사나 감사에 필요한 로그는 남기고 줄여도 되는 로그부터 보관 기간을 6개월로 조정하고 있다.