2025.01.06 - [Spring/Logging] - [Logging] 로그 출력을 효율적으로 생성 및 추적하기 7편 - Spring AOP2025.01.06 - [Spring/Logging] - [Logging] 로그 출력을 효율적으로 생성 및 추적하기 6편 - Proxy2025.01.06 - [Spring/Logging] - [Logging] 로그 출력을 효율적으로 생성 및 추적하기 5편 - Template Method2025.01.06 - [Spring/Logging] - [Logging] 로그 출력을 효율적으로 생성 및 추적하기 4편 ThreadLocal사용기2024.12.26 - [Spring/Logging] - [Logging] 로그 출력을 효율적으로 생성 및 추적하기 3편2024.12.2..

Spring AOP수 많은 문제점을 거쳐서 드디어 결론에 도달했다... 결국에는 Spring에서 제공하는 AOP의 동작방식과 강력한 지원 기능에 대해 설명하려고 달려왔던것 같았다 ㅎㅎ처음 다뤘던 내용과 같이 애플리케이션의 비즈니스 로직은 핵심 기능과 부가 기능으로 분리할 수 있다.핵심 기능은 도메인의 객체가 수행하는 고유의 기능이다.부가 기능은 핵심 기능을 보조하기위해 제공하는 기능이다. 예를 들어서 로그 추적 로직, 트랜잭션 기능 등이 이에 해당된다.핵심 기능은 각 객체의 고유 기능이기에 중복적인 수행이 아니지만, 부가 기능은 동일한 기능을 수행하기 때문에 각 도메인마다 중복되는 기능이 수행된다.객체지향적인 코드를 짜기 위해서는 중복된 내용은 하나의 추상화를 통해 공통적으로 사용할 수 있는 하나의 객체..

Proxy를 사용한 Logging우선 인터페이스 프록시와 상속을 받은 프록시 이렇게 두가지 방법으로 각 레이어에 프록시를 만들어 traceId를 출력하도록 만드는 프록시 객체를 만들어기존의 코드를 수정하지 않고도 프록시 객체가 실제 객체대신 수행되도록 만들 수 있다.하지만 단점으로는 프록시 클래스를 너무 많이 만들어야 한다는 점이다. 또한 프록시 클래스들이 하는일은 로그를 다루는 일인다 그 로직이 모두 똑같다. 그렇다면 굳이 프록시 클래스를 여러개 만들 필요가 없는것이다.이때 사용하는 것이 동적 프록시라는 기술이다.자바가 기본적으로 제공하는 JDK 동적 프록시 기술이나 CGLIB 같은 프록시 생성 오픈소스 기술을 활용하면 프록시 객체를 동적으로 만들어 낼 수 있다.하나의 프록시 객체를 생성하고 이를 동적..

이전 문제점각각의 Controller, Service, Repository에서 주요 비즈니스 로직(CRUD)이 있고, 이 활동을 확인하기 위한 부가 기능인 로깅 출력 기능을 구현했다.부가기능과 핵심 기능이 한 군데 모여 있어 가독성이 떨어지고, 코드가 복잡해지면 유지 보수하기가 어려워진다는 문제점이 발생한다.핵심 기능과 부가 기능을 분리하여 설계하는 것이 디자인적으로 더 좋은 설계라고 할 수 있다.try{ answer = userService.create(name); //핵심 기능 trace.end(status); //부가기능 }catch (Exception e){ trace.exception(status, e); //부가기능 ..

V3에서 진행했던 방식의 문제점이였던 동시성을 ThreadLocal을 사용해서 해결해보려 한다.ThreadLocal은 다른 쓰레드와 자원을 공유하지 않는 독립적인 영역이다.그러므로 동시에 수행해도 각자 같은 이름의 변수이지만 다른 객체를 사용하고 있는 것이다.큰 변동사항없이 기존에 사용했던 TraceIdHolder의 타입을 ThreadLocal로 바꿔주고 문법에 맞게 변경해준다.FieldLogTracetraceIdHolder, syncTraceId, begin, releaseTraceId에서 ThreadLocal의 get(),set()메서드를 사용하도록 수정해주면 된다.package com.example.loggingtest.global.trace;import lombok.extern.slf4j.Slf4..

Partitioning테이블은 수직적 또는 수평적으로 분할될 수 있다.수평적 분할은 테이블의 행을 기준으로 테이블을 나누고, 수직적 분할은 테이블의 열을 기준으로 테이블을 나누어 저장한다.정규화된 테이블일지라도 물리적으로 테이블의 열을 분리하여 저장하는 것이 효율적일 때가 있다.테이블에 발생하는 트랜잭션 수에 비해 테이블 내에 열이 과도하게 많거나, 특정 열에 속하는 레코드의 데이터 크기가 다른 열의 레코드에 비해 과도하게 큰 경우, 또는 보안 상의 이유로 특정 열을 별개의 테이블로 나누어 저장해야 하는 경우 수직적 분할이 필요하다.예를 들어 게시글id, title, writer, content가 있는데 content에 과도하게 많은 양의 데이터가 있어 크기가 큰 경우에는 별도의 테이블로 분리한 뒤 필요..