코딩블로그
Spring에서 API 연동 도구 선택(feat: WebClient, RestClient) 본문
외부 API 연동, 어떻게 해야 최선일까?
서버 개발자라면 외부 API 연동은 이제 기본입니다. 저도 공공데이터, 영화진흥위원회, 심지어 카카오 로그인까지 다양한 API 연동 작업을 해왔어요. 처음에는 "이렇게 하면 되는구나~" 하고 OkHttp로 시작해서 Feign까지 써봤죠.
그런데 문제는, 그냥 돌아가게만 만들었지, 왜 이렇게 동작하는지, 어떤 도구가 더 좋은지 제대로 이해하지 못했다는 겁니다. 시간이 없기도 했고, 솔직히 귀찮기도 했고요... 😅
그러다 문득 이런 생각이 들었어요. "만약 면접에서 '이 상황에서는 OkHttp 대신 왜 Feign이나 WebClient, RestClient를 써야 하나요?'라고 질문을 받으면 뭐라고 대답하지?" 아차 싶었죠. 그래서 이번에 제대로 공부해보기로 했습니다. 마침 이번 프로젝트에서 Spring Quartz를 이용해 특정 시간대에 적지 않은 데이터를 호출해 서버에서 가공하고 저장까지 해야 하는 요구사항이 있었거든요. 이 상황에서 최선의 선택은 무엇인지, 그리고 그 선택에 대한 타당한 이유까지 완벽하게 이해하고 넘어가고 싶었습니다.
1. 외부 API 연결 도구 선정
먼저, 초반에는 위에서 언급한 요구사항에 맞는 도구로 WebClient를 선정했습니다. 단순한 HttpUrlConnection이나 OkHttp와 비교해, 왜 굳이 WebClient를 선택했는지, 어떤 장점이 있는지 설명해볼게요.
1.1 HttpURLConnection/URLConnection
- 기본적인 HTTP 통신: 자바에서 제공하는 기본 API로, 순수 자바로 HTTP 통신을 지원합니다. 데이터의 타입이나 길이에 거의 제한이 없죠.
- 동기적 통신: 오래된 자바 버전에서 사용하는 이 클래스는 동기적 통신을 기본으로 합니다. 요청을 보내고 응답을 기다리는 동안 스레드가 대기 상태에 머물러 성능에 큰 영향을 미칠 수 있습니다.
- 불편함: 기본적인 요청과 응답 기능을 제공하지만, 추가적인 기능들은 사용자가 직접 구현해야 하는 불편함이 있습니다.
1.2 OkHttpClient
- 간편한 사용성: 단순하고 직관적인 API를 제공해 사용하기 쉽습니다. 응답 캐싱을 지원해 중복 요청을 방지하고 네트워크 트래픽을 줄일 수 있습니다.
- 안정성 문제: 최근에 출시된 라이브러리라 안정성이 완벽하게 검증되지 않았습니다.
- 메모리 문제: OkHttp의 프로세스 메모리가 크고, 간혹 Out of Memory (OOM) 에러가 발생하는 경우가 많습니다. 특히 OkHttp의 Direct Buffer Pool은 GC(Garbage Collect)를 통해 회수가 안 되는 문제가 있어, 장기간 사용 시 메모리 누수가 발생할 수 있습니다.
1.3 WebClient
- 비동기/논블로킹 처리: 외부 API 호출을 비동기 및 논블로킹 방식으로 처리할 수 있습니다. 이는 I/O 작업이 많거나 네트워크 통신이 빈번한 애플리케이션에서 특히 유용합니다.
- 리액티브 프로그래밍: 데이터 스트림을 효과적으로 처리할 수 있어, 높은 처리량과 확장성을 확보할 수 있습니다.
- 단점: 학습 장벽이 높습니다. 새로운 개념인 리액티브 프로그래밍을 이해하고 적용하는 데 시간이 필요합니다.
결론
이러한 이유로, 주기적으로 대량의 외부 API 데이터를 처리하고 이를 데이터베이스에 저장해야 하는 복잡한 워크플로우에서 WebClient를 사용하여 비동기적으로 처리하는 것이 최적의 선택이라고 판단했습니다.
2. 실질적인 통신 과정에 대한 고민
WebClient를 사용하여 비동기 또는 논블로킹 방식으로 I/O를 처리하는 것에 대한 고민은 데이터베이스의 트랜잭션과 어떻게 상호작용하는지에 대한 중요한 질문으로 이어집니다. 비동기 처리 방식이 데이터베이스 트랜잭션에 미치는 영향과 이러한 방식이 정말 최선의 선택인지에 대해 살펴보겠습니다.
2.1 비동기와 논블로킹 처리의 데이터베이스 트랜잭션과의 상호작용
비동기 I/O의 트랜잭션 관리:
비동기 I/O를 사용할 때, 네트워크 요청과 응답은 비동기적으로 처리되지만, 데이터베이스 트랜잭션은 여전히 동기적으로 관리됩니다. 즉, 비동기적으로 외부 API에서 데이터를 가져와도, 데이터베이스에 저장하거나 트랜잭션을 처리하는 과정은 여전히 동기적으로 이루어집니다. 이로 인해 비동기 I/O와 데이터베이스 트랜잭션 간의 상호작용에서 신중해야 합니다.트랜잭션 경계와 일관성:
비동기 처리 중 데이터베이스 트랜잭션을 관리할 때는 트랜잭션 경계를 명확히 설정하는 것이 중요합니다. 비동기 작업이 완료되기 전까지 트랜잭션을 유지해야 하며, 이 과정에서 트랜잭션의 일관성을 보장해야 합니다. 예를 들어, 비동기 API 호출 후 결과를 데이터베이스에 저장하는 경우, 데이터베이스 트랜잭션이 비동기 작업의 완료를 기다리는 동안 유지되어야 합니다.데이터베이스 연결과 스레드 관리:
비동기 I/O가 데이터베이스 트랜잭션과 상호작용할 때는 스레드 관리와 데이터베이스 연결 관리가 중요합니다. 비동기 작업으로 인해 여러 스레드가 데이터베이스에 동시에 접근할 수 있으므로, 데이터베이스 연결 풀과 스레드 풀을 적절하게 관리해야 합니다. 특히, 스레드 풀이 과도하게 많거나 적절히 설정되지 않으면 Context Switching Overhead와 같은 성능 문제를 초래할 수 있습니다.비동기 처리의 복잡성:
비동기 처리는 동시성 관리와 스레드 간의 상호작용이 복잡하기 때문에, 데이터베이스 트랜잭션을 관리하는 데 추가적인 복잡성이 생길 수 있습니다. 이러한 복잡성은 개발과 유지보수에서 추가적인 부담이 될 수 있습니다.
2.2 다른 방법... RestClient?
이런 주의점에 대해 알아본 후 저는 WebClient를 사용하는 것이 과연 옳은 선택일까에 대한 고민을 했습니다. 비동기식으로 API 호출하는 것과 동기식으로 API 호출하는 것에 드라마틱한 차이점이 없는데 굳이 Webclient를 사용하기 위해서 새로운 R2DBC나 NoSQL과 같은 조금은 러닝 커브가 있는 것들을 도입하는 것이 최선일까 의문을 품었습니다.
비동기 처리를 사용하지 않는다면 WebClient 대신 어떤 도구를 사용할 수 있을까요? 이런 고민 끝에 최근에 등장한 RestClient를 발견했습니다.
RestClient
- Spring 6.1.2 버전부터 등장: WebFlux 의존성 없이 사용할 수 있는 도구입니다.
- 동기식으로 동작: WebClient와 유사하지만 동기식으로 동작합니다.
- 사용 편리성: HttpInterface라는 유용한 도구를 WebClient와 함께 사용해야 했지만, RestClient가 등장하면서 이러한 번거로움을 해소했습니다.
결론
이 RestClient를 보고, 기존에 결정한 WebClient를 대체하기로 했습니다. 비동기적 통신의 리스크와 굳이 리액티브 프로그래밍 환경이 아닌 이상 RestClient를 두고 WebClient를 사용할 이유가 없다고 판단했기 때문입니다. 저는 결론적으로 RestClient와 HttpInterface를 활용해서 외부 API를 호출하여 데이터를 가져오는 작업을 진행하기로 결정했습니다.
3. 외부 API와 연동, 그 이후
외부 API와 통신이 된다고 해서 끝이 아닙니다. 이제 RestClient로 단순히 외부 데이터를 가져와 작동시키는 것을 넘어, 더 효과적으로 처리할 방법에 대해 고민해보려고 합니다. 예를 들어, Rate Limit을 적용하거나, 타임아웃 설정, 캐싱 처리 등 무궁무진한 효율적인 개선 방법들을 찾아볼 예정입니다. 앞으로 더 많은 고민과 개선을 통해 최적의 API 연동 방식을 찾아가겠습니다.
이렇게 정리된 글을 통해 비동기 I/O와 트랜잭션 관리의 복잡성, 그리고 각 도구의 장단점을 이해하고, 최적의 선택을 하는 데 도움이 되기를 바랍니다!