다음을 통해 공유

Azure Storage 계정의 가용성 문제 해결

  • 아티클

이 문서는 가용성의 변경 내용(예: 실패한 요청 수)을 조사하는 데 도움이 됩니다. 이러한 가용성 변경 내용은 Azure Monitor에서 스토리지 메트릭을 모니터링하여 식별할 수 있는 경우가 많습니다. Azure Monitor에서 메트릭 및 로그를 사용하는 방법에 대한 일반적인 내용은 다음 문서를 참조하세요.

가용성 모니터링

가용성 메트릭의 값을 모니터링하여 스토리지 계정에서 스토리지 서비스의 가용성 을 모니터링해야 합니다. 가용성 메트릭에는 백분율 값이 포함됩니다. 청구 가능한 총 요청 값을 가져와서 예기치 않은 오류를 발생시킨 요청을 포함하여 적용 가능한 요청 수로 나누어 계산됩니다.

100% 미만의 값은 일부 스토리지 요청이 실패했음을 나타냅니다. ResponseType 차원에서 ServerTimeoutError와 같은 오류 유형을 검사하여 실패하는 이유를 확인할 수 있습니다. 서비스가 더 나은 부하 분산 요청으로 파티션을 이동하는 동안 일시적인 서버 시간 제한과 같은 이유로 가용성 이 일시적으로 100% 미만으로 떨어질 것으로 예상해야 합니다. 클라이언트 애플리케이션의 재시도 논리는 이러한 일시적인 조건을 처리해야 합니다.

Azure Monitor의 기능을 사용하여 서비스의 가용성 이 지정한 임계값보다 낮으면 경고할 수 있습니다.

메트릭은 제한 오류의 증가를 보여 줍니다.

스토리지 서비스의 확장성 목표를 초과하면 제한 오류가 발생합니다. 스토리지 서비스는 단일 클라이언트 또는 테넌트가 다른 클라이언트를 희생하여 서비스를 사용할 수 없도록 제한합니다. 자세한 내용은 스토리지 계정의 확장성 목표 및 스토리지 계정 내 파티션의 성능 목표에 대한 자세한 내용은 표준 스토리지 계정의 확장성 및 성능 목표를 참조하세요.

ResponseType 차원의 ClientThrottlingError 또는 ServerBusyError 값에 제한 오류로 실패하는 요청의 비율이 증가하는 경우 다음 두 가지 시나리오 중 하나를 조사해야 합니다.

  • PercentThrottlingError의 일시적인 증가
  • PercentThrottlingError 오류의 영구 증가

제한 오류의 증가는 스토리지 요청 수가 증가하거나 애플리케이션을 처음 로드할 때와 동시에 발생하는 경우가 많습니다. 또한 클라이언트에서 스토리지 작업의 메시지를 "503 서버 사용 중" 또는 "500 작업 시간 제한" HTTP 상태 메시지로 나타낼 수도 있습니다.

제한 오류의 일시적인 증가

애플리케이션에 대한 높은 활동 기간과 일치하는 제한 오류가 급증하는 경우 클라이언트에서 다시 시도하기 위한 지수(선형이 아닌) 백오프 전략을 구현합니다. 백오프 재시도는 파티션의 즉각적인 부하를 줄이고 애플리케이션이 트래픽 급증을 원활하게 처리할 수 있도록 지원합니다. 스토리지 클라이언트 라이브러리를 사용하여 재시도 정책을 구현하는 방법에 대한 자세한 내용은 RetryOptions.MaxRetries 속성을 참조하세요.

참고

애플리케이션에 대한 높은 활동 기간과 일치하지 않는 제한 오류가 급증할 수도 있습니다. 가장 가능성이 높은 원인은 부하 분산을 개선하기 위해 파티션을 이동하는 스토리지 서비스입니다.

제한 오류의 영구적 증가

트랜잭션 볼륨이 영구적으로 증가한 후 또는 애플리케이션에서 초기 부하 테스트를 수행할 때 제한 오류에 대해 지속적으로 높은 값이 표시되는 경우 애플리케이션이 스토리지 파티션을 사용하는 방법과 스토리지 계정의 확장성 목표에 근접하는지 평가해야 합니다. 예를 들어 큐에 제한 오류(단일 파티션으로 계산됨)가 표시되는 경우 추가 큐를 사용하여 트랜잭션을 여러 파티션에 분산하는 것이 좋습니다. 테이블에 제한 오류가 표시되는 경우 다른 분할 체계를 사용하여 더 넓은 범위의 파티션 키 값을 사용하여 트랜잭션을 여러 파티션에 분산하는 것이 좋습니다. 이 문제의 일반적인 원인 중 하나는 파티션 키로 날짜를 선택한 다음 특정 날짜의 모든 데이터가 하나의 파티션에 기록되는 앞에 추가/추가 안티패턴입니다(로드 중이면 쓰기 병목 현상이 발생할 수 있습니다). 다른 분할 디자인을 고려하거나 Blob Storage를 사용하는 것이 더 나은 솔루션인지 평가합니다. 또한 트래픽 급증으로 인해 제한이 발생하는지 여부를 검사 요청 패턴을 부드럽게 하는 방법을 조사합니다.

트랜잭션을 여러 파티션에 분산하는 경우 스토리지 계정에 대해 설정된 확장성 제한을 알고 있어야 합니다. 예를 들어 10개의 큐를 사용하여 각각 초당 최대 2,000개의 1KB 메시지를 처리하는 경우 스토리지 계정에 대해 초당 메시지의 전체 제한인 20,000개입니다. 초당 20,000개 이상의 엔터티를 처리해야 하는 경우 여러 스토리지 계정을 사용하는 것이 좋습니다. 또한 스토리지 서비스가 클라이언트를 제한할 때 요청 및 엔터티의 크기가 영향을 줍니다. 더 큰 요청 및 엔터티가 있는 경우 더 빨리 제한될 수 있습니다.

비효율적인 쿼리 디자인으로 인해 테이블 파티션의 확장성 제한에 도달할 수도 있습니다. 예를 들어 파티션에서 엔터티의 1%만 선택하지만 파티션의 모든 엔터티를 검사하는 필터가 있는 쿼리는 각 엔터티에 액세스해야 합니다. 모든 엔터티 읽기는 해당 파티션의 총 트랜잭션 수에 계산됩니다. 따라서 확장성 목표에 쉽게 도달할 수 있습니다.

참고

성능 테스트는 애플리케이션의 비효율적인 쿼리 디자인을 표시해야 합니다.

메트릭은 시간 제한 오류의 증가를 보여 줍니다.

Timeout 오류는 ResponseType 차원이 ServerTimeoutError 또는 ClientTimeout과 같을 때 발생합니다.

메트릭은 스토리지 서비스 중 하나에 대한 시간 제한 오류의 증가를 보여 줍니다. 동시에 클라이언트는 스토리지 작업에서 대량의 "500 작업 시간 제한" HTTP 상태 메시지를 받습니다.

참고

스토리지 서비스가 파티션을 새 서버로 이동하여 요청을 부하 분산하기 때문에 시간 제한 오류가 일시적으로 표시 될 수 있습니다.

서버 시간 제한(ServerTimeOutError)은 서버의 오류로 인해 발생합니다. 클라이언트 시간 제한(ClientTimeout)은 서버의 작업이 클라이언트에서 지정한 시간 제한을 초과했기 때문에 발생합니다. 예를 들어 스토리지 클라이언트 라이브러리를 사용하는 클라이언트는 작업에 대한 시간 제한을 설정할 수 있습니다.

서버 시간 제한은 추가 조사가 필요한 스토리지 서비스에 문제가 있음을 나타냅니다. 메트릭을 사용하여 서비스에 대한 확장성 제한에 도달했는지 확인하고 이 문제를 일으킬 수 있는 트래픽 급증을 식별할 수 있습니다. 문제가 일시적인 경우 서비스의 부하 분산 작업 때문일 수 있습니다. 문제가 지속적이고 애플리케이션이 서비스의 확장성 제한에 도달하여 발생하지 않는 경우 지원 문제를 제기해야 합니다. 클라이언트 시간 제한의 경우 시간 제한이 클라이언트에서 적절한 값으로 설정되어 있는지 여부를 결정하고 클라이언트에서 설정된 시간 제한 값을 변경하거나, 예를 들어 테이블 쿼리를 최적화하거나 메시지 크기를 줄여 스토리지 서비스에서 작업의 성능을 향상시키는 방법을 조사해야 합니다.

메트릭은 네트워크 오류의 증가를 보여 줍니다.

ResponseType 차원이 NetworkError와 같을 때 네트워크 오류가 발생합니다. 이는 클라이언트가 스토리지 요청을 수행할 때 스토리지 서비스에서 네트워크 오류를 감지할 때 발생합니다.

이 오류의 가장 일반적인 원인은 스토리지 서비스에서 시간 제한이 만료되기 전에 클라이언트 연결을 끊는 것입니다. 클라이언트의 코드를 조사하여 클라이언트가 스토리지 서비스에서 연결을 끊는 이유와 시기를 이해합니다. 타사 네트워크 분석 도구를 사용하여 클라이언트의 네트워크 연결 문제를 조사할 수도 있습니다.

참고 항목

도움을 요청하십시오.

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