백엔드‐로깅, 모니터링
- 에러 추적이 어렵다.
- 휘발된다.
- 성능 저하를 유발한다.
참고: 블로그 - 왜 System.out.println으로 로깅하면 안되나요?
logback
-
JUL : 자바 기본 로깅 프레임워크
- 장점: 간단한 사용이 가능하다
- 단점: 기능적 제한, 극심한 성능 차이
출처: 스택 오버플로우 - 어째서 JUL을 쓰지 말아야 하는가?
- Log4j: 2015년 서비스 개발 문단, 2021년 취약점 문제 발생
출처: Apache Logging Service: Log4j 보안 취약성
-
Log4j2: 성능적 개선 - 필터링 기능, 자동 리로딩 지원
- Multi Thread 환경에서 logback보다 18배 많은 처리량과 짧은 대기 시간을 제공
출처: Apache Logging Service: Log4j2
-
Logback사용- ⭐️ 스프링 자동 지원
- log4j2를 제외하면 성능 차이가 크지 않음
- 적용이 간단하기 때문에 간단한 프로젝트에 적합함
현재 피드백 처리 코드 중 '키워드' 로직은 웹 클라이언트와 서버가 통신하며 서로의 값이 동일한지 검증하고, 동일하지 않다면 예외가 발생합니다.
프로덕션 서버 적용 이후 실제 서비스 중 해당 로직과 관련된 잦은 수정이 발생할 가능성이 있어 DEBUG 로 분류했습니다.
또한 커스텀 예외는 프로젝트 플로우 상 오류가 아닌 '서버가 의도한 상황'으로 처리합니다.
따라서 해당 상황 또한 DEBUG 로 분류하고, 차후 ExceptionType 에 따라 분기를 나누는 경우를 고려할 생각입니다.
실제 유저가 제기할 CS를 고려하였을 때
사용자로부터 문의/복구 요청이 들어온다면 대부분의 경우 해당 정보들이 필요할 것으로 예상되어 INFO 로 분류했습니다.
의도치 않은 경로로 들어온 요청은 클라이언트를 거치지 않은 비정상적인 접근이라고 판단해 WARN 으로 분류했습니다.
커스텀 에러가 아닌 의도치 않은 예외를 ERROR 로 분류했습니다.
- 오류 발생 시 빠르게 감지 가능
- 사용 용량 파악/계획 가능
- 오류 식별 & 근본 원인 분석
- 용량 최적화 & 비용 관리
출처: IBM - 모니터링
CloudWatch (AWS 제공 인프라)
현재 프로젝트는 다양한 AWS 서비스(CodeBuild, CodeDeploy, CodePipeLine, S3 등)를 활용하고 있습니다. 따라서 해당 서비스들간의 로깅, 모니터링, 알람 등 다양한 기능을 위한 대시보드를 쉽게 구성할 수 있다는 장점이 다른 프레임워크들에 비해 크다고 생각해 해당 기술을 선정했습니다.
위에 열거한 사유들을 근거로 현재 개발 서버에서는
- EC2 패킷 사용량
- EC2 CPU 사용량에 대한 지표 및 인스턴스 동작 성공 여부
- EC2 로그
- Code Build 사용량을 확인하고 있습니다.
차후 CD 과정에서 사용하는 CodePipeline, CodeBuild, CodeDeploy 에 대한 지표를 차차 추가할 예정입니다.