API Gateway vs 로드 밸런서

인터넷 기술의 발전과 함께 네트워크 데이터 요청의 수가 급격히 증가하면서 서버에 더 큰 부하가 가해지고 있습니다. 초기 시스템 아키텍처에서는 주로 로드 밸런서를 사용하여 네트워크 트래픽을 여러 서버에 분산시켜 단일 서버의 부하를 줄였습니다.

그러나 현재는 다양한 유형의 백엔드 서비스가 외부에 API를 노출시키면서 API의 수가 점점 증가하고 있습니다. 이로 인해 주로 로드 밸런서에 의존하는 시스템 아키텍처의 한계가 드러나게 되었는데, 이는 주로 4계층에서 동작하며 7계층에서의 기능이 제한적이기 때문입니다. 이에 따라 주로 7계층에서 동작하며 광범위한 확장 기능을 제공하는 API Gateway라는 인프라가 등장하게 되었습니다.

이 글에서는 로드 밸런서와 API 게이트웨이의 특징을 소개하고, 그 차이점을 탐구하여 독자들이 이 둘의 관계를 더 잘 이해할 수 있도록 돕겠습니다.

로드 밸런서란 무엇인가?

로드 밸런서의 주요 역할은 여러 백엔드 서비스에 대해 로드 밸런싱 기능을 제공하여, 서로 다른 로드 밸런싱 알고리즘을 기반으로 트래픽을 분산시키는 것입니다. 로드 밸런서의 역사는 길며, 대략 다음과 같은 단계로 나눌 수 있습니다:

• 첫 번째 단계: 이 단계의 로드 밸런서는 일반적으로 하드웨어 장치로 구성되어 있으며, 높은 성능과 높은 신뢰성을 가지지만 유연성이 떨어지고 비용이 많이 듭니다.

• 두 번째 단계: 로드 밸런서가 소프트웨어로 구현되기 시작하면서 더 유연하고 확장 가능해졌으며, 소프트웨어 배포에서 자주 등장하여 비용이 줄어들었습니다. LVS(Linux Virtual Server)가 이 유형의 예입니다.

• 세 번째 단계: 클라우드 컴퓨팅 기술의 부상과 함께 로드 밸런서도 클라우드 버전이 등장했습니다. 이러한 로드 밸런서의 중요한 장점 중 하나는 기업이 더 낮은 비용으로 고성능 로드 밸런싱 서비스를 얻을 수 있다는 점입니다. 또 다른 장점은 클라우드 컴퓨팅의 확장성과 탄력성을 활용하여 전체 가용성을 향상시킬 수 있다는 점입니다. 클라우드 로드 밸런서의 예로는 AWS의 Classic Load Balancer, Application Load Balancer, Network Load Balancer 등이 있습니다.

로드 밸런서는 트래픽 분산과 네트워크 확장성 향상 외에도 네트워크 보안 강화에도 사용될 수 있습니다. 예를 들어, 내부 서버를 공용 인터넷으로부터 격리시켜 악의적인 공격과 무단 접근을 방지할 수 있습니다. 간단한 사용 사례로는 민감한 정보를 포함한 내부 서버가 있는데, 로드 밸런서가 이를 내부 네트워크 내에 격리시켜 보안을 효과적으로 보호할 수 있습니다.

API 게이트웨이란 무엇인가?

간단히 말해, API 게이트웨이는 API 트래픽을 관리하고 전달하는 인프라로, 주로 7계층에서 동작합니다. 이는 로드 밸런서가 갖지 못한 강력한 확장성을 제공하며, 인증, 관측 가능성, 그리고 사용자 정의 플러그인 등을 포함합니다. 주요 기능은 다음과 같습니다:

• 풍부한 라우팅 전략: API 게이트웨이는 7계층에서 동작하므로 HTTP/HTTPS 계층의 데이터를 파싱할 수 있습니다. 따라서 요청 경로, 도메인, 헤더 등의 조건에 따라 다양한 업스트림 서버로 요청을 전달할 수 있습니다.

• 인증: API 게이트웨이는 API 수준에서 다양한 인증 방법을 지원하여 무단 요청을 방지합니다. 예를 들어 OAuth2와 JWT가 있습니다. 인증은 비즈니스 로직과 분리되어 독립적으로 유지될 수 있으므로 비즈니스 코드에 침투적이지 않거나 최소한의 침투성을 가집니다.

• 속도 제한: 다양한 라우팅 수준에서 세밀한 속도 제한을 적용하여 악의적인 공격을 방지하고 백엔드 서비스의 과부하를 피할 수 있습니다.

• 관측 가능성: 관측 가능성은 시스템 외부에서 내부 프로그램의 실행 상태와 자원 사용량을 관찰할 수 있는 능력을 말합니다. API 게이트웨이는 로그를 Kafka, Google Cloud Logging Service, Elasticsearch 등에 연결하고, 관련 메트릭을 Prometheus, Datadog 등에 연결할 수 있습니다.

• 확장성: API 게이트웨이 자체가 게이트웨이이기 때문에, 다양한 회사의 다양한 애플리케이션 시나리오에 적응할 수 있도록 설계되었습니다. 예를 들어, 다양한 인증 방식, 카나리 릴리스, 보안 정책, 로그 수집 등이 있습니다. 또한 API 게이트웨이는 사용자가 확장 기능을 선택하거나 사용자 정의 개발을 할 수 있도록 해야 하므로 확장성이 강력하며, 사용 가능한 확장 기능의 선택지도 매우 다양합니다. 예를 들어, Apache APISIX는 13가지의 다양한 인증 확장 기능을 제공하며, 시장에서 흔히 볼 수 있는 거의 모든 인증 요구 사항을 커버합니다.

현재 시장에는 Apache APISIX, Kong, Tyk, Zuul 등 다양한 API 게이트웨이가 있습니다. 개발자는 자신의 특정 요구 사항에 따라 가장 적합한 API 게이트웨이를 선택할 수 있습니다.

API 게이트웨이와 로드 밸런서의 주요 차이점

주요 초점 영역

API 게이트웨이와 로드 밸런서 모두 4계층과 7계층 프록시를 지원하지만, API 게이트웨이는 주로 7계층에 초점을 맞추고 로드 밸런서는 주로 4계층에 초점을 맞춥니다.

따라서 4계층에서 동작하는 로드 밸런서는 여러 가지 장점을 가지고 있습니다. 첫째, API 게이트웨이에 비해 프로토콜 파싱 오버헤드가 적어 처리량이 더 높습니다. 둘째, 클라이언트 IP 주소를 투명하게 전달할 수 있는 반면, API 게이트웨이는 일반적으로 HTTP 헤더를 통해 클라이언트 IP 주소를 전달합니다.

기능의 풍부함

예를 들어, 로드 밸런서는 HTTP 7계층 처리 능력이 약하며, 인증, 권한 부여, 복잡한 라우팅 로직, 로그 수집 등의 기능이 부족한 경우가 많습니다. 반면 API 게이트웨이는 7계층 프로토콜 처리 능력이 강력하며, 접근 제어, 로깅, API 관리, 서버리스 컴퓨팅 등 다양한 기능 확장을 추가할 수 있습니다.

사용자 정의 개발

현재 빠르게 변화하는 기술 시장에서 많은 기업들은 사용자 정의 개발을 지원할 수 있는 능력을 요구합니다. API 게이트웨이는 다양한 사용자 정의 개발 옵션을 제공하며, 예를 들어 다양한 프로그래밍 언어를 지원하고 트래픽 전달의 다양한 단계에서 사용자 정의 처리 로직을 주입할 수 있습니다. 반면 로드 밸런서는 사용자 정의 개발 옵션을 제공하지 않습니다.

트래픽 분배 방식

로드 밸런서는 일반적으로 직접 트래픽 분배를 통해 로드 밸런싱을 달성합니다. 알고리즘을 통해 트래픽 데이터를 특정 백엔드 서버 노드로 직접 전송하므로, 트래픽을 받을 준비가 된 각 서비스 인스턴스는 일관된 동작을 해야 하며, 이는 일부 유연성을 감소시킵니다. 반면 API 게이트웨이는 URL Path, Domain, Header 등 다양한 차원을 기반으로 트래픽을 분배합니다. 결과적으로 트래픽을 받을 준비가 된 서비스 인스턴스는 다양할 수 있으며, 예를 들어 개인 API나 GRPC API 등이 될 수 있어 트래픽 분배가 매우 유연합니다.

사용 사례

마이크로서비스 사용 사례

마이크로서비스 아키텍처 시스템의 경우 API 게이트웨이는 필수적입니다. 첫째, 다양한 백엔드 서비스를 쉽게 관리하고 라우팅할 수 있습니다. 둘째, API 게이트웨이는 인증, 권한 부여, 속도 제한, 전달, 로깅 등 많은 고급 기능을 제공할 수 있습니다. 따라서 각 마이크로서비스는 속도 제한 및 인증과 같은 기능을 반복적으로 구현할 필요가 없어 각 마이크로서비스의 기능 구현이 더 집중되고 개발 비용이 줄어듭니다.

마이크로서비스 아키텍처는 많은 서비스를 포함하므로 4계층 로드 밸런서는 여러 백엔드 서비스의 로드 밸런싱에는 적합하지 않습니다. 대신 단일 백엔드 서비스와 함께 사용하는 것이 더 적합합니다. 한편, 7계층 로드 밸런서는 일반적으로 고급 기능을 제공하지 않으므로 마이크로서비스에서 API 게이트웨이에 비해 장점이 덜합니다.

API 관리 및 배포

API 게이트웨이는 많은 수의 API를 관리하고 배포해야 하는 시나리오에서도 매우 적합합니다. 이는 강력한 API 관리 기능을 가지고 있기 때문입니다. 이 경우 특정 API를 쉽게 활성화하거나 비활성화할 수 있으며, API의 전달 구성을 빠르게 수정하고, 속도 제한, 인증, 로깅 등의 기능을 추가할 수 있습니다. API 게이트웨이를 재시작할 필요 없이 이러한 작업을 수행할 수 있습니다.

Apache APISIX를 예로 들면, 이는 Apache 재단의 최상위 오픈소스 프로젝트이며 현재 가장 활발한 오픈소스 게이트웨이 프로젝트입니다. 동적, 실시간, 고성능 오픈소스 API 게이트웨이로서 Apache APISIX는 로드 밸런싱, 동적 업스트림, 카나리 릴리스, 서킷 브레이커, 인증, 관측 가능성 등 다양한 트래픽 관리 기능을 제공합니다.

반면, 전통적인 로드 밸런서는 API 관리 측면에서 상대적으로 약하며, 이러한 풍부한 고급 기능이 필요하지 않습니다.

고성능 네트워크 접근

고트래픽과 극도로 높은 안정성이 필요한 네트워크 접근 시나리오에서는 4계층 로드 밸런서가 분명히 더 적합합니다. 이는 네트워크의 원래 4계층 트래픽을 각 백엔드 서비스로 직접 분배할 수 있으며, 중간 계층에서 애플리케이션 계층 프로토콜을 여러 번 파싱하는 영향을 받지 않아 더 높은 처리량을 처리할 수 있습니다.

반면, 7계층에서 동작하는 API 게이트웨이는 통일된 진입점으로서 프로토콜 파싱이 필요하므로 처리량에 일정한 제한이 있습니다. 네트워크 접근에 4계층 API 게이트웨이를 사용하는 것은 특별히 유리하지 않습니다. 이 계층은 API 게이트웨이의 주요 초점이 아니기 때문입니다. 이 계층에서 로드 밸런서의 수년간의 기술적 축적에 비해 API 게이트웨이의 장점은 훨씬 적습니다.

요약

일반적으로 API 게이트웨이와 로드 밸런서는 서로 다른 문제를 해결하기 위해 사용되는 인프라 솔루션입니다. API 게이트웨이는 주로 백엔드 API 인터페이스의 프록시로 사용되며, 다양한 유형의 API에 접근할 수 있는 단일 진입점을 제공하고 속도 제한, 인증, 모니터링 등의 독립적인 기능을 제공합니다. 반면 로드 밸런서는 주로 4계층 트래픽 분배를 위해 사용되며, 여러 백엔드 서버에 요청을 분산시켜 요청 부하를 균형 있게 분배하고 전체 시스템의 가용성과 내결함성을 향상시킵니다.

합리적인 아키텍처 설계 하에서 API 게이트웨이와 로드 밸런서는 일반적으로 함께 사용됩니다. 로드 밸런서는 전체 시스템의 네트워크 접근을 담당하며, 트래픽을 여러 API 게이트웨이 인스턴스로 분배합니다. 각 API 게이트웨이 인스턴스는 요청을 라우팅, 인증, 권한 부여하여 전체 네트워크를 더 견고하고 신뢰할 수 있으며 확장 가능하게 만듭니다.