MSA로 전환하면서 각 서버마다 다른 URL을 가지게 되었고, 이로 인해 프론트에서 여러 URL을 관리하게 되었습니다. 그러나 프론트에서 여러 URL을 관리하는 것은 비효율적이기 때문에, 서비스 단일 진입점이 필요하다고 판단하여 API Gateway를 도입하게 되었습니다.

API Gateway를 통해서는 인증, 라우팅, 로드밸런싱, 모니터링, 장애 복구 등을 효율적으로 관리할 필요가 있었습니다.

API Gateway 의사결정

• Kong
  • Spring Cloud Gateway와 비교했을 때 플러그인 및 레퍼런스가 제한적
  • 플러그인과 라이브러리가 부족하여 확장 시 직접적인 개발 부담이 증가할 수 있음
  • 프로젝트와의 통합이나 유지보수가 복잡할 가능성이 높음
• AWS API Gateway
  • 높은 비용 구조로 인해 트래픽 증가 시 비용 부담이 예상됨
  • Spring 기반 프로젝트에서 세부적인 커스터마이징이 어려울 수 있음
  • AWS 환경에 종속적이며, 타 플랫폼 간 이식성이 낮음
• Spring Cloud Gateway
  • Spring Cloud 생태계와 높은 호환성을 제공
  • YAML 파일 또는 JAVA 코드로 설정을 할 수 있어 세부적인 커스터마이징이 가능
  • Gateway 전용 서버가 필요하기 때문에 추가 인프라 비용이 발생

기술 결정

Kong은 플러그인이나 라이브러리가 부족하며, 다른 솔루션 대비 러닝커브가 있습니다.
AWS API Gateway는 Spring 기반 프로젝트에서 세부적인 커스터마이징이 어려울 수 있습니다.
Spring Cloud Gateway는 Spring 기반 프로젝트와의 호환성이 매우 높아 개발 환경에 적합하며 코드 기반의 커스터마이징이 가능하고, 다양한 필터와 라우팅 정책을 쉽게 적용할 수 있습니다.

그렇기 때문에 Spring Cloud Gateway로 결정하였습니다.