NGINX Cache 클러스터 구축 1부: 대용량, 고가용성, 확장성

NGINX 또는 NGINX Plus를 사용하여 대용량의 고가용성 Cache 클러스터를 어떻게 확장 가능하게 구축할 수 있습니까? 이것은 이 목표를 달성하기 위한 대안적 접근 방식을 제시하는 2부작 시리즈 중 첫 번째입니다.

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

목차

1. NGINX Cache 개요
  1-1. NGINX Cache를 위해 공유 디스크를 사용하지 않는 이유는 무엇일까요?
  1-2. 여러 NGINX Plus 서버에서 캐시를 공유하는 이유는 무엇일까요?
2. 캐시 샤딩
3. 샤드 캐시 구성 최적화
  3-1. 로드 밸런서와 캐시 계층 결합
  3-2. 1단계 “핫” 캐시 구성
4. NGINX Cache 요약

1. NGINX Cache 개요

NGINX Plus는 Origin Server와 원격 클라이언트 사이에 있는 프록시 캐시 서버로 작동할 수 있습니다. NGINX Plus는 Origin Server에 대한 트래픽을 관리하고 변경되지 않는 공통 리소스를 캐시(저장)합니다.

이를 통해 NGINX Plus는 이러한 리소스가 요청될 때 클라이언트에 직접 응답하여 Origin Server의 부하를 줄입니다. NGINX Plus의 프록시 캐시는 Origin Server 옆의 데이터 센터에 가장 일반적으로 배포되며 전 세계적으로 분산된 PoP에서 CDN과 같은 방식으로 배포될 수도 있습니다.

콘텐츠 캐싱은 놀랍도록 복잡한 주제입니다. 이 문서를 계속하기 전에 몇 가지 기본 캐싱 기술에 익숙해지는 것이 좋습니다.

1-1. NGINX Cache 를 위해 공유 디스크를 사용하지 않는 이유는 무엇일까요?

각 NGINX Plus 서버는 독립적인 웹 캐시 서버로 작동합니다. 여러 NGINX Plus 서버 간에 디스크 기반 캐시를 공유할 수 있는 기술적 수단이 없습니다. 이것은 의도적인 디자인 결정입니다.

대기 시간이 길고 잠재적으로 신뢰할 수 없는 공유 파일 시스템에 캐시를 저장하는 것은 좋은 설계 선택이 아닙니다. NGINX Plus는 디스크 대기 시간에 민감하며 스레드 풀 기능이 기본 스레드에서 read () 및 write () 작업을 오프로드하더라도 파일 시스템이 느리고 캐시 I/O가 높으면 NGINX Plus가 대량 볼륨에 의해 압도 될 수 있습니다.

NGINX Plus 인스턴스 전체에서 일관된 공유 캐시를 유지하려면 fills, reads 및 deletes와 같은 중첩 캐시 작업을 동기화하기 위해 클러스터 전체 잠금이 필요합니다. 마지막으로, 공유 파일 시스템은 안정성과 일관된 성능이 가장 중요한 캐싱에 불안정성과 예측할 수 없는 성능의 원인이 됩니다.

마지막으로, 공유 파일 시스템은 신뢰성과 일관된 성능이 가장 중요한 캐싱에 신뢰할 수없고 예측할 수없는 성능의 원천을 소개합니다.

1-2. 여러 NGINX Plus 서버에서 캐시를 공유하는 이유는 무엇일까요?

파일 시스템을 공유하는 것이 캐싱에 대한 좋은 접근 방식은 아니지만 각각 해당 기술이 있는 여러 NGINX Plus 서버 간에 콘텐츠를 캐싱해야 할 충분한 이유가 있습니다.

  • 기본 목표가 매우 큰 용량의 캐시를 만드는 것이라면 여러 서버에 걸쳐 캐시를 샤딩(분할)합니다.
  • 기본 목표가 Origin Server의 로드를 최소화하면서 고가용성을 달성하는 것이라면 고가용성 공유 캐시를 사용하십시오.
shared

2. 캐시 샤딩

캐시 샤딩은 여러 웹 캐시 서버에 캐시 항목을 배포하는 프로세스입니다. NGINX Plus 캐시 샤딩은 일관된 해싱 알고리즘을 사용하여 각 캐시 항목에 대해 하나의 캐시 서버를 선택합니다.

그림은 하나의 서버가 다운되거나(가운데 그림) 다른 서버가 추가될 때(오른쪽 그림) 3개의 서버(왼쪽 그림)에 걸쳐 샤딩된 캐시에 어떤 일이 발생하는지 보여줍니다.

shading

총 캐시 용량은 각 서버의 캐시 용량의 합계입니다. 하나의 서버만 각 리소스를 캐시하려고 시도하기 때문에 Origin Server로의 이동을 최소화합니다.

cache server

이 패턴은 N개의 캐시 서버가 있고 하나가 실패하면 캐시의 1/ N 만 손실된다는 점에서 내결함성이 있습니다. ‘손실된 부분’은 나머지 N  –1 서버에 걸쳐 일관된 해시에 의해 균등하게 분배됩니다. 더 간단한 해싱 방법은 대신 전체 캐시를 나머지 서버에 재분배하므로 재분배 중에 거의 모든 캐시가 손실됩니다.

일관된 해시 로드 밸런싱을 수행할 때 Cache Key (또는 키 구성에 사용되는 필드의 하위 집합)를 일관된 해시의 키로 사용합니다 .

upstream cache_servers {
    hash $scheme$proxy_host$request_uri consistent;

    server red.cache.example.com;
    server green.cache.example.com;
    server blue.cache.example.com;
}

NGINX Plus의 Active-Passive 고가용성(HA) 솔루션, 라운드 로빈 DNS 또는 keepalived.

3. 샤드 캐시 구성 최적화

캐시 샤딩 구성에 대한 두 가지 최적화 중 하나를 선택할 수 있습니다.

3-1. 로드 밸런서와 캐시 계층 결합

LB 및 캐시 계층을 결합할 수 있습니다. 이 구성에서는 두 개의 가상 서버가 각 NGINX Plus 인스턴스에서 실행됩니다.

로드 밸런싱 가상 서버(그림의 “LB VS”)는 외부 클라이언트의 요청을 수락하고 일관된 해시를 사용하여 내부 네트워크로 연결된 클러스터의 모든 NGINX Plus 인스턴스에 요청을 배포합니다.

각 NGINX Plus 인스턴스의 캐싱 가상 서버(“Cache VS”)는 내부 IP 주소에서 요청 공유를 수신하고 이를 Origin Server로 전달하고 응답을 캐싱합니다. 이를 통해 모든 NGINX Plus 인스턴스가 캐싱 서버로 작동하여 캐시 용량을 최대화할 수 있습니다.

load balance

3-2. 1단계 “Hot” 캐시 구성

대용량 공유 캐시를 두 번째 수준 캐시로 사용하여 매우 자주 사용되는 콘텐츠에 대해 Frontend LB Tier에서 첫 번째 수준 캐시를 구성할 수 있습니다.

이렇게 하면 첫 번째 계층 캐시 콘텐츠가 점차 만료될 때 콘텐츠를 새로 고치기만 하면 되므로 두 번째 수준 캐시 계층이 실패할 경우 성능을 향상하고 Origin Server에 미치는 영향을 줄일 수 있습니다.

hot cache configuration

캐시 클러스터가 매우 많은 양의 Hot 콘텐츠를 처리하는 경우 더 작은 1단계 캐시의 변동률이 매우 높다는 것을 알 수 있습니다.

즉, 캐시의 제한된 공간에 대한 수요가 너무 높아 콘텐츠가 하나의 후속 요청을 충족하는 데 사용되기 전에(최근에 요청된 콘텐츠를 위한 공간을 만들기 위해) 캐시에서 제거됩니다.

이 상황을 나타내는 한 가지 지표는 NGINX Plus API 모듈 에서 보고하는 확장된 통계에 포함된 두 가지 메트릭인 작성된 콘텐츠에 대한 제공된 콘텐츠의 비율이 낮다는 것입니다.

기본 제공 Live Activity 모니터링 대시보드의 캐시 탭에 있는 게재됨 및 작성됨 필드에 나타납니다. (NGINX Plus API 모듈 및 Live Activity 모니터링 대시보드는 NGINX 오픈소스에서 사용할 수 없습니다.)

이 스크린샷은 NGINX Plus가 캐시에서 제공하는 것보다 더 많은 콘텐츠를 캐시에 쓰는 상황을 나타냅니다.

traffic

이 경우 가장 일반적으로 요청되는 콘텐츠만 저장하도록 캐시를 미세 조정할 수 있습니다. 지시문 은 proxy_cache_min_uses이 콘텐츠를 식별하는 데 도움이 될 수 있습니다.

4. NGINX Cache 요약

여러 NGINX 또는 NGINX Plus 웹 캐시 서버에서 캐시를 샤딩하는 것은 대용량의 확장 가능한 캐시를 만드는 효과적인 방법입니다. 일관된 해시는 상당한 수준의 고가용성을 제공하여 캐시가 실패할 경우 캐시된 콘텐츠의 해당 공유만 무효화되도록 합니다.

이 포스트의 2부에서는 한 쌍의 NGINX Cache 서버에 캐시를 복제하는 대체 공유 캐시 패턴에 대해 설명합니다. 총 용량은 개별 서버의 용량으로 제한되지만 구성은 완전한 내결함성이 있으며 캐시 서버를 사용할 수 없게 되더라도 캐시된 콘텐츠가 손실되지 않습니다.

NGINX Plus로 캐시 샤딩을 사용해 보십시오. 무료 30일 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의하십시오.