1. 배경

현대오토에버 모빌리티 스쿨에서 진행한 'WMS 프로젝트'에서는 MSA 기반 분산 아키텍처로 설계를 진행하였습니다.

이에, 서버에 이루어지는 모든 요청이 Spring MVC 패턴으로 구현된다면 다음과 같은 문제가 발생할 것으로 예상되었습니다.

• 요청 수가 증가하면 스레드 자원이 낭비됨
  • N개의 요청이 발생하면 N개의 스레드가 생성
  • 대기 시간이 긴 요청이 많아질수록 스레드 점유 시간이 증가
  • 스레드 풀 한계를 초과할 경우 성능 저하 발생
• API Gateway에서 블로킹 방식의 비효율성
  • API Gateway는 다양한 서비스(API)로 요청을 전달하고 응답을 반환하는 역할
  • 다수의 요청을 처리할 경우, 블로킹 방식(Spring MVC)에서는 스레드가 대기 상태에 빠질 위험이 있음

이를 해결하기 위해 API Gateway를 Spring WebFlux 기반으로 구현하였습니다.

2. 개선 방법

✅ WebFlux 도입 배경

Spring WebFlux는 논블로킹 비동기 처리 방식을 제공하는 리액티브 프로그래밍 모델을 기반으로 합니다. 이를 통해 다음과 같은 개선 효과를 기대할 수 있습니다.

1. 스레드 자원 최적화
   • 이벤트 루프(Event Loop) 기반으로 동작하여 소수의 스레드로 많은 요청 처리 가능
   • 블로킹이 발생하지 않아 CPU 자원 활용도 증가
2. API Gateway의 효율적인 요청 처리
   • API Gateway는 다양한 서비스로 요청을 라우팅하며, 외부 API 호출이 많음
   • WebFlux의 논블로킹 I/O를 활용하여 대기 시간을 최소화하고, 응답 속도를 개선
3. MSA 환경과의 적합성
   • MSA에서는 여러 서비스 간 네트워크 호출이 빈번하기 때문에, 비동기 방식이 적합
   • Spring WebFlux를 활용하면, 각 서비스 간 호출을 최적화하여 전체적인 시스템 성능을 향상

3. 개선 결과

최종적으로 Spring MVC 아키텍처를 Spring WebFlux 를 활용하여 서버 동시 처리량을 약 13배 이상 개선하였습니다.

📈 성능 비교 결과

테스팅은 Jmeter로 진행하였습니다.

추후에는, 단일 컴퓨터 인스턴스에서 실행하는 Jmeter 보다는, 실제로 여러 개의 Instance를 생성해서 테스트 해볼 수 있는 AWS Lambda를 이용해 테스트 해보는 것이 더욱 좋은 테스팅이 될 것 같습니다.

1️⃣ 처리량 비교 (Requests/sec)

요청 수	Spring MVC	Spring WebFlux	차이
10,000	1,081.8	4,990.0	🔺 4.6배 ↑
20,000	1,098.5	5,046.7	🔺 4.6배 ↑
30,000	706.2	6,267.8	🔺 8.9배 ↑
40,000	373.9	5,596.2	🔺 15배 ↑

✅ 결과 요약:
WebFlux가 모든 테스트에서 월등히 높은 처리량을 보였으며, 특히 요청 수가 증가할수록 차이가 더 벌어졌습니다.

---

2️⃣ 평균 응답 시간 비교 (ms)

요청 수	Spring MVC	Spring WebFlux	차이
10,000	82	10	🔽 8.2배 ↓
20,000	176	29	🔽 6.1배 ↓
30,000	401	46	🔽 8.7배 ↓
40,000	1,045	61	🔽 17배 ↓

✅ 결과 요약:
WebFlux의 평균 응답 시간이 MVC보다 최대 17배 빠른 성능을 보이며, 요청 수가 증가할수록 응답 속도 차이가 커졌습니다.

---

최종 결과

TPS : 약 13배 증가!

응답 속도 : 약 95% 증가!