OpenFeign에 INFO 레벨 로그 추가하기 (2/2): 로그 설정과 Configuration 고민

저번 글에서는 WireMock을 활용해 Clova AI(외부) 서버를 모킹하는 방법을 다뤘습니다. 이를 통해 Clova 서버를 호출하지 않음으로써 비용 발생 없이, @FeignClient 에 logger-level: FULL 설정이 잘 적용 되었는지를 확인하는 과정을 살펴봤습니다.

 

이번 글에서는 INFO 레벨에서 Feign 로그를 출력하도록 커스터마이징하는 방법을 소개하려 했지만, 이미 이를 다룬 좋은 글들이 많아 해당 주제를 간단히 넘어가고, OpenFeign의 @Configuration 설계 과정에서 고민했던 점을 공유하고자 합니다.

 

Feign 커스터마이징 관련 좋은 글

• 우아한 feign 적용기
• 망나니 개발자님의 OpenFeign 설명 과 Github
• (tistory) FeignClient Logging 방법 정리

1. INFO 레벨 로그를 위한 @Configuration 설정

INFO 로그가 모든 @FeignClient에 적용되도록 하기 위해 @Configuration을 활용하여 설정 클래스를 작성했습니다.
@Configuration은 내부의 @Bean 메서드들을 CGLIB 라이브러리를 통해 처리하며, 수동으로 등록된 빈을 싱글톤으로 관리합니다. 그리고, @Configuration 내에서 설정된 것들은 @EnableFeignClients가 탐색하는 모든 Feign 클라이언트에 적용됩니다.

 

로그 커스터마이징 코드

logRequest와 logAndRebufferResponse 메서드를 재정의해 INFO 레벨에서 필요한 로그를 출력하도록 설정합니다. 전체 코드는 Github에 있습니다.

 

@EnableFeignClients를 @SpringBootApplication 이 아닌 @Configuration에 붙인 이유

해당 글을 참고하여 WebMvcTest, DataJpaTest와 같이 Feign 관련 빈이 필요하지 않은 테스트에서 불필요한 Feign 빈이 자동으로 설정되는 것을 방지합니다.

@EnableFeignClients("bsise.server")
@Configuration
public class FeignGlobalConfig {

    @Bean
    Logger.Level feignLoggerLevel() {
        return BASIC; // Log.LEVEL 은 NONE -> BASIC -> HEADERS -> FULL 순으로 상세하게 로그가 출력됨
    }

    @Bean
    public CustomFeignLogging customFeignLogging() {
        return new CustomFeignLogging();
    }

    @Slf4j
    public static class CustomFeignLogging extends Logger {

        @Override
        protected void logRequest(String configKey, Level logLevel, Request request) {
            if (logLevel.ordinal() >= HEADERS.ordinal()) {
                super.logRequest(configKey, logLevel, request);
                return;
            }
            String stringBody = createRequestStringBody(request);
            log.info("[threadId={}] ---> {} {} {} [Body]: {}",
                    Thread.currentThread().getId(),
                    request.httpMethod(),
                    request.url(),
                    request.protocolVersion(),
                    stringBody);
        }

        private String createRequestStringBody(Request request) {
            return request.body() == null ? "" : new String(request.body(), StandardCharsets.UTF_8);
        }

        // 응답이 400번대 이상이면 INFO 레벨이 아닌 WARN / ERROR 로 남기고자 함.
        @Override
        protected Response logAndRebufferResponse(String configKey, Level logLevel, Response response, long elapsedTime)
                throws IOException {
            if (logLevel.ordinal() >= HEADERS.ordinal() || response.status() >= 400) {
                return super.logAndRebufferResponse(configKey, logLevel, response, elapsedTime);
            }
            byte[] byteArray = getResponseBodyByteArray(response);
            log.info("[threadId={}] <--- {} {} ({}ms) [Body]: {}",
                    Thread.currentThread().getId(),
                    response.protocolVersion(),
                    response.status(),
                    elapsedTime,
                    new String(byteArray, StandardCharsets.UTF_8));

            return response.toBuilder().body(byteArray).build();
        }

        private byte[] getResponseBodyByteArray(Response response) throws IOException {
            if (response.body() == null) {
                return new byte[]{};
            }
            return StreamUtils.copyToByteArray(response.body().asInputStream());
        }

        /**
         * CustomFeignLogging 을 빈으로 등록하고, log()와 format()이 없으면 feign 로그 레벨이 HEADERS 이상일 떄, DEBUG 레벨의 로그가 나오지 않음
         */
        @Override
        protected void log(String configKey, String format, Object... args) {
            log.debug(format(configKey, format, args));
        }

        protected String format(String configKey, String format, Object... args) {
            return String.format(methodTag(configKey) + format, args);
        }
    }
}

 

2. ErrorDecoder 구현

위와 같은 설정으로 끝내면 300번대~500번대 응답이 왔을 때, customFeignLogging 의 log() 의해 DEBUG 레벨로 출력됩니다. 저는 400번대와 500번대 응답이 왔을 때, ERROR 레벨의 로그로 출력하길 원했습니다. Clova 서버를 호출하지 못하는 것은 저희 프로젝트 상 매우 중요해서 즉각 대응해야 했기 때문입니다. (OpenFeign은 기본적으로 200번대 응답만을 성공으로 간주하며, 그 외의 응답에 대해서는 ErrorDecoder가 동작합니다.)

 

Implement this method in order to decode an HTTP Response when Response.status() is not in the 2xx range. Please raise application-specific exceptions where possible

* ErrorDecoder 문서 중 일부

 

이에 따라, 200번대 외의 응답을 핸들링할 수 있도록 ErrorDecoder를 상속한 설정 클래스를 추가로 작성했습니다.

 

GlobalFeignConfig와 ClovaFeignConfig를 분리한 이유

• ErrorDecoder는 Feign 클라이언트별로 개별 설정이 필요하다고 판단했습니다.
• 따라서, ClovaFeignConfig 는 모든 @FeignClient에 적용되지 않도록 @Configuration을 생략했습니다.
•  

. 전체 코드는 Github에 있습니다.

@Slf4j
public class ClovaFeignConfig {

    @Bean
    public CustomClovaFeignErrorDecoder customClovaFeignErrorDecoder() {
        return new CustomClovaFeignErrorDecoder();
    }

    @Slf4j
    static class CustomClovaFeignErrorDecoder implements ErrorDecoder {

        @Override
        public Exception decode(String methodKey, Response response) {
            ... Response 에서 300번대 ~ 500번대에 일 경우 비즈니스에 맞게 예외 처리
        }
    }
}

그리고, ClovaFeignConfig 를 사용하려는 @FeignClient 에 속성을 추가합니다.

@FeignClient(name = "clova-service", url = "${feign.clova.url}", configuration = ClovaFeignConfig.class)

 

3. @Configuration 없이 @Bean 메서드 호출

customFeignErrorDecoder는 @Bean 메서드로 정의되었지만, 해당 클래스(ClovaFeignConfig)에 @Configuration이 없기 때문에 빈으로 등록되지만 Spring 컨테이너가 싱글톤으로 관리하지 않는 빈(Bean)입니다. 따라서 이 메서드가 호출될 때마다 새로운 인스턴스가 생성됩니다.

 

의문: 생성된 인스턴스는 Spring 컨텍스트 종료 시까지 살아남을까?

정말 만에 하나 @Bean 어노테이션이 붙어 있기 때문에, Spring 컨텍스트가 종료될 때 생성된 인스턴스들도(@Bean) 함께 소멸할 가능성이 있지 않을까라는 의문이 들었습니다. 만약, 이 메서드가 호출될 때마다 생성된 인스턴스들이 Spring 컨텍스트 종료 시점까지 메모리에 남아 있다면, 이는 메모리 릭 문제로 이어질 수 있습니다.

 

Spring 공식 문서에 따르면

• @Configuration이 없는 클래스에서 선언된 @Bean 메서드는 Spring 컨테이너에 의해 관리되지 않습니다.
• 이러한 메서드는 일반적인 팩토리 메서드처럼 동작하며, 호출 시마다 새로운 인스턴스를 생성합니다.
• 생성된 인스턴스는 Spring 컨테이너와 무관하게 동작합니다.

이러한 이유로 @Configuration 없는 @Bean 메서드는 일반 메서드 호출처럼 동작하며, Spring의 생명주기 관리 대상이 아님을 명확히 알 수 있습니다.

 

Spring 공식 문서 중 일부

When @Bean methods are declared within classes that are not annotated with @Configuration - or when @Configuration(proxyBeanMethods=false) is declared -, they are referred to as being processed in a "lite" mode. In such scenarios, @Bean methods are effectively a general-purpose factory method mechanism without special runtime processing (that is, without generating a CGLIB subclass for it). A custom Java call to such a method will not get intercepted by the container and therefore behaves just like a regular method call, creating a new instance every time rather than reusing an existing singleton (or scoped) instance for the given bean.

 

 

마치며 .. 

이번 프로젝트에서 발생한 문제를 해결하기 위해 OpenFeign의 일부 기능, 특히 로깅에 집중해 학습하고 활용해 보았습니다. 하지만 공식 문서의 일부만 다룬 것에 불과하다니, OpenFeign과 FeignClient를 활용한 다양한 상황을 더 경험해보고 싶어집니다. 아직 부족한 점이 많지만, 부족한 부분과 다양한 경험을 댓글로 알려주시면 계속 배우고 노력하며 성장해 나가겠습니다. 두서없는 글을 끝까지 읽어주셔서 감사합니다.

 

참고 

- Spring Cloud OpenFeign Docs