학습
모듈
.NET Aspire 프로젝트의 캐시를 사용하여 성능 개선 - Training
이 모듈에서는 .NET Aspire 클라우드 네이티브 앱의 캐시와 이를 사용하여 마이크로 서비스 성능을 최적화하는 방법에 대해 알아봅니다.
적시에 응답을 받지 않는 클라이언트 작업으로 인해 대기 시간이 높거나 시간 제한 예외가 발생할 수 있습니다. 작업은 다양한 단계에서 시간 초과할 수 있습니다. 시간 제한이 발생하는 위치는 원인과 완화를 확인하는 데 도움이 됩니다.
이 섹션에서는 Azure Managed Redis(미리 보기)에 연결할 때 발생하는 대기 시간 및 시간 제한 문제에 대한 문제 해결에 대해 설명합니다.
참고
이 가이드에 나오는 문제 해결 단계 중 몇 가지는 Redis 명령을 실행하고 다양한 성능 메트릭을 모니터링하는 것을 포함합니다. 자세한 내용 및 지침은 추가 정보 섹션의 문서를 참조합니다.
클라이언트 쪽 문제 해결은 다음과 같습니다.
트래픽 버스트와 잘못된 ThreadPool
설정이 결합되면 Redis 서버에서 이미 전송되었지만 클라이언트 측에서 아직 사용되지 않은 데이터를 처리하는 데 지연이 발생할 수 있습니다. 메트릭 “오류”(형식: UnresponsiveClients)를 확인하여 클라이언트 호스트가 트래픽의 급격한 급증을 따라갈 수 있는지 확인합니다.
예제 ThreadPoolLogger
를 사용하여 ThreadPool
통계가 시간에 따라 어떻게 바뀌는지 모니터링합니다. StackExchange.Redis의 TimeoutException
메시지를 사용하여 자세히 조사를 할 수 있습니다.
System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)
앞의 예외에는 몇 가지 흥미로운 문제가 있습니다.
IOCP
섹션과 WORKER
섹션에 Min
값보다 큰 Busy
값이 있습니다. 이러한 차이는 ThreadPool
설정을 조정해야 한다는 것을 나타냅니다.in: 64221
도 볼 수 있습니다: 이 값은 64,221바이트를 클라이언트의 커널 소켓 계층에서 받았지만 애플리케이션에서 아직 읽지 않았음을 나타냅니다. 이 차이는 일반적으로 애플리케이션(예: StackExchange.Redis)이 데이터를 서버에서 보내는 만큼 빠르게 네트워크로부터 읽지 못하고 있음을 의미합니다.ThreadPool
설정을 구성하여 버스트 시나리오에서 스레드 풀이 신속하게 스케일 업할 수 있도록 합니다.
여러 키와 더 작은 값을 사용하는 방법에 대한 자세한 내용은 더 많은 키와 더 작은 값 고려를 참조하세요.
redis-cli --bigkeys
명령을 사용하여 캐시에서 큰 키를 확인할 수 있습니다. 자세한 내용은 redis-cli, Redis 명령줄 인터페이스--Redis를 참조하세요.
클라이언트 CPU 사용량이 높다는 것은 시스템이 할당된 작업을 따라잡을 수 없다는 것을 의미합니다. 캐시가 신속하게 응답을 전송해도 클라이언트가 제시간에 응답을 처리하지 못할 수 있습니다. 클라이언트 CPU를 80% 미만으로 유지하는 것이 좋습니다. 메트릭 “오류”(유형: UnresponsiveClients
)를 확인하여 클라이언트 호스트가 Redis 서버의 응답을 제 시간에 처리할 수 있는지 확인합니다.
Azure Portal에서 제공하는 메트릭을 사용하거나 머신의 성능 카운터를 통해 클라이언트의 시스템 전체 CPU 사용량을 모니터링하세요. 단일 프로세스는 CPU 사용량이 낮지만 시스템 전체 CPU 사용량은 높을 수 있으므로 프로세스 CPU를 모니터링하지 않도록 주의합니다. CPU 사용량에서 제한 시간에 해당 하는 급증을 확인합니다. [트래픽 버스트] 섹션에 설명된 대로 높은 CPU는 TimeoutException
오류 메시지의 in: XXX
값을 높이는 원인이 될 수도 있습니다.
참고
StackExchange.Redis 1.1.603 이상은 TimeoutException
오류 메시지에 local-cpu
매트릭을 포함합니다. StackExchange.Redis NuGet 패키지의 최신 버전을 사용 중인지 확인합니다. 버그가 코드에서 정기적으로 수정되어 시간 제한에 대한 강력한 기능을 제공합니다. 최신 버전을 보유하는 것이 중요합니다.
클라이언트의 높은 CPU 사용량을 완화하려면 다음을 수행합니다.
클라이언트 컴퓨터의 아키텍처에 따라, 클라이언트 컴퓨터는 어느 정도의 네트워크 대역폭을 사용할 수 있는지에 제한이 있습니다. 클라이언트가 네트워크 용량을 오버로드하여 사용 가능한 대역폭을 초과하면 서버에서 보내는 만큼 신속하게 클라이언트 쪽에서 데이터가 처리되지 않습니다. 이 경우 시간이 초과될 수 있습니다.
예제 BandwidthLogger
를 사용하여 대역폭 사용량이 시간에 따라 어떻게 바뀌는지 모니터링합니다. 이 코드는 (Azure 웹 사이트와 같이) 권한이 제한된 일부 환경에서 성공적으로 실행되지 않을 수도 있습니다.
이 문제를 완화하려면 네트워크 대역폭 소비를 줄이거나 클라이언트 VM 크기를 네트워크 용량이 더 많은 크기로 늘리세요. 자세한 내용은 큰 요청 또는 응답 크기를 참조하세요.
Linux의 낙관적 TCP 설정으로 인해 Linux에서 호스트되는 클라이언트 애플리케이션에 연결 문제가 발생할 수 있습니다. 자세한 내용은 Linux 호스팅 클라이언트 애플리케이션에 대한 TCP 설정을 참조하세요.
RedisSessionStateProvider
를 사용하는 경우 다시 시도 시간 제한을 올바르게 설정했는지 확인합니다 retryTimeoutInMilliseconds
값이 operationTimeoutInMilliseconds
값보다 높아야 합니다. 그렇지 않으면 다시 시도하지 않습니다. 다음 예제에서 retryTimeoutInMilliseconds
가 3,000으로 설정됩니다. 자세한 내용은 ASP.NET Azure Managed Redis용 세션 상태 공급자 및 세션 상태 공급자 및 출력 캐시 공급자의 구성 매개 변수를 사용하는 방법을 참조하세요.
<add
name="AFRedisCacheSessionStateProvider"
type="Microsoft.Web.Redis.RedisSessionStateProvider"
host="enbwcache.eastus.redis.azure.net"
port="10000"
accessKey="..."
ssl="true"
databaseId="0"
applicationName="AFRedisCacheSessionState"
connectionTimeoutInMilliseconds = "5000"
operationTimeoutInMilliseconds = "1000"
retryTimeoutInMilliseconds="3000"
>
계획되거나 계획되지 않은 유지 관리로 인해 클라이언트 연결이 중단될 수 있습니다. 예외의 수와 유형은 코드 경로에서 요청의 위치와 캐시가 연결을 닫는 시점에 따라 달라집니다. 예를 들어, 요청을 보냈지만 장애 조치(failover)가 발생할 때 응답을 받지 못한 작업에서 시간 제한 예외가 발생할 수 있습니다. 닫힌 연결 개체에 대한 새 요청은 다시 연결이 성공적으로 발생할 때까지 연결 예외를 수신합니다.
자세한 내용은 연결 복원력을 참조하세요.
CPU가 높으면 Redis 서버가 요청을 따라갈 수 없으므로 시간이 초과됩니다. 서버의 응답 속도가 느려지고 요청 속도를 따라가지 못할 수 있습니다.
CPU와 같은 메트릭을 모니터링합니다 . CPU
사용량에서 제한 시간에 해당하는 급증을 확인합니다. CPU의 메트릭에 대한 경고를 만들어 잠재적인 영향에 대해 초기에 알려 줍니다.
높은 CPU를 완화하기 위해 수행할 수 있는 몇 가지 변경 사항이 있습니다.
B0, B1, B3 및 B5 캐시에서 내부 Defender 검색이 VM에서 실행되는 동안 하루에 몇 번 요청 증가로 인해 CPU가 짧은 급증을 볼 수 있습니다. 이러한 계층에서 내부 Defender 검사가 진행되는 동안 요청 대기 시간이 길어집니다. 이러한 계층의 캐시에는 멀티태스크에 대한 코어가 2개뿐이며 내부 Defender 검사 및 Redis 요청을 제공하는 작업을 구분합니다.
자세한 내용은 상위 메모리 사용량을 참조하세요.
일부 Redis 명령 실행은 다른 명령에 비해 비용이 많이 듭니다. Redis 명령 설명서는 각 명령의 시간 복잡성을 보여 줍니다. Redis 명령 처리는 단일 스레드입니다. 실행하는 데 시간이 오래 걸리는 명령은 명령 뒤에 오는 다른 모든 명령을 차단할 수 있습니다.
Redis 서버에 실행하는 명령을 검토하여 성능에 미치는 영향을 파악합니다. 예를 들어, KEYS 명령은 O(N) 작업이라고 알지 못해도 자주 사용됩니다. SCAN을 사용하여 CPU 급증을 줄이는 KEYS를 방지할 수 있습니다.
SLOWLOG GET 명령을 사용하여 서버에 대해 실행되는 비용이 많이 드는 명령을 측정할 수 있습니다.
고객은 콘솔을 사용하여 이러한 Redis 명령을 실행하여 장기 실행 및 비용이 많이 드는 명령을 조사할 수 있습니다.
SLOWLOG
명령을 사용하여 Redis 서버에 대해 실행되는 비용이 많이 드는 명령을 측정/로그할 수 있습니다.출력 샘플입니다.
# CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1
캐시 크기가 다르면 네트워크 대역폭 용량도 다릅니다. 서버가 사용 가능한 대역폭을 초과하면 데이터가 클라이언트에게 신속하게 전송되지 않습니다. 서버에서 클라이언트로 데이터를 충분히 빠르게 푸시할 수 없어서 클라이언트 요청이 시간 초과될 수 있습니다.
"Cache Read" 및 "Cache Write" 메트릭을 사용하여 서버 쪽 대역폭의 사용량을 확인할 수 있습니다. 포털을 사용하여 이러한 메트릭을 볼 수 있습니다. 캐시 읽기 또는 캐시 쓰기와 같은 메트릭에 잠재적 영향을 초기에 알리도록 경고를 만듭니다.
네트워크 대역폭 사용량이 최대 용량에 근접하는 상황을 완화하려면 다음을 수행합니다.
StackExchange.Redis를 사용할 때 시간 제한을 해결하는 자세한 내용은 StackExchange.Redis에서 시간 제한 예외 조사를 참조하세요.
학습
모듈
.NET Aspire 프로젝트의 캐시를 사용하여 성능 개선 - Training
이 모듈에서는 .NET Aspire 클라우드 네이티브 앱의 캐시와 이를 사용하여 마이크로 서비스 성능을 최적화하는 방법에 대해 알아봅니다.
설명서
Azure Managed Redis(미리 보기) 관리 FAQ - Azure Managed Redis
Azure Managed Redis를 관리하는 데 도움이 되는 일반적인 질문에 대한 답변 알아보기
Azure Managed Redis에 대한 연결 복원력에 대한 모범 사례(미리 보기) - Azure Managed Redis
Azure Managed Redis 연결을 복원력 있게 만드는 방법을 알아봅니다.
Azure Managed Redis의 연결 문제 해결(미리 보기) - Azure Managed Redis
Azure Managed Redis를 사용하여 클라이언트를 만들 때 연결 문제를 해결하는 방법을 알아봅니다.