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

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

편집자 주 – 이 글은 대용량·고가용성 캐싱에 관한 시리즈의 첫 번째 글입니다:

• 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대의 서버에 균등하게 분산됩니다. 반면 더 단순한 해싱 방식은 전체 캐시를 나머지 서버에 재분배하므로, 재분배 과정에서 캐시의 거의 전부를 잃게 됩니다.

When you perform 일관된 해시 부하 분산을 수행할 때는 캐시 키(또는 키를 구성하는 데 사용되는 필드의 일부)를 일관된 해시의 키로 사용하세요:

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;
}

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

샤딩된 캐시 구성 최적화

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

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

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

1단계 “핫” 캐시 구성

또는 자주 요청되는 콘텐츠를 위해 프런트엔드 LB 계층에 1차 캐시를 구성하고, 대규모 공유 캐시를 2차 캐시로 사용할 수 있습니다. 이렇게 하면 성능이 향상되며, 2차 캐시 계층에 장애가 발생하더라도 1차 캐시의 콘텐츠가 점진적으로 만료될 때만 콘텐츠를 새로 고치면 되므로 오리진 서버에 미치는 영향을 줄일 수 있습니다.

캐시 클러스터에서 매우 많은 양의 인기 콘텐츠를 처리하는 경우, 용량이 더 작은 1단계 캐시의 교체율이 매우 높을 수 있습니다. 즉, 제한된 캐시 공간에 대한 수요가 너무 높아 콘텐츠가 이후 요청을 단 한 번도 처리하지 못한 채 캐시에서 제거되어 더 최근에 요청된 콘텐츠를 위한 공간을 확보하게 됩니다.

이러한 상황을 나타내는 한 가지 지표는 제공된 콘텐츠와 기록된 콘텐츠의 비율이 낮다는 것입니다. 이 두 메트릭은 NGINX Plus API module에서 보고하는 확장 통계에 포함됩니다. 이러한 메트릭은 기본 제공 Served 및 Written 필드의 Caches 탭에 있는 live activity monitoring dashboard에 표시됩니다. (NGINX Plus API module 및 live activity monitoring dashboard는 NGINX Open Source에서 사용할 수 없습니다.)

이 스크린샷은 NGINX Plus가 캐시에서 제공하는 콘텐츠보다 캐시에 기록하는 콘텐츠가 더 많은 상황을 보여줍니다:

이 경우 가장 자주 요청되는 콘텐츠만 저장하도록 캐시를 세부 조정할 수 있습니다. proxy_cache_min_uses 지시어를 사용하면 이러한 콘텐츠를 식별할 수 있습니다.

요약

캐시를 여러 NGINX 또는 NGINX Plus 웹 캐시 서버에 샤딩하면 용량이 매우 크고 확장 가능한 캐시를 효과적으로 구축할 수 있습니다. 일관된 해시는 높은 수준의 가용성을 제공하므로 캐시 하나에 장애가 발생하더라도 해당 캐시가 담당하는 캐시 콘텐츠만 무효화됩니다.

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

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

작성자 소개

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

Owen Garrett의 다른 블로그 게시물