현대 애플리케이션의 현실에 맞춰 설계한 차세대 NGINX 경험 구축

NGINX | 2024년 1월 23일

NGINX의 제품 담당 부사장으로서 저는 고객 및 사용자들과 자주 대화를 나눕니다. 플랫폼 운영 팀, Kubernetes 아키텍트, 애플리케이션 개발자, CISO, CIO, CTO 등 어떤 역할을 맡고 계시든, 저는 여러분과 같은 분들과 이야기를 나눠 왔습니다. 대화를 통해 여러분은 NGINX의 제품, 가격 정책, 라이선스 모델을 비롯해 NGINX에 대한 솔직한 의견을 들려주셨으며, 강점과 약점을 모두 짚어 주셨습니다.

우리가 얻은 핵심 교훈은 ‘NGINX가 세상의 중심’이라는 접근 방식이 사용자에게 도움이 되지 않는다는 점입니다. 그동안 우리는 NGINX를 애플리케이션 배포와 관련된 모든 것을 아우르는 통합 관리 영역인 ‘플랫폼’으로 만들기 위한 제품을 개발해 왔습니다. 이러한 목표에 맞춰 개발한 일부 기존 제품의 사용률과 도입률이 낮다는 사실도 알고 있었습니다. 여러분은 NGINX가 자체 개발 여부와 관계없이 기존 플랫폼에서 미션 크리티컬한 구성 요소이기는 하지만, NGINX 자체가 플랫폼은 아니라고 말씀해 주셨습니다. 따라서 제품을 더 쉽게 배포하고 관리하며 보호할 수 있도록 여러분이 사용하는 다른 구성 요소와의 통합을 개선해야 했습니다. 또한 중요한 점은 투명한 가격 및 사용량 모델을 제공해야 한다는 것입니다. 물론 이 모든 작업을 API를 통해 수행할 수 있어야 합니다.

그 이면의 메시지는 명확했습니다. 특정 방식을 강요하지 않으면서 NGINX를 여러분의 워크플로, 기존 도구 체인 및 프로세스에 더 쉽게 통합할 수 있도록 해달라는 것이었습니다. 여러분의 목소리를 경청했습니다. 2024년에는 데이터 플레인과 보안을 위한 사용 사례 구성 및 관리에 훨씬 더 유연하고 간단하며 반복 가능하고 확장 가능한 접근 방식을 도입할 것입니다.

여러분이 이를 원하는 것은 지극히 당연합니다. 여러분이 처한 환경은 변해 왔으며 지금도 계속 변하고 있습니다! 클라우드에서 하이브리드로, 다시 멀티 클라우드와 멀티 클라우드 하이브리드 구성으로 전환하며 여러 단계를 거쳤습니다. VM에서 Kubernetes로, API에서 마이크로서비스와 서버리스로의 변화도 있었습니다. 많은 분이 시프트 레프트를 도입했고, 이는 복잡성 증가로 이어졌습니다. 더 많은 팀이 더 많은 도구를 사용하면서 관리, 관측 가능성, 강력한 보안에 대한 요구도 커졌습니다. 이 모든 것은 몇 시간, 며칠, 몇 주가 아니라 단 몇 분 만에 확장할 수 있어야 하는 앱을 지원합니다. 여기에 최근의 촉진제인 인공지능(AI)까지 더해져 레거시 애플리케이션 및 인프라 아키텍처에 상당한 부담을 주고 있습니다.

향후 NGINX 제품 릴리스에서 해결할 과제

NGINX 제품의 근간은 언제나 매우 견고하고, 실전에서 검증되었으며, 뛰어난 성능을 제공해 왔지만, 사용자가 NGINX의 모든 측면을 활용하고 관리하며 관찰하는 방식은 시대의 흐름을 따라가지 못했습니다. 이를 개선하기 위해 새로운 제품을 출시하고 다양한 신규 기능을 선보이는 등 빠르게 움직이고 있습니다. 이에 관한 자세한 내용은 F5의 콘퍼런스인 AppWorld 2024에서 발표할 예정입니다. 이 행사는 2월 6일부터 8일까지 열립니다. 향후 제품 릴리스에서 해결하고자 하는 구체적인 문제는 다음과 같습니다.

문제점 #1: 최신 앱은 배포 환경이 다양해 관리하기 어렵습니다

오늘날 CIO와 CTO는 매우 다양한 애플리케이션 배포 방식 중에서 선택할 수 있습니다. 이는 성능, 기능, 복원력 측면에서 훨씬 더 폭넓은 선택지를 제공한다는 점에서 축복입니다. 하지만 다양성은 복잡성과 무분별한 확산을 초래한다는 점에서 저주이기도 합니다. 예를 들어 AWS에서 실행되는 애플리케이션을 관리하려면 Azure Cloud에서 실행되는 애플리케이션을 관리할 때와는 다른 구성, 도구 및 조직 내 경험 지식이 필요합니다.

컨테이너가 애플리케이션 배포의 상당 부분을 표준화했지만, 컨테이너 하위 영역(또는 컨테이너로 들어오고 나가는 영역)은 여전히 제각각입니다. 사실상의 컨테이너 오케스트레이션 플랫폼인 Kubernetes가 이 과정을 정리해 줄 것으로 기대됐습니다. 하지만 Amazon EKS, Azure Kubernetes Service(AKS), Google Kubernetes Engine(GKE)에 배포해 본 사람이라면 누구나 이들이 전혀 비슷하지 않다는 사실을 알고 있습니다.

여러분은 이처럼 매우 다양한 환경에서 NGINX 제품을 관리하려면 상당한 운영 리소스가 필요하고 낭비가 발생한다고 말씀해 주셨습니다. 솔직히 말해, 서버리스 환경에서 앱을 출시하고 Kubernetes 환경에서 확장하며 개발 목적으로 클라우드에서 소규모 내부 배포를 계속 운영할 수 있는 동적 환경에서는 연간 라이선스 기반의 가격 책정 모델이 제대로 작동하지 않습니다.

문제점 #2: 다양한 환경에서 실행되고 여러 라이선스 유형에 걸친 앱은 보안 유지가 어렵습니다

다양한 환경의 복잡성으로 인해 최신 앱이 어디에 배포되어 있는지 파악하고 모니터링한 다음 적절한 보안 조치를 적용하기가 어려울 수 있습니다. 예를 들어 NGINX Plus를 글로벌 로드 밸런서로 배포하고, 다양한 마이크로서비스에는 NGINX Open Source를 배포했으며, 각각 서로 다른 클라우드나 서로 다른 유형의 애플리케이션에서 실행되고 있을 수 있습니다. 또한 개인정보 보호, 데이터 보호 및 트래픽 관리에 대한 요구 사항도 각각 다를 수 있습니다.
이러한 조합이 하나씩 늘어날 때마다 새로운 보안 문제가 발생합니다. 표준화된 종합 솔루션이 없기 때문에 운영이 복잡해지고 구성 오류가 발생할 가능성도 커집니다. 솔직히 말해, 어떤 유형의 보안을 어떤 NGINX 솔루션에 적용할 수 있는지 혼란스럽게 만든 탓에 저희도 이러한 복잡성을 가중했습니다.

저희도 잘 알고 있습니다. 고객에게는 NGINX를 활용하는 모든 애플리케이션을 보호할 수 있는 단일한 방법이 필요합니다. 이 통합 보안 솔루션은 대다수의 사용 사례를 지원하고, 모든 클라우드, 온프레미스, 서버리스 및 기타 환경에서 동일한 도구, 대시보드, 운영 프로세스를 적용할 수 있어야 합니다. 또한 NGINX 커뮤니티의 집단 지성과 저희가 보유한 전례 없는 글로벌 트래픽 가시성을 활용하여 더욱 지능적인 보안 접근 방식으로 전환하는 것이 중요하다는 점도 잘 알고 있습니다.

문제점 #3: 최신 애플리케이션의 비용 관리는 복잡하며 낭비를 초래합니다

시프트 레프트 환경에서 모든 조직은 개발자와 실무자가 티켓을 제출하거나 Slack 메시지를 보내지 않고도 업무를 더 효율적으로 수행할 수 있도록 지원하고자 합니다. 하지만 현실은 달랐습니다. Kubernetes, 서버리스 및 분산 애플리케이션과 온프레미스, 클라우드, 멀티클라우드 환경에 걸친 애플리케이션을 관리하는 기타 메커니즘을 통해 복잡성이 어느 정도 추상화되기는 했습니다. 그러나 이러한 진전은 대부분 컨테이너와 애플리케이션 내부에 국한되었습니다. 네트워킹, 보안, 관측 가능성과 같은 애플리케이션 주변 계층이나 CI/CD에는 제대로 적용되지 못했습니다.

앞서 언급한 문제점들에서도 이러한 이슈를 암시했지만, 핵심은 이렇습니다. 복잡성은 많은 시간과 수고를 요구하고, 보안을 약화시키며, 복원력에도 큰 비용을 초래합니다. 갈수록 복잡해지는 시스템을 유지하는 일은 근본적으로 어렵고 많은 리소스가 필요합니다. 복잡한 가격 및 라이선스 체계는 여기에 또 하나의 골칫거리를 더합니다. NGINX는 사용자가 실수로 사용량을 초과했을 때 사후 정산을 빌미로 과도한 비용을 청구하는 회사가 아니었습니다.

하지만 SaaS, API, 마이크로서비스가 중심이 된 세상에서는 연 단위나 사용자 수 또는 사이트 라이선스 기준이 아니라 사용한 만큼 비용을 지불하기를 원합니다. 또한 전체 기술 인프라와 애플리케이션 포트폴리오에 걸쳐 모든 NGINX 제품 및 서비스에 적용되는, 사용량 기반의 이해하기 쉬운 요금제를 원합니다. 아울러 팀에서 사용하는 모든 오픈 소스 모듈에 대해 필요한 부분만 비용을 지불하면서 지원과 보안을 포함할 수 있는 방법도 원합니다.

이를 위해서는 NGINX가 제품을 패키징하고 가격을 책정하는 방식에 어느 정도 변화가 필요합니다. 궁극적인 해법은 다른 SaaS와 마찬가지로 단순하고 투명하며, 사용한 만큼만 비용을 지불하는 것이어야 합니다. 여러분의 목소리를 잘 알고 있습니다. 그리고 앞서 언급한 세 가지 문제를 모두 해결할 훌륭한 방안을 준비하고 있습니다.

App World 2024에서 함께하세요

이러한 흥미로운 업데이트에 대해 AppWorld 2024에서 소개할 예정이며, 향후 12개월 동안 장기 계획과 로드맵의 일환으로 솔루션의 각 기능을 순차적으로 출시할 예정입니다.

이 여정에 함께하시고 AppWorld에서 앞으로 펼쳐질 내용을 자세히 확인해 보세요. 얼리버드 요금은 1월 21일까지 적용됩니다. 자세한 내용은 AppWorld 2024 등록 페이지에서 확인해 주세요. 또한 2월 6일 저녁, 산호세 F5 사무실에서 NGINX 리더 및 커뮤니티 구성원들과 함께 NGINX의 미래를 내다보고, 교류를 나누며, 빠질 수 없는 피자와 기념품을 즐기는 자리에 여러분을 초대합니다! 등록 및 자세한 내용은 이벤트 페이지에서 확인하세요.

다음 달 산호세에서 뵙기를 바랍니다!


공유

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.