Azure Storage 계정의 성능 문제 해결

아티클
04/10/2024

이 문서는 예기치 않은 동작 변경(예: 평소보다 느린 응답 시간)을 조사하는 데 도움이 됩니다. 이러한 동작 변경 내용은 Azure Monitor에서 스토리지 메트릭을 모니터링하여 식별할 수 있는 경우가 많습니다. Azure Monitor에서 메트릭 및 로그를 사용하는 방법에 대한 일반적인 내용은 다음 문서를 참조하세요.

성능 모니터링

스토리지 서비스의 성능을 모니터링하려면 다음 메트릭을 사용할 수 있습니다.

SuccessE2ELatency 및 SuccessServerLatency 메트릭은 스토리지 서비스 또는 API 작업 유형이 요청을 처리하는 데 걸리는 평균 시간을 보여 줍니다. SuccessE2ELatency 는 요청을 읽고 요청을 처리하는 데 걸린 시간 외에도 응답을 보내는 데 걸린 시간을 포함하는 엔드 투 엔드 대기 시간의 측정값입니다(따라서 요청이 스토리지 서비스에 도달하면 네트워크 대기 시간이 포함됨). SuccessServerLatency 는 처리 시간의 측정값이므로 클라이언트와의 통신과 관련된 네트워크 대기 시간을 제외합니다.
송신 및 수신 메트릭은 스토리지 서비스 또는 특정 API 작업 유형을 통해 들어오고 나가는 총 데이터 양(바이트)을 보여 줍니다.
트랜잭션 메트릭은 API 작업의 스토리지 서비스가 수신하는 총 요청 수를 보여 줍니다. 트랜잭션은 스토리지 서비스에서 수신하는 총 요청 수입니다.

이러한 값 중에서 예기치 않은 변경 내용을 모니터링할 수 있습니다. 이러한 변경 내용은 추가 조사가 필요한 문제를 나타낼 수 있습니다.

Azure Portal 이 서비스에 대한 성능 메트릭이 지정한 임계값보다 낮거나 초과할 때 이를 알리는 경고 규칙을 추가할 수 있습니다.

성능 문제 진단

애플리케이션의 성능은 특히 사용자 관점에서 주관적일 수 있습니다. 따라서 성능 문제가 있을 수 있는 위치를 식별하는 데 도움이 되는 기준 메트릭을 사용할 수 있어야 합니다. 클라이언트 애플리케이션 관점에서 Azure Storage 서비스의 성능에는 많은 요소가 영향을 줄 수 있습니다. 이러한 요소는 스토리지 서비스, 클라이언트 또는 네트워크 인프라에서 작동할 수 있습니다. 따라서 성능 문제의 출처를 식별하기 위한 전략을 갖는 것이 중요합니다.

메트릭에서 성능 문제의 원인의 가능성이 있는 위치를 식별한 후 로그 파일을 사용하여 자세한 정보를 찾아 문제를 추가로 진단하고 해결할 수 있습니다.

메트릭은 높은 SuccessE2ELatency 및 낮은 SuccessServerLatency를 표시합니다.

경우에 따라 SuccessE2ELatency 가 SuccessServerLatency보다 높을 수 있습니다. 스토리지 서비스는 성공적인 요청에 대한 SuccessE2ELatency 메트릭만 계산하며 SuccessServerLatency와 달리 클라이언트가 데이터를 보내고 스토리지 서비스에서 승인을 받는 데 걸리는 시간을 포함합니다. 따라서 SuccessE2ELatency 와 SuccessServerLatency 의 차이는 클라이언트 애플리케이션의 응답 속도가 느리거나 네트워크의 조건으로 인해 발생할 수 있습니다.

참고

스토리지 로깅 로그 데이터에서 개별 스토리지 작업에 대한 E2ELatency 및 ServerLatency 를 볼 수도 있습니다.

클라이언트 성능 문제 조사

클라이언트가 느리게 응답하는 가능한 이유는 사용 가능한 연결 또는 스레드가 제한되거나 CPU, 메모리 또는 네트워크 대역폭과 같은 리소스가 부족하기 때문입니다. 클라이언트 코드를 보다 효율적으로 수정하거나(예: 스토리지 서비스에 대한 비동기 호출 사용) 더 많은 코어와 더 많은 메모리가 있는 더 큰 Virtual Machine을 사용하여 문제를 resolve 수 있습니다.

테이블 및 큐 서비스의 경우 Nagle 알고리즘은 SuccessServerLatency에 비해 SuccessE2ELatency가 높을 수도 있습니다. 자세한 내용은 Nagle 알고리즘이 작은 요청에 대해 친숙하지 않음 게시물을 참조하세요. 네임스페이스의 클래스를 사용하여 코드에서 Nagle 알고리즘을 ServicePointManagerSystem.Net 사용하지 않도록 설정할 수 있습니다. 이미 열려 있는 연결에 영향을 주지 않으므로 애플리케이션에서 테이블 또는 큐 서비스를 호출하기 전에 이 작업을 수행해야 합니다. 다음 예제는 작업자 역할의 Application_Start 메서드에서 가져옵니다.

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

클라이언트 쪽 로그를 검사 클라이언트 애플리케이션이 제출하는 요청 수를 확인하고 CPU, .NET 가비지 수집, 네트워크 사용률 또는 메모리와 같은 클라이언트의 일반적인 .NET 관련 성능 병목 현상에 대해 검사. .NET 클라이언트 애플리케이션 문제 해결을 위한 시작점으로 디버깅, 추적 및 프로파일링을 참조하세요.

네트워크 대기 시간 문제 조사

일반적으로 네트워크로 인한 엔드투엔드 대기 시간이 긴 것은 일시적인 조건 때문입니다. Wireshark와 같은 도구를 사용하여 삭제된 패킷과 같은 일시적 및 영구적 네트워크 문제를 모두 조사할 수 있습니다.

메트릭은 낮은 SuccessE2ELatency 및 낮은 SuccessServerLatency를 표시하지만 클라이언트는 대기 시간이 짧습니다.

이 시나리오에서 가장 가능성이 높은 원인은 스토리지 서비스에 도달하는 스토리지 요청의 지연입니다. 클라이언트의 요청이 Blob 서비스로 연결되지 않는 이유를 조사해야 합니다.

클라이언트가 요청 전송을 지연시키는 한 가지 가능한 이유는 사용 가능한 연결 또는 스레드 수가 제한되어 있기 때문입니다.

또한 클라이언트가 여러 횟수 재시도를 수행하는지 여부를 검사 이유를 조사합니다. 클라이언트가 여러 횟수 재시도를 수행하는지 여부를 확인하려면 다음을 수행할 수 있습니다.

로그를 검사합니다. 여러 횟수 재시도가 발생하는 경우 동일한 클라이언트 요청 ID를 사용하는 여러 작업이 표시됩니다.
클라이언트 로그를 검사합니다. 자세한 정보 로깅은 다시 시도가 발생했음을 나타냅니다.
코드를 디버그하고 요청과 연결된 개체의 OperationContext 속성을 검사. 작업이 다시 시도된 경우 속성에는 RequestResults 여러 고유 요청이 포함됩니다. 각 요청에 대한 시작 및 종료 시간을 검사 수도 있습니다.

클라이언트에 문제가 없는 경우 패킷 손실과 같은 잠재적인 네트워크 문제를 조사해야 합니다. Wireshark와 같은 도구를 사용하여 네트워크 문제를 조사할 수 있습니다.

메트릭은 높은 SuccessServerLatency를 표시합니다.

Blob 다운로드 요청에 대한 SuccessServerLatency 가 높은 경우 스토리지 로그를 사용하여 동일한 Blob(또는 Blob 집합)에 대해 반복된 요청이 있는지 확인해야 합니다. Blob 업로드 요청의 경우 클라이언트가 사용하는 블록 크기를 조사해야 합니다(예: 읽기가 64K 미만인 경우가 아니면 크기가 64K 미만인 블록은 오버헤드가 발생할 수 있습니다). 여러 클라이언트가 동일한 Blob에 블록을 병렬로 업로드하는 경우. 또한 초당 확장성 목표를 초과하는 요청 수의 급증에 대한 분당 메트릭을 검사 합니다.

동일한 Blob 또는 Blob 집합에 대해 반복된 요청이 있을 때 Blob 다운로드 요청에 대한 SuccessServerLatency 가 높은 경우 Azure Cache 또는 AZURE CDN(Content Delivery Network)을 사용하여 이러한 Blob을 캐싱하는 것이 좋습니다. 업로드 요청의 경우 더 큰 블록 크기를 사용하여 처리량을 향상시킬 수 있습니다. 테이블에 대한 쿼리의 경우 동일한 쿼리 작업을 수행하고 데이터가 자주 변경되지 않는 클라이언트에서 클라이언트 쪽 캐싱을 구현할 수도 있습니다.

높은 SuccessServerLatency 값은 검사 작업을 초래하거나 추가/앞에 추가 안티 패턴을 따르는 잘못 디자인된 테이블 또는 쿼리의 증상일 수도 있습니다.

참고

Microsoft Azure Storage 성능 및 확장성 검사 목록에서 포괄적인 성능 검사 목록을 찾을 수 있습니다.

큐에서 메시지 배달이 예기치 않게 지연되는 경우

애플리케이션이 큐에 메시지를 추가하는 시간과 큐에서 읽을 수 있는 시간 사이에 지연이 발생하는 경우 다음 단계를 수행하여 문제를 진단합니다.

애플리케이션이 큐에 메시지를 성공적으로 추가했는지 확인합니다. 애플리케이션이 성공하기 전에 메서드를 AddMessage 여러 번 다시 시도하지 않는지 확인합니다.
큐에 메시지를 추가하는 작업자 역할과 큐에서 메시지를 읽는 작업자 역할 사이에 클록 오차가 없는지 확인합니다. 시계 기울이기는 처리가 지연되는 것처럼 표시됩니다.
큐에서 메시지를 읽는 작업자 역할이 실패하는지 확인합니다. 큐 클라이언트가 메서드를 GetMessage 호출하지만 승인으로 응답하지 않으면 기간이 만료될 때까지 invisibilityTimeout 메시지가 큐에 표시되지 않습니다. 이 시점에서 메시지를 다시 처리할 수 있게 됩니다.
큐 길이가 시간이 지남에 따라 증가하는지 확인합니다. 이는 다른 작업자가 큐에 배치하는 모든 메시지를 처리할 수 있는 충분한 작업자가 없는 경우에 발생할 수 있습니다. 또한 메트릭을 검사 삭제 요청이 실패하고 메시지의 큐에서 제거 횟수가 있는지 확인합니다. 이는 메시지를 삭제하려고 반복적으로 실패했음을 나타낼 수 있습니다.
예상보다 긴 기간 동안 E2ELatency 및 ServerLatency 값이 예상보다 높은 큐 작업에 대해 스토리지 로그를 검사합니다.

참고 항목

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유