NGINXaaS for Azure는 기업이 클라우드에서 고성능 애플리케이션을 안전하게 제공할 수 있도록 지원합니다. 2023년 1월에 정식 출시된 완전 관리형 서비스인 NGINX Plus를 기반으로 합니다. 출시 이후부터 앞으로도 계속 새로운 새로운 기능을 추가하여 Azure용 NGINXaaS를 개선해 나갈 것입니다.
이 블로그에서는 자체 NGINX Plus 인스턴스를 배포, 유지 관리 및 업데이트할 필요 없이 더 많은 NGINX Plus 혜택을 누릴 수 있는 최신 성능 및 보안 기능 몇 가지를 중점적으로 소개합니다. Azure용 NGINXaaS 및 주요 기능에 대한 일반적인 정보는 애저용 F5 NGINXaaS로 클라우드 마이그레이션 간소화 및 가속화를 읽어보시기 바랍니다.
그림 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 포털을 통해 키 자료가 실수로 또는 의도적으로 공개되는 것을 방지합니다.
그림 3: Azure Key Vault를 사용한 인증서 순환
이제 Azure용 NGINXaaS는 인증서가 AKV에서 업데이트될 때마다 NGINX 배포를 통해 자동으로 회전할 수 있습니다. 새 버전의 인증서는 4시간 이내에 배포에 순환됩니다.
HTTP/2 프록시(및 추가 프로토콜 옵션)
눈을 감고 1997년을 떠올려보세요. 우리는 JNCO 청바지(또는 캐나다인이라면 모드로브)를 입고 함께 춤을 추고 있었고, HTTP/1.1이 출시되었습니다. 당시 대부분의 최종 사용자는 전화 접속 모뎀을 통해 인터넷에 접속했고 웹 페이지에는 수십 개의 요소만 포함되어 있었으며 사용자 경험에 있어서는 지연 시간보다 대역폭이 훨씬 더 큰 관심사였습니다.
25년이 지난 지금도 상당수의 웹 애플리케이션은 콘텐츠를 전송하는 데 HTTP/1.1을 사용하고 있습니다. 이는 문제가 될 수 있습니다. HTTP/1.1은 여전히 작동하지만, 연결당 한 번에 하나의 리소스만 전송할 수 있습니다. 한편 최신 웹 앱은 사용자 인터페이스를 업데이트하기 위해 수백 번의 요청을 할 수 있습니다.
대부분의 사용자는 훨씬 더 많은 대역폭을 사용할 수 있지만, 데이터 전송 속도(기본 광속의 제약을 받음)는 그만큼 빠르게 발전하지 못했습니다. 따라서 이러한 모든 요청의 누적 지연 시간은 애플리케이션의 체감 성능에 상당한 영향을 미칠 수 있습니다. 최신 브라우저는 동일한 서버에 대해 여러 개의 TCP 연결을 열지만 이러한 연결의 각 요청은 여전히 순차적이기 때문에 느린 리소스 하나가 뒤에 있는 다른 모든 리소스를 지연시킬 수 있습니다.
Take a look at F5’s homepage when it loads using only HTTP/1.1:
그림 4: HTTP/1.1을 통해 접속한 F5.com
회색 막대가 보이시나요? 이는 브라우저가 세션 설정을 기다리거나 느린 리소스 하나를 차단하거나 새로운 TCP 연결을 사용할 수 있게 되기를 기다리는 동안 낭비하는 귀중한 시간입니다.
HTTP/2를 활성화하고 다시 시도해 보겠습니다:
Figure 5: The same request, but using HTTP/2
훨씬 나아졌습니다. 여전히 느린 리소스가 몇 개 있지만 다른 요청을 지연시키지 않으며 대기열 관련 지연으로 인한 대기 시간도 훨씬 줄어듭니다. HTTP/2는 웹 브라우저와 서버가 HTTP/1.1에서 익숙한 동일한 의미를 유지하면서 애플리케이션 성능이 좋지 않게 인식되는 몇 가지 이유(예: 요청 우선순위 지정, 헤더 압축, 요청 다중화)를 해결하기 위한 새로운 기능을 추가합니다.
이러한 명확한 차이를 감안하여 이제 Azure용 NGINXaaS는 HTTP/2를 통한 클라이언트 요청을 지원합니다. 클라이언트 측 연결은 왕복 시간이 길어지면 영향을 받을 가능성이 높으므로 업스트림 서버를 변경하지 않고 HTTP/2의 지연 시간 단축 이점을 통해 해당 트래픽을 전송할 수 있습니다.
웹 애플리케이션 업계 일부의 생각과 달리, 저희는 HTTP 외에도 사용할 수 있는 프로토콜 옵션이 있다는 사실을 잘 알고 있습니다. 이것이 바로 NGINX gRPC 모듈이 이제 Azure용 NGINXaaS에서도 제공되는 이유입니다. 이 모듈은 오류 차단, 헤더 조작 등을 포함하여 gRPC 트래픽 작업을 위한 여러 구성 지시어를 제공합니다.
비 HTTP/gRPC 트래픽의 경우, stream 모듈을 이제 Azure용 NGINXaaS에서 사용할 수 있습니다. 이 모듈은 TCP 및 UDP 트래픽 프록시 및 로드 밸런싱을 지원합니다.
레이어 4 및 레이어 7 부하 분산 지원
이제 Azure용 NGINXaaS는 레이어 4 TCP/UDP 및 레이어 7 HTTP/HTTP 클라우드 네이티브 로드 밸런서 역할을 모두 수행할 수 있습니다. 이것이 왜 중요한가요? 두 개의 서로 다른 서비스 또는 로드 밸런서를 배포하는 대신 Azure용 NGINXaaS를 사용하면 단일 로드 밸런서를 배포하고 두 계층에서 동시에 작동하도록 구성하여 클라우드 아키텍처를 간소화하고 비용을 절감할 수 있습니다.
구성에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
더 높은 용량(최대 160개 NCU)
Azure용 NGINXaaS는 시간당 계량되고 월 단위로 청구되는 소비 기반 서비스이며, <데이터-dl-uid="53">NGINX 용량 단위(NCU)로 청구됩니다. 최근 배포 용량을 80개 NCU에서 160개 NCU로 두 배로 늘렸습니다. 고객은 20개 NCU의 소규모 시스템을 배포할 수 있으며, 워크로드가 증가하면 최대 160개 NCU까지 확장할 수 있습니다. 또한 고객은 처음에 최대 160개의 NCU를 배포할 수 있는 옵션도 있습니다.
NGINX 플러스 지시어 추가
온프레미스에서 완전 관리형 클라우드 제품으로 쉽게 구성 환경을 전환할 수 있도록 많은 NGINX Plus 지시어를 추가했습니다. Azure용 NGINXaaS에서 지원하는 모든 NGINX Plus 지시어는 여기에서 참조하세요.
지금 시작하기
당사는 모든 앱과 API를 어디서나 보호, 제공 및 최적화하기 위해 NGINX와 F5 기술을 사용할 수 있는 방법을 항상 개선하고 확장하고 있습니다. 앞서 언급한 기능 및 기타 새로운 기능이 Azure용 NGINXaaS에 추가됨에 따라 더 많은 Azure 사용자가 추가 VM 또는 컨테이너 인프라 관리의 오버헤드 없이 NGINX Plus의 강력한 기능으로 수많은 앱 및 API 문제를 해결할 수 있습니다.
위 내용와 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
NGINXaaS for Azure는 기업이 클라우드에서 고성능 애플리케이션을 안전하게 제공할 수 있도록 지원합니다. 2023년 1월에 정식 출시된 완전 관리형 서비스인 NGINX Plus를 기반으로 합니다. 출시 이후부터 앞으로도 계속 새로운 새로운 기능을 추가하여 Azure용 NGINXaaS를 개선해 나갈 것입니다.
이 블로그에서는 자체 NGINX Plus 인스턴스를 배포, 유지 관리 및 업데이트할 필요 없이 더 많은 NGINX Plus 혜택을 누릴 수 있는 최신 성능 및 보안 기능 몇 가지를 중점적으로 소개합니다. Azure용 NGINXaaS 및 주요 기능에 대한 일반적인 정보는 애저용 F5 NGINXaaS로 클라우드 마이그레이션 간소화 및 가속화를 읽어보시기 바랍니다.
그림 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 포털을 통해 키 자료가 실수로 또는 의도적으로 공개되는 것을 방지합니다.
그림 3: Azure Key Vault를 사용한 인증서 순환
이제 Azure용 NGINXaaS는 인증서가 AKV에서 업데이트될 때마다 NGINX 배포를 통해 자동으로 회전할 수 있습니다. 새 버전의 인증서는 4시간 이내에 배포에 순환됩니다.
HTTP/2 프록시(및 추가 프로토콜 옵션)
눈을 감고 1997년을 떠올려보세요. 우리는 JNCO 청바지(또는 캐나다인이라면 모드로브)를 입고 함께 춤을 추고 있었고, HTTP/1.1이 출시되었습니다. 당시 대부분의 최종 사용자는 전화 접속 모뎀을 통해 인터넷에 접속했고 웹 페이지에는 수십 개의 요소만 포함되어 있었으며 사용자 경험에 있어서는 지연 시간보다 대역폭이 훨씬 더 큰 관심사였습니다.
25년이 지난 지금도 상당수의 웹 애플리케이션은 콘텐츠를 전송하는 데 HTTP/1.1을 사용하고 있습니다. 이는 문제가 될 수 있습니다. HTTP/1.1은 여전히 작동하지만, 연결당 한 번에 하나의 리소스만 전송할 수 있습니다. 한편 최신 웹 앱은 사용자 인터페이스를 업데이트하기 위해 수백 번의 요청을 할 수 있습니다.
대부분의 사용자는 훨씬 더 많은 대역폭을 사용할 수 있지만, 데이터 전송 속도(기본 광속의 제약을 받음)는 그만큼 빠르게 발전하지 못했습니다. 따라서 이러한 모든 요청의 누적 지연 시간은 애플리케이션의 체감 성능에 상당한 영향을 미칠 수 있습니다. 최신 브라우저는 동일한 서버에 대해 여러 개의 TCP 연결을 열지만 이러한 연결의 각 요청은 여전히 순차적이기 때문에 느린 리소스 하나가 뒤에 있는 다른 모든 리소스를 지연시킬 수 있습니다.
Take a look at F5’s homepage when it loads using only HTTP/1.1:
그림 4: HTTP/1.1을 통해 접속한 F5.com
회색 막대가 보이시나요? 이는 브라우저가 세션 설정을 기다리거나 느린 리소스 하나를 차단하거나 새로운 TCP 연결을 사용할 수 있게 되기를 기다리는 동안 낭비하는 귀중한 시간입니다.
HTTP/2를 활성화하고 다시 시도해 보겠습니다:
Figure 5: The same request, but using HTTP/2
훨씬 나아졌습니다. 여전히 느린 리소스가 몇 개 있지만 다른 요청을 지연시키지 않으며 대기열 관련 지연으로 인한 대기 시간도 훨씬 줄어듭니다. HTTP/2는 웹 브라우저와 서버가 HTTP/1.1에서 익숙한 동일한 의미를 유지하면서 애플리케이션 성능이 좋지 않게 인식되는 몇 가지 이유(예: 요청 우선순위 지정, 헤더 압축, 요청 다중화)를 해결하기 위한 새로운 기능을 추가합니다.
이러한 명확한 차이를 감안하여 이제 Azure용 NGINXaaS는 HTTP/2를 통한 클라이언트 요청을 지원합니다. 클라이언트 측 연결은 왕복 시간이 길어지면 영향을 받을 가능성이 높으므로 업스트림 서버를 변경하지 않고 HTTP/2의 지연 시간 단축 이점을 통해 해당 트래픽을 전송할 수 있습니다.
웹 애플리케이션 업계 일부의 생각과 달리, 저희는 HTTP 외에도 사용할 수 있는 프로토콜 옵션이 있다는 사실을 잘 알고 있습니다. 이것이 바로 NGINX gRPC 모듈이 이제 Azure용 NGINXaaS에서도 제공되는 이유입니다. 이 모듈은 오류 차단, 헤더 조작 등을 포함하여 gRPC 트래픽 작업을 위한 여러 구성 지시어를 제공합니다.
비 HTTP/gRPC 트래픽의 경우, stream 모듈을 이제 Azure용 NGINXaaS에서 사용할 수 있습니다. 이 모듈은 TCP 및 UDP 트래픽 프록시 및 로드 밸런싱을 지원합니다.
레이어 4 및 레이어 7 부하 분산 지원
이제 Azure용 NGINXaaS는 레이어 4 TCP/UDP 및 레이어 7 HTTP/HTTP 클라우드 네이티브 로드 밸런서 역할을 모두 수행할 수 있습니다. 이것이 왜 중요한가요? 두 개의 서로 다른 서비스 또는 로드 밸런서를 배포하는 대신 Azure용 NGINXaaS를 사용하면 단일 로드 밸런서를 배포하고 두 계층에서 동시에 작동하도록 구성하여 클라우드 아키텍처를 간소화하고 비용을 절감할 수 있습니다.
구성에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
더 높은 용량(최대 160개 NCU)
Azure용 NGINXaaS는 시간당 계량되고 월 단위로 청구되는 소비 기반 서비스이며, <데이터-dl-uid="53">NGINX 용량 단위(NCU)로 청구됩니다. 최근 배포 용량을 80개 NCU에서 160개 NCU로 두 배로 늘렸습니다. 고객은 20개 NCU의 소규모 시스템을 배포할 수 있으며, 워크로드가 증가하면 최대 160개 NCU까지 확장할 수 있습니다. 또한 고객은 처음에 최대 160개의 NCU를 배포할 수 있는 옵션도 있습니다.
NGINX 플러스 지시어 추가
온프레미스에서 완전 관리형 클라우드 제품으로 쉽게 구성 환경을 전환할 수 있도록 많은 NGINX Plus 지시어를 추가했습니다. Azure용 NGINXaaS에서 지원하는 모든 NGINX Plus 지시어는 여기에서 참조하세요.
지금 시작하기
당사는 모든 앱과 API를 어디서나 보호, 제공 및 최적화하기 위해 NGINX와 F5 기술을 사용할 수 있는 방법을 항상 개선하고 확장하고 있습니다. 앞서 언급한 기능 및 기타 새로운 기능이 Azure용 NGINXaaS에 추가됨에 따라 더 많은 Azure 사용자가 추가 VM 또는 컨테이너 인프라 관리의 오버헤드 없이 NGINX Plus의 강력한 기능으로 수많은 앱 및 API 문제를 해결할 수 있습니다.
위 내용와 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기