다음을 통해 공유

Azure Storage 계정의 성능 문제 해결

  • 아티클

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

성능 모니터링

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

  • SuccessE2ELatency 및 SuccessServerLatency 메트릭의 값은 스토리지 서비스 또는 API 작업 유형이 요청을 처리하는 데 걸리는 평균 시간을 표시합니다. SuccessE2ELatency 는 요청을 읽고 응답을 보내는 데 걸린 시간과 요청을 처리하는 데 걸린 시간(따라서 요청이 스토리지 서비스에 도달하면 네트워크 대기 시간이 포함됨)을 포함하는 엔드 투 엔드 대기 시간의 측정값입니다. SuccessServerLatency 는 처리 시간에 대한 측정값이므로 클라이언트와의 통신과 관련된 모든 네트워크 대기 시간을 제외합니다.

  • Egress 및 Ingress 메트릭은 스토리지 서비스로 들어오거나 스토리지 서비스에서 나가는 총 데이터 양 또는 특정 API 작업 유형을 통과하는 총 데이터 양(바이트)을 표시합니다.

  • Transactions 메트릭은 스토리지 서비스 또는 API 작업이 수신하는 총 요청 수를 표시합니다. 트랜잭션은 스토리지 서비스에서 수신하는 총 요청 수입니다.

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

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

진단 성능 이슈

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

메트릭을 통해 성능 문제의 원인일 가능성이 높은 위치를 파악한 후에는 로그 파일을 사용하여 문제를 추가로 진단하고 해결하기 위한 세부 정보를 찾을 수 있습니다.

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

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

참고 항목

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

클라이언트 성능 문제 조사

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

테이블 및 큐 서비스의 경우 Nagle 알고리즘은 SuccessServerLatency에 비해 SuccessE2ELatency가 높을 수도 있습니다. 자세한 내용은 Nagle 알고리즘이 작은 요청에 대해 친숙하지 않다는 게시물을 참조하세요. 네임스페이스의 클래스를 사용하여 코드에서 Nagle 알고리즘을 ServicePointManager System.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가 높게 표시되는 경우 Storage 로그를 사용하여 같은 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 값이 정상 상태보다 오랫동안 예상보다 높게 나타나는 큐 작업의 Storage 로그를 검사합니다.

참고 항목

도움을 요청하십시오.

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