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

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

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

이 게시물은 원래 여기에서 논의되었던 별도의 확장 상태 모듈을 대체하고 더 이상 사용되지 않는 NGINX Plus API를 참조하도록 업데이트되었습니다.

NGINX 또는 NGINX Plus를 사용하여 대용량, 고가용성 캐시 클러스터를 구축하려면 어떻게 해야 합니까? 이는 이 목표를 달성하기 위한 대안적인 접근 방식을 제시하는 2부작 시리즈의 첫 번째 글입니다. 위의 링크를 통해 두 번째 부분에 접근할 수 있습니다. (참고로, 이러한 접근 방식은 NGINX Open Source와 NGINX Plus에 동일하게 적용되지만 간략하게 NGINX Plus만 언급하겠습니다.)

NGINX Plus 캐싱 개요

NGINX Plus는 원본 서버와 원격 클라이언트 사이에 위치하여 프록시 캐시 서버로 작동할 수 있습니다. NGINX Plus는 원본 서버로의 트래픽을 관리하고 공통적이고 변경되지 않는 리소스를 캐시(저장)합니다. 이를 통해 NGINX Plus는 이러한 리소스가 요청될 때 클라이언트에 직접 응답하여 원본 서버의 부하를 줄일 수 있습니다. NGINX Plus의 프록시 캐시는 일반적으로 원본 서버 옆의 데이터 센터에 배포되지만 전 세계적으로 분산된 PoP에 CDN과 같은 방식으로 배포될 수도 있습니다.

콘텐츠 캐싱은 놀라울 정도로 복잡한 주제입니다. 이 기사를 계속 읽기 전에 몇 가지 기본 캐싱 기술에 익숙해지는 것이 좋습니다.

• NGINX Plus 캐싱의 메커니즘 – 핵심 구성 및 캐시 로더와 캐시 관리자 프로세스의 역할
• 캐시 시간 미세 조정 – 마이크로캐싱과 같은 관행을 구현하여 콘텐츠가 캐시되는 방식과 만료 시 새로 고쳐지는 방식을 제어합니다.

NGINX Plus가 캐싱에 공유 디스크를 사용하지 않는 이유는 무엇입니까?

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

대기 시간이 길고 신뢰할 수 없는 공유 파일 시스템에 캐시를 저장하는 것은 좋은 설계 선택이 아닙니다. NGINX Plus는 디스크 지연 시간에 민감하며, 스레드 풀 기능이 메인 스레드에서 read() 및 write() 작업을 오프로드하더라도 파일 시스템이 느리고 캐시 I/O가 높으면 NGINX Plus가 대량의 스레드에 압도될 수 있습니다. NGINX Plus 인스턴스 전체에서 일관되고 공유되는 캐시를 유지하려면 채우기, 읽기, 삭제와 같은 겹치는 캐시 작업을 동기화하기 위한 클러스터 전체 잠금도 필요합니다. 마지막으로, 공유 파일 시스템은 캐싱에 신뢰성과 예측할 수 없는 성능을 초래합니다. 캐싱에서는 신뢰성과 일관된 성능이 가장 중요합니다.

여러 NGINX Plus 서버에서 캐시를 공유하는 이유는 무엇입니까?

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

• 주요 목표가 대용량 캐시를 만드는 것이라면 캐시를 여러 서버에 분할(파티션)하세요. 이 게시물에서는 이 기술에 대해 다루겠습니다.
• 주요 목표가 원본 서버의 부하를 최소화하면서 높은 가용성을 달성하는 것이라면, 고가용성 공유 캐시를 사용하세요. 이 기술에 대해서는 관련 게시물(곧 제공)을 참조하세요.

캐시 샤딩

캐시 샤딩은 캐시 항목을 여러 웹 캐시 서버에 분산하는 프로세스입니다. NGINX Plus 캐시 샤딩은 일관된 해싱 알고리즘을 사용하여 각 캐시 항목에 대해 하나의 캐시 서버를 선택합니다. 이 그림은 세 개의 서버에 분산된 캐시(왼쪽 그림)에서 한 서버가 다운되거나(가운데 그림) 다른 서버가 추가될 때(오른쪽 그림) 어떤 일이 일어나는지 보여줍니다.

전체 캐시 용량은 각 서버의 캐시 용량의 합계입니다. 각 리소스를 캐싱하려는 서버는 단 하나뿐이므로 원본 서버로의 이동이 최소화됩니다(동일한 리소스의 여러 독립적인 사본이 없음).

이 패턴은 N개의 캐시 서버가 있고 그 중 하나가 실패하면 캐시의 1/ N 만 손실되므로 장애 내구성이 있습니다. 이 '손실된 부분'은 일관된 해시를 통해 나머지 N -1 서버에 균등하게 분산됩니다. 그 대신 더 간단한 해싱 방법은 나머지 서버에 전체 캐시를 재분산하는데, 이 과정에서 캐시를 거의 모두 잃게 됩니다.

일관된 해시 부하 분산을 수행하는 경우 일관된 해시의 키로 캐시 키 (또는 키 구성에 사용된 필드의 하위 집합)를 사용합니다.

업스트림 캐시_서버 { 해시 $scheme$proxy_host$request_uri 일관성 있음;

서버 red.cache.example.com;
서버 green.cache.example.com;
서버 blue.cache.example.com;
}

NGINX Plus의 액티브-패시브 고가용성 솔루션 , 라운드 로빈 DNS 또는 keepalived 와 같은 고가용성 솔루션을 사용하여 들어오는 트래픽을 부하 분산 장치(LB) 계층 전체에 분산할 수 있습니다.

샤드 캐시 구성 최적화

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

로드 밸런서와 캐시 계층 결합

LB와 캐시 계층을 결합할 수 있습니다. 이 구성에서는 각 NGINX Plus 인스턴스에서 두 개의 가상 서버가 실행됩니다. 부하 분산 가상 서버(그림의 "LB VS")는 외부 클라이언트의 요청을 수락하고 일관된 해시를 사용하여 이를 클러스터의 모든 NGINX Plus 인스턴스에 분산합니다. 이 인스턴스는 내부 네트워크로 연결됩니다. 각 NGINX Plus 인스턴스의 캐싱 가상 서버("캐시 VS")는 내부 IP 주소에서 해당 요청의 공유 부분을 수신하고 이를 원본 서버로 전달하고 응답을 캐싱합니다. 이를 통해 모든 NGINX Plus 인스턴스가 캐싱 서버 역할을 하여 캐시 용량을 극대화할 수 있습니다.

1차 "핫" 캐시 구성

또는 매우 인기 있는 콘텐츠에 대해 프런트엔드 LB 계층에 1차 캐시를 구성하고, 대용량 공유 캐시를 2차 캐시로 사용할 수 있습니다. 이렇게 하면 2차 캐시 계층에 장애가 발생해도 원본 서버에 미치는 영향을 줄이고 성능을 향상시킬 수 있습니다. 1차 캐시 콘텐츠가 점차 만료될 때만 콘텐츠를 새로 고치면 되기 때문입니다.

캐시 클러스터가 매우 많은 양의 인기 콘텐츠를 처리하는 경우 더 작은 1차 캐시의 이탈률이 매우 높다는 것을 알 수 있습니다. 다시 말해, 캐시의 제한된 공간에 대한 수요가 너무 높아서 최근에 요청된 콘텐츠를 위한 공간을 확보하기 위해 콘텐츠가 캐시에서 제거된 후에야 후속 요청을 충족시키는 데 사용될 수 있게 됩니다.

이러한 상황을 나타내는 한 가지 지표는 제공된 콘텐츠와 작성된 콘텐츠의 비율이 낮다는 것입니다. 이 두 가지 지표는 NGINX Plus API 모듈 에서 보고하는 확장 통계에 포함됩니다. 이러한 정보는 내장된 라이브 활동 모니터링 대시보드 의 캐시 탭에 있는 제공됨 및 작성됨 필드에 나타납니다. ( NGINX Plus API 모듈과 라이브 활동 모니터링 대시보드는 NGINX 오픈 소스에서 사용할 수 없습니다.)

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

이 경우, 가장 자주 요청되는 콘텐츠만 저장하도록 캐시를 미세 조정할 수 있습니다. proxy_cache_min_uses 지시어는 이 콘텐츠를 식별하는 데 도움이 될 수 있습니다.

요약

여러 NGINX 또는 NGINX Plus 웹 캐시 서버에 캐시를 분할하는 것은 매우 고용량의 확장 가능한 캐시를 만드는 효과적인 방법입니다. 일관된 해시는 높은 수준의 고가용성을 제공하여 캐시에 오류가 발생하는 경우 캐시된 콘텐츠 중에서 해당 캐시된 부분만 무효화되도록 보장합니다.

이 게시물의 두 번째 부분에서는 NGINX 또는 NGINX Plus 캐시 서버 쌍에서 캐시를 복제하는 대체 공유 캐시 패턴을 설명합니다. 총 용량은 개별 서버의 용량으로 제한되지만, 구성은 완벽한 내결함성을 갖추고 있으며 캐시 서버를 사용할 수 없게 되어도 캐시된 콘텐츠는 손실되지 않습니다.

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