[성능튜닝] 반복적인 vault 서버 호출 제거하기

성능 테스트 시 vuser 임계치를 설정하고, Scouter를 통한 병목구간 분석하여 TPS를 개선한 경험을 공유합니다.

Scouter의 XLog 분석하기

 

Scouter xLog

Scouter의 xLog를 드래그하면 각 응답마다 아래와 같은 항목들을 볼 수 있습니다.

1. Elasped Time
2. CPU
3. SQL Count
4. SQL Time
5. API Count
6. API Time

위의 항목 중 응답속도 기준(Elasped Time)으로 정렬하여 가 제일 오래 걸린 구간을 확인했습니다.

 

 

눈에 띄는 구간은 두 구간이 있었습니다.

(1) 구간 - Ngrinder의 RampUp 설정으로 인한 초기 응답속도 지연구간으로 추측했습니다.

(2) 구간 - API Time이 올라가여 상세 호출 메서드를 확인하였습니다. 

 

 

해당 메서드는 ngrinder 테스트 API 호출 전 Security Filter적용을 위한 접근 가능한 url정보를 vault서버로부터 받아오는 메서드였습니다. 코드를 확인하면 해당 Filter를 검사하기 위해 vault 서버를 호출하는 것을 확인할 수 있었습니다.

 

 

반복적인 호출을 개선하기 위해 접근 가능한 url을 호출하는 로직을 Bean으로 등록하였습니다. Application이 부팅될 때 한 번만 호출하여 반복적인 호출을 제거하였습니다. UrlProps라는 inner class를 두어 url 정보를 담았습니다. 사용하는 쪽에서 NameSpace를 알 수 있도록 Inner Class로 생성하였습니다.

 

@RequiredArgsConstructor
@Configuration
@EnableWebSecurity
public class SecurityConfig {

    private final ObjectMapper objectMapper;
    private final JwtTokenProvider jwtTokenProvider;
    private final VaultOperationService vaultOperationService;

    @Bean
    public UrlProps urlProps() {
        return vaultOperationService.getProps(VAULT_PATH, VAULT_URL_SECRETES, UrlProps.class);
    }

	//중간생략
    
    public record UrlProps(String url) {
        public UrlProps {
            Assert.notNull(url, "url must not null");
        }
    }

}

 

shouldNotFilter 메서드에는 bean으로 동륵된 urlProps를 사용하여 반복적인 vault 서버 호출을 줄였습니다.

 

성능 튜닝 결과

튜닝 전 376.2 TPS에서 400TPS로 개선된 것을 확인할 수 있었습니다. 아래와 같이 동일한 테스트를 3번 반복한 이유는 네트워크 환경 및 외부요소에 의한 영향을 고려하여 성능테스트를 세번 반복하여 TPS를 계산하였습니다.

 

---

[참고]

책 - 자바 트러블 슈팅

책 - 실무로 배우는 시스템 성능 최적화