Azure Managed Redis(미리 보기) 관리 FAQ

TLS를 사용하는 것이 거의 모든 Redis 사용 사례에서 모범 사례로 권장됩니다. 이전 버전과의 호환성을 위해 TLS 없이 연결하는 옵션이 포함되어 있습니다.

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

StackExchange.Redis 모범 사례

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

구성 및 개념

• Redis는 메모리 내 데이터 저장소입니다. 자세한 내용은 데이터 손실이 발생할 수 있는 시나리오를 인식할 수 있도록 Azure Managed Redis 의 데이터 손실 문제를 참조하세요.
• 패치 및 장애 조치(failover)로 인한 연결 블립을 처리할 수 있도록 시스템을 개발합니다.

성능 테스트

• Azure Managed Redis에서 고유한 성능 테스트를 실행하기 위한 벤치마크 및 지침은 Azure Managed Redis를 사용한 성능 테스트를 참조하세요.

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

• 캐시 진단을 사용하도록 설정하면 캐시의 상태를 모니터링할 수 있습니다. Azure 포털에서 메트릭을 볼 수 있으며 선택한 도구를 사용하여 메트릭을 다운로드 및 검토 할 수도 있습니다.
• Azure Managed Redis에서 고유한 성능 테스트를 실행하기 위한 벤치마크 및 지침은 Azure Managed Redis를 사용한 성능 테스트를 참조하세요.

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)를 사용합니다.

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

  참고 항목

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

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

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

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

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

다음 단계

다른 Azure Managed Redis FAQ에 대해 알아봅니다.