NGINX Load Balancer 배포 시나리오
NGINX Plus가 여러 배포 시나리오에서 로드 밸런서로 사용되는 것을 점점 더 많이 보고 있으며 이 가이드에서는 가장 일반적인 몇 가지에 대해 설명합니다. 고객이 서로 다른 배포 시나리오를 사용하는 이유, 각 시나리오를 사용할 때 고려해야 할 사항, 그리고 가능한 마이그레이션 경로에 대해 논의합니다.
목차
1. 소개
2. 시나리오 1: NGINX Plus에서 모든 로드 밸런싱 수행
3. 시나리오 2: NGINX Plus는 레거시 하드웨어 기반 로드 밸런서와 병렬로 작동
4. 시나리오 3: NGINX Plus는 레거시 하드웨어 기반 로드 밸런서 뒤에 있습니다.
4-1. 대규모 다중 테넌트 하드웨어 로드 밸런서의 문제
4-2. 다중 프록시 레이어를 사용하는 것이 합리적인 이유
5. 요약
1. 소개
많은 기업이 하드웨어 로드 밸런서에서 NGINX Plus로 이동하여 애플리케이션을 제공하려고 합니다. 이 결정에는 많은 동인이 있을 수 있습니다 . 하드웨어 어플라이언스를 사용할 수 없는 가상화 또는 클라우드로 이동합니다. 하드웨어 로드 밸런서와 함께 사용할 수 없는 DevOps 도구를 사용합니다. 하드웨어 어플라이언스로는 실현할 수 없는 탄력적이고 확장된 인프라로 이동합니다. 그리고 더.
로드 밸런서를 처음 배포하는 경우 NGINX Plus가 애플리케이션에 이상적인 플랫폼일 수 있습니다. 이미 하드웨어 로드 밸런서가 있는 기존 환경에 NGINX Plus를 추가하는 경우 NGINX Plus를 병렬 또는 직렬로 배포할 수 있습니다.
2. 시나리오 1: NGINX Plus에서 모든 로드 밸런싱 수행
가장 간단한 배포 시나리오는 NGINX Plus가 모든 로드 밸런싱 작업을 처리하는 경우입니다. NGINX Plus는 환경의 첫 번째 로드 밸런서이거나 레거시 하드웨어 기반 로드 밸런서를 대체할 수 있습니다. 클라이언트는 NGINX Plus에 직접 연결한 다음 역 프록시 역할을 하여 백엔드 서버 풀에 대한 요청을 로드 밸런싱합니다.
이 시나리오는 관리할 플랫폼이 하나만 있는 단순성의 이점이 있으며 아래에서 설명하는 다른 배포 시나리오 중 하나로 시작하는 마이그레이션 프로세스의 최종 결과가 될 수 있습니다.
SSL/TLS가 사용 중인 경우 NGINX Plus는 백엔드 서버에서 SSL/TLS 처리를 오프로드할 수 있습니다. 이는 백엔드 서버의 리소스를 확보할 뿐만 아니라 SSL/TLS 처리를 중앙 집중화하면 SSL/TLS 세션 재사용도 증가합니다. SSL/TLS 세션 생성은 SSL/TLS 처리에서 CPU를 가장 많이 사용하는 부분이므로 세션 재사용을 늘리면 성능에 큰 긍정적인 영향을 미칠 수 있습니다.
NGINX와 NGINX Plus는 모두 정적 및 동적 콘텐츠의 Cache로 사용할 수 있으며 NGINX Plus는 Cache에서 항목을 제거하는 기능을 추가하여 특히 동적 콘텐츠에 유용합니다.
NGINX Plus는 애플리케이션 상태 확인 , 세션 지속성 , 요청 속도 제한 , 응답 속도 제한 , 연결 제한 등과 같은 추가 ADC 기능을 제공합니다 .
이 시나리오에서 고가용성(HA)을 지원하려면 NGINX Plus 인스턴스의 클러스터링이 필요합니다.
3. 시나리오 2: NGINX Plus는 레거시 하드웨어 기반 로드 밸런서와 병렬로 작동
이 시나리오에서 NGINX Plus는 레거시 하드웨어 어플라이언스가 기존 애플리케이션의 로드 밸런싱을 계속하는 환경에서 새로운 애플리케이션의 로드 밸런싱을 위해 도입되었습니다.
이 시나리오는 하드웨어 로드 밸런서와 NGINX Plus가 모두 있는 데이터 센터에 적용하거나 NGINX Plus가 새 데이터 센터 또는 클라우드에 배포되는 동안 하드웨어 로드 밸런서가 레거시 데이터 센터에 있을 수 있습니다.
NGINX Plus와 하드웨어 기반 로드 밸런서는 어떤 식으로든 연결되어 있지 않으므로 NGINX Plus 관점에서 보면 NGINX가 유일한 로드 밸런서인 첫 번째 시나리오와 매우 유사합니다.
클라이언트는 SSL/TLS 종료를 오프로드하고 정적 및 동적 콘텐츠를 Cache하며 기타 고급 ADC 기능을 수행할 수 있는 NGINX Plus에 직접 연결합니다.
고가용성이 중요한 경우 이전 시나리오와 동일한 솔루션을 사용할 수 있습니다.
이러한 방식으로 NGINX를 배포하는 일반적인 이유는 회사가 보다 현대적인 소프트웨어 기반 플랫폼으로 이동하기를 원하지만 기존 하드웨어 로드 밸런서를 모두 제거하고 교체하기를 원하지 않기 때문입니다. 모든 새로운 애플리케이션을 NGINX Plus 뒤에 배치함으로써 기업은 소프트웨어 기반 플랫폼 구현을 시작한 다음 시간이 지남에 따라 기존 애플리케이션을 하드웨어 로드 밸런서에서 NGINX Plus로 마이그레이션할 수 있습니다.
4. 시나리오 3: NGINX Plus는 레거시 하드웨어 기반 로드 밸런서 뒤에 있습니다.
이전 시나리오와 마찬가지로 NGINX Plus는 레거시 하드웨어 기반 로드 밸런서가 있는 환경에 추가되지만 여기서는 레거시 로드 밸런서 뒤에 있습니다. 하드웨어 기반 로드 밸런서는 클라이언트 요청을 수락하고 이를 NGINX Plus 인스턴스 풀에 로드 밸런싱하여 실제 백엔드 서버 그룹에 걸쳐 로드 밸런싱합니다. 이 시나리오에서 NGINX Plus는 모든 Layer-7 애플리케이션 로드 밸런싱 및 캐싱을 수행합니다.
NGINX Plus 인스턴스가 하드웨어 로드 밸런서에 의해 로드 밸런싱되고 있기 때문에 하드웨어 로드 밸런서가 NGINX Plus 인스턴스에 대한 상태 확인을 수행하고 다운된 인스턴스에 대한 트래픽 전송을 중지함으로써 HA를 달성할 수 있습니다.
4-1. 대규모 다중 테넌트 하드웨어 로드 밸런서의 문제
이러한 방식으로 NGINX Plus를 배포하는 데에는 여러 가지 이유가 있을 수 있습니다. 하나는 기업 구조 때문입니다. 많은 내부 애플리케이션 팀이 장치 또는 장치 세트를 공유하는 다중 테넌트 환경에서 하드웨어 로드 밸런서는 종종 네트워크 팀이 소유하고 관리합니다. 애플리케이션 팀은 애플리케이션별 로직을 추가하기 위해 로드 밸런서에 액세스하기를 원할 수 있지만 진정한 멀티 테넌시의 복잡성으로 인해 정교한 솔루션이라도 여전히 애플리케이션과 다른 애플리케이션 간에 완전한 격리를 제공할 수 없습니다. 애플리케이션 팀에 공유 장치에 대한 무료 액세스 권한이 부여된 경우 한 팀이 다른 팀에 부정적인 영향을 미치는 구성 변경을 수행할 수 있습니다.
잠재적인 문제를 피하기 위해 네트워크 팀은 종종 하드웨어 로드 밸런서를 단독으로 제어합니다. 애플리케이션 팀은 구성을 변경하려면 요청을 제출해야 합니다. 또한 팀 간의 구성 충돌 가능성 때문에 네트워크 팀은 노출되는 고급 ADC 기능을 제한할 수 있습니다.
4-2. 다중 프록시 레이어를 사용하는 것이 합리적인 이유
이 문제에 대한 한 가지 솔루션은 NGINX Plus와 같은 작은 로드 밸런서 세트를 배포하여 각 애플리케이션 팀이 자체 로드 밸런서를 가질 수 있도록 하는 것입니다. 서로 완전히 격리된 애플리케이션 팀은 다른 팀에 부정적인 영향을 미치지 않으면서 필요한 모든 기능을 최대한 활용할 수 있습니다. 각 애플리케이션 팀에 하드웨어 어플라이언스 세트를 제공하는 것은 비용 효율적이지 않으므로 NGINX Plus와 같은 소프트웨어 기반 로드 밸런서의 훌륭한 사용 사례입니다.
하드웨어 로드 밸런서는 그대로 유지되며 네트워크 팀이 여전히 소유 및 관리하지만 복잡한 멀티 테넌트 문제나 애플리케이션 로직을 더 이상 처리할 필요가 없습니다. 그들의 유일한 작업은 애플리케이션 로직이 상주하는 올바른 NGINX Plus 인스턴스에 대한 요청을 가져오는 것이며 NGINX Plus는 요청을 올바른 백엔드 서버로 라우팅합니다. 이를 통해 네트워크 팀은 필요한 제어 기능을 제공하는 동시에 애플리케이션 팀이 ADC 기능을 최대한 활용할 수 있습니다.
5. 요약
소프트웨어 기반 로드 밸런서 고유의 유연성을 통해 거의 모든 환경 및 시나리오에 쉽게 배포할 수 있습니다. IT 세계는 분명히 소프트웨어 기반 플랫폼으로 이동하고 있으며 NGINX Plus를 사용하면 기존의 것을 뜯어내고 교체할 필요가 없습니다. NGINX Plus를 기존 환경이나 미래의 아키텍처로 마이그레이션할 때 새 환경에 설치할 수 있습니다.
댓글을 달려면 로그인해야 합니다.