API Gateway를 직접 구현해야 할까?

서론

만들고 있는 서비스가 MSA(마이크로서비스 아키텍처)를 사용하다 보니 API Gateway의 구현이 필수적으로 요구되었습니다.

API GateWay를 구현하는 방법에는 크게 두 가지 접근 방식이 있습니다. 첫 번째는 직접 구현하는 방식이고, 두 번째는 프레임워크를 사용하는 방식입니다.
 
저는 직접 API Gateway를 구현하는 방법을 택했는데, 이 글에서 그 이유와 구현 방식에 대해서 설명해보겠습니다.

API Gateway란?

 

API Gateway는 클라이언트와 백엔드 서비스 간의 요청을 중계하는 서버입니다. 이 서버는 인증과 인가를 담당하여, 사용자의 권한에 맞는 서비스만 호출할 수 있도록 관리해줍니다.
 
보통 API Gateway는 아래의 그림처럼 단순히 인증 및 인가를 처리하고, 클라이언트의 요청을 적절한 서비스로 라우팅해주는 역할을 한다고 생각하기 쉽습니다. 하지만 API Gateway의 역할은 단순한 라우팅 이상입니다.

API Gateway는 클라이언트의 비즈니스 요청을 받아 내부의 여러 서비스들을 조합하고, 필요한 데이터를 가공하여 클라이언트에게 전달하는 중요한 역할을 해야 합니다.

단순히 외부에서 API를 제공해주는 용도로 프레임워크를 사용하여 라우팅만 한다면, 이는 API Gateway의 본래 기능을 충분히 활용하지 못한 "Gateway Routing" 패턴에 불과합니다.

모놀로틱 구조를 Gateway로 변경해보자

API Gateway를 제대로 이해하기 위해선 모놀로틱 구조의 어떤 기능들이 API Gateway로 매핑되어야 하는지 알아야 한다.
 
모놀로틱 구조에서는 주로 표현 계층과 비즈니스 계층으로 나뉩니다. 표현 계층의 역할은 외부 클라이언트 요청을 받아 비즈니스 계층을 호출하고, 그 결과를 클라이언트가 원하는 형식으로 반환하는 것입니다.
 
퍼사드(Facade) 패턴은 여러 비즈니스 로직을 조합하여 클라이언트의 복잡한 요청을 처리하는 방식으로, 이 구조에서는 상위 계층에서 하위 계층으로의 호출만 존재하고, 하위 계층에서 상위 계층을 호출하는 일은 없습니다. 

 
이를 MSA 구조로 매핑하면, API Gateway가 표현 계층의 역할을 하게 됩니다.

어째서 API Gateway Framework를 사용하면 안될까?

API Gateway Framework를 사용할 경우, 요청의 라우팅이 강제되는 문제가 발생하게 됩니다. 이로 인해 컨트롤러와 퍼사드 패턴이 존재하지 않으며, 횡단 관심사만 처리하는 기능인 필터와 인터셉터만 작동하게 됩니다. 이러한 구조는 보안 문제와 계층 간의 강결합 문제를 일으킬 수 있습니다.

보안

수평적 권한 상승 문제는 이러한 보안 이슈의 대표적인 예입니다.

수평적 권한 상승이란, 인증된 A 사용자가 본인의 정보만 접근할 수 있어야 하는 상황에서, B 사용자의 정보까지 접근할 수 있게 되는 보안상의 취약점을 말합니다.

이는 서비스의 보안성을 크게 위협하며, 사용자 데이터의 무결성을 유지하기 위해 반드시 방지해야 하는 중요한 사안입니다.
 
이 문제를 해결하기 위해서는 개발자가 각 요청에 대해 세밀하게 권한을 검증하고, 필요에 따라 적절한 제어 로직을 컨트롤러에서 직접 작성해야 합니다.

예를 들어, 사용자가 요청한 데이터가 해당 사용자의 소유인지 확인하는 검증 로직을 삽입하여 수평적 권한 상승을 방지할 수 있습니다.

책임 전가

퍼사드가 없을 경우, 이러한 비즈니스 조합 요청이 클라이언트 개발자에게 전가됩니다. 이로 인해 클라이언트 개발자는 자신의 개발에 집중하지 못하고, 백엔드 시스템 구조를 이해해야 하는 부담을 지게 됩니다. 이는 개발 효율성을 저하시키고, 클라이언트와 백엔드 간의 명확한 역할 구분을 어렵게 만듭니다.
 
또한, 비즈니스 로직을 다른 서비스로 전가하는 방법도 있지만, 이는 특정 서비스 개발자가 알지 못하는 로직을 구현해야 하는 책임을 떠안게 됩니다.

이렇게 되면 해당 서비스가 본래 역할이 아닌 다른 역할까지 맡게 되면서 시스템의 복잡도가 증가하고, 장애가 발생할 경우 그 영향이 다른 모든 계층으로 전파될 수 있습니다.

이는 MSA의 주요 장점 중 하나인 장애 격리를 방해할 수 있습니다.

유지 보수 문제

상업용으로 서비스가 확장되면 표현 계층이 여러 개로 분리될 수 있습니다. 단순 라우팅만을 담당하는 경우, 표현 계층별로 다른 API를 만들어야 하는 상황이 발생할 수 있습니다. 이는 유지보수의 복잡성을 증가시키고, 개발의 일관성을 저해할 수 있습니다.

성능 문제

여러 API 호출을 조합해야 하므로 네트워크 호출이 여러 번 발생하게 되어 성능 문제가 발생할 수 있습니다.

특히, API Gateway Framework를 사용할 경우 논 블로킹 I/O나 WebFlux와 같은 비동기 처리가 충분히 구현되지 않으면, 요청이 강제적으로 직렬화되면서 성능 이슈가 발생할 수 있습니다.

이는 여러 API 호출을 병렬로 처리하지 못하고, 각 호출이 순차적으로 처리되면서 응답 시간이 증가하는 문제로 이어질 수 있습니다.
 
 
[참고 자료]
https://www.youtube.com/watch?v=P2nM0_YptOA&t=1664s