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

편집자 - 이것은 고용량 및 고가용성 캐싱에 대한 시리즈의 두 번째 부분입니다.

• NGINX Plus 캐시 클러스터를 사용한 공유 캐시, 1부
• NGINX Plus 캐시 클러스터를 사용한 공유 캐시, 2부(이 게시물)

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

리뷰 - 샤디드 캐시 솔루션

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

이 패턴은 자유롭게 확장 가능한 매우 큰 용량의 캐시를 만들어야 할 때 효과적입니다. 각 리소스는 하나의 서버에만 캐시되므로 완전한 장애 내구성은 없지만, 일관된 해시 부하 분산을 통해 서버에 장애가 발생하는 경우 캐시된 콘텐츠 중 해당 서버에 할당된 부분만 무효화됩니다.

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

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

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

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

기본 캐시 서버 구성

기본 캐시 서버가 모든 요청을 보조 서버로 전달하고 응답을 캐시하도록 구성합니다. 업스트림 그룹의 서버 지시문에 대한 백업 매개변수에서 표시된 대로, 보조 서버에 장애가 발생하는 경우 기본 서버는 요청을 원본 서버로 직접 전달합니다.

proxy_cache_path /tmp/mycache keys_zone=mycache:10m; server { status_zone mycache; # NGINX Plus 확장 상태 listen 80; proxy_cache mycache; proxy_cache_valid 200 15s; location / { proxy_pass http://secondary; } } upstream secondary { zone secondary 128k; # NGINX Plus 확장 상태 server 192.168.56.11; # 보조 서버 192.168.56.12 backup ; # origin }

2차 캐시 서버 구성

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

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
status_zone mycache; # NGINX Plus 확장 상태용

listen 80;

proxy_cache mycache;
proxy_cache_valid 200 15s;

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

upstream origin {
zone origin 128k; # NGINX Plus 확장 상태용

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차측이 고장났다고 가정해보자 . 기본 서버는 이를 감지하고(HA 솔루션의 일부로 구성된 상태 검사를 사용하여) 트래픽을 백업 서버(원본 서버)로 직접 전달합니다.

기본 서버는 캐시가 가득 차서 정상적으로 작동합니다. 다시 말해, 원본 서버에 추가적인 부하가 발생하지 않습니다.

2차 데이터베이스가 복구되면 캐시는 최신이 아닙니다. 그러나 기본 서버의 캐시가 만료될 때만 기본 서버에서 요청을 받게 되며, 이때 보조 서버의 복사본도 만료됩니다. 2차 서버가 원본 서버에 콘텐츠를 요청해야 하더라도, 원본 서버에 대한 요청 빈도는 늘어나지 않습니다. 원본 서버에 부정적인 영향이 없습니다.

장애 조치 동작 테스트

HA 솔루션을 테스트하기 위해 원본 서버가 요청을 기록 하고 각 요청에 대한 현재 시간을 반환 하도록 구성했습니다. 이는 원본 서버의 응답이 매초마다 변경된다는 것을 의미합니다.

access_log /var/log/nginx/access.log;
location / {
return 200 "지금은 $time_localn입니다";
}

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

프록시_캐시_유효 200 15초;

캐시 동작 확인

1초에 한 번씩 캐시 클러스터의 고가용성 가상 IP 주소로 HTTP 요청을 보냅니다. 기본 및 보조 서버의 캐시가 만료되고 원본 서버에서 응답이 새로 고쳐질 때까지 응답은 변경되지 않습니다. 이 일은 15~16초마다 일어납니다.

$ while sleep 1 ; do curl http://192.168.56.20/ ; done 지금은 9/2/2017:06:35:03 -0800입니다. 지금은 9/2/2017:06:35:03 -0800입니다. 지금은 9/2/2017:06:35:03 -0800입니다. 지금은 9/2/2017:06:35:19 -0800입니다. 지금은 9/2/2017:06:35:19 -0800입니다 . ^C

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

장애 조치 확인

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

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

캐시 업데이트 타이밍

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

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

요약

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

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

귀하의 서버에서 고가용성 캐싱을 직접 사용해 보세요. 오늘 무료 30일 체험판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의해 보세요 .