Azure Cache for Redis 관리 FAQ

Redis 서버는 기본적으로 TLS를 지원하지 않지만, Azure Cache for Redis는 이를 지원합니다. Azure Cache for Redis에 연결하고 클라이언트에서 StackExchange.Redis와 같은 TLS를 지원하는 경우 TLS를 사용합니다.

redis-cli와 같은 Redis 도구는 TLS 포트에서 작동하지 않지만, Redis용 ASP.NET 세션 상태 제공자 미리 보기 릴리스 발표 블로그 게시물의 지침에 따라 stunnel과 같은 유틸리티를 사용하여 도구를 TLS 포트에 안전하게 연결할 수 있습니다.

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

• StackExchange.Redis 모범 사례
• 구성 및 개념
• 성능 테스트

StackExchange.Redis 모범 사례

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

구성 및 개념

• 프로덕션 시스템에 대해 표준 또는 프리미엄 계층을 사용합니다. 기본 계층은 데이터 복제 및 SLA가 없는 단일 노드 시스템입니다. 또한 C1 이상의 캐시를 사용합니다. C0 캐시는 일반적으로 간단한 개발/테스트 시나리오에 사용됩니다.
• Redis는 메모리 내 데이터 저장소입니다. 자세한 내용은 데이터 손실이 발생할 수 있는 시나리오를 인식할 수 있도록 Azure Cache for Redis의 데이터 손실 문제 해결을 참조하세요.
• 패치 및 장애 조치(failover)로 인한 연결 블립을 처리할 수 있도록 시스템을 개발합니다.

성능 테스트

• 자체 성능 테스트를 작성하기 전에 먼저 redis-benchmark.exe를 사용하여 가능한 처리량을 확인하세요. redis-benchmark는 TLS를 지원하지 않으므로 테스트를 실행하기 전에 Azure Portal을 통해 비 TLS 포트를 사용하도록 설정해야 합니다. 예를 들어 내 캐시의 성능을 어떻게 벤치마크 및 테스트할 수 있나요?
• 테스트에 사용되는 클라이언트 VM은 Azure Cache for Redis 인스턴스와 동일한 지역에 있어야 합니다.
• Dv2 VM 시리즈는 하드웨어 성능이 더 우수하고 최상의 결과를 제공하므로 클라이언트에 이 시리즈를 사용하는 것이 좋습니다.
• 선택한 클라이언트 VM에는 적어도 테스트 중인 캐시만큼의 컴퓨팅 및 대역폭 성능이 있어야 합니다.
• Windows에서 작업하는 경우 클라이언트 컴퓨터에서 VRSS를 사용하도록 설정합니다. 자세한 내용은 여기를 참조하세요.
• 프리미엄 계층 Redis 인스턴스는 CPU와 네트워크 모두에 대해 더 나은 하드웨어에서 실행되므로 더 나은 네트워크 대기 시간과 처리량을 제공합니다.

• 완료하는 데 오래 걸리는 특정 Redis 명령은 이러한 명령의 결과를 완전히 이해하는 경우에만 사용해야 합니다. 예를 들어 KEYS 명령은 프로덕션에서 실행하지 마세요. 키 수에 따라 반환되는 데 시간이 오래 걸릴 수 있습니다. Redis는 단일 스레드 서버이며 한 번에 하나씩 명령을 처리합니다. KEYS 후에 실행되는 다른 명령이 있는 경우 Redis는 먼저 KEYS 명령을 처리한 후에 해당 명령을 처리합니다. redis.io 사이트 에는 지원되는 각 작업에 대한 시간 복잡도와 관련된 세부 정보가 제공됩니다. 각 작업에 대한 복잡성을 확인하려면 각 명령을 선택합니다.
• 키 크기 - 작은 키/값을 사용해야 하나요, 아니면 큰 키/값을 사용해야 하나요? 이는 시나리오에 따라 달라집니다. 시나리오에서 큰 키가 필요한 경우 ConnectionTimeout 및 다시 시도 값을 조정한 다음 다시 시도 논리를 조정할 수 있습니다. Redis 서버 관점에서는 값이 작을수록 성능이 향상됩니다.
• 이러한 고려 사항이 Redis에서 큰 값을 저장할 수 없다는 의미는 아닙니다. 다음과 같은 고려 사항에 주의해야 합니다. 대기 시간이 더 길어집니다. 더 큰 데이터 세트와 더 작은 데이터 세트가 있는 경우 여러 ConnectionMultiplexer 인스턴스를 사용할 수 있습니다. 이전의 StackExchange.Redis 구성 옵션은 어떤 기능을 수행하나요? 섹션에서 설명한 대로 서로 다른 시간 제한 및 다시 시도 값 세트를 사용하여 각각을 구성합니다.

• 캐시 진단을 사용하도록 설정하면 캐시의 상태를 모니터링할 수 있습니다. Azure 포털에서 메트릭을 볼 수 있으며 선택한 도구를 사용하여 메트릭을 다운로드 및 검토 할 수도 있습니다.
• redis-benchmark.exe를 사용하여 Redis 서버를 부하 테스트할 수 있습니다.
• 부하 테스트 클라이언트와 Azure Cache for Redis가 동일한 지역에 있는지 확인합니다.
• redis-cli.exe를 사용하고 INFO 명령을 통해 캐시를 모니터링합니다.
• 부하로 인해 높은 메모리 조각화가 발생하는 경우 더 큰 캐시 크기로 확장해야 합니다.
• Redis 도구 다운로드에 대한 지침은 어떻게 Redis 명령을 실행할 수 있나요? 섹션을 참조하세요.

redis-benchmark.exe를 사용하는 몇 가지 예제는 다음과 같습니다. 이러한 명령은 정확한 results.cache-development-faq.yml을 위해 캐시와 동일한 지역의 VM에서 실행합니다.

• 1K 페이로드를 사용하여 파이프라인 SET 요청 테스트

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

• 1K 페이로드를 사용하여 파이프라인 GET 요청 테스트

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

CLR ThreadPool에는 두 가지 유형의 스레드 - "작업자" 및 "I/O 완료 포트"(IOCP) 스레드가 있습니다.

• 작업자 스레드는 Task.Run(…) 또는 ThreadPool.QueueUserWorkItem(…) 메서드를 처리하는 등의 작업에 사용됩니다. 이러한 스레드는 작업을 백그라운드 스레드에서 수행해야 할 경우에 CLR에서 다양한 구성 요소에서 사용됩니다.
• IOCP 스레드는 비동기 IO가 발생하는 경우(예: 네트워크에서 읽을 때) 사용됩니다.

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

기존(사용 중) 스레드의 수가 스레드의 "최소" 수에 도달하면 ThreadPool은 500밀리초당 하나의 스레드에 새 스레드를 삽입하는 비율을 제한합니다. 일반적으로 시스템에서는 IOCP 스레드가 필요한 작업이 폭주하면 해당 작업을 신속하게 처리합니다. 그러나 버스트가 구성된 "최소" 설정보다 많은 경우 ThreadPool에서 두 가지 가능성 중 하나를 기다리므로 일부 작업을 처리하는 데 약간의 지연이 있습니다.

• 기존 스레드는 작업을 처리할 수 있는 상태가 됩니다.
• 500ms 동안 기존 스레드가 비워지지 않으면 새 스레드가 만들어집니다.

기본적으로 사용 중인 스레드의 수가 최소 스레드 수보다 큰 경우 네트워크 트래픽이 애플리케이션에서 처리되기 전에 500ms 지연에 대한 비용을 지불할 수도 있습니다. 또한 기존 스레드가 15초를 초과하여 유휴 상태로 있으면 정리되고, 이러한 증가 및 축소 주기가 반복될 수 있습니다.

StackExchange.Redis(빌드 1.0.450 이상)의 오류 메시지 예제를 살펴보면 이제 ThreadPool 통계가 출력된다는 것을 알 수 있습니다. 자세한 내용은 아래의 IOCP 및 WORKER를 참조하세요.

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 및 작업자 스레드에 대해 기본값보다 큰 값으로 최소 구성 값을 설정하는 것이 좋습니다. 하나의 애플리케이션에 대한 올바른 값은 다른 애플리케이션에 대해 너무 높거나 낮을 수 있으므로 이 값에 대해 모든 지침에 맞는 하나의 크기를 제공할 수 없습니다. 이 설정은 복잡한 애플리케이션에서 다른 부분의 성능에 영향을 줄 수 있으므로 각 고객은 특정 요구 사항에 맞게 이 설정을 미세 조정해야 합니다. 좋은 시작 지점은 200 또는 300이며 필요에 따라 테스트 및 조정합니다.

이 설정을 구성하는 방법

• global.asax.cs에서 ThreadPool.SetMinThreads (...) 메서드를 사용하여 프로그래밍 방식으로 이 설정을 변경하는 것이 좋습니다. 예시:

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

  참고 항목

  이 메서드로 지정된 값은 전역 설정으로, 전체 AppDomain에 영향을 미칩니다. 예를 들어 4개의 코어 머신이 있으며 런타임 중에 minWorkerThreads 및 minIoThreads를 CPU당 50으로 설정하려는 경우 ThreadPool.SetMinThreads(200, 200)을 사용합니다.

• Machine.config의 <processModel> 구성 요소 아래에 있는 minIoThreads 또는 minWorkerThreads 구성 설정을 사용하여 최소 스레드 수 설정을 지정할 수도 있습니다. Machine.config는 일반적으로 %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\에 있습니다. 최소 스레드 수를 이 방식으로 설정하는 것은 시스템 수준 설정이므로 권장되지 않습니다.

  참고 항목

  이 구성 요소에 지정된 값은 코어당 설정입니다. 예를 들어 4코어 컴퓨터가 있고 minIOThreads 설정을 런타임 시 200으로 지정하려는 경우 <processModel minIoThreads="50"/>를 사용합니다.

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

• 서버 GC를 사용하도록 설정하려면
• 가비지 수집 기본 사항
• 가비지 수집 및 성능

가격 책정 계층마다 클라이언트 연결, 메모리 및 대역폭에 대한 제한이 다릅니다. 각 캐시 크기는 일정 횟수의 연결‘까지’ 허용하지만 Redis에 대한 각 연결에는 오버헤드가 연결되어 있습니다. 이러한 오버헤드의 예로 TLS/SSL 암호화로 인한 CPU 및 메모리 사용량이 있습니다. 특정 캐시 크기에 대한 최대 연결 제한은 부하가 적은 캐시를 가정합니다. 연결 오버헤드의 부하 ‘그리고’ 클라이언트 작업의 부하가 시스템의 용량을 초과하면 현재 캐시 크기에 대한 연결 제한을 초과하지 않은 경우에도 캐시에 용량 문제가 발생할 수 있습니다.

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

다음 단계

다른 Azure Cache for Redis FAQ에 대해 알아보세요.