NGINX 오픈 소스와 당사의 애플리케이션 전송 플랫폼인 NGINX Plus – UDP 부하 분산에 흥미로운 새 기능이 추가되었다는 소식을 전해드리게 되어 기쁘게 생각합니다. 새로운 기능은 기존의 TCP 및 HTTP 기능을 기반으로 구축되었으며, 이를 통해 NGINX는 더욱 광범위한 인터넷 애플리케이션 및 장치를 위한 강력하고 사용하기 쉬우 며 일관된 프런트엔드가 됩니다. 세계에서 가장 바쁜 애플리케이션의 절반 이상에 전력을 공급하는 부하 분산 기능을 사물 인터넷(IoT)을 구축하는 새로운 사용자 그룹에게 확장하게 되어 기쁩니다.
대부분의 인터넷 애플리케이션은 네트워크 통신을 위해 HTTP에 의존합니다. SOAP 및 REST와 같은 고급 프로토콜은 HTTP를 기반으로 구축되었으며, TLS를 사용한 보안, Gzip을 사용한 압축, HTTP/2를 사용한 성능 향상 등 다양한 풍부한 확장 기능을 활용할 수 있습니다.
그럼에도 불구하고, 많은 애플리케이션은 다양한 목적에 따라 여러 프로토콜을 사용해야 하며, 핵심 인터넷 프로토콜 중 다수는 HTTP보다 먼저 나왔습니다. 이러한 이유로 부하 분산 및 역방향 프록싱을 위한 완벽한 솔루션은 TCP 기반 및 UDP 기반 프로토콜을 모두 포함한 광범위한 프로토콜을 지원해야 합니다.
UDP는 본질적으로 트랜잭션이 아닌 가벼운 프로토콜에 일반적으로 사용됩니다. 이러한 프로토콜로는 DNS(도메인 이름을 주소로 확인하는 데 사용), syslog(가벼운 로깅에 사용), RADIUS(인증에 사용)가 있습니다. 이러한 프로토콜에는 엄격한 안정성 요구 사항이 없습니다. 즉, UDP 메시지( 데이터그램 )가 삭제되더라도 클라이언트는 시간 초과 후에 안전하게 메시지를 다시 보낼 수 있습니다. 그러나 이러한 프로토콜이 제공하는 서비스는 인터넷 서비스가 올바르게 작동하는 데 필수적입니다. UDP는 낮은 대역폭 요구 사항으로 인해 새로운 IoT 애플리케이션을 위한 프로토콜 중 하나로 떠오르고 있습니다.
1년 전, NGINX는 사용자 커뮤니티와 상업 고객에게 TCP 부하 분산을 도입했습니다 . 이제 UDP 로드 밸런싱을 추가하여 로드 밸런싱 기능을 확장하게 되어 기쁩니다. NGINX와 NGINX Plus를 사용하면 이제 사용자는 안정성, 확장성, 성능을 갖춘 UDP 기반 서비스를 제공할 수 있습니다.
NGINX는 관리자가 정의한 하나 이상의 주소(IP 주소 및 포트)에서 UDP 네트워크 트래픽(DNS, syslog, RADIUS와 같은 프로토콜)을 수신합니다. 이러한 주소는 클라이언트가 원하는 서비스에 대한 요청을 어디로 보내야 할지 알 수 있도록 게시됩니다.
HTTP 및 TCP 부하 분산의 경우와 마찬가지로 UDP 부하 분산 구성은 업스트림 그룹 (UDP 기반 서비스를 제공하는 원본 서버 세트)과 서버 간에 트래픽 부하 분산에 사용할 알고리즘 (예: 라운드 로빈, 최소 연결 또는 소스 IP 주소 기반 해시)을 정의합니다. 이 구성에서는 관련 서비스를 제공하는 업스트림 그룹을 명명하는 proxy_pass
지시문으로 각 UDP 포트에 대한 가상 서버도 정의합니다.
# 두 서버에서 UDP 기반 DNS 트래픽 로드 밸런싱stream {
upstream dns_upstreams {
server 192.168.136.130:53;
server 192.168.136.131:53;
}
server {
listen 53 udp;
proxy_pass dns_upstreams;
proxy_timeout 1s;
proxy_responses 1;
error_log logs/dns.log;
}
}
NGINX가 포트에서 UDP 데이터그램을 수신하면(여기서는 포트 53의 DNS 쿼리), 구성된 부하 분산 알고리즘(여기서는 기본 라운드 로빈)을 사용하여 업스트림 그룹에서 해당 데이터그램을 처리할 서버를 선택합니다. 적절한 경우 NGINX는 서버로부터 응답을 기다리고 해당 응답(및 제한 시간 내에 수신된 모든 후속 패킷)을 클라이언트로 다시 전달합니다.
서버가 요청에 응답하지 못하면 NGINX는 이를 '실패'로 표시하고 일시적으로 해당 서버로의 데이터그램 전송을 중단합니다. 몇 초마다 NGINX는 소량의 라이브 트래픽을 보내 서버가 복구되었는지 확인하기 위해 서버 상태를 점검합니다.
NGINX Plus R9에는 HTTP 및 TCP 트래픽 과 유사한 UDP 서비스에 대한 애플리케이션 상태 점검(비동기 또는 합성이라고도 함) 기능이 포함됩니다. NGINX Plus를 구성하여 업스트림 서버로 특수 UDP 요청을 보내고, 서버가 정상으로 간주되기 위해 반환해야 하는 응답 유형을 정의할 수 있습니다.
UDP 부하 분산에서 지원되는 다른 기능으로는 웹 서버 스타일 액세스 로그에 대한 트랜잭션 로깅, IP 주소 기반 액세스 제어 목록 및 다양한 속도 제한 기능이 있습니다.
NGINX Plus R9 에서는 Status 모듈 에서 제공하는 라이브 활동 모니터링 통계에 UDP 메트릭이 포함되고, 현재 HTTP 및 TCP 서버에서 가능하듯이 HTTP 기반 API와 DNS를 사용하여 UDP 업스트림 그룹을 즉시 재구성 할 수 있습니다.
UDP 부하 분산은 고가용성 및 수평적 확장이라는 두 가지 주요 사용 사례를 해결합니다. UDP는 설계상 종단 간 데이터 전달을 보장하지 않으므로 클라이언트 소프트웨어에서 네트워크 수준의 오류와 재전송을 처리해야 합니다. UDP 기반 프로토콜은 일반적으로 서버 쌍을 정의합니다. 클라이언트가 기본 서버에 연결할 수 없는 경우 다른 서버에 연결을 시도하기 전에 정의된 시간 초과 기간 동안 기다려야 합니다. 이로 인해 UDP 거래에 오랜 지연이 발생할 수 있습니다.
UDP 서버 앞에 NGINX 또는 NGINX Plus를 고가용성 및 안정성이 뛰어난 로드 밸런서로 배포하면 이런 종류의 지연을 없애거나 줄일 수 있습니다. 클라이언트는 UDP 요청을 NGINX 또는 NGINX Plus 로드 밸런서로 보냅니다. 이 로드 밸런서는 UDP 서버의 상태와 가용성을 모니터링하고 오류가 발생하거나 과부하된 서버로는 요청을 보내지 않습니다. 클라이언트는 연결이나 요청 실패를 경험하지 않으므로 요청을 다시 시도하는 것과 관련된 시간 초과로 어려움을 겪지 않습니다.
NGINX 또는 NGINX Plus를 부하 분산 장치로 사용하면 대량 트래픽을 처리하기 위해 UDP 애플리케이션을 확장할 수도 있습니다. 일반적인 UDP 배포에서 클라이언트는 최대 2개의 UDP 서버를 인식하지만, 높은 수요를 충족시키기 위해 확장하려면 훨씬 더 많은 UDP 서버가 필요합니다. 이 시나리오에서 클라이언트는 UDP 요청을 하나 또는 두 개의 알려진 NGINX 또는 NGINX Plus 인스턴스로 보내면 이를 통해 실제로 부하를 처리하는 데 필요한 더 많은 수의 UDP 서버에 요청의 부하가 분산됩니다.
NGINX 및 NGINX Plus를 사용한 UDP 부하 분산은 데이터를 전송하고 선택적으로 하나 이상의 응답을 기대하는 모든 UDP 기반 애플리케이션에 적합합니다. NGINX는 IoT 환경에서 찾을 수 있는 것과 같은 독점적인 UDP 기반 프로토콜의 부하를 분산할 수도 있습니다.
당사 릴리스에서 UDP 부하 분산이 제공되는 구체적인 시점은 다음과 같습니다.
NGINX와 NGINX Plus는 광범위한 인터넷 프로토콜에 대한 완전한 부하 분산 및 애플리케이션 전송 플랫폼을 제공합니다. HTTP 기반 애플리케이션, 하위 수준 TCP 애플리케이션 또는 UDP 기반 프로토콜을 제공하든 NGINX와 NGINX Plus를 사용하면 단일 경량 애플리케이션에서 높은 가용성, 안정성, 확장성 및 성능을 제공할 수 있습니다. 우리는 새로운 UDP 부하 분산 기능과 이를 통해 다양한 장치에 고성능 부하 분산과 완벽한 애플리케이션 전송을 제공할 수 있는 잠재력에 대해 매우 기대하고 있습니다.
UDP 로드 밸런싱이 릴리스 9에 출시되기 전에 NGINX Plus에 대해 알아보고 싶으신가요? 오늘 무료 30일 체험판을 시작하거나, 사용 사례에 대해 논의하기 위해 저희에게 문의하세요 .
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."