[Project] 서비스간 통신방식 고민 (OpenFeign/WebClient)
Categories: Project
📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]
서비스 간 통신 방식
그룹웨어 프로젝트 중에 모든 것에 연관관계를 지니고 있는 Employee가 core-api에는 없어서 employee를 어떻게 가져올까 하고 고민하던 와중에 커뮤니티 방식에는 동기방식과 비동기방 식이 있다고 한다.
동기는 작업이 마무리되어야 다른 작업으로 넘어갈 수 있는 방식(순차적)과
비동기방식은 AMQP라는 방식으로 연결되어있는 모든 서비스에게 전달하는 방식이 있다
동기 방식
동기 방식은 요청을 보내고 응답을 받을 때까지 기다리는 방식으로, 작업이 완료되어야 다음 작업으로 넘어갈 수 있는 순차적인 처리 방식을 의미한다. 대표적인 동기 통신 방법으로는 RestTemplate과 OpenFeign이 있다.
- RestTemplate
- Spring에서 제공하는 RestTemplate은 전통적으로 많이 사용된 동기 방식의 HTTP 클라이언트
- 다른 API를 호출하기 위해 간편하게 사용할 수 있으며, 다양한 HTTP 메서드를 지원하여 유연한 API 호출이 가능하다.
- 장점
- 사용이 간편하고 직관적이다.
- 다양한 HTTP 메서드와 설정을 지원하여 유연한 API 호출이 가능하다.
- Spring의 다른 기능들과 쉽게 통합할 수 있다.
- 단점
- 동기 방식이기 때문에 응답을 기다리는 동안 블로킹이 발생할 수 있다.
- 높은 부하가 걸릴 경우 성능 저하가 발생할 수 있다.
-
OpenFeign
OpenFeign은 선언적인 REST 클라이언트로,
인터페이스 기반의 선언을 통해 간편하게 HTTP API를 호출할 수 있다.
Spring Cloud와 함께 사용되며, 라운드로빈 방식의 로드 밸런싱을 쉽게 구현할 수 있다.
- 장점
- 선언적인 방식으로 코드가 간결해진다.
- Spring Cloud와의 통합을 통해 로드 밸런싱, 재시도 등의 기능을 쉽게 활용할 수 있다.
- 다양한 인코딩/디코딩 옵션을 지원하여 유연한 API 호출이 가능하다.
- 단점
- 설정이 다소 복잡할 수 있다.
- 동기 방식이 기본이기 때문에 비동기 방식의 요구사항에는 추가적인 구현이 필요하다.
- 장점
비동기 방식
비동기 방식은 요청을 보낸 후 응답을 기다리지 않고 다음 작업을 진행하는 방식으로
주로 메시지 큐(예: AMQP)를 사용하여 여러 서비스에 데이터를 전달한다.
- AMQP (Advanced Message Queuing Protocol)
- AMQP는 메시지 브로커를 통해 메시지를 전달하는 프로토콜
- RabbitMQ와 같은 메시지 브로커와 함께 사용된다.
- 비동기 방식의 대표적인 통신 방법으로, 서비스 간의 결합도를 낮추고 높은 확장성을 제공한다.
- 장점
- 높은 확장성을 제공한다.
- 응답 시간을 기다리지 않아 전체 시스템의 성능을 향상시킨다.
- 실패한 요청을 재시도하거나 메시지를 저장해두는 등 유연한 에러 핸들링이 가능하다.
- 단점
- 구현이 상대적으로 복잡하다.
- 메시지 순서 보장이나 중복 처리 등 추가적인 관리가 필요하다.
-
WebClient
Spring 5에서 도입된 비동기 HTTP 클라이언트로, 리액티브 프로그래밍을 지원하며 비동기 방식으로 API를 호출할 수 있다.
- 장점
- 비동기 및 논블로킹 방식으로 높은 성능 향상
- 리액티브 스트림을 활용해 데이터 흐름을 효율적으로 관리 가능
- WebClient는 비동기식 뿐만 아니라 동기식 방식으로도 사용할 수 있어, 기존의 RestTemplate를 대체할 수 있다
- 비동기 처리를 통해 시스템의 확장성을 높일 수 있었다.
- 단점
- 리액티브 프로그래밍의 복잡성: 리액티브 프로그래밍에 대한 이해가 필요하여 학습 곡선이 존재
- 코드의 복잡성: 비동기 및 리액티브 특성으로 인해 코드가 복잡해질 수 있었다.
- 장점
동기방식을 선택하면 빈번하게 요청이 되는 employee같은 경우 응답시간이 길어지고 성능에 영향을 많이 줄 것 같았고
비동기 방식을 도입하면 성능 향상을 시킬 수 있다고 해서 도입해보고 싶었지만 가장 큰 걱정은 구현의 복잡성이 컸다. 순서 보장 문제도 익히 들어봐서 이걸 컨트롤 할 수 없을 것 같았다.
다양한 통신 방식을 생각해봤지만, 결국 OpenFeign 방식을 선택했다.
- 선언적인 API 호출의 간편함
- OpenFeign은 인터페이스 기반의 선언적인 방식으로 API를 호출할 수 있어, 코드가 간결해지고 유지보수가 용이함
- Spring Cloud와의 원활한 통합
- Spring Cloud와의 통합을 통해 로드 밸런싱, 재시도 등의 기능을 쉽게 활용할 수 있었다.
- 특히, Ribbon과 같은 클라이언트 사이드 로드 밸런서를 함께 사용하여, 라운드로빈 방식으로 요청을 고르게 분산시킬 수 있다.
- 유연한 설정과 확장성
- OpenFeign은 다양한 인코딩/디코딩 옵션을 지원하여, 다양한 API 호출 시 유연하게 대응할 수 있다.
- 또한, 커스터마이징이 용이하여 프로젝트의 요구사항에 맞게 설정을 조정할 수 있다.
- 비동기 방식의 복잡성 회피
- 비동기 방식의 통신을 도입하는 과정에서 발생할 수 있는 복잡성과 관리의 어려움을 고려했을 때, 현재 프로젝트의 요구사항과 팀의 역량을 고려하여 동기 방식의 OpenFeign을 사용하는 것이 더 적합하다고 판단했다.
아무래도 프로젝트 해야될 것이 산더미고 면접보고 코테보러다니는 팀원도 있어서 온전히 덜어둘 것은 덜어두고 일단 요구사항 상부터 쳐낸 다음에 고려해 봐야 할 것 같다.
OpenFeign은 호출이 정말 간편해서 빠르게 개발할 수 있었지만 나중에 프로젝트가 끝나더라도 추후에 보완을 한다면 시스템 확장성과 유지보수 고려해서 비동기 방식을 도입하는 것도 해보고 싶다.
Leave a comment