사내에서 로그를 Error 수준으로만 보내고 있었다. 그래서 CS가 들어오는 경우에 확인할 방법이 DB 말고는 없었다. 즉, 로그가 잘 찍히지 않은 상태였다. 그래서 로깅하는 것을 보완하게 되었다.
로그 레벨 설정
- info: 특정 이벤트 CS 업무가 많이 들어오거나 데이터로 활용 가능해서 의미 있다고 생각하는 부분은 Info 수준으로 남겼다.
- warn: 만약 5번 이상이거나 몇 분간 지속적으로 발생된다면 문제가 생길 것 같은 부분에는 warn 레벨로 설정하였다.
- error: 즉각적으로 인지하거나 해결해야 하는 부분에는 error를 달게 되었다.
Logback
logback부터 먼저 손을 보았다. logback이 환경별로 구분되지 않은 상태였다. 이를 dev, prod 환경으로 나누었고, 메인 logback이 있으면 재활용이 가능하다.
네트워크 통신으로 CloudWatch 로그를 못 보낸다면?
이런 경우를 대비하여 console에도 남기게 되었다. 운영 환경에서는 모두 남기면 성능 문제가 있다고 하는데, 불필요한 부분만 그런 거 같고 찍어도 괜찮을 부분은 상관없다고 생각한다. 더해서 사내에서 console로 남기면 이를 더 활용하는 방법에 대해서 이야기해서 팀 내부적으로 console에도 찍기로 결정했다. 그리고 네트워크 통신문제로 CloudWatch에 보내지 못한다면 로그가 유실되는데 이런 경우를 방지하기 위함이다.
서버 비용
서버의 로그를 CloudWatch와 연동하여 쌓고 있다. 하지만 CloudWatch 내 저장 로그가 많을수록 비용이 커지기 때문에, 기간이 지난 로그를 S3로 이관할 계획이다. 그 중 저장소는 S3를 선택했다.
큰 구현 틀 (서버리스 로그 아키텍처)
- CloudWatch에 로그를 적재하는데 일정 기간만 저장하고 삭제하도록 한다.
- 삭제되기 전 로그는 S3로 이관해서 보관한다.
- Lambda를 사용해 CloudWatch에 있는 로그를 S3로 이관시킨다.
- S3에 있는 로그를 레벨별, 환경별로 나누어 보관한다.
- 기간이 지나면 Glacier 정책을 통해 이동시킨다.
- Lambda 트리거로는 EventBridge Scheduler를 사용한다.
- IAM 권한 관리: 보안 설정 및 접근 제어.
- 비용 절감 경험: 로그 수집, 저장 비용 최적화 사례.
주의사항
- IAM 권한으로 버킷 권한 설정: 왜냐하면 로그는 외부에서 접근 불가능해야 하기 때문이다.
- json 형식으로 저장하기: 주로 json 형식으로 저장하면 추후에 이로운 점이 있다고 생각한다.
장점
- 로그 유실 방지: 지금까지 로그 저장을 2주만 하고 사라지게 되었는데, 이를 보관할 수 있다.
- 서버리스로 매번 작동하지 않아도 되기 때문에 비용 절감.
- CloudWatch 비용 절감.
단점
- 관리 포인트 증가? Lambda 코드 관리인데, 한 번 사용하면 수정하는 경우가 드물다고 생각한다.
- Lambda 함수의 단점들? ColdStart, 디버깅 어려움.
