NGINX Plus 캐시 클러스터를 사용한 공유 캐시

NGINX 또는 NGINX Plus를 사용하여 대용량, 고가용성 캐시 클러스터를 어떻게 구축할 수 있습니까? 이 게시물에서는 두 개 이상의 NGINX 또는 NGINX Plus 캐시 서버를 사용하여 고가용성 캐시 클러스터를 만드는 방법을 설명합니다. (여기에 설명된 방법은 언급된 경우를 제외하고 NGINX Open Source와 NGINX Plus에 동일하게 적용되지만 간결하게 NGINX Plus만 참조합니다.)

리뷰 – 샤디드 캐시 솔루션

이 시리즈의 첫 번째 부분에서는 매우 큰 샤드 캐시 클러스터를 만드는 패턴을 설명했습니다.

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

고가용성 캐시 클러스터 생성

원점 서버에 대한 요청 수를 어떻게든 최소화하는 것이 주요 목표라면 캐시 샤딩 솔루션은 최선의 선택이 아닙니다. 대신, 1차 및 2차 NGINX Plus 인스턴스를 신중하게 구성한 솔루션이 요구 사항을 충족할 수 있습니다.

기본 NGINX Plus 인스턴스는 모든 트래픽을 수신하고 요청을 보조 인스턴스로 전달합니다. 보조 인스턴스는 원본 서버에서 콘텐츠를 검색하여 캐시합니다. 기본 인스턴스는 보조 인스턴스의 응답도 캐시하여 클라이언트로 반환합니다.

두 장치 모두 캐시가 완전히 채워졌으며, 캐시는 구성된 시간 제한에 따라 새로 고쳐집니다.

기본 캐시 서버 구성

모든 요청을 보조 서버로 전달하고 응답을 캐시하도록 기본 캐시 서버를 구성합니다. 업스트림 그룹의 지시문 backup에 대한 매개변수 에서 알 수 있듯이 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차 캐시 서버 구성

보조 캐시 서버를 구성하여 원본 서버로 요청을 전달하고 응답을 캐시합니다.

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
}

고가용성 구성

마지막으로, 기본 서버에 장애가 발생하면 보조 서버가 유입 트래픽을 처리하고, 기본 서버가 이후 복구되면 트래픽을 다시 처리할 수 있도록 고가용성(HA)을 구성해야 합니다.

이 예에서 우리는 NGINX Plus에 대한 액티브-패시브 HA 솔루션을 사용합니다 . 외부에서 광고된 가상 IP 주소는 192.168.56.20이고, 기본 캐시 서버는 클러스터에서 HA의 기본 노드 역할을 합니다. NGINX 오픈 소스를 사용하는 경우 수동으로 설치하고 구성 keepalived하거나 다른 HA 솔루션을 구성할 수 있습니다.

장애 조치 시나리오

캐시 서버가 실패하더라도 계속 작동하는 고가용성 캐시 클러스터를 만들고 싶다는 점을 기억하세요. 캐시 서버가 실패하거나 복구되어 오래된 콘텐츠를 새로 고쳐야 할 때 원본 서버의 부하가 증가하는 것을 원하지 않습니다.

기본 서버에 장애가 발생 하고 NGINX Plus HA 솔루션 이 외부 IP 주소를 보조 서버에 전송한다고 가정해 보겠습니다.

2차 서버에는 캐시가 가득 차 있고 정상적으로 작동합니다. 원본 서버에는 추가 부하가 없습니다.

기본 캐시 서버가 복구되어 클라이언트 트래픽을 수신하기 시작하면 캐시가 오래되고 많은 항목이 만료됩니다. 기본 캐시는 보조 캐시 서버에서 로컬 캐시를 새로 고칩니다. 보조 서버의 캐시가 이미 최신 상태이므로 원본 서버로의 트래픽이 증가하지 않습니다.

이제 2차 서버가 실패했다고 가정해 보겠습니다 . 1차 서버가 이를 감지하고( HA 솔루션의 일부로 구성된 상태 검사를 사용하여 ) 트래픽을 백업 서버(원본 서버)로 직접 전달합니다.

기본 서버에는 캐시가 가득 차 있고 정상적으로 계속 작동합니다. 다시 한 번, 원본 서버에는 추가 부하가 없습니다.

2차 서버가 복구되면 캐시는 오래될 것입니다. 그러나 1차 서버의 캐시가 만료될 때만 1차 서버에서 요청을 받게 되며, 이때 2차 서버의 사본도 만료됩니다. 2차 서버에서 원본 서버로부터 콘텐츠를 요청해야 하지만, 원본 서버에 대한 요청 빈도는 증가하지 않습니다. 원본 서버에 부정적인 영향은 없습니다.

장애 조치 동작 테스트

HA 솔루션을 테스트하기 위해, 우리는 요청을 기록 하고 각 요청에 대한 현재 시간을 반환 하도록 원본 서버를 구성합니다 . 즉, 원본 서버의 응답은 매초마다 변경됩니다.

access_log /var/log/nginx/access.log;
location / {
    return 200 "It's now $time_localn";
}

1차 및 2차 캐시 서버는 이미 15초 동안 상태 코드로 응답을 캐시하도록 구성되어 있습니다 200. 이는 일반적으로 15초 또는 16초마다 캐시 업데이트가 발생합니다.

proxy_cache_valid 200 15s;

캐시 동작 확인

1초에 한 번씩 캐시 클러스터의 고가용성 가상 IP 주소로 HTTP 요청을 보냅니다. 응답은 기본 및 보조 서버의 캐시가 만료되고 응답이 원본 서버에서 새로 고쳐질 때까지 변경되지 않습니다. 이는 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

또한 원본 서버의 로그를 검사하여 15~16초마다 요청을 받는지 확인할 수 있습니다.

장애 조치 확인

예를 들어, 프로세스를 중지하여 기본 서버나 보조 서버를 중지함으로써 장애 조치가 올바르게 작동하는지 확인할 수 있습니다 nginx. 상수 부하 테스트는 계속 실행되고 응답은 일관되게 캐시됩니다.

원본 서버의 액세스 로그를 검사하면 캐시 서버 중 어느 것이 실패하거나 복구되든 15~16초마다 요청을 수신하는 것을 확인할 수 있습니다.

캐시 업데이트 타이밍

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

가끔 캐시가 더 느리게 업데이트되는 것처럼 보일 수 있습니다(콘텐츠 변경 사이에 최대 30초). 이는 기본 캐시 서버의 콘텐츠가 만료되고 기본이 보조에서 거의 만료된 캐시된 콘텐츠를 검색하는 경우 발생합니다. 이것이 문제가 되면 보조 서버에서 더 짧은 캐시 시간 초과를 구성할 수 있습니다.

요약

여기에 설명된 방식으로 두 개 이상의 NGINX 캐시 서버 간에 캐시를 계층화하는 것은 고가용성 캐시 클러스터를 만드는 효과적인 방법으로, 캐시 서버 중 하나에 장애가 발생하거나 복구될 때 트래픽이 급증하는 상황으로부터 원본 서버의 부하를 최소화하고 이를 보호합니다.

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