AWS ALB vs NGINX Plus Health Check 비교 분석

NGINX 오픈소스에서도 간단한 Passive Health Check 기능은 지원하지만, 해당 포스트에서는 각각의 AWS ALB(Application Load Balancer)를 기반으로 한 NGINX Plus의 Active Health Check 기능과 AWS Health Check를 비교 및 분석하였습니다.

AWS는 Amazon에서 제공하는 세계적인 클라우드 컴퓨팅 플랫폼입니다. 이 플랫폼은 다양한 서비스와 인프라를 제공하여 고객들이 쉽게 시스템을 구축하고 확장할 수 있도록 지원합니다. AWS는 컴퓨팅, 스토리지, 데이터베이스, 인공 지능, 머신 러닝, 보안 및 기타 많은 분야에서 서비스를 제공하고 있습니다. 현재 국내 클라우드 시장 점유율 또한 Amazon이 1위이며 이만큼 국내에서도 Amazon의 기술을 많이 사용하고 있습니다.

NGINX는 고성능, 확장성이 뛰어난 오픈 소스 웹 서버, Reverse Proxy 그리고 Load Balancer 로 널리 알려져 있습니다. Igor Sysoev가 개발한 이 웹 서버는 비동기 Event-Driven 아키텍처(Asynchronous event-driven architecture)를 사용하여 높은 동시 연결 처리 능력을 제공합니다. NGINX는 동시 연결 처리에 백만 개 이상의 높은 성능과 유연한 Reverse Proxy 및 Load Balancing, 가볍고, 소스가 압축되며 리소스를 사용할 수 있는 등 다양한 기능이 포함되어 있습니다.

목차

1. AWS ALB Health Check
1-1. AWS ALB Health Check 구성
1-2. AWS ALB Health Check의 기본값 분석
1-3. AWS Health Check 설정 최적화하기
2. NGINX Plus Health Check
2-1. NGINX Plus Health Check 구성
2-2. NGINX Plus Health Check의 기본값 분석
2-3. NGINX Plus Health Check 설정 최적화하기
3. AWS ALB vs NGINX Plus Health Check 기능 비교
4. AWS Health Check vs NGINX Plus Health Check
5. AWS ALB vs NGINX Plus LB

1. AWS ALB Health Check

AWS ALB Health Check는 AWS에서 제공하는 여러 가지 서비스에서 사용되는 모니터링 기능입니다. 클라우드 인프라와 애플리케이션 상태를 지속적으로 확인하여 가용성 및 성능을 유지하고, 서비스 중단이나 요청 실패를 줄이는 데 도움을 줍니다. AWS에서는 Route 53, Elastic Load Balancer(ELB), Amazon ECS 등 다양한 서비스에서 Health Check를 제공합니다.

1-1. AWS ALB Health Check 구성

성능 비교를 위한 테스트 환경은 다음과 같습니다.

1. Instances

2. Load Balancer

3. Target Group

테스트를 진행하기 위해 2개의 Instance를 생성하였고, Load Balancer 및 Target Group을 각각 하나씩 생성하였습니다.

1-2. AWS ALB Health Check의 기본값 분석

1. Target Groups 탭에서 생성한 Target Group을 선택한 뒤, Health Checks 블록을 클릭하면 현재 Health Check의 설정을 확인할 수 있습니다.

AWS ALB Health Checks Tab

오른쪽의 Edit을 클릭하여 설정 편집에 들어가 자세한 값을 확인합니다.

다음은 Edit 클릭 후 AWS ALB Health Check 설정의 기본값(default setting) 입니다.

AWS ALB Health Chec Settings

Health Check 할 프로토콜은 HTTP이고 경로는 / 로 설정되어 있는 것을 확인할 수 있고, 아래에 Advanced health check settings를 클릭하여 자세한 구성을 확인합니다. 다음은 AWS Health Check의 기본 구성입니다.

AWS ALB Advanced Health Check Settings

따라서 AWS Health Check의 기본값은 다음과 같습니다.

  • Health check port – Load Balancer 가 대상에 대한 Health Check를 수행할 때 Target Group과 동일한 포트를 사용합니다.
  • Healthy threshold – 연속 5번의 Health Check를 성공하면 정상으로 간주합니다.
  • Unhealthy threshold – 연속 2번의 Health Check를 실패하면 비정상으로 간주합니다.
  • Timeout – 5초동안 응답이 없으면 Health Check 실패로 간주합니다.
  • Interval – Health Check는 30초에 한 번 이루어집니다.
  • Success codes – 응답 성공시 상태 코드 200을 나타냅니다.

여기서 중요한 점은 AWS Health Check의 기본 구성을 변경하지 않고 사용한다면 Health Check를 30초에 1번 실행한다는 것입니다. Health Check를 30초에 1번 진행한다면 30초의 긴 시간 동안 서버나 애플리케이션에서 발생하는 문제를 실시간으로 감지하는데 상대적으로 느릴 수 있습니다. Health Check 간격이 길어질수록 많은 문제점들이 생깁니다.

관리자는 서버나 리소스에 대한 대응이 늦어지게 됩니다. 이로 인해 서비스 제공 업체의 관리 및 모니터링 작업에서 지연이 발생하며, 즉각적인 조치가 요구되는 문제를 빠르게 대응하지 못할 수 있습니다. 이는 곧 사용자들에게도 영향을 미치며 실패한 서비스와 계속되는 로딩 및 요청 실패 등의 문제에 직면할 가능성이 높습니다. 이 외에도 많은 문제점이 발생할 수 있으므로 이를 고려하여, Health Check의 간격을 적절히 조절하여 안정성과 성능을 유지할 필요가 있습니다.

1-3. AWS Health Check 최적화하기

AWS Health Check 설정을 변경하여 최적화하겠습니다. 다음과 같이 설정할 수 있는 제한이 아래에 표시되어 있습니다. 이에 맞게 최솟값으로 변경합니다. 해당 비교에서는 다음과 같이 수정하였습니다.

AWS ALB Advanced Health Check Settings-2

AWS Health Check의 Interval 최솟값은 5초입니다. 이 5초가 느린 시간은 아닙니다. 하지만 실시간 서비스가 중요하거나 높은 수준의 가용성이 요구되는 서비스를 운영하는 기업 같은 경우는 이 5초 또한 길 수 있습니다. 예를 들면 다음과 같습니다.

  • 금융 서비스 – 주식 거래 플랫폼, 금융 거래 및 실시간 분석 시스템과 같은 금융 서비스는 네트워크 지연 시간에 매우 민감하며, 신속한 거래 처리와 데이터 신뢰성이 중요합니다.
  • 응급 서비스 – 응급 의료 서비스나 긴급 상황 대응을 위한 통신 시스템과 같은 응급 서비스는 시스템 가용성이 매우 중요하며, 짧은 Health Check Interval 값이 필요합니다.
  • 스트리밍 서비스 – 실시간 스트리밍 서비스, 게임 서비스 및 고화질 동영상 스트리밍 플랫폼 들에서는 실시간 서비스 가용성이 중요합니다.

이 외에도 Health Check를 빠르게 설정해야 하는 기업이나 서비스들은 5초라는 시간은 느린 편에 속합니다. 이런 고객들이 AWS Health Check를 사용하려고 하면 문제가 생길 수 있습니다. 만약 고객이 Health Check를 1초에 한 번 즉, Interval 값을 1로 지정해야 하는 고객일 경우 다음과 같은 문제가 발생합니다.

AWS ALB Health Check Interval

AWS Health Check에서 제공하는 범위가 5~300초 이기 때문에 1초로 설정할 수 없습니다.

2. NGINX Plus Health Check

NGINX Plus Health Check는 다양한 기능을 지원합니다. 먼저 Active Health Check와 Passive Health Check를 지원합니다. 이를 이용하여 백엔드 서버들의 상태를 지속적으로 모니터링하고, 문제가 발생한 서버를 감지하고 해당 트래픽을 정상 서버로 우회합니다. NGINX Plus Health Check는 빠른 장애 탐지 및 복구가 가능합니다. 이를 통해 시스템의 복구 시간을 최소화하고, 서비스의 안정성을 향상시킬 수 있습니다. 또한 Health Check의 다양한 설정 옵션을 제공합니다. 고객의 목적에 따라 Health Check 설정을 유연하게 설정할 수 있습니다.

종합적으로, NGINX Plus Health Check는 고가용성, 향상된 성능, 빠른 장애 대응, 유연한 설정 등 웹 애플리케이션 및 서버 가용성과 성능을 확보하는 데 도움이 됩니다.

2-1. NGINX Plus Health Check 구성

이번 비교에서는 NGINX Plus Active Health Check만을 다루었고, 성능 비교를 위한 테스트 환경은 다음과 같습니다. (총 3개의 서버를 사용하였고, 환경은 동일합니다.)

다음은 Active Health Check를 활성화하는 방법입니다.

먼저 Upstream 블록에 zone 지시문을 추가합니다.

upstream LB {
     zone LB 64;
     server 192.168.200.10;
     server 192.168.200.11;
}

그리고 proxy_pass 지시문이 있는 location 블록 아래에 health_check 지시문을 사용하면 NGINX Plus Active Health Check 기능이 활성화됩니다.

location / {
     proxy_pass http://LB;
     health_check;
}

2-2. NGINX Plus Health Check의 기본값 분석

이제 interval 지시문의 기본값은 5초입니다. NGINX Plus에서 제공하는 dashboard 기능을 사용하여 Health Check가 정상 작동하는지 확인해보겠습니다.

약 10초 동안 Health Check 횟수가 2개 증가한 것을 확인할 수 있습니다. 이로써 NGINX Plus Active Health Check의 기본값은 서버 시작 시 Health Check를 1회 실행하고 interval 기본값 5초마다 Health Check를 수행하는 것을 확인할 수 있습니다.

2-3. NGINX Plus Health Check 최적화 하기

분명 Interval 값을 변경하고 싶은 경우가 있을 것입니다. 그렇다면 다음과 같이 interval 지시문을 추가해주시면 됩니다.

location / {
     proxy_pass http://LB;
     health_check interval=1;
}

interval 지시문에 숫자만 입력하게 되면 기본적으로 second 단위로 정의됩니다. 따라서 위의 구성은 interval 값이 1s로 설정한 것입니다. 이를 다시 dashboard를 사용해 확인해 보면 다음과 같습니다.

설정한 것과 같이 Health Check 실행 횟수가 1초당 1회로 실행된 것을 확인할 수 있습니다.

3. AWS ALB vs NGINX Plus Health Check 기능 비교

이렇게 AWS Health Check와 NGINX Plus Health Check를 분석해봤습니다.

위의 테스트 자료에서도 확인할 수 있듯이 AWS Health Check에서 확인한 Interval의 최솟값은 5(s) 입니다. 그리고 NGINX Plus Health Check에서 확인한 Interval 값은 1(s) 입니다. 서로 비교해 봤을 때 AWS Health Check와 NGINX Plus Health Check는 5초 정도 차이가 나는 것을 확인할 수 있습니다.

하지만 여기서 NGINX Plus Health Check에서 Interval 값을 1(s)로 설정은 했지만, 그 어디에도 1(s)가 최솟값이라고 말한 적은 없습니다. 과연 NGINX Plus Health Check의 Interval 최솟값은 1(s) 일까요?

이에 대한 대답은 “아니요” 입니다. NGINX Plus Health Check의 Interval 최솟값은 무려 1(ms) 입니다. 확인하기 위해 다음과 같이 테스트 해봤습니다.

location / {
     proxy_pass http://LB;
     health_check interval=1ms;
}

테스트를 진행해본 결과 interval=1ms 는 너무 빨라 저의 테스트 환경으로는 쫓아갈 수 없었습니다. 그렇기 때문에 100ms 정도로 늦춰서 테스트를 다시 한번 진행해본 결과.

location / {
     proxy_pass http://LB;
     health_check interval=100ms;
}

interval=100ms는 약 10초에 Health Check 100회 수행 즉, 초당 1회의 Health Check가 저의 테스트환경에서는 정확히 표시되는 것을 확인할 수 있었습니다.

NGINX Plus Health Check는 최솟값뿐이 아닌 최댓값 또한 AWS Health Check와 차이가 납니다. AWS Health Check의 경우 최대가 300s이지만, NGINX Plus Health Check는 “interval = 1d” 처럼 ms뿐만 아니라 day까지 지원합니다. 즉, interval = 1ms, interval = 1s, interval = 1m, interval = 1h, interval = 1d 이렇게 목적에 맞는 다양한 설정이 가능합니다.

4. AWS Health Check vs NGINX Plus Health Check

지금까지 AWS Health Check와 NGINX Plus Health Check의 Interval을 직접 테스트하며 분석해본 결과는 다음과 같습니다.

AWS와 NGINX Plus의 최소 Interval 비교 결과, Interval의 최솟값 기준 초당 5000회 차이가 나는 것을 확인했습니다. 작업 환경과 사양에 따라서 1ms보다 높게 설정해야 할 수도 있습니다. 저 같은 경우 100ms로 테스트했을 때 정확하게 Health Check를 수행하였고, 100ms로 수정해도 AWS가 Health Check를 1회 수행할 때 NGINX Plus는 50회 실행하여 엄청난 차이를 확인할 수 있었습니다.

이로써 서버에 대한 Health Status를 빠르고, 정확하게 파악할 수 있습니다.

interval 외에 jitter, fails, passes 등 다양한 지시문을 사용하여 설정을 더욱 구체화할 수 있습니다. 자세한 정보는 NGINX STORE의 가이드를 참조하세요.

5. AWS ALB vs NGINX Plus LB

Health Check 기능도 중요하지만 그 만큼 Load Balancer도 중요합니다. 아래에 Load Balancer 비교표를 확인하시고 더 나은 Load Balancer를 선택하십시오. 자세한 내용은 AWS Application Load Balancer vs NGINX Plus 포스트를 참조하십시오.

 Amazon Application Load BalancerNGINXNGINX Plus
Load Balancing 방법 및 특징Round_robin 및 least_outstanding_requests 메서드, 쿠키 기반 세션 지속성, 가중 대상 그룹(Weighted Target Groups) 및 느린 시작(Slow Start)가중 Upstream 서버를 사용하는 여러 Load Balancing 방법(라운드 로빈, 최소 연결, 해시, IP 해시 및 랜덤 포함)NGINX와 동일하며 최소 시간 방법, 더 많은 세션 지속 방법 및 느린 시작(Slow Start)
캐싱(Caching)❌ Load Balancer의 캐싱이 지원되지 않음✅ 정적 파일 캐싱 및 동적(애플리케이션) 캐싱✅ 정적 파일 캐싱 및 동적(애플리케이션) 캐싱
헬스 체크(Health Checks)Active(비동기 검사를 위해 반환된 상태 코드를 확인하여 실패한 서버 식별)Passive(클라이언트 요청에 대한 응답을 확인하여 실패한 서버 식별)Active and Passive – Active 검사는 ALB보다 더 풍부하게 구성 가능합니다.
고가용성HA 여러 가용 영역에 ALB 인스턴스를 배포할 수 있지만 지역 간에는 배포할 수 없습니다.NLB가 있는 Active‑Active HA 및 탄력적 IP주소가 있는 Active‑Passive HANGINX와 동일하며, 모든 NGINX Plus 인스턴스에서 원활한 HA를 위한 내장 클러스터 상태 공유
IP 제품군의 모든 프로토콜 지원❌ HTTP 및 HTTPS 전용✅ TCP 및 UDP, Passive 헬스 체크 기능 포함✅ TCP 및 UDP, Active, Passive 헬스 체크 기능 포함
Load Balancer 인스턴스당 여러 애플리케이션✅✅✅
콘텐츠 기반 라우팅✅ 요청 URL, 호스트 헤더, 표준 및 사용자 지정 HTTP 헤더, 메서드, 쿼리 매개변수, Source IP 주소를 포함한 요청 필드 기반✅ ALB와 동일한 요소, NGINX JavaScript 모듈을 Inline JavaScript 엔진으로 사용하는 쿠키 및 동적 계산을 기반으로 합니다.✅ NGINX와 동일한 요소와 Key‑Value Store 의 JWT 클레임 및 값을 기반으로 합니다.
컨테이너화된 애플리케이션Amazon ID, ECS 컨테이너 인스턴스, Auto Scaling 그룹 및 AWS Lambda 함수에 대한 Load Balancing 가능수동 구성 또는 구성 템플릿 필요SRV 레코드를 포함한 DNS를 사용한 자동 구성, 주요 Registry 서비스와 함께 작동
휴대성❌ 모든 환경(개발, 테스트 및 Production)은 AWS에 있어야 합니다.✅ 모든 환경은 모든 배포 플랫폼에 있을 수 있습니다.✅ 모든 환경은 모든 배포 플랫폼에 있을 수 있습니다.
SSL/TLS✅ SNI를 지원하는 멀티 SSL/TLS 인증서
❌ SSL/TLS Upstream 검증이 지원되지 않음		✅ SNI를 지원하는 멀티 SSL/TLS 인증서
✅ SSL/TLS 암호의 전체 선택
✅ SSL/TLS Upstream의 전체 검증		✅ SNI를 지원하는 멀티 SSL/TLS 인증서
✅ SSL/TLS 암호의 전체 선택
✅ SSL/TLS Upstream의 전체 검증
HTTP/2 및 WebSocket✅✅✅
인증 기능– OIDC, SAML, LDAP, AD IdP 인증 옵션
– AWS Cognito 및 CloudFront와 통합		멀티 인증 옵션멀티 인증 옵션
고급 기능❌ 베어본(Barebones) API✅ 오리진 서비스(Origin Serving), 우선 순위 지정, 속도 제한 등✅ NGINX와 동일, RESTful API, Key‑Value Store
Logging 및 디버깅✅ Amazon binary 로그 형식✅ 사용자 지정 가능한 로그 파일 및 여러 디버그 인터페이스✅ 완전히 사용자 지정 가능한 로그 파일 및 여러 디버그 인터페이스, NGINX에서 완벽하게 지원
모니터링 도구✅ Amazon CloudWatch와 통합✅ NGINX Controller 및 기타 타사 도구✅ NGINX Controller 및 기타 타사 도구, 통계에 보고된 확장 세트
공식 기술 지원✅ 추가 비용으로❌ 커뮤니티 지원만 해당✅ 가격에 포함되며 NGINX Support가 제공됩니다.
프리 티어(Free tier)✅ 처음 750시간✅ 언제나 무료✅ 30일 Trial 구독

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

아래 뉴스레터를 구독하고 NGINX의 최신 정보들을 빠르게 전달받아보세요.