22.10.19

Advance I/Spring

22.10.19

kinggora 2022. 10. 19. 18:53

9. 스프링 AOP 개념

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

핵심 기능과 부가 기능

핵심 기능: 해당 객체가 제공하는 고유의 기능. 예를 들어서 OrderService 의 핵심 기능은 주문 로직이다.
부가 기능: 핵심 기능을 보조하기 위해 제공되는 기능. 예를 들어서 로그 추적 로직, 트랜잭션 기능이 있다. 이러한 부가 기능은 단독으로 사용되지 않고, 핵심 기능과 함께 사용된다. 예를 들어서 로그 추적 기능은 어떤 핵심 기능이 호출되었는지 로그를 남기기 위해 사용한다.

주문 로직을 실행하기 직전에 로그 추적 기능을 사용해야 하면, 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 하나의 객체 안에 섞여 들어가게 된다. 부가 기능이 필요한 경우 이렇게 둘을 합해서 하나의 로직을 완성한다.

이제 주문 서비스를 실행하면 핵심 기능인 주문 로직과 부가 기능인 로그 추적 로직이 함께 실행된다.

여러 곳에서 공통으로 사용하는 부가 기능

보통 부가 기능은 여러 클래스에 걸쳐서 함께 사용된다. 이때 부가 기능은 횡단 관심사(cross-cutting concerns)가 된다.

쉽게 이야기해서 하나의 부가 기능이 여러 곳에 동일하게 사용된다는 뜻이다.

부가 기능 적용 문제

부가 기능을 여러 곳에 적용하려면 여러 곳에 동일한 코드를 모두 추가해야 한다.

부가 기능을 별도의 유틸리티 클래스로 만든다고 해도, 해당 유틸리티 클래스를 호출하는 코드가 결국 필요하다. 그리고 부가 기능이 구조적으로 단순 호출이 아니라 try~catch~finally 같은 구조가 필요하다면 더욱 복잡해진다. (예: 실행 시간 측정)

더 큰 문제는 수정이다. 만약 부가 기능을 수정하거나, 부가 기능이 적용되는 위치를 변경하기 위해서는, 모든 클래스를 하나씩 찾아가면서 수정해야 한다.

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

클래스마다 핵심 기능이 다르기 때문에 중복 코드를 메서드로 추출하기에도 애매하다.

소프트웨어 개발에서 변경 지점은 하나가 될 수 있도록 잘 모듈화 되어야 한다. 그런데 부가 기능처럼 특정 로직을 애플리케이션 전반에 적용하는 문제는 일반적인 OOP 방식으로는 해결이 어렵다.

AOP 소개 - 애스펙트

핵심 기능과 부가 기능을 분리

부가 기능과 부가 기능을 어디에 적용할지 선택하는 기능을 합해서 하나의 모듈로 만들었는데 이것이 바로 애스펙트(aspect)이다.

애스펙트 = 부가 기능 + 부가 기능 적용 위치

예를 들어서 로그 출력 기능을 모든 컨트롤러에 적용해라 라는 것이 정의되어 있다.

우리가 이전에 알아본 @Aspect 가 바로 그것이다. 그리고 스프링이 제공하는 어드바이저도 어드바이스(부가 기능)과 포인트컷(적용 대상)을 가지고 있어서 개념상 하나의 애스펙트이다.

애스펙트는 우리말로 해석하면 관점이라는 뜻인데, 이름 그대로 애플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사(cross-cutting concerns) 관점으로 달리 보는 것이다. 이렇게 애스펙트를 사용한 프로그래밍 방식을 관점 지향 프로그래밍 AOP(Aspect-Oriented Programming)이라 한다.

참고: AOP는 OOP를 대체하기 위한 것이 아니라, 횡단 관심사를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발되었다.

AspectJ 프레임워크

AOP의 대표적인 구현으로 AspectJ 프레임워크(https://www.eclipse.org/aspectj/)가 있다.

물론 스프링도 AOP를 지원하지만 대부분 AspectJ의 문법을 차용하고, AspectJ가 제공하는 기능의 일부만 제공한다.

AspectJ 프레임워크는 스스로를 다음과 같이 설명한다.

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

AOP 적용 방식

AOP를 사용하면 핵심 기능과 부가 기능이 코드상 완전히 분리되어서 관리된다.

그렇다면 AOP를 사용할 때 부가 기능 로직은 어떤 방식으로 실제 로직에 추가될 수 있을까?

컴파일 시점
클래스 로딩 시점
런타임 시점(프록시)

컴파일 시점

.java 소스 코드를 컴파일러를 사용해서 .class 를 만드는 시점에 부가 기능 로직을 추가할 수 있다.

이때는 AspectJ가 제공하는 특별한 컴파일러를 사용해야 한다.

컴파일 된 .class 를 디컴파일 해보면 애스펙트 관련 호출 코드가 들어간다. 부가 기능 코드가 핵심 기능이 있는 컴파일된 코드 주변에 실제로 붙어 버린다고 생각하면 된다. AspectJ 컴파일러는 Aspect를 확인해서 해당 클래스가 적용 대상인지 먼저 확인하고, 적용 대상인 경우에 부가 기능 로직을 적용한다. 참고로 이렇게 원본 로직에 부가 기능 로직이 추가되는 것을 위빙(Weaving)이라 한다.

*위빙(Weaving): 옷감을 짜다. 직조하다. 애스펙트와 실제 코드를 연결해서 붙이는 것

컴파일 시점 - 단점

컴파일 시점에 부가 기능을 적용하려면 특별한 컴파일러도 필요하고 복잡하다.

클래스 로딩 시점

자바를 실행하면 자바 언어는 .class 파일을 JVM 내부의 클래스 로더에 보관한다. 이때 중간에서 .class 파일(바이트 코드)을 조작한 다음 JVM에 올릴 수 있다. 자바 언어는 .class 를 JVM에 저장하기 전에 조작할 수 있는 기능을 제공한다. (java Instrumentation) 참고로 수 많은 모니터링 툴들이 이 방식을 사용한다. 이 시점에 애스펙트를 적용하는 것을 로드 타임 위빙이라 한다.

클래스 로딩 시점 - 단점

로드 타임 위빙은 자바를 실행할 때 특별한 옵션( java -javaagent )을 통해 클래스 로더 조작기를 지정해야 하는데, 이 부분이 번거롭고 운영하기 어렵다.

런타임 시점

런타임 시점은 컴파일도 다 끝나고, 클래스 로더에 클래스도 다 올라가서 이미 자바가 실행되고 난 다음을 말한다. 자바의 메인( main ) 메서드가 이미 실행된 다음이다. 따라서 자바 언어가 제공하는 범위 안에서 부가 기능을 적용해야 한다.

스프링과 같은 컨테이너의 도움을 받고 프록시와 DI, 빈 포스트 프로세서 같은 개념들을 총 동원해야 한다. 이렇게 하면 최종적으로 프록시를 통해 스프링 빈에 부가 기능을 적용할 수 있다.

지금까지 학습한 것이 바로 프록시 방식의 AOP이다.

프록시를 사용하기 때문에 AOP 기능에 일부 제약이 있다.

하지만 특별한 컴파일러나, 자바를 실행할 때 복잡한 옵션과 클래스 로더 조작기를 설정하지 않아도 된다. 스프링만 있으면 얼마든지 AOP를 적용할 수 있다.

부가 기능이 적용되는 차이를 정리하면 다음과 같다.

컴파일 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. -> AspectJ 직접 사용
클래스 로딩 시점: 실제 대상 코드에 애스팩트를 통한 부가 기능 호출 코드가 포함된다. -> AspectJ 직접 사용
런타임 시점: 실제 대상 코드는 그대로 유지된다. 대신에 프록시를 통해 부가 기능이 적용된다. 항상 프록시를 통해야 부가 기능을 적용할 수 있다. 스프링 AOP는 이 방식을 사용한다.

AOP 적용 위치 - 조인 포인트(Join point)

AOP는 지금까지 학습한 메서드 실행 위치 뿐만 아니라 다양한 위치에 적용할 수 있다.

Join point: 생성자, 필드 값 접근, static 메서드 접근, 메서드 실행

AspectJ 사용 ( 컴파일, 클래스 로딩 시점 )

컴파일 시점과 클래스 로딩 시점에 적용하는 AOP는 바이트코드를 실제 조작하기 때문에 해당 기능을 모든 지점에 다 적용할 수 있다.
AspectJ 의 특별한 컴파일러나 옵션이 필요하다.

프록시 방식 사용 ( 런타임 시점 - 스프링 AOP )

메서드 실행 지점에만 AOP를 적용할 수 있다.
프록시는 메서드 오버라이딩 개념으로 동작한다. 따라서 생성자나 static 메서드, 필드 값 접근에는 프록시 개념이 적용될 수 없다.
프록시를 사용하는 스프링 AOP의 조인 포인트는 메서드 실행으로 제한된다.
프록시 방식을 사용하는 스프링 AOP는 스프링 컨테이너가 관리할 수 있는 스프링 빈에만 AOP를 적용할 수 있다.

참고: 스프링은 AspectJ의 문법을 차용하고 프록시 방식의 AOP를 적용한다. 즉, AspectJ를 직접 사용하는 것이 아니다.

중요

스프링이 제공하는 AOP는 프록시를 사용한다. 따라서 프록시를 통해 메서드를 실행하는 시점에만 AOP가 적용된다. AspectJ를 사용하면 앞서 설명한 것 처럼 더 복잡하고 더 다양한 기능을 사용할 수 있다.

그러나 AspectJ를 사용하려면 공부할 내용도 많고, 자바 관련 설정(특별한 컴파일러, AspectJ 전용 문법, 자바 실행 옵션)도 복잡하다. 반면에 스프링 AOP는 별도의 추가 자바 설정 없이 스프링만 있으면 편리하게 AOP 를 사용할 수 있다.

실무에서는 스프링이 제공하는 AOP 기능만 사용해도 대부문의 문제를 해결할 수 있다.

AOP 용어 정리

조인 포인트(Join point)

어드바이스가 적용될 수 있는 위치, 메소드 실행, 생성자 호출, 필드 값 접근, static 메서드 접근 같은 프로그램 실행 중 지점
조인 포인트는 추상적인 개념이다. AOP를 적용할 수 있는 모든 지점이라 생각하면 된다.
스프링 AOP는 프록시 방식을 사용하므로 조인 포인트는 항상 메소드 실행 지점으로 제한된다.

포인트컷(Pointcut)

조인 포인트 중에서 어드바이스가 적용될 위치를 선별하는 기능
주로 AspectJ 표현식을 사용해서 지정
프록시를 사용하는 스프링 AOP는 메서드 실행 지점만 포인트컷으로 선별 가능

타켓(Target)

어드바이스(부가 기능)를 받는 객체, 포인트컷으로 결정

어드바이스(Advice)

부가 기능
특정 조인 포인트에서 Aspect에 의해 취해지는 조치
Around(주변), Before(전), After(후)와 같은 다양한 종류의 어드바이스가 있음

애스펙트(Aspect)

어드바이스 + 포인트컷을 모듈화 한 것
@Aspect 를 생각하면 됨
하나의 애스펙트에 여러 어드바이스와 포인트 컷이 함께 존재할 수 있음

어드바이저(Advisor)

하나의 어드바이스와 하나의 포인트 컷으로 구성된 애스펙트
스프링 AOP에서만 사용되는 특별한 용어

위빙(Weaving)

포인트컷으로 결정한 타켓의 조인 포인트에 어드바이스를 적용하는 것
위빙을 통해 핵심 기능 코드에 영향을 주지 않고 부가 기능을 추가 할 수 있음
AOP 적용을 위해 애스펙트를 객체에 연결한 상태
컴파일 타임, 로드 타임, 런타임

AOP 프록시

AOP 기능을 구현하기 위해 만든 프록시 객체, 스프링에서 AOP 프록시는 JDK 동적 프록시 또는 CGLIB 프록시이다.

10. 스프링 AOP 구현

프로젝트 생성

이번에는 스프링 웹 기술을 사용하지 않는다.

스프링 프레임워크의 핵심 모듈들은 별도의 설정이 없어도 자동으로 추가된다.

build.gradle

--스프링 AOP 기능

implementation 'org.springframework.boot:spring-boot-starter-aop'

--테스트 코드에서 lombok 사용

testCompileOnly 'org.projectlombok:lombok'
testAnnotationProcessor 'org.projectlombok:lombok'

참고: @Aspect 를 사용하려면 @EnableAspectJAutoProxy 를 스프링 설정에 추가해야 하지만, 스프링 부트를 사용하면 자동으로 추가된다.

예제 프로젝트 만들기

OrderRepository 클래스

@Slf4j
@Repository
public class OrderRepository {

    public String save(String itemId){
        log.info("[orderRepository] 실행");
        //저장 로직
        if (itemId.equals("ex")) {
            throw new IllegalArgumentException("예외 발생!");
        }
        return "ok";
    }
}

OrderService 클래스

@Slf4j
@Service
public class OrderService {

    private final OrderRepository orderRepository;

    public OrderService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void orderItem(String itemId) {
        log.info("[orderService] 실행");
        orderRepository.save(itemId);
    }
}

AopTest

@Test
void aopInfo() {
    log.info("isAopProxy, orderService={}", AopUtils.isAopProxy(orderService));
    log.info("isAopProxy, orderRepository={}", AopUtils.isAopProxy(orderRepository));
}

AopUtils.isAopProxy() 메서드를 통해 AOP 프록시가 적용 되었는지 확인할 수 있다.

스프링 AOP 구현1 - 시작

@Aspect 를 사용한 가장 단순한 AOP 구현

@Slf4j
@Aspect
public class AspectV1 {

    //hello.aop.order 패키지와 하위 패키지
    @Around("execution(* hello.aop.order..*(..))")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable{
        log.info("[log] {}", joinPoint.getSignature()); //join point 시그니처
        return joinPoint.proceed();
    }
}

@Around 애노테이션의 값인 execution(* hello.aop.order..*(..)) 는 포인트컷이 된다.
@Around 애노테이션의 메서드인 doLog 는 어드바이스( Advice )가 된다.
execution(* hello.aop.order..*(..)) : hello.aop.order 패키지와 그 하위 패키지( .. )를 지정하는 AspectJ 포인트컷 표현식. 이제 OrderService , OrderRepository 의 모든 메서드는 AOP 적용의 대상이 된다. 참고로 스프링은 프록시 방식의 AOP를 사용하므로 프록시를 통하는 메서드만 적용 대상이 된다.

참고: 스프링 AOP는 AspectJ의 문법을 차용하고, 프록시 방식의 AOP를 제공한다. AspectJ를 직접 사용하는 것이 아니다.

스프링 AOP를 사용할 때는 @Aspect 애노테이션을 주로 사용하는데, 이 애노테이션도 AspectJ가 제공하는 애노테이션이다.

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Around;

참고: @Aspect 를 포함한 org.aspectj 패키지 관련 기능은 aspectjweaver.jar 라이브러리가 제공하는 기능이다. build.gradle 에 spring-boot-starter-aop 를 포함하면 스프링의 AOP 관련 기능과 함께 aspectjweaver.jar 도 의존 관계에 포함된다.

그런데 스프링에서는 AspectJ가 제공하는 애노테이션이나 관련 인터페이스만 사용하는 것이고, 실제 AspectJ가 제공하는 컴파일, 로드타임 위버 등을 사용하는 것은 아니다. 스프링은 프록시 방식의 AOP를 사용한다.

@Aspect 는 애스펙트라는 표식이지 컴포넌트 스캔이 되는 것은 아니다.

따라서 AspectV1 를 AOP로 사용하려면 스프링 빈으로 등록해야 한다.

참고: 스프링 빈 등록 방법

@Bean 을 사용해서 직접 등록
@Component 컴포넌트 스캔을 사용해서 자동 등록
@Import 주로 설정 파일을 추가할 때 사용( @Configuration )

테스트에서는 버전을 올려가면서 변경할 예정이어서 간단하게 @Import 기능을 사용했다.

테스트 코드와 로그

@Test
void success(){
    orderService.orderItem("itemA");
}

[log] void hello.aop.order.OrderService.orderItem(String)
[orderService] 실행
[log] String hello.aop.order.OrderRepository.save(String)
[orderRepository] 실행

클라이언트 " orderService.orderItem("itemA"); "

-> AspectV1.doLog(joinPoint)

-> ( joinPoint.proceed() ) orderService.orderItem("itemA")

-> AspectV1.doLog(joinPoint)

-> ( joinPoint.proceed() ) orderRepository.save("itemA")

스프링 AOP 구현2 - 포인트컷 분리

@Around 에 포인트컷 표현식을 직접 넣을 수 있지만, @Pointcut 애노테이션을 사용해서 별도로 분리할 수 있다.

@Slf4j
@Aspect
public class AspectV2 {

    //hello.aop.order 패키지와 하위 패키지
    @Pointcut("execution(* hello.aop.order..*(..))")
    private void allOrder(){} //pointcut signature


    @Around("allOrder()")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable{
        log.info("[log] {}", joinPoint.getSignature()); //join point 시그니처
        return joinPoint.proceed();
    }
}

@Pointcut

@Pointcut 에 포인트컷 표현식을 사용한다.
메서드 이름과 파라미터를 합쳐서 포인트컷 시그니처(signature)라 한다.
메서드의 반환 타입은 void 여야 한다.
코드 내용은 비워둔다.
포인트컷 시그니처는 allOrder() 이다. 이름 그대로 주문과 관련된 모든 기능을 대상으로 하는 포인트컷이다.
@Around 어드바이스에서는 포인트컷을 직접 지정해도 되지만, 포인트컷 시그니처를 사용해도 된다. 여기서는 @Around("allOrder()") 를 사용한다.
접근 제어자는 내부에서만 사용하면 private 을 사용해도 되지만, 다른 애스팩트에서 참고하려면 public 을 사용해야 한다.

결과적으로 AspectV1 과 같은 기능을 수행한다.

이렇게 분리하면 하나의 포인트컷 표현식을 여러 어드바이스에서 함께 사용할 수 있다.

그리고 뒤에 설명하겠지만 다른 클래스에 있는 외부 어드바이스에서도 포인트컷을 함께 사용할 수 있다.

스프링 AOP 구현3 - 어드바이스 추가

로그를 출력하는 기능에 추가로 트랜잭션을 적용하는 기능 추가

진짜 트랜잭션을 실행하는 것은 아니고, 기능이 동작한 것 처럼 로그만 남긴다.

트랜잭션 동작 과정

핵심 로직 실행 직전에 트랜잭션을 시작
핵심 로직 실행
핵심 로직 실행에 문제가 없으면 커밋
핵심 로직 실행에 예외가 발생하면 롤백

트랜잭션은 보통 비지니스 로직을 실행하기 전에 시작하고, 비지니스 로직이 끝날 때 커밋하는데, 비지니스 로직은 서비스 계층에 들어간다. 따라서 트랜잭션을 위한 포인트컷은 서비스 계층에 대해 걸어준다.

어드바이스 (@Around) : 트랜잭션 적용 로그
포인트컷 (@Pointcut) : 서비스 계층 클래스

@Slf4j
@Aspect
public class AspectV3 {

    //hello.aop.order 패키지와 하위 패키지
    @Pointcut("execution(* hello.aop.order..*(..))")
    private void allOrder(){} //pointcut signature

    //클래스 이름 패턴이 *Service
    @Pointcut("execution(* *..*Service.*(..))")
    private void allService(){}


    @Around("allOrder()")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable{
        log.info("[log] {}", joinPoint.getSignature()); //join point 시그니처
        return joinPoint.proceed();
    }

    @Around("allOrder() && allService()")
    //hello.aop.order 패키지와 하위 패키지이면서 클래스 이름 패턴이 *Service
    public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable{
        try{
            log.info("[트랜잭션 시작] {}", joinPoint.getSignature());
            Object result = joinPoint.proceed();
            log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
            return result;
        } catch(Exception e){
            log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
            throw e;
        } finally{
            log.info("[리소스 릴리즈] {}", joinPoint.getSignature());
        }
    }
}

allOrder() 포인트컷 : hello.aop.order 패키지와 하위 패키지 대상
allService() 포인트컷 : 타입 이름 패턴 *Service 대상 ( Service 로 끝나는 이름 ) *Servi* 과 같은 패턴도 가능하다. 여기서 타입 이름 패턴이라고 한 이유는 클래스, 인터페이스에 모두 적용되기 때문이다.

@Around("allOrder() && allService()")

포인트컷은 이렇게 조합할 수 있다. && (AND), || (OR), ! (NOT) 3가지 조합이 가능하다.
hello.aop.order 패키지와 하위 패키지 이면서 타입 이름 패턴이 *Service 인 것을 대상으로 한다.
doTransaction() 어드바이스는 OrderService 에만 적용된다.
doLog() 어드바이스는 OrderService , OrderRepository 에 모두 적용된다.

포인트컷이 적용된 AOP 결과

orderService : doLog() , doTransaction() -> 어드바이스 적용

orderRepository : doLog() -> 어드바이스 적용

실행 - success()

[log] void hello.aop.order.OrderService.orderItem(String)
[트랜잭션 시작] void hello.aop.order.OrderService.orderItem(String)
[orderService] 실행
[log] String hello.aop.order.OrderRepository.save(String)
[orderRepository] 실행
[트랜잭션 커밋] void hello.aop.order.OrderService.orderItem(String)
[리소스 릴리즈] void hello.aop.order.OrderService.orderItem(String)

orderRepository.save() 실행 후, orderService.orderItem() 다음 로직과 리턴 직전에 finally 실행

클라이언트 -> [ doLog() -> doTransaction() ] -> orderService.orderItem() -> [ doLog() ] -> orderRepository.save()

Advise Ordering

이때 로그를 남기는 순서가 [ doLog() -> doTransaction() ] 순서로 작동한다.

만약 어드바이스가 적용되는 순서를 변경하고 싶으면 어떻게 하면 될까?

예를 들어서 실행 시간을 측정해야 하는데 트랜잭션과 관련된 시간을 제외하고 측정하고 싶다면 [ doTransaction() -> doLog() ] 이렇게 트랜잭션 이후에 로그를 남겨야 할 것이다.