AWS Load Balancer 로 NGINX Plus 고가용성 사용하기

AWS Load Balancer 는 웹 애플리케이션에 도착하는 트래픽을 효율적으로 분산시켜주는 중요한 서비스입니다. 웹 애플리케이션의 성능과 가용성을 향상시키는 방법에 대해 알아볼 것입니다. 이를 통해 웹 애플리케이션의 안정성을 높이고 사용자 경험을 개선하는 데 도움이 될 것입니다.

Load Balancer는 웹 애플리케이션의 단일 항목 역할을 하는 경우가 많으므로 애플리케이션 전송 인프라에서 중요한 구성 요소이며, Load Balancer Downtime은 곧 애플리케이션 Downtime을 의미합니다. Downtime과 이로 인한 사용자 불만을 최소화하려면 Load Balancer를 고가용성(HA) 방식으로 배포해야 합니다.

이 포스트에서는 AWS Load Balancer 로 NGINX Plus의 HA를 달성하기 위해 사용할 수 있는 몇 가지 방법을 비교합니다. On-premise 배포를 위해 제공하는 HA를 위한 Keepalived 기반 솔루션에 이미 익숙하실 수도 있습니다. 그러나 일반적으로 AWS 및 클라우드 환경의 네트워킹 제한으로 인해 클라우드에서는 해당 솔루션을 사용할 수 없습니다. 그럼에도 불구하고 AWS는 NGINX Plus의 HA를 달성하기 위한 다른 옵션을 제공합니다.

NGINX Plus의 고가용성 Active-Active 배포를 AWS NLB(Network Load Balancer)와 결합한 솔루션도 있습니다.

이 포스트에서 설명하는 방법은 NGINX Opens Source와 NGINX Plus 모두에 적용되지만 간결한을 위해 나머지 부분에서는 NGINX Plus만 언급하겠습니다.

표에는 이 포스트에서 설명할 네 가지 방법이 요약되어 있습니다.

MethodHA TypeIP Address TypeNotes
ELBActive‑ActiveDynamic; CNAME 위임이 필요합니다.ELB는 WebSocket 또는 HTTP/2 지원을 위해 TCP 모드로 구성해야 합니다.
Route 53Active‑Active 또는 Active‑PassiveStatic; Route 53에서 호스팅되는 DNS
Elastic IP address 및 keepalivedActive‑PassiveStatic; 어디서나 호스팅되는 DNS
Elastic IP address 및 LambdaActive‑PassiveStatic; 어디서나 호스팅되는 DNSNGINX Professional Services에서 구성

이 포스트는 AWS Load Balancer 로 NGINX Plus의 한 가지 측면, 즉 고가용성 제공에 초점을 맞추고 있습니다.

목차

1. ELB를 사용하는 NGINX Plus의 고가용성
2. AWS Load Balancer 없이 Route 53을 사용하는 NGINX Plus의 고가용성
3. ELB 또는 Route 53이 없는 NGINX Plus의 고가용성
4. AWS Load Balancer 요약

1. ELB를 사용하는 NGINX Plus의 고가용성

AWS의 기본 기본 제공 Load Balancer인 Elastic Load Balancer(ELB, 현재 공식 명칭은 Classic Load Balancer)는 기능이 제한적이지만 가용성이 높습니다. 따라서 다이어그램에 표시된 것처럼 ELB를 활용하여 NGINX Plus를 고가용성으로 만들 수 있습니다.

When you use the native AWS load balancer, ELB, for NGINX high availability, it is an active-active setup: traffic is routed to both NGINX Plus instances durning normal operation.

모든 NGINX Plus 인스턴스 간에 트래픽을 Load Balancing하도록 ELB를 구성한 다음 애플리케이션 인스턴스로 트래픽을 Load Balancing합니다. NGINX Plus 인스턴스 중 하나에 장애가 발생하면 ELB가 장애를 감지하고 해당 인스턴스로의 트래픽 전송을 중지합니다. ELB가 NGINX Plus 인스턴스의 장애를 신속하게 감지할 수 있도록 ELB Health Check을 구성하는 것이 중요합니다.

ELB는 Active-Active HA를 제공하므로 모든 NGINX Plus 인스턴스가 사용 중이며 트래픽을 할당받습니다. 대기 NGINX Plus 인스턴스를 배포하지 않으면 전체 비용이 절감됩니다.

그러나 HTTP Load Balancer로 배포된 ELB는 HTTP/2 또는 WebSocket 프로토콜을 지원하지 않습니다. 이러한 프로토콜을 NGINX Plus와 함께 사용해야 하는 경우, ELB를 HTTP가 아닌 TCP Load Balancer로 배포해야 합니다. 이 경우 클라이언트 IP 주소를 ELB에서 NGINX Plus로 전달해야 하며, ELB와 NGINX Plus 모두에서 Proxy 프로토콜도 구성해야 합니다.

NGINX Plus의 HA 배포에 ELB를 사용하면 몇 가지 단점이 있습니다.

  • ELB는 일부 애플리케이션에서 중요한 요구 사항인 고정 IP 주소를 Expose하지 않습니다.
  • ELB는 Load Balancing 계층을 추가하므로 복잡성과 비용이 증가합니다.
  • ELB는 UDP를 지원하지 않으므로 NGINX Plus를 사용하여 UDP 트래픽을 Load Balancing할 수 없습니다.
  • ELB는 빠르게 확장되지 않으므로 대규모 트래픽 급증으로 인해 트래픽이 감소할 수 있습니다.
  • ELB IP 주소는 DNS CNAME 레코드를 사용하여 게시됩니다. 모든 DNS를 Route 53에 위임하지 않으면 root 도메인(예: example.com)을 CNAME에 매핑할 수 없습니다.

유사한 방식으로 최신 기본 AWS Load Balancer 인 Application Load Balancer(ALB)를 사용할 수도 있습니다. ELB보다 더 많은 기능과 유연성을 제공하지만 이전 목록의 단점을 공유합니다.

2. AWS Load Balancer 없이 Route 53을 사용하는 NGINX Plus의 고가용성

ELB와 마찬가지로 Route 53을 사용하면 그림과 같이 Active-Active NGINX Plus 배포를 생성할 수 있습니다.

When you use Route 53 as the AWS load balancer for NGINX high availability, it is an active-active setup: traffic is routed to both NGINX Plus instances durning normal operation. When an instance fails, Route 53 removes its DNS record.

호스트 영역을 생성하고 레코드를 추가하여 모든 NGINX Plus 인스턴스로 트래픽을 라우팅할 수 있도록 합니다. NGINX Plus 인스턴스의 Route 53 Health Check을 구성해야 합니다. NGINX Plus 인스턴스 중 하나에 장애가 발생하면 Route 53은 해당 인스턴스와 연결된 레코드를 DNS 쿼리에 대한 응답에서 제외합니다. 그러나 클라이언트와 중간 DNS 서버는 권한 있는 DNS 서버가 설정한 각 레코드의 TTL(Time-to-Live) 값에 따라 레코드를 캐시합니다. 이들은 TTL이 만료될 때까지 레코드를 업데이트하지 않으므로 권한 있는 서버가 응답에서 NGINX Plus 인스턴스에 대한 레코드를 제거해도 즉시 알아차리지 못합니다. 이 문제를 해결하려면 NGINX Plus 레코드에 최소 TTL 값을 설정해야 합니다.

Active-Active 배포 외에도 Route 53을 사용하면 AWS 설명서에 설명된 대로 Active-Passive 배포 또는 훨씬 더 복잡한 장애 조치 조합을 생성할 수 있습니다.

이 포스트에 설명된 다른 방법과 함께 Route 53을 사용할 수도 있습니다.

3. ELB 또는 Route 53이 없는 NGINX Plus의 고가용성

여러 가지 이유로 NGINX Plus의 고가용성을 위해 ELB 또는 Route 53에 의존하고 싶지 않을 수 있습니다. 한 가지 대안은 Active-Passive NGINX Plus 배포에서 AWS의 Elastic IP 주소 기능을 사용하는 것입니다. 여기서는 NGINX Plus의 고정 IP 주소를 Expose하고 이를 기본(Active 또는 마스터) NGINX Plus 인스턴스와 연결합니다. 대기 또는 백업 모드의 두 번째 NGINX Plus 인스턴스는 트래픽을 처리하지 않지만 마스터 NGINX Plus 인스턴스가 실패할 때 인계할 준비가 되어 있습니다. 인계(장애 조치) 중에 Elastic IP 주소는 이제 마스터로 간주되는 두 번째 인스턴스로 재할당됩니다.

A solution for NGINX high availability that does not rely on an AWS load balancer uses an Elastic IP address that moves from the master (active) NGINX Plus instance to the standby (passive) instance if the master fails.

Elastic IP 주소 방법의 단점은 다음과 같습니다.

  • 백업 인스턴스는 대부분의 시간 동안 사용되지 않으므로 배포 비용이 증가합니다.
  • 일반적인 On-premise 배포와 달리 고정 IP 주소의 재연결은 즉각적으로 이루어지지 않습니다. 테스트 결과 IP 주소를 새 마스터 인스턴스와 재연결하는 데 최대 6초가 걸리는 것으로 나타났습니다.
  • 마스터 NGINX Plus 인스턴스의 상태를 모니터링하고 마스터가 실패할 경우 탄력적 IP 주소를 다시 연결하는 소프트웨어를 설치하고 적절하게 구성해야 하므로 배포는 ELB 또는 Route 53 방법보다 더 복잡합니다.

NGINX팀 Elastic IP 주소를 사용하는 두 가지 솔루션을 제공합니다. 이 두 솔루션은 마스터 NGINX Plus 인스턴스의 상태를 모니터링하고 Elastic IP 주소를 재연결하는 방식에서 차이가 있습니다.

keepalived 기반 솔루션 – On-premise 배포를 위한 keepalived 기반 솔루션을 수정하여 AWS에서 Elastic IP 주소 재연결을 지원하도록 할 수 있습니다. On-premise HA 배포에서와 마찬가지로, 백업 NGINX Plus 인스턴스의 keepalived 데몬은 마스터 인스턴스의 상태를 모니터링합니다. On-premise 솔루션과의 차이점은 마스터에 장애가 발생하면 keepalived가 AWS API를 호출하는 사용자 정의 스크립트를 호출하여 Elastic IP 주소를 재연결한다는 것입니다. 이 솔루션은 NGINX Plus 지원 계약에 포함되지 않는다는 점에 유의하세요.

AWS Lambda 기반 솔루션 – 이 솔루션은 Lambda 함수를 사용하여 NGINX Plus 마스터 인스턴스의 상태를 모니터링하고 마스터가 실패할 경우 Elastic IP 주소를 다시 연결합니다. 이 솔루션은 고객을 위해 솔루션을 배포 및 구성하고 지원을 제공하는 전문 서비스 팀에서 사용할 수 있습니다.

NGINX Plus의 고가용성 Active-Active 배포를 AWS NLB와 결합하는 솔루션도 있습니다.

4. AWS Load Balancer 요약

AWS Load Balancer 에는 고가용성이 매우 중요합니다. AWS는 이 포스트에서 설명한 대로 고가용성 방식으로 NGINX Plus를 배포할 수 있는 여러 가지 방법을 제공합니다. ELB 또는 Route 53을 기반으로 하는 방법이 좋은 시작점이며, 고정 IP 주소가 필요한 경우에는 keepalived 또는 AWS Lambda를 기반으로 하는 Elastic IP 방법을 사용하세요.

AWS에서 NGINX Plus을 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.