이슈
어플리케이션을 개발하던 도중 특정 프로세스에서 급격하게 느려지는 현상을 발견했다.
어떠한 특정 로직에서 병목현상이 발생하거나 혹은 필요없는 로직을 타고 있다는 의심이 들었고 각 메서드마다 성능을 측정해봐야 한다는 생각이 들었다.
가장먼저 떠오른 방법은 AOP 를 이용하는 방법 이었다.
AOP 를 이용해서 각각의 메서드를 측정하여 평균 시간이 오래 걸리는 로직순서대로 하나씩 확인해 볼 예정이었다.
문제해결
1. 리플렉션과 커스텀 애노테이션
모든 메서드의 성능을 확인할 필요는 없다.
특정 프로세스에서 느려지는 현상을 확인하기 위해 모든 메서드에 AOP를 적용하게 된다면 전체적으로 성능이 느려질 것 이고 그에 따라서 제대로 된 성능을 확인하기 어려울 것이라고 생각했다.
제한된 컴퓨팅 파워에서 성능 측정을 위한 최소한의 설계 방식을 어떠한 방법으로 해결할 수 있을 까 생각을 했고 리플렉션을 이용하기로 했다.
커스텀 어노테이션을 이용하여 성능 측정을 원하는 메서드에 적용시키는 방법을 통해 컴퓨팅 파워에 영향을 줄 수 있는 요소를 줄이는 방식을 사용했다.
2. 전파 단위
하나의 프로세스는 수많은 객체의 상호작용을 통해 동작한다.
매우 많은 클래스들이 선언되고 그 과정에서 모든 메서드 들이 특정 프로세스를 위해 동작하는 것은 아니기 때문에 성능 측정을 원하는 메서드에 AOP를 개별적으로 적용시킬 필요가 있었다.
사실상 말이 안된다.
메서드 하나하나 따라가서 호출되는 연쇄적인 모든 메서드에 커스텀 어노테이션을 달아주는건 너무 비효율적이기 때문이다.
따라서 메서드가 전파될 수 있는 최상위 메서드에 어노테이션을 적용시킨다면 최상위 메서드가 호출하는 서브 메서드들이 전부다 AOP의 영향을 받을 수 있도록 설계 해야 했다.
class A 의 최상위 메서드에 어노테이션을 적용시키면 그 메서드 들이 호출하는 다른 클래스의 서브 메서드들도 다 영향을 받을 수 있도록 전이 시켰다.
해결 방법은 생각보다 단순했다.
최상위 메서드가 호출되는 순간 플래그를 on, 리턴후 플래그를 off 하여 플래그의 여부에 따라서 AOP의 적용 여부를 선택했다.
물론 이 과정에 있어서 단순히 어노테이션의 적용범위를 메서드에 국한하지 않고 클래스 범위로 확장하는 변경을 진행해야 했다.
하지만 해당 어플리케이션은 단일 스레드로 동작하지 않는다.
3. 멀티 쓰레드
총 8개의 작은 프로세스들이 상호작용하며, 명시적 선언을 통해 가용하는 쓰레드만 11개인 어플리케이션에서 위와 같은 단순 플래그를 통해 AOP를 적용시키면 최 상위 메서드가 해당 어노테이션을 품지 않고 있더라도 최상위 메서드로부터 호출되는 서브 메서드가 AOP에 적용될 가능성이 생긴다.
4. 메세징 큐 구조
카프카를 사용하지는 않았지만 기본적으로 메세징 큐 구조로 구현되어있는 프로세스이다 보니 최상위 메서드에서 호출하는 서브 메서드에 AOP를 전파 한다고 하더라도 최종적으로 엔드 투 엔드의 동작 과정에 있어서 AOP 가 모든 메서드에 적용되지 않는 문제가 발생했다.
메세징 큐에서 스케줄러를 통해서 메세징 큐에 task 가 있는지 확인하고 체크하는 과정도 AOP를 적용할 수 있는 방법을 찾아야 했다.
5. 성능 측정의 지표
이정도의 성능이 나온다 라는 것을 얘기할 수 있는 성능을 어떠한 방식으로 보여줄 것 인가?
db 저장방식? -> 어떤 데이터를 저장할 것인지 ? 매번 db에 저장하는지 뭐 이런것들에 대한 부분 .
상세 설명
