AOP에 정리할 겸 보다보니 log4j2에 대해서도 정리할 것이 많은 것 같아서 따로 블로그에 올리기로 하였습니다.

 

배경

logging 이란 어떤 이벤트가 일어났을 때 시스템의 상태와 작동 정보를 시간의 경과에 따라 기록하는 것을 말합니다. 로깅을 하는 것은 문제가 발생했을 때 동작을 파악해 문제를 파악, 해결하기 위해서입니다.

 

log4j2를 보기 전 log4라는 것이 있길래 읽어 보니 2015년도 개발이 중단된 로깅프로그램이였습니다. 일단은 상관 없긴 하지만 급하게 읽었으면 넘어갈 뻔 했기에 적습니다.

Logback
  • Logback은 수정 시 구성 파일을 자동으로 다시 로드할 수 있습니다.
  • 필터링 기능 제공합니다.
  • logback의 Logger클래스는 기본적으로 SLF4J API를 구현하므로 기본 구현으로 logback을 사용하여 SLF4J 로거를 호출할 때 오버헤드가 발생하지 않습니다.
  • Logback은 상세하고 지속적으로 업데이트되는 문서와 함께 제공됩니다.

https://logback.qos.ch/reasonsToSwitch.html

 

Reasons to prefer logback

Reasons to prefer logback over log4j 1.x Unless specified otherwise, when we say "log4j" we mean log4j 1.x. Logback brings a large number of improvements over log4j 1.x, big and small. They are too many to enumerate exhaustively. Nevertheless, here is a no

logback.qos.ch

 

Log4j2
  • Logback과 마찬가지로 Log4j 2는 수정 시 구성을 자동으로 다시 로드할 수 있습니다.
  • Logback과 마찬가지로 Log4j 2는 컨텍스트 데이터, 마커, 정규식 및 Log 이벤트의 기타 구성 요소를 기반으로 필터링을 지원합니다.
  • 다중 스레드 시나리오에서 비동기식 로거는 Log4j 1.x 및 Logback보다 처리량이 18배 더 높고 지연 시간이 훨씬 더 낮습니다.
  • 람다 식을 지원합니다.
  • Log4j 2 API는 최고의 성능을 제공하지만 Log4j 2는 Log4j 1.2, SLF4J, Commons Logging 및 java.util.logging(JUL) API를 지원합니다.

 

https://logging.apache.org/log4j/2.x/

 

Log4j – Apache Log4j 2

<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apa

logging.apache.org

정말 많은 내용들이 있었기 때문에 각자 대표적인 내용들만 적었습니다.

 

log4j2는 비동기식이며, 멀티스레드이기 때문에 Logback과 속도 측면에서 18배 정도 차이가 나며, 지원해주는 부분에서도 세세하게 다른 것을 느끼며 다음에는 객관적으로 선택,사용해봐야겠습니다.

'WEB-DEV > SPRING' 카테고리의 다른 글

AOP와 interceptor  (0) 2022.12.05
[Spring] Sticky Session vs Redis vs Session Clustering  (0) 2022.05.26
Sticky Session

가장 먼저 sticky session입니다.

 

Sticky Session은 말그대로 껌딱지 세션입니다.

로드 밸러싱이 되면서 로그인 세션 등 세션들이 기존과 다른 서버에 가는 것을 막고자 첫 Request에 대한 응답을 준 서버에 껌딱지 처럼 붙어있는 것을 Sticky Session이라고 합니다.

하지만 단점으로 특정 서버에만 과부화가 올 수 있다는 점, 특정 서버가 Fail 될 시 해당 서버 세션들이 소실 될 수 있습니다.

 

이러한 단점은 보완한 것이 Session Clustering입니다.

 

Session Clustering

 

여러 서버의 세션을 동일한 세션으로 관리하는 것을 Session Clustering이라고 합니다.

해당 방법은 특정 서버에서만 발생할 수 있는 문제점을 해결해주지만 이 역시 여러 단점들이 존재합니다.

여러 서버에 동일한 세션을 사용하면 오버헤드가 발생할 수 있으며, 서버 수에 비해 네트워크 트래픽이 증가하는 등 성능 저하가 발생합니다. 또한 새로운 서버를 띄울 때마다 기존에 존재하던 WAS에 새로운 서버 IP/포트를 입력하여 클러스터링 해주어야 해서 에러 발생이 생길 수도 있습니다.

그러므로 Session Clustering은 대규모보다는 소규모의 클러스터에 사용하는 것이 좋습니다.

 

In-Memory DB

 

인메모리 DB에도 여러 종류가 있습니다. 그중에서도 Redis에 대해서 알아보려고 합니다.

 

레디스는 메모리 기반의 키-값 구조의 데이터 관리 시스템입니다.

In-Memory DB로 읽기 성능 증대를 위한 서버 복제를 지원합니다. 

레디스의 장점은 value 값으로 다양한 데이터 형식을 지원하기 때문에 리스트 배열과 같은 데이터를 처리 유용하며, 리스트형 데이터 입력과 삭제가 MySql에 비해 10배 정도 빠르다는 것입니다. 

물론 단점도 존재합니다.

In-Memory 방식은 매체가 휘발성이기 때문에 갑자기 장애가 발생할 시 데이터를 유실할 수 있습니다.

 

 

 

 

 

 

'WEB-DEV > SPRING' 카테고리의 다른 글

AOP와 interceptor  (0) 2022.12.05
log4j2 vs logback  (0) 2022.11.22

+ Recent posts