API 게이트 웨이

전 회사에서 일했을 당시, 게이트웨이라는 도메인이 따로 존재했습니다. 제 기억으로는 넷플릭스에서 만든 Zuul을 사용하고 있었고, 이후 스프링 버전 업 과정에서 Spring Cloud Gateway로 전환했던 것으로 기억합니다. 당시 제가 이해하고 있던 게이트웨이는 단순했습니다. 앞단에서 요청을 받아 인증이나 로깅 같은 공통 처리를 대신 수행하고, 그 결과를 각 도메인 서비스로 전달해주는 역할 정도로 인식하고 있었습니다. 다만 그 구조가 왜 그렇게 동작해야 하는지, 왜 이런 처리를 각 도메인이 아니라 게이트웨이가 담당해야 하는지에 대해서는 깊이 생각해보지 못했던 것 같습니다. 이번 기회를 통해 API Gateway가 왜 필요한지, 그리고 단순한 앞단 컴포넌트가 아니라 어떤 역할을 맡고 있는지 정리해보려 합니다.

API 게이트 웨이가 필요한 이유

기존 모놀로식 구조로 개발을 할 때는 진입 지점이 하나였습니다.
제가 사용하는 스프링을 기준으로 단순화해서 그려보면 다음과 같은 형태가 됩니다.

filter vs interceptor vs AOP

API Gateway를 사용한다는 것은, 곧 MSA 구조로 개발을 진행한다는 의미가 됩니다.
그리고 MSA로 전환되면, 기존과 달리 진입 지점이 하나가 아니라 여러 개로 늘어나게 됩니다.
각 서비스는 독립적으로 배포되고, 각각의 엔드포인트를 가지게 되기 때문입니다.

이때 API Gateway는 분산되어 있는 여러 진입점을 외부에서 하나의 진입점처럼 보이도록 묶어주는 역할을 하게 됩니다.
즉, 클라이언트는 더 이상 각 서비스의 위치나 구조를 알 필요가 없고, 모든 요청은 API Gateway를 통해 내부 서비스로 전달되도록 구성됩니다.

API Gateway를 사용한다는 것은, 기존 모놀로식 구조에서 필터나 인터셉터가 담당하던 역할을 애플리케이션 내부가 아니라, 시스템의 가장 앞단에서 수행하도록 분리한 것으로 해석하면 이해하기 쉽습니다. 다만 중요한 차이점은, 필터와 인터셉터는 하나의 애플리케이션 내부에서만 동작하지만, API Gateway는 여러 서비스 전체에 대해 동일한 정책을 적용한다는 점입니다.

API 게이트 웨이는 무엇을 할까?

위에서 모놀로식 구조에서 필터나 인터셉터가 담당했던 부분을 공통적으로 적용하기 사용하기 위해 사용한다고 했습니다.
가장 먼저 API 게이트웨이의 본질부터 생각해봅시다.

이제 가장 먼저 API Gateway의 본질부터 생각해보겠습니다. API Gateway는 특정 기능의 집합이 아니라,
요청이 들어오기 전과 요청이 처리된 이후의 경계에서 공통 관심사를 처리하는 역할을 담당합니다.

예를 들어 MDC 설정이나 로깅 작업, 그리고 라우팅과 같은 처리를 API Gateway에서 수행할 수 있습니다.
이 중에서 라우팅 작업이 필요한 이유는, MSA 구조에서는 도메인마다 독립적인 서버가 존재하기 때문입니다.
서버가 여러 개로 분리된다는 것은, 곧 각 서비스가 서로 다른 주소를 가지게 된다는 의미이기도 합니다.
API Gateway는 이러한 분산된 서비스들을 외부에서는 하나의 주소로 통신하는 것처럼 보이도록 만들어주는 역할을 합니다.
클라이언트는 개별 서비스의 위치를 알 필요 없이, API Gateway를 통해 내부 서비스로 요청을 전달하게 됩니다.

결론

원래 저번주에 작성되어야 하는 글이었는데 못쓰는 바람에 짧게 작성합니다. 
아무튼 간단하게 API 게이트웨이가 왜 필요한지 어떤일을 하는지 간략하게 알아봤습니다.