Aspect Instantiation Models, An AOP Example, Proxying Mechanisms

https://sundaland.tistory.com/90

[ ▶ Aspect Instantiation Models ]

기본적으로 각 aspect는 애플리케이션 컨텍스트 내에서 단일 인스턴스를 가진다. AspectJ에서는 이를 싱글톤 인스턴스화 모델이라고 부른다. 하지만 다른 생명 주기를 가진 aspect를 정의한 것도 가능하다. 스프링은 AspectJ의 perthis, pertarget, pertypewithin 인스턴스화 모델을  지원하며, percflow 및 percflowbelow는 현재 지원하지 않는다.

@Aspect 어노테이션에서 perthis 절을 지정하여 perthis aspect를 선언할 수 있다.

@Aspect("perthis(execution(* com.xyz..service.*.*(..)))")
public class MyAspect {

    private int someState;

    @Before("execution(* com.xyz..service.*.*(..))")
    public void recordServiceUsage() {
        // ...
    }
}

perthis 절의 효과는 비즈니스 서비스를 수행하는 각 고유한 서비스 객체 (포인트 컷 표현식에 의해 매칭되는 조인 포인트에서 this에 바인딩된 고유 객체)마다 하나의 aspect 인스턴스가 생성된다는 것이다. 서비스 객체의 메서드가 처음 호출될 떄 aspect 인스턴스가 생성된다. 서비스 객체가 스코프에서 벗어나면 aspect도 스코프에서 벗어난다. aspect 인스턴스가 생성되기 전에는 그 안에 선언된 advice는 실행되지 않는다. aspect가 인스턴스가 생성되며느 해당 인스턴스와 연결된 서비스 객체가 참여하는 매칭된 조인 포인트에서 선언된 advice가 실행된다.

pertarget 인스턴스화 모델은 perthis와 동일한 방식으로 작동하지만, 매칭된 조인 포인트에서 각 고유한 타겟 객체마다 하나의 aspect 인스턴스를 생성한다.

 

[ ▷ AOP 예제 ]

비즈니스 서비스의 실행은 떄때로 동시성 문제 (교착 상태에서 패배 등)가 원인이 되어 실패할 수 있다. 만약 작업을 다시 시도하면, 다음 시도에서 성공할 가능성이 높다. 이러한 상황에서 다시 시도하는 것이 적절한 비즈니스 서비스 (사용자에게 충돌 해결을 위해 다시 돌아갈 필요가 없는 멱등 연산)에서는 클라이언트가 PessimisticLockingFailureException을 보지 않도록 작업을 투명하게 재시도해야 한다. 이러한 요구사항은 서비스 계층의 여러 서비스에 걸쳐 발생하므로, aspect로 구현하기에 이상적이다.

작업을 다시 시도하려면, 여러 번 proceed를 호출할 수 있도록 around advice를 사용해야 한다. 아래 예제넌 기본적인 aspect 구현이다.

@Aspect
public class ConcurrentOperationExecutor implements Ordered {

    private static final int DEFAULT_MAX_RETRIES = 2;

    private int maxRetries = DEFAULT_MAX_RETRIES;
    private int order = 1;

    public void setMaxRetries(int maxRetries) {
        this.maxRetries = maxRetries;
    }

    public int getOrder() {
        return this.order;
    }

    public void setOrder(int order) {
        this.order = order;
    }

    @Around("com.xyz.CommonPointcuts.businessService()") 
    public Object doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
        int numAttempts = 0;
        PessimisticLockingFailureException lockFailureException;
        do {
            numAttempts++;
            try {
                return pjp.proceed();
            }
            catch(PessimisticLockingFailureException ex) {
                lockFailureException = ex;
            }
        } while(numAttempts <= this.maxRetries);
        throw lockFailureException;
    }
}

여기서 businessService라는 이름의 포인트컷을 참조하는 부분은 Named Pointcut 정의에서 가져온 것이다.

이 aspect는 Orderd 인터페이스를 구현하며, 트랜잭션 어드바이스보다 높은 우선순위를 가지도록 설정할 수 있다. (재시도할 때마다 새로운 트랜잭션을 원하기 때문이다). maxRetries와 order 속성은 스프링에 의해 구성된다. 주요 동작은 doConcurrentOperation around advice에서 발생한다. 현재는 모든 buinessService에 재시도 로직을 적용한다. 먼저 proceed를 시도하고, PessimisticLockingFailureException이 발생하면 재시도한다. 단, 모든 재시도 기회를 다 소진했을 경우에는 예외를 다시 던진다.

<aop:aspectj-autoproxy/>

<bean id="concurrentOperationExecutor"
        class="com.xyz.service.impl.ConcurrentOperationExecutor">
    <property name="maxRetries" value="3"/>
    <property name="order" value="100"/>
</bean>

이  aspect를 멱등 연산에만 재시도하도록 개선하기 위해, 다음과 같은 Idempotend 어노테이션을 정의할 수 있다.

@Retention(RetentionPolicy.RUNTIME)
// 마커 애노테이션
public @interface Idempotent {
}

그런 다음 이 어노테이션을 서비스 연산의 구현에 적용할 수 있다. 멱등 연산에만 재시도하도록 aspect를 변경하려면 포인트컷 표현식을 수정하여 @Idempotent 어노테이션이 적용된 연산만 매칭되도록 해야 한다.

@Around("execution(* com.xyz..service.*.*(..)) && " +
        "@annotation(com.xyz.service.Idempotent)")
public Object doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
    // ...
}

 

[ ▷ Proxying Mechanisms ]

스프링 AOP는 지정된 타겟 객체에 대해 JDK 동적 프록시 또는 CGLIB을 사용하여 프록시를 생성한다. JDK 동적 프록시는 JDK에 내장되어 있는 반면, CGLIB은 일반적인 오픈 소스 클래스 정의 라이브러리로, Spring Core에 재패키징되어 있다.

프록시 대상 객체가 하나 이상의 인터페이스를 구현하는 경우 JDK 동적 프록시가 사용된다. 이때 타겟 타입이 구현하는 모든 인터페이스가 프록시된다. 반면, 타겟 객체가 인터페이스를 구현하지 않는 경우 CGLIB 프록시가 생성된다.

모든 메서드 (인터페이스에서 구현한 메서드뿐만 아니라 타겟 객체에 정의된 모든 메서드)를 프록시하려면 CGLIB 프록시를 강제로 사용하도록 설정할 수 있다. 그러나 다음과 같은 문제를 고려해야 한다.

• CGLIB을 사용하는 경우, final 메서드는 런타임 생성된 서브클래스에서 오버라이드할 수 없으므로 어노테이션을 적용할 수 없다.
• 스프링 4.0 부터는 더 이상 프록시된 객체의 생성자가 두 번 호출되지 않는다. 이는 CGLIB 프록시 인스턴스가 Objenesis를 통해 생성되기 때문이다. 단 JVM이 생성자 우회를 허용하지 않는 경우, 생성자가 두 번 호출되는 것과 관련된 디버그 로그 항목을 볼 수 있다.
• CGLIB 프록시 사용은 JDK 9+ 플랫폼 모듈 시스템에서 제한될 수 있다. 일반적인 경우로, 모듈 경로에서 배포할 때 java.lang 패키지의 클래스를 프록시로 생성할 수 없다. 이러한 경우 JVM 부트스트랩 플래그  --add-opens=java.base/java.lang=ALL-UNNAME가 필요하지만, 이는 모듈에서 사용할 수 없다.

CGLIB 프록시 사용을 강제하려면 <aop:config> 요소의 proxy-target-class 속성 값을 true로 설정한다.

<aop:config proxy-target-class="true">
    <!-- 다른 빈 정의는 여기... -->
</aop:config>

@AspectJ 자동 프록시 지원을 사용할 때 CGLIB 프록시를 강제하려면 <aop:aspectj-autoproxy> 요소의 proxy-target-class 속성 값을 true로 설정한다.

<aop:aspectj-autoproxy proxy-target-class="true"/>

여러 <aop:config/> 섹션이 런타임 시 단일 통합 자동 프록시 생성기로 병합되며, 이는 각 <aop:config/> 섹션(일반적으로 다른 XML 빈 정의 파일에서 지정됨)이 지정한 가장 강력한 프록시 설정을 적용한다.. 이 규칙은 <tx:annotation-driven/> 및 <aop:aspectj-autoproxy/> 요소에도 적용된다.

따라서 <tx:annotation-driven/>, <aop:aspectj-autoproxy/>, 또는 <aop:config/> 요소에 proxy-target-class="true"를 사용하면 세 요소 모두에 대해 CGLIB 프록시 사용이 강제된다.

 

 

[ ▷ Understanding AOP Proxies ]

스프링 AOP는 프록시 기반이다. 이 문장이 실제로 의미하는 바를 충분히 이해하는 것이 매우 중요하다. 그래야 자신만의 aspect를 작성하거나 스프링 프레임워크에서 제공하는 AOP 기반 aspect를 사용할 때 제대로 활용할 수 있다.

먼저 프록시가 적용되지 않은 일반 객체 참조가 있는 시나리오는 아래와 같다.

public class SimplePojo implements Pojo {

    public void foo() {
        // 다음 메서드 호출은 'this' 참조에 대한 직접 호출입니다.
        this.bar();
    }

    public void bar() {
        // 일부 로직...
    }
}

객체 참조에서 메서드를 호출하면 해당 객체 참조에서 메서드가 직접 호출된다.

public class Main {

    public static void main(String[] args) {
        Pojo pojo = new SimplePojo();
        // 이것은 'pojo' 참조에서의 직접 메서드 호출입니다.
        pojo.foo();
    }
}

 

클라이언트 코드가 가진 참조가 프록시인 경우에는 상황이 약간 달라진다.

public class Main {

    public static void main(String[] args) {
        ProxyFactory factory = new ProxyFactory(new SimplePojo());
        factory.addInterface(Pojo.class);
        factory.addAdvice(new RetryAdvice());

        Pojo pojo = (Pojo) factory.getProxy();
        // 이것은 프록시에 대한 메서드 호출입니다!
        pojo.foo();
    }
}

여기서 이해해야할 핵심은 Main 클래스의 main(..) 메서드 내 클라이언트 코드가 프록시에 대한 참조를 가진다는 점이다. 이는 객체 참조에서의 메서드 호출이 프록시에 대한 호출임을 의미한다. 그 결과 프록시는 해당 메서드 호출과 관련된 모든 인터셉트 (조언)에 위음할 수 있다. 그러나 호출이 결국 타겟 객체에 도달하면 (이 경우 SimplePojo 참조), 그 객체가 자신에게 호출하는 모든 메서드 (this.bar() 또는 this.foo()등)은 프록시가 아닌 this 참조에 대해 호출된다. 이는 중요한 함의를 가지고 있다. 자기 호출 (Self-invocation)에서는 메서드 호출과 관련된 조언이 실행될 기회를 얻지 못하게 된다.

이 문제를 해결하기 위한 가장 좋은 방법은 자기 호출이 발생하지 않도록 코드를 리팩터링하는 것이다. 이는 일부 작업을 필요로 하지만, 가장 적게 침입하는 최선의 접근 방식이다. 다음 접근 방식은 클래스내 로직을 완전히 스프링 AOP에 결합하는 것이다.

public class SimplePojo implements Pojo {

    public void foo() {
        // 이렇게 하면 되지만... 정말 별로입니다!
        ((Pojo) AopContext.currentProxy()).bar();
    }

    public void bar() {
        // 일부 로직...
    }
}

이 접근 방식은 코드와 스프링 AOP를 완전히 결합시키며, 클래스 자체가 AOP 컨텍스트에서 사용된다는 사실을 인지하게 한다. 이는 AOP 취지에 어긋난다. 또한 프록시를 생성할 떄 추가 구성을 필요로 하며, 아래와 같은 구성을 요구한다.

public class Main {

    public static void main(String[] args) {
        ProxyFactory factory = new ProxyFactory(new SimplePojo());
        factory.addInterface(Pojo.class);
        factory.addAdvice(new RetryAdvice());
        factory.setExposeProxy(true);

        Pojo pojo = (Pojo) factory.getProxy();
        // 이것은 프록시에 대한 메서드 호출입니다!
        pojo.foo();
    }
}

마지막으로 AspectJ는 프록시 기반의 AOP 프레임워크가 아니기 때문에 자기 호출 문제를 가지고 있지 않다는 점에 유의해야 한다.