캐시 관리 FAQ

• Redis 서버의 로드 테스트를 수행하는 데 사용합니다 redis-benchmark.exe . 사용자 고유의 성능 테스트를 작성하기 전에 가능한 처리량을 확인하는 데 사용합니다 redis-benchmark.exe .
• 명령을 사용하여 redis-cli 캐시를 모니터링하는 데 사용합니다INFO. Redis 도구 다운로드에 대한 지침은 Redis 명령을 실행하려면 어떻게 해야 합니까?를 참조하십시오.
• 캐시 인스턴스에서 TLS/SSL(전송 계층 보안/Secure Socket Layer)을 사용하는 경우 Redis 도구 명령에 매개 변수를 추가하거나 --tls TLS/SSL을 사용하도록 설정하는 것과 같은 stunnel 프록시를 사용합니다.
• Redis-benchmark 기본적으로 포트를 6379 사용합니다. -p 캐시가 SSL/TLS 포트 6380 또는 엔터프라이즈 계층 포트를 10000사용하는 경우 매개 변수를 사용하여 이 설정을 재정의합니다.
• 필요한 경우 부하 테스트를 실행하기 전에 Azure Portal을 통해 비 TLS 포트를 사용하도록 설정할 수 있습니다.
• 테스트에 사용하는 클라이언트 VM(가상 머신)이 Azure Cache for Redis 인스턴스와 동일한 지역에 있는지 확인합니다.
• 클라이언트 VM에 최소한 테스트 중인 캐시만큼의 컴퓨팅 및 대역폭 기능이 있는지 확인합니다. 최상의 결과를 얻으려면 클라이언트에 D 시리즈 및 E 시리즈 VM을 사용합니다.
• Windows를 사용하는 경우 클라이언트 컴퓨터에서 VRSS(Virtual Receive-side Scaling)를 사용하도록 설정합니다. 자세한 내용은 Windows Server 2012 R2의 가상 수신측 배율을 참조하세요.
• 캐시 진단을 사용하도록 설정하여 캐시 상태를 모니터링할 수 있습니다. Azure Portal에서 메트릭을 볼 수 있으며, 선택한 도구를 사용하여 메트릭을 다운로드하고 검토할 수도 있습니다.
• 부하로 인해 높은 메모리 조각화가 발생하는 경우 더 큰 캐시 크기로 확장하십시오.

다음 예제에서는 를 사용하는 redis-benchmark.exe방법을 보여 줍니다. 정확한 결과를 위해 캐시와 동일한 지역에 있는 VM에서 이러한 명령을 실행합니다.

먼저 1k 페이로드를 사용하여 파이프라인된 SET 요청을 테스트합니다.

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

테스트를 실행한 SET 후 1k 페이로드를 사용하여 파이프라인된 GET 요청을 실행합니다.

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

서버 GC(가비지 수집)를 사용하도록 설정하면 클라이언트를 최적화하고 StackExchange.Redis를 사용할 때 더 나은 성능과 처리량을 제공할 수 있습니다. 서버 GC 및 사용하도록 설정하는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.

• <gcServer> 요소
• 가비지 수집의 기본 사항
• 가비지 수집 및 성능

Redis 서버는 기본적으로 TLS(전송 계층 보안)를 지원하지 않지만 Azure Cache for Redis는 TLS를 지원합니다. TLS를 지원하는 StackExchange.Redis와 같은 클라이언트를 사용하여 Azure Cache for Redis에 연결하는 경우 TLS를 사용합니다.

캐시가 TLS를 사용하는 경우 와 같은 --tlsRedis 도구에 대한 옵션을 사용하여 TLS를 redis-cli 활성화해야 합니다. Redis용 stunnel 블로그 게시물의 지침에 따라 도구를 TLS 포트에 안전하게 연결하는 등의 유틸리티를 사용할 수도 있습니다.

Redis 도구 다운로드에 대한 지침은 Redis 명령을 실행하려면 어떻게 해야 합니까?를 참조하십시오.

• 완료하는 데 오래 걸리는 특정 Redis 명령은 이러한 명령의 결과를 완전히 이해하는 경우에만 사용해야 합니다. 예를 들어 KEYS 명령은 프로덕션에서 실행하지 마세요. 키 수에 따라 반환되는 데 시간이 오래 걸릴 수 있습니다. Redis는 한 번에 하나씩 명령을 처리하는 단일 스레드 서버입니다. 명령을 실행하면 KEYS Redis는 명령 처리를 KEYS 완료할 때까지 후속 명령을 처리하지 않습니다.

  redis.io 사이트에는 지원하는 각 작업에 대한 시간 복잡도 세부 정보가 있습니다. 각 작업에 대한 복잡성을 확인하려면 각 명령을 선택합니다.

• 사용할 키 크기는 시나리오에 따라 다릅니다. 시나리오에 더 큰 키가 필요한 경우 , 재시도 값을 조정하고 ConnectionTimeout재시도 논리를 조정할 수 있습니다. Redis 서버 관점에서 키 값이 작을수록 성능이 향상됩니다.

• 이러한 고려 사항이 Redis에 더 큰 값을 저장할 수 없다는 의미는 아니지만 대기 시간이 더 높습니다. 한 데이터 집합이 다른 데이터 집합보다 큰 경우 각각 다른 시간 제한 및 재시도 값 집합으로 구성된 여러 ConnectionMultiplexer 인스턴스를 사용할 수 있습니다. 자세한 내용은 StackExchange.Redis 구성 옵션의 기능을 참조하세요.

각 Azure Cache for Redis 가격 책정 계층에는 클라이언트 연결, 메모리 및 대역폭에 대한 제한이 다릅니다. 각 캐시 크기는 최대 몇 개의 연결을 허용하지만 Redis에 대한 각 연결에는 연결된 오버헤드가 포함됩니다. 이러한 오버헤드의 예로는 TLS/SSL 암호화로 인한 CPU 및 메모리 사용량이 있습니다.

특정 캐시 크기에 대한 최대 연결 제한은 부하가 적은 캐시를 가정합니다. 연결 오버헤드의 부하 와 클라이언트 작업의 부하가 시스템 용량을 초과하는 경우 현재 캐시 크기에 대한 연결 제한을 초과하지 않더라도 캐시에서 용량 문제가 발생할 수 있습니다.

각 계층의 연결 제한에 대한 자세한 내용은 Azure Cache for Redis 가격 책정을 참조하세요. 연결 및 기타 기본 구성에 대한 정보는 기본 Redis 서버 구성을 참조하세요.

• 프로덕션 시스템에 표준 또는 프리미엄 계층을 사용합니다. 기본 계층은 데이터 복제가 없고 SLA(서비스 수준 계약)가 없는 단일 노드 시스템입니다. 또한 프로덕션에 C1 캐시 이상을 사용합니다. C0 캐시는 일반적으로 간단한 개발/테스트 시나리오에 사용됩니다.
• Redis는 메모리 내 데이터 저장소이며 일부 시나리오에서는 데이터 손실이 발생할 수 있습니다. 자세한 내용은 Azure Cache for Redis의 데이터 손실 문제 해결을 참조하세요.
• 패치 및 장애 조치로 인한 연결 블립을 처리할 수 있도록 시스템을 개발합니다.
• 프리미엄 계층 Azure Redis 인스턴스는 CPU와 네트워크 모두에 더 나은 하드웨어를 제공하므로 네트워크 대기 시간 및 처리량을 개선하려면 인스턴스를 사용합니다.

StackExchange.Redis 모범 사례

• false AbortConnect 로 설정하면 ConnectionMultiplexer 자동으로 다시 연결됩니다.
• 각 요청에 대해 새 연결을 만드는 대신 수명이 긴 단일 ConnectionMultiplexer 인스턴스를 사용합니다.
• Redis는 더 작은 값에서 가장 잘 작동하므로 더 큰 데이터를 여러 개의 키로 분할하는 것을 고려합니다. 예를 들어 redis의 이상적인 값 크기 범위는 무엇입니까?에서 100kb는 큰 것으로 간주됩니다. 자세한 내용은 더 많은 키와 더 작은 값 고려를 참조하세요.
• 시간 초과를 방지하도록 ThreadPool 설정 을 구성합니다.
• 기본값 connectTimeout 인 5초 이상을 사용합니다. 이 간격은 네트워크 블립이 있는 경우 StackExchange.Redis에 연결을 다시 설정할 수 있는 충분한 시간을 제공합니다.
• 실행하는 다양한 작업과 관련된 성능 비용을 알고 있어야 합니다. 예를 들어 KEYS 명령은 O(n) 작업이므로 피해야 합니다. redis.io 사이트에는 지원하는 각 작업의 시간 복잡도에 대한 세부 정보가 있습니다. 각 작업에 대한 복잡성을 확인하려면 각 명령을 선택합니다.

CLR(공용 언어 런타임) ThreadPool에는 작업자와 IOCP(I/O 완료 포트)의 두 가지 유형의 스레드가 있습니다.

• WORKER스레드는 , 또는 Task.Run(…) 메소드를 ThreadPool.QueueUserWorkItem(…)처리하는 것과 같은 작업에 사용됩니다. CLR의 다양한 구성 요소도 백그라운드 스레드에서 작업을 수행해야 할 때 이러한 스레드를 사용합니다.
• IOCP 스레드는 네트워크에서 읽을 때와 같이 비동기 I/O에 사용됩니다.

스레드 풀은 각 스레드 유형에 대한 설정에 도달할 minimum 때까지 제한 없이 요청 시 새 작업자 스레드 또는 I/O 완료 스레드를 제공합니다. 기본적으로 최소 스레드 수는 시스템에서 프로세서의 수로 설정됩니다.

기존 사용 중인 스레드의 수가 스레드 수에 도달하면 minimum ThreadPool은 500밀리초당 하나의 스레드에 새 스레드를 삽입하는 속도를 제한합니다.

일반적으로 시스템에서 스레드가 필요한 IOCP 작업이 급증하면 해당 작업을 신속하게 처리합니다. 그러나 버스트가 구성된 minimum 설정보다 많으면 ThreadPool이 다음 두 가지 가능성 중 하나를 기다리기 때문에 일부 작업을 처리하는 데 약간의 지연이 있습니다.

• 기존 스레드는 작업을 처리할 수 있는 상태가 됩니다.
• 기존 스레드는 500ms 동안 해제되지 않으므로 새 스레드가 생성됩니다.

기본적으로 스레드 수가 Busy 스레드보다 Min 많으면 응용 프로그램이 네트워크 트래픽을 처리하기 전에 500ms 지연이 발생합니다. 또한 15초 이상 유휴 상태로 유지되는 기존 스레드는 정리되며 이러한 증가 및 축소 주기가 반복될 수 있습니다.

StackExchange.Redis 빌드 1.0.450 이상의 오류 메시지는 다음 예제와 같이 ThreadPool 통계를 인쇄합니다.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

이 예제에서는 스레드에 IOCP 대해 6개의 사용 중인 스레드가 있고 시스템이 4개의 최소 스레드를 허용하도록 구성되어 있음을 보여 줍니다. 이 경우 클라이언트는 6 > 4.

및 IOCP 스레드의 WORKER 최소 구성 값을 기본값보다 큰 값으로 설정하는 것이 가장 좋습니다. 한 응용 프로그램에 적합한 값이 다른 응용 프로그램에는 너무 높거나 낮을 수 있으므로 이 값에 대한 모든 상황에 적용되는 단일 지침은 없습니다. 이 설정은 복잡한 응용 프로그램의 다른 부분의 성능에도 영향을 줄 수 있습니다. 특정 요구 사항에 맞게 이 설정을 미세 조정해야 합니다. 좋은 시작점은 200 또는 300입니다. 그런 다음 필요에 따라 테스트하고 조정합니다.

최소 스레드 수 설정 구성

ThreadPool.SetMinThreads (...) 메서드를 사용하여 프로그래밍 방식으로 이 설정을 변경할 수 있습니다.

예를 들어, NET Framework에서는 메서드의 Global.asax.cs에서 이 값을 설정합니다.Application_Start

    private readonly int minThreads = 200;
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        ThreadPool.SetMinThreads(minThreads, minThreads);
    }

.NET Core를 사용하는 경우 다음을 호출하기 직전에 Program.cs 값을 설정합니다.WebApplication.CreateBuilder()

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

의 configuration 요소 아래에 minIoThreads 있는 또는 minWorkerThreads구성 설정을 사용하여 <processModel> 최소 스레드 설정을 지정할 수도 Machine.config있습니다. Machine.config 는 일반적으로 %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\에 있습니다.

이러한 방식으로 최소 스레드 수를 설정하는 것은 시스템 전체 설정이므로 권장되지 않습니다. 이러한 방식으로 최소 스레드를 설정하는 경우 응용 프로그램 풀을 다시 시작해야 합니다.

관련 콘텐츠

• 다른 Azure Cache for Redis FAQ를 참조하세요.