Azure Storage 계정의 가용성 문제 해결
이 문서는 가용성의 변경 내용(예: 실패한 요청 수)을 조사하는 데 도움이 됩니다. 이러한 가용성 변경은 종종 Azure Monitor에서 스토리지 메트릭을 모니터링하여 식별할 수 있습니다. Azure Monitor에서 메트릭 및 로그를 사용하는 방법에 대한 일반적인 내용은 다음 문서를 참조하세요.
가용성 모니터링
가용성 메트릭의 값을 모니터링하여 스토리지 계정에서 스토리지 서비스의 가용성을 모니터링해야 합니다. 가용성 메트릭에는 백분율 값이 포함됩니다. 총 청구 가능 요청 값을 가져와서 예기치 않은 오류를 발생시킨 요청을 포함하여 적용 가능한 요청 수로 나누어 계산됩니다.
값이 100%보다 작으면 일부 스토리지 요청이 실패함을 나타냅니다. ServerTimeoutError와 같은 오류 유형에 대한 ResponseType 차원을 검사하여 실패하는 이유를 확인할 수 있습니다. 서비스가 더 나은 부하 분산 요청으로 파티션을 이동하는 동안 일시적인 서버 시간 제한과 같은 이유로 가용성이 일시적으로 100% 미만으로 떨어질 것으로 예상합니다. 클라이언트 애플리케이션의 재시도 논리는 이러한 일시적인 조건을 처리해야 합니다. 가용성 메트릭은 계정에서 트랜잭션이 발생하는 기간 동안만 사용할 수 있습니다.
Azure Monitor의 기능을 사용하여 서비스에 대한 가용성이 지정한 임계값보다 낮으면 경고할 수 있습니다.
메트릭이 제한 오류 증가를 나타냄
스토리지 서비스의 확장성 목표를 초과하면 제한 오류가 발생합니다. 스토리지 서비스는 단일 클라이언트나 테넌트만이 서비스를 사용하는 현상을 방지하기 위해 제한 오류를 발생시킵니다. 스토리지 계정의 확장성 목표와 스토리지 계정 내 파티션의 성능 목표에 대한 자세한 내용은 표준 스토리지 계정의 확장성 및 성능 목표를 참조하세요.
ResponseType 차원의 ClientThrottlingError 또는 ServerBusyError 값이 제한 오류로 실패하는 요청 비율의 증가를 나타낼 경우 다음 두 시나리오 중 하나를 조사해야 합니다.
- 일시적인 PercentThrottlingError 증가
- 영구적인 PercentThrottlingError 오류 증가
제한 오류의 증가는 스토리지 요청 수가 증가하거나 애플리케이션을 처음 로드할 때와 동시에 발생하는 경우가 많습니다. 또한 이 오류는 스토리지 작업에서 "503 서버 사용 중" 또는 "500 작업 시간 초과" HTTP 상태 메시지로 클라이언트에 표시될 수도 있습니다.
제한 오류의 일시적인 증가
애플리케이션에 대한 높은 활동 기간과 일치하는 제한 오류가 급증하는 경우 클라이언트에서 다시 시도하기 위한 지수(선형이 아닌) 백오프 전략을 구현합니다. 백오프 재시도는 파티션의 즉각적인 부하를 줄이고 애플리케이션이 트래픽 급증을 원활하게 하는 데 도움이 됩니다. 스토리지 클라이언트 라이브러리를 사용하여 다시 시도 정책을 구현하는 방법에 대한 자세한 내용은 RetryOptions.MaxRetries 속성을 참조하세요.
참고 항목
애플리케이션에 대한 높은 작업 기간과 일치하지 않는 제한 오류가 급증할 수도 있습니다. 가장 가능성이 큰 원인은 부하 분산을 개선하기 위해 파티션을 이동하는 스토리지 서비스입니다.
제한 오류의 영구 증가
트랜잭션 볼륨이 영구적으로 증가한 후 또는 애플리케이션에서 초기 부하 테스트를 수행할 때 제한 오류에 대해 지속적으로 높은 값이 표시되는 경우 애플리케이션에서 스토리지 파티션을 사용하는 방법과 스토리지 계정의 확장성 목표에 근접하는지 여부를 평가해야 합니다. 예를 들어 단일 파티션으로 계산되는 큐에 제한 오류가 표시되는 경우 추가 큐를 사용하여 트랜잭션을 여러 파티션에 분산하는 것이 좋습니다. 테이블에 제한 오류가 표시되는 경우 다른 분할 체계를 사용하여 더 넓은 범위의 파티션 키 값을 사용하여 트랜잭션을 여러 파티션에 분산하는 것이 좋습니다. 이 문제의 일반적인 원인 중 하나는 파티션 키로 날짜를 선택한 다음 특정 날짜의 모든 데이터가 하나의 파티션에 기록되는 앞에 추가/추가 안티패턴입니다(로드 시 쓰기 병목 현상이 발생할 수 있습니다). 다른 분할 디자인을 고려하거나 Blob Storage를 사용하는 것이 더 나은 솔루션이 될 수 있는지 평가합니다. 또한 트래픽 급증으로 인해 제한이 발생하는지 확인하고 요청 패턴을 부드럽게 하는 방법을 조사합니다.
트랜잭션을 여러 파티션으로 분산시키는 경우에도 스토리지 계정에 대해 설정된 확장성 제한을 파악해야 합니다. 예를 들어 10개의 큐를 사용한 경우 각각 초당 최대 2,000개의 1KB 메시지를 처리한 경우 스토리지 계정의 전체 메시지 수는 초당 20,000개입니다. 초당 20,000개 이상의 엔터티를 처리해야 하는 경우 여러 스토리지 계정을 사용하는 것이 좋습니다. 또한 스토리지 서비스가 클라이언트를 제한할 때 요청 및 엔터티의 크기가 영향을 줍니다. 더 큰 요청 및 엔터티가 있는 경우 더 빨리 제한될 수 있습니다.
쿼리 디자인이 비효율적인 경우에도 테이블 파티션의 확장성 제한에 도달할 수 있습니다. 예를 들어 파티션 내 엔터티 중 1%만 선택하고 모든 엔터티를 검사하는 필터가 포함된 쿼리는 각 엔터티에 액세스해야 합니다. 모든 엔터티 읽기는 해당 파티션의 총 트랜잭션 수에 계산됩니다. 따라서 확장성 목표에 쉽게 도달할 수 있습니다.
참고 항목
성능 테스트를 통해 애플리케이션의 비효율적인 쿼리 디자인을 확인해야 합니다.
메트릭이 시간 초과 오류의 증가를 나타냄
시간 초과 오류는 ResponseType 차원이 ServerTimeoutError 또는 ClientTimeout과 같을 때 발생합니다.
메트릭은 스토리지 서비스 중 하나의 시간 초과 오류 증가를 나타냅니다. 스토리지 작업에서 많은 수의 "500 작업 시간 초과" HTTP 상태 메시지가 클라이언트에 수신되는 경우가 있습니다.
참고 항목
스토리지 서비스가 파티션을 새 서버로 이동하여 요청 부하를 분산할 때는 시간 초과 오류가 일시적으로 발생할 수 있습니다.
서버 시간 초과(ServerTimeOutError)는 서버의 오류로 인해 야기됩니다. 클라이언트 시간 제한(ClientTimeout)은 서버의 작업이 클라이언트에서 지정한 시간 제한을 초과했기 때문에 발생합니다. 예를 들어 스토리지 클라이언트 라이브러리를 사용하는 클라이언트는 작업에 대한 시간 제한을 설정할 수 있습니다.
서버 시간 초과는 스토리지 서비스에 추가 조사가 필요한 문제가 있음을 나타냅니다. 메트릭을 사용하여 서비스의 확장성 제한에 도달했는지 확인하고 이 문제를 발생시키는 트래픽 급증 현상을 파악할 수 있습니다. 일시적인 문제는 서비스의 부하 분산 작업으로 인해 발생할 수 있습니다. 애플리케이션이 서비스의 확장성 제한에 도달하지 않았는데 영구적인 문제가 발생하는 경우에는 지원 문제에 대해 문의해야 합니다. 클라이언트 시간 제한의 경우 시간 제한이 클라이언트에서 적절한 값으로 설정되었는지 여부를 결정하고 클라이언트에서 설정된 시간 제한 값을 변경하거나, 예를 들어 테이블 쿼리를 최적화하거나 메시지 크기를 줄여 스토리지 서비스에서 작업의 성능을 향상시킬 수 있는 방법을 조사해야 합니다.
메트릭이 네트워크 오류 증가를 나타냄
ResponseType 차원이 NetworkError와 같을 때 네트워크 오류가 발생합니다. 이러한 오류는 클라이언트가 스토리지 요청을 수행할 때 스토리지 서비스에서 네트워크 오류를 검색하면 발생합니다.
이 오류의 가장 일반적인 원인은 스토리지 서비스에서 제한 시간이 만료되기 전에 클라이언트의 연결이 끊기는 현상입니다. 클라이언트의 코드를 조사하여 스토리지 서비스에서 클라이언트의 연결이 끊기는 이유와 시기를 파악합니다. 타사 네트워크 분석 도구를 사용하여 클라이언트에서 발생하는 네트워크 연결 문제를 조사할 수도 있습니다.
참고 항목
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.