Load Balancer VS Reverse Proxy VS API Gateway

스우·2024년 8월 27일

API Gateway lb load balancer reverse proxy 네트워크

Motivation

클라우드 아키텍처 설계 중 특정 경로로 들어오는 요청을 처리하는 방식으로 어떤 방식을 택하면 좋을지 고민 중이었다. 특히 eks 내의 ingress를 통해 처리하던 기존 방식은 인증 및 권한 부여 기능이 없기 때문에 로그인을 처리하는 service를 분리하는 MSA 구조에서의 한계를 만날 수 있었다.
해당 문제점을 해결할 방법을 찾던 중 API Gateway를 알게 되었는데 둘의 개념 차이가 궁금해져서 작성하게 되었다.
또한 ingress 사용 전에 nginx를 통해 Reverse proxy를 구현해 경로를 구분했던 경험이 있다. 세 개의 용어들 모두 서버로 들어오는 요청을 경로에 따라 구분해주는 것으로 이해했는데, 어떠한 차이가 있고 특정 상황에서는 어떤 것을 이용해야하는지 고민해보고자 한다. 기술에 대한 필자의 개인적인 생각 및 요약은 italic 글자로 표현하도록 하겠다.

Load Balancer

서버에 가해지는 부하를 분산 해주는 장치 또는 기술을 이야기한다.
클라이언트와 서버 Pool 사이에 위치하며, 여러 대의 서버가 존재할 때 한 대의 서버로 부하가 집중하지 않도록 트래픽을 관리해 각각의 서버가 트래픽을 처리할 수 있도록 한다. 특정 경로로 요청이 들어오면 요청을 수신하고 라우팅해주는 역할까지 수행한다.
서버 충돌이 발생하면 로드 밸런서는 자동으로 다른 활성 서버로 Redirection을 시켜준다. Scale-out의 방식으로 사용자의 요구에 따라 서버가 증설될 수 있는 환경이라면 트래픽을 균등하게 분산해주는 로드밸런싱이 필요하다.
또한 로드 밸런서는 등록된 Backend 서버에서 상태 검사를 수행하도록 구성할 수 있다. 이러한 상태 검사를 통해 활성화된 서버를 확인하여 가용성을 체크하는 것이다.
트래픽을 분산할 때는 다양한 알고리즘을 통해 분산 가능하다.

로드밸런서를 통해서 특정 경로에 대한 요청을 특정 서버로 연결하는 것은 물론 가능하다. 애플리케이션 로드 밸런서(L7 Load Balancer)에서 요청 경로에 따라 트래픽을 분배하는 기능을 제공하기 때문이다. 그러나 주된 목적은 부하 분산임을 잊지 말아야 한다. 할 수는 있지만, 경로 기반 라우팅 기능은 리버스 프록시나 API Gateway를 사용하는 것이 더 적합하다.

L4 Load Balancer

L4 계층은 전송 계층으로 주로 라운드 로빈 방식을 사용하며 네트워크 계층이나 전송 계층의 정보를 바탕으로 부하를 분산한다. 네트워크 계층과 전송 계층은 IP, Port 정보를 사용하기 때문에 이를 기반으로 부하를 분산한다. 요청하는 서비스의 종류와는 상관없이 IP, Port에 따라 서버로 요청이 전송된다.

L7 Load Balancer

L7 계층은 응용 계층에서 동작하기 때문에 IP, Port 이외에도 URI, Payload, Http Header, Cookie 등의 내용을 기준으로 부하를 분산한다. L7 로드 밸런서는 요청의 세부적인 사항을 두고 다른 역할을 하는 서버 등으로 분리해서 MSA 아키텍처에서도 유용하게 사용할 수 있다.
또한 L7 로드 밸런서는 데이터를 분석해서 처리가 가능하기 때문에 악의적인 콘텐츠를 감지해 보안 기능을 추가할 수 있다는 장점이 있다.

Reverse Proxy

리버스 프록시는 클라이언트와 서버 사이의 중재자 역할을 한다. 클라이언트는 리버스 프록시와만 상호 작용하고, 백엔드 서버는 프록시 서버를 통해서만 요청을 전달받는다.
해당 구조는 내부 네트워크 내의 개별 서버와 구현 세부 사항을 숨기고, 서버의 IP 주소의 기밀성을 유지할 수 있다.

또한 다음과 같은 기능을 지원한다.

부하 분산 기능 : 해당 리버스 프록시로 들어오는 요청을 서버 여러 개로 부하 분산 가능, 특정 경로로 오는 요청을 백엔드의 특정 IP로 Forwarding 가능
캐싱 : 반복되는 요청의 경우 프록시 캐시에 저장되어 Server에서 데이터를 가져올 필요성이 줄어들고 클라이언트에게 더 빠른 응답을 제공
보안 강화 : 외부 요청을 필터링하는 옵션을 제공하여 Server에 대한 추가 보호를 제공한다. 또한 리버스 프록시 존재 자체가 기존 서버의 IP를 숨겨주고, DDos와 같은 공격에서 벗어날 수 있도록 도와준다.
SSL Termination : 암호화된 트래픽을 서버로 전달하기 전에 암호화된 트래픽을 해독하는 기능

Load Balancer와 같은 맥락이다. 결국 Reverse Proxy는 특정 경로에 대한 요청을 라우팅해주는 기능을 포함하지만 주요한 목적은 클라이언트가 서버로 직접 접속할 수 없도록 제한해주는 것이다. 해당 용어들의 목적을 구분하는 것이 용어 구분의 핵심이다.

API Gateway

API Gateway는 트래픽을 전달할 뿐만 아니라 아키텍처에서 Backend 내의 분할을 클라이언트에게 숨길 수 있다.
해당 과정을 통해서 클라이언트 코드의 간소화를 도울 수 있다.
예를 들어서 www.example.com 으로 요청을 보낼 때 요청을 URI에 따라서 구분할 수 있다면 www.example.com/service1 과 www.example.com/service2로 사용 가능하다. 동일한 서버에 요청을 보내는 것 같지만 Backend 내부에서 다른 API로 라우팅되는 것이다.
해당 과정을 통해서 클라이언트는 여러 백엔드와 통신하지 않고 Gateway하고만 통신하면 된다.

프로젝트에서 필요한 부분은 바로 해당 부분이었다. 나는 클라이언트 코드에서 각 마이크로서비스의 API로 요청을 보낼 때 각 마이크로서비스가 띄워진 IP가 아니라 Gateway를 통해서 한 부분으로 요청을 보내면 자동으로 맞는 API로 연결되기를 원했다. 생각해보자 React 코드 내에서 axios를 통해서 요청을 보낼 때 필요한 마이크로서비스마다 다른 IP를 써야한다면, 코드 가독성이 매우 안좋아질 것이다.

이에 더불어 API Gateway는 더 다양한 기능을 제공한다.

보안
분석 및 모니터링
인증 / 인가
캐시

API Gateway 내부 단계

클라이언트로부터 Http Request가 들어온다면 파란색의 절차를 거쳐 처리되게 된다.
노란색은 필수는 아니지만 필요로 하면 사용할 수 있는 기능이다.

각 단계를 살펴보자
1. Parameter Validation
API 게이트웨이는 HTTP 요청 내의 속성을 조사하고 검증

Allow/Deny List
API 게이트웨이는 요청 검증을 위해 해당 리스트를 확인
Authentication & Authorization
API 게이트웨이는 Identity Providers를 통해 사용자의 권한을 검증하고, 권한을 부여
Identity Provider 예로는 AWS Cognito가 있다.
Rage Limit
속도 제한 규칙이 적용되고, 제한을 초과하는 요청은 거부
Dynamic Routing
API 게이트웨이에서 요청 내 경로를 보고 경로에 일치하는 백엔드 서비스로 요청을 전달
Service Discovery
서비스로 전달하기 위해 서비스를 검색하는 기능
Protocol Conversion
API 게이트웨이는 요청을 적합한 프로토콜로 변환하여 백엔드 마이크로서비스로 전달

그 외로는 Error Handling, Circuit Break, Logging and Monitoring, Cache 기능이 있다.
Circuit Break는 회로 차단을 통해 장애를 식별했을 때 상호 연결된 서비스의 과부하를 방지하기 위해 연쇄 장애를 완화한다.
Logging and Monitoring은 ELK 스택이나 다양한 관찰도구를 결합하여 사용한다.
Cache는 반복되는 요청에 대한 응답을 캐시하여 레디스와 같은 캐시 저장 데이터베이스와 결합하여 응답성 향상을 돕는다.