Question 1

내 캐시의 성능을 어떻게 벤치마크 및 테스트할 수 있나요?

Accepted Answer

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

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

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

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

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

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

Question 2

StackExchange.Redis를 사용할 때 클라이언트에서 서버 GC를 사용하도록 설정하여 처리량을 늘리려면 어떻게 해야 하나요?

Accepted Answer

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

Question 3

언제 비 TLS/SSL 포트를 사용하여 Redis에 연결할 수 있도록 해야 하나요?

Accepted Answer

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

참고

기본적으로 새로운 Azure Redis 인스턴스에서는 TLS가 아닌 포트가 사용하지 않도록 설정됩니다. 클라이언트가 TLS를 지원하지 않는 경우 액세스 포트의 지침에 따라 TLS가 아닌 포트를 사용하도록 설정합니다.

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

Redis 도구를 다운로드하는 방법에 대한 지침은 Redis 명령을 어떻게 실행할 수 있나요?를 참조하세요.

Question 4

일반적인 Redis 명령을 사용할 때 고려해야 할 사항은 무엇인가요?

Accepted Answer

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

redis.io 사이트에는 지원하는 각 작업에 대한 시간 복잡도 세부 정보가 있습니다. 각 작업에 대한 복잡성을 확인하려면 각 명령을 선택합니다.
어떤 크기의 키를 사용할지는 시나리오에 따라 달라집니다. 시나리오에 더 큰 키가 필요한 경우 ConnectionTimeout을 조정한 다음 값을 다시 시도하고 다시 시도 논리를 조정할 수 있습니다. Redis 서버 관점에서 볼 때, 키 값이 작을수록 성능이 더 좋습니다.
이러한 고려 사항이 Redis에 더 큰 값을 저장할 수 없다는 것을 의미하는 것은 아니지만, 대기 시간이 길어질 수 있습니다. 다른 데이터 집합보다 큰 데이터 집합이 있는 경우 여러 개의 ConnectionMultiplexer 인스턴스를 사용할 수 있으며, 각각은 다른 시간 제한 및 다시 시도 값 집합으로 구성됩니다. 자세한 내용은 StackExchange.Redis 구성 옵션은 무엇을 하나요?를 참조하세요.

Question 5

연결 성능과 관련하여 어떤 고려 사항이 있나요?

Accepted Answer

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

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

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

Question 6

프로덕션 모범 사례에는 어떤 것이 있나요?

Accepted Answer

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

StackExchange.Redis 모범 사례

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

Question 7

ThreadPool 증가에 대한 중요한 세부 정보

Accepted Answer

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이기 때문에 500ms 지연을 두 번 볼 가능성이 높습니다.

참고

IOCP 또는 WORKER 스레드의 성장이 제한되면 StackExchange.Redis에서 시간 제한이 발생할 수 있습니다.

IOCP 및 WORKER 스레드의 최소 구성 값은 기본값보다 큰 값으로 설정하는 것이 가장 좋습니다. 이 값에 대한 일괄적인 지침은 없습니다. 한 애플리케이션에 적합한 값이 다른 애플리케이션에는 너무 높거나 낮을 수 있기 때문입니다. 이 설정은 복잡한 애플리케이션의 다른 부분의 성능에도 영향을 미칠 수 있습니다. 이 설정을 사용자의 특정 요구 사항에 맞게 미세 조정해야 합니다. 적합한 시작 지점은 200 또는 300입니다. 그런 다음 필요에 따라 테스트하고 조정합니다.

최소 스레드 설정 구성

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

예를 들어, NET Framework에서는 메서드의 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를 사용하는 경우 를 호출하기 직전에 WebApplication.CreateBuilder()에 값을 설정합니다.

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

참고

이 메서드에서 지정하는 값은 AppDomain 전체에 영향을 미치는 글로벌 설정입니다. 예를 들어, 4코어 VM이 있고 런타임 동안 CPU당 minWorkerThreads 및 minIoThreads를 50으로 설정하려면 ThreadPool.SetMinThreads(200, 200)을 사용합니다.

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

최소 스레드 수를 이 방식으로 설정하는 것은 시스템 수준 설정이므로 권장되지 않습니다. 이런 방식으로 최소 스레드를 설정하는 경우 애플리케이션 풀을 다시 시작해야 합니다.

참고

이 메서드에서 지정하는 값은 코어당 설정입니다. 예를 들어, 4코어 컴퓨터가 있고 런타임에 minIoThreads 설정을 200으로 설정하려면 을 사용합니다.

다음을 통해 공유

캐시 관리 FAQ