Spring Logging System

👣 개요

Logging은 프로그래밍에 있어서 매우 중요한 역할을 차지한다.
Logging은 어플리케이션의 안정성, 성능, 보안 등 다양한 측면에서 활약을 할 수 있는데,
다음과 같은 사례에서 사용될 수 있다.

1. 디버깅과 오류 분석
   프로그램이 실행 중에 발생하는 오류나 예외를 기록하면, 이후에 오류의 원인을 분석하고 디버깅하는데 도움이 된다. 오류 로그를 살펴봄으로써 어떤 상황에서 오류가 발생하는지, 어디에서 오류가 발생했는지를 확인할 수 있다.
   
   
2. 성능 최적화
   로깅을 통해 프로그램의 성능을 평가하고 최적화하는데 도움을 준다.
   예를 들어, 어떤 함수가 느리게 실행되고 있는지, 얼마나 자주 호출되는지 등을
   로그로 기록하여 성능에 대한 통찰을 얻을 수 있다.
   
   
3. 보안 감시
   보안 관련 로그를 남겨서 시스템의 보안 상태를 모니터링하고 이상 동작을 감지하는데 활용할 수 있다.
   로그를 통해 불법적인 접근 시도를 파악하거나, 보안 취약점을 식별하는데 도움이 된다.
   
   
4. 사용자 활동 추적
   어플리케이션의 사용자 활동을 추적하기 위해 로그를 기록할 수 있다.
   사용자들의 행동 패턴을 파악하거나 특정 기능의 사용 빈도를 파악하는데 도움이 된다.
   이는 차후에 비즈니스적 판단의 근거로 사용된다.

 

👣 Log4j, Logback, Log4j2

log4j -> logback -> log4j2 순서로 등장하였고,
logback, log4j2는 둘 다 log4j를 기반으로 하고 있어
설정하는 방법이나 사용 방법이 유사합니다.

Log4j
Log4j는 Apache Software Foundation에서 개발한 로깅 라이브러리로,
Java 애플리케이션의 로깅을 위해 널리 사용되곤 했다.
2015년 개발이 중단되었고 때문에 최근에 잘 사용되지 않는다.

Logback
SLF4J의 기본 구현체로 사용되는 로깅 라이브러리.
Logback은 Log4j의 후속 제품으로서, 더 높은 성능과 간편한 설정을 갖춘 로깅 구현체.
Logback은 Log4j의 기능을 대부분 지원하며, 더 나은 성능과 설정 유연성을 제공하여 Log4j 대신 많이 사용된다.

Log4j2
Log4j 2는 Log4j 1.x에서 발생한 몇 가지 제약 사항과 성능 문제를 개선하였으며, 다양한 기능과 유연성을 제공함.
SLF4J와 결합하여 사용할 수 있다.
logback과의 가장 큰 차이점은 Multi Thread 환경에서 비동기 로거(Async Logger)의 경우
log4j, logback 보다 처리량이 더 높고, 대기 시간이 훨씬 짧다. 
다만 비교적 최근 Log4j2의 보안 취약점이 드러나 이러한 점을 유의하며 사용해야 한다.

아래 보안 취약점에 대해 간단하게만 언급하면 해커가 서버의 Shell 마냥
최고 관리자 권한으로 조작을 할 수 있다는 것이다.

Log4j 2 원격코드 실행 취약점(CVE-2021-44228) 대응방안

 

👣 Logging Facade

Logging Facade란 쉽게 말해 복잡한 Logging 라이브러리를 단순화한 인터페이스다.
때문에 구현체의 복잡한 구조를 이해하지 못해도 쉽게 사용할 수 있게 하는 인터페이스이다.

Spring Framework에서는 2 가지의 Logging Facade를 사용하고 있다.

1. JCL - Jakarta Common Logging
2. Slf4j - Simple Logging Facade for Java

👣 JCL - Jakarta Common Logging

Spring Framework이 개발될 당시 Slf4j는 개발되기 전이었기에 JCL로 로깅 시스템을 꾸려 나갔다.
해당 Logging Facade는 클래스 로더 충돌 문제와 복잡한 설정 문제가 있어서 최선의 로깅 퍼사드는 아니었다.

클래스 로더 충돌 문제는 로깅 구현체를 선택할 때 서로 다른 클래스 로더의 우선순위로 인해
의도치 않은 로깅 라이브러리가 선택되는 문제였다.
예를 들어, 한 웹 애플리케이션에서는 Log4j를 사용하고,
다른 웹 애플리케이션에서는 Logback을 사용하는 경우,
JCL의 클래스 로더 충돌로 인해 Log4j가 선택되는 경우도 발생했었다.
이로 인해 로깅 설정이 복잡해지고, 원하지 않는 로깅 시스템이 동작했다.

아래는 Commons Logging을 이용한 로그 호출 방법이다.
Slf4j와는 달리 문자열 연산을 하고 로깅을 하는 방법을 사용한다.

👣 SLF4J - Java Simple Logging Facade for Java

Spring은 버전이 업데이트되면서 Jakarta Common Logging을 SLF4J로 대체하고 있다.
SLF4J는 JCL과 비교하여 성능 면에서 더 효율적이며, 더욱 유연하고 간단한 설정을 제공한다.
SLF4J는 로깅 라이브러리를 바꿔가며 테스트하거나 배포할 때 더 편리한 이식성을 제공하며,
다양한 로깅 시스템과 통합하기도 쉽습니다.
하지만 Spring은 여전히 호환성을 유지하기 위해 JCL도 지원하고 있다.

SLF4J는 클래스 로더 충돌 문제를 해결하기 위해 로깅 구현체와의 결합을 느슨하게 했다.
이를 위해 SLF4J는 바인딩 라이브러리를 사용하여 로깅 구현체와의 결합을 간단하게 만들었다.
바인딩 라이브러리는 SLF4J를 특정 로깅 라이브러리(예: Logback, Log4j)와 결합하는 역할을 수행하며,
SLF4J를 통해 원하는 로깅 시스템을 자유롭게 선택할 수 있게 한다.
이렇게 하면 클래스 로더 우선순위와 관계없이 원하는 로깅 라이브러리를 사용할 수 있어서
로깅 설정이 간단해지고, 의도하지 않은 로깅 구현체 선택 문제를 해결할 수 있다.

아래는 JCL에서 수행해야 했던 문자열 연산을 메서드 내부에서 실행토록 하기 때문에
불필요한 연산을 수행하지 않아도 된다.

 

👣 JCL와 Slf4j의 호환 문제

Spring Boot는 기본적으로 spring-jcl 모듈을 이용해서 로깅을 수행한다.
JCL모듈은 Spring boot starter web을 추가하면 자동으로 의존성이 추가된다.
JCL를 통해 Slf4j의 API를 호출하기 위해 Spring Boot에서는 브릿지를 사용한다.

다만, 요즘은 Lombok을 이용해 Slf4j API를 직접 호출한다고 한다.