OpenFeign 도입을 고민해보자

Posted on

마이크로서비스 개발에 있어서 OpenFeign 활용에 대한 부분이 아닌 작은 모놀리식으로 구성된 소규모 시스템에서도 Apache HttpClient를 직접적으로 사용하지 않고 어노테이션과 인터페이스 기반의 선언적으로 통신에 대한 로직을 작성하는 것을 고민하게 되는 부분을 적어보고자 한다.

통신 로직에 대한 반복적인 코드 작성

RestTemplate와 HttpClient를 직접적으로 사용하여 통신에 대한 코드를 작성하는 경우 URI 구성과 쿼리 파라미터 그리고 폼 데이터 또는 요청 데이터 그리고 응답 결과에 대한 데이터 처리까지 아래와 같은 부분들이 강제화 되어버리는 경우가 많은 것 같다.

ObjectMapper objectMapper = new ObjectMapper();
LoginEntity login = objectMapper.readValue(json, new TypeReference<>(){});

통신해야하는 시스템에서 제공하는 REST API 규격에 따라 쿼리 파라미터 또는 요청 데이터를 직접 구성해야하고 전달받은 응답에 대하여 위와 같이 직접적으로 원하는 모델 클래스로 변환하는 코드를 작성해야만 한다. 이것은 스프링 백엔드 개발자가 Spring MVC의 컨트롤러를 작성하는 것과는 다른데 OpenFeign 클라이언트는 선언적인(Declarative) 방식을 통해 이러한 과정을 간소화하고 Spring MVC와 비슷한 방식으로 작성됨에 따라서 시스템 간 연동을 위한 통신 로직을 작성하고 관리하기 용이한 장점을 가지고 있는 것 같다.

의존 시스템에 대한 장애 처리 부족

마이크로서비스 구성이 아닌 일반적인 소규모 시스템에서 RestTemplate와 HttpClient를 직접적으로 사용하다보면 시스템 간 통신에 대한 오류와 재시도 방안에 대한 고민을 하지 않고 무시하게 되는 경우가 많다. OpenFeign은 마이크로서비스 개발에 사용되어지는 만큼 마이크로서비스에서 중요시하게 되는 장애 전파 방지에 대한 부분을 고려할 수 있다.

마이크로서비스 구성 확장에 대한 고려

모놀리식 아키텍처로 구성되는 소규모 시스템도 현재 시스템 규모와 요구사항을 넘어 대규모 트래픽 또는 데이터를 처리하기 위한 시스템으로 확장되는 것을 목표로 하는 경우가 대부분이다. 현재 신규 프로젝트도 마이크로서비스 구성을 목표로 초기 설계가 되어있음에 따라 Spring Cloud 모듈에 대한 의존성을 보유하고 있다. Spring Cloud OpenFeign 로 작성되어있는 경우 서비스 디스커버리를 위한 Eureka와 장애 처리를 위한 Resilience4J 과의 통합이 용이하다고 한다.

이와 같이 마이크로서비스 아키텍처가 아니더라도 외부 시스템 또는 시스템 간 통신이 많은 시스템의 프로젝트라면 OpenFeign 클라이언트 도입을 고려해볼만하지 않을까? 물론, Feign 코드 분석과 서버 성능 개선 에서처럼 문제가 내재되지 않는 건 아님을 감안하긴 해야겠지만 말이다.

🔥 FeignClient 에서 GET 대신에 POST 요청이 되는 이유

FeignClient에 대한 간단한 예제 코드를 작성해보던 중에 GET 요청이 POST로 전환되어 요청되는 문제를 경험했다. GET 요청 시 쿼리 파라미터를 전달하기 위해서는 @SpringQueryMap를 해당 파라미터에 선언해야하더라. 쿼리 파라미터가 전달되지 않는 경우가 아닌 선언된 요청 함수가 바뀌어버리는 건 신기한 부분이다.