소프트웨어 로드 밸런싱으로 전환해야 하는 5가지 이유

이 게시물은 NGINX, Inc.의 Floyd Smith와 Faisal Memon의 웨비나 에서 발췌한 것입니다. 해당 주제에 관한 새로운 전자책을 다운로드 할 수 있습니다.

목차

0:00 소개

플로이드 스미스: 안녕하세요. 저희 프레젠테이션에 오신 것을 환영합니다. 저희는 NGINX에 있으며, 오늘은 제가 쓴 전자책 '부하 분산을 위한 소프트웨어로 전환해야 하는 5가지 이유' 에 대해 이야기해보겠습니다.

오늘 이 자리에는 두 분이 발표자로 참석하셨습니다. 저는 NGINX의 기술 마케팅 작가인 플로이드 스미스입니다. 저는 이전에 Apple의 수석 기술 작가였으며, 기술의 다양한 측면에 대한 여러 권의 책을 썼습니다.

파이살 메몬: 안녕하세요, 저는 Faisal Memon이고 NGINX에서 제품 마케팅을 담당하고 있습니다. 여기서 일한 지 1년 정도 되었습니다. NGINX에 오기 전에는 Riverbed와 Cisco에서 기술 마케팅 엔지니어로 일했습니다. 저는 C 언어로 개발을 하며 경력을 시작했습니다. Cisco에서 소프트웨어 엔지니어로 약 8년간 일했습니다.

1:38 당신은 누구입니까?

플로이드: 우리는 웨비나를 시작하기 전에 등록을 받고, 각자 제출한 직함, 조직, 참석 이유를 볼 수 있습니다.

참석하는 사람들의 직함을 보는 것은 정말 흥미로웠습니다. 우리는 솔루션 아키텍트를 보유하고 있습니다. 여러 종류의 아키텍트입니다. Linux 관리자, 엔지니어링 책임자, CEO, 수석 Agile Delivery 관리자, DevOps 직책을 맡은 사람, 풀 스택 소프트웨어 개발자, 엔지니어, 과학자, 개발자, 마케팅 운영 관리자.

우리 회사에는 기술적인 소양을 갖춘 다양한 인재가 있습니다. 제 생각에는 이 웨비나에 참여하는 사람들은 기술에 매우 직접적이고 오늘 여기서 이야기하는 문제에 직접 직면하게 될 것입니다.

우리는 또한 매우 다양하고 폭넓은 조직을 대표하고 있습니다. 여러분 중에는 고객이 현명한 결정을 내릴 수 있도록 안내하고자 이 문제를 살펴보는 사람도 있겠지만, 대부분은 회사 내에서 직접 문제를 처리하는 듯합니다.

3:53 하드웨어에서 소프트웨어로

재무 보고서에 따르면 하드웨어 ADC 시장은 감소하고 있으므로 하드웨어 ADC를 판매하는 사람들은 고객 기반이 감소하고 있음에도 불구하고 고객당 얻는 수익을 늘리려고 노력하고 있습니다. 많은 하드웨어 ADC 고객은 하드웨어 ADC 제공 서비스에 점점 더 많은 돈을 지불하는 점점 줄어드는 고객층에 속하고 싶지 않다는 사실을 깨닫기 시작했습니다. 그들은 소프트웨어에서도 실제로 동일한 작업을 더 잘 수행할 수 있고, 더 큰 유연성도 얻을 수 있다는 것을 깨닫기 시작했습니다. 직함에 DevOps라는 단어가 들어간 분들이라면 아마 제 말이 무슨 뜻인지 아실 겁니다.

NGINX에서 자주 보는 것은 사람들이 하드웨어 ADC에서 계약 갱신 날짜에 도달하거나 트래픽이 갑자기 증가하고 요금이 갑자기 오른 다음 계약을 해지하기 위해 정말 애쓰는 것입니다. 그러면 그들은 매우 빠르게 일을 처리해야 합니다. 그들은 보통 성공하지만, 스트레스가 많고, 계획되지 않았으며, 예산도 없습니다. 이 프레젠테이션의 도움으로 더욱 계획된 프로세스를 시작할 수 있습니다.

예산 문제는 그렇게 심각하지 않습니다. 소프트웨어로 전환하면 엄청난 비용을 절감할 수 있기 때문입니다. 그러나 운영상의 번거로움은 엄청납니다. 일찍 시작하면 이런 비용을 많이 줄일 수 있습니다.

NGINX는 하드웨어 ADC에 대한 정말 견고한 대안입니다. 원래는 C10K 문제를 해결하기 위해 만들어졌습니다. 즉, 한 대의 컴퓨터에서 한 대의 웹 서버가 10,000개 이상의 동시 연결을 처리합니다. NGINX가 나오기 전에는 불가능했습니다. 사람들이 웹사이트를 만들고, 인기를 얻으면 곧 무너지곤 했습니다. 이런 일이 일어나는 것을 막는 것은 매우 매우 매우 어려웠지만, NGINX를 사용하면 훨씬 쉬워졌습니다.

우리의 첫 번째 오픈 소스 릴리스는 2004년 러시아에서 이루어졌는데, NGINX [소프트웨어]가 처음 만들어진 곳입니다 .[편집자 - Floyd는 여기서 "설립"이라고 말했습니다. NGINX, Inc.는 2011년에 설립되었습니다.] 지원되는 상용 버전인 NGINX Plus는 2013년에 출시되었습니다.

NGINX 회사는 실리콘 밸리(샌프란시스코)에 본사가 있으며, 개발 사무실은 모스크바에 있습니다. 영국에도 사무실이 있습니다. 이 회사는 업계 리더들의 VC 지원을 받았습니다. 저희는 800명이 넘는 고객을 보유하고 있으며, 얼마 전 직원 수가 100명에 달했습니다.

6:33 세계에서 가장 바쁜 사이트를 위한 선도적인 웹 서버

NGINX에서 운영되는 총 사이트 수는 1억 6천만 개입니다.

이는 두 가지 모드로 사용됩니다. 일부 사이트는 NGINX를 웹 서버 로 실행하는데, 이것이 원래 목적이었습니다. 하지만 많은 사이트는 NGINX를 역방향 프록시 서버 로 실행합니다. NGINX를 현재 아키텍처 앞에 놓고, NGINX를 사용하여 트래픽을 처리하고 애플리케이션 서버로의 트래픽을 라우팅하는 방식입니다. 그렇게 하면 바로 로드 밸런싱을 수행하는 길에 들어서게 되는데, 오늘 우리가 이야기할 것이 바로 그것입니다.

가장 바쁜 상위 10,000개 웹사이트 중 51%가 NGINX로 이전했습니다. 그 이유는 무엇일까요? 왜 가장 바쁜 웹사이트에서는 전체 웹사이트보다 우리의 사용량이 더 많을까요?

그 이유는 NGINX가 정말 바쁜 웹사이트에 가장 적합한 솔루션이기 때문입니다. 문제가 있는 바쁜 웹사이트를 빠르게 저장하는 방법은 NGINX를 역방향 프록시 서버로 사용한 다음 그 위에 로드 밸런싱을 실행하는 것 입니다.

시간이 지남에 따라 기존 앱을 NGINX로 전환할 수 있으며, 새 앱을 개발하는 경우 해당 앱의 웹 서버로도 NGINX를 실행할 수 있습니다. 그리고 이렇게 해서 우리는 변덕스럽게 웹 서버를 바꾸지 않는 바쁜 사람들 사이에서 이런 사용이 가능해졌습니다. 그들은 다른 웹 서버를 사용한 경험이 있고 사용 방법도 알고 있지만, NGINX가 제공하는 모든 기능 때문에 이러한 변경을 단행했습니다.

Amazon Web Services의 모든 사이트 중 36%가 NGINX를 사용합니다. 일종의 표준 도구가 되어가고 있습니다. 요즘 사람들은 종종 NGINX로 시작해 프로젝트 전체에 걸쳐 계속 사용합니다.

저희를 사용하는 사이트 중 일부는 다음과 같습니다. 물론 NGINX를 사용하는 웹사이트가 1억 6천만 개나 되므로 한 슬라이드에 모두 담을 수는 없습니다. 하지만 저희의 파트너와 친구로는 Netflix, Airbnb, Uber, Amazon Web Services, 앞서 언급했듯이 Box, Pinterest, WordPress 등이 있습니다.

생계를 위해 웹 전송을 해야 하는 모든 회사는 NGINX로 전환했습니다.

8:48 NGINX가 적합한 곳

NGINX가 어디에 적합한지 살펴보겠습니다.

오른쪽에서는 NGINX가 웹 서버로 실행되는 것을 볼 수 있습니다. 웹 서버로서, 다양한 종류의 앱 서버가 함께 실행될 수 있도록 애플리케이션 게이트웨이를 사용합니다. 웹 서버로 NGINX를 사용하면 수행하는 작업에 따라 최대 10,000개의 동시 연결을 처리할 수 있습니다.

하지만 NGINX는 역방향 프록시 서버로도 유용하며, 이를 통해 캐싱, 부하 분산 및 기타 여러 기능을 얻을 수 있습니다.

9:32 현대 웹 아키텍처

NGINX는 또한 최신 웹 아키텍처로 전환하는 데 도움이 됩니다. 3계층 J2EE 스타일 아키텍처가 마이크로서비스로 전환되는 것이 될 수 있습니다. HTML과 SOAP의 복잡한 프로토콜이 마이크로서비스의 큰 부분인 REST와 메시징과 같은 더 가벼운 프로토콜로 전환될 수도 있습니다. 또는 컨테이너나 VM을 실행하는 변경 가능한 배포로 지속형 배포에서 전환할 수도 있습니다.

고정되고 정적인 인프라 대신, 일반적으로 사용자가 직접 소유한 서비스를 이용하게 됩니다. SDN과 NFV, 클라우드, 특히 클라우드와 같은 것이 있습니다. 몇 달마다 대규모 릴리스를 하는 대신, 몇 시간마다 지속적으로 배포합니다. 개발 그룹, 테스트 그룹, 운영 그룹이 각자의 관리자를 통해 작업하는 분리된 팀 대신, 모든 사람이 소매를 걷어붙이고 모든 문제의 측면을 처리하는 공동 책임의 DevOps 문화가 있습니다.

10:42 DevOps는 NGINX와 잘 어울립니다.

DevOps 방법론, 클라우드 배포 및 자동화된 서비스 검색” size-full wp-image-46723″ style="border:2px solid #666666; padding:2px; margin:2px;” />

DevOps 스토리는 NGINX와 밀접하게 얽혀 있습니다. 많은 DevOps 담당자가 NGINX를 주머니에 넣고 다니며 문제가 있는 배포에 직면하면 NGINX를 가져옵니다.

어떤 배포 환경에서는 앱 설정을 전혀 변경할 필요가 없는 경우도 있습니다. NGINX를 앞에 놓으면 앱 서버로의 트래픽을 앱 서버가 처리할 수 있는 수준으로 가져올 수 있습니다. 여러분은 그 코드를 변경하지 않았고, 성능 문제를 해결하기 위해 서두르다가 핵심 기능을 위험에 빠뜨리지도 않았습니다.

DevOps와 NGINX가 함께 잘 작동하는 것 중 하나는 소프트웨어 부하 분산입니다. 이에 대해서는 나중에 설명하겠습니다. 클라우드 배포에는 아주 잘 맞지만, 자체 서버에서도 잘 작동합니다. 다양한 부하 분산 방법을 제공합니다. 여기서 NGINX와 NGINX Plus의 차이점이 있는데, 잠시 후에 설명하겠습니다.

NGINX의 즉석 재구성 기능은 서비스 검색 및 가동 시간을 지원합니다. 서비스 검색은 마이크로서비스와 자동화에 필수적이며, 즉석 재구성을 통해 서비스를 구성하기 위해 사람들을 서버에서 내보낼 필요가 없으므로 고객을 온라인 상태로 유지하는 데 큰 이점이 있습니다.

애플리케이션 상태 검사는 애플리케이션 전송 문제에 대한 조기 경고를 제공하므로 문제가 있는 서버가 갑자기 멈추거나 사람들이 어리둥절해하는 상황을 방지하기 위해 서버를 우아하게 종료할 수 있습니다. 그리고 강력하고 사용자 정의 가능한 모니터링도 있습니다. 다시 말해, 이는 문제가 발생하는 즉시 이를 알려서 고객에게 영향을 미치기 전에 문제를 해결할 수 있도록 하는 것입니다.

12:30 NGINX Plus 기능

NGINX Plus에는 무엇이 들어있나요?

따라서 오픈소스 NGINX가 원래 제품이고 NGINX Plus는 그 위에 올라선 상용 제품입니다. NGINX에서는 최소 70%의 시간을 오픈 소스 측면에 투자하고 있습니다. 하지만 이는 NGINX Plus의 고급 기능을 위한 기반이기도 합니다.

오픈소스 제품에는 웹서버의 핵심 기능인 요청 라우팅이 포함되어 있습니다. 압축은 웹서버의 부하를 최소화하고, 네트워크를 통한 트래픽을 최소화하여 매우 가치 있는 기능을 제공합니다. 보안을 위해 SSL을 지원합니다. 또한 내장된 스크립팅 언어가 두 개 있습니다. 하나는 우리의 NGINX JavaScript 모듈[이전에는 nginScript라고 불림]이고, 다른 하나는 Lua입니다.

NGINX의 일부 기능은 오픈 소스이지만 NGINX Plus에서 향상되었습니다. 오픈 소스 NGINX를 사용해도 부하 분산을 꽤 잘 수행할 수 있지만, NGINX Plus를 사용하면 몇 가지 고급 기능을 사용할 수 있습니다. 마찬가지로, 오픈소스 NGINX를 에지 캐시와 미디어 스트리밍으로 사용할 수 있으며, 이는 NGINX Plus에서 더욱 효과적으로 작동합니다.

NGINX Plus에도 여러 가지 고유한 기능이 있습니다. 애플리케이션 상태 모니터링, 모니터링, 모니터링 및 분석을 위한 GUI 시각화, RESTful 구성 API, 그리고 몇 가지 고급 로드 밸런싱 기술이 있습니다.

NGINX Plus를 사용하면 작업을 수행할 때 지원을 제공하는 NGINX 엔지니어에게 액세스할 수 있습니다. 현재 F5, Citrix 또는 이와 유사한 시스템을 사용하고 있다면 이러한 종류의 지원에 익숙할 것입니다. 규모가 크고 바쁜 웹사이트의 경우 조금만 가동이 중단되어도 많은 비용이 발생하므로 이는 매우 중요할 수 있습니다. 일년에 한 번만이라도 짧은 가동 중단을 피한다면 비용을 충분히 회수할 수 있습니다.

14:41 고객 사례 연구 – WordPress.com

전환한 고객의 사례 연구를 살펴보겠습니다.

WordPress.com은 F5의 BIG-IP를 사용 중이었고, 서버당 초당 10,000개 이상의 요청에 대한 부하 분산이 필요했기 때문에 NGINX에서는 이를 사용하지 않기로 했습니다. 이것이 바로 우리가 이야기했던 C10k 문제이며 NGINX는 10년 이상 이 문제를 해결해 왔습니다. 당시에는 서버당 초당 요청이 1,000개로 제한되었습니다. 10,000명 이상과 비교했을 때 그것이 얼마나 부담스러운지 상상할 수 있을 것입니다.

Wordpress.com은 여러 개의 F5 BIG‑IP 시스템을 보유하고 있었으며, 이는 10개의 데이터 센터로 확장될 예정이었습니다. 높은 가용성을 지원하고 기본적으로 모든 데이터 센터에 대한 라이브 백업을 갖추기 위해 그들은 10쌍의 BIG‑IP 서버를 고려했습니다. 매우 비싼 편. 또한, 구성을 변경할 때 사용자를 부팅하지 않도록 즉석 재구성이 필요했습니다.

그들은 Gravatar에서 테스트를 시작하여 NGINX로의 전환을 시작했습니다. Gravatar는 사용자의 아바타를 보여주는 앱입니다. 그로 인해 그들은 NGINX에 익숙해졌습니다. 그런 다음, 그들은 F5 서버에서 NGINX로 이동했고, 그로 인해 작고 예측 가능한 메모리 공간과 작고 예측 가능한 CPU 공간을 확보했습니다.

이제 그들은 36개의 NGINX 서버에서 초당 70,000개 이상의 요청과 초당 15기가비트[Gbps]를 처리합니다. 서버당 초당 최대 20,000개의 요청을 처리할 수 있습니다. 그리고 즉시 재구성하고 업데이트할 수도 있습니다.

견적을 보면 작은 구현과 NGINX를 사용하면 상당한 금액을 절약할 수 있는 비용 차이에 대해서만 이야기하고 있습니다. 하지만 서버 10개 쌍으로 가면 엄청난 차이가 납니다.

16:42 고객 사례 연구 – Montana Interactive

Montana Interactive는 고가용성 부하 분산을 위해 NGINX Plus를 선택했습니다. 실제로 많은 정부 서비스는 온라인으로 제공하는 것이 더 쉽고, 저렴하고, 더 좋습니다. 자동차 검사소나 비슷한 곳에 예약을 해두셨다면 제 말이 무슨 뜻인지 아실 겁니다. 이러한 웹사이트는 투표, 세금 납부 등에 대한 지원을 제공할 수 있습니다.

이런 필수적인 정부 서비스는 엄청나게 많은데, 몬태나주는 매우 큰 주이고 인구도 비교적 적어 곳곳에 흩어져 살고 있습니다. 따라서 주민들이 정부 사무실에 출근하기 위해 6~8시간을 운전하는 것보다는 서비스를 온라인으로 이용할 수 있는 것이 매우 중요합니다.

몬태나는 처음에는 온라인 서비스로 적극적으로 전환했지만, 성장하면서 세션 중단이 발생하기 시작했습니다. 세금을 위한 대규모 결제 앱으로 인해 분기별 거래 트래픽이 크게 급증했습니다. 방대한 양식을 작성하는 도중에 갑자기 누군가가 떨어져서 모든 작성 내용이 사라지는 일이 있었습니다. 세금 신고나 다른 복잡한 절차를 밟고 있다면, 꽤나 스트레스가 많은 일입니다.

그들에게 주어진 솔루션은 파운드를 실행하는 서버에서 NGINX Plus로 업그레이드하고, NGINX Plus를 다른 하이퍼바이저와 데이터 센터에 배치하고, 동적 역방향 프록시로 작동하고, 요청을 실시간으로 라우팅하여 트래픽 관리를 개선하는 것이었습니다. NGINX Plus로 전환한 결과, 속도, 유연성, 사용 편의성 면에서 엄청난 개선을 경험했습니다. 그들은 즉석 재구성의 이점을 얻었고 SSL 처리를 NGINX 서버로 오프로드했으며 역할 기반 관리를 사용하여 운영과 보안을 개선했습니다.

Montana Interactive의 James Ridle은 NGINX의 힘에 놀랐습니다. 벤치마크는 그를 놀라게 했고 그는 NGINX로 동일한 서버에서 처리할 수 있는 것의 차이를 거의 믿을 수 없었습니다.

18:43 고객 사례 연구 – BuyDig.com

이는 고객에게 막대한 이점을 제공하는 또 다른 사례 연구입니다. BuyDig.com은 NGINX를 사용하여 확장성과 보안을 갖춘 전자상거래 사이트입니다.

BuyDig.com은 오래된 .NET 앱을 사용했습니다. 그들은 그것을 바꾸고 싶어하지 않았고, 바꿀 필요도 없었습니다. 대규모 DDoS 공격을 받은 후, 그들은 더 나은 성능, 보안 및 확장성을 갖춘 빠르고, 내결함성이 뛰어나며, 구성하기 쉬운 프런트엔드가 필요하다는 것을 깨달았습니다.

그들은 Amazon Web Services에 호스팅된 프런트엔드 애플리케이션 계층에 NGINX Plus를 넣었습니다. 그들은 .NET에서 실행되는 백엔드 서비스에 아무런 변경도 하지 않았습니다. 그리고 그것은 너무 큽니다. 변화가 없습니다. 작은 변화도 없고, 사소한 번거로움도 없고, 사소한 위험도 없습니다. 하지만 아무것도 없습니다.

이제 그들은 놀라운 성능과 보안을 얻게 되었습니다. 그들은 NGINX를 사용자 정의하기 위해 구성 언어를 사용했습니다. 그들은 보안을 유지하기 위해 TLS SNI와 사용자 정의 로그를 사용합니다. 그들은 단 한 번의 속도 저하나 사이트 다운타임도 경험하지 못했으며 성능에 매우 만족하고 있습니다.

그럼, NGINX Plus가 할 수 있는 일의 몇 가지 예를 들어보겠습니다.

20:10 전자책 – 부하 분산을 위한 소프트웨어로 전환해야 하는 5가지 이유

이제 전자책으로 들어가보겠습니다. 저는 전자책의 내용을 간략하게 요약해 드리고, 그다음 Faisal이 전환의 두 가지 이유를 설명할 것입니다. 두 이유는 더 기술적이고, 저는 그 다음에 계속 설명하겠습니다. 링크가 있습니다. 완료된 후 이 프레젠테이션과 웨비나 녹화본을 제공해 드리겠습니다. 이메일이 발송되려면 약 하루 정도 걸릴 것 같아요.

여기 링크를 클릭하면 무료 전자책을 다운로드할 수 있는 페이지로 이동합니다. 그럼, 미리 그 이유를 말씀드리자면, 비용을 절감하기 위해서, DevOps에 적합성을 개선하기 위해서, 어디에든 배포하기 위해서(자체 온프레미스 서버, 클라우드, 프라이빗 클라우드, 원하는 모든 곳), 빠르게 적응할 수 있기 위해서, 그리고 나중에 자세히 설명드릴 이상한 계약적 제약이 없기 위해서입니다. 하지만 이제는 비용 절감에 대해 파이살에게 이야기해 보도록 하겠습니다.

21:22 이유 #1 – 비용을 획기적으로 절감

파이살: 고맙네요, 플로이드. 5가지 이유 중 첫 번째 이유는 소프트웨어 애플리케이션 제공을 위해 NGINX Plus로 전환하면 비용을 대폭 절감할 수 있다는 것입니다.

90년대 중반을 돌이켜보면, 웹사이트를 확장하는 유일한 방법은 더 큰 서버를 구매하는 것이었는데, 이는 엄청나게 비용이 많이 들었을 뿐만 아니라 신뢰할 수도 없었습니다. 그 단일 서버가 단일 장애점이었기 때문입니다.

F5가 처음으로 BIG-IP를 출시한 것도 이 무렵이었고, 이는 웹사이트 소유자에게 다른 아키텍처를 제공했습니다. 더 큰 서버를 구매하는 대신 BIG-IP를 사용하여 저렴한 서버를 여러 대 로드 밸런싱할 수 있었습니다. 따라서 비용이 절감됩니다. 거대한 서버 하나를 구매하는 것보다 BIG-IP와 저렴한 서버를 구매하는 것이 더 저렴하기 때문입니다. 또한 단일 장애 지점을 제거했기 때문에 어느 정도 중복성도 확보할 수 있습니다.

이것은 훌륭한 건축물이었고 혁신적이었고 당시로서는 유일한 게임이었습니다. 하지만 지난 20년 동안 많은 것이 바뀌었습니다. 가장 큰 변화 중 하나는 서버 비용이 엄청나게 떨어졌다는 것입니다. 요즘에는 샌프란시스코 만 지역에서 한 달 임대료보다 적은 비용으로 상당히 견고한 서버를 구입할 수 있습니다.

두 번째 주요 변경 사항은 F5 BIG‑IP 또는 Citrix NetScaler에서 제공하는 것과 동일한 기능을 제공하는 NGINX와 같은 오픈 소스 소프트웨어가 존재한다는 것입니다. 오픈소스의 경우, 값비싼 대형 가전제품과 비슷한 기능을 무료로 얻을 수 있습니다. Floyd는 이전에 NGINX를 사용하는 웹사이트가 1억 6천만 개가 넘는다고 지적했습니다. 그리고 상위 10,000개 사이트를 살펴보면 그 중 절반 이상이 NGINX에서 실행되고 있습니다.

따라서 이제 우리는 F5와 비교했을 때 필요한 모든 기능을 갖추고 있을 뿐만 아니라 다른 상업용 제품만큼 확장성과 안정성이 뛰어난 오픈 소스 소프트웨어를 보유하게 되었습니다.

23:19 NGINX Plus 대. F5 BIG‑IP

저는 올해 초에 벤치마킹과 비용 분석을 했고 여기 그 중 일부가 발췌되어 있습니다. 이는 기성품 하드웨어에서 실행되는 NGINX Plus 소프트웨어를 비교한 것입니다. 이 경우 Dell에서 제공하며 [우리는] 이를 F5 BIG‑IP의 다양한 모델과 비교하고 있습니다.

이 특정 예는 엔트리 레벨 F5 BIG‑IP인 2000S입니다. 저는 이를 Dell 서버에서 두 가지 크기의 NGINX Plus와 비교했습니다. F5 BIG‑IP보다 성능이 약간 낮은 제품(하단에서 성능 측정 항목을 확인할 수 있음)과 성능이 거의 두 배에 가까운 제품(F5 BIG‑IP보다 성능이 약간 낮은 제품)이 있습니다.

오른쪽 열만 보면 NGINX Plus가 2000S의 성능을 두 배로 향상시켜 1년차에 하드웨어 비용과 1년간의 유지 관리 지원 비용을 포함하여 78%의 절감 효과를 얻고 있습니다. 그리고 그러한 비용 절감은 5년차까지 이어집니다. 5년이 지난 후에도 Dell 서버를 갖춘 NGINX Plus의 총 소유 비용은 F5보다 58% 더 저렴합니다.

24:37 NGINX Plus 대. 시트릭스 넷스케일러

Citrix NetScaler와 동일한 비용 비교를 수행했습니다. 여기에서는 엔트리 레벨 NetScaler인 MPX‑5550 Enterprise Edition을 비교해 보겠습니다.

Citrix에서는 캐싱 및 콘텐츠 압축과 같은 기본 기능을 원하는 경우 라이선스를 Enterprise Edition 라이선스로 업그레이드해야 하는 라이선스를 제공합니다. NGINX를 사용하면 오픈 소스와 NGINX Plus 모두에서 콘텐츠 캐싱 및 압축 기능이 추가 비용 없이 포함됩니다. 따라서 여기서 비교하는 것은 Citrix NetScaler의 Enterprise Edition입니다. 이 제품은 NGINX Plus에서 제공하는 기능과 더 나은 동등성을 제공하며 Citrix NetScaler를 NGINX Plus로 교체할 때 F5와 동일한 비용 절감 효과가 있기 때문입니다.

기대했던 모든 기능과 성능을 얻을 수 있지만 1년차에는 89% 더 저렴하게 지불하게 됩니다. 5년차까지도 하드웨어 비용(이 경우 상용 Dell 서버)과 NGINX Plus 소프트웨어 구독 비용 모두에서 75%를 절약할 수 있습니다.

하드웨어 공급업체가 자주 언급하는 중요한 지표 중 하나는 초당 SSL 거래, 즉 초당 생성할 수 있는 새로운 SSL 연결 수입니다. 이러한 플랫폼 내에서 해당 숫자는 일반적으로 하드웨어에 의해 가속화되므로 NetScaler와 F5 BIG‑IP는 SSL 트랜잭션을 가속화하기 위한 특수 하드웨어를 보유하고 있으며, 이로 인해 해당 플랫폼의 비용이 상승합니다.

우리가 보고 있는 것은 하드웨어 가속 없이 CPU의 처리 능력만 사용하는 소프트웨어 솔루션이라도 맞춤형 하드웨어를 따라갈 수 있다는 것입니다. 하드웨어 가속 솔루션에서 얻을 수 있는 성능과 함께 극적인 비용 절감 효과를 제공합니다.

NGINX Plus로 전환하면 많은 비용을 절약할 수 있다는 것이 이유 1입니다. 하지만 돈만이 문제가 아닙니다.

26:52 이유 #2 – DevOps에는 소프트웨어 애플리케이션 제공이 필요합니다.

소프트웨어 기반 솔루션을 사용하면 많은 유연성도 얻을 수 있습니다. 소프트웨어 기반 로드 밸런서로 전환하는 두 번째 이유는 DevOps로 전환하는 경우 애플리케이션 제공을 위한 소프트웨어가 실제로 필요하다는 것입니다.

F5와 NetScaler의 경우, 이러한 어플라이언스는 일반적으로 대규모 기업에서 집계 지점으로 배포됩니다. 그래서 관련 없는 트래픽이 많이 발생합니다. 동일한 F5 BIG‑IP는 네트워크 방화벽의 부하를 분산할 수도 있고, 회사 이메일 서버의 부하를 분산할 수도 있고, 여러 개의 백엔드 엔터프라이즈 애플리케이션의 부하를 분산할 수도 있으며, 프런트엔드 엔터프라이즈 애플리케이션의 부하를 분산할 수도 있습니다. 마이크로서비스 아키텍처에서 API의 로드 밸런싱이 될 수 있습니다. 그래서 많은 것들의 부하를 분산할 수 있습니다.

표면적으로 보면 이것은 매우 간단하기 때문에 좋은 아키텍처처럼 보입니다. 모든 것을 F5로 실행하기만 하면 됩니다. 오랫동안 이 방법이 효과적이었습니다. 특히 2000년대 초반에는 모든 것이 개인 데이터 센터에 관한 것이었고, 우리는 모든 애플리케이션과 기업이 의존하는 모든 것을 온프레미스 데이터 센터에서 실행했습니다. 하지만 지난 몇 년 동안 상황이 바뀌었고, 이제는 대부분의 일이 클라우드로 옮겨가고 있습니다.

클라우드라고 하면 Amazon 내에서 프런트엔드 웹 애플리케이션을 호스팅하는 것만을 말하는 것이 아니라 온프레미스 CRM 시스템 및 온프레미스 이메일 서버가 아닌 Salesforce 및 Office 365와 같은 것을 사용하는 것도 말합니다. 따라서 이 모든 일을 할 수 있는 장치를 갖는다는 것은 요즘 사람들이 실제로 사용하는 것에 비하면 과도할 수 있습니다.

이러한 통합으로 인해 발생하는 두 번째 문제는 이러한 기기가 매우 잘 잠겨 있다는 것입니다. F5 구성을 잘못하면 회사 네트워크 전체가 다운될 수 있기 때문에 변경하는 데 매우 주저하게 됩니다. 이메일 서버나 네트워크 방화벽의 부하를 분산하는 것이 될 수도 있습니다. 따라서 구성은 위험한 일이 되고 변경 사항은 매우 제한적이고 엄격하게 보호되어야 합니다.

일반적으로 이를 변경하고 싶은 사람은 IT 티켓을 제출해야 하는데, 이는 조직과 조직이 요청한 변경 사항에 두는 우선순위에 따라 몇 시간, 며칠 또는 몇 주가 걸릴 수 있습니다.

이렇게 엄격하게 통제된 하드웨어를 사용하면 DevOps로 전환하기가 정말 어렵습니다. DevOps를 수행하고 자동화를 향해 나아가면 지속적인 통합을 향해 나아가고 훨씬 더 자주 코드를 릴리스하는 쪽으로 나아가게 됩니다. 그리고 변경을 할 때마다 IT 티켓을 제출해야 한다면 그 이니셔티브는 방해를 받고 무산됩니다.

많은 조직에서 볼 수 있는 것은 애플리케이션을 담당하고 DevOps와 Agile 개발로 전환하고자 하는 사람들이 매번 티켓을 제출해야 하는 상황을 감당할 수 없다는 것입니다. 이는 DevOps와 Agile 이니셔티브에 방해가 되기 때문입니다. 그래서 그들은 때때로 오픈 소스 NGINX를 배포하고 F5 BIG‑IP가 그것을 가리키도록 하며, 해당 NGINX 인스턴스는 DevOps 또는 애플리케이션 팀에서 관리하여 번거로움 없이 자동화를 수행하고 변경할 수 있습니다. 그래서 그것은 일종의 기업 IT 정책을 우회하는 방법입니다. 그런 다음, 많은 고객이 NGINX Plus로 옮겨가서 지원과 함께 더욱 고급 기능을 사용하는 것을 보았습니다.

NGINX는 다양한 유연하고 다양한 배포 모델을 지원하며, 현재 F5를 그대로 유지할 수도 있습니다. NGINX Plus를 사용하면 프런트엔드 웹 애플리케이션과 API, 마이크로서비스의 로드 밸런싱 및 전송을 보완하고 오프로드할 수 있으며, F5를 그대로 유지하여 회사 이메일 서버의 네트워크 로드 밸런싱을 수행할 수 있습니다. 네트워크 서비스와 네트워크 부하 분산이 필요하지 않다면 F5를 NGINX Plus로 바꿔서 단일 솔루션을 얻을 수도 있습니다.

우리는 조직이 DevOps, 지속적인 배포, 자동화로 전환할 수 있도록 다양한 배포 모델을 지원합니다.

세 번째 이유는 플로이드 덕분입니다.

31:59 이유 #3 – 하나의 ADC로 어디에나 배포 가능

플로이드: 고맙습니다, 파이살.

NGINX를 사용하면 하나의 ADC 솔루션으로 어디에나 배포할 수 있습니다. '모든 곳'은 무슨 뜻인가요? 즉, 온프레미스 서버, 퍼블릭 클라우드, 프라이빗 클라우드 또는 하이브리드 클라우드가 모두 하나의 솔루션에서 작동한다는 의미입니다. 그리고 거기에는 실용적인 측면과 건축적인 측면이 있습니다.

우선, 사내 서버를 사용하고 클라우드를 사용하지 않는 경우, 우리가 말한 모든 내용이 강력히 적용됩니다. 더 나은 유연성과 더 많은 기능을 얻고 비용을 절감하기 위해 NGINX 및 NGINX Plus로 전환하는 많은 사람들이 바로 이러한 상황에 처해 있습니다. 즉, 사내 서버에 배포하고 있는 것입니다.

앞으로 클라우드를 사용하거나 사용할 것을 고려하고 있다면 NGINX와 하드웨어 ADC는 비교할 수 없습니다. 하드웨어 ADC를 Amazon의 데이터 센터로 옮길 수 없습니다. 하드웨어 ADC는 여기서 도움이 되지 않습니다.

하드웨어 ADC 개발자들은 일부 소프트웨어 기반 솔루션을 보유하고 있지만, 어떤 경우에는 개발에만 사용하도록 권장합니다. 하드웨어 ADC를 대체하는 것은 아닙니다. 단순성이나 "고장나지 않았으면 고치지 마라"는 측면에서 볼 수 있는 이점은 클라우드 로 이동하려고 할 때 무너집니다.

NGINX 및 NGINX Plus를 사용하면 애플리케이션 아키텍처가 전송 플랫폼과 독립적입니다. 일부 클라우드 제공업체는 API를 통해 연결할 수 있는 서비스를 점점 더 추가하기 시작했습니다. 개발하는 동안, 어떻게 해야 할지 걱정할 필요가 없기 때문에 정말 좋은 기능입니다. API를 사용하여 로드 밸런싱이나 캐싱 또는 기타 기능을 처리하기만 하면 됩니다. 하지만 확장하면 모든 거래에 대해 소액의 비용을 지불하게 됩니다.

글쎄요, 갑자기 수천, 수만, 수십만 건의 거래를 하게 되면 그 숫자가 쌓이기 시작합니다. 청구는 매우 혼란스럽고 예측하기 어렵습니다. 특히, 항상 변화하는 트래픽에 따라 청구되기 때문입니다.

NGINX 또는 NGINX Plus 기반 접근 방식을 사용하면 기본적으로 모든 플랫폼에서 동일한 작업을 수행하며 다른 클라우드 공급자나 내부로 이전하더라도 차이가 거의 없습니다.

실제로 일부 고객은 자사 내부 서버와 클라우드에서 로드 밸런싱을 수행하고 있습니다. 그럼, 어떤 모습일까요? 그들은 80~90%의 시간 동안 그들의 필요를 충족시킬 만큼 충분한 사내 서버를 확보합니다. 그러면 확장해야 할 때 새로운 서버를 구매하거나 플러그인할 필요 없이 클라우드로 확장하면 됩니다.

클라우드는 일반적으로 온프레미스 서버보다 느리며 모든 것이 부하 분산되므로 사내 서버만 사용하는 경우 삭제될 세션만 클라우드로 전송됩니다. 대기 시간이 약간 더 길지만 처리되고 대기열에 추가되거나 삭제되지 않습니다.

재정적으로는 갑작스러운 트래픽 급증과 같은 비상 상황에서만 클라우드 비용을 지불하기 때문에 좋습니다. 이런 일은 뉴스 보도, 제품에 대한 좋은 평가, 지속적으로 사업 계획을 초과 달성하고 있지만 아직 내부적으로 규모를 확장하지 못했거나, 휴일이라 몇 주 동안만 필요한 서버를 두 배로 늘릴 가치가 없을 때 발생할 수 있습니다. 클라우드로 확장하면 가능합니다. NGINX를 사용하면 이 모든 작업을 유연하게, 심지어 자동으로 수행할 수 있습니다.

35:42 이유 #4 – 변화하는 요구 사항에 빠르게 적응하세요

NGINX를 사용하면 애플리케이션의 변화하는 요구 사항에 맞게 신속하게 적응할 수 있습니다. 고가용성을 위해 서버를 빠르게 추가하거나 서버 쌍을 추가해야 하는 경우 하드웨어를 주문하고, 배송받고, 받고, 테스트하고, iRules를 실행하거나 필요한 소프트웨어 구성을 수행하는 것을 기다릴 수 없습니다. iRules는 또한 독점적입니다. 즉, F5 서버가 있는 경우에만 iRules가 필요합니다. 대학을 졸업하고 나서 쉽게 채용할 수 있는 기술은 아닙니다. iRules 담당자가 떠나면 다른 담당자를 찾는 데 어려움을 겪게 됩니다.

구성 변경과 관련해서는 네트워크 운영자가 변경 사항을 승인할 때까지 기다릴 수 없는 경우가 많습니다. 실제로는 덜 시급한 일들과 함께 변경 사항을 대기열에 넣고 싶지 않을 것입니다.

NGINX를 사용하면 새로운 프로젝트 승인에 따른 오버헤드가 훨씬 줄어듭니다. NGINX와 NGINX Plus를 사용하면 비용이 2,000달러 또는 3,000달러인 서버에 대해 이야기할 때 추가 하드웨어를 보관할 수 있습니다. 하드웨어 ADC에 수만 달러가 들 때 이런 일을 할 수는 없습니다.

그런 종류의 유연성, 중복성, 필요한 작업을 필요한 때에 수행할 수 있는 능력은 NGINX의 핵심 기능이며, 저희를 사용하는 사람들이 저희를 그렇게 사랑하는 이유 중 하나입니다.

37:08 이유 #5 – 인공적인 성능 제약 없음

마지막으로, NGINX를 사용하면 성능에 인위적 또는 접촉 기반 제약이 없습니다. NetScaler Enterprise Edition의 경우 해당 서버의 처리량에 대한 계약 제한은 0.5Gbps입니다. 글쎄요, 기업 상황에서는 터무니없는 일이죠. 업계 표준 하드웨어에서 실행되는 비슷한 NGINX 설정은 20Gbps를 지원합니다. 이는 Citrix 한도의 40배입니다.

또 다른 점은 Citrix 번호가 계약상의 제약이라는 것입니다. 이를 초과하면 지불 조건이 갑자기 엄청나게 늘어납니다. 20Gbps는 우리의 권장사항입니다. 즉, 해당 영역에 들어가면 성능이 약간 떨어지는 것을 느낄 수 있고, 다른 서버를 가져와서 부하를 분산하는 것이 좋을 수도 있습니다. 하지만 당신에게는 유연성이 있습니다. 당신이 결정하세요. 예산이 갑자기 줄어들지 않습니다.

Citrix를 사용하는 건 마치 정지 신호에 부딪힌 것과 같습니다. 그런 시나리오에선, 사업이 더 늘어나는 건 나쁜 소식이 될 수 있다. 고객이 한 명 더 늘어나면 엄청난 돈이 들고, 고객이 몇 명 더 늘어나면 한도를 넘기 때문에 엄청난 돈이 들 수 있습니다. NGINX를 사용하면 비즈니스가 늘어나는 것은 좋은 소식이며, 고객 기반의 증가로 인해 수익이 늘어나 비용이 꾸준히 증가합니다.

우리는 종종 이러한 상한선을 초과한 사람들로부터 긴급 전화를 받고 갑자기 예산을 초과하게 됩니다. 그리고 그들은 큰 변화 없이는 예산을 회수할 수 없을 것입니다. 그러면 그들은 NGINX에 올라가서 좋은 상황을 되찾기 위해 급히 노력해야 합니다. 그러면 NGINX에서 엄청난 비용을 절감했기 때문에 실제로는 예산 이하로 끝나는 경우가 많습니다.

하지만 그런 두통이 필요한 사람은 누구인가? 그리고 예산과 성과가 갑자기 충돌하면 불확실성과 공포감을 느끼게 마련이죠. 일찍 NGINX로 전환하면 이런 문제에서 완전히 자유로울 수 있습니다.

40:00 리소스

• 사례 연구 – WordPress.com/Automattic의 NGINX
• 사례 연구 – Montana Interactive, NGINX Plus로 앱 성능 및 고객 서비스 개선
• 사례 연구 – Buydig.com이 코드 한 줄도 변경하지 않고 Microsoft .NET 앱을 확장하고 보안하는 방법
• 전자책 – 부하 분산을 위한 소프트웨어로 전환해야 하는 5가지 이유
• 블로그 – NGINX Plus 대. F5 BIG‑IP: 가격 대비 성능 비교
• 블로그 – NGINX Plus 대. 시트릭스 넷스케일러: 가격 대비 성능 비교
• NGINX Plus 무료 체험판