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

Floyd Smith콘텐츠 마케팅 디렉터

이 게시물은 NGINX, Inc.의 Floyd Smith와 Faisal Memon이 진행한 웨비나를 바탕으로 작성되었습니다. 이 주제에 관한 새로운 전자책을 다운로드하실 수 있습니다.

목차

0:00 소개

Floyd Smith: 안녕하세요. 저희 프레젠테이션에 오신 것을 환영합니다. 오늘은 NGINX에서 제 전자책인 로드 밸런싱에 소프트웨어를 사용해야 하는 5가지 이유에 대해 이야기해 보겠습니다.

오늘 발표는 두 사람이 함께 진행합니다. 저는 NGINX의 기술 마케팅 라이터인 플로이드 스미스입니다. 이전에는 Apple에서 선임 테크니컬 라이터로 근무했으며, 기술의 다양한 측면을 다룬 여러 권의 책을 집필했습니다.

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

1:38 자기소개를 부탁드립니다

Floyd: 웨비나를 진행하기 전에 참가 신청을 받는데, 여러분이 제출한 직책, 소속 기관, 참가 이유를 확인할 수 있습니다.

참석자들의 직함을 살펴보니 정말 흥미로웠습니다. 솔루션 아키텍트를 비롯해 여러 분야의 아키텍트가 있고, Linux 관리자, 엔지니어링 책임자, CEO, 시니어 애자일 딜리버리 매니저, DevOps 관련 직함을 가진 여러 분, 풀스택 소프트웨어 개발자, 엔지니어, 과학자, 개발자, 마케팅 운영 관리자도 있습니다.

기술적 성향을 지닌 다양한 분들이 참여하고 계십니다. 이번 웨비나에 참석하신 분들은 실제로 기술을 직접 다루는 실무자들이며, 오늘 여기서 논의하는 문제들을 현장에서 직접 마주하고 계실 것 같습니다.

또한 매우 다양하고 폭넓은 조직에서 참석해 주셨습니다. 고객이 현명한 결정을 내릴 수 있도록 안내하기 위해 이 내용을 살펴보는 분들도 계시겠지만, 대부분은 사내에서 이 문제를 직접 다루고 계신 것 같습니다.

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

재무 보고서에 따르면 하드웨어 ADC 시장은 축소되고 있습니다. 이에 따라 하드웨어 ADC 판매업체들은 고객 기반이 줄어드는 상황에서도 고객당 매출을 늘리려 하고 있습니다. 많은 하드웨어 ADC 고객은 하드웨어 ADC가 제공하는 서비스에 갈수록 더 많은 비용을 지불하는, 계속해서 줄어드는 고객 집단에 남고 싶지 않다는 사실을 깨닫기 시작했습니다. 이들은 소프트웨어로도 같은 작업을 더 잘 수행할 수 있을 뿐 아니라 유연성까지 높일 수 있다는 점을 알아가고 있습니다. 직함에 DevOps가 들어가는 분들이라면 아마 무슨 뜻인지 아실 겁니다.

NGINX에서 흔히 목격하는 상황은 고객이 하드웨어 ADC 계약 갱신일을 맞거나 트래픽이 갑자기 증가해 요금이 급등한 뒤에야 계약에서 벗어나려고 다급하게 움직이는 것입니다. 그러다 보니 모든 일을 매우 서둘러 처리해야 합니다. 대개는 성공하지만, 스트레스가 크고 계획에도 예산에도 없던 일입니다. 이 프레젠테이션을 활용하면 보다 체계적인 전환 절차를 시작할 수 있습니다.

소프트웨어로 전환하면 비용을 크게 절감할 수 있으므로 예산 문제는 그리 심각하지 않지만, 운영상의 번거로움은 상당합니다. 일찍 시작하기만 해도 이러한 번거로움을 크게 줄일 수 있습니다.

NGINX는 하드웨어 ADC를 대체할 수 있는 매우 안정적인 솔루션입니다. 원래 C10K 문제를 해결하기 위해 만들어졌습니다. C10K 문제란 한 대의 컴퓨터에서 실행되는 하나의 웹 서버가 10,000개 이상의 동시 연결을 처리하는 것을 말합니다. NGINX가 등장하기 전에는 불가능한 일이었습니다. 웹사이트를 개설한 뒤 인기를 얻으면 결국 서버가 다운되곤 했습니다. 이를 방지하는 것은 정말, 정말, 정말 어려웠지만 NGINX 덕분에 훨씬 쉬워졌습니다.

첫 오픈 소스 버전은 2004년 러시아에서 출시되었으며, 그곳에서 NGINX [소프트웨어]가 처음 개발되었습니다. [편집자 주 – 여기서 Floyd는 “설립되었다”고 표현했지만, NGINX, Inc.는 2011년에 설립됨]. 지원이 포함된 상용 버전인 NGINX Plus는 2013년에 출시되었습니다.

NGINX는 실리콘밸리(샌프란시스코)에 본사를 두고 있으며, 개발 사무소는 모스크바에 있습니다. 영국에도 사무소가 있습니다. 업계 선도 기업들로부터 벤처 투자를 받고 있습니다. 고객사는 800곳이 넘으며, 최근 직원 수가 100명에 도달했습니다.

6:33 세계에서 가장 트래픽이 많은 사이트들이 선택한 최고의 웹 서버

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

NGINX는 두 가지 방식으로 사용됩니다. 일부 사이트에서는 NGINX를 웹 서버로 사용하는데, 이는 NGINX의 원래 용도였습니다. 하지만 많은 사이트에서는 NGINX를 리버스 프록시 서버로 사용합니다. 즉, 현재 아키텍처 앞단에 NGINX를 배치하여 트래픽을 처리하고 애플리케이션 서버로 전달하는 방식입니다. 이렇게 사용하기 시작하면 자연스럽게 부하 분산으로 이어지며, 이것이 오늘 다룰 주제입니다.

트래픽이 가장 많은 상위 10,000개 웹사이트 중 51%가 NGINX로 전환했습니다. 그 이유는 무엇일까요? 전체 웹사이트에서보다 트래픽이 가장 많은 웹사이트에서 NGINX 사용률이 더 높은 이유는 무엇일까요?

그 이유는 NGINX가 트래픽이 매우 많은 웹사이트에 가장 적합한 솔루션이기 때문입니다. 문제가 발생한 트래픽이 많은 웹사이트를 빠르게 정상화하려면 NGINX를 리버스 프록시 서버로 도입한 다음, 그 위에서 로드 밸런싱을 실행하면 됩니다.

시간이 지나면서 기존 애플리케이션을 NGINX로 전환할 수도 있고, 새 애플리케이션을 개발한다면 해당 애플리케이션에서도 NGINX를 웹 서버로 사용할 수 있습니다. 웹 서버를 충동적으로 바꾸지 않는, 매우 바쁜 사용자들 사이에서 NGINX가 이처럼 널리 사용되게 된 것도 바로 이런 방식 덕분입니다. 이들은 다른 웹 서버를 사용해 본 경험이 있고 사용법도 잘 알고 있지만, NGINX가 제공하는 다양한 이점 때문에 전환을 선택합니다.

Amazon Web Services에서 운영되는 전체 사이트의 36%가 NGINX를 사용합니다. NGINX는 사실상 표준 도구로 자리 잡아 가고 있습니다. 이제는 많은 사람이 NGINX로 시작해 프로젝트가 끝날 때까지 계속 사용합니다.

다음은 NGINX를 사용하는 사이트 중 일부입니다. 물론 NGINX를 사용하는 웹사이트가 1억 6천만 개에 달하기 때문에 한 슬라이드에 모두 담을 수는 없지만, 파트너이자 고객인 곳으로는 Netflix, Airbnb, Uber, 앞서 말씀드린 Amazon Web Services, Box, Pinterest, WordPress 등이 있습니다.

웹 콘텐츠 전송을 주업으로 하며 안정적인 운영이 필수인 이 모든 기업은 NGINX로 전환했습니다.

8:48 NGINX가 적합한 영역

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는 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 또는 이와 유사한 시스템을 사용하고 있다면 이러한 지원 방식에 익숙할 것입니다. 아주 짧은 다운타임에도 큰 비용이 발생하는 규모가 크고 트래픽이 많은 웹사이트의 경우, 이러한 지원은 매우 중요할 수 있으며 1년에 단 한 번이라도 짧은 서비스 중단을 방지한다면 비용을 충분히 상쇄할 수 있습니다.

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곳으로 확장할 계획이었습니다. 고가용성을 지원하기 위해, 즉 각 데이터 센터마다 실시간 백업을 두기 위해 BIG‑IP 서버 10쌍을 도입하는 방안을 검토하고 있었습니다. 비용이 매우 많이 드는 방안이었습니다. 또한 구성을 변경할 때 사용자의 연결이 끊기지 않도록 즉시 재구성할 수 있는 기능도 필요했습니다.

먼저 사용자 아바타를 표시해 주는 앱인 Gravatar에서 NGINX를 테스트하며 전환을 시작했습니다. 이를 통해 NGINX에 익숙해진 후 F5 서버에서 NGINX로 전환했고, 그 결과 메모리와 CPU 사용량을 작고 예측 가능한 수준으로 유지할 수 있었습니다.

이제 이들은 36대의 NGINX 서버에서 초당 70,000건 이상의 요청과 초당 15기가비트[Gbps]의 트래픽을 처리합니다. 서버 한 대당 최대 초당 20,000건의 요청을 처리할 수 있으며, 운영 중에도 재구성하고 업데이트할 수 있습니다.

견적을 보면, 소규모로 구축할 때 NGINX를 사용하면 상당한 비용을 절감할 수 있다는 비용 차이에 대해 이야기하고 있을 뿐입니다. 하지만 서버를 10쌍으로 늘리면 그 차이는 그야말로 하늘과 땅 차이입니다.

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

Montana Interactive는 고가용성 부하 분산을 위해 NGINX Plus를 선택했습니다. 실제로 많은 정부 서비스를 온라인으로 제공하는 것이 더 쉽고 저렴하며 효율적입니다. 차량 등록 기관이나 이와 유사한 곳에 방문 예약을 해본 적이 있다면 무슨 뜻인지 아실 겁니다. 이러한 웹사이트에서는 투표, 세금 납부 등의 업무를 처리할 수 있습니다.

이러한 필수 정부 서비스는 매우 다양하며, 몬태나는 면적이 매우 넓은 데 비해 인구가 비교적 적고 주민들이 주 전역에 흩어져 있습니다. 따라서 주민들이 관공서에 가기 위해 6시간이나 8시간씩 운전해야 하는 것보다 온라인으로 서비스를 이용할 수 있도록 하는 것이 매우 중요합니다.

몬태나주는 처음에는 온라인 서비스로의 전환을 매우 활발하게 추진했지만, 서비스 규모가 커지면서 세션이 끊기는 문제가 발생하기 시작했습니다. 대규모 세금 납부 앱으로 인해 분기마다 거래 트래픽이 급증했습니다. 긴 양식을 작성하던 도중 갑자기 접속이 끊겨 지금까지 작성한 내용을 모두 잃는 경우도 있었습니다. 세금 신고처럼 복잡한 절차를 진행하던 중이라면 상당히 큰 스트레스를 받을 수밖에 없습니다.

이 문제를 해결하기 위해 Pound를 실행하던 서버를 NGINX Plus로 업그레이드하고, NGINX Plus를 여러 하이퍼바이저와 데이터 센터에 배치했으며, 실시간으로 요청을 라우팅하는 동적 리버스 프록시로 운영하여 트래픽을 더욱 효율적으로 관리했습니다. NGINX Plus로 전환한 결과 속도, 유연성, 사용 편의성이 크게 향상되었습니다. 또한 즉각적인 재구성 기능을 활용하고, SSL 처리를 NGINX 서버로 오프로드했으며, 역할 기반 관리를 통해 운영 효율성과 보안을 개선했습니다.

Montana Interactive의 James Ridle은 NGINX의 성능에 감탄했습니다. 벤치마크 결과는 놀라울 정도였으며, 동일한 서버에서 NGINX를 통해 처리할 수 있는 용량이 이토록 크게 달라진다는 사실을 거의 믿을 수 없었습니다.

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

또 다른 사례 연구에서는 NGINX를 통해 확장성과 보안성을 확보한 전자상거래 사이트 BuyDig.com이 고객으로서 얻은 막대한 이점을 소개합니다.

BuyDig.com은 오래된 .NET 앱을 사용하고 있었습니다. 이들은 앱을 변경하고 싶지 않았고, 그럴 필요도 없었습니다. 대규모 DDoS 공격을 겪은 후, 성능과 보안, 확장성이 뛰어나면서 빠르고 내결함성이 있으며 구성하기 쉬운 프런트엔드가 필요하다는 사실을 깨달았습니다.

Amazon Web Services에서 호스팅되는 프런트엔드 애플리케이션 계층에 NGINX Plus를 배치했습니다. .NET에서 실행되는 백엔드 서비스는 전혀 변경하지 않았습니다. 바로 이 점이 매우 중요합니다. 변경 사항이 적거나, 번거로움이 사소하거나, 위험이 미미한 정도가 아니라 아예 아무것도 없었습니다.

이제 이들은 탁월한 성능과 보안을 누리고 있습니다. NGINX의 구성 언어를 사용해 환경을 맞춤 설정했으며, TLS SNI와 사용자 지정 가능한 로그를 활용해 보안을 유지하고 있습니다. 지금까지 단 한 번도 속도 저하나 사이트 중단이 발생하지 않았으며, 성능에 매우 만족하고 있습니다.

이처럼 NGINX Plus로 구현할 수 있는 몇 가지 사례를 살펴보았습니다.

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

이제 전자책의 내용을 자세히 살펴보겠습니다. 먼저 전자책에 어떤 내용이 담겨 있는지 간략히 요약해 드린 다음, Faisal이 전환해야 하는 첫 번째와 두 번째 이유를 설명해 드릴 예정입니다. 이 두 가지는 좀 더 기술적인 내용이며, 그 이후부터는 제가 이어서 설명하겠습니다. 관련 링크도 있습니다. 발표가 끝나면 이 프레젠테이션 자료와 웨비나 녹화본을 받아보실 수 있습니다. 안내 이메일이 발송되기까지는 하루 정도 걸릴 것 같습니다.

그리고 여기 있는 링크를 클릭하면 이 무료 전자책을 다운로드할 수 있는 페이지로 이동합니다. 전환해야 하는 이유를 미리 간단히 말씀드리면 비용 절감, DevOps와의 적합성 향상, 어디서나 배포 가능(자체 온프레미스 서버, 클라우드, 프라이빗 클라우드 등 원하는 모든 환경), 신속한 적응 능력, 그리고 이상한 계약상 제약이 없다는 점입니다. 이에 대해서는 제가 조금 더 자세히 설명하겠습니다. 하지만 이제 비용 절감에 관해 설명해 줄 Faisal에게 마이크를 넘기겠습니다.

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

Faisal: 감사합니다, Floyd. 다섯 가지 이유 중 첫 번째는 소프트웨어 애플리케이션 제공을 위해 NGINX Plus로 전환하면 비용을 대폭 절감할 수 있다는 것입니다.

1990년대 중반을 돌이켜보면, 웹사이트를 확장할 수 있는 유일한 방법은 더 큰 서버를 구입하는 것이었습니다. 이는 엄청난 비용이 들었을 뿐만 아니라, 해당 서버 하나가 단일 장애점이 되기 때문에 안정성도 떨어졌습니다.

바로 이 무렵 F5가 처음으로 BIG‑IP를 출시했고, 이를 통해 웹사이트 운영자는 기존과 다른 아키텍처를 활용할 수 있게 되었습니다. 더 큰 서버를 구입하는 대신 BIG‑IP를 사용해 여러 대의 저렴한 서버에 부하를 분산할 수 있었습니다. BIG‑IP와 저렴한 서버들을 구입하는 편이 초대형 서버 한 대를 구입하는 것보다 비용이 적게 들기 때문에 비용을 절감할 수 있었고, 단일 장애 지점을 제거함으로써 어느 정도의 이중화도 확보할 수 있었습니다.

이는 훌륭한 아키텍처였습니다. 혁신적이었고 당시에는 사실상 유일한 선택지였죠. 하지만 지난 20년 동안 많은 것이 달라졌습니다. 가장 큰 변화 중 하나는 서버 비용이 크게 낮아졌다는 점입니다. 요즘에는 샌프란시스코 베이 에어리어의 한 달치 임대료보다 저렴한 가격으로도 상당히 고성능인 서버를 구입할 수 있습니다.

두 번째 주요 변화는 이제 NGINX와 같은 오픈 소스 소프트웨어가 등장해 F5 BIG‑IP나 Citrix NetScaler에서 제공하는 것과 동일한 기능을 제공한다는 점입니다. 오픈 소스를 사용하면 값비싼 대형 어플라이언스와 유사한 기능을 무료로 이용할 수 있습니다. 앞서 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보다 성능이 약간 낮고(아래쪽에서 성능 지표를 확인할 수 있습니다), 다른 하나는 성능이 거의 두 배에 달합니다.

NGINX Plus가 2000S보다 두 배 높은 성능을 제공하는 오른쪽 열만 살펴보면, 하드웨어 비용과 1년간의 유지보수 지원 비용을 포함해 1년 차에 78%를 절감할 수 있습니다. 이러한 비용 절감 효과는 5년 차까지 계속됩니다. 5년이 지난 후에도 Dell 서버와 NGINX Plus를 함께 사용할 때의 총소유비용은 F5보다 58% 저렴합니다.

24:37 NGINX Plus와 Citrix NetScaler 비교

Citrix NetScaler에 대해서도 동일한 비용 비교를 수행했습니다. 여기서는 엔트리급 NetScaler인 MPX‑5550 Enterprise Edition을 비교합니다.

Citrix의 라이선스 정책에서는 캐싱 및 콘텐츠 압축과 같은 기본 기능을 사용하려면 Enterprise Edition 라이선스로 업그레이드해야 합니다. NGINX의 경우 오픈 소스 버전과 NGINX Plus 모두 콘텐츠 캐싱 및 압축 기능을 추가 비용 없이 제공합니다. 따라서 여기서는 NGINX Plus에서 제공하는 기능과 더 유사한 Citrix NetScaler Enterprise Edition을 비교합니다. Citrix NetScaler를 NGINX Plus로 교체하면 F5의 경우와 동일한 수준의 비용 절감 효과를 얻을 수 있습니다.

기대하는 것과 동일한 기능과 성능을 모두 제공하면서도 1년 차 비용은 89% 더 저렴합니다. 5년 차까지 고려하더라도 하드웨어(이 경우 범용 Dell 서버) 비용과 NGINX Plus 소프트웨어 구독 비용을 합쳐 여전히 75%를 절감할 수 있습니다.

하드웨어 공급업체들이 자주 언급하는 핵심 지표 중 하나는 초당 SSL 트랜잭션 수, 즉 초당 새로 설정할 수 있는 SSL 연결 수입니다. 이러한 플랫폼에서는 일반적으로 하드웨어를 통해 이 수치를 높이므로, NetScaler와 F5 BIG‑IP에는 SSL 트랜잭션을 가속하는 전용 하드웨어가 탑재되어 있으며, 이로 인해 해당 플랫폼의 비용이 상승합니다.

현재 확인되는 바로는 하드웨어 가속 없이 CPU의 처리 능력만 사용하는 소프트웨어 솔루션으로도 맞춤형 하드웨어에 뒤처지지 않는 성능을 낼 수 있습니다. 하드웨어 가속 솔루션과 동일한 수준의 성능을 제공하면서도 비용을 획기적으로 절감할 수 있습니다.

따라서 이것이 첫 번째 이유입니다. NGINX Plus로 전환하면 많은 비용을 절감할 수 있습니다. 하지만 비용만이 전부는 아닙니다.

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

소프트웨어 기반 솔루션은 뛰어난 유연성도 제공합니다. 소프트웨어 기반 로드 밸런서로 전환해야 하는 두 번째 이유는 DevOps로 전환하려면 애플리케이션 딜리버리를 위한 소프트웨어가 반드시 필요하기 때문입니다.

F5와 NetScaler의 경우, 대기업에서는 일반적으로 이러한 어플라이언스를 트래픽 집선 지점으로 배포합니다. 따라서 서로 관련이 없는 다양한 트래픽이 이 장비를 통과합니다. 동일한 F5 BIG‑IP가 네트워크 방화벽, 기업 이메일 서버, 여러 백엔드 엔터프라이즈 애플리케이션뿐만 아니라 외부에 공개된 엔터프라이즈 애플리케이션의 부하도 분산할 수 있습니다. 또한 마이크로서비스 아키텍처의 API 부하를 분산할 수도 있습니다. 즉, 매우 다양한 대상의 부하를 분산할 수 있습니다.

표면적으로는 모든 것을 F5를 거치게 하기만 하면 되므로 상당히 단순하고 좋은 아키텍처처럼 보입니다. 실제로 이 방식은 오랫동안 잘 작동했습니다. 특히 프라이빗 데이터 센터가 중심이었던 2000년대 초반에는 모든 애플리케이션과 기업이 의존하는 모든 시스템을 온프레미스 데이터 센터에서 운영했습니다. 하지만 지난 몇 년 사이 상황이 달라졌고, 이제는 대부분이 클라우드로 이전되고 있습니다.

제가 클라우드라고 할 때는 단순히 Amazon에서 외부 공개용 웹 애플리케이션을 호스팅하는 것뿐만 아니라, 온프레미스 CRM 시스템과 온프레미스 이메일 서버 대신 Salesforce나 Office 365 같은 서비스를 사용하는 것도 포함합니다. 따라서 이 모든 기능을 수행할 수 있는 장비를 갖추는 것은 요즘 사람들이 실제로 운영하는 환경에 비해 과도할 수 있습니다.

이러한 통합으로 인해 발생하는 두 번째 문제는 해당 어플라이언스가 매우 엄격하게 통제된다는 점입니다. F5 구성을 잘못 건드리면 회사 네트워크 전체가 중단될 수 있기 때문에 변경을 주저하게 됩니다. 이 장비가 이메일 서버의 부하 분산이나 네트워크 방화벽 역할을 담당하고 있을 수도 있습니다. 따라서 구성 변경에는 위험이 따르며, 변경 권한과 절차를 매우 엄격하게 제한하고 통제해야 합니다.

이를 변경하려는 사람은 일반적으로 IT 티켓을 제출해야 하며, 요청된 변경 사항에 조직이 부여하는 우선순위와 조직의 상황에 따라 처리에 몇 시간, 며칠 또는 몇 주가 걸릴 수 있습니다.

이처럼 극도로 엄격하게 통제되는 하드웨어가 있으면 DevOps로 전환하기가 매우 어렵습니다. DevOps를 도입해 자동화와 지속적 통합을 추진하고 코드를 훨씬 더 자주 릴리스하려는 상황에서, 변경할 때마다 IT 티켓을 제출해야 한다면 이러한 이니셔티브는 제약을 받아 결국 무산되고 맙니다.

많은 조직에서 볼 수 있는 현상은, 애플리케이션을 담당하면서 DevOps와 애자일 개발로 전환하려는 사람들이 변경할 때마다 티켓을 제출해야 하는 방식을 감당하기 어렵다는 것입니다. 이러한 절차가 DevOps와 애자일 이니셔티브를 방해하기 때문입니다. 그래서 오픈 소스 NGINX를 배포하고 F5 BIG‑IP이 이를 가리키도록 구성하는 경우가 있습니다. 해당 NGINX 인스턴스는 DevOps 팀이나 애플리케이션 팀이 관리하므로 번거로운 절차 없이 자동화하고 변경할 수 있습니다. 이는 기업의 IT 정책을 어느 정도 우회하는 방법입니다. 물론 많은 고객이 이를 사용해 본 후에는 지원과 함께 더욱 고급 기능을 이용하기 위해 NGINX Plus로 전환하기 시작합니다.

NGINX는 현재 사용 중인 F5를 그대로 유지할 수 있는 모델을 비롯해 다양하고 유연한 배포 모델을 지원합니다. F5는 기업 이메일 서버의 네트워크 부하 분산에 계속 사용하면서, NGINX Plus를 통해 외부에 공개되는 웹 애플리케이션, API 및 마이크로서비스의 부하 분산과 전송을 보완하고 처리 부담을 줄일 수 있습니다. 네트워크 서비스와 네트워크 부하 분산이 필요하지 않다면 F5를 NGINX Plus로 교체하여 단일 솔루션으로 통합할 수도 있습니다.

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

세 번째 이유는 Floyd가 이어서 설명하겠습니다.

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%에 해당하는 수요를 감당할 수 있을 만큼의 사내 서버를 확보합니다. 이후 확장이 필요할 때는 새 서버를 구매하거나 연결할 필요 없이 클라우드로 확장하기만 하면 됩니다.

클라우드는 일반적으로 온프레미스 서버보다 느립니다. 하지만 모든 트래픽이 부하 분산되므로, 사내 서버만 사용했다면 처리되지 못했을 세션만 클라우드로 전송됩니다. 이러한 세션은 지연 시간이 약간 더 길지만 정상적으로 처리되며, 대기열에 들어가거나 유실되지 않습니다.

비용 측면에서도 매우 효율적입니다. 갑작스러운 트래픽 급증과 같은 비상 상황에서만 클라우드 비용을 지불하면 되기 때문입니다. 이러한 상황은 언론 보도나 제품에 대한 호평으로 발생할 수도 있고, 지속적으로 사업 계획상의 예상치를 초과하고 있지만 아직 이에 맞춰 사내 인프라를 확장하지 못한 경우에도 발생할 수 있습니다. 또는 연말연시처럼 1년에 몇 주밖에 필요하지 않은 서버를 두 배로 늘리는 것이 비효율적인 시기에도 클라우드로 확장하면 됩니다. NGINX를 사용하면 이 모든 작업을 유연하게, 심지어 자동으로 처리할 수 있습니다.

35:42 이유 #4 – 변화하는 수요에 신속하게 대응

NGINX를 사용하면 애플리케이션에 대한 변화하는 요구 사항에 신속하게 대응할 수 있습니다. 고가용성을 위해 서버나 서버 쌍을 빠르게 추가해야 할 때, 하드웨어를 주문하고 배송받아 인수 및 테스트한 후 iRules나 기타 필요한 소프트웨어 구성을 완료할 때까지 기다릴 수는 없습니다. 또한 iRules는 독점 기술로, F5 서버를 사용하는 경우에만 필요합니다. 대학을 갓 졸업한 인재 중에서 iRules 기술을 갖춘 사람을 쉽게 채용하기도 어렵습니다. iRules 담당자가 퇴사하면 대체 인력을 찾기가 매우 어려울 것입니다.

구성 변경의 경우 네트워크 운영팀의 승인을 기다릴 여유가 없는 경우가 많습니다. 긴급성이 떨어지는 작업들과 함께 변경 요청이 대기열에 들어가는 것은 원치 않을 것입니다.

NGINX를 사용하면 신규 프로젝트 승인에 드는 부담이 훨씬 줄어듭니다. NGINX와 NGINX Plus의 경우 서버 가격이 2,000달러나 3,000달러 수준이므로 여분의 하드웨어를 창고에 보관해 둘 수 있습니다. 하지만 수만 달러에 달하는 하드웨어 ADC의 경우에는 그렇게 할 수 없습니다.

이러한 유연성과 이중화, 그리고 필요할 때 필요한 작업을 수행할 수 있는 역량은 NGINX의 핵심 기능이며, 사용자들이 NGINX를 매우 선호하는 이유 중 하나입니다.

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

마지막으로 NGINX에는 인위적이거나 계약에 따른 성능 제약이 없습니다. NetScaler Enterprise Edition의 경우 해당 서버의 계약상 처리량 한도는 0.5 Gbps입니다. 엔터프라이즈 환경에서는 터무니없이 낮은 수준입니다. 업계 표준 하드웨어에서 실행되는 동급의 NGINX 구성은 20 Gbps를 지원합니다. 이는 Citrix 한도의 40배입니다.

또 한 가지는 Citrix의 수치가 계약상 제한이라는 점입니다. 이를 초과하면 지불 금액이 갑자기 큰 폭으로 늘어납니다. 20 Gbps는 당사가 권장하는 수치입니다. 따라서 이 수준에 이르면 성능이 조금 저하되는 것을 느끼기 시작할 수 있으며, 서버를 한 대 더 추가해 부하를 분산하는 것이 좋겠다고 판단할 수도 있습니다. 하지만 선택의 유연성은 여러분에게 있으며, 결정도 여러분이 내립니다. 예산이 갑자기 늘어나는 일은 없습니다.

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와 Citrix NetScaler 비교: 가격 대비 성능
• NGINX Plus 무료 체험

작성자 소개

Floyd Smith콘텐츠 마케팅 디렉터

Floyd Smith의 다른 블로그 게시물