NGINX Cache 클러스터 구축 2부: 페일오버

NGINX 또는 NGINX Plus를 사용하여 대용량의 고가용성 Cache 클러스터를 어떻게 구축할 수 있습니까? 해당 포스트에서는 두 개 이상의 NGINX 또는 NGINX Plus Cache 서버를 사용하여 고가용성 NGINX Cache 클러스터를 생성하는 방법을 설명합니다.

(명시된 경우를 제외하고 여기에 설명된 방법은 NGINX 오픈소스 및 NGINX Plus에 동일하게 적용되지만 간결성을 위해 NGINX Plus만 언급하겠습니다.)

목차

1. 검토 – 샤드 Cache 솔루션
2. 고가용성 NGINX Cache 클러스터 생성
 2-1. 기본 NGINX Cache 서버 구성
 2-2. 보조 NGINX Cache 서버 구성
 2-3. 고가용성 구성
3. Fail over 시나리오
4. Fail over 동작 테스트
 4-1. Cache 동작 확인
 4-2. Fail over 확인
 4-3. Cache 업데이트 타이밍
5. NGINX Cache 요약

1. 검토 – 샤드 캐시 솔루션

이 시리즈의 1부에서는 매우 큰 샤드 NGINX Cache 클러스터를 만드는 패턴을 설명했습니다.

cache solution

이 패턴은 원하는 대로 확장할 수 있는 대용량 캐시를 만들어야 할 때 효과적입니다. 각 리소스는 하나의 서버에만 캐시되므로 완전한 내결함성은 없지만 일관된 해시 로드 밸런싱을 통해 서버에 장애가 발생할 경우 캐시된 콘텐츠 중 해당 리소스의 공유만 무효화됩니다.

2. 고가용성 NGINX Cache 클러스터 생성

어떤 대가를 치르더라도 Origin Server에 대한 요청 수를 최소화하는 것이 주요 목표라면 Cache 공유 솔루션은 최선의 옵션이 아닙니다.

대신 Primary 및 Secondary NGINX Plus 인스턴스를 신중하게 구성하는 솔루션은 다음과 같은 요구 사항을 충족할 수 있습니다:

HA cluster

기본 NGINX Plus 인스턴스는 모든 트래픽을 수신하고 Secondary 인스턴스로 요청을 전달합니다.

Secondary 인스턴스는 Origin Server에서 내용을 검색하여 캐시하고, Primary 인스턴스는 Secondary 서버에서 응답을 캐시하여 클라이언트로 반환합니다.

두 장치 모두 캐시가 완전히 채워져 있으며 구성된 시간 초과에 따라 캐시가 새로 고쳐집니다.

2-1. Primary NGINX Cache 서버 구성

모든 요청을 보조 서버로 전달하고 응답을 캐시하도록 기본 NGINX Cache 서버를 구성합니다.

업스트림 그룹의 서버 지시문에 백업 매개 변수로 표시된 것처럼 Secondary 서버에 장애가 발생할 경우 Primary 서버는 요청을 Origin Server로 직접 전달합니다:

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;

server {
    status_zone mycache;          # for NGINX Plus extended status

    listen 80;

    proxy_cache mycache;
    proxy_cache_valid 200 15s;

    location / {
        proxy_pass http://secondary;
    }
}

upstream secondary {
    zone secondary 128k;          # for NGINX Plus extended status

    server 192.168.56.11;         # secondary
    server 192.168.56.12 backup;  # origin
}

2-2. 보조 NGINX Cache 서버 구성

요청을 Origin Server로 전달하고 응답을 캐시하도록 Secondary Cache 서버를 구성합니다.

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;

server {
    status_zone mycache;          # for NGINX Plus extended status

    listen 80;

    proxy_cache mycache;
    proxy_cache_valid 200 15s;

    location / {
        proxy_pass http://origin;
    }
}

upstream origin {
    zone origin 128k;            # for NGINX Plus extended status

    server 192.168.56.12;        # origin
}

2-3. 고가용성 구성

마지막으로 Primary 서버가 실패할 경우 Secondary 서버가 수신 트래픽을 수신하고, 이후 복구될 때 Primary 서버가 트래픽을 다시 수신하도록 HA(고가용성)를 구성해야 합니다.

이 예에서는 NGINX Plus에 active-passive HA 솔루션을 사용합니다. 외부에 알려진 가상 IP 주소는 192.168.56.20이고 Primary 캐시 서버는 클러스터에서 HA의 기본 노드 역할을 합니다.

NGINX 오픈소스를 사용하는 경우 keepalived 등과 같은 다른 HA 솔루션을 수동으로 설치 및 구성할 수 있습니다.

global_defs {
    vrrp_version 3
}

vrrp_script chk_manual_failover {
    script   "/usr/libexec/keepalived/nginx-ha-manual-failover"
    interval 10
    weight   50
}

vrrp_script chk_nginx_service {
    script   "/usr/libexec/keepalived/nginx-ha-check"
    interval 3
    weight   50
}

vrrp_instance VI_1 {
    interface                  eth0
    priority                   101
    virtual_router_id          51
    advert_int                 1
    accept
    garp_master_refresh        5
    garp_master_refresh_repeat 1
    unicast_src_ip             192.168.100.100

    unicast_peer {
        192.168.100.101
    }

    virtual_ipaddress {
        192.168.100.150
    }

    track_script {
        chk_nginx_service
        chk_manual_failover
    }

    notify "/usr/libexec/keepalived/nginx-ha-notify"
}

3. Fail over 시나리오

Cache 서버에 장애가 발생하더라도 계속 작동하는 고가용성 NGINX Cache 클러스터를 만들고자 합니다. Cache 서버에 장애가 발생하거나 Cache 서버가 복구되어 오래된 콘텐츠를 새로 고쳐야 하는 경우 Origin Server의 로드가 증가하지 않도록 합니다.

Primary 서버가 실패하고 NGINX Plus HA 솔루션이 외부 IP 주소를 Secondary 서버로 전송한다고 가정합니다.

failover scenario

Secondary 서버는 전체 캐시를 가지고 있으며 정상적으로 계속 작동합니다. Origin Server에는 추가 부하는 없습니다.

Primary NGINX Cache 서버가 복구되어 클라이언트 트래픽 수신을 시작하면 캐시가 오래되고 많은 항목이 만료됩니다. Primary는 Secondary Cache 서버에서 로컬 캐시를 새로 고칩니다. Secondary 서버의 캐시가 이미 최신 상태이므로 Origin Server에 대한 트래픽이 증가하지 않습니다.

이제 Secondary 서버가 실패했다고 가정합니다 . Primary 서버는 이를 감지하고 (HA 솔루션의 일부로 구성된 상태 확인을 사용하여) 트래픽을 백업 서버(Origin Server)로 직접 전달합니다.

cache server primary

Primary 서버는 전체 캐시를 가지고 있으며 정상적으로 계속 작동합니다. 다시 한 번 말하지만, Origin Server에 대한 추가 로드는 없습니다.

Secondary 서버가 복구되면 캐시가 만료됩니다. 그러나 Primary 캐시가 만료될 때만 Primary 캐시에서 요청을 수신하며, 이 시점에서 Secondary 복사본도 만료됩니다. Secondary 서버가 Origin Server에서 콘텐츠를 요청해야 하더라도 Origin Server에 대한 요청 빈도는 증가하지 않습니다. Origin Server에는 악영향이 없습니다.

4. Fail over 동작 테스트

HA 솔루션을 테스트하기 위해 요청을 기록하고 각 요청의 현재 시간을 반환하도록 Origin Server를 구성합니다. 이것은 Origin Server의 응답이 매초마다 변경됨을 의미합니다.

access_log /var/log/nginx/access.log;

location / {
    return 200 "It's now $time_localn";
}

Primary 서버 및 Secondary Cache 서버는 기본적으로 200 상태 코드가 포함된 응답을 캐시하도록 구성되어 있습니다.
이로 인해 일반적으로 15초 또는 16초마다 캐시가 업데이트 됩니다

proxy_cache_valid 200 15s;

4-1. Cache 동작 확인

초당 한 번씩 캐시 클러스터의 고가용성 가상 IP 주소로 HTTP 요청을 보냅니다. Primary 및 Secondary Cache 서버의 캐시가 만료되고 Origin Server에서 응답이 새로 고쳐질 때까지 응답은 변경되지 않습니다. 이는 15초 또는 16초마다 발생합니다.

$ while sleep 1 ; do curl http://192.168.56.20/ ; done
It's now 9/Feb/2017:06:35:03 -0800
It's now 9/Feb/2017:06:35:03 -0800
It's now 9/Feb/2017:06:35:03 -0800
It's now 9/Feb/2017:06:35:19 -0800
It's now 9/Feb/2017:06:35:19 -0800 
^C

또한 Origin Server의 로그를 검사하여 15초 또는 16초마다 요청을 수신하고 있는지 확인할 수 있습니다.

4-2. Fail over 확인

nginx 프로세스를 중지하는 등의 방법으로 Primary 서버 또는 Secondary Cache 서버를 중지하여 Fail over 동작 테스트가 올바르게 작동하는지 확인할 수 있습니다. 일정 부하 테스트가 계속 실행되고 응답이 일관되게 캐시됩니다.

Origin Server에서 액세스 로그를 검사하면 캐시 서버가 실패하거나 복구되더라도 15-16초마다 요청을 수신하는지 확인할 수 있습니다.

4-3. Cache 업데이트 타이밍

안정적인 상황에서 캐시된 콘텐츠는 일반적으로 15~16초마다 업데이트됩니다. 콘텐츠는 15초 후에 만료되며 다음 요청이 수신될 때까지 최대 1초의 지연이 발생하여 캐시 업데이트가 발생합니다.

경우에 따라 캐시가 더 느리게 업데이트되는 것처럼 보일 수 있습니다(콘텐츠 변경 사이에 최대 30초). 이 문제는 주 캐시 서버의 콘텐츠가 만료되고 주 Cache 서버가 거의 만료된 캐시된 콘텐츠를 보조 캐시에서 검색하는 경우에 발생합니다. 이로 인해 문제가 발생할 경우 보조 서버에서 캐시 제한 시간을 단축할 수 있습니다.

5. NGINX Cache 요약

여기서 설명한 방법으로 둘 이상의 NGINX 캐시 서버 간에 캐시를 계층화하는 것은 Origin Server의 로드를 최소화하는 고가용성 캐시 클러스터를 생성하여 캐시 서버 중 하나에 장애가 발생하거나 복구될 때 트래픽 급증을 방지하는 효과적인 방법입니다.

캐시의 총 용량은 단일 캐시 서버의 용량으로 제한됩니다. 이 시리즈의 1부에서는 캐시 서버 클러스터에서 캐시를 분할하는 대체 샤드 캐시 패턴을 설명했습니다. 이 경우 총 용량은 모든 캐시 서버의 합계이지만 캐시 서버에 장애가 발생할 경우 Origin Server로의 트래픽 급증을 방지하기 위해 콘텐츠가 복제되지는 않습니다.

NGINX Plus 서버에서 고가용성 캐싱을 사용해 보십시오. 오늘 무료 30일 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의하십시오.