오늘 배운 점
-
API Gateway가 클라이언트의 요청을 받아 각각의 백엔드 서비스로 전달하는 단일 진입점 역할을 한다는 것을 배웠다.
-
Spring Cloud Gateway에서 Path와 lb://서비스명을 이용해 요청을 특정 서비스로 라우팅할 수 있다는 것을 확인했다.
-
Gateway도 Eureka Client로 동작하며, Eureka에 등록된 서비스 정보를 이용해 order-service, product-service와 같은 서비스를 찾을 수 있다는 것을 확인했다.
-
http://localhost:19091/order로 요청했을 때 Gateway를 거쳐 order-service의 19092 포트로 요청이 전달되고 Order details가 반환되는 것을 확인했다.
-
Product Service를 19093, 19094 두 개의 인스턴스로 실행하고 Gateway를 통해 요청했을 때 Load Balancer가 여러 인스턴스에 요청을 분산하는 것을 확인했다.
-
Gateway의 Pre Filter는 서비스로 요청을 보내기 전에, Post Filter는 서비스에서 응답을 받은 후 동작한다는 것을 배웠다.
내일도 이어서 해볼 점
-
Gateway의 Pre Filter와 Post Filter가 실제 요청 과정에서 언제 실행되는지 로그를 통해 다시 확인해볼 예정이다.
-
Eureka에 등록된 여러 Product Service 인스턴스 중 Load Balancer가 어떤 방식으로 인스턴스를 선택하는지 계속 확인해볼 예정이다.
-
Gateway에서 라우팅과 필터가 실제 요청 흐름에서 어떻게 연결되는지 복습해볼 예정이다.
오늘 아쉬웠던 점
-
강의에서는 Spring Boot 3 버전을 사용했지만 현재 실습 프로젝트는 Spring Boot 4.1.1과 Spring Cloud 2025.1.3을 사용하고 있어 Gateway 설정 방식에서 차이가 있었다.
-
강의의 설정을 그대로 적용했을 때 Gateway에서 /order 요청이 404로 반환되어 원인을 확인하는 데 시간이 걸렸다.
-
현재 버전에 맞게 spring.cloud.gateway.server.webflux 구조로 설정을 수정한 후 Gateway를 재시작하여 정상적으로 라우팅되는 것을 확인했다.
내일 해결을 위해 시도해볼 점
- 문제가 발생했을 때 Gateway, Eureka, 각 서비스에 직접 요청해보면서 어느 단계에서 문제가 발생했는지 구분해서 확인해볼 예정이다.
