NS1 및 NGINX Plus 를 사용한 Global Server 로드 밸런싱
DNS 서비스 제공업체 NS1 에 등록된 도메인을 대상으로 글로벌 서버 로드 밸런싱(GSLB)을 NGINX Plus 로 프록시하여 배포하세요.
글로벌 서버 로드 밸런싱(GSLB)은 여러 위치에 있는 서버 리소스 간의 트래픽을 지능적으로 분산하는 것을 의미합니다. GSLB는 DNS 요청에 대한 응답을 제어하여 각 사용자를 가용성, 성능 및 각 PoP의 근접성에 기반하여 가장 적합한 목적지 IP 주소로 안내합니다.
다양한 DNS 제공업체에서 GSLB의 형태를 제공합니다. NS1은 가장 진보된 솔루션 중 하나를 서비스로 제공하며, 각 PoP가 가용성과 현재 부하에 대해 NS1 서버에 동적으로 알릴 수 있는 풍부한 API를 제공합니다.
이 문서에서는 NGINX의 NS1 에이전트를 사용하여 NS1 서비스와 상호 작용하여 NGINX Plus로 구동되는 여러 PoP 간에 고급 GSLB를 활성화하는 방법을 설명합니다. 에이전트 인스턴스를 각 NGINX Plus 인스턴스 옆에 배치하거나, 에이전트를 구성하여 하나 이상의 원격 NGINX Plus 인스턴스를 쿼리할 수 있습니다. (이 가이드는 콜로케이션 옵션에 대해서만 다룹니다.)
에이전트는 주기적으로 NGINX Plus API를 쿼리하여 현재 활성 연결 수와 부하 평균을 계산하는 데 사용하는 여러 메트릭을 가져와 NS1에 보고합니다. 에이전트는 사이트의 상태를 up: true 또는 up: false (즉, down)로 보고할 수도 있습니다.
에이전트는 다음과 같은 기능을 지원합니다.
원격 Health Checks: 사용할 수 없는 (다운 또는 접근할 수 없는) PoP로 클라이언트를 안내하지 않습니다.
로컬 용량 확인: 충분한 건강한 서버가 없는 PoP로 클라이언트를 안내하지 않습니다.
중앙 용량 분산: 각 PoP의 현재 부하에 따라 클라이언트를 PoP 간에 균형있게 분산하고, 과부하가 걸린 PoP에서 트래픽을 제거합니다.
이 솔루션은 지리적으로 가까운 라우팅과 같은 NS1의 다른 기능과 함께 작동합니다. 이는 각 클라이언트를 가장 가까운 PoP로 안내합니다.
목차
1. NGINX Plus 에 대해
2. NS1 로드밸런싱 전제조건
3. NS1 설정
3-1. 레코드 정보 확인
4. NS1 에이전트 설치
4-1. NS1 에이전트 YAML 파일
5. NS1이 트래픽을 로드 밸런싱하는지 확인하기
5-1. NGINX Plus 인스턴스가 표시 중지된 경우 트래픽 로드 밸런싱 확인
5-2. NGINX Plus 업스트림 그룹이 다운된 경우 트래픽 로드 밸런싱 확인
5-3. 임계값 초과 시 로드 밸런싱 확인
5-3-1. NS1 임계값 테스트
1. NGINX Plus 에 대해
NGINX Plus는 NGINX 오픈소스의 상용 지원 버전입니다. NGINX Plus는 완전한 애플리케이션 전달 플랫폼으로, NGINX의 강력한 기능을 확장하여 대규모 웹 애플리케이션 구축에 필수적인 기능을 제공합니다.
- 완전한 기능을 갖춘 HTTP, TCP 및 UDP 로드 밸런싱
- 지능적인 세션 지속성
- 고성능 리버스 프록시
- 동적 및 정적 콘텐츠의 캐싱 및 오프로드
- 모든 기기에 오디오 및 비디오를 제공하기 위한 적응형 스트리밍
- 애플리케이션 인식 상태 확인 및 고가용성
- 대시보드 또는 API를 통한 Advanced Activity Monitoring
- DevOps 친화적인 도구를 사용한 관리 및 실시간 구성 변경
2. NS1 로드밸런싱 전제조건
- 등록된 도메인 이름
- NS1 계정
- NGINX Plus 인스턴스가 3개 이상 배포되어 있으며, 각 인스턴스에는 다음이 포함되어 있어야 합니다.
- NGINX Plus API가 활성화되어 있어야 합니다.
- Go 1.7 이상이 설치되어 있어야 합니다.
3. NS1 설정
1. NS1 계정에 로그인한 후, 제목 표시줄에서 ZONES 를 클릭하여 “Your Zones” 페이지를 엽니다. 그런 다음 오른쪽 상단에 있는 + Add Zone 버튼을 클릭하세요.
2. “Add Zone” 팝업 창에서 도메인 이름(이 가이드에서는 nginxgslb.cf)을 “Domain Name” 필드에 입력하세요. 기본 설정을 변경하지 않고 저장할 것이지만 TTL(생존 시간) 설정에 대한 정보는 NS1 문서를 참조하세요. “Save Zone” 버튼을 클릭하세요.
3. 열리는 페이지에서 NAMESERVERS 탭을 클릭하고, 새 도메인 이름을 NS1에 위임하기 위해 다음 지침을 따르세요.
4. RECORDS 탭을 클릭하세요. 스크린샷에 표시된 대로, NS (네임 서버) 레코드가 자동으로 생성되어 흰색 상자에 표시됩니다. Add Record 버튼 중 하나를 클릭하세요.
5. Add Record 창이 나타납니다. 다음 값을 입력하세요.
- Record Type – A (기본값)
- name – 서브도메인의 A 레코드를 생성하는 경우를 제외하고는 비워두세요.
- TTL – 3600이 기본값이며, 변경하지 않습니다.
- ANSWERS – 첫 번째 NGINX Plus 인스턴스의 공용 IP 주소를 입력하세요. 다른 인스턴스를 추가하려면 Add Answer 버튼을 클릭하세요. (이 포스트에서는 예시로 10.0.0.0/8 범위의 사설 IP 주소를 사용합니다.)
Save All Changes 버튼을 클릭하세요.
6. RECORDS 탭에 새로운 A 레코드가 나타납니다. 해당 행의 오른쪽 끝에 있는 3 Answers 버튼을 클릭하여 A 레코드의 세부 정보 페이지를 엽니다. (스크린샷 – 이 페이지와 세부 정보 페이지의 후속 스크린샷은 탭의 하단 절반만 표시됩니다.)
3-1. 레코드 정보 확인
7. 열리는 창에는 A 레코드의 세부 정보가 표시됩니다. NGINX Plus 인스턴스의 IP 주소는 그룹화되지 않은 답변 섹션에 나타납니다. 첫 번째 주소(이 가이드에서는 10.10.10.1)의 필드 오른쪽 끝에 있는 쌓인 점 아이콘을 클릭하고 “Edit Answer Metadata”를 선택하세요.
8. 팝업되는 “Answer Metadata” 창에서, SETTING 열의 STATUS 섹션에서 Up/down 을 선택하세요(이미 선택되어 있는 경우 제외). AVAILABLE 열의 Select 상자를 클릭한 다음, 드롭다운 메뉴에서 Up 또는 Down을 선택하세요. 이 가이드에서는 NGINX Plus 인스턴스가 작동 중임을 나타내기 위해 Up을 선택합니다.
9. SETTING 열의 GEOGRAPHICAL 섹션에서 값을 클릭하고 NGINX Plus 인스턴스의 위치를 지정하세요. NS1에서 위치를 식별하기 위해 제공하는 여러 유형의 코드 중 하나를 선택하세요:
- Canadian province(s) – 캐나다 주의 두 글자 코드
- Country/countries – 국가와 영토의 두 글자 코드
- Geographic region(s) – US-WEST 및 ASIAPAC와 같은 식별자
- ISO region code – ISO 3166에서 정의된 국가와 영토의 식별 코드
- Latitude – 위도의 도, 분, 초 (북반구 또는 남반구)
- Longitude – 경도의 도, 분, 초 (동반구 또는 서반구)
- US State(s) – 미국 주의 두 글자 코드
이 가이드에서는 Country/countries를 사용합니다. 첫 번째 NGINX Plus 인스턴스에서 Americas > Northern America > United States (US)를 선택하고 Ok 버튼을 클릭합니다.
10. 다른 두 개의 NGINX Plus 인스턴스에 대해서도 단계 7-9를 반복하세요. 단계 9에서 국가를 선택할 때, NGINX Plus 인스턴스 2에는 Europe > Western Europe > Germany (DE)를 선택하고, NGINX Plus 인스턴스 3에는 Asia > South-Eastern Asia > Singapore (SG)를 선택합니다.
두 인스턴스 모두 완료한 후, A 레코드의 세부 정보 페이지에서 Save Record 버튼을 클릭하세요.
11. Create Filter Chain 버튼을 클릭하여 Up/Down 및 Country/countries 메타데이터를 기반으로한 필터 체인을 생성하세요. (필터 체인에 대한 개요는 NS1 문서를 참조하세요)
12. 팝업 창에서 필터를 추가하기 위해 각 필터 버튼의 더하기 기호(+)를 클릭하세요. 이 가이드에서는 다음 순서로 필터를 구성합니다:
- HEALTHCHECKS 섹션에서 “_”(밑줄) 버튼의 더하기 기호(+)를 클릭하세요.
- GEOGRAPHIC 섹션에서 지리적 필터의 대상 국가를 선택하세요.
- TRAFFIC MANAGEMENT 섹션에서 “First N”을 선택하세요.
Save Filter Chain 버튼을 클릭하세요.
4. NS1 에이전트 설치
이 섹션에서는 NS1 에이전트를 NGINX Plus 인스턴스와 동일한 호스트에 설치하고 구성합니다. 또한, 각 에이전트에 대해 NS1 데이터 피드를 생성하여 NS1 API를 통해 해당 NGINX Plus 인스턴스의 상태 정보를 NS1로 전송할 수 있도록 설정합니다.
1. NS1 문서의 지침에 따라 각각의 세 개의 NGINX Plus 인스턴스에 대해 별도의 데이터 피드를 설정하고 연결하세요. NS1에서는 이를 “answers”라고 부릅니다.
첫 번째 페이지(Configure a new data source from NSONE Data Feed API v1)에서 데이터 소스의 이름을 지정하세요. 이는 생성할 데이터 피드의 관리 컨테이너입니다. 지침을 따를 때마다 동일한 이름을 사용하세요. 이 가이드에서는 데이터 소스를 NGINX-GSLB로 지정합니다.
다음 페이지(Create Feed from NSONE Data Feed API v1)에서 인스턴스에 대한 데이터 피드를 생성하세요. Name 필드는 내부적인 용도로 사용되므로 어떤 값이든 상관없습니다. Label 필드의 값은 인스턴스의 YAML 구성 파일에 사용됩니다(아래 단계 4 참조). 이 가이드에서는 인스턴스가 실행 중인 국가(ISO 3166 코드 사용)를 나타내는 레이블을 지정합니다.
- 미국에서 실행 중인 인스턴스 1의 경우 us-nginxgslb-datafeed
- 독일에서 실행 중인 인스턴스 2의 경우 de-nginxgslb-datafeed
- 싱가포르에서 실행 중인 인스턴스 3의 경우 sg-nginxgslb-datafeed
세 개의 피드를 생성한 후, INTEGRATIONS 탭에서 Feeds URL 필드의 값을 확인하세요. URL의 마지막 요소는 단계 4의 YAML 구성 파일에서 지정할 입니다. 예를 들어, NS1 문서의 세 번째 스크린샷에서는 e566332c5d22c6b66aeaa8837eae90ac입니다.
2. NS1 문서의 지침에 따라, 에이전트를 위한 NS1 API 키를 생성하세요(단계 1에서 Account Settings에 액세스하려면 NS1 제목 표시줄의 오른쪽 상단에 있는 사용자 이름을 클릭하세요). 이 가이드에서는 앱 이름을 NGINX-GSLB로 지정합니다. 키 값을 확인하세요 – 이를 단계 4의 YAML 구성 파일에서 로 지정할 것입니다. API Key 필드의 원본 16진수 값을 확인하려면 API Key 필드의 원형 문자 i를 클릭하세요.
3. 각 NGINX Plus 호스트에서 NS1 에이전트의 GitHub 리포지토리를 클론하세요.
4. 각 NGINX Plus 호스트에서 NS1 에이전트를 위한 YAML 구성 파일을 생성하세요. 이 가이드에서는 다음 파일을 사용합니다.
4-1. NS1 에이전트 YAML 파일
agent:
interval: 10
retry_time: 5
nginx_plus:
hosts:
- host: "127.0.0.1:8000"
resolve: false
host_header: "127.0.0.1:8000"
api_endpoint: "/api"
client_timeout: 10
nsone:
api_key: "<NS1-API-key>"
client_timeout: 10
source_id: "<NS1-data-source-ID>"
services:
method: "upstream_groups"
threshold: 2
sampling_type: "count"
feeds:
- name: "my_backend"
feed_name: "<xx>-nginxgslb-datafeed"hosts 섹션은 에이전트를 NGINX Plus 인스턴스와 동일한 호스트(이 가이드에서는 localhost)에서 실행하도록 구성합니다. localhost는 호스트 필드에서 IP 주소(127.0.0.1)로 식별되므로 호스트 이름 해석은 필요하지 않으며, resolve는 false로 설정됩니다. 에이전트는 NGINX Plus API(/api 엔드포인트)에서 8000 포트로부터 메트릭을 수집합니다.
nsone 섹션에서는 Step 2와 Step 1에서 확인한 및 값을 포함하세요.
services 섹션에서는 NS1 에이전트가 사용할 방법으로 upstream_groups를 지정합니다. 이는 NGINX Plus 인스턴스가 로드 밸런싱하는 업스트림 그룹에 대한 메트릭을 수집한다는 의미입니다. feeds 섹션의 name 필드에서 지정한 my_backend입니다. threshold 필드는 백엔드 앱이 up으로 간주되기 위해 업스트림 그룹에서 건강한 서버가 몇 개 필요한지를 정의하고, sampling_type 필드는 에이전트가 백엔드 서버로의 활성 연결 합계를 수집하도록 지시합니다. (백엔드 앱의 실제 설정 및 NGINX Plus 인스턴스의 구성 파일은 독자에게 맡깁니다.)
에이전트 구성은 각각의 연결된 에이전트와 NGINX Plus 인스턴스에 대해 동일하지만, feed_name 필드의 값(피드 이름은 단계 1 참조)만 다릅니다. 각 인스턴스에 대해 다른 업스트림 그룹을 구성하려는 경우 name 필드의 값도 변경하세요.
구성 파일의 모든 필드에 대한 자세한 내용은 GitHub 리포지토리의 문서를 참조하세요.
GitHub 리포지토리의 지침에 따라 에이전트를 시작하세요.
5. NS1이 트래픽을 로드 밸런싱하는지 확인하기
이 섹션에서는 클라이언트에 가장 가까운 PoP가 작동하지 않을 때 NS1이 트래픽을 대체 PoP로 올바르게 재분배하는지 확인하는 방법을 설명합니다(이 가이드의 설정에서 세 개의 NGINX Plus 인스턴스는 각각 하나의 PoP에 해당합니다). PoP가 다운되었음을 NS1에 알리는 방법은 세 가지가 있습니다:
- NS1 A 레코드에서 NGINX Plus 인스턴스의 상태를 Down으로 변경합니다.
- 프록시된 업스트림 그룹의 서버를 중지합니다.
- 트래픽이 구성된 임계값을 초과하도록 합니다.
5-1. NGINX Plus 인스턴스가 표시 중지된 경우 트래픽 로드 밸런싱 확인
여기에서는 가장 가까운 NGINX Plus 인스턴스의 메타데이터를 Down으로 변경할 때 NS1이 다음으로 가까운 NGINX Plus 인스턴스로 전환되는지 확인합니다.
1. 미국에 위치한 호스트에서 다음 명령을 실행하여 NS1이 가장 가까운 사이트로 반환하는지 확인하세요. 적절하게 10.10.10.1, 미국의 NGINX Plus 인스턴스의 IP 주소를 반환합니다.
$ nslookup nginxgslb.cf
Server: 10.10.100.102
Address: 10.10.100.102#53
Non-authoritative answer:
Name: nginxgslb.cf
Address: 10.10.10.12. US 인스턴스의 Up/Down 응답 메타데이터를 Down으로 변경하세요.
3. nginxgslb.cf의 A 레코드의 기본 TTL(3600초)을 변경하지 않았기 때문에 약 한 시간 동안 기다려야 합니다. 그리고 다시 nslookup 명령을 실행하세요. NS1은 이제 가장 가까운 독일의 NGINX Plus 인스턴스인 10.10.10.2를 반환합니다.
$ nslookup nginxgslb.cf
Server: 10.10.100.102
Address: 10.10.100.102#53
Non-authoritative answer:
Name: nginxgslb.cf
Address: 10.10.10.25-2. NGINX Plus 업스트림 그룹이 다운된 경우 트래픽 로드 밸런싱 확인
NGINX Plus 인스턴스(answers)가 NS1 데이터 피드에 연결되었으므로, 에이전트로부터 상위 그룹이 다운되었음을 나타내는 데이터를 받을 때 NS1이 트래픽을 올바르게 재분배하는지 확인할 수 있습니다. 다음 예제에서는 us-nginxgslb-datafeed 피드에서 보고된 대로 my_backend 그룹이 다운됩니다.
다음 명령을 US에 위치한 호스트에서 실행합니다.
1. US의 NGINX Plus 인스턴스가 프록시하는 my_backend 업스트림 그룹의 현재 상태가 up인지 확인하기 위해 NGINX Plus API에 쿼리하세요.
$ curl -X GET "127.0.0.1:8000/api/<version>/http/upstreams/my_backend/" -H "accept: application/json" | python -m json.tool | grep state
"state": "up",2. NS1 API에 쿼리하여 NS1도 US의 my_backend 업스트림 그룹을 up으로 인식하는지 확인하세요. (이 API 호출에 대한 자세한 내용은 NS1 문서를 참조하세요. 페이지가 해당 섹션으로 자동으로 스크롤되지 않으면 “Get active data feeds for a source”를 검색하세요.)
명령줄에서 와 는 NS1 에이전트 설치의 단계 4에서 YAML 파일에 포함한 값과 동일합니다.
출력에는 각 데이터 피드에 대한 destinations 항목이 포함되어 있으므로, label 필드가 us-nginxgslb-datafeed인 항목을 찾고 해당 항목의 up 필드가 true인지 확인하세요.
$ curl -X GET -H 'X-NSONE-Key: <NS1-API-key>' https://api.nsone.net/v1/data/feeds/<NS1-data-source-ID> | python -m json.tool
[
...
{
"destinations": [
{
"destid": "<Answer-ID>",
"desttype": "answer",
"record": "<Record-ID>"
}
],
"id": "<Feed-ID>",
"data": {
"up": "true"
},
"config": {
"label": "us-nginxgslb-datafeed"
},
"name": "us-nginxgslb-datafeed"
},
...
]3. US 호스트에 대해 NS1이 반환하는 사이트를 확인하세요. 적절하게도, 미국 기반 NGINX Plus 인스턴스의 IP 주소인 10.10.10.1을 반환합니다.
$ nslookup nginxgslb.cf
Server: 10.10.100.102
Address: 10.10.100.102#53
Non-authoritative answer:
Name: nginxgslb.cf
Address: 10.10.10.14. my_backend 업스트림 그룹의 서버를 중지하세요. 이를 위해 여러 가지 방법이 있습니다: 각 서버에서 실제 앱을 중지하거나, NGINX Plus 인스턴스에서 앱의 포트 번호를 잘못된 값으로 변경하거나, server 지시문이나 NGINX Plus API를 사용하여 각 서버의 상태를 Down으로 설정할 수 있습니다.
5. 단계 1을 반복하세요. 이제 NGINX Plus API에서 상태를 unhealthy으로 보고합니다.
$ curl -X GET "127.0.0.1:8000/api/<version>/http/upstreams/my_backend/" -H "accept: application/json" | python -m json.tool | grep state
"state": "unhealthy",6. 단계 2를 반복하세요. 이제 NS1 API에서 up 필드에 false를 반환합니다.
$ curl -X GET -H 'X-NSONE-Key: <NS1-API-key>' https://api.nsone.net/v1/data/feeds/<NS1-data-source-ID> | python -m json.tool
[
...
{
"destinations": [
{
"destid": "<Answer-ID>",
"desttype": "answer",
"record": "<Record-ID>"
}
],
"id": "<Feed-ID>",
"data": {
"up": "false"
},
"config": {
"label": "us-nginxgslb-datafeed"
},
"name": "us-nginxgslb-datafeed"
},
...
]7. nginxgslb.cf의 A 레코드의 기본 TTL(3600초)을 변경하지 않았기 때문에 약 한 시간 정도 기다리세요.
그리고 단계 3을 반복하세요. NS1은 이제 US 기반 호스트에 가장 가까운 독일의 NGINX Plus 인스턴스인 10.10.10.2를 반환합니다.
$ nslookup nginxgslb.cf
Server: 10.10.100.102
Address: 10.10.100.102#53
Non-authoritative answer:
Name: nginxgslb.cf
Address: 10.10.10.25-3. 임계값 초과 시 로드 밸런싱 확인
특정 NGINX Plus 인스턴스의 부하 메트릭이 설정한 하나 이상의 임계값을 초과할 때 NS1이 트래픽을 해당 인스턴스에서 분산시키도록 NS1을 구성할 수 있습니다. 이 임계값은 NS1 shed 필터에 설정됩니다. NS1은 현재 IP 주소에서 다른 IP 주소로 트래픽을 “shedding load”라고 설명하고 있습니다.
여기에서는 인스턴스의 활성 연결 수가 설정한 임계값을 초과할 때 NS1이 트래픽을 올바르게 재분배하는지 확인합니다.
Shed 필터 생성
먼저 다음 단계를 수행하여 shed 필터를 생성합니다:
1. ZONES 탭에서 nginxgslb.cf의 A 레코드의 세부 정보 페이지로 이동합니다(이미 열려 있지 않은 경우). Edit Filter Chain 버튼을 클릭하세요.
2. 열리는 “Add Filters” 창에서 HEALTHCHECKS 섹션의 “Shed Load” 상자의 더하기 기호(+)를 클릭하세요.
3. “Shed Load” 필터가 Active Filters 섹션에서 네 번째(가장 낮은) 상자로 추가됩니다. 이를 위해 해당 상자를 클릭하고 드래그하여 “Select First N” 상자 위로 이동하세요.
4. Save Filter Chain 버튼을 클릭하세요.
5. A 레코드의 세부 정보 페이지로 돌아가서, Filter Chain 열에서 “Shed Load” 상자를 클릭하면 해당 필터가 확장되어 필터의 작동 방식에 대한 설명이 표시됩니다. 설명의 하단에 있는 흰색 상자의 레이블을 클릭하고 드롭다운 메뉴에서 “Active connections”를 선택하세요.
6. Ungrouped Answers 섹션에서 US 기반 NGINX Plus 인스턴스(10.10.10.1)에 대한 필드 오른쪽 끝에 있는 쌓인 점 아이콘을 클릭하고 “Edit Answer Metadata”를 선택하세요.
7. 열리는 “Answer Metadata” 창에서 다음 메타데이터에 대한 값을 설정하세요. 각 경우에 대해 메타데이터 행의 FEED 열에 있는 아이콘을 클릭한 다음, AVAILABLE 열에 지정된 값을 선택하거나 입력하세요. (테스트 목적으로 임계값이 매우 빠르게 초과되도록 매우 작은 값을 설정합니다.)
- Active connections – us-nginxgslb-datafeed
- High watermark – 5
- Low watermark – 2
세 개의 값을 모두 설정한 후, Ok 버튼을 클릭하세요. (스크린샷은 이 작업 직전의 창을 보여줍니다.)
5-3-1. NS1 임계값 테스트
shed 필터가 준비되었으므로, 가장 가까운 인스턴스의 활성 연결 수가 상위 임계값인 5를 초과할 때 NS1이 다음으로 가까운 NGINX Plus 인스턴스로 트래픽을 전환하는지 확인할 준비가 되었습니다. 바로 위의 단계 7에서 언급한 대로 매우 작은 값을 설정하여 초과되었을 때 효과를 빠르게 확인할 수 있습니다. 하위 임계값인 2로 설정되어 있으므로, 세 개의 활성 연결이 있을 때 NS1은 확률적으로 트래픽을 전환하고, 다섯 개 이상의 연결이 있을 때는 확실히 트래픽을 전환합니다.
우리는 네 개 이상의 동시 연결을 지속적으로 시뮬레이션하는 스크립트를 작성했습니다. 또한, 연결이 닫히기 전에 에이전트가 NS1에 활성 연결 수를 보고할 충분한 시간 동안 연결이 유지되도록 백엔드 앱을 구성했습니다.
US에 위치한 호스트에서 다음 명령을 실행합니다.
1. NGINX Plus API에 Active 연결 수를 조회하세요.
$ curl -X GET "127.0.0.1:8000/api/<version>/connections" -H "accept: application/json" | python -m json.tool | grep active
"active": 1,2. NS1 API에 쿼리하여 NS1 에이전트가 NS1에 보고한 활성 연결 수를 확인하세요. (이 API 호출에 대한 자세한 내용은 NS1 문서를 참조하세요. 페이지가 해당 섹션으로 자동으로 스크롤되지 않으면 “Get data feed details”를 검색하세요.)
명령줄에서 다음을 실행하세요.
<NS1-API-key>와<NS1-data-source-ID>는 4. NS1 에이전트 설치의 단계 4에서 YAML 파일에 포함한 값이며, 5-2. NGINX Plus 업스트림 그룹이 다운된 경우 트래픽 로드 밸런싱 확인의 단계 2에서 사용한 값입니다.<NS1-feed-ID>는 NS1이 us-nginxgslb-datafeed 데이터 피드에 할당한 ID입니다. 5-2. NGINX Plus 업스트림 그룹이 다운된 경우 트래픽 로드 밸런싱 확인 의 단계 2에서 출력의id필드로 보고되었습니다. (다음 출력에서도 해당 필드에 표시됩니다.)
출력의 관련 필드는 데이터 섹션의 connections입니다. 이 예제에서는 활성 연결이 하나 있음을 나타냅니다.
$ curl -X GET -H 'X-NSONE-Key: <NS1-API-key>' https://api.nsone.net/v1/data/feeds/<NS1-data-source-ID>/<NS1-feed-ID> | python -m json.tool
{
"config": {
"label": "us-nginxgslb-datafeed"
},
"data": {
"connections": 1,
"up": true
},
"destinations": [
{
"destid": "<Answer-ID>",
"desttype": "answer",
"record": "<Record-ID>"
}
],
"id": "<Feed-ID>",
"name": "us-nginxgslb-datafeed",
"networks": [
0
]
}3. US의 호스트에 대해 NS1이 반환하는 사이트를 확인하세요. 적절하게도, 미국 기반 NGINX Plus 인스턴스의 IP 주소인 10.10.10.1을 반환합니다.
$ nslookup nginxgslb.cf
Server: 10.10.100.102
Address: 10.10.100.102#53
Non-authoritative answer:
Name: nginxgslb.cf
Address: 10.10.10.14. NGINX Plus 인스턴스에 다섯 개 이상의 connections을 생성하세요. 이를 위해 이 섹션의 소개에서 언급한 스크립트를 실행하세요.
5. 단계 1을 반복하세요. 이제 NGINX Plus API에서는 다섯 개의 Active 연결을 보고합니다.
$ curl -X GET "127.0.0.1:8000/api/<version>/connections" -H "accept: application/json" | python -m json.tool | grep active
"active": 5,6. 단계 2를 반복하세요. NS1 API에서도 다섯 개의 Active Connection을 보고합니다.
$ curl -X GET -H 'X-NSONE-Key: <NS1-API-key>' https://api.nsone.net/v1/data/feeds/<NS1-data-source-ID>/<NS1-feed-ID> | python -m json.tool
{
"config": {
"label": "us-nginxgslb-datafeed"
},
"data": {
"connections": 5,
"up": true
},
...
}7. nginxgslb.cf의 A 레코드의 기본 TTL(3600초)을 변경하지 않았기 때문에 약 한 시간 정도 기다려야 합니다. 그리고 단계 3을 반복하세요. NS1은 이제 미국의 인스턴스에 너무 많은 Active Connection이 있으므로 독일의 NGINX Plus 인스턴스인 10.10.10.2를 반환합니다. 이는 현재 가장 가까운 인스턴스입니다.
$ nslookup nginxgslb.cf
Server: 10.10.100.102
Address: 10.10.100.102#53
Non-authoritative answer:
Name: nginxgslb.cf
Address: 10.10.10.2NS1 및 NGINX Plus 를 통해 Global Server 로드 밸런싱을 구현하려면 지금 NGINX Plus의 30일 무료 평가판을 시작하거나 사용 사례에 대해 NGINX STORE에 문의해보세요.
아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.
댓글을 달려면 로그인해야 합니다.