F5 DNS 로드 밸런서 및 NGINX Plus로 가용성 보장

이 포스트는 NGINX Plus 와 F5 DNS 로드 밸런서 클라우드 서비스가 함께 작동하여 애플리케이션의 가용성을 높이는 방법에 중점을 두었습니다.


IDC 보고서 에 따르면 애플리케이션 중단 시간은 Fortune지 선정 1000대 기업이 매년 12억5000만 달러에서 25억 달러 사이의 비용을 지출하는 큰 문제입니다. 중단은 고객 신뢰에 영향을 미치고 비즈니스를 정지시킬 수 있습니다.

가동 중지 시간을 줄이고 비용을 줄이기 위해 NGINX와 같은 현대적이고 확장 가능한 애플리케이션 플랫폼을 사용하여 기존 인프라에서 장애 지점을 제거하는 것부터 시작할 수 있습니다. DNS를 사용하여 성능을 더욱 최적화하고 애플리케이션의 가용성을 향상 수 있습니다.

목차

1. DNS는 어떻게 Downtime을 최소화할 수 있습니까?
2. NGINX Plus 및 F5 DNS 로드 밸런서
3. 여러 지역 및 지역에 걸친 애플리케이션 로드 밸런싱
4. 부하 분산 레코드 구성
5. NGINX Plus 활성 상태 확인 구성
6. F5 DNS 및 NGINX Plus 구성 테스트
7. 애플리케이션 실패 처리
8. F5 DNS + NGINX Plus 요약

1. DNS는 어떻게 Downtime을 최소화할 수 있습니까?

DNS는 인터넷에서 이루어지는 모든 요청의 기본입니다. 모든 요청에 ​​대해 첫 번째이자 가장 중요한 결정인 올바른 애플리케이션으로 라우팅하는 방법입니다.

응답하지 않는 애플리케이션 인스턴스에서 클라이언트를 제어함으로써 Global server load balancing (GSLB) 이라고도 하는 DNS 로드 밸런싱은 요청이 다운된 서버로 이동할 때 사용자가 경험하는 가동 중지 시간을 제거합니다.

최신 DNS 로드 밸런싱 솔루션은 애플리케이션 상태 모니터와 클라이언트 위치에 대한 정보를 사용하여 매번 요청을 올바르게 라우팅하고 최종 사용자 경험을 최적화합니다.

2. NGINX Plus 및 F5 DNS 로드 밸런서

NGINX는 가볍고 유연한 고성능 올인원 소프트웨어 로드 밸런서, WAF, 리버스 프록시, 웹 서버, 콘텐츠 캐시 및 API Gateway로, 다른 어떤 웹 서버보다 가장 바쁜 1,000,000개 사이트를 지원합니다. NGINX 소프트웨어는 오픈 소스와 추가 기능이 포함된 엔터프라이즈급 버전인 NGINX Plus로 제공됩니다.

F5의 DNS 로드 밸런서 클라우드 서비스는 지능형 로드 관리 기능을 활용하여 애플리케이션 성능 및 가용성을 최적화하기 위한 확장 가능한 글로벌 트래픽 관리 서비스입니다.

NGINX Plus와 DNS 로드 밸런서가 함께 작동하면 하나 이상의 서버가 단일 지역 내에서 또는 전 세계적으로 다운될 때 영향을 받는 서버 및 위치 주위로 트래픽이 자동으로 라우팅됩니다. 서버가 다시 가동되면 자동으로 부하 분산 풀에 다시 추가됩니다.

3. 여러 지역 및 지역에 걸친 애플리케이션 로드 밸런싱

간단하게 하기 위해 이 블로그에서는 미국의 별도 클라우드 지역에 위치한 두 개의 NGINX Plus 인스턴스가 있는 샘플 토폴로지를 사용하며 둘 다 동일한 애플리케이션을 제공합니다. 실제 배포에는 전 세계 여러 지역에 애플리케이션 인스턴스(및 함께 제공되는 NGINX Plus 리버스 프록시 인스턴스)가 있어야 합니다.

F5 DNS Load Balancer + NGINX Plus

사용자가 브라우저에서 http://www.example.com 을 요청하면 기본 DNS 서비스는 http://www.gslb.example.com 에 대한 정보를 요청하도록 브라우저에 지시합니다. DNS 로드 밸런서 서비스는 *.gslb.example.com 하위 도메인의 모든 DNS 쿼리에 응답하는 전역 트래픽 관리용으로 구성됩니다.

DNS Load Balancer는 애플리케이션 상태를 확인하기 위해 고급 상태 모니터 프로브를 보내고 응답을 기반으로 사용 가능한 경우에만 지역의 애플리케이션 인스턴스로 클라이언트를 보냅니다. 예를 들어 샘플 토폴로지에서 us-west 지역의 NGINX Plus 인스턴스에 의해 프록시된 백엔드 애플리케이션을 사용할 수 없는 경우 DNS 로드 밸런서는 us-east 에서 호스팅되는 애플리케이션 인스턴스로 모든 요청을 조정하고 그 반대의 경우도 마찬가지입니다.

4. 부하 분산 레코드 구성

트래픽을 애플리케이션으로 라우팅하도록 DNS 로드 밸런서를 구성하려면 Load Balancing Record (LBR)라는 지능형 DNS 레코드를 정의합니다. LBR에서 트래픽을 라우팅할 호스트(IP 끝점)와 각 최종 사용자 요청에 대한 최상의 응답을 선택하기 위한 규칙을 지정합니다.

클라이언트 요청이 들어오면 DNS Load Balancer는 이를 LBR의 호스트 목록과 비교합니다. 또한 요청 클라이언트의 지리적 위치를 확인하고 우선 순위 점수를 사용하여 클라이언트를 가장 가까운 애플리케이션 인스턴스로 안내할 수 있습니다.

다음 예에서는 DNS 로드 밸런서의 선언적 API를 사용하여 이러한 구성 개체를 포함하는 LBR을 정의합니다.

  • IP 엔드포인트( 아래 virtual_servers) – DNS 로드 밸런서가 애플리케이션의 클라이언트에 알리는 호스트의 IP 주소 및 관련 정보입니다. 이 예에서 두 개의 IP 엔드포인트는 us-east 및 us-west 지역 의 NGINX Plus 인스턴스입니다.
  • 풀(아래 pools) – IP 엔드포인트의 논리적 그룹화 및 이들 간에 트래픽을 분산하는 데 사용되는 로드 밸런싱 알고리즘입니다. 이 예에서는 nginx_us_pool두 NGINX Plus 인스턴스 간의 라운드 로빈 로드 밸런싱을 정의합니다. 구성을 배포에 적용할 때 address아래 블록의 필드를 virtual_serversNGINX Plus 인스턴스의 IP 주소로 변경하기만 하면 됩니다.
    실제 토폴로지에는 각각 다른 지리적 영역에 있는 IP 끝점을 함께 그룹화하는 여러 개의 풀이 있을 수 있습니다.
  • 상태 모니터( 아래 monitors) –
  • 상태 모니터(모니터 아래) – 애플리케이션을 제공하는 호스트를 사용할 수 있는지 확인하기 위한 고급 HTTP 검사입니다. 이 예에서 모니터는 NGINX Plus 인스턴스의 상태를 확인합니다. 200–499 범위의 NGINX Plus에서 HTTP 응답 코드를 해석하여 프록시 애플리케이션을 사용할 수 있음을 의미합니다. 5xx 응답은 애플리케이션을 사용할 수 없음을 나타냅니다. DNS Load Balancer는 해당 지역을 작동 중지로 표시하고 다른 지역의 IP 엔드포인트 주소로 클라이언트 요청에 응답합니다. 모니터의 수신 값은 유효한 정규식 문자열을 지원하므로 동적으로 생성된 콘텐츠가 HTTP 응답에 있는지 확인할 수 있습니다.
  • 로드 밸런싱 레코드( 아래 load_balanced_records) – 트래픽이 풀로 라우팅되는 방식을 결정하는 DNS 레코드입니다. 이 예에서는 www 에 대한 DNS A레코드를 정의합니다.
{
  "zone":"gslb.example.com",
  "load_balanced_records":{
    "WWW":{
      "aliases": [
        "www"
      ],
      "rr_type": "A",
      "display_name": "www",
      "enable": true,
      "persistence": false,
      "proximity_rules": [
        {
          "region": "global",
          "pool": "nginx_us_pool",
          "score": 1
        }
      ]
    }
  },
  "pools": {
    "nginx_us_pool": {
      "display_name": "NGINX US Pool",
      "enable": true,
      "remark": "",
      "rr_type": "A",
      "ttl": 60,
      "load_balancing_mode": "round-robin",
      "max_answers": 1,
      "members": [
        {
          "virtual_server": "us_west_1_nginx",
          "monitor": "http_monitor"
        },
        {
          "virtual_server": "us_west_2_nginx",
          "monitor": "http_monitor"
        }
      ]
    }
  },
  "virtual_servers": {
    "us_west_1_nginx": {
      "virtual_server_type": "cloud",
      "display_name": "US West NGINX Instance 1",
      "port": 80,
      "address": "192.0.2.100",
      "monitor": "http_adv_monitor"
    },
    "us_east_1_nginx": {
      "virtual_server_type": "cloud",
      "display_name": "US East NGINX Instance 1",
      "port": 80,
      "address": "198.51.100.50",
      "monitor": "http_adv_monitor"
    }
  },
  "monitors": {
    "http_adv_monitor": {
      "display_name": "HTTP Monitor",
      "monitor_type": "https_advanced",
      "target_port": 443,
      "receive": "HTTP/1.. (2|3|4).{2}",
      "send": "GET / HTTP/1.0"
    }
  }
}

5. NGINX Plus 활성 상태 확인 구성

다음으로 해당 지역의 backend upstream 그룹 에 있는 애플리케이션 서버의 상태를 주기적으로 확인하도록 각 NGINX Plus 인스턴스를 구성합니다. 모든 서버가 상태 확인에 실패하면 NGINX Plus는 자동으로 502(BadGateway)사용자 지정 오류 페이지인 error_fail.html 을 반환합니다. 위에서 언급한 대로 DNS 로드 밸런서는  502해당 지역에서 백엔드 애플리케이션을 사용할 수 없음을 의미하는 코드를 해석합니다.

match 블록은 백엔드 애플리케이션이 표시된 응답 본문을 반환하도록 구성되어 있다고 가정합니다.

upstream backend {
    zone backend 64k;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

# Match successful backend app health checks
match server_ok {
    status 200;
    body ~ '{"HealthCheck":"OK"}';
}

server {
    listen 80;
    status_zone backend;

    location / {
        proxy_pass http://backend;
    }

    location @healthcheck {
        internal;
        proxy_pass http://backend;
        error_page 500 502 503 504 = /error_fail.html;
        health_check uri=/healthcheck match=server_ok interval=30s;
    }
}

6. F5 DNS 및 NGINX Plus 구성 테스트

DNS 로드 밸런서 및 NGINX Plus 구성이 준비되면 curl또는 HTTPie 와 같은 도구를 사용하여 애플리케이션을 테스트할 수 있습니다.

$ http --headers https://www.example.com
HTTP/1.1 200 OK
...

DNS 로드 밸런서가 클라이언트를 지시하는 위치를 확인하려면 와 같은 DNS 문제 해결 도구를 사용할 수 있습니다 dig. 정상적인 상황에서 예상되는 다음과 같은 출력은 DNS 로드 밸런서가 두 NGINX Plus 인스턴스의 주소를 교대로 반환함을 나타냅니다(192.0.2.100은 미국 서부 NGINX 인스턴스 1 이고 198.51.100.50은 미국 동부 NGINX 인스턴스 1 임 ).

$ dig +short www.example.com
192.0.2.100
$ dig +short www.example.com
198.51.100.50
$ dig +short www.example.com
192.0.2.100
...

7. 애플리케이션 실패 처리

앞서 언급한 바와 같이 애플리케이션 중단은 고객 신뢰도에 상당한 걸림돌이 됩니다. 귀하의 애플리케이션에 세계 최고의 오류 페이지가 있더라도 중단이 발생한 애플리케이션 인스턴스로 고객을 보내는 이유는 무엇일까요?

여기서는 이러한 상황을 방지하기 위해 앱 배포를 구성했습니다. NGINX Plus 가 상태 모니터에 오류를 반환하면  DNS 로드 밸런서는 모든 새 트래픽을 사용 가능한 다른 지역으로 보냅니다.

F5 DNS Load Balancer + NGINX Plus 502 Error

이 코드를 다시 사용하면 이번에는 DNS 로드 밸런서가 미국 서부 NGINX 인스턴스 1 (192.0.2.100) dig에 대한 주소만 반환하는 것으로 표시됩니다.

$ dig +short www.example.com
192.0.2.100
$ dig +short www.example.com
192.0.2.100
$ dig +short www.example.com
192.0.2.100
...

사용할 수 없는 지역에 있는 백엔드 서버 중 하나 이상이 다시 온라인 상태가 되면 DNS 로드 밸런서가 트래픽을 해당 지역으로 다시 한 번 자동으로 보냅니다.

8. F5 DNS + NGINX Plus 요약

애플리케이션을 여러 지역으로 확장하고 DNS 로드 밸런서를 최신 글로벌 트래픽 관리 솔루션으로 사용하여 고객에게 향상된 가용성을 제공하는 것이 얼마나 간단한지 보여주었습니다.

DNS 로드 밸런서 프리 티어 오퍼링을 활용하여 NGINX 소프트웨어 및 F5 SaaS 솔루션이 어떻게 애플리케이션의 성능과 관리 용이성을 높일 수 있는지 직접 확인하십시오.

예정된 DNS 로드 밸런서용 NGINX Plus 통합 조기 액세스 미리 보기 에 대한 액세스를 요청할 수도 있습니다. 이 통합을 통해 글로벌 애플리케이션 트래픽 관리를 최적화하기 위해 DNS 로드 밸런서와 구성 및 성능 정보를 공유하도록 NGINX Plus 인스턴스를 구성할 수 있습니다.

사용 사례에 대해 논의하려면 당사에 문의하십시오.

NGINX에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.