개요
안녕하세요.
이번 글은 Java에서 가장 많이 사용되는 logging 라이브러리 log4j2와 logback에 대해 간단히 테스트해보겠습니다.
들어가기 앞서
log
이전 글 중 로그에 대해 정리한 내용이 있어 인용하겠습니다~!
로그란 운영 체제나 다르소프트웨어가 실행 중에 발생하는 이벤트나 각기 다른 사용자의 통신 소프트웨어 간의 메시지를 기록한 파일입니다.
주로 활용하고 싶은 정보를 모으고자 작성합니다.
로그는 데이터베이스의 트랜잭션 정보, 로그인을 위한 API 호출 정보, 특정 사용자의 웹피이지 접근 등 다양한 소스에서 각종 내용을 기록됩니다.
방금 이야기한 로그들은 다음과 같은 곳에서 활용 가능합니다.
[그림01] 로그 활용 예시
Pacade Pattern
퍼사드 패턴은 프로그래밍 패턴 중 하나입니다.
이 패턴은 정교한 라이브러리나 복잡한 하위 시스템에 대한 간단한 인터페이스를 제공합니다.
간단한 햄버거 예시와 함께 알아보겠습니다.
우리는 주문앱을 통해 2가지가 가능합니다.
- 햄버거를 집으로 배달하기
- 햄버거를 매장에서 먹기
그 안에는 다음과 같은 작업이 숨어있습니다.
- 주문 받기
- 햄버거 만들기
- 매장에서 먹을 수 있도록 준비하기
- 배달할 수 있도록 준비하기
- 배달원 부르기
- 햄버거 배달하기
- …
만약 우리가 앱이 없이 배달을 원한다면 어떨까요??
직접 매장에 주문을 넣고 매장에서는 햄버거를 만들겠죠??
그러는 중 배달원을 부르고 다 만들어진 햄버거를 알려주고 이를 가져오라고 알리고,,,,,
하지만 우리는 앱을 통해 일련의 과정을 쉽게 수행할 수 있습니다.
이런 앱의 역할을 퍼사드 패턴이 수행합니다!!
하지만 퍼사드 패턴에 모든 기능을 넣는다면 혼자서 모든 작업을 수행하는 일명 god object가 되어 객체지향 프로그래밍의 기본 목적을 상실하게 됩니다.
따라서 다른 패턴과 마찬가지로 상황에 따라 적용해야합니다~!
스프링 로깅 살펴보기
log4j
자바 1.4에서 추가된 라이브러리로 가장 오래된 라이브러리입니다.
발표 당시 기본 로깅 라이브러리인 JUL(java.util.logging)에 비해 다양한 handler, format을 지원했습니다.
하지만 이를 관리하는 아파티 재단에서 2015년 이후 log4j2로의 마이그레이션을 추천하며 지원을 중단했습니다.
따라서 현재에는 찾아보기 힘든 로깅 라이브러리입니다.
만약 현재도 사용하고 있다면 몇 가지 보안 취약점을 개선한 reload4j(link)의 사용을 추천드립니다.
logback
스프링의 기본 로그 라이브러리입니다.
log4j와 비교해 자동으로 설정을 불러오며 비동기 로깅을 지원합니다.
또한 아래에서 설명할 slf4j로의 확장을 기본적으로 제공합니다.
스프링 프레임워크의 기본 로깅인만큼 아마 가장 친숙하실거라 생각합니다.
log4j2
2014년에 log4j에서 메이저 업데이트를 통해 배포된 log4j의 2버전입니다.
가장 최근에 나온 만큼 Garbage-free logging과 같은 다양한 기능이 존재합니다.
하지만 log4와 호환되지 않아 기존 사용자들이 러닝커브를 겪을 수 있다는 단점이 있다고 하는데… 저는 log4j2를 먼저 배웠기에 해당사항이 없습니다..!
번외: slf4j
slf4j는 다른 로그 라이브러리를 쉽게 사용할 수 있도록 퍼사드 패턴을 적용한 warpper 라이브러리입니다.
log4j2와 logback를 비롯해 다양한 라이브러리를 몇 가지 설정을 통해 편리하게 이용할 수 있습니다.
비교
성능 비교를 위한 준비
테스트 환경은 Sonoma(14.2.1), M1, RAM 16GB, openjdk 11.0.11, spring-boot-starter-log4j2 3.2.3, logback-classic 1.4.14입니다.
test 함수 내에서 100번의 get request를 1세트로 설정하여 0.5초 간격으로 100번의 실행을 설계했습니다.
사실 동일한 환경을 위해 1개 앱에서 2개의 로그 라이브러리의 실행을 시도했는데요.
실력 부족으로 앱을 2개 띄우는 방향이 최선이었습니다…🥲
혹시 해결방법을 알고 계신 분은 github 레포지토리에서 수정 및 PR 부탁드리겠습니다!
속도 비교
우선 속도입니다.
로그가 찍히기 시작한 시점과 끝난 시점을 비교한 결과 log4j2는 2.503초, logback은 4.247초로 약 40%의 차이를 보였습니다.
큰 차이가 나지 않을거라 기대했는데 생각보다 큰 격차를 보여줍니다.
메모리 비교
두 번째는 메모리입니다.
다음 2개 차트를 통해 살펴보겠습니다.
[그림02] log4j2 결과
[그림03] logback 결과
데이터를 확인해보면 logback의 경우 heap을 더 빠르게 점유해서 GC가 동작하는 모습을 볼 수 있습니다.
구체적인 GC 동작 횟수는 log4j2가 14회, logback이 19회로 logback이 약 25% 더 많이 동작했습니다.
각 차트의 데이터는 아래에 첨부드립니다.
결론
우선 각 실행 환경과 라이브러리의 버전에 따라 차이가 발생할 수 있다는 점 참고 부탁드립니다.
저의 경우 속도에서 큰 차이를 확인하지 못했습니다.
하지만 메모리 사용량의 경우 log4j2가 logback에 비해 25%정도 메모리를 덜 점유했습니다.
따라서 저는 log4j2를 선택했습니다.
마무리하며
이번 글에서는 스프링에서 가장 많이 사용되는 2가지 라이브러리 log4j2와 logback에 대해 알아봤습니다.
로그는 원천데이터 혹은 소스데이터의 다수를 차지합니다.
서버 모니터링, 접속 기록, 유저의 웹사이트 이동 경로 등의 데이터를 위해 다양한 형식과 형태로 수집되는데요.
정말 작은 성능의 차이라도 대규모 혹은 분산 처리 시스템에서 큰 효과 혹은 부작용을 일으킬 수 있습니다.
하지만 성능이 언제나 최선은 아닙니다.
성능은 분명 중요하지만 많은 유저풀, 높은 확장성, 기존 레거시와의 호환성 등 선택을 위한 다양한 요인 중 하나입니다.
그러므로 독자분께서는 각자의 환경에서 R&D를 진행해보시길 추천드립니다.
이 글이 조금이나마 도움이 되셨으면 합니다.
감사합니다. 😀
참고 문헌
- Facade pattern, https://en.wikipedia.org/wiki/Facade_pattern
- 퍼사드 패턴, https://refactoring.guru/ko/design-patterns/facade
- Log4j2, https://logging.apache.org/log4j/2.12.x/
- Logback, https://logback.qos.ch/
- Slf4j, https://www.slf4j.org/
- Reload4j, https://reload4j.qos.ch/
Comments powered by Disqus.