API Gateway와 Load Balancer를 NGINX로 통합
API Gateway, Load Balancer 최근 DevOps 기반 조직의 표준으로 채택되고 있는 습니다. 우리는 어떤 새로운 과제를 안고 있습니까? “proxy sprawl”의 복잡성을 어떻게 처리할 수 있습니까? 성능, 안정성 및 기능을 저하 시키지 않고 통합할 수 있습니까?
Web 및 App 제공 분야의 대부분의 전문가는 하드웨어 Load Balancer 시장에 익숙합니다. 하드웨어 Load Balancer는 Load Balancing 라우터로 시작하여 트래픽이 많거나 비즈니스에 중요한 애플리케이션을 제공하는 표준 방식으로 빠르게 자리 잡았습니다.
매출 증대에 대한 끊임없는 압박에 힘입어 하드웨어 Load Balancer 공급업체는 SSL VPN의 가상 데스크톱 브로커와 같은 여러 기능을 장치에 번들로 제공했습니다. 하드웨어 장치는 점점 더 복잡해지고 다루기 어려워졌고, 사용자들은 이 필수적인 기술을 소유하고 운영하는데 점점 더 많은 비용이 든다는 것을 알게 되었습니다.
목차
1. 기업에서 하드웨어 Load Balancer를 대체하는 소프트웨어
1-1. 소프트웨어는 포인트 솔루션 이상으로 발전해야 합니다.
2. NGINX 및 NGINX Plus를 통한 애플리케이션 제공 스택 통합
2-1. 성능 저하 없는 통합
3. API Gateway 사용 사례
3-1. NGINX Plus를 통한 API Gateway 솔루션 향상
4. 결론
1. 기업에서 하드웨어 Load Balancer를 대체하는 소프트웨어
하드웨어 Load Balancer가 붕괴되기 시작하자 DevOps팀은 애플리케이션 제공 요구 사항을 충족하기 위해 훨씬 더 가벼운 소프트웨어 Load Balancer를 대안으로 전환했습니다. 익숙한 오픈소스 기술인 NGINX 리버스 프록시, ModSecurity 웹 애플리케이션 방화벽(WAF), Varnish cache, HAProxy와 같은 소프트웨어 기반 솔루션이 하드웨어를 대체했습니다. 소프트웨어는 애플리케이션별로 쉽고 비용 효율적으로 배포할 수 있어 애플리케이션 소유자에게 직접 제어 권한을 부여하고 DevOps팀이 신속하게 프로세스를 지원할 수 있습니다.
소프트웨어 에코시스템은 DevOps 엔지니어가 직면한 각 문제에 대한 단일 목적의 포인트 솔루션으로 가득 차 있습니다. 각각의 새로운 사용 사례는 리버스 프록시를 기반으로 구축된 새로운 솔루션 세트로 해결되었습니다. 예를 들어 API 기반 서비스를 보호하기 위해 API 트래픽을 관리하고 라우팅, 인증, 속도 제한 및 액세스 제어 정책을 적용해야 하기 때문에 API Gateway 제품이 등장했습니다.
1-1. 소프트웨어는 포인트 솔루션 이상으로 발전해야 합니다.
포인트 솔루션의 폭발적 증가는 DevOps 엔지니어에게 분명히 문제를 제기합니다. 그들은 각 솔루션을 배포, 구성, 업데이트 및 모니터링하는 프로세스에 익숙해져야 합니다. 특히 여러 솔루션 간의 상호 작용으로 인해 문제가 발생하는 경우 문제 해결이 훨씬 더 복잡해집니다.
특정 용도의 하드웨어 장치가 확산되면서 단일 Load Balancer에서 많은 기능이 통합된 것처럼 DevOps팀은 이제 소프트웨어 기능을 단일 플랫폼으로 통합하여 복잡성을 줄이고 인프라를 단순화해야 합니다. 그러나 이번에는 이전에 하드웨어 Load Balancing 장치에서 했던 실수를 피하는 것이 중요합니다. 통합 솔루션은 성능이 떨어지거나 운영이 복잡하거나 애플리케이션별로 배포하는 데 비용이 많이 드는 경우에는 거의 소용이 없습니다.
2. NGINX 및 NGINX Plus를 통한 API Gateway, Load Balancer 통합
대부분의 DevOps 엔지니어들은 웹 서버, 리버스 프록시, API Gateway 등 다양한 기능을 제공하고 세계에서 가장 빠른 솔루션인 NGINX에 매우 익숙합니다.
NGINX 오픈소스를 사용하여 분산 콘텐츠 전송 네트워크(CloudFlare, CloudFront, MaxCDN 등)에서 로컬 API Gateway에 이르기까지 다양한 특정 솔루션을 구축합니다. NGINX는 또한 Kong과 Red Hat 3scale의 상용 Load Balancer 및 API Gateway를 포함한 많은 오픈소스 및 상용 포인트 솔루션의 핵심입니다.
NGINX Plus는 NGINX 오픈소스팀에서 개발했습니다. 인증, 리버스 프록시, Caching, API Gateway, Load Balancing 등의 여러 기능을 단일 소프트웨어 플랫폼으로 통합하여 복잡한 포인트 솔루션 체인이 필요하지 않습니다. WAF(ModSecurity, Stealth Security 및 Wallarm용 모듈 포함), 고급 인증(Curity, Forgerock, IDFConnect, Ping Identity) 및 프로그래밍 기능(NGINX JavaScript, Lua)을 추가하는 인증된 모듈로 쉽게 확장할 수 있습니다.
DevOps 엔지니어에게 NGINX Plus의 이점은 단순한 기능 통합 이상의 것입니다. 풍부한 RESTful API는 NGINX Plus와 Load Balancing중인 Backend 서버의 상태와 성능에 대한 깊은 통찰력을 제공합니다. 동적 재구성 및 서비스 검색 통합은 클라우드 또는 Kubernetes와 같은 유동적인 환경에서 NGINX Plus의 운영을 단순화합니다. NGINX Plus의 클러스터링 기능을 사용하면 신뢰할 수 있는 HA 방식으로 클러스터 간에 트래픽을 분산하고 런타임 상태를 공유할 수 있습니다.
2-1. 성능 저하 없는 통합
NGINX 오픈소스를 기반으로 구축된 타사 솔루션은 추가 NGINX Plus 기능, API 및 클러스터링의 이점을 제공하지 않습니다. 또한 많은 솔루션이 Lua에 의존하여 추가 기능을 구현합니다. Lua는 매우 유능한 언어이지만 확장의 복잡성 때문에 NGINX에 예측할 수 없는 성능 저하를 부과합니다.
NGINX Plus는 NGINX 오픈소스의 고성능 및 가벼운 특성을 손상 시키지 않습니다. 핵심 NGINX Plus 바이너리는 크기가 1.6MB에 불과하며, 업계 표준 하드웨어에서 초당 100만 건 이상, 70Gbps 처리량 및 초당 65,000개의 새로운 SSL 트랜잭션을 처리할 수 있습니다. 새로운 기능은 NGINX 오픈소스와 마찬가지로 핵심 NGINX팀이 프로세스 내 모듈로 구현하므로 각 기능의 성능, 안정성 및 품질을 보장 받을 수 있습니다.
3. API Gateway 사용 사례
대표적인 예가 API Gateway입니다. 다음 표에서는 API Gateway로서의 NGINX Plus가 외부 소스의 API 요청을 관리하고 이를 내부 서비스로 라우팅하기 위한 다양한 요구 사항을 어떻게 충족하는지 보여줍니다.
| 헤더 레이블 | API Gateway 요구 사항 | NGINX Plus 솔루션 |
|---|---|---|
| 핵심 프로토콜 | REST (HTTPS), gRPC | HTTP, HTTPS, HTTP/2, gRPC |
| 추가 프로토콜 | TCP 기반 메시지 큐 | WebSocket, TCP, UDP |
| 라우팅 요청 | 요청은 서비스(호스트 헤더), API 메서드(HTTP URL) 및 매개 변수를 기반으로 라우팅됩니다. | 호스트 헤더, URL 및 기타 요청 헤더에 기반한 매우 유연한 요청 라우팅 |
| API 수명 주기 관리 | 레거시 API 요청 재작성, 사용되지 않는 API에 대한 호출 거부 | 요청을 라우팅하거나 직접 응답할 수 있는 포괄적인 요청 재작성 및 풍부한 의사 결정 엔진 |
| 애플리케이션 보호 방법 | API 및 메서드에 의한 속도 제한 | Source Address, 요청 매개 변수를 포함한 여러 기준에 의한 속도 제한, Backend 서비스에 대한 연결 제한 |
| Offload 인증 | 수신 요청의 인증 토큰 검사 | JWT, API Key, 외부 인증 서비스 및 OpenID Connect를 포함한 여러 인증 방법 지원 |
| 애플리케이션 토폴로지 | 구성 변경을 수락하고 Blue-Green Workflow를 지원하는 다양한 API 구현 | Endpoint를 찾기 위한 API 및 서비스 검색 통합. API는 Blue-Green 및 기타 사용 사례에 맞게 조정될 수 있습니다. |
통합 솔루션인 NGINX Plus는 웹 트래픽을 쉽게 관리할 수 있으며 프로토콜(HTTP/2와 HTTP, FastCGI, uwsgi) 간에 변환하고 일관된 구성 및 모니터링 인터페이스를 제공합니다. NGINX Plus는 컨테이너 환경이나 최소한의 리소스 설치 공간으로 사이드카로 배치하기에 충분히 가볍습니다.
3-1. NGINX Plus를 통한 API Gateway 솔루션 향상
NGINX 오픈소스는 원래 HTTP(웹) 트래픽을 위한 Gateway로 개발되었으며, 구성되는 기본 요소는 HTTP 요청으로 표현됩니다. 이것은 API Gateway를 구성하는 것과 비슷하지만 동일하지는 않기 때문에 DevOps 엔지니어는 API 정의와 HTTP 요청에 매핑 방법을 이해해야 합니다.
4. 결론
DevOps팀이 애플리케이션을 제공하고 운영하기 위해 소프트웨어 구성 요소에 크게 의존하기 때문에 하드웨어 Load Balancer는 제외되었습니다. NGINX 오픈소스는 대부분의 애플리케이션 제공 스택의 핵심 부분으로 인식됩니다.
여러 소프트웨어 구성 요소의 단일 용도 또는 포인트 솔루션 기능으로 인해 다중 계층 애플리케이션 제공 스택이 발생할 수 있습니다. 이러한 최고의 구성 요소로 구축되었지만 이러한 스택은 운영이 복잡하고 문제 해결이 어려우며 성능과 확장성이 일관되지 않을 수 있습니다. NGINX Plus는 이 기능을 단일 소프트웨어 플랫폼으로 통합합니다.
NGINX Plus는 성능이나 안정성을 해치지 않는 검증된 친숙한 기술을 활용해 API 제공 등 광범위한 문제에 적용할 수 있습니다.
NGINX Plus를 API Gateway로 사용해 보고 싶으시면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.