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

Owen Garrett제품 관리 부문 수석 이사

편집자 – 고용량 및 고가용성 캐싱에 관한 시리즈의 두 번째 글입니다:

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

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

검토 – 샤딩된 캐시 솔루션

이 시리즈의 첫 번째 글에서는 대규모 샤딩 캐시 클러스터를 구축하는 패턴을 설명했습니다.

이 패턴은 필요에 따라 확장할 수 있는 초대용량 캐시를 구축해야 할 때 효과적입니다. 각 리소스가 하나의 서버에만 캐시되므로 완전한 내결함성을 제공하지는 않지만, 일관된 해시 기반 부하 분산을 통해 서버에 장애가 발생하더라도 해당 서버가 담당하던 캐시 콘텐츠만 무효화됩니다.

고가용성 캐시 클러스터 만들기

어떤 대가를 치르더라도 오리진 서버로 전송되는 요청 수를 최소화하는 것이 최우선 목표라면 캐시 샤딩 솔루션은 최선의 선택이 아닙니다. 대신 기본 및 보조 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
}

보조 캐시 서버 구성

보조 캐시 서버가 요청을 오리진 서버로 전달하고 응답을 캐시하도록 구성합니다.

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 Open Source를 사용하는 경우 keepalived 또는 다른 HA 솔루션을 수동으로 설치하고 구성할 수 있습니다.

장애 조치 시나리오

캐시 서버에 장애가 발생하더라도 계속 작동하는 고가용성 캐시 클러스터를 구축하는 것이 목표라는 점을 기억하세요. 캐시 서버에 장애가 발생했을 때뿐만 아니라 복구 후 오래된 콘텐츠를 새로 고쳐야 할 때도 오리진 서버의 부하가 증가하지 않도록 해야 합니다.

기본 서버에 장애가 발생했다고 가정해 보겠습니다 그러면 NGINX Plus HA 솔루션이 외부 IP 주소를 보조 서버로 이전합니다.

보조 서버에는 전체 캐시가 있으며 정상적으로 계속 작동합니다. 오리진 서버에 추가 부하가 발생하지 않습니다.

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

이제 보조 서버에 장애가 발생했다고 가정해 보겠습니다. 기본 서버는 이를 감지하고(HA 솔루션의 일부로 구성된 상태 확인을 사용) 트래픽을 백업 서버(즉, 오리진 서버)로 직접 전달합니다.

기본 서버에는 전체 캐시가 있으며 계속 정상적으로 작동합니다. 이 경우에도 오리진 서버에 추가 부하가 발생하지 않습니다.

보조 서버가 복구되면 해당 캐시는 최신 상태가 아닙니다. 하지만 주 서버의 캐시가 만료될 때만 주 서버로부터 요청을 받으며, 그 시점에는 보조 서버의 캐시도 이미 만료된 상태입니다. 보조 서버가 오리진 서버에 콘텐츠를 요청해야 하더라도 오리진 서버에 대한 요청 빈도가 증가하지는 않습니다. 따라서 오리진 서버에 미치는 부정적인 영향은 없습니다.

장애 조치 동작 테스트

HA 솔루션을 테스트하기 위해 오리진 서버가 요청을 기록하고 각 요청에 대해 현재 시간을 반환하도록 구성합니다. 즉, 오리진 서버의 응답은 매초 달라집니다:

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

기본 및 보조 캐시 서버는 상태 코드가 200인 응답을 15초 동안 캐시하도록 이미 구성되어 있습니다. 따라서 일반적으로 캐시는 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 캐시 서버 간에 캐시를 계층화하면 고가용성 캐시 클러스터를 효과적으로 구축할 수 있습니다. 이를 통해 오리진 서버의 부하를 최소화하고, 캐시 서버 중 하나에 장애가 발생하거나 복구될 때 트래픽이 급증하는 상황으로부터 오리진 서버를 보호할 수 있습니다.

캐시의 총용량은 단일 캐시 서버의 용량으로 제한됩니다. 이 시리즈의 1부에서는 캐시 서버 클러스터 전체에 캐시를 분할하는 대안적인 샤딩 캐시 패턴을 설명합니다. 이 경우 총용량은 모든 캐시 서버의 용량을 합한 것과 같지만, 캐시 서버에 장애가 발생했을 때 오리진 서버로 향하는 트래픽이 급증하는 것을 방지하기 위한 콘텐츠 복제는 이루어지지 않습니다.

자체 서버에서 고가용성 캐싱을 사용해 보세요. 지금 30일 무료 체험을 시작하거나 문의하여 사용 사례를 상담해 보세요.

작성자 소개

Owen Garrett제품 관리 부문 수석 이사

Owen Garrett의 다른 블로그 게시물