NGINX로 Azure 앱 성능 및 보안 개선

Azure용 NGINXaaS를 사용하면 기업이 클라우드에서 고성능 애플리케이션을 안전하게 제공할 수 있습니다. NGINX Plus로 구동되는 완전 관리형 서비스로, 2023년 1월에 일반적으로 출시되었습니다. 출시 이후, 앞으로도 새로운 기능을 추가하여 Azure용 NGINXaaS를 지속적으로 개선해 나갈 것입니다.

이 블로그에서는 NGINX Plus 인스턴스를 직접 배포, 유지 관리, 업데이트하지 않고도 NGINX Plus의 이점을 더 많이 누릴 수 있게 해주는 최신 성능 및 보안 기능 중 일부를 소개하겠습니다. Azure용 NGINXaaS와 그 포괄적인 기능에 대한 일반 정보는 F5 NGINXaaS for Azure로 클라우드 마이그레이션을 간소화하고 가속화를 참조하세요.

그림 1 : Azure용 NGINXaaS 개요

mTLS를 사용한 업스트림 트래픽 보안

리버스 프록시는 공용 인터넷에서 클라이언트 측 트래픽을 암호화하기 위해 SSL/TLS가 필요한 반면, 서버 측에서 인증하고 기밀성을 보장하려면 상호 TLS(mTLS)가 필수적입니다. Zero Trust 로 전환함에 따라 업스트림 서버 트래픽이 변경되거나 가로채지지 않았는지 확인하는 것도 필요합니다.

그림 2: NGINXaaS를 사용한 mTLS

Azure용 NGINXaaS는 이제 SSL/TLS 인증서로 업스트림 트래픽을 보호 하는 NGINX 지침을 지원합니다. 이러한 지침을 사용하면 mTLS를 통해 업스트림 트래픽을 암호화할 수 있을 뿐만 아니라, 업스트림 서버가 신뢰할 수 있는 인증 기관의 유효한 인증서를 제시하는지 확인할 수도 있습니다.

자격증 순환

Azure용 NGINXaaS에서 TLS 인증서를 사용하는 데 있어 중요한 부분은 Azure Key Vault(AKV) 를 사용하여 해당 인증서를 안전하게 관리하는 것입니다. AKV는 중요하고 암호화된 자료를 안전하게 보관하고, Azure용 NGINXaaS가 해당 인증서를 사용할 수 있도록 하는 동시에 Azure Portal을 통해 키 자료가 실수로 또는 의도적으로 공개되는 것을 방지합니다.

그림 3: Azure Key Vault를 사용한 인증서 회전

Azure용 NGINXaaS는 이제 AKV에서 업데이트될 때마다 NGINX 배포를 통해 인증서를 자동으로 회전 할 수 있습니다. 인증서의 새 버전은 4시간 이내에 배포로 회전됩니다.

HTTP/2 프록시(및 추가 프로토콜 옵션)

눈을 감고 1997년을 떠올려보세요. 우리는 Chumbawamba와 함께 Tubthumping을 하며 JNCO 청바지를 입고(캐나다에 사는 사람이라면 Modrobes를 입을 수도 있겠죠) HTTP/1.1이 출시되었습니다. 당시 대부분의 최종 사용자는 다이얼업 모뎀을 통해 인터넷에 접속했고, 웹 페이지에는 수십 개의 요소만 있었고, 사용자 경험 측면에서는 지연 시간보다 대역폭이 훨씬 더 큰 문제였습니다.

25년이 지난 지금도 상당수의 웹 애플리케이션은 여전히 HTTP/1.1을 사용하여 콘텐츠를 전송합니다. 이는 문제가 될 수 있습니다. HTTP/1.1은 여전히 작동하지만 한 번에 연결당 하나의 리소스만 전송할 수 있습니다. 반면, 최신 웹 앱은 사용자 인터페이스를 업데이트하기 위해 수백 개의 요청을 할 수 있습니다.

대부분 사용자는 훨씬 더 많은 대역폭을 사용할 수 있지만, 데이터 전송 속도(기본적인 빛의 속도에 의해 제한됨)는 그만큼 빠르게 발전하지 못했습니다. 따라서 모든 요청의 누적 지연 시간은 애플리케이션의 체감 성능에 상당한 영향을 미칠 수 있습니다. 최신 브라우저는 동일한 서버에 여러 개의 TCP 연결을 열지만, 해당 연결에 대한 각 요청은 여전히 순차적이므로 느린 리소스 하나가 다른 모든 리소스를 지연시킬 수 있습니다.

HTTP/1.1만을 사용하여 로드할 때 F5 홈페이지를 살펴보세요.

그림 4: HTTP/1.1을 통해 접근한 F5.com

저 회색 막대 보이시나요? 브라우저가 세션 설정을 기다리거나, 느린 리소스 하나를 차단하거나, 사용 가능한 새 TCP 연결을 찾는 등 귀중한 시간을 낭비하고 있기 때문입니다.

HTTP/2를 활성화하고 다시 시도해 보겠습니다.

그림 5: 동일한 요청이지만 HTTP/2를 사용합니다.

훨씬 좋아졌어요. 여전히 느린 리소스가 몇 개 있지만 다른 요청을 지연시키지 않으며 대기열 관련 지연을 기다리는 데 소요되는 시간이 상당히 줄었습니다. HTTP/2는 웹 브라우저와 서버에서 HTTP/1.1부터 익숙한 의미 체계를 그대로 유지하면서도 애플리케이션 성능이 저하되는 이유(예: 요청 우선 순위, 헤더 압축, 요청 다중화)를 해결하기 위한 새로운 기능을 추가했습니다.

이처럼 명확한 차이점을 고려하여 Azure용 NGINXaaS는 이제 HTTP/2 를 통해 클라이언트 요청을 처리하는 것을 지원합니다. 클라이언트 측 연결은 긴 왕복 시간으로 인해 영향을 받을 가능성이 더 높으므로 업스트림 서버를 변경하지 않고도 HTTP/2의 지연 시간을 줄여 트래픽을 전송할 수 있습니다.

웹 애플리케이션 업계에 있는 일부 사람들이 믿고 싶어하는 것과 달리, 우리는 HTTP 외에도 여러분이 사용할 수 있는 추가 프로토콜 옵션이 있다는 사실을 인식하고 있습니다. 이것이 NGINX gRPC 모듈 이 이제 Azure용 NGINXaaS에서도 사용 가능한 이유입니다. gRPC 트래픽 작업을 위한 여러 가지 구성 지침을 제공하며, 여기에는 오류 차단, 헤더 조작 등이 포함됩니다.

HTTP/gRPC가 아닌 트래픽의 경우 이제 Azure용 NGINXaaS에서 스트림 모듈을 사용할 수 있습니다. 이 모듈은 TCP 및 UDP 트래픽의 프록싱과 부하 분산을 지원합니다.

4계층 및 7계층 부하 분산 지원

Azure용 NGINXaaS는 이제 계층 4 TCP/UDP와 계층 7 HTTP/HTTP 클라우드 네이티브 부하 분산 장치로 모두 작동할 수 있습니다. 왜 이것이 중요한가요? 두 개의 서로 다른 서비스나 로드 밸런서를 배포하는 대신, Azure용 NGINXaaS를 사용하면 단일 로드 밸런서를 배포하고 두 계층에서 동시에 작동하도록 구성할 수 있으므로 클라우드 아키텍처가 간소화되고 비용이 절감됩니다.

구성에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

더 높은 용량(최대 160개 NCU)

Azure용 NGINXaaS는 NGINX 용량 단위(NCU) 로 시간 단위로 측정되고 월 단위로 청구되는 소비 기반 서비스입니다. 최근 우리는 배치 용량을 80개 NCU에서 160개 NCU로 두 배로 늘렸습니다. 고객은 20개의 NCU를 갖춘 작은 시스템을 구축할 수 있으며, 작업 부하가 늘어나면 최대 160개의 NCU까지 확장할 수 있습니다. 또한 고객은 처음에 최대 160개의 NCU를 배포할 수 있는 옵션도 있습니다.

NGINX Plus 지침 추가

온프레미스에서 완전 관리형 클라우드 서비스로 쉽게 리프트 앤 시프트 방식으로 구성을 변경할 수 있는 환경을 제공하기 위해 많은 NGINX Plus 지침을 추가했습니다. Azure용 NGINXaaS에서 지원하는 모든 NGINX Plus 지침을 여기 에서 참조하세요.

오늘 시작하세요

우리는 NGINX와 F5 기술을 사용하여 모든 앱과 API를 어디에서나 보호하고, 제공하고, 최적화할 수 있는 방법을 끊임없이 개선하고 확장하고 있습니다. 앞서 언급한 기능과 Azure용 NGINXaaS에 추가된 다른 새로운 기능을 통해 더 많은 Azure 사용자가 추가 VM이나 컨테이너 인프라를 관리하는 오버헤드 없이 NGINX Plus의 힘으로 수많은 앱과 API 문제를 해결할 수 있습니다.

Azure용 NGINXaaS에 대해 자세히 알아보려면 제품 설명서를 살펴보세요. Azure용 NGINXaaS를 사용해보고 싶으시다면 Azure Marketplace를 방문하거나 당사에 문의하여 사용 사례에 대해 논의해 보세요.