spring aop

[hyunjungkimm]

aop

설정 파일

• spring jpa를 쓰면 자동으로 추가되지만 안 쓰면 직접 추가해줄 것
  • implementation 'org.springframework.boot:spring-boot-starter-aop'
  • 
  • @ Aspect를 포함한 org.aspectj 패키지 관련 기능 aspectjweaver.jar 라이브러리가 제공하는 기능임
• spring boot 사용하면 @ Aspect를 사용할 수 있도록 @ EnableAspectJAutoProxy가 스프링 설정에 추가됨

체크

• AopUtils.isAopProxy()
  • AOP 프록시가 적용되었는지 확인할 수 있음
• org.assertj.assertions.assertThatThrownBy()
  • 예외 처리

AOP

• joinpoint.getSignature() 메서드의 정보를 다 알 수 있음
• joinpoint.proceed() 실제 target 호출

@ Pointcut

• @ Around에 포인트컷 표현식을 직접 넣을 수도 있지만, @ Pointcut 애노테이션을 사용해서 별도로 분리할 수도 있음
• 포인트 시그니처 : 메서드 이름 + 파라미터
• 메서드의 반환 타입 : void
• 코드 내용은 비워놓음
• private, public 같은 접근 제어자는 내부에서만 사용하면 private을 사용해도 되지만, 다른 애스팩트에서 참고하려면 public을 사용해야 함
• 하나의 포인트컷 표현식을 여러 어드바이스에서 함께 사용할 수 있고, 다른 클래스에 있는 외부 어드바이스에서도 포인트컷을 함께 사용할 수 있음

트랜잭션 기능 동작

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

보통 트랜잭션을 service에 시작

• 비즈니스 로직 시작 : 트랜잭션 걸고, 종료 : 커밋, 롤백 결정

어드바이스 순서

• 어드바이스는 기본적으로 순서를 보장하지 않는다.
• 순서를 지정하고 싶으면 @ Aspect 적용 단위로 org.springframework.core.annotation.@ Order 애노테이션을 적용해야 함
• 어드바이스 단위가 아니라 클래스 단위로 적용할 수 있어서 애스펙트를 별도의 클래스로 분리해야 함
• 숫자가 작을수록 먼저 실행됨

어드바이스 종류

• @ Around
  • 메서드 호출 전후에 수행
  • 가장 강력한 어드바이스 (모든 걸 할 수 있음)
  • 조인 포인트 실행 여부 선택 joinPoint.proceed() 호출 여부 선택
  • 전달 값 변환 joinPoint.proceed(args[])
  • 반환 값 변환
  • 예외 변환
  • 트랜잭션 처럼 try ~ catch ~ finally 모두 들어가는 구문 처리 가능
  • 어드바이스의 첫번째 파라미터는 ProceedingJoinPoint를 사용해야 한다.
  • proceed()를 통해 대상을 실행함
  • proceed()를 여러번 실행할 수도 있음(재시도)
• @ Before
  • 조인포인트 실행 이전에 실행
  • @ Around와 다르게 작업흐름을 변경할 수 없다.
  • proceed() 사용하지 않아도 메서드 종료시 자동으로 다음 타켓이 호출된다.
  • 예외 발생하면 다음 코드가 호출되지 않음
• @ AfterReturning
  • 조인 포인트가 정상 완료 후 실행
  • returning 속성에 사용된 이름은 어드바이스 메서드의 매개 변수과 일치해야 한다.
  • retuning절에 지정된 타입의 값을 반환하는 메서드만 대상으로 실행됨 (부모 타입으로 지정하면 모든 자식 타입은 인정됨)
  • @ Around와 다르게 반환되는 객체를 변경할 수 없다.(return을 하지 않으니까)
• @ AfterThrowing
  • 메서드가 예외를 던지는 경우 실행
  • throwing 속성에 사용된 이름은 어드바이스 메서드의 매개 변수과 일치해야 한다.
  • throwing절에 지정된 타입과 맞는 예외를 대상으로 실행함(부모 타입으로 지정하면 모든 자식 타입은 인정됨)
• @ After
  • 조인 포인트가 정상 또는 예외에 관계없이 실행(finally)

JoinPoint - ProceedingJoinPoint(하위타입)

• 모든 어드바이스는 JoinPoint를 첫번째 파라미터에 사용할 수 있다.(생략 가능)
• @ Around는 ProceedingJoinPoint을 사용해야 한다.

JoinPoint 인터페이스의 주요 기능

• getArgs() : 메서드 인수를 반환함
• getThis() : 프록시 객체를 반환함
• getTarget() : 대상 객체를 반환함
• getSignature() : 조언되는 메서드에 대한 설명을 반환함
• toString() : 조언되는 방법에 대한 유용한 설명을 인쇄함

ProceedingJoinPoint 인터페이스의 주요 기능

• proceed() : 다음 어드바이스나 타켓을 호출함

@ Aspect 조인포인트 우선순위

• 실행 순서 : @ Around, @ Before, @ After, @ AfterReturning, @ AfterThrowing
• 어드바이스가 적용되는 순서는 이러게 적용되지만, 호출 순서와 리턴 순서는 반대라는 점

@ Around 외에 다른 어드바이스가 존재하는 이유

@Around("hello.aop.order.aop.Pointcuts.orderAndService()") public void doBefore(JoinPoint joinPoint) { log.info("[before] {}", joinPoint.getSignature()); }

• 이코드는 타켓을 호출하지 않는다. (실수 = 치명적 버그)

@Before("hello.aop.order.aop.Pointcuts.orderAndService()") public void doBefore(JoinPoint joinPoint) { log.info("[before] {}", joinPoint.getSignature()); }

• joinPoint.proceed()를 호출하는 고민을 하지 않아도 됨

• @ Around 는 가장 넓은 기능을 제공하지만 실수할 가능성이 있음

• @ Before, @ After 같은 어드바이스는 기능은 적지만 실수 가능성이 낮고, 코드가 단순하고, 이 코드를 작성한 의도가 명확하게 드러남

좋은 설계는 제약이 있는 것

• 제약은 실수를 미연에 방지하는 가이드 역할을 함

[hyunjungkimm]

Spring AOP - 포인트컷

• Aspect pointcut expression, 애스펙트 J가 제공하는 포인트컷 표현식을 줄여서 말하는 것
• AspectJExpressionPointcut
  • 포인트컷 표현식을 처리해주는 클래스
  • 포인트컷 표현식을 지정하면 된다.
  • AspectJExpressionPointcut에 pointcut.setExpression("execution(~~)")을 통해서 포인트컷 표현식을 적용할 수 있음
  • pointcut.matches(메서드, 대상 클래스)를 실행하면 지정한 포인트컷 표현식의 매칭여부를 true, false로 반환함
  • 

포인트컷 지시자 (Pointcut Designator, PCD)

execution

• 메소드 실행 조인 포인트를 매칭함
• 스프링 AOP에서 가장 많이 사용함(나머지는 자주 사용하지 않음)
• 문법
  • execution(modifiers-pattern? ret-type-pattern declaring-type-pattern?name-pattern(param-pattern) throws-pattern?) execution 접근제어자? 반환타입 선언타입?메서드이름(파라미터) 예외?
  • 메소드 실행 조인 포인트를 매칭함
  • ? 는 생략할 수 있음
  • * 같은 패턴을 지정할 수 있음
  • 아무 값이 들어와도 상관없다는 뜻
  • 메서드 이름 앞 뒤에 *을 사용해서 매칭할 수 있음
  • 파라미터에서 ..은 파라미터의 타입과 수과 상관없다는 뜻
  • 선언 타입 : 패키지명 + 클래스명
  • 반환타입이나 파라미터는 패키지명 생략 가능
  • 패키지에서 .,..의 차이점
  • . : 정확하게 해당 위치의 패키지
  • .. : 해당 위치의 패키지와 그 하위 패키지 포함
• 부모 타입을 선언해도 그 자식 타입은 매칭된다. 다형성에서 부모타입 = 자식타입 이 할당 가능하다는 점을 떠올려 보면 됨
• 부모 타입을 표현식에 선언한 경우 부모 타입에서 선언한 메서드가 자식 타입에 있어야 매칭에 성공한다
• execution 파라미터 매칭 규칙
  • (String) : 정확히 String 타입 파라미터
  • () : 파라미터가 없어야 함
  • (*) : 정확히 하나의 파라미터, 단 모든 타입을 허용함
  • (, ) : 정확히 두 개의 파라미터, 단 모든 타입을 허용함
  • (..) : 숫자와 무관하게 모든 파라미터, 모든 타입을 허용함. 파라미터가 없어도 됨
  • (String, ..) : String 타입으로 시작하는 숫자와 무관하게 모든 파라미터, 모든 타입을 허용함
  • (String) , (String, Xxx), (String, Xxx, Xxx) 허용

within

• 특정 타입 내의 조인 포인트를 매칭한다.
• 해당 타입이 매칭되면 그 안의 메서드(조인 포인트) 들이 자동 매칭된다. (하나를 딱 지정)
• execution의 타입 부분만 사용한다고 보면된다.
• 거의 사용 안함(하나만 지정하니까)
• 표현식에 부모타입을 지정하면 안된다. 정확하게 타입이 맞아야 한다는 점에서 execution과 차이점이 있다.

args

• 인자가 주어진 타입의 인스턴스인 조인 포인트
• 기본 문법은 execution 과 args 부분과 같지만, execution은 파라미터 타입이 정확하게 매칭되어야하고, args는 부모타입을 허용한다.
• execution은 클래스에 선언된 정보를 기반으로 판단하고, args는 실제 넘어온 파라미터 객체 인스턴스를 보고 판단하기 때문
  • execution : 메서드의 시그니처로 판단(정적)
  • args : 런타임에 전달된 인수로 판단(동적)
• 단독으로 사용되기 보다는 파라미터 바인딩에서 주로 사용됨

this

• 스프링 빈 객체(스프링 AOP 프록시)를 대상으로 하는 조인 포인트
• 프록시 객체를 전달 받는다.
• 적용 타입 하나를 정확하게 지정해야 함
  • this(hello.aop.member.MemberService)
• * 같은 패턴을 사용할 수 없음
• 부모 타입을 허용함
• 스프링 빈으로 등록되어 있는 프록시 객체를 대상으로 포인트컷을 매칭함
• 단독으로 사용되기 보다는 파라미터 바인딩에서 주료 사용함

target

• Target 객체(스프링 AOP 프록시가 가리키는 실제 대상)를 대상으로 하는 조인 포인트
• 실제 객체를 전달 받는다.
• 적용 타입 하나를 정확하게 지정해야 함
  • target(hello.aop.member.MemberService)
• *같은 패턴을 사용할 수 없음
• 부모 타입을 허용함
• 실제 target 객체를 대상으로 포인트컷을 매칭함
• 단독으로 사용되기 보다는 파라미터 바인딩에서 주료 사용함

@target

• 실행 객체의 클래스에 주어진 타입의 애노테이션이 있는 조인 포인트
• @target(hello.aop.member.annotation.ClassAop)
• 인스턴스의 모든 메서드를 조인 포인트로 적용
• 부모 클래스의 메서드까지 어드바이스를 다 적용
• 파라미터 바인딩에서 함께 사용됨

@within

• 주어진 애노테이션이 있는 타입 내 조인 포인트
• @within(hello.aop.member.annotation.ClassAop)
• 해당 타입 내에 있는 메서드만 조인 포인트로 적용
• 자기 자신의 클래스에 정의된 메서드에만 어드바이스를 적용 (부모 클래스에 있는 메서드는 AOP 적용 대상이 아님)
• 파라미터 바인딩에서 함께 사용됨

@annotation

• 메서드가 주어진 애노테이션을 가지고 있는 조인 포인트를 매칭
• 메서드의 애노테이션을 전달 받음
• annotation.value() 해당 애노테이션의 값을 출력할 수 있음

@args

• 전달된 실제 인수의 런타임 타입이 주어진 타입의 애노테이션을 갖는 조인 포인트
• 전달된 인수의 런타임 타입에 @Check 애노테이션이 있는 경우에 매칭한다.
• @args(test.Check)

bean

• 스프링 전용 포인트컷 지시자, 빈의 이름으로 포인트컷을 지정한다.
• 스프링 빈의 이름으로 AOP 적용 여부를 지정한다. 스프링에서만 사용할 수 있는 지시자
• bean(orderService) || bean(*Repository)

프록시 생성 방식에 따른 차이 (this, target)

JDK 동적 프록시

MemberService 인터페이스 지정

• this(hello.aop.member.MemberService)
  • proxy 객체를 보고 판단한다. this는 부모 타입을 허용하기 때문에 AOP가 적용된다.
• target(hello.aop.member.MemberService)
  • target 객체를 보고 판단한다. target는 부모 타입을 허용하기 때문에 AOP가 적용된다.

    MemberServiceImpl 구체클래스 지정

• this(hello.aop.member.MemberServiceImpl)
  • proxy 객체를 보고 판단한다. JDK 동적 프록시로 만들어진 proxy 객체는 MemberService 인터페이스를 기반으로 구현된 새로운 클래스라서 MemberServiceImpl를 전혀 알지 못하므로 AOP 적용 대상이 아니다.
• target(hello.aop.member.MemberServiceImpl)
  • target 객체를 보고 판단한다. target 객체가 MemberServiceImpl 타입이므로 AOP 적용 대상이다.

CGLIB

MemberService 인터페이스 지정

• this(hello.aop.member.MemberService)
  • proxy 객체를 보고 판단한다. this는 부모 타입을 허용하기 때문에 AOP가 적용된다.
• target(hello.aop.member.MemberService)
  • target 객체를 보고 판단한다. target는 부모 타입을 허용하기 때문에 AOP가 적용된다.

    MemberServiceImpl 구체클래스 지정

• this(hello.aop.member.MemberServiceImpl)
  • proxy 객체를 보고 판단한다. CGLIB로 만들어진 proxy 객체는 MemberServiceImpl을 상속받아서 만들었기 때문에 AOP가 적용된다. this가 부모 타입을 허용하기 때문에 포인트컷의 대상이 된다.
• target(hello.aop.member.MemberServiceImpl)
  • target 객체를 보고 판단한다. target 객체가 MemberServiceImpl 타입이므로 AOP 적용 대상이다.

설정

* application.properties
* spring.aop.proxy-target-class = true // CGLIB - default
* spring.aop.proxy-target-class = false //JDK 동적 프록시 (인터페이스가 없다면 CGLIB를 사용함)

@SpringBootTest(properties = "spring.aop.proxy-target-class=false") //JDK 동적 프록시
//@SpringBootTest(properties = "spring.aop.proxy-target-class=true") //CGLIB - default

매개변수 전달

• this, target, args, @target, @within, @annotation, @args
• 위 포인트컷 표현식을 사용해서 어드바이스에 매개변수를 전달할 수 있음
• 포인트컷 이름과 매개변수의 이름을 맞추어야 한다.
• 타입이 메서드에 지정한 타입으로 제한됨

주의

args, @args, @target 포인트컷 지시자는 단독으로 사용 금지

• 원인 : 실행 시점에 일어나는 포인트컷 지시자는 모든 스프링 빈에 AOP를 적용하려고 시도하므로 final로 지정된 빈들도 있기 때문에 오류가 발생할 수 있음
• 해결법 : 최대한 프록시 적용 대상을 축소하는 표현식과 같이 사용해야함
  • @Around("execution(* hello.aop..*(..)) && @target(hello.aop.member.annotation.ClassAop))")
• 원리
  • args, @args, @target 포인트컷 지시자들은 실제 객체 인스턴스가 생성되고 실행될 때 어드바이스 적용 여부를 확인할 수 있다.
  • 실행 시점에 일어나는 포인트컷 적용 여부도 프록시가 있어야 실행 시점에 판단할 수 있는데, 스프링 컨테이너가 프록시를 생성하는 시점은 스프링 컨테이너가 만들어지는 애플리케이션 로딩 시점에 적용할 수 있다.

[hyunjungkimm]

로그 출력 AOP

• optional
• 특정 이상 시간일때 로그를 남긴다 or 예외 터졌을 때 로그를 남긴다
• 5초 이상 : warning
• 10초 이상 : info

재시도 AOP

• 외부 api와 통신(server to server)하는데 간헐적으로 어쩌다 한번씩 튀는경우가 있는데 이런 경우 간헐적으로 다시 한번 조회
• retry 는 횟수 제한을 두는게 중요함

대표적인 AOP 예

• @Transactional : 애노테이션으로 만든 AOP
• @Async : 동기를 돌아가던 코드를 비동기로 바꾼다(별도의 쓰레드 할당 - 별도의 쓰레드로 돌아갈때)

[hyunjungkimm]

스프링 AOP 실무 주의사항

• 내부 호출에 프록시 적용 X
• 타입 캐스팅, 의존관계 주입

1. 내부 호출

• 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 어드바이스도 호출되지 않음
• 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생함 (proxy -> target -> method)
  • 자바에서는 메서드를 호출할 때 대상을 지정하지 않으면 자기 자신의 인스턴스를 뜻하는 this가 붙게 됨(this.internal())

스프링은 프록시 방식의 AOP를 사용하는데, 프록시 방식의 AOP는 메서드 내부 호출에 프록시를 적용할 수 없다.

• 실제 코드에 AOP 를 직접 적용하는 AspectJ를 사용하면 이런 문제가 발생하지 않음
• 프록시를 통하는것이 아니라 해당 코드에 직접 AOP 적용 코드가 붙어 있기 때문에 내부 호출과 무관하게 AOP 적용 가능
• 설정이 복잡하여 AspectJ를 직접 사용하는 방법은 실무에서는 거의 사용하지 않음

내부 호출 대안1. 자기 자신 주입

• 스프링 2.6부터 순환참조 기본적으로 금지되서 생성자 주입이 실패하는 것처럼 수정자 주입도 실패함

• spring.main.allow-circular-references=true 설정을 넣거나 @Lazy어노테이션 사용해야 함

  /*
  * 참고 : 생성자 주입은 순환 사이클을 만들기 때문에 실패함 -스프링 2.6부터 순환참조 기본적으로 금지
  */
  @Component
  @Slf4j
  public class CallService1 {
  
  private CallService1 callService1;
  
  @Lazy
  @Autowired
  public void setCallService1(CallService1 callService1) {
      this.callService1 = callService1;
  }
  
  public void external() {
      log.info("call external");
      callService1.internal(); //외부 메서드 호출
  }
  
  public void internal() {
      log.info("call internal");
  }
  }

  @Import(CallLogAspect.class)
  @SpringBootTest
  //@SpringBootTest("spring.main.allow-circular-references=true") //스프링 2.6부터 순환참조 기본적으로 금지
  class CallService1Test {
  
  @Autowired
  CallService1 callService1;
  
  @Test
  void external() {
      callService1.external();
  }
  }

내부 호출 대안2. 지연 조회

• 스프링 빈을 지연해서 조회
• 자기 자신을 주입 받는 것이 아니기 때문에 순환 사이클이 발생하지 않음

ObjectProvider(Provider)

• 객체를 스프링 컨테이너에서 조회하는 것을 스프링 빈 생성 시점이 아니라 실제 객체를 사용하는 시점으로 지연
• callServiceProvider.getObject()를 호출하는 시점에 스프링 컨테이너에서 빈을 조회함

  ApplicationContext

• 너무 많은 기능을 제공함

내부 호출 대안3. 구조 변경

• 내부 호출이 발생하지 않도록 구조를 변경함
• 가장 권장

AOP 적용 단위

• AOP는 주로 트랜잭션 적용이나 주요 컴포넌트의 로그 출력 기능에 사용함 (큰 단위)
• 인터페이스에 메서드가 나올 정도의 규모에 AOP를 적용하는 것이 적당함 = public 메서드에만 적용함 = private 메서드처럼 작은 단위에는 AOP를 적용하지 않음

한계 - 타입 캐스팅, 의존관계 주입

• AOP 프록시 만드는 2가지 방법
  • JDK 동적 프록시 : 인터페이스를 기반으로 프록시 생성 (인터페이스 필수)
  • CGLIB 프록시: 구체 클래스를 기반으로 프록시 생성
• 스프링이 프록시를 만들 때 제공하는 ProxyFactory에 proxyTargetClass 옵션
  • proxyTargetClass = false JDK 동적 프록시를 사용해서 인터페이스 기반 프록시 생성
  • proxyTargetClass = true CGLIB를 사용해서 구체 클래스 기반 프록시 생성
  • 참고로 옵션과 무관하게 인터페이스가 없으면 JDK 동적 프록시를 적용할 수 없으므로 CGLIB를 사용함

JDK 동적 프록시 한계

JDK 동적 프록시 - 캐스팅, 의존관계 주입

• 구체 클래스로 타입 캐스팅이 불가능함 (ClassCastException.class 예외가 발생함)
• 구체 클래스 타입에 의존관계 주입 불가능
• 인터페이스를 기반으로 생성된 프록시여서 구체 클래스에 대해서 전혀 알지 못하기 때문이다.

CGLIB 프록시 캐스팅, 의존관계 주입

• 구체 클래스로 타입 캐스팅이 가능함
• 구체 클래스로 의존관계 주입이 가능함
• 구체클래스를 기반으로 생성된 프록시여서 구체클래스는 물론이고, (인터페이스가 있을경우) 부모인 인터페이스로 캐스팅, 인터페이스로 의존관계 주입이 가능하다.

결론

• 실제로 개발할때는 인터페이스가 있으면 인터페이스를 기반으로 의존관계 주입을 받는게 맞음
  • DI 장점은 클라이언트 코드의 변경 없이 구현 클래스를 변경할 수 있다는 것이다.
  • 구현 클래스에 의존관계를 주입하면 향후 구현클래스 변경시 의존관계 주입을 받는 클라이언트의 코드도 함께 변해야 하기 때문
• 테스트, 다른 이유로 AOP 프록시가 적용된 구체 클래스를 직접 의존관계 주입 받아야 하는 경우가 있을 수 있는데, 이때는 CGLIB를 통해 구체 클래스 기반으로 AOP 프록시를 적용하면 됨

CGLIB 프록시 한계

• 구체 클래스를 상속 받기 때문에 문제 발생

  • 대상 클래스에 기본 생성자 필수
  • CGLIB 를 사용할 때 CGLIB가 만드는 프록시 생성자는 우리가 호출하는 것이 아니다.
  • CGLIB 프록시는 대상 클래스를 상속 받고, 생성자에서 대상 클래스의 기본 생성자를 호출함
  • 대상 클래스에 기본 생성자를 만들어야 함
  • 생성자 2번 호출 문제
  • 상속을 받으면 자식 클래스의 생성자를 호출할 때 부모 클래스의 생성자도 호출해야 함

  • 

    • 1. 실제 taget의 객체를 생성할 때
    • 2. 프록시 객체를 생성할 때 부모 클래스의 생성자 호출
  • final 키워드 클래스, 메서드 사용 불가
  • final 키워드가 클래스에 있으면 상속 불가능, 메서드에 있으면 오버라이딩 불가능
  • CGLIB는 상속을 기반으로 하기 때문에 두 경우 프록시가 생성되지 않거나 정상 작동하지 않음
  • 프레임 워크 같은 개발이 아니라 일반적인 웹 애플리케이션 개발할때는 final 키워드를 잘 사용하지 않아서 별 문제 안됨

스프링 부트 - CGLIB 기본 사용

• 대상 클래스에 기본 생성자 필수, 생성자 2번 호출 문제는 스프링 4.0 objenesis 라는 라이브러리를 사용해서 문제 해결함
• final 클래스나 메서드 문제는 잘 사용하지 않아 별 문제가 안됨
• CGLIB 사용하면 JDK 동적 프록시에서 동작하지 않는 구체 클래스 주입이 가능함
• 사실 개발자 입장에서는 어떤 프록시 기술을 사용해도 상관이 없음. 문제 없고, 개발하기 편리하면 됨