소프트웨어 로드 밸런서 가 더 나은 이유

NGINX 의 SEO였 Gus Robertson은 소프트웨어 로드 밸런서가 DevOps 도구에서 중요한 구성 요소임을 설명했는데, 다만 그것이 올바른 종류의 로드 밸런서 경우에만 해당한다고 합니다. 하드웨어 기반 로드 밸런서는 사실 민첩한 개발에 방해가 되는 장애물입니다. 소프트웨어 접근 방식이 필수적이라고 합니다.

InformationWeek와 Interop ITX의 조사 결과에 따르면, 조직의 50%가 이미 DevOps 방법론을 구현하거나 곧 구현할 계획이 있다고 합니다. 그러나 DevOps 방법론은 빠른 확장과 높은 기능 속도를 신속하게 달성하기 위해 필요한 민첩성과 유연성을 제공하는 솔루션을 요구합니다.

그러나 모든 소프트웨어 로드 밸런서가 동일하게 생성되는 것은 아닙니다. 대체로 두 가지 종류가 있습니다.

• 가상 머신(VM)에서 실행되는 소프트웨어 어플라이언스. (예: F5의 BIG-IP Virtual Edition 또는 Citrix의 ADC 가상 어플라이언스)입니다. 이러한 제품은 일반적으로 바이너리가 아니라 본격적인 VM 또는 헤비급 클라우드 이미지로 패키징됩니다.
• 진정한 소프트웨어 기반 로드 밸런서로는 NGINX Open Source와 NGINX Plus가 있습니다. 이러한 로드 밸런서 는 처음부터 소프트웨어로 구축되며 다른 소프트웨어 애플리케이션과 마찬가지로 베어메탈, VM 컨테이너, 클라우드 등 기술 사양을 충족하는 모든 환경에 설치할 수 있는 바이너리입니다.

대부분의 소프트웨어 어플라이언스는 통합된 하드웨어 디바이스로 시작되었으며, 고유한 (단일 목적, 폐쇄된) 하드웨어, 운영체제 및 사용자 인터페이스를 가지고 있었습니다. 공급 업체들이 로드 밸런서 의 소프트웨어 버전을 생성할 때, 운영체제와 소프트웨어를 하이퍼바이저(또는 클라우드)에서 실행할 수 있는 표준화된 가상화된 하드웨어 인스턴스를 제공하는 방식으로 운영체제와 소프트웨어를 조정했습니다.

반면에 NGINX와 같은 소프트웨어 로드 밸런서는 휴대 가능하고 가벼운 애플리케이션으로, 다양한 범용 운영체제에서 실행할 수 있는 특징을 가지고 있습니다.

목차

1. 소프트웨어 로드 밸런서가 더 나은 이유는 무엇입니까?
2. 요약

1. 소프트웨어 로드 밸런서, 더 나은 이유는 무엇입니까?

진정한 소프트웨어 로드 밸런서는 소프트웨어 어플라이언스보다 이점이 있습니까? NGINX는 그렇게 믿습니다. 이 두 가지 접근 방식이 다른 네 가지 차원을 살펴보겠습니다.

• 유연성 – 소프트웨어 어플라이언스 공급 업체들은 일반적으로 처리량과 기능에 인위적인 제한을 부과하여 더 나은 성능이나 고급 기능을 얻기 위해 추가 비용을 지불하도록 유도합니다. NGINX는 로드 밸런서, 웹 서버, 컨텐츠 캐시, 리버스 프록시, 마이크로서비스를 위한 Service Mesh 및 API Gateway로 동시에 사용될 수 있으며, 기반 하드웨어의 능력을 최대한 활용합니다. 예를 들어, NGINX를 로드 밸런서로 사용하고 있는데 갑자기 DDoS 공격을 경험한다면, 실제 사용자에게 특징적인 요청 속도로 요청속도(Rate Limit)를 제한하여 NGINX의 API Gateway 기능을 통해 이 공격을 완화할 수 있습니다.
  이 유연성은 고객들이 복잡성을 줄이고 비용을 절감할 수 있도록 해줍니다. 예를 들어, 대형 웹 사이트를 운영하는 선도적인 B2C 기업은 콘텐츠 전송 네트워크 (CDN), 네트워크 (Layer 4) 로드 밸런서, 애플리케이션 (Layer 7) 로드 밸런서, API Gateway, 웹 애플리케이션 방화벽 (WAF), 리버스 프록시, 웹 서버, 애플리케이션 서버 및 마이크로서비스 사이드카 프록시와 같은 서로 다른 13가지 솔루션을 사용하고 있었습니다. 그들은 NGINX 애플리케이션 플랫폼을 사용하여 이 13가지 솔루션을 3가지로 통합하는 계획을 가지고 있습니다.

• 원활한 통합 – 진정한 소프트웨어 로드 밸런서 는 다양한 유형의 애플리케이션의 요구 사항을 충족시키도록 설계되었습니다. 이들은 쉽게 애플리케이션 스택에 통합되며, 줄기 줄기로 배치할 수 있습니다. 레거시 애플리케이션 또는 마이크로서비스를 사용하는 현대 애플리케이션을 로드 밸런싱해야 하는 경우, 진정한 소프트웨어 로드 밸런서 는 애플리케이션 코드와 원활하게 상호작용하여 높은 성능과 신뢰성을 제공합니다.
  반면에 소프트웨어 어플라이언스는 엔드포인트로만 작동할 수 있습니다 – 애플리케이션 스택의 “전면 출입구” 역할을 합니다. 소프트웨어 어플라이언스는 대용량 크기와 VM으로 패키징되어 있기 때문에 클라우드, 컨테이너 및 마이크로서비스 기반의 현대적인 애플리케이션 환경에는 적합하지 않습니다. NGINX 및 NGINX Plus와 같은 진정한 소프트웨어 로드 밸런서는 네트워크 엣지에서의 리버스 프록시부터 마이크로서비스 환경에서 서비스 간 메쉬 트래픽을 처리하는 사이드카 프록시까지 인프라의 모든 계층에서 작동할 수 있습니다.

• 규정 준수 – 진정한 소프트웨어 로드 밸런서 는 IT팀에서 강화되고 승인한 Linux 운영체제 배포판에 배포할 수 있습니다. 소프트웨어 어플라이언스는 이미 자체 운영체제와 다른 시스템 소프트웨어로 구성되어 있기 때문에 IT 정책과의 준수를 유지하는 것이 더 어려울 수 있습니다.
  소프트웨어 어플라이언스는 본질적으로 블랙 박스입니다. 취약점이 발견될 경우 (최근 몇 년간 OpenSSL에서 발견된 많은 취약점과 같이), 패치를 통합하고 테스트하며 수정을 발행하는 어플라이언스 공급 업체에 의존해야 합니다. 심각한 취약점에 대해 몇 주 동안의 전환 기간이 필요한 사례와 관리 인터페이스에 10년 전 버전의 OpenSSL을 사용하는 어플라이언스에 관한 보고서를 들어봤습니다.

• 가볍움 – VM으로 패키지화된 소프트웨어 어플라이언스는 호스트 운영체제 위에 고유한 운영체제와 다른 시스템 소프트웨어 구성 요소를 포함하므로 큰 풋프린트를 가지고 있습니다(일반적으로 여러 GB입니다). 만약 베어 메탈 환경을 사용하거나 컨테이너화된 환경으로 전환하고 있다면 이는 분명 이상적이지 않습니다. 소프트웨어 어플라이언스는 가상화된 환경에도 이상적이지 않습니다 – 로드 밸런서 가 CPU나 메모리로 제약되지 않도록 하기 위해 소프트웨어 어플라이언스를 호스팅하는 VM에 대한 계산 자원이 과다하게 할당되어 비용이 상당히 많이 발생합니다.
  NGINX의 크기는 2MB 미만입니다. 지원되는 Linux 서버(베어 메탈, 클라우드 또는 가상)에서 실행하거나 Kubernetes 및 기타 플랫폼에서 직접 컨테이너 내에서 실행할 수 있습니다. NGINX를 실행하는 데 필요한 계산 자원은 환경의 요구 사항에 따라 제어할 수 있습니다.

소프트웨어 어플라이언스에 내장된 제한 사항은 기업 애플리케이션 배포 환경에서 사용되는 아키텍처의 작은 하위 집합만을 다루는 것을 의미합니다. 반면 진정한 소프트웨어 로드 밸런서 는 이러한 모든 아키텍처를 포괄합니다:

2. 요약

진정한 소프트웨어 로드 밸런서 는 가장 넓은 범위의 컴퓨팅 인프라와 다양한 종류의 애플리케이션에 적합합니다. 소프트웨어 어플라이언스는 레거시 애플리케이션을 지원하는 전통적인 IT 인프라 환경으로 제한됩니다. 인프라와 애플리케이션을 현대화할 때 진정한 소프트웨어 로드 밸런서 는 DevOps 목표를 달성하는 데 중요한 역할을 합니다. 동시에 이들은 기존의 레거시 컴퓨팅 인프라와 기존 애플리케이션의 전 범위에서 잘 작동하므로 실제로 아키텍처를 단순화하는 유일한 선택입니다.

소프트웨어 어플라이언스가 DevOps 목표를 달성하는 데 제한을 둔다고 생각하십니까? 어플라이언스를 보완하기 위해 진정한 소프트웨어 로드 밸런서 를 배포해야 한다고 생각하십니까? 아니면 진정한 소프트웨어 로드 밸런서 에 투자한 경험이 있으십니까? 댓글로 의견을 나누어 주시면 감사하겠습니다. 그 동안 아래에 NGINX Plus의 무료 30일 체험판을 사용하여 진정한 소프트웨어 기반 로드 밸런서의 장점을 누려보세요.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.