NGINX Plus 로 백엔드 업그레이드, 3부 앱 버전

이것은 NGINX Plus를 사용하여 중단 시간 없이 백엔드 서버를 업그레이드 하는 방법에 대한 시리즈의 세 포스트 중 마지막 포스트입니다. 첫 번째 포스트에서는 다운타임 없이 백엔드 업그레이드에 사용할 수 있는 두 가지 NGINX Plus 기능(NGINX Plus API 및 애플리케이션 상태 확인)에 대해 설명하고 각 방법의 이점에 대해 설명합니다.

이 세 번째 포스트에서는 upstream 서버 그룹에서 애플리케이션 버전을 업그레이드 하는 몇 가지 사용 사례를 다룹니다. 개별 서버 시스템에서 소프트웨어 또는 하드웨어를 업그레이드 하는 것과 관련된 사용 사례는 두 번째 문서 NGINX Plus 로 백엔드 업그레이드, 2부 개별 서버를 참조하세요.

애플리케이션을 실행하기 위해 새로운 서버 세트를 추가하여 애플리케이션의 새 버전으로 전환할 때 이전 버전의 서버를 오프라인으로 전환하고 새 버전의 서버를 온라인으로 전환하는 제어된 방법이 필요합니다. 이를 달성하기 위한 여러 가지 방법을 살펴보고 그 중에서 선택하는 데 도움이 되는 몇 가지 요소가 있습니다.

업그레이드 전후에 동일한 upstream 그룹을 사용하시겠습니까, 아니면 새 버전에 대해 새 upstream 그룹을 생성하시겠습니까?

전환하는 동안 짧은 시간 동안 클라이언트가 이전 버전과 새 버전 모두에 액세스할 수 있습니까? 여러 사용 사례에서 서버 가중치를 사용하여 버전 중복을 최소화합니다. 특히 중첩이 허용되지 않는 경우 NGINX Plus API 사용을 참조하십시오.

[참고 – 이 문서는 upstream 그룹의 실시간 활동 모니터링 및 동적 구성에 NGINX Plus API를 사용하도록 업데이트되어 원래 사용되었던 별도의 Status 및 Upstream Conf API를 대체합니다.]

목차

1. NGINX Plus 사용 사례의 기본 구성
2. 단일 Upstream 그룹 사용
2-1. 중복이 허용되는 경우 NGINX Plus API 사용
2-2. 중첩이 허용되지 않는 경우 NGINX Plus API 사용
2-3. Semaphore Health Checks 사용
2-4. health check에서 버전 번호 사용
3. 새 Upstream 그룹 사용
3-1. 간단한 cutover 작업
3-2. Canary Release 수행
3-3. 출시 일정
3-4. 클라이언트 IP 주소를 기반으로 새 버전에 대한 액세스 제어
4. 결론

1. NGINX Plus 사용 사례의 기본 구성

NGINX Plus API 예제의 경우 NGINX Plus 인스턴스에서 API 호출을 수행하므로 localhost로 전송됩니다.

사용 사례의 기본 구성은 demoapp이라는 단일 upstream 구성 블록에 있는 두 개의 서버로 시작합니다. 첫 번째 server 구성 블록에서는 demoapp upstream 그룹에 대한 모든 요청의 부하를 분산하는 포트 80에서 수신 대기하는 가상 서버를 구성합니다.

백엔드 서버 오류가 사용자 경험에 미치는 영향을 줄이고 모니터링을 개선하기 위한 모범 사례인 애플리케이션 상태 확인을 구성하고 있습니다. 여기서는 서버가 HTTP 2xx 또는 3xx 응답 코드(상태 확인의 기본 성공 기준)와 함께 healthcheck.html 파일을 반환하는 경우 성공하도록 상태 확인을 구성합니다.

기본 상태 확인에 꼭 필요한 것은 아니지만 health_check 지시문을 자체 location 블록에 넣습니다. 이는 상태 확인과 일반 트래픽에 대해 시간 제한 및 헤더와 같은 다른 설정을 구성할 수 있으므로 좋은 방법입니다. health_check 지시문에 대한 별도의 location이 필요한 사용 사례는 Canary Release 수행을 참조하십시오.

# In the HTTP context 
upstream demoapp {
    zone demoapp 64k;
    server 172.16.210.81:80;
    server 172.16.210.82:80;
}

server {
    listen 80;
    status_zone demoapp;

    location / {
        proxy_pass http://demoapp;
    }

    location @healthcheck {
        internal;
        proxy_pass http://demoapp;
        health_check uri=/healthcheck.html;
    }
}

또한 NGINX Plus API(/api) 및 NGINX Plus 상태 대시보드(/dashboard.html)에 해당하는 location에 대한 요청에 대해 포트 8080에서 수신 대기하는 두 번째 가상 서버를 구성합니다. 이러한 location 이름은 일반적인 이름이지만 원하는 경우 다른 이름을 선택할 수 있습니다.

NGINX Plus API 및 대시보드에 대한 모든 트래픽을 보호하는 것이 가장 좋습니다. 여기서는 192.168.100.0에서 192.168.100.255 범위의 내부 IP 주소에 있는 사용자에게만 액세스 권한을 부여합니다. 더 강력한 보안을 위해 클라이언트 인증서, HTTP 기본 인증 또는 인증 요청 모듈을 사용하여 LDAP와 같은 외부 인증 시스템과 통합하십시오.

# In the HTTP context
server {
    listen 8080;
    allow 192.168.100.0/24;
    deny all;

    location /api {
        api write=on;
    }   

    location = /dashboard.html {
        root /usr/share/nginx/html;
    }

    # Redirect requests made to the pre-NGINX Plus R14 dashboard
    location = /status.html {
        return 301 /dashboard.html;
    }
}

이 구성을 사용하면 이 문서의 API 명령에 대한 기본 URL은 다음과 같습니다.

http://localhost:8080/api/3/http/upstreams/demoapp/servers

2. 단일 Upstream 그룹 사용

단일 upstream 그룹을 사용하는 경우 NGINX Plus는 새 애플리케이션 버전에 대한 요청을 이전 버전과 동일한 upstream 그룹에 전달합니다. 한 가지 장점은 업그레이드 프로세스 전체에서 동일한 upstream 그룹 이름을 계속 모니터링할 수 있다는 것입니다. 단일 upstream으로 업그레이드 하는 방법에는 몇 가지가 있습니다.

• 이전 서버와 새 서버 간의 중복이 허용되는 경우
• 이전 서버와 새 서버 간의 중복이 허용되지 않는 경우
• semaphore health checks 사용
• health check에서 버전 번호 사용

2-1. 중복이 허용되는 경우 NGINX Plus API 사용

클라이언트가 짧은 시간 동안 애플리케이션의 두 버전 중 하나에 도달하는 것이 허용되는 경우 다음 단계를 따릅니다.

1. 각 서버에 대해 POST 메소드를 사용하여 curl 명령을 전송하여 upstream 그룹에 새 서버를 추가합니다. 기본적으로 클라이언트는 즉시 액세스할 수 있지만 온라인 상태로 전환할 준비가 될 때까지 down 매개변수를 true로 설정할 수 있습니다. 이때 매개변수를 false로 설정하는 명령을 실행합니다.

이 예에서는 새 애플리케이션 버전을 실행하는 두 개의 서버를 추가합니다.

$ curl -X POST -d '{"server":"172.16.211.83:80","down":true}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/
$ curl -X POST -d '{"server":"172.16.211.84:80","down":true}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/

2. 이 명령을 실행하여 새 서버와 이전 서버에 할당된 내부 ID를 확인합니다(jq 유틸리티로 출력을 필터링하여 각 서버의 호스트 이름 또는 IP 주소 및 ID만 표시).

$ curl -s http://localhost:8080/api/3/http/upstreams/demoapp/servers/ | jq -c '.peers[] | {server, id}'
{"server":"172.16.210.81:80","id":0}
{"server":"172.16.210.82:80","id":1}
{"server":"172.16.210.83:80","id":2}
{"server":"172.16.210.84:80","id":3}

3. 새 서버를 작동으로 표시하고 이전 서버를 작동 중지로 표시하여 ID로 식별합니다.

$ curl -X PATCH -d '{"down":false}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/2
$ curl -X PATCH -d '{"down":false}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/3
$ curl -X PATCH -d '{"down":true}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X PATCH -d '{"down":true}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

4. 이전 서버를 모니터링하고 연결 수가 0이면 upstream 그룹에서 제거합니다.

$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

2-2. 중첩이 허용되지 않는 경우 NGINX Plus API 사용

업그레이드 중에 클라이언트가 이전 서버와 새 서버 모두에 도달하는 것이 허용되지 않는 경우 이를 방지하는 한 가지 방법은 API 요청을 역순으로 전송하여 먼저 이전 서버를 다운으로 표시한 다음 새 서버를 추가하는 것입니다. 그러나 이 접근 방식에는 두 가지 단점이 있습니다.

• 마지막 이전 서버가 다운된 시간과 첫 번째 새 서버가 추가된 시간 사이에 사용 가능한 서버가 없으며 클라이언트 요청이 오류와 함께 거부됩니다.
• 이전 서버를 다운된 것으로 표시하면 용량이 줄어듭니다. 시스템에 과부하가 걸리면 부하를 처리할 수 없어 모든 새 서버가 온라인 상태가 될 때까지 오류가 발생할 수 있습니다.

이러한 단점을 극복하기 위해 우리는 서버 가중치를 사용하여 이전 서버가 여전히 실행 중인 경우에도 요청을 줄이고 제거할 수 있습니다. 가중치에 대한 자세한 내용은 블로그에서 NGINX Plus 로드 밸런싱 기술 선택을 참조하세요.

이전 섹션에서와 같이 이전 서버를 중단하고 오프라인으로 전환하기 전에 여전히 새 서버를 가동하지만 이전 서버를 중단하기 전에 이전 서버가 요청을 받을 가능성이 거의 없도록 새 서버에 매우 높은 가중치를 설정했습니다. 이전 서버에 아직 기본 가중치 1이 없는 경우 가중치를 해당 값으로 재설정하는 것으로 시작합니다.

다음 명령은 이전 섹션과 동일한 서버 ID 번호를 사용합니다.

1. 아직 값이 아닌 경우 현재(이전) 서버의 가중치를 다시 기본값인 1로 설정합니다.

$ curl -X PATCH -d '{"weight":1}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X PATCH -d '{"weight":1}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

2. 작동 중지 상태에서 추가되는 새 서버의 가중치를 매우 높은 값으로 설정합니다.

$ curl -X POST -d '{"server":"172.16.211.83:80","down":true,"weight":100000}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/
$ curl -X POST -d '{"server":"172.16.211.84:80","down":true,"weight":100000}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/

3. 새 서버를 작동으로 표시하고 이전 서버를 작동 중지로 표시하여 ID로 식별합니다.

$ curl -X PATCH -d '{"down":false}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/2
$ curl -X PATCH -d '{"down":false}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/3
$ curl -X PATCH -d '{"down":true}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X PATCH -d '{"down":true}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

4. 이전 서버를 모니터링하고 연결 수가 0이면 upstream 그룹에서 제거합니다.

$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

5. 새 서버의 가중치를 더 낮은 값으로 설정하십시오. 다음 명령은 용량이 같다고 가정하고 각각의 가중치를 1로 반환합니다.

$ curl -X PATCH -d '{"weight":1}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/2
$ curl -X PATCH -d '{"weight":1}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/3

2-3. Semaphore Health Checks 사용

upstream 그룹을 관리하는 가장 깨끗하고 효율적인 방법으로 NGINX Plus API를 권장하지만 기존 인프라는 이미 이를 위해 health check에 의존하고 있을 수 있습니다. 다음은 health check를 사용하여 중복 없이 이전 서버 세트에서 새 세트로 전환하는 방법입니다. healthcheck.html이라는 파일의 존재 또는 부재로 인해 상태 검사가 각각 성공하거나 실패한다고 가정합니다.

다음 단계에서는 NGINX Plus API를 사용하여 upstream 서버를 변경(추가 및 제거, 가중치 설정)하지만 NGINX Plus 대시보드를 사용하거나 구성 파일을 수동으로 편집하고 다시 로드할 수도 있습니다.

1. 새 서버를 upstream 그룹에 추가하기 전에 각 서버의 상태 확인 파일 이름을 변경하여(예: fail-healthcheck.html로) 새 서버가 추가될 때 상태 확인에 실패하고 NGINX Plus에서 제거하도록 합니다. 로드 밸런싱 순환.

2. 현재(이전) 서버의 가중치를 매우 높은 값으로 설정합니다.

기본적으로 NGINX Plus는 새로 추가된 서버로 트래픽 전송을 즉시 시작합니다. 또한 즉시 상태 확인을 보내지만 시스템의 부하가 높고 모든 서버의 가중치가 동일한 경우 NGINX Plus는 상태 확인을 완료하는 데 걸리는 시간 동안 새 서버에 요청을 보낼 수 있습니다. 이전 서버에 높은 가중치를 설정하고 새 서버에 대한 가중치를 기본값 1로 유지함으로써 새 서버가 추가될 때 대부분의 트래픽을 새 서버에서 전환합니다. 이전 서버에 설정하는 적절한 가중치는 로드 양에 따라 다르며 테스트를 통해 찾을 수 있습니다.

$ curl -X PATCH -d '{"weight":100000}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X PATCH -d '{"weight":100000}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

3. 새 서버를 추가하고 NGINX Plus 대시보드 또는 NGINX Plus API를 사용하여 트래픽을 수신하고 있지 않은지 확인합니다(fail-healthcheck.html 파일이 해당 서버를 비정상으로 표시하기 때문).

$ curl -X POST -d '{"server":"172.16.211.83:80"}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/
$ curl -X POST -d '{"server":"172.16.211.84:80"}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/

4. 현재(이전) 서버의 가중치를 다시 이전 값으로 줄입니다.

$ curl -X PATCH -d '{"weight":previous-value}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X PATCH -d '{"weight":previous-value}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

5. 새 서버의 가중치를 매우 높은 값으로 설정하십시오.

$ curl -X PATCH -d '{"weight":100000}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/2
$ curl -X PATCH -d '{"weight":100000}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/3

6. 상태 확인을 통과하고 트래픽 수신을 시작하도록 새 서버의 상태 확인 파일 이름을 healthcheck.html로 바꿉니다. 이전 서버에 비해 가중치가 너무 높기 때문에 NGINX Plus는 대부분의 트래픽을 여기에 보냅니다.

7. 상태 확인에 실패하도록 이전 서버의 상태 확인 파일 이름을 fail-healthcheck.html로 바꿉니다.

8. 이전 서버에 활성 연결이 없으면(NGINX Plus 대시보드 또는 NGINX Plus API로 확인) upstream 그룹에서 제거할 수 있습니다.

$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

9. 새 서버의 가중치를 정상 값으로 줄입니다(여기서는 기본값 1 사용).

$ curl -X PATCH -d '{"weight":1}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/2
$ curl -X PATCH -d '{"weight":1}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/3

2-4. health check에서 버전 번호 사용

지금까지 우리는 성공적인 상태 확인을 위한 기본 기준(리소스가 상태 코드 2xx 또는 3xx와 함께 반환됨)에 의존해 왔지만 성공하기 위해 다른 많은 종류의 추가 또는 대체 요구 사항을 정의할 수 있습니다.

이 기능을 활용하여 서버에서 반환된 페이지 본문에 특정 버전 번호를 요구함으로써 새 애플리케이션 버전으로의 업그레이드를 제어할 것입니다. 이 예에서는 버전 1.0에서 버전 2.0으로 업그레이드할 때 성공 기준으로 문자열 버전: x.0을 사용하지만 원하는 텍스트 문자열을 정의할 수 있습니다.

먼저 http 컨텍스트에 match 구성 블록을 추가하여 성공적인 상태 확인을 위한 두 가지 기준을 정의합니다. 서버는 상태 200의 페이지를 반환하고 페이지에는 버전: 1.0이라는 문자열이 포함됩니다.

# In the HTTP context
match matchstring {
    status 200;
    body ~ "Version: 1.0";
}

또한 일치 조건을 참조하도록 첫 번째 server 블록의 health_check 지시문을 수정합니다.

# In the first server block
location @healthcheck {
    internal;
    proxy_pass http://demoapp;
    health_check uri=/healthcheck.html match=matchstring;
}

구성을 즉시 다시 로드하지 않고 대신 다음 절차의 두 번째 단계로 다시 로드합니다. 다른 사용 사례와 마찬가지로 NGINX Plus API를 사용하여 upstream 서버를 수정하고 있지만 대신 NGINX Plus 대시보드를 사용하거나 구성을 수동으로 편집하고 다시 로드할 수 있습니다.

1. 각 현재(이전) 서버의 healthcheck.html 파일에서 버전 문자열을 버전: 1.0으로 설정합니다.

2. 구성을 다시 로드합니다.

$ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ nginx -s reload

3. 새 서버를 upstream 그룹에 추가하기 전에 각 서버의 healthcheck.html 파일에서 버전 문자열을 버전: 2.0으로 설정하여 새 서버가 추가될 때 health check에 실패하고 NGINX Plus가 로드 밸런싱 회전에서 제외합니다.

4. upstream 그룹에 새 서버를 추가합니다.

$ curl -X POST -d '{"server":"172.16.211.83:80"}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/
$ curl -X POST -d '{"server":"172.16.211.84:80"}' http://localhost:8080/api/3/http/upstreams/demoapp/servers/

5. 업그레이드할 준비가 되면 일치 블록의 문자열을 버전: 2.0으로 변경합니다.

# In the HTTP context
match matchstring {
    status 200;
    body ~ "Version: 2.0";
}

6. 구성을 다시 로드합니다. 새 서버는 이제 상태 확인을 통과하지만 이전 서버는 실패합니다.

$ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ nginx -s reload

7. 이전 서버에 활성 연결이 없으면(NGINX Plus 대시보드 또는 NGINX Plus API로 확인됨) upstream 그룹에서 제거합니다.

$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/0
$ curl -X DELETE http://localhost:8080/api/3/http/upstreams/demoapp/servers/1

이전 서버가 상태 확인에 실패할 때까지 잠시 동안 클라이언트 요청을 이전 서버나 새 서버로 보낼 수 있습니다. 새 서버에 대한 요청 분배를 왜곡하려면 4단계에서 새 서버에 높은 가중치를 설정하고 아직 낮지 않은 경우 이전 서버에 낮은 가중치를 설정합니다. 5단계 후에 새 서버의 가중치를 적절한 값으로 줄입니다. 가중치 설정에 대한 자세한 지침은 이전 섹션인 Semaphore Health Checks 사용을 참조하십시오.

3. 새 Upstream 그룹 사용

이제 새 서버에 대해 새 upstream 그룹을 활용하는 옵션을 살펴봅니다. 단일 upstream 그룹에 비해 더 많은 유연성을 얻고 동시에 모든 새 서버로 전환할 수 있습니다. 단점은 모니터링 도구를 재구성하여 새 upstream 그룹으로 안내해야 한다는 것입니다. 다시 말하지만 선택할 수 있는 몇 가지 접근 방식이 있습니다.

• 간단한 cutover 작업
• Canary Release 수행
• 출시 일정
• 클라이언트 IP 주소를 기반으로 새 애플리케이션에 대한 액세스 제어

3-1. 간단한 cutover 작업

모니터링할 서버를 변경해야 하는 경우를 제외하면 cutover는 확실히 새 애플리케이션 버전으로 마이그레이션하는 가장 깔끔한 방법입니다.

1. 업그레이드 사용 사례를 위해 기본 구성에서 생성한 구성을 편집하여 새 애플리케이션 버전을 실행하는 서버의 새로운 upstream 그룹(demoapp‑v2)을 생성합니다.

# In the HTTP context
upstream demoapp {
    zone demoapp 64k;
    server 172.16.210.81:80;
    server 172.16.210.82:80;
}

upstream demoapp-v2 {
    zone demoapp-v2 64k;
    server 172.16.210.83:80;
    server 172.16.210.84:80;
}

2. 새 upstream 그룹(demoapp-v2)을 가리키도록 첫 번째 server 블록의 status_zone 및 proxy_pass 지시문을 변경합니다.

# In the HTTP context
server {
    listen 80;
    status_zone demoapp-v2;

    location / {
        proxy_pass http://demoapp-v2;
    }

    location @healthcheck {
        internal;
        proxy_pass http://demoapp-v2;
        health_check uri=/healthcheck.html match=matchstring;
    }
}

3. 구성을 다시 로드합니다. NGINX Plus는 즉시 클라이언트 트래픽을 새 서버로 전달하기 시작합니다.

$ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ nginx -s reload

4. 이전 서버에 더 이상 활성 연결이 없으면 오프라인으로 전환하고 선택적으로 구성에서 upstream 그룹을 제거합니다.

3-2. Canary Release 수행

경우에 따라 소규모 사용자 집합에서 애플리케이션의 새 버전을 테스트하여 프로덕션에서 성능을 확인한 다음 모든 트래픽이 새 서버로 이동할 때까지 점진적으로 새 서버에 대한 트래픽 비율을 높이는 것이 가장 안전합니다. 이 방법을 일반적으로 Canary Release 또는 다크 런치라고 합니다. (“Canary Release”는 광부가 영향을 받기 전에 위험한 가스의 존재를 감지하기 위해 Canary를 탄광으로 가져가는 오래된 광업 관행을 의미합니다. 이 맥락에서 새 서버로 이동하는 사용자는 Canary입니다.) NGINX Plus(및 NGINX)의 ‘클라이언트 분할’ 기능은 이에 적합합니다.

split_clients 구성 블록은 고정된 비율의 트래픽을 다른 upstream 그룹으로 보냅니다. 이 예에서는 들어오는 요청의 5%를 새 upstream 그룹으로 보내는 것으로 시작합니다. 모든 것이 순조롭게 진행되면 10%, 20% 등으로 늘릴 수 있습니다. 새 버전으로 완전히 이동하는 것이 안전하다고 판단되면 split_clients 블록을 제거하고 새 upstream 그룹을 가리키도록 proxy_pass 지시문을 변경하기만 하면 됩니다.

이 방법은 NGINX Plus가 특정 클라이언트에서 클라이언트의 첫 번째 요청을 처리한 동일한 서버로 트래픽을 보내야 하는 세션 지속성과 호환되지 않습니다. split_clients 지시문은 소스를 고려하지 않고 엄격한 비율의 트래픽을 각 upstream 그룹으로 보내므로 올바른 서버를 포함하지 않는 upstream 그룹에 클라이언트 요청을 보낼 수 있습니다.

1. 새 애플리케이션 버전에 대한 새 upstream 그룹인 demoapp-v2를 만듭니다(이전 섹션에서와 같이).

# In the HTTP context
upstream demoapp {
    zone demoapp 64K;
    server 172.16.210.81:80 slow_start=30s;
    server 172.16.210.82:80 slow_start=30s;
}

upstream demoapp-v2 {
    zone demoapp-v2 64K;
    server 172.16.210.83:80 slow_start=30s;
    server 172.16.210.84:80 slow_start=30s;
}

2. 업그레이드 사용 사례를 위해 기본 구성에서 생성한 첫 번째 server 블록에서, demoapp와 같은 리터럴 대신 upstream 그룹 이름을 나타내는 변수를 사용하도록 proxy_pass 블록을 변경합니다(변수는 split_clients 블록에서 설정됩니다. 다음 단계).

# In the first server block
location / {
    proxy_pass http://$app_upstream;
}

3. http 컨텍스트에 split_clients 블록을 추가합니다. 여기에서 NGINX Plus에 $app_upstream 변수를 수신 요청의 5%에 대해 demoapp-v2로 설정하고 나머지 모든 요청에 대해 demoapp으로 설정하도록 지시합니다. 변수 값은 요청이 전달되는 upstream 그룹을 결정하기 위해 proxy_pass 지시문(2단계에서 정의됨)에 전달됩니다.

split_clients의 첫 번째 매개변수는 요청이 분산되는 방식을 결정하기 위해 해시되는 요청 특성, 여기서는 클라이언트 IP 주소($remote_addr) 및 포트($remote_port)를 정의합니다.

# In the HTTP context 
split_clients $remote_addr$remote_port $app_upstream {
    5% demoapp-v2;
    *  demoapp;
}

4. 이전에 우리는 어떤 경우에 정상 트래픽에 대한 것과는 별개의 location 블록에서 상태 확인을 정의해야 한다고 언급했으며, 이것이 그러한 경우입니다. NGINX Plus는 초기화할 때 상태 확인을 설정하고 해당 시점에 상태 확인을 보낼 upstream 그룹을 알아야 합니다. 이 경우와 같이 구성이 런타임 변수를 사용하여 upstream 그룹을 선택하는 경우 NGINX Plus는 upstream 그룹 이름을 결정할 수 없습니다. 초기화 시 필요한 정보를 제공하기 위해 명시적으로 이름을 지정하는 각 upstream 그룹에 대해 별도의 location 블록을 생성합니다. 현재 사례에는 두 개의 upstream 그룹이 있으므로 각 그룹에 대해 server 블록에 location 블록이 있습니다.

# In the first server block
location @healthcheck {
    internal;
    proxy_pass http://demoapp;
    health_check uri=/healthcheck.html match=matchstring-v1;
}

location @healthcheck-v2 {
    internal;
    proxy_pass http://demoapp-v2;
    health_check uri=/healthcheck.html match=matchstring-v2;
}

5. http 컨텍스트에서 일치 블록을 추가하여 각 상태 확인에 대한 일치 조건을 정의합니다.

# In the HTTP context
match matchstring-v1 {
    status 200;
    body ~ "Version: 1.0 Status: OK";
}

match matchstring-v2 {
    status 200;
    body ~ "Version: 2.0 Status: OK";
}

3-3. 출시 일정

약간의 Lua 스크립팅으로 특정 시간에 업그레이드를 예약할 수 있습니다. 새 upstream 그룹을 설정하면 스크립트는 시스템 시간에 따라 다른 upstream 이름을 반환합니다. 컷오버 시간 이전의 이전 upstream 이름과 이후에 새 upstream 그룹입니다.

Canary Release 수행에서와 동일한 upstream 그룹을 사용하여 기본 location 블록( / )에 다음 Lua 스크립트를 추가하여 현지 시간으로 2016년 6월 21일 오후 10시에 컷오버가 발생하도록 할 수 있습니다. 그 전에 수신된 모든 요청 시간은 demoapp upstream 그룹으로 전송되고 해당 시간 또는 그 이후에 수신된 모든 요청은 demoapp-v2 upstream 그룹으로 전송됩니다.

# In the first server block
location / {
    rewrite_by_lua '
        if ngx.localtime() >= "2016-06-21 22:00:00" then
            ngx.var.app_upstream = "demoapp-v2"
        else
            ngx.var.app_upstream = "demoapp"
        end
    ';

    proxy_pass http://$app_upstream;
}

3-4. 클라이언트 IP 주소를 기반으로 새 버전에 대한 액세스 제어

Canary Release 수행에서 모든 사람에게 공개하기 전에 적은 수의 사용자로 새 애플리케이션을 테스트하는 한 가지 방법을 다루었습니다. 여기에서 IP 주소를 기반으로 소수의 사용자를 선택하고 새 애플리케이션의 URI에 대한 액세스만 허용합니다. 특히 클라이언트 IP 주소를 포함하는 $remote_addr 변수를 기반으로 upstream 그룹 이름을 설정하는 map 블록을 설정합니다. 특정 클라이언트 IP 주소 또는 IP 주소 범위를 지정할 수 있습니다.

예를 들어, Canary Release 수행에서 설명한 것과 동일한 upstream 그룹을 사용하여 172.16.210.1과 172.16.210.19 사이의 범위에 있는 내부 IP 주소의 요청을 demoapp-v2 upstream 그룹(여기서 서버는 새 애플리케이션 버전을 실행 중) 다른 모든 요청을 demoapp upstream 그룹에 보내는 동안:

# In the HTTP context
map $remote_addr $app_upstream {
    ~^172.16.210.([1-9]|[1-9][0-9])$ demoapp-v2;
    default demoapp;
}

이전과 마찬가지로 $app_upstream 변수의 값은 첫 번째 server 블록의 proxy_pass 지시문에 전달되므로 요청을 받는 upstream 그룹을 결정합니다.

# In the first server block
location / {
    proxy_pass http://$app_upstream;
}

4. NGINX Plus 결론

NGINX Plus는 운영 및 DevOps 엔지니어에게 개별 서버에서 소프트웨어 및 하드웨어 업그레이드를 관리하는 동시에 다운타임을 방지하여 우수한 고객 경험을 지속적으로 제공하기 위한 여러 옵션을 제공합니다.

이 시리즈의 다른 두 포스트를 확인하십시오.

• 업그레이드 방법 개요
• 개별 서버에서 하드웨어 또는 소프트웨어 업그레이드

NGINX Plus를 직접 사용해 보고 이것이 어떻게 업그레이드를 더 쉽고 효율적으로 만드는지 확인하십시오. 30일 무료 평가판을 시작하거나 당사에 연락하여 사용 사례에 대해 논의하십시오.

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