@Aspect AOP + 스프링 AOP 개념

[LeeeeDain]

섹션8 - @Aspect AOP

@Aspect

• 스프링은 @Aspect 애노테이션으로 편리하게 포인트컷과 어드바이스로 구성되어있는 Advisor 생성 기능을 지원한다.

• 관점 지향 프로그래밍(AOP)를 가능하게 하는 AspectJ 프로젝트에서 제공하는 애노테이션

• 자동 프록시 생성기(AnnotationAwareAspectJAutoProxyCreator)가 @Aspect를 찾아서 이것을 Advisor로 만들어준다.

  • 자동 프록시 생성기는 2가지 일을 한다.
    1. @Aspect를 보고 Advisor로 변환해서 저장
    2. 어드바이저를 기반으로 프록시를 생성

• 예제

  • @Slf4j
    @Aspect
    public class LogTraceAspect {
    
    private final LogTrace logTrace;
    
    public LogTraceAspect(LogTrace logTrace) {
        this.logTrace = logTrace;
    }
    
    @Around("execution(* hello.proxy.app..*(..))") // 포인트컷
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        // 어드바이스(부가기능)
        TraceStatus status = null;
        try {
            String meesage = joinPoint.getSignature().toShortString();
            status = logTrace.begin(meesage);
    
            // 로직 호출
            Object result = joinPoint.proceed();
    
            logTrace.end(status);
            return result;
        } catch (Exception e) {
            logTrace.exception(status, e);
            throw e;
        }
    }
    }

횡단 관심사(cross-cutting concerns)

• 애플리케이션의 여러 기능들 사이에 걸쳐서 들어가는 관심사

스프링 AOP

• 횡단 관심사를 전문으로 해결

[LeeeeDain]

섹션9 - 스프링 AOP 개념

AOP 소개 - 핵심 기능과 부가 기능

• 핵심 기능
  • 해당 객체가 제공하는 고유의 기능
  • OrderService 의 핵심 기능은 주문 로직
• 부가 기능
  • 핵심 기능을 보조하기 위해 제공하는 기능
  • 로그 추적 로직, 트랜젝션 기능
  • 여러 클래스에 걸쳐서 함께 사용됨 -> 횡단 관심사(cross-cutting concerns)

부가 기능 적용 문제

• 적용할 때 아주 많은 반복이 필요하다.
• 여러 곳에 퍼져서 중복 코드를 만들어낸다.
• 변경할 때 중복 때문에 많은 수정이 필요하다.
• 적용 대상을 변경할 때 많은 수정이 필요하다.

AOP 소개 - 애스펙트

• 애스펙트 - 핵심 기능과 부가 기능을 분리
  • 부가 기능과, 해당 부가 기능을 어디에 적용할지 정의한 것
  • @Aspect
• 애스펙트를 사용한 프로그래밍 방식을 관점 지향 프로그래밍(AOP)이라 한다.
• AOP는 OOP를 대체하기 위한 것이 아니라 횡단 관심사를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발되었다.

AspectJ 프레임워크

• AOP의 대표적인 구현
• 스프링도 AOP를 지원하지만 대부분 AspectJ의 문법을 차용하고, AspectJ가 제공하는 기능의 일부만 제공
• 자바 프로그래밍 언어에 대한 완벽한 관점 지향 확정
• 횡단 관심사의 깔끔한 모듈화
  • 오류 검사 및 처리
  • 동기화
  • 성능 최적화(캐싱)
  • 모니터링 및 로깅

AOP 적용 방식

1. 컴파일 시점
   • .java 소스 코드를 컴파일러를 사용해서 .class를 만드는 시점에 부가 기능 로직을 추가
   • 컴파일 시점에 부가 기능을 적용하려면 특별한 컴파일러도 필요하고 복잡해서 잘 사용하지 않음
   • 실제 대상 코드에 애스펙트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다.
2. 클래스 로딩 시점
   • .class 파일을 JVM 내부의 클래스 로더에 저장하기 전에 조작하여 JVM에 올림
   • 수많은 모니터링 툴들이 이 방식을 사용
   • 이 시점에 애스펙트를 적용하는 것을 로드 타임 위빙이라고 하는데, 로드 타임 위빙은 자바를 실행할 때 특별한 옵션(java-javaagent)를 통해 클래스 로더 조작기를 지정해야 하는데, 이 부분이 번거롭고 운영하기 어렵다.
   • 실제 대상 코드에 애스펙트를 통한 부가 기능 호출 코드가 포함된다. AspectJ를 직접 사용해야 한다.
3. 런타임 시점(프록시) <- 지금까지 적용한 방법
   • 컴파일이 다 끝나고, 클래스 로더에 클래스도 다 올라가서 자바의 메인(main) 메서드가 실행된 다음ㅍ 프록시를 통해 스프링 빈에 부가 기능을 적용하는 방식
   • 프록시를 사용하기 때문에 AOP 기능에 일부 제약이 있다. (예를 들어, 생성자 안되고 오버라이드가 되는 메서드에만 적용 가능)
   • 스프링만 있으면 얼마든지 AOP를 적용할 수 있다.
   • 실제 대상 코드는 그대로 유지한다. 대신에 프록시를 통해 부가 기능이 적용된다. 따라서 항상 프록시를 통해야 부가 기능을 사용할 수 있다. 스프링 AOP는 이 방식을 사용한다.

AOP 적용 위치

• 적용 가능 지점(Join point): 생성자, 필드 값 접근, static 메서드 접근, 메서드 실행
• 스프링 AOP의 적용 가능 지점: 메서드 실행
• 스프링 AOP보다 AspectJ를 직접 사용하는게 좋지 않나?
  • 공부할 내용 많고 매우 복잡
  • 실무에서는 스프링 AOP 기능만 사용해도 대부분의 문제를 해결할 수 있다.

AOP 용어 정리

• 조인 포인트(Join point)
  • AOP를 적용할 수 있는 위치
  • 스프링 AOP의 조인 포인트는 항상 메서드 실행 시점으로 제한된다.
• 포인트컷(Pointcut)
  • 조인 포인트 중에서 어드바이스가 적용될 위치를 선별하는 기능
  • AspectJ 표현식을 사용
  • 스프링 AOP는 메서드 실행 지점만 포인트컷으로 지정 가능
• 타켓(Target)
  • 어드바이스를 받는 객체, 부가 기능을 적용 받는 객체
  • 포인트컷으로 결정
• 어드바이스(Advice)
  • 부가 기능
  • 특정 조인 포인트에서 Aspect에 의해 취해지는 조치
  • Around, Before, After와 같은 다양한 종류의 어드바이스가 있음
• 애스펙트(Aspect)
  • 어드바이스 + 포인트컷을 모듈화한 것
  • @Aspect
  • 여러 어드바이스와 포인트컷이 함께 존재
• 어드바이저(Advisor)
  • 하나의 어드바이스와 하나의 포인트컷으로 구성
  • 스프링 AOP에서만 사용되는 용어
• 위빙(Weaving)
  • 포인트컷으로 결정한 타겟의 조인 포인트에 어드바이스를 적용하는 것
  • 위빙을 통해 핵심 기능에 영향을 주지 않고 부가 기능을 추가할 수 있음
  • AOP 적용을 위해 애스펙트를 객체에 연결한 상태
  • 컴파일 타임
  • 로드 타임
  • 런타임
• AOP 프록시
  • AOP 기능을 구현하기 위해 만든 프록시 객체
  • 스프링에서 AOP 프록시는 JDK 동적 프록시 또는 CGLIB 프록시이다.

[cme10575]

AspectJ의 @Aspect 를 통해 Advisor를 간편하게 만들 수 있다.

@Aspect //Advisor로 변환해서 저장
public class LogTraceAspect {

    @Around("execution(* hello.proxy.app..*(..))") //pointcut
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable { //advice
                String meesage = joinPoint.getSignature().toShortString();
        status = logTrace.begin(meesage);

        joinPoint.proceed();
    }
}

참고) @Aspect 하나에 여러 어드바이저 만들 수 있음

AOP

부가 기능 도입시 문제점

1. 아주 많은 반복 필요
2. 중복 코드 만들어냄
3. 기능 변경시 많은 수정 필요
4. 적용 대상 변경시 많은 수정 필요

Aspect(관점)

부가 기능을 한 곳에서 관리하도록 변경 어디에 적용할지 선택하는 기능 추가

AOP (Aspect-Oriented-Programming)

Aspect를 사용한 프로그래밍 방식

AspectJ

J는 Java의 J AOP의 대표적인 구현 프레임워크 스프링도 AOP를 제공하지만 대부분 AspectJ의 문법 차용(직접사용 X), 기능 일부만 제공 제공 기능

• 자바 프로그래밍 언어에 대한 완벽한 관점 지향 확장
• 횡단 관심사의 모듈화
  • 오류 검사 및 처리
  • 동기화
  • 성능 최적화(캐싱)
  • 모니터링 및 로깅

AOP 적용 방식

부가 로직을 실제로 추가하는 방법

1. 컴파일 시점 -> .class 파일 생성시 코드를 실제로 붙여버리는 방법, AspectJ 컴파일러 사용해야함
2. 클래스 로딩 시점 -> 자바 실행시 AspectJ 클래스 로더 조작기가 .class 파일 조작하여 JVM에 올림
3. 런타임 시점 -> 복잡한 과정(스프링 컨테이너의 도움 받음, 프록시, DI, 빈 포스트 프로세서 등)을 통해 프록시를 적용함

• 런타임 시점의 장점
  • AspectJ의 컴파일러나 클래스 로더 조작기를 사용하지 않아도 된다.
• 런타임 시점의 단점
  • 메서드 실행 시점에만 적용가능
    • 생성자, static메서드, 필드 값 접근 등 불가능

[otakijae]

• https://goddaehee.tistory.com/154
• https://velog.io/@miot2j/Spring-Filter-Interceptor-AOP-%EC%B0%A8%EC%9D%B4-%EB%B0%8F-AOP%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-Logging%EC%9D%84-%EA%B5%AC%ED%98%84%ED%95%9C-%EC%9D%B4%EC%9C%A0

---

• Filter
  • Spring이 아닌 톰캣과 같은 웹 컨테이너의 영역
  • ex) HTTP 또한 Spring이 아닌 WAS에서 처리하는 것이니까 HTTP Request/Response에 대한 로깅은 Filter에서 처리하는 게 적절
• Interceptor
  • Spring이 제공하는 레이어로, DistpatcherServlet 이 호출되기 전, 호출된 후에 끼어들기 때문에 Spring Context 내부에서 요청과 응답을 가공할 수 있음
  • ex) Spring Security, 인증 처리를 하는 것이 적절
• AOP
  • Spring 내에서 흩뿌려진 반복적인 코드를 한 곳에 모아서 응집력있게 관리할 수 있어 유지보수에 효울적이고, 좀 더 비즈니스 로직에 집중할 수 있으며, 변화 수용에 용이함
  • ex) 인가, 로깅 등 비즈니스 로직 전/후로 횡단으로 선행되야하는 부수적인 작업들을 처리하는 게 적절