Microsoft Azure Storage 모니터링, 진단 및 문제 해결(클래식)
이 가이드에서는 Azure 스토리지 분석, Azure Storage 클라이언트 라이브러리의 클라이언트 쪽 로깅 및 기타 타사 도구와 같은 기능을 사용하여 Azure Storage 관련 문제를 식별, 진단 및 해결하는 방법을 보여 줍니다.
이 가이드는 주로 이러한 온라인 서비스 관리하는 Azure Storage Services 및 IT 전문가를 사용하는 온라인 서비스 개발자가 읽습니다. 이 가이드의 목표는 다음과 같습니다.
- Azure Storage 계정의 상태 및 성능을 유지 관리하는 데 도움이 됩니다.
- 애플리케이션의 문제 또는 문제가 Azure Storage와 관련이 있는지 여부를 결정하는 데 도움이 되는 필요한 프로세스와 도구를 제공합니다.
- Azure Storage와 관련된 문제를 해결하기 위한 실행 가능한 지침을 제공합니다.
참고
이 문서는 클래식 메트릭 및 로그라고 하는 스토리지 분석 메트릭 및 로그를 사용하는 방법을 기반으로 합니다. 스토리지 분석 로그 대신 Azure Monitor에서 Azure Storage 메트릭 및 로그를 사용하는 것이 좋습니다. 자세한 내용은 다음 문서를 참조하세요.
개요
클라우드 환경에서 호스트되는 분산 애플리케이션의 문제를 진단하고 해결하는 것은 기존 환경보다 더 복잡할 수 있습니다. 애플리케이션은 PaaS 또는 IaaS 인프라, 온-프레미스, 모바일 디바이스 또는 이러한 환경의 일부 조합으로 배포할 수 있습니다. 일반적으로 애플리케이션의 네트워크 트래픽은 공용 및 프라이빗 네트워크를 트래버스할 수 있으며 애플리케이션은 관계형 및 문서 데이터베이스와 같은 다른 데이터 저장소 외에도 Microsoft Azure Storage 테이블, Blob, 큐 또는 파일과 같은 여러 스토리지 기술을 사용할 수 있습니다.
이러한 애플리케이션을 성공적으로 관리하려면 애플리케이션을 사전에 모니터링하고 모든 측면과 해당 종속 기술을 진단하고 문제를 해결하는 방법을 이해해야 합니다. Azure Storage 서비스의 사용자는 애플리케이션에서 사용하는 스토리지 서비스를 지속적으로 모니터링하여 예기치 않은 동작 변경(예: 평소보다 느린 응답 시간)을 모니터링하고 로깅을 사용하여 보다 자세한 데이터를 수집하고 문제를 심층적으로 분석해야 합니다. 모니터링 및 로깅에서 얻은 진단 정보는 애플리케이션에서 발생한 문제의 근본 원인을 확인하는 데 도움이 됩니다. 그런 다음 문제를 해결하고 수정할 적절한 단계를 결정할 수 있습니다. Azure Storage는 핵심 Azure 서비스이며 고객이 Azure 인프라에 배포하는 대부분의 솔루션에서 중요한 부분을 차지합니다. Azure Storage에는 클라우드 기반 애플리케이션의 스토리지 문제 모니터링, 진단 및 문제를 간소화하는 기능이 포함되어 있습니다.
이 가이드의 구성 방법
스토리지 서비스 모니터링 섹션에서는 Azure 스토리지 분석 메트릭(스토리지 메트릭)을 사용하여 Azure Storage 서비스의 상태 및 성능을 모니터링하는 방법을 설명합니다.
스토리지 문제 진단 섹션에서는 Azure 스토리지 분석 로깅(스토리지 로깅)을 사용하여 문제를 진단하는 방법을 설명합니다. 또한 .NET용 스토리지 클라이언트 라이브러리 또는 Java용 Azure SDK와 같은 클라이언트 라이브러리 중 하나의 기능을 사용하여 클라이언트 쪽 로깅을 사용하도록 설정하는 방법도 설명합니다.
엔드 투 엔드 추적 섹션에서는 다양한 로그 파일 및 메트릭 데이터에 포함된 정보를 상호 연결하는 방법을 설명합니다.
문제 해결 지침 섹션에서는 발생할 수 있는 일반적인 스토리지 관련 문제 중 일부에 대한 문제 해결 지침을 제공합니다.
부록 섹션에는 네트워크 패킷 데이터를 분석하기 위한 Wireshark 및 Netmon과 같은 다른 도구 및 HTTP/HTTPS 메시지를 분석하기 위한 Fiddler와 같은 다른 도구를 사용하는 방법에 대한 정보가 포함되어 있습니다.
스토리지 서비스 모니터링
Windows 성능 모니터링에 익숙한 경우 스토리지 메트릭은 Windows 성능 모니터 카운터와 동등한 Azure Storage라고 생각할 수 있습니다. 스토리지 메트릭에서는 서비스 가용성, 서비스에 대한 총 요청 수 또는 서비스에 대한 성공적인 요청의 비율과 같은 포괄적인 메트릭 집합(Windows 성능 모니터 용어의 카운터)을 찾을 수 있습니다. 사용 가능한 메트릭의 전체 목록은 스토리지 분석 메트릭 테이블 스키마를 참조하세요. 스토리지 서비스가 매시간 또는 매분마다 메트릭을 수집하고 집계할지 여부를 지정할 수 있습니다. 메트릭을 사용하도록 설정하고 스토리지 계정을 모니터링하는 방법에 대한 자세한 내용은 스토리지 메트릭 사용 및 메트릭 데이터 보기를 참조하세요.
Azure Portal 표시할 시간별 메트릭을 선택하고 시간별 메트릭이 특정 임계값을 초과할 때마다 관리자에게 메일로 알리는 규칙을 구성할 수 있습니다. 자세한 내용은 경고 알림 받기를 참조하세요.
스토리지용 Azure Monitor(미리 보기)를 검토하는 것이 좋습니다. Azure Storage 서비스 성능, 용량 및 가용성에 대한 통합 보기를 제공하여 Azure Storage 계정에 대한 포괄적인 모니터링을 제공하는 Azure Monitor의 기능입니다. 아무것도 사용하도록 설정하거나 구성할 필요가 없으며 미리 정의된 대화형 차트 및 포함된 기타 시각화에서 이러한 메트릭을 즉시 볼 수 있습니다.
스토리지 서비스는 메트릭을 수집하기 위해 최선을 다하지만 모든 스토리지 작업을 기록하지는 않을 수 있습니다.
Azure Portal 스토리지 계정에 대한 가용성, 총 요청 및 평균 대기 시간 수와 같은 메트릭을 볼 수 있습니다. 가용성이 특정 수준 아래로 떨어지면 관리자에게 경고하도록 알림 규칙도 설정되었습니다. 이 데이터를 볼 때 조사 가능한 한 가지 영역은 테이블 서비스 성공률이 100% 미만이라는 것입니다(자세한 내용은 메트릭이 낮은 PercentSuccess 또는 분석 로그 항목에 ClientOtherErrors 섹션의 트랜잭션 상태 있는 작업이 있음을 보여 주세요).
Azure 애플리케이션이 정상 상태이고 예상대로 수행되도록 Azure 애플리케이션을 지속적으로 모니터링해야 합니다.
- 현재 데이터를 비교하고 Azure Storage 및 애플리케이션의 동작에 중요한 변경 내용을 식별할 수 있는 애플리케이션에 대한 몇 가지 기준 메트릭을 설정합니다. 기준 메트릭의 값은 대부분의 경우 애플리케이션별로 지정되며 애플리케이션을 성능 테스트할 때 설정해야 합니다.
- 분 메트릭을 기록하고 이를 사용하여 오류 수 또는 요청 속도 급증과 같은 예기치 않은 오류 및 변칙을 적극적으로 모니터링합니다.
- 시간별 메트릭을 기록하고 이를 사용하여 평균 오류 수 및 요청 속도와 같은 평균 값을 모니터링합니다.
- 스토리지 문제 진단 섹션의 뒷부분에서 설명한 대로 진단 도구를 사용하여 잠재적인 문제를 조사합니다.
다음 이미지의 차트는 시간별 메트릭에 대해 발생하는 평균이 활동 급증을 숨기는 방법을 보여 줍니다. 시간별 메트릭은 안정적인 요청 속도를 표시하는 것처럼 보이지만 분 메트릭은 실제로 발생하는 변동을 표시합니다.
이 섹션의 나머지 부분에서는 모니터링해야 하는 메트릭과 그 이유를 설명합니다.
서비스 상태 모니터링
Azure Portal 사용하여 전 세계 모든 Azure 지역에서 Storage 서비스(및 기타 Azure 서비스)의 상태를 볼 수 있습니다. 모니터링을 사용하면 컨트롤 외부의 문제가 애플리케이션에 사용하는 지역의 Storage 서비스에 영향을 미치는지 즉시 확인할 수 있습니다.
Azure Portal 다양한 Azure 서비스에 영향을 주는 인시던트에 대한 알림을 제공할 수도 있습니다.
참고
이 정보는 이전에 Azure 서비스 대시보드에서 기록 데이터와 함께 사용할 수 있었습니다. Azure DevOps용 Application Insights에 대한 자세한 내용은 부록 5: Azure DevOps용 Application Insights를 사용하여 모니터링을 참조하세요.
용량 모니터링
스토리지 메트릭은 Blob이 일반적으로 저장된 데이터의 가장 큰 비율을 차지하므로 Blob 서비스에 대한 용량 메트릭만 저장합니다(쓰기 시 스토리지 메트릭을 사용하여 테이블 및 큐의 용량을 모니터링할 수 없음). Blob 서비스에 대한 모니터링을 $MetricsCapacityBlob 사용하도록 설정한 경우 테이블에서 이 데이터를 찾을 수 있습니다. 스토리지 메트릭은 하루에 한 번 이 데이터를 기록하며, 의 값을 RowKey 사용하여 행에 사용자 데이터(값) 또는 분석 데이터(값dataanalytics)와 관련된 엔터티가 포함되어 있는지 여부를 확인할 수 있습니다. 저장된 각 엔터티에는 사용된 스토리지 양(Capacity 바이트 단위)과 스토리지 계정에서 사용 중인 컨테이너(ContainerCount) 및 Blob()의 현재 수에ObjectCount 대한 정보가 포함됩니다. 테이블에 저장된 $MetricsCapacityBlob 용량 메트릭에 대한 자세한 내용은 스토리지 분석 메트릭 테이블 스키마를 참조하세요.
참고
스토리지 계정의 용량 한도에 근접하고 있다는 조기 경고에 대해 이러한 값을 모니터링해야 합니다. Azure Portal 집계 스토리지 사용이 지정한 임계값을 초과하거나 초과하는 경우 경고 규칙을 추가하여 알릴 수 있습니다.
Blob과 같은 다양한 스토리지 개체의 크기를 예측하려면 블로그 게시물 Azure Storage 청구 이해 – 대역폭, 트랜잭션 및 용량을 참조하세요.
가용성 모니터링
시간별 또는 분 메트릭 테이블(, , , $MetricsMinutePrimaryTransactionsBlob$MetricsCapacityBlob$MetricsHourPrimaryTransactionsQueue$MetricsMinutePrimaryTransactionsQueue$MetricsHourPrimaryTransactionsTable$MetricsMinutePrimaryTransactionsTable) 열의 값을 Availability 모니터링하여 스토리지 계정에서 스토리지 서비스의 가용성을 모니터링해야 합니다. $MetricsHourPrimaryTransactionsBlob 열에는 Availability 서비스 또는 행이 나타내는 API 작업의 가용성을 나타내는 백분율 값이 포함되어 있습니다( RowKey 행에 서비스 전체 또는 특정 API 작업에 대한 메트릭이 포함되어 있는지 표시됨).
100% 미만의 값은 일부 스토리지 요청이 실패했음을 나타냅니다. ServerTimeoutError와 같이 다른 오류 형식의 요청 수를 표시하는 메트릭 데이터의 다른 열을 검사하여 실패하는 이유를 확인할 수 있습니다. 서비스가 더 나은 부하 분산 요청으로 파티션을 Availability 이동하는 동안 일시적인 서버 시간 제한과 같은 이유로 일시적으로 100% 미만으로 떨어질 것으로 예상됩니다. 클라이언트 애플리케이션의 재시도 논리는 이러한 일시적인 조건을 처리해야 합니다. 기록된 작업 및 상태 메시지 스토리지 분석 문서에서는 스토리지 메트릭이 계산에 Availability 포함하는 트랜잭션 유형을 나열합니다.
Azure Portal 서비스에 대해 지정한 임계값보다 낮은 경우 Availability 경고 규칙을 추가하여 알릴 수 있습니다.
이 가이드의 문제 해결 지침 섹션에서는 가용성과 관련된 몇 가지 일반적인 스토리지 서비스 문제에 대해 설명합니다.
성능 모니터링
스토리지 서비스의 성능을 모니터링하려면 시간별 및 분 메트릭 테이블에서 다음 메트릭을 사용할 수 있습니다.
- 및
AverageServerLatency열의AverageE2ELatency값은 스토리지 서비스 또는 API 작업 유형이 요청을 처리하는 데 걸리는 평균 시간을 보여 줍니다.AverageE2ELatency는 요청을 읽고 요청을 처리하는 데 걸린 시간 외에 응답을 보내는 데 걸린 시간을 포함하는 엔드 투 엔드 대기 시간의 측정값입니다(따라서 요청이 스토리지 서비스에 도달하면 네트워크 대기 시간 포함).AverageServerLatency는 처리 시간의 측정값이므로 클라이언트와의 통신과 관련된 네트워크 대기 시간을 제외합니다. 이 가이드의 뒷부분에 있는 높은 AverageE2ELatency 및 낮은 AverageServerLatency 섹션을 보여 주는 메트릭 을 참조하여 이러한 두 값 간에 상당한 차이가 있을 수 있는 이유에 대해 설명합니다. - 및
TotalEgress열의TotalIngress값은 스토리지 서비스 또는 특정 API 작업 유형을 통해 들어오고 나가는 총 데이터 양(바이트)을 보여 줍니다. - 열의
TotalRequests값은 API 작업의 스토리지 서비스가 수신하는 총 요청 수를 보여 줍니다.TotalRequests는 스토리지 서비스에서 수신하는 총 요청 수입니다.
일반적으로 이러한 값의 예기치 않은 변경 내용을 모니터링합니다. 이는 조사가 필요한 문제가 있음을 나타냅니다.
Azure Portal 이 서비스에 대한 성능 메트릭이 지정한 임계값을 초과하거나 초과하는 경우 경고 규칙을 추가하여 알릴 수 있습니다.
이 가이드의 문제 해결 지침 섹션에서는 성능과 관련된 몇 가지 일반적인 스토리지 서비스 문제에 대해 설명합니다.
스토리지 문제 진단
다음과 같은 여러 가지 방법으로 애플리케이션에서 문제 또는 문제를 인식할 수 있습니다.
- 애플리케이션 작동이 중단되거나 중지되는 주요 오류입니다.
- 스토리지 서비스 모니터링 이전 섹션에 설명된 대로 모니터링하는 메트릭의 기준 값에서 중요한 변경 내용입니다.
- 애플리케이션 사용자가 특정 작업이 예상대로 완료되지 않았거나 일부 기능이 작동하지 않는다고 보고합니다.
- 로그 파일 또는 다른 알림 방법을 통해 표시되는 애플리케이션 내에서 생성된 오류입니다.
일반적으로 Azure Storage 서비스와 관련된 문제는 다음 네 가지 범주 중 하나로 분류됩니다.
- 애플리케이션에는 사용자가 보고하거나 성능 메트릭의 변경 내용에 의해 표시되는 성능 문제가 있습니다.
- 하나 이상의 지역에서 Azure Storage 인프라에 문제가 있습니다.
- 사용자가 보고하거나 모니터링하는 오류 수 메트릭 중 하나가 증가하여 애플리케이션에 오류가 발생합니다.
- 개발 및 테스트 중에 로컬 스토리지 에뮬레이터를 사용할 수 있습니다. 스토리지 에뮬레이터 사용과 관련된 몇 가지 문제가 발생할 수 있습니다.
다음 섹션에서는 이러한 네 가지 범주 각각에서 문제를 진단하고 해결하기 위해 수행해야 하는 단계를 간략하게 설명합니다. 이 가이드의 뒷부분에 있는 문제 해결 지침 섹션에서는 발생할 수 있는 몇 가지 일반적인 문제에 대해 자세히 설명합니다.
서비스 상태 문제
서비스 상태 문제는 일반적으로 제어할 수 없는 문제입니다. 이 Azure Portal 스토리지 서비스를 포함하여 Azure 서비스의 지속적인 문제에 대한 정보를 제공합니다. 스토리지 계정을 만들 때 Read-Access Geo-Redundant Storage를 선택한 경우 기본 위치에서 데이터를 사용할 수 없게 되면 애플리케이션이 보조 위치의 읽기 전용 복사본으로 일시적으로 전환할 수 있습니다. 보조에서 읽으려면 애플리케이션이 기본 및 보조 스토리지 위치 사용 간에 전환할 수 있어야 하며 읽기 전용 데이터로 기능 모드가 축소될 수 있어야 합니다. Azure Storage 클라이언트 라이브러리를 사용하면 주 스토리지에서 읽기가 실패하는 경우 보조 스토리지에서 읽을 수 있는 재시도 정책을 정의할 수 있습니다. 또한 애플리케이션은 보조 위치의 데이터가 결국 일치한다는 것을 알고 있어야 합니다. 자세한 내용은 블로그 게시물 Azure Storage 중복성 옵션 및 읽기 액세스 지역 중복 스토리지를 참조하세요.
성능 문제
애플리케이션의 성능은 특히 사용자 관점에서 주관적일 수 있습니다. 따라서 성능 문제가 있을 수 있는 위치를 식별하는 데 도움이 되는 기준 메트릭을 사용할 수 있어야 합니다. 클라이언트 애플리케이션 관점에서 Azure Storage 서비스의 성능에는 많은 요소가 영향을 줄 수 있습니다. 이러한 요소는 스토리지 서비스, 클라이언트 또는 네트워크 인프라에서 작동할 수 있습니다. 따라서 성능 문제의 출처를 식별하기 위한 전략을 갖는 것이 중요합니다.
메트릭에서 성능 문제의 원인의 가능성이 있는 위치를 확인한 후 로그 파일을 사용하여 자세한 정보를 찾아 문제를 추가로 진단하고 해결할 수 있습니다.
이 가이드의 뒷부분에 있는 문제 해결 지침 섹션에서는 발생할 수 있는 몇 가지 일반적인 성능 관련 문제에 대한 자세한 정보를 제공합니다.
오류 진단
애플리케이션 사용자는 클라이언트 애플리케이션에서 보고한 오류를 알릴 수 있습니다. 또한 스토리지 메트릭은 NetworkError, ClientTimeoutError 또는 AuthorizationError와 같은 스토리지 서비스의 다양한 오류 유형 수를 기록합니다. 스토리지 메트릭은 다양한 오류 유형의 개수만 기록하지만 서버 쪽, 클라이언트 쪽 및 네트워크 로그를 검사하여 개별 요청에 대한 자세한 정보를 얻을 수 있습니다. 일반적으로 스토리지 서비스에서 반환된 HTTP 상태 코드는 요청이 실패한 이유를 나타냅니다.
참고
일시적인 네트워크 조건 또는 애플리케이션 오류로 인한 오류와 같은 몇 가지 일시적인 오류가 표시되어야 합니다.
다음 리소스는 스토리지 관련 상태 및 오류 코드를 이해하는 데 유용합니다.
스토리지 에뮬레이터 문제
Azure SDK에는 개발 워크스테이션에서 실행할 수 있는 스토리지 에뮬레이터가 포함되어 있습니다. 이 에뮬레이터는 대부분의 Azure Storage 서비스 동작을 시뮬레이션하며 개발 및 테스트 중에 유용하므로 Azure 구독 및 Azure Storage 계정 없이도 Azure Storage 서비스를 사용하는 애플리케이션을 실행할 수 있습니다.
이 가이드의 문제 해결 지침 섹션에서는 스토리지 에뮬레이터를 사용하여 발생하는 몇 가지 일반적인 문제에 대해 설명합니다.
스토리지 로깅 도구
스토리지 로깅은 Azure Storage 계정에서 스토리지 요청의 서버 쪽 로깅을 제공합니다. 서버 쪽 로깅을 사용하도록 설정하고 로그 데이터에 액세스하는 방법에 대한 자세한 내용은 스토리지 로깅 사용 및 로그 데이터 액세스를 참조하세요.
.NET용 스토리지 클라이언트 라이브러리를 사용하면 애플리케이션에서 수행하는 스토리지 작업과 관련된 클라이언트 쪽 로그 데이터를 수집할 수 있습니다. 자세한 내용은 .NET Storage 클라이언트 라이브러리를 사용하여 클라이언트 쪽 로깅을 참조하세요.
참고
SAS 권한 부여 실패와 같은 일부 상황에서는 서버 쪽 스토리지 로그에서 요청 데이터를 찾을 수 없는 오류를 보고할 수 있습니다. Storage 클라이언트 라이브러리의 로깅 기능을 사용하여 문제의 원인이 클라이언트에 있는지 조사하거나 네트워크 모니터링 도구를 사용하여 네트워크를 조사할 수 있습니다.
네트워크 로깅 도구 사용
클라이언트와 서버 간의 트래픽을 캡처하여 클라이언트와 서버가 교환하는 데이터 및 기본 네트워크 조건에 대한 자세한 정보를 제공할 수 있습니다. 유용한 네트워크 로깅 도구는 다음과 같습니다.
- Fiddler 는 HTTP 및 HTTPS 요청 및 응답 메시지의 헤더 및 페이로드 데이터를 검사할 수 있는 무료 웹 디버깅 프록시입니다. 자세한 내용은 부록 1: Fiddler를 사용하여 HTTP 및 HTTPS 트래픽 캡처를 참조하세요.
- Microsoft 네트워크 모니터(Netmon) 및 Wireshark 는 다양한 네트워크 프로토콜에 대한 자세한 패킷 정보를 볼 수 있는 무료 네트워크 프로토콜 분석기입니다. Wireshark에 대한 자세한 내용은 부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처를 참조하세요.
- 기본 연결 테스트를 수행하여 클라이언트 컴퓨터가 네트워크를 통해 Azure Storage 서비스에 연결할 수 있는지 검사 경우 클라이언트의 표준 ping 도구를 사용하여 이 작업을 수행할 수 없습니다. 그러나 tcping 도구를 사용하여 연결을 검사 수 있습니다.
대부분의 경우 스토리지 로깅 및 스토리지 클라이언트 라이브러리의 로그 데이터는 문제를 진단하기에 충분하지만 일부 시나리오에서는 이러한 네트워크 로깅 도구가 제공할 수 있는 보다 자세한 정보가 필요할 수 있습니다. 예를 들어 Fiddler를 사용하여 HTTP 및 HTTPS 메시지를 볼 수 있으므로 스토리지 서비스와 주고 받는 헤더 및 페이로드 데이터를 볼 수 있으므로 클라이언트 애플리케이션이 스토리지 작업을 다시 테스트하는 방법을 검토할 수 있습니다. Wireshark와 같은 프로토콜 분석기는 패킷 수준에서 작동하므로 TCP 데이터를 볼 수 있으므로 손실된 패킷 및 연결 문제를 해결할 수 있습니다.
엔드 투 엔드 추적
다양한 로그 파일을 사용하는 엔드 투 엔드 추적은 잠재적인 문제를 조사하는 데 유용한 기술입니다. 메트릭 데이터의 날짜/시간 정보를 사용하여 로그 파일에서 문제를 해결하는 데 도움이 되는 자세한 정보를 확인할 위치를 나타낼 수 있습니다.
로그 데이터 상관 관계 지정
클라이언트 애플리케이션, 네트워크 추적 및 서버 쪽 스토리지 로깅에서 로그를 볼 때 요청을 서로 다른 로그 파일 간에 상호 연결할 수 있어야 합니다. 로그 파일에는 상관 관계 식별자로 유용한 다양한 필드가 포함됩니다. 클라이언트 요청 ID는 다른 로그의 항목을 상호 연결하는 데 사용할 수 있는 가장 유용한 필드입니다. 그러나 경우에 따라 서버 요청 ID 또는 타임스탬프를 사용하는 것이 유용할 수 있습니다. 다음 섹션에서는 이러한 옵션에 대한 자세한 내용을 제공합니다.
클라이언트 요청 ID
스토리지 클라이언트 라이브러리는 모든 요청에 대해 고유한 클라이언트 요청 ID를 자동으로 생성합니다.
- Storage 클라이언트 라이브러리가 만드는 클라이언트 쪽 로그에서 클라이언트 요청 ID는
Client Request ID요청과 관련된 모든 로그 항목의 필드에 표시됩니다. - Fiddler에서 캡처한 것과 같은 네트워크 추적에서 클라이언트 요청 ID는 요청 메시지에 HTTP 헤더 값으로
x-ms-client-request-id표시됩니다. - 서버 쪽 스토리지 로깅 로그에서 클라이언트 요청 ID가 클라이언트 요청 ID 열에 나타납니다.
참고
스토리지 클라이언트 라이브러리가 새 값을 자동으로 할당하지만 클라이언트가 이 값을 할당할 수 있으므로 여러 요청이 동일한 클라이언트 요청 ID를 공유할 수 있습니다. 클라이언트가 다시 시도하면 모든 시도가 동일한 클라이언트 요청 ID를 공유합니다. 클라이언트에서 보낸 일괄 처리의 경우 일괄 처리에는 단일 클라이언트 요청 ID가 있습니다.
서버 요청 ID
스토리지 서비스는 서버 요청 ID를 자동으로 생성합니다.
- 서버 쪽 스토리지 로깅 로그에서 서버 요청 ID가 열에
Request ID header나타납니다. - Fiddler에서 캡처한 것과 같은 네트워크 추적에서 서버 요청 ID는 응답 메시지에 HTTP 헤더 값으로
x-ms-request-id표시됩니다. - 스토리지 클라이언트 라이브러리가 만드는 클라이언트 쪽 로그에서 서버 요청 ID는 서버 응답의
Operation Text세부 정보를 보여 주는 로그 항목의 열에 나타납니다.
참고
스토리지 서비스는 항상 수신하는 모든 요청에 고유한 서버 요청 ID를 할당하므로 클라이언트에서 다시 시도할 때마다 일괄 처리에 포함된 모든 작업에는 고유한 서버 요청 ID가 있습니다.
아래 코드 샘플에서는 사용자 지정 클라이언트 요청 ID를 사용하는 방법을 보여 줍니다.
var connectionString = Constants.connectionString;
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");
BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");
string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());
using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
BlobDownloadInfo download = blobClient.Download();
using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
{
download.Content.CopyTo(downloadFileStream);
downloadFileStream.Close();
}
}
타임 스탬프
타임스탬프를 사용하여 관련 로그 항목을 찾을 수도 있지만 존재할 수 있는 클라이언트와 서버 간의 클록 오차는 주의해야 합니다. Search 클라이언트의 타임스탬프를 기준으로 일치하는 서버 쪽 항목에 대해 15분을 더하거나 뺀 값입니다. 메트릭이 포함된 Blob에 대한 Blob 메타데이터는 Blob에 저장된 메트릭의 시간 범위를 나타냅니다. 이 시간 범위는 동일한 분 또는 시간에 대한 메트릭 Blob이 많은 경우에 유용합니다.
문제 해결 지침
이 섹션에서는 Azure Storage 서비스를 사용할 때 애플리케이션에서 발생할 수 있는 몇 가지 일반적인 문제를 진단하고 해결하는 데 도움이 됩니다. 아래 목록을 사용하여 특정 문제와 관련된 정보를 찾습니다.
문제 해결 의사 결정 트리
문제가 스토리지 서비스 중 하나의 성능과 관련이 있나요?
- 메트릭은 높은 AverageE2ELatency 및 낮은 AverageServerLatency를 표시합니다.
- 메트릭은 AverageE2ELatency가 낮고 AverageServerLatency가 낮지만 클라이언트에 높은 대기 시간이 발생합니다.
- 메트릭은 높은 AverageServerLatency를 표시합니다.
- 큐에서 메시지 배달이 예기치 않게 지연됩니다.
스토리지 서비스 중 하나의 가용성과 관련된 문제가 있나요?
- 메트릭은 PercentThrottlingError의 증가를 보여 줍니다.
- 메트릭은 PercentTimeoutError의 증가를 보여 줍니다.
- 메트릭은 PercentNetworkError의 증가를 보여 줍니다.
클라이언트 애플리케이션이 스토리지 서비스에서 HTTP 4XX(예: 404) 응답을 받고 있나요?
- 클라이언트가 HTTP 403(사용할 수 없음) 메시지를 수신하고 있습니다.
- 클라이언트가 HTTP 404(찾을 수 없음) 메시지를 수신하고 있습니다.
- 클라이언트가 HTTP 409(충돌) 메시지를 수신하고 있습니다.
메트릭은 낮은 PercentSuccess 또는 분석 로그 항목에 ClientOtherErrors의 트랜잭션 상태 있는 작업이 있음을 보여 줍니다.
용량 메트릭은 스토리지 용량 사용량이 예기치 않게 증가하는 것을 보여 줍니다.
개발 또는 테스트에 스토리지 에뮬레이터를 사용하면 문제가 발생합니다.
.NET용 Azure SDK를 설치하는 데 문제가 있습니다.
스토리지 서비스에 다른 문제가 있습니다.
메트릭은 높은 AverageE2ELatency 및 낮은 AverageServerLatency를 표시합니다.
Azure Portal 모니터링 도구의 아래 그림은 AverageE2ELatency가 AverageServerLatency보다 훨씬 높은 예제를 보여 줍니다.
스토리지 서비스는 성공적인 요청에 대한 메트릭 AverageE2ELatency 만 계산하며 AverageServerLatency와 달리 클라이언트가 데이터를 보내고 스토리지 서비스에서 승인을 받는 데 걸리는 시간을 포함합니다. 따라서 AverageE2ELatency 와 AverageServerLatency 의 차이는 클라이언트 애플리케이션의 응답 속도가 느리거나 네트워크의 조건으로 인해 발생할 수 있습니다.
참고
스토리지 로깅 로그 데이터에서 개별 스토리지 작업에 대한 E2ELatency 및 ServerLatency 를 볼 수도 있습니다.
클라이언트 성능 문제 조사
클라이언트가 느리게 응답하는 가능한 이유는 사용 가능한 연결 또는 스레드 수가 제한되거나 CPU, 메모리 또는 네트워크 대역폭과 같은 리소스가 부족하기 때문입니다. 클라이언트 코드를 보다 효율적으로 수정하거나(예: 스토리지 서비스에 대한 비동기 호출 사용) 더 큰 Virtual Machine(더 많은 코어 및 더 많은 메모리 포함)을 사용하여 문제를 resolve 수 있습니다.
테이블 및 큐 서비스의 경우 Nagle 알고리즘은 AverageServerLatency에 비해 AverageE2ELatency가 높을 수도 있습니다. 자세한 내용은 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와 같은 도구를 사용하여 삭제된 패킷과 같은 일시적 및 영구적 네트워크 문제를 모두 조사할 수 있습니다.
Wireshark를 사용하여 네트워크 문제를 해결하는 방법에 대한 자세한 내용은 부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처를 참조하세요.
메트릭은 AverageE2ELatency가 낮고 AverageServerLatency가 낮지만 클라이언트에 높은 대기 시간이 발생합니다.
이 시나리오에서 가장 가능성이 높은 원인은 스토리지 서비스에 도달하는 스토리지 요청의 지연입니다. 클라이언트의 요청이 Blob 서비스로 연결되지 않는 이유를 조사해야 합니다.
클라이언트가 요청 전송을 지연시키는 한 가지 가능한 이유는 사용 가능한 연결 또는 스레드 수가 제한되어 있기 때문입니다.
또한 클라이언트가 여러 횟수 재시도를 수행하는지 여부를 검사 이유를 조사합니다. 클라이언트가 여러 횟수 재시도를 수행하는지 여부를 확인하려면 다음을 수행할 수 있습니다.
- 스토리지 분석 로그를 검사합니다. 여러 번 다시 시도하면 클라이언트 요청 ID가 동일하지만 서버 요청 ID가 다른 여러 작업이 표시됩니다.
- 클라이언트 로그를 검사합니다. 자세한 정보 로깅은 다시 시도가 발생했음을 나타냅니다.
- 코드를 디버그하고 요청과 연결된 개체의
OperationContext속성을 검사. 작업이 다시 시도된RequestResults경우 속성에는 여러 고유 서버 요청 ID가 포함됩니다. 각 요청에 대한 시작 및 종료 시간을 검사 수도 있습니다. 자세한 내용은 서버 요청 ID 섹션의 코드 샘플을 참조하세요.
클라이언트에 문제가 없는 경우 패킷 손실과 같은 잠재적인 네트워크 문제를 조사해야 합니다. Wireshark와 같은 도구를 사용하여 네트워크 문제를 조사할 수 있습니다.
Wireshark를 사용하여 네트워크 문제를 해결하는 방법에 대한 자세한 내용은 부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처를 참조하세요.
메트릭은 높은 AverageServerLatency를 표시합니다.
Blob 다운로드 요청에 대한 AverageServerLatency 가 높은 경우 스토리지 로깅 로그를 사용하여 동일한 Blob(또는 Blob 집합)에 대한 반복된 요청이 있는지 확인해야 합니다. Blob 업로드 요청의 경우 클라이언트가 사용하는 블록 크기를 조사해야 합니다(예: 읽기가 64K 미만인 경우가 아니면 크기가 64K 미만인 블록은 오버헤드가 발생할 수 있습니다). 여러 클라이언트가 동일한 Blob에 블록을 병렬로 업로드하는 경우. 또한 초당 확장성 목표를 초과하는 요청 수의 급증에 대한 분당 메트릭을 검사 합니다. 자세한 내용은 PercentTimeoutError의 메트릭 증가 표시를 참조하세요.
동일한 Blob 또는 Blob 집합에 대한 반복된 요청이 있을 때 Blob 다운로드 요청에 대한 AverageServerLatency 가 높은 경우 Azure Cache 또는 AZURE CDN(Content Delivery Network)을 사용하여 이러한 Blob을 캐싱하는 것이 좋습니다. 업로드 요청의 경우 더 큰 블록 크기를 사용하여 처리량을 향상시킬 수 있습니다. 테이블에 대한 쿼리의 경우 동일한 쿼리 작업을 수행하고 데이터가 자주 변경되지 않는 클라이언트에서 클라이언트 쪽 캐싱을 구현할 수도 있습니다.
AverageServerLatency 값이 높음은 검사 작업을 발생하거나 추가/앞에 추가 안티 패턴을 따르는 잘못 디자인된 테이블 또는 쿼리의 증상일 수도 있습니다. 자세한 내용은 PercentThrottlingError의 증가 메트릭 표시를 참조하세요.
참고
성능 및 확장성 검사 목록 Microsoft Azure Storage 포괄적인 성능 검사 목록은 여기에서 찾을 수 있습니다.
큐에서 메시지 배달이 예기치 않게 지연되는 경우
애플리케이션이 큐에 메시지를 추가하는 시간과 큐에서 읽을 수 있는 시간 사이에 지연이 발생하는 경우 다음 단계를 수행하여 문제를 진단합니다.
- 애플리케이션이 큐에 메시지를 성공적으로 추가했는지 확인합니다. 애플리케이션이 성공하기 전에 메서드를
AddMessage여러 번 다시 시도하지 않는지 확인합니다. 스토리지 클라이언트 라이브러리 로그에는 스토리지 작업의 반복된 재시도가 표시됩니다. - 큐에 메시지를 추가하는 작업자 역할과 큐에서 메시지를 읽는 작업자 역할 사이에 클록 오차가 없는지 확인합니다. 시계 기울이기 때문에 처리가 지연되는 것처럼 표시됩니다.
- 큐에서 메시지를 읽는 작업자 역할이 실패하는지 확인합니다. 큐 클라이언트가 메서드를
GetMessage호출하지만 승인으로 응답하지 않으면 기간이 만료될 때까지invisibilityTimeout메시지가 큐에 표시되지 않습니다. 이 시점에서 메시지를 다시 처리할 수 있게 됩니다. - 큐 길이가 시간이 지남에 따라 증가하는지 확인합니다. 이는 다른 작업자가 큐에 배치하는 모든 메시지를 처리할 수 있는 충분한 작업자가 없는 경우에 발생할 수 있습니다. 또한 메트릭을 검사 삭제 요청이 실패하고 메시지의 큐에서 제거 횟수가 있는지 확인합니다. 이는 메시지를 삭제하려고 반복적으로 실패했음을 나타낼 수 있습니다.
- 예상보다 긴 기간 동안 E2ELatency 및 ServerLatency 값이 예상보다 높은 큐 작업에 대한 스토리지 로깅 로그를 검사합니다.
메트릭은 PercentThrottlingError의 증가를 보여 줍니다.
스토리지 서비스의 확장성 목표를 초과하면 제한 오류가 발생합니다. 스토리지 서비스는 단일 클라이언트 또는 테넌트가 다른 클라이언트를 희생하여 서비스를 사용할 수 없도록 제한합니다. 자세한 내용은 스토리지 계정의 확장성 목표 및 스토리지 계정 내 파티션의 성능 목표에 대한 자세한 내용은 표준 스토리지 계정의 확장성 및 성능 목표를 참조하세요.
PercentThrottlingError 메트릭에 제한 오류로 실패하는 요청 비율이 증가하는 것으로 표시되는 경우 다음 두 가지 시나리오 중 하나를 조사해야 합니다.
PercentThrottlingError의 증가는 스토리지 요청 수가 증가하거나 애플리케이션을 처음 로드 테스트할 때와 동시에 발생하는 경우가 많습니다. 또한 클라이언트에서 스토리지 작업의 메시지를 "503 서버 사용 중" 또는 "500 작업 시간 제한" HTTP 상태 메시지로 나타낼 수도 있습니다.
PercentThrottlingError의 일시적인 증가
애플리케이션에 대한 높은 활동 기간과 일치하는 PercentThrottlingError 값이 급증하는 경우 클라이언트에서 다시 시도하기 위한 지수(선형이 아닌) 백오프 전략을 구현할 수 있습니다. 백오프 재시도는 파티션의 즉각적인 부하를 줄이고 애플리케이션이 트래픽 급증을 원활하게 처리할 수 있도록 지원합니다. Storage 클라이언트 라이브러리를 사용하여 재시도 정책을 구현하는 방법에 대한 자세한 내용은 Microsoft.Azure.Storage.RetryPolicies 네임스페이스를 참조하세요.
참고
애플리케이션에 대한 높은 활동 기간과 일치하지 않는 PercentThrottlingError 값이 급증할 수도 있습니다. 가장 가능성이 높은 원인은 부하 분산을 개선하기 위해 파티션을 이동하는 스토리지 서비스입니다.
PercentThrottlingError의 영구 증가
트랜잭션 볼륨이 영구적으로 증가한 후 PercentThrottlingError 에 대해 지속적으로 높은 값이 표시되는 경우 또는 애플리케이션에서 초기 부하 테스트를 수행할 때 애플리케이션이 스토리지 파티션을 사용하는 방법과 스토리지 계정의 확장성 목표에 근접하는지 평가해야 합니다. 예를 들어 큐에 제한 오류(단일 파티션으로 계산됨)가 표시되는 경우 추가 큐를 사용하여 트랜잭션을 여러 파티션에 분산하는 것이 좋습니다. 테이블에 제한 오류가 표시되는 경우 다른 분할 체계를 사용하여 더 넓은 범위의 파티션 키 값을 사용하여 여러 파티션에 트랜잭션을 분산하는 것이 좋습니다. 이 문제의 일반적인 원인 중 하나는 파티션 키로 날짜를 선택한 다음 특정 날짜의 모든 데이터가 하나의 파티션에 기록되는 앞에 추가/추가 안티패턴입니다. 로드 시 쓰기 병목 현상이 발생할 수 있습니다. 다른 분할 디자인을 고려하거나 Blob Storage를 사용하는 것이 더 나은 솔루션인지 평가합니다. 또한 트래픽 급증으로 인해 제한이 발생하는지 여부를 검사 요청 패턴을 부드럽게 하는 방법을 조사합니다.
트랜잭션을 여러 파티션에 분산하는 경우 스토리지 계정에 대해 설정된 확장성 제한을 알고 있어야 합니다. 예를 들어 초당 최대 2,000개의 1KB 메시지를 처리하는 10개의 큐를 사용한 경우 스토리지 계정에 대해 초당 20,000개의 메시지로 제한됩니다. 초당 20,000개 이상의 엔터티를 처리해야 하는 경우 여러 스토리지 계정을 사용하는 것이 좋습니다. 또한 요청 및 엔터티의 크기는 스토리지 서비스가 클라이언트를 제한할 때 영향을 줍니다. 더 큰 요청 및 엔터티가 있는 경우 더 빨리 제한될 수 있습니다.
비효율적인 쿼리 디자인으로 인해 테이블 파티션의 확장성 제한에 도달할 수도 있습니다. 예를 들어 파티션에서 엔터티의 1%만 선택하지만 파티션의 모든 엔터티를 검사하는 필터가 있는 쿼리는 각 엔터티에 액세스해야 합니다. 모든 엔터티 읽기는 해당 파티션의 총 트랜잭션 수에 계산됩니다. 따라서 확장성 목표에 쉽게 도달할 수 있습니다.
참고
성능 테스트는 애플리케이션의 비효율적인 쿼리 디자인을 표시해야 합니다.
메트릭은 PercentTimeoutError의 증가를 보여 줍니다.
메트릭은 스토리지 서비스 중 하나에 대한 PercentTimeoutError 의 증가를 보여 줍니다. 동시에 클라이언트는 스토리지 작업에서 대량의 "500 작업 시간 제한" HTTP 상태 메시지를 받습니다.
참고
스토리지 서비스가 파티션을 새 서버로 이동하여 요청을 부하 분산하기 때문에 시간 제한 오류가 일시적으로 표시 될 수 있습니다.
PercentTimeoutError 메트릭은 ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError 및 SASServerTimeoutError 메트릭의 집계입니다.
서버 시간 제한은 서버의 오류로 인해 발생합니다. 클라이언트 시간 제한은 서버의 작업이 클라이언트에서 지정한 시간 제한을 초과했기 때문에 발생합니다. 예를 들어 스토리지 클라이언트 라이브러리를 사용하는 클라이언트는 클래스의 QueueRequestOptions 속성을 사용하여 ServerTimeout 작업에 대한 시간 제한을 설정할 수 있습니다.
서버 시간 제한은 추가 조사가 필요한 스토리지 서비스에 문제가 있음을 나타냅니다. 메트릭을 사용하여 서비스에 대한 확장성 제한에 도달했는지 확인하고 이 문제를 일으킬 수 있는 트래픽 급증을 식별할 수 있습니다. 문제가 일시적인 경우 서비스의 부하 분산 작업 때문일 수 있습니다. 문제가 지속적이고 애플리케이션이 서비스의 확장성 제한에 도달하여 발생하지 않는 경우 지원 문제를 제기해야 합니다. 클라이언트 시간 제한의 경우 시간 제한이 클라이언트에서 적절한 값으로 설정되어 있는지 여부를 결정하고 클라이언트에서 설정된 시간 제한 값을 변경하거나, 예를 들어 테이블 쿼리를 최적화하거나 메시지 크기를 줄여 스토리지 서비스에서 작업의 성능을 향상시키는 방법을 조사해야 합니다.
메트릭은 PercentNetworkError의 증가를 보여 줍니다.
메트릭은 스토리지 서비스 중 하나에 대한 PercentNetworkError 의 증가를 보여 줍니다. PercentNetworkError 메트릭은 NetworkError, AnonymousNetworkError 및 SASNetworkError 메트릭의 집계입니다. 이는 클라이언트가 스토리지 요청을 수행할 때 스토리지 서비스에서 네트워크 오류를 감지할 때 발생합니다.
이 오류의 가장 일반적인 원인은 스토리지 서비스에서 시간 제한이 만료되기 전에 클라이언트 연결을 끊는 것입니다. 클라이언트의 코드를 조사하여 클라이언트가 스토리지 서비스에서 연결을 끊는 이유와 시기를 이해합니다. Wireshark 또는 Tcping을 사용하여 클라이언트의 네트워크 연결 문제를 조사할 수도 있습니다. 이러한 도구는 부록에 설명 되어 있습니다.
클라이언트가 HTTP 403(사용할 수 없음) 메시지를 수신하고 있습니다.
클라이언트 애플리케이션이 HTTP 403(사용할 수 없음) 오류를 throw하는 경우 클라이언트가 스토리지 요청을 보낼 때 만료된 SAS(공유 액세스 서명)를 사용하고 있는 것일 수 있습니다(다른 가능한 원인으로는 클록 기울이기, 잘못된 키 및 빈 헤더가 포함됨). 만료된 SAS 키가 원인인 경우 서버 쪽 스토리지 로깅 로그 데이터에 항목이 표시되지 않습니다. 다음 표에서는 이 문제가 발생하는 것을 보여 주는 스토리지 클라이언트 라이브러리에서 생성된 클라이언트 쪽 로그의 샘플을 보여 줍니다.
| 원본 | 세부 정보 표시 | 세부 정보 표시 | 클라이언트 요청 ID | 작업 텍스트 |
|---|---|---|---|---|
| Microsoft.Azure.Storage | 정보 | 3 | 85d077ab-... | Starting operation with location Primary per location mode PrimaryOnly. |
| Microsoft.Azure.Storage | 정보 | 3 | 85d077ab -... | Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request. |
| Microsoft.Azure.Storage | 정보 | 3 | 85d077ab -... | Waiting for response. |
| Microsoft.Azure.Storage | 경고 | 2 | 85d077ab -... | Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden. |
| Microsoft.Azure.Storage | 정보 | 3 | 85d077ab -... | Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = . |
| Microsoft.Azure.Storage | 경고 | 2 | 85d077ab -... | Exception thrown during the operation: The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | 정보 | 3 | 85d077ab -... | Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | 정보 | 3 | 85d077ab -... | The next location has been set to Primary, based on the location mode. |
| Microsoft.Azure.Storage | 오류 | 1 | 85d077ab -... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden. |
이 시나리오에서는 클라이언트가 서버에 토큰을 보내기 전에 SAS 토큰이 만료되는 이유를 조사해야 합니다.
- 일반적으로 클라이언트에서 즉시 사용할 SAS를 만들 때 시작 시간을 설정해서는 안 됩니다. 현재 시간을 사용하여 SAS를 생성하는 호스트와 스토리지 서비스 간에 약간의 클록 차이가 있는 경우 스토리지 서비스에서 아직 유효하지 않은 SAS를 받을 수 있습니다.
- SAS에서 매우 짧은 만료 시간을 설정하지 마세요. 다시 말하지만, SAS를 생성하는 호스트와 스토리지 서비스 간의 작은 클록 차이로 인해 SAS가 예상보다 일찍 만료될 수 있습니다.
- SAS 키의 version 매개 변수(예
sv: =2015-04-05)가 사용 중인 Storage 클라이언트 라이브러리 버전과 일치하나요? 항상 최신 버전의 Storage 클라이언트 라이브러리를 사용하는 것이 좋습니다. - 스토리지 액세스 키를 다시 생성하는 경우 기존 SAS 토큰이 무효화될 수 있습니다. 이 문제는 클라이언트 애플리케이션이 캐시할 만료 시간이 긴 SAS 토큰을 생성하는 경우에 발생할 수 있습니다.
스토리지 클라이언트 라이브러리를 사용하여 SAS 토큰을 생성하는 경우 유효한 토큰을 쉽게 빌드할 수 있습니다. 그러나 스토리지 REST API를 사용하고 SAS 토큰을 직접 생성하는 경우 공유 액세스 서명을 사용하여 액세스 위임을 참조하세요.
클라이언트가 HTTP 404(찾을 수 없음) 메시지를 수신하고 있습니다.
클라이언트 애플리케이션이 서버에서 HTTP 404(찾을 수 없음) 메시지를 수신하는 경우 이는 클라이언트가 사용하려는 개체(예: 엔터티, 테이블, Blob, 컨테이너 또는 큐)가 스토리지 서비스에 없음을 의미합니다. 다음과 같은 여러 가지 가능한 이유가 있습니다.
- 클라이언트 또는 다른 프로세스가 이전에 개체를 삭제했습니다.
- SAS(공유 액세스 서명) 권한 부여 문제입니다.
- 클라이언트 쪽 JavaScript 코드에는 개체에 액세스할 수 있는 권한이 없습니다.
- 네트워크 오류.
이전에 개체를 삭제한 클라이언트 또는 다른 프로세스
클라이언트가 스토리지 서비스에서 데이터를 읽거나 업데이트하거나 삭제하려고 하는 시나리오에서는 일반적으로 서버 쪽 로그에서 스토리지 서비스에서 문제의 개체를 삭제한 이전 작업을 쉽게 식별할 수 있습니다. 로그 데이터에 다른 사용자 또는 프로세스가 개체를 삭제한 것으로 표시되는 경우가 많습니다. 서버 쪽 Storage 로깅 로그에서 작업 유형 및 requested-object-key 열은 클라이언트가 개체를 삭제한 경우를 표시합니다.
클라이언트가 개체를 삽입하려고 하는 시나리오에서는 클라이언트가 새 개체를 만드는 경우 HTTP 404(찾을 수 없음) 응답이 발생하는 이유가 즉시 명확하지 않을 수 있습니다. 그러나 클라이언트가 Blob을 만드는 경우 Blob 컨테이너를 찾을 수 있어야 합니다. 클라이언트가 메시지를 만드는 경우 큐를 찾을 수 있어야 합니다. 클라이언트가 행을 추가하는 경우 테이블을 찾을 수 있어야 합니다.
스토리지 클라이언트 라이브러리의 클라이언트 쪽 로그를 사용하여 클라이언트가 스토리지 서비스에 특정 요청을 보내는 시기를 보다 자세히 이해할 수 있습니다.
Storage 클라이언트 라이브러리에서 생성된 다음 클라이언트 쪽 로그는 클라이언트가 만드는 Blob에 대한 컨테이너를 찾을 수 없는 경우의 문제를 보여 줍니다. 이 로그에는 다음 스토리지 작업에 대한 세부 정보가 포함됩니다.
| 요청 ID | 작업 |
|---|---|
| 07b26a5d-... | DeleteIfExists 메서드를 사용하여 Blob 컨테이너를 삭제합니다. 이 작업에는 컨테이너의 존재에 대한 검사 요청이 포함 HEAD 됩니다. |
| e2d06d78... | CreateIfNotExists 메서드를 사용하여 Blob 컨테이너를 만듭니다. 이 작업에는 컨테이너의 존재를 확인하는 요청이 포함 HEAD 됩니다. 는 HEAD 404 메시지를 반환하지만 계속합니다. |
| de8b1c3c-... | UploadFromStream 메서드를 사용하여 Blob을 만듭니다. 요청이 PUT 404 메시지와 함께 실패합니다. |
로그 항목:
| 요청 ID | 작업 텍스트 |
|---|---|
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = "0x8D14D2DC63D059B". |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = . |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | Preparing to write request data. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| e2d06d78-... | Downloading response body. |
| e2d06d78-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Writing request data. |
| de8b1c3c-... | Waiting for response. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (409) Conflict.. |
| e2d06d78-... | Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Downloading error response body. |
| de8b1c3c-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = . |
| de8b1c3c-... | Exception thrown during the operation: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict.. |
이 예제에서 로그는 클라이언트가 메서드의 요청(요청 CreateIfNotExists ID e2d06d78...)과 메서드의 요청 UploadFromStream (de8b1c3c-...)을 인터리빙하고 있음을 보여 줍니다. 이 인터리빙은 클라이언트 애플리케이션이 이러한 메서드를 비동기적으로 호출하기 때문에 발생합니다. 클라이언트에서 비동기 코드를 수정하여 해당 컨테이너의 Blob에 데이터를 업로드하기 전에 컨테이너를 만들도록 합니다. 이상적으로는 모든 컨테이너를 미리 만들어야 합니다.
SAS(공유 액세스 서명) 권한 부여 문제
클라이언트 애플리케이션이 작업에 필요한 권한을 포함하지 않는 SAS 키를 사용하려고 하면 스토리지 서비스는 HTTP 404(찾을 수 없음) 메시지를 클라이언트에 반환합니다. 동시에 메트릭에 에 대한 SASAuthorizationError 값이 0이 아닌 값도 표시됩니다.
다음 표에서는 스토리지 로깅 로그 파일의 샘플 서버 쪽 로그 메시지를 보여 줍니다.
| 이름 | 값 |
|---|---|
| 요청 시작 시간 | 2014-05-30T06:17:48.4473697Z |
| 작업 유형 | GetBlobProperties |
| 요청 상태 | SASAuthorizationError |
| HTTP 상태 코드 | 404 |
| 인증 유형 | Sas |
| 서비스 유형 | Blob |
| 요청 URL | https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt |
| ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14 | |
| 요청 ID 헤더 | <요청 ID 헤더> |
| 클라이언트 요청 ID | <클라이언트 요청 ID> |
클라이언트 애플리케이션이 권한이 부여되지 않은 작업을 수행하려는 이유를 조사합니다.
클라이언트 쪽 JavaScript 코드에는 개체에 액세스할 수 있는 권한이 없습니다.
JavaScript 클라이언트를 사용 중이고 스토리지 서비스가 HTTP 404 메시지를 반환하는 경우 브라우저에서 다음 JavaScript 오류를 검사.
SEC7120: Access-Control-Allow-Origin 헤더에서 원본 http://localhost:56309 을 찾을 수 없습니다.
SCRIPT7002: XMLHttpRequest: 네트워크 오류 0x80070005 액세스가 거부되었습니다.
참고
인터넷 Explorer F12 개발자 도구를 사용하여 클라이언트 쪽 JavaScript 문제를 해결할 때 브라우저와 스토리지 서비스 간에 교환된 메시지를 추적할 수 있습니다.
이러한 오류는 웹 브라우저가 웹 페이지가 페이지가 가져온 도메인과 다른 도메인의 API를 호출하지 못하도록 하는 동일한 원본 정책 보안 제한을 구현하기 때문에 발생합니다.
JavaScript 문제를 해결하려면 클라이언트가 액세스하는 스토리지 서비스에 대해 CORS(원본 간 리소스 공유)를 구성할 수 있습니다. 자세한 내용은 Azure Storage 서비스에 대한 CORS(원본 간 리소스 공유) 지원을 참조하세요.
다음 코드 샘플에서는 Contoso 도메인에서 실행되는 JavaScript가 Blob Storage 서비스의 Blob에 액세스할 수 있도록 Blob 서비스를 구성하는 방법을 보여 줍니다.
var connectionString = Constants.connectionString;
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobServiceProperties sp = blobServiceClient.GetProperties();
// Set the service properties.
sp.DefaultServiceVersion = "2013-08-15";
BlobCorsRule bcr = new BlobCorsRule();
bcr.AllowedHeaders = "*";
bcr.AllowedMethods = "GET,POST";
bcr.AllowedOrigins = "http://www.contoso.com";
bcr.ExposedHeaders = "x-ms-*";
bcr.MaxAgeInSeconds = 5;
sp.Cors.Clear();
sp.Cors.Add(bcr);
blobServiceClient.SetProperties(sp);
네트워크 오류
경우에 따라 네트워크 패킷이 손실되면 스토리지 서비스가 HTTP 404 메시지를 클라이언트로 반환할 수 있습니다. 예를 들어 클라이언트 애플리케이션이 테이블 서비스에서 엔터티를 삭제하는 경우 클라이언트가 테이블 서비스에서 "HTTP 404(찾을 수 없음)" 상태 메시지를 보고하는 스토리지 예외를 throw하는 것을 볼 수 있습니다. 테이블 스토리지 서비스의 테이블을 조사할 때 서비스가 요청된 대로 엔터티를 삭제한 것을 볼 수 있습니다.
클라이언트의 예외 세부 정보에는 요청에 대해 테이블 서비스에서 할당한 요청 ID(7e84f12d...)가 포함됩니다. 이 정보를 사용하여 로그 파일의 열에서 검색하여 서버 쪽 스토리지 로그에서 request-id-header 요청 세부 정보를 찾을 수 있습니다. 메트릭을 사용하여 이와 같은 오류가 발생하는 시기를 식별한 다음 메트릭이 이 오류를 기록한 시간에 따라 로그 파일을 검색할 수도 있습니다. 이 로그 항목은 "HTTP(404) 클라이언트 기타 오류" 상태 메시지와 함께 삭제가 실패했음을 보여 줍니다. 동일한 로그 항목에는 열(813ea74f...)에서 클라이언트가 client-request-id 생성한 요청 ID도 포함됩니다.
또한 서버 쪽 로그에는 동일한 엔터티 및 동일한 client-request-id 클라이언트에서 성공적으로 삭제 작업을 수행할 수 있는 동일한 값(813ea74f...)의 다른 항목도 포함됩니다. 이 성공적인 삭제 작업은 실패한 삭제 요청 직전에 수행되었습니다.
이 시나리오의 가장 가능성이 높은 원인은 클라이언트가 엔터티에 대한 삭제 요청을 테이블 서비스로 보냈기 때문입니다. 이 요청은 성공했지만 서버로부터 승인을 받지 못했습니다(임시 네트워크 문제 때문일 수 있음). 그런 다음 클라이언트는 동일한 client-request-id를 사용하여 작업을 자동으로 다시 시도했으며 엔터티가 이미 삭제되었기 때문에 이 재시도에 실패했습니다.
이 문제가 자주 발생하는 경우 클라이언트가 테이블 서비스에서 승인을 받지 못하는 이유를 조사해야 합니다. 문제가 일시적인 경우 "HTTP(404) 찾을 수 없음" 오류를 트래핑하고 클라이언트에 기록해야 하지만 클라이언트가 계속되도록 허용해야 합니다.
클라이언트가 HTTP 409(충돌) 메시지를 수신하고 있습니다.
다음 표에서는 두 클라이언트 작업에 DeleteIfExists 대한 서버 쪽 로그의 추출을 보여 줍니다. 그 다음에는 동일한 Blob 컨테이너 이름을 사용하여 즉시 CreateIfNotExists 수행됩니다. 각 클라이언트 작업을 수행하면 두 개의 요청이 서버로 전송되고, 먼저 GetContainerProperties 컨테이너가 있는 경우 검사 요청과 DeleteContainer 또는 CreateContainer 요청이 차례로 발생합니다.
| Timestamp | 작업 | 결과 | Container 이름 | 클라이언트 요청 ID |
|---|---|---|---|---|
| 05:10:13.7167225 | GetContainerProperties |
200 | mmcont | c9f52c89-... |
| 05:10:13.8167325 | DeleteContainer |
202 | mmcont | c9f52c89-... |
| 05:10:13.8987407 | GetContainerProperties |
404 | mmcont | bc881924-... |
| 05:10:14.2147723 | CreateContainer |
409 | mmcont | bc881924-... |
클라이언트 애플리케이션의 코드는 동일한 이름을 사용하여 Blob 컨테이너를 삭제한 다음 즉시 다시 만듭니다. CreateIfNotExists 메서드(클라이언트 요청 ID bc881924-...)는 결국 HTTP 409(충돌) 오류로 인해 실패합니다. 클라이언트가 Blob 컨테이너, 테이블 또는 큐를 삭제하는 경우 이름을 다시 사용할 수 있게 되기까지 짧은 기간이 있습니다.
클라이언트 애플리케이션은 삭제/다시 만들기 패턴이 일반적인 경우 새 컨테이너를 만들 때마다 고유한 컨테이너 이름을 사용해야 합니다.
메트릭에 낮은 PercentSuccess 또는 분석 로그 항목에 ClientOtherErrors의 트랜잭션 상태 있는 작업이 있음을 보여 줍니다.
PercentSuccess 메트릭은 HTTP 상태 코드를 기반으로 성공한 작업의 백분율을 캡처합니다. 상태 코드가 2XX인 작업은 성공한 것으로 계산되지만 3XX, 4XX 및 5XX 범위의 상태 코드를 사용하는 작업은 실패한 것으로 계산되고 PercentSuccess 메트릭 값이 낮아집니다. 서버 쪽 스토리지 로그 파일에서 이러한 작업은 ClientOtherErrors의 트랜잭션 상태 기록됩니다.
이러한 작업이 성공적으로 완료되었으므로 가용성과 같은 다른 메트릭에는 영향을 주지 않는다는 점에 유의해야 합니다. 성공적으로 실행되지만 실패한 HTTP 상태 코드가 발생할 수 있는 작업의 몇 가지 예는 다음과 같습니다.
- ResourceNotFound(찾을 수 없음 404) 예를 들어 요청에서
GET존재하지 않는 Blob에 이르기까지. - ResourceAlreadyExists(충돌 409) 예를 들어 리소스가
CreateIfNotExist이미 있는 작업입니다. - ConditionNotMet(수정되지 않음 304) 예를 들어 클라이언트가 마지막 작업 이후 업데이트된 경우에만 이미지를 요청하기 위해 값 및 HTTP
If-None-Match헤더를 보내는ETag경우와 같은 조건부 작업에서 발생합니다.
스토리지 서비스가 일반적인 REST API 오류 코드 페이지에서 반환하는 일반적인 REST API 오류 코드 목록을 찾을 수 있습니다.
용량 메트릭은 스토리지 용량 사용량이 예기치 않게 증가하는 것을 보여 줍니다.
스토리지 계정에서 갑자기 예기치 않은 용량 사용량이 변경되는 경우 가용성 메트릭을 먼저 확인하여 이유를 조사할 수 있습니다. 예를 들어 실패한 삭제 요청 수가 증가하면 공간을 확보할 것으로 예상했을 수 있는 애플리케이션별 정리 작업으로 사용 중인 Blob Storage의 양이 예상대로 작동하지 않을 수 있습니다(예: 공간 확보에 사용되는 SAS 토큰이 만료되었기 때문).
개발 또는 테스트에 스토리지 에뮬레이터를 사용하면 문제가 발생합니다.
일반적으로 개발 및 테스트 중에 스토리지 에뮬레이터를 사용하여 Azure Storage 계정에 대한 요구 사항을 방지합니다. 스토리지 에뮬레이터를 사용할 때 발생할 수 있는 일반적인 문제는 다음과 같습니다.
- 스토리지 에뮬레이터에서 기능 "X"가 작동하지 않습니다.
- 스토리지 에뮬레이터를 사용할 때 "HTTP 헤더 중 하나에 대한 값이 올바른 형식이 아닙니다." 오류가 발생했습니다.
- 스토리지 에뮬레이터를 실행하려면 관리 권한이 필요합니다.
스토리지 에뮬레이터에서 기능 "X"가 작동하지 않음
스토리지 에뮬레이터는 파일 서비스와 같은 Azure Storage 서비스의 모든 기능을 지원하지 않습니다. 자세한 내용은 개발 및 테스트에 Azure Storage 에뮬레이터 사용을 참조하세요.
스토리지 에뮬레이터에서 지원하지 않는 기능의 경우 클라우드에서 Azure Storage 서비스를 사용합니다.
스토리지 에뮬레이터를 사용할 때 "HTTP 헤더 중 하나에 대한 값이 올바른 형식이 아닙니다." 오류
로컬 스토리지 에뮬레이터에 대해 Storage 클라이언트 라이브러리를 사용하는 애플리케이션을 테스트하고 "HTTP 헤더 중 하나에 대한 값이 올바른 형식이 아닙니다."라는 오류 메시지와 함께 실패와 같은 CreateIfNotExists 메서드 호출을 테스트하고 있습니다. 이는 사용 중인 스토리지 에뮬레이터 버전이 사용 중인 스토리지 클라이언트 라이브러리의 버전을 지원하지 않음을 나타냅니다. 스토리지 클라이언트 라이브러리는 헤더가 만드는 모든 요청에 헤더 x-ms-version 를 추가합니다. 스토리지 에뮬레이터가 헤더의 값을 x-ms-version 인식하지 못하면 요청을 거부합니다.
스토리지 라이브러리 클라이언트 로그를 사용하여 전송하는 의 x-ms-version header 값을 볼 수 있습니다. Fiddler를 사용하여 클라이언트 애플리케이션의 요청을 추적하는 경우에도 의 x-ms-version header 값을 볼 수 있습니다.
이 시나리오는 일반적으로 스토리지 에뮬레이터를 업데이트하지 않고 최신 버전의 Storage 클라이언트 라이브러리를 설치하고 사용하는 경우에 발생합니다. 최신 버전의 스토리지 에뮬레이터를 설치하거나 개발 및 테스트를 위해 에뮬레이터 대신 클라우드 스토리지를 사용해야 합니다.
스토리지 에뮬레이터를 실행하려면 관리 권한이 필요합니다.
스토리지 에뮬레이터를 실행할 때 관리자 자격 증명을 묻는 메시지가 표시됩니다. 이는 스토리지 에뮬레이터를 처음으로 초기화할 때만 발생합니다. 스토리지 에뮬레이터를 초기화한 후에는 다시 실행하기 위해 관리 권한이 필요하지 않습니다.
자세한 내용은 개발 및 테스트에 Azure Storage 에뮬레이터 사용을 참조하세요. Visual Studio에서 스토리지 에뮬레이터를 초기화할 수도 있으며, 관리 권한도 필요합니다.
.NET용 Azure SDK를 설치하는 데 문제가 발생했습니다.
SDK를 설치하려고 하면 로컬 컴퓨터에 스토리지 에뮬레이터를 설치하는 동안 실패합니다. 설치 로그에는 다음 메시지 중 하나가 포함됩니다.
- CAQuietExec: 오류: SQL instance 액세스할 수 없음
- CAQuietExec: 오류: 데이터베이스를 만들 수 없음
원인은 기존 LocalDB 설치와 관련된 문제입니다. 기본적으로 스토리지 에뮬레이터는 LocalDB를 사용하여 Azure Storage 서비스를 시뮬레이트할 때 데이터를 유지합니다. SDK를 설치하기 전에 명령 프롬프트 창에서 다음 명령을 실행하여 LocalDB instance 다시 설정할 수 있습니다.
sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0
이 delete 명령은 스토리지 에뮬레이터의 이전 설치에서 이전 데이터베이스 파일을 제거합니다.
스토리지 서비스에 다른 문제가 있습니다.
이전 문제 해결 섹션에 스토리지 서비스에 대한 문제가 포함되지 않은 경우 문제를 진단하고 해결하는 다음 방법을 채택해야 합니다.
- 메트릭을 확인하여 예상 기준 동작에서 변경 내용이 있는지 확인합니다. 메트릭에서 문제가 일시적인지 영구적인지, 문제가 영향을 미치는 스토리지 작업을 확인할 수 있습니다.
- 메트릭 정보를 사용하여 서버 쪽 로그 데이터를 검색하여 발생하는 오류에 대한 자세한 정보를 검색할 수 있습니다. 이 정보는 문제를 해결하고 resolve 데 도움이 될 수 있습니다.
- 서버 쪽 로그의 정보가 문제를 성공적으로 해결하는 데 충분하지 않은 경우 Storage 클라이언트 라이브러리 클라이언트 쪽 로그를 사용하여 클라이언트 애플리케이션 및 Fiddler 및 Wireshark와 같은 도구의 동작을 조사하여 네트워크를 조사할 수 있습니다.
Fiddler 사용에 대한 자세한 내용은 부록 1: Fiddler를 사용하여 HTTP 및 HTTPS 트래픽 캡처를 참조하세요.
Wireshark 사용에 대한 자세한 내용은 부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처를 참조하세요.
부록
부록은 Azure Storage(및 기타 서비스) 문제를 진단하고 해결할 때 유용할 수 있는 여러 도구를 설명합니다. 이러한 도구는 Azure Storage의 일부가 아니며 일부는 타사 제품입니다. 따라서 이러한 부록에서 설명하는 도구에는 Microsoft Azure 또는 Azure Storage와 체결할 수 있는 지원 계약이 적용되지 않습니다. 따라서 평가 프로세스의 일부로 이러한 도구의 공급자에서 사용할 수 있는 라이선스 및 지원 옵션을 검토해야 합니다.
부록 1: Fiddler를 사용하여 HTTP 및 HTTPS 트래픽 캡처
Fiddler 는 클라이언트 애플리케이션과 사용 중인 Azure Storage 서비스 간의 HTTP 및 HTTPS 트래픽을 분석하는 데 유용한 도구입니다.
참고
Fiddler는 HTTPS 트래픽을 디코딩할 수 있습니다. Fiddler 설명서를 주의 깊게 읽어 이 작업을 수행하는 방법과 보안에 미치는 영향을 이해해야 합니다.
이 부록은 Fiddler를 설치한 로컬 머신과 Azure Storage 서비스 간의 트래픽을 캡처하도록 Fiddler를 구성하는 방법에 대한 간략한 연습을 제공합니다.
Fiddler를 시작한 후에는 로컬 컴퓨터에서 HTTP 및 HTTPS 트래픽 캡처를 시작합니다. 다음은 Fiddler를 제어하는 데 유용한 몇 가지 명령입니다.
- 트래픽 캡처를 중지하고 시작합니다. 기본 메뉴에서 파일로 이동한 다음 트래픽 캡처를 선택하여 캡처를 켜고 끕니다.
- 캡처된 트래픽 데이터를 저장합니다. 기본 메뉴에서 파일로 이동하여 저장을 선택한 다음, 모든 세션을 선택합니다. 이렇게 하면 세션 보관 파일에 트래픽을 저장할 수 있습니다. 나중에 분석을 위해 세션 보관 파일을 다시 로드하거나 Microsoft 지원에 요청된 경우 보낼 수 있습니다.
Fiddler가 캡처하는 트래픽의 양을 제한하려면 필터 탭에서 구성하는 필터를 사용할 수 있습니다. 다음 스크린샷은 스토리지 엔드포인트로 전송된 트래픽만 캡처하는 필터를 contosoemaildist.table.core.windows.net 보여 줍니다.
부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처
Wireshark 는 광범위한 네트워크 프로토콜에 대한 자세한 패킷 정보를 볼 수 있는 네트워크 프로토콜 분석기입니다.
다음 절차에서는 Wireshark를 설치한 로컬 컴퓨터에서 Azure Storage 계정의 테이블 서비스로 트래픽에 대한 자세한 패킷 정보를 캡처하는 방법을 보여 줍니다.
로컬 컴퓨터에서 Wireshark를 시작합니다.
시작 섹션에서 인터넷에 연결된 로컬 네트워크 인터페이스 또는 인터페이스를 선택합니다.
캡처 옵션을 선택합니다.
필터 캡처 텍스트 상자에 필터를 추가합니다. 예를 들어
host contosoemaildist.table.core.windows.net은 contosoemaildist 스토리지 계정의 테이블 서비스 엔드포인트에서 전송된 패킷만 캡처하도록 Wireshark를 구성합니다. 캡처 필터의 전체 목록을 확인합니다.
시작을 선택합니다. 이제 Wireshark는 로컬 컴퓨터에서 클라이언트 애플리케이션을 사용할 때 테이블 서비스 엔드포인트에서 전송된 모든 패킷을 캡처합니다.
완료되면 기본 메뉴에서 캡처>중지를 선택합니다.
캡처된 데이터를 Wireshark 캡처 파일에 저장하려면 기본 메뉴에서 파일>저장을 선택합니다.
WireShark는 패킷 목록 창에 있는 모든 오류를 강조 표시합니다. 전문가 정보 창(전문가 정보분석> 선택)을 사용하여 오류 및 경고 요약을 볼 수도 있습니다.
TCP 데이터를 마우스 오른쪽 단추로 클릭하고 TCP Stream 팔로우를 선택하여 애플리케이션 계층에서 볼 때 TCP 데이터를 볼 수도 있습니다. 이는 캡처 필터 없이 덤프를 캡처한 경우에 유용합니다. 자세한 내용은 다음 TCP 스트림을 참조하세요.
참고
Wireshark 사용에 대한 자세한 내용은 Wireshark 사용자 가이드를 참조하세요.
부록 4: Excel을 사용하여 메트릭 및 로그 데이터 보기
많은 도구를 사용하여 Azure Table Storage에서 데이터를 구분된 형식으로 다운로드하여 보기 및 분석을 위해 Excel에 데이터를 쉽게 로드할 수 있습니다. Azure Blob Storage 스토리지 로깅 데이터는 Excel에 로드할 수 있는 구분된 형식으로 이미 있습니다. 그러나 스토리지 분석 로그 형식 및 스토리지 분석메트릭 테이블 스키마의 정보에 따라 적절한 열 머리글을 추가해야 합니다.
Blob Storage에서 다운로드한 후 스토리지 로깅 데이터를 Excel로 가져오려면 다음을 수행합니다.
- 데이터 메뉴에서 텍스트에서를 선택합니다.
- 보려는 로그 파일로 이동하여 가져오기를 선택합니다.
- 텍스트 가져오기 마법사의 1단계에서 구분 기호를 선택합니다.
텍스트 가져오기 마법사의 1단계에서 유일한 구분 기호로 세미콜론을 선택하고 텍스트 한정자로 큰따옴표를 선택합니다. 그런 다음 마침 을 선택하고 통합 문서에 데이터를 배치할 위치를 선택합니다.
부록 5: Azure DevOps용 Application Insights를 사용하여 모니터링
성능 및 가용성 모니터링의 일부로 Azure DevOps용 Application Insights 기능을 사용할 수도 있습니다. 이 도구는 다음을 수행할 수 있습니다.
- 웹 서비스를 사용할 수 있고 응답성이 있는지 확인합니다. 앱이 웹 사이트이든 웹 서비스를 사용하는 디바이스 앱이든 관계없이 전 세계 위치에서 몇 분마다 URL을 테스트하고 문제가 있는지 알려줄 수 있습니다.
- 웹 서비스의 성능 문제 또는 예외를 신속하게 진단합니다. CPU 또는 기타 리소스가 늘어나고 있는지 확인하고, 예외에서 스택 추적을 가져와 로그 추적을 쉽게 검색합니다. 앱의 성능이 허용 가능한 한도 아래로 떨어지면 Microsoft에서 전자 메일을 보낼 수 있습니다. .NET 및 Java 웹 서비스를 모두 모니터링할 수 있습니다.
자세한 내용은 Application Insights란?에서 확인할 수 있습니다.
다음 단계
Azure Storage의 분석에 대한 자세한 내용은 다음 리소스를 참조하세요.
타사 정보 고지 사항
이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기