Microsoft Azure Storage(클래식) 모니터링, 진단 및 문제 해결

이 가이드에서는 Azure 스토리지 분석, Azure Storage 클라이언트 라이브러리의 클라이언트 쪽 로깅 및 기타 타사 도구와 같은 기능을 사용하여 Azure Storage 관련 문제를 식별, 진단 및 해결하는 방법을 보여 줍니다.

이 가이드의 기본 대상은 Azure Storage 서비스를 사용하는 온라인 서비스의 개발자 및 이러한 온라인 서비스를 관리하는 IT 전문가입니다. 이 가이드의 목표는 다음과 같습니다.

• Azure Storage 계정의 상태와 성능을 유지 관리하는 데 도움이 되는 정보 제공
• 애플리케이션의 문제가 Azure Storage와 관련이 있는지 여부를 결정하는 데 필요한 프로세스 및 도구 제공
• Azure Storage 관련 문제 해결을 위한 실행 가능 지침 제공

개요

클라우드 환경에서 호스트된 분산 애플리케이션의 문제를 진단하고 해결하는 과정이 기존 환경보다 복잡할 수 있습니다. 애플리케이션은 PaaS 또는 IaaS 인프라, 온-프레미스, 모바일 디바이스 또는 이들 중 일부가 조합된 환경에 배포될 수 있습니다. 일반적으로 애플리케이션의 네트워크 트래픽은 공용 및 프라이빗 네트워크를 트래버스할 수 있으며, 애플리케이션은 관계형 및 문서 데이터베이스와 같은 다른 데이터 저장소 외에도 Microsoft Azure Storage 테이블, Blob, 큐 또는 파일과 같은 여러 스토리지 기술을 사용할 수 있습니다.

이러한 애플리케이션을 성공적으로 관리하려면 애플리케이션을 사전에 모니터링하고 해당 애플리케이션의 모든 측면과 종속 기술을 진단하고 문제를 해결하는 방법을 이해해야 합니다. Azure Storage 서비스의 사용자는 애플리케이션에서 사용하는 Storage 서비스를 지속적으로 모니터링하여 예기치 않은 동작 변경(예: 평소보다 느린 응답 시간)을 모니터링하고 로깅을 사용하여 더 자세한 데이터를 수집하고 문제를 심층 분석해야 합니다. 모니터링 및 로깅에서 얻은 진단 정보는 애플리케이션에서 발생한 문제의 근본 원인을 확인하는 데 도움이 됩니다. 그러면 문제를 해결하고 해당 문제를 완화하기 위한 적절한 단계를 결정할 수 있습니다. Azure Storage는 핵심 Azure 서비스이며 고객이 Azure 인프라에 배포하는 대부분의 솔루션에서 중요한 부분을 차지합니다. Azure Storage에는 클라우드 기반 애플리케이션의 스토리지 문제 모니터링, 진단 및 해결 과정을 간소화하는 기능이 포함되어 있습니다.

이 가이드의 구성 방식

스토리지 서비스 모니터링 섹션에서는 Azure 스토리지 분석 메트릭(스토리지 메트릭)을 사용하여 Azure Storage 서비스의 상태 및 성능을 모니터링하는 방법을 설명합니다.

스토리지 문제 진단 섹션에서는 Azure 스토리지 분석 로깅(스토리지 로깅)을 사용하여 문제를 진단하는 방법을 설명합니다. 또한 .NET용 Storage 클라이언트 라이브러리 또는 Java용 Azure SDK와 같은 클라이언트 라이브러리 중 하나의 기능을 사용하여 클라이언트 쪽 로깅을 사용하도록 설정하는 방법을 설명합니다.

엔드 투 엔드 추적 섹션에서는 다양한 로그 파일 및 메트릭 데이터에 포함된 정보의 상관 관계를 지정하는 방법을 설명합니다.

문제 해결 지침 섹션에서는 발생할 수 있는 일반적인 스토리지 관련 문제 중 일부에 대한 문제 해결 지침을 제공합니다.

부록 섹션에는 네트워크 패킷 데이터를 분석하기 위한 Wireshark 및 Netmon과 같은 다른 도구와 HTTP/HTTPS 메시지를 분석하기 위한 Fiddler와 같은 다른 도구를 사용하는 방법에 대한 정보가 포함되어 있습니다.

스토리지 서비스 모니터링

Windows 성능 모니터링에 대해 잘 알고 있는 경우 Storage 메트릭은 Windows 성능 모니터 카운터의 Azure Storage 버전이라고 생각하면 됩니다. 스토리지 메트릭에서는 서비스 가용성, 서비스에 대한 총 요청 수 또는 서비스에 대한 성공적인 요청의 비율과 같은 포괄적인 메트릭 집합(Windows 성능 모니터 용어의 카운터)을 찾을 수 있습니다. 사용 가능한 메트릭의 전체 목록은 스토리지 분석 메트릭 테이블 스키마를 참조하세요. 스토리지 서비스가 메트릭을 수집 및 집계하는 간격(1시간마다/1분마다)을 지정할 수 있습니다. 메트릭을 사용하도록 설정하고 스토리지 계정을 모니터링하는 방법에 대한 자세한 내용은 스토리지 메트릭 설정 및 메트릭 데이터 보기를 참조하세요.

Azure Portal에 표시할 시간 메트릭을 선택하고 시간 메트릭이 특정 임계값을 초과할 때마다 관리자에게 전자 메일로 알리는 규칙을 구성할 수 있습니다. 자세한 내용은 경고 알림 받기를 참조하세요.

스토리지용 Azure Monitor(미리 보기)를 검토하는 것이 좋습니다. 이는 Azure Monitor의 기능으로, Azure Storage 서비스 성능, 용량, 가용성에 대한 통합 보기를 제공하여 Azure Storage 계정의 포괄적인 모니터링을 제공합니다. 사용 설정이나 구성이 전혀 필요하지 않으며 미리 정의된 대화형 차트 및 포함된 기타 시각화에서 이러한 메트릭을 즉시 볼 수 있습니다.

스토리지 서비스는 메트릭을 수집하기 위해 최선을 다하지만 모든 스토리지 작업을 기록하지는 않을 수 있습니다.

Azure Portal에서 스토리지 계정에 대해 가용성, 총 요청 수, 평균 대기 시간 수 등의 메트릭을 확인할 수 있습니다. 알림 규칙도 설정되어 가용성이 특정 수준 아래로 떨어지면 관리자에게 경고를 보냅니다. 이 데이터를 볼 때 조사를 위해 가능한 한 가지 영역은 테이블 서비스 성공률이 100% 미만이라는 것입니다(자세한 내용은 메트릭에 낮은 PercentSuccess 또는 분석 로그 항목에 ClientOtherErrors 섹션의 트랜잭션 상태가 있는 작업이 있음을 보여 줍니다.)

Azure 애플리케이션을 지속적으로 모니터링한 후 다음을 수행하여 애플리케이션이 정상 상태이며 성능이 적절한 수준인지를 확인해야 합니다.

• 현재 데이터를 비교하고 Azure Storage 및 애플리케이션의 동작에서 중요한 변경 내용을 식별할 수 있는 애플리케이션에 대한 몇 가지 기준 메트릭을 설정합니다. 기준 메트릭의 값은 대부분의 경우 애플리케이션별로 지정되며, 애플리케이션을 성능 테스트할 때 설정해야 합니다.
• 분 메트릭을 기록하고 이를 사용하여 오류 수 또는 요청 속도 급증과 같은 예기치 않은 오류 및 변칙을 적극적으로 모니터링합니다.
• 시간 메트릭을 기록한 다음 평균 오류 수와 요청 속도 등의 평균 값을 모니터링하는 데 사용합니다.
• 스토리지 문제 진단 섹션의 뒷부분에서 설명한 대로 진단 도구를 사용하여 잠재적인 문제 조사

다음 그림의 차트에는 시간 메트릭의 평균을 표시함으로써 활동 급증이 숨겨지는 방식이 표시되어 있습니다. 시간 메트릭에는 요청 속도가 안정적인 것으로 표시되지만 분 메트릭에는 실제로 발생하는 요청 수의 증감이 표시됩니다.

이 섹션의 나머지 부분에서는 모니터링해야 하는 메트릭과 그 이유에 대해 설명합니다.

서비스 상태 모니터링

Azure Portal을 사용하여 전 세계 모든 Azure 지역의 Storage 서비스와 기타 Azure 서비스 상태를 확인할 수 있습니다. 모니터링을 사용하면 컨트롤 외부의 문제가 애플리케이션에 사용하는 지역의 Storage 서비스에 영향을 미치는지 즉시 확인할 수 있습니다.

Azure Portal에서는 여러 Azure 서비스에 영향을 주는 문제에 대한 알림도 제공합니다.

용량 모니터링

일반적으로는 저장되는 데이터 중 Blob이 가장 큰 비율을 차지하므로 Storage 메트릭은 Blob service의 용량 메트릭만을 저장합니다. 이 문서 작성 당시에는 Storage 메트릭을 사용하여 테이블과 큐의 용량을 모니터링할 수 없었습니다. Blob 서비스에 대한 모니터링을 $MetricsCapacityBlob 사용하도록 설정한 경우 테이블에서 이 데이터를 찾을 수 있습니다. 스토리지 메트릭은 하루에 한 번 이 데이터를 기록하며, 이 값을 RowKey 사용하여 행에 사용자 데이터(값) 또는 분석 데이터(값dataanalytics)와 관련된 엔터티가 포함되어 있는지 확인할 수 있습니다. 저장된 각 엔터티에는 사용된 스토리지 양(Capacity 바이트 단위)과 스토리지 계정에서 사용 중인 컨테이너(ContainerCount) 및 Blob(ObjectCount)의 현재 수에 대한 정보가 포함됩니다. 테이블에 저장된 $MetricsCapacityBlob 용량 메트릭에 대한 자세한 내용은 스토리지 분석 메트릭 테이블 스키마를 참조하세요.

Blob과 같은 다양한 스토리지 개체의 크기를 예측하려면 Azure Storage 청구 이해 블로그 게시물 인 대역폭, 트랜잭션 및 용량을 참조하세요.

가용성 모니터링

매시간 또는 분 메트릭 테이블$MetricsHourPrimaryTransactionsTable$MetricsCapacityBlob$MetricsHourPrimaryTransactionsBlob$MetricsMinutePrimaryTransactionsQueue$MetricsHourPrimaryTransactionsQueue$MetricsMinutePrimaryTransactionsTable$MetricsMinutePrimaryTransactionsBlob의 열 값을 Availability 모니터링하여 스토리지 계정의 스토리지 서비스 가용성을 모니터링해야 합니다. 열에는 Availability 서비스 또는 행이 나타내는 API 작업의 가용성을 나타내는 백분율 값이 포함되어 있습니다( RowKey 행에 서비스 전체 또는 특정 API 작업에 대한 메트릭이 포함되어 있는지 표시).

값이 100%보다 작으면 일부 스토리지 요청이 실패함을 나타냅니다. ServerTimeoutError와 같이 오류 유형이 다른 요청 수를 표시하는 메트릭 데이터의 다른 열을 검사하여 실패하는 이유를 확인할 수 있습니다. 서비스가 더 나은 부하 분산 요청으로 파티션을 이동하는 동안 일시적인 서버 시간 제한과 같은 이유로 일시적으로 100% 미만으로 떨어질 것으로 예상됩니다 Availability . 클라이언트 애플리케이션의 재시도 논리는 이러한 일시적인 조건을 처리해야 합니다. 기록된 작업 및 상태 메시지에 스토리지 분석 문서에는 스토리지 메트릭이 계산에 Availability 포함하는 트랜잭션 유형이 나열되어 있습니다.

Azure Portal에서 서비스에 대해 지정한 임계값 아래로 떨어지는 경우 Availability 알림에 경고 규칙을 추가할 수 있습니다.

이 가이드의 문제 해결 지침 섹션에서는 가용성과 관련된 몇 가지 일반적인 스토리지 서비스 문제에 대해 설명합니다.

성능 모니터링

스토리지 서비스의 성능을 모니터링하려면 시간 및 분 메트릭 테이블에서 다음 메트릭을 사용할 수 있습니다.

• 열의 AverageE2ELatency AverageServerLatency 값은 스토리지 서비스 또는 API 작업 유형이 요청을 처리하는 데 걸리는 평균 시간을 보여 줍니다. AverageE2ELatency 는 요청을 읽고 응답을 보내는 데 걸린 시간과 요청을 처리하는 데 걸린 시간(따라서 요청이 스토리지 서비스에 도달하면 네트워크 대기 시간 포함)을 포함하는 엔드 투 엔드 대기 시간의 측정값입니다. AverageServerLatency 는 처리 시간의 측정값이므로 클라이언트와의 통신과 관련된 모든 네트워크 대기 시간을 제외합니다. 이 두 값 간에 큰 차이가 있을 수 있는 이유에 대한 설명은 이 가이드의 뒷부분에 있는 높은 AverageE2ELatency 및 낮은 AverageServerLatency 섹션을 보여 줍니다.
• 열의 TotalEgress 값 TotalIngress 은 스토리지 서비스 또는 특정 API 작업 유형을 통해 들어오고 나가는 총 데이터 양(바이트)을 보여 줍니다.
• 열의 TotalRequests 값은 API 작업의 스토리지 서비스가 수신하는 총 요청 수를 보여 줍니다. TotalRequests 는 스토리지 서비스가 수신하는 총 요청 수입니다.

일반적으로 이러한 값의 예기치 않은 변경 내용을 모니터링합니다. 이는 조사가 필요한 문제가 있음을 나타냅니다.

Azure Portal에서 경고 규칙을 추가하여 이 서비스에 대한 성능 메트릭이 지정한 임계값 아래로 떨어지거나 초과하는 경우 이를 알릴 수 있습니다.

이 가이드의 문제 해결 지침 섹션에서는 성능과 관련된 몇 가지 일반적인 스토리지 서비스 문제에 대해 설명합니다.

스토리지 문제 진단

다음과 같은 여러 가지 방법으로 애플리케이션의 문제를 파악할 수 있습니다.

• 애플리케이션 작동이 중단되거나 중지되는 주요 오류입니다.
• 스토리지 서비스 모니터링 이전 섹션에 설명된 대로 모니터링하는 메트릭의 기준 값에서 중요한 변경 내용입니다.
• 일부 특정 작업이 정상적으로 완료되지 않거나 일부 기능이 작동하지 않는다는 애플리케이션 사용자의 보고
• 애플리케이션 내에서 생성되어 로그 파일이나 일부 기타 알림 방법을 통해 표시되는 오류

일반적으로 Azure Storage 서비스 관련 문제는 크게 다음의 네 가지 범주 중 하나에 속합니다.

• 애플리케이션에는 사용자가 보고하거나 성능 메트릭의 변경으로 인해 표시되는 성능 문제가 있습니다.
• 하나 이상의 지역에서 Azure Storage 인프라에 문제가 있습니다.
• 애플리케이션에서 사용자가 보고하거나 모니터링하는 오류 수 메트릭 중 하나가 증가하여 표시되는 오류가 발생합니다.
• 개발 및 테스트 중에 로컬 스토리지 에뮬레이터를 사용할 수 있습니다. 스토리지 에뮬레이터 사용과 관련된 몇 가지 문제가 발생할 수 있습니다.

다음 섹션에서는 이러한 각 4개 범주의 문제를 진단하고 해결하려면 따라야 하는 단계를 대략적으로 설명합니다. 이 가이드의 뒷부분에 있는 문제 해결 지침 섹션에서는 발생할 수 있는 몇 가지 일반적인 문제에 대해 자세히 설명합니다.

서비스 상태 문제

서비스 상태 문제는 대개 직접 해결할 수가 없습니다. Azure Portal은 스토리지 서비스를 포함하여 Azure 서비스의 지속적인 문제에 대한 정보를 제공합니다. 스토리지 계정을 만들 때 Read-Access Geo Redundant Storage를 선택한 경우, 기본 위치에서 데이터를 사용할 수 없게 되면 애플리케이션이 보조 위치의 읽기 전용 복사본으로 임시 전환될 수 있습니다. 보조 스토리지에서 읽으려면 애플리케이션이 기본 및 보조 스토리지 위치 사용 간에 전환할 수 있어야 하며 읽기 전용 데이터로 축소된 기능 모드에서 작업할 수 있어야 합니다. Azure Storage 클라이언트 라이브러리에서는 기본 스토리지에서 읽기가 실패하는 경우 보조 스토리지에서 읽을 수 있는 다시 시도 정책을 정의할 수 있습니다. 또한 애플리케이션은 보조 위치의 데이터가 기본 위치와 일치함을 인식할 수 있어야 합니다. 자세한 내용은 Azure Storage 중복성 옵션 및 읽기 액세스 지역 중복 스토리지 블로그 게시물을 참조하세요.

성능 문제

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

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

이 가이드의 뒷부분에 있는 문제 해결 지침 섹션에서는 발생할 수 있는 몇 가지 일반적인 성능 관련 문제에 대한 자세한 정보를 제공합니다.

오류 진단

애플리케이션 사용자가 클라이언트 애플리케이션에서 보고한 오류에 대해 알려오는 경우가 있습니다. 또한 스토리지 메트릭은 NetworkError, ClientTimeoutError 또는 AuthorizationError와 같은 스토리지 서비스의 다양한 오류 유형 수를 기록합니다. Storage 메트릭은 서로 다른 오류 유형의 수만 기록하지만 서버 쪽, 클라이언트 쪽 및 네트워크 로그를 검사하여 개별 요청에 대한 추가 정보를 얻을 수도 있습니다. 일반적으로는 스토리지 서비스에서 반환하는 HTTP 상태 코드를 통해 요청이 실패한 이유를 파악할 수 있습니다.

다음 리소스에서 스토리지 관련 상태 및 오류 코드를 파악할 수 있습니다.

• 일반적인 REST API 오류 코드
• Blob Service 오류 코드
• 큐 서비스 오류 코드
• Table Service 오류 코드
• 파일 서비스 오류 코드

스토리지 에뮬레이터 문제

Azure SDK에는 개발 워크스테이션에서 실행할 수 있는 스토리지 에뮬레이터가 포함되어 있습니다. 이 에뮬레이터는 대부분의 Azure Storage 서비스 동작을 시뮬레이션하며 개발 및 테스트 중에 유용하므로 Azure 구독 및 Azure Storage 계정 없이도 Azure Storage 서비스를 사용하는 애플리케이션을 실행할 수 있습니다.

이 가이드의 문제 해결 지침 섹션에서는 스토리지 에뮬레이터를 사용하여 발생하는 몇 가지 일반적인 문제에 대해 설명합니다.

스토리지 로깅 도구

스토리지 로깅은 Azure Storage 계정의 스토리지 요청에 대한 서버 쪽 로깅 기능을 제공합니다. 서버 쪽 로깅을 사용하도록 설정하고 로그 데이터에 액세스하는 방법에 대한 자세한 내용은 스토리지 로깅 사용 및 로그 데이터 액세스를 참조하세요.

.NET용 Storage 클라이언트 라이브러리에서는 애플리케이션이 수행하는 스토리지 작업과 관련된 클라이언트 쪽 로그 데이터를 수집할 수 있습니다. 자세한 내용은 .NET Storage 클라이언트 라이브러리를 사용한 클라이언트 쪽 로깅을 참조하세요.

네트워크 로깅 도구 사용

클라이언트와 서버 간의 트래픽을 캡처하여 클라이언트와 서버가 교환하는 데이터 및 기본 네트워크 상태에 대한 상세 정보를 제공할 수 있습니다. 다음과 같은 유용한 네트워크 로깅 도구를 사용할 수 있습니다.

• Fiddler 는 HTTP/HTTPS 요청 및 응답 메시지의 헤더 및 페이로드 데이터를 검사하는 데 사용할 수 있는 무료 웹 디버깅 프록시입니다. 자세한 내용은 부록1: Fiddler를 사용하여 HTTP 및 HTTPS 트래픽 캡처를 참조하세요.
• Microsoft 네트워크 모니터(Netmon) 및 Wireshark는 광범위한 네트워크 프로토콜에 대한 상세 패킷 정보를 확인하는 데 사용할 수 있는 무료 네트워크 프로토콜 분석기입니다. Wireshark에 대한 자세한 내용은 부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처를 참조하세요.
• 기본 연결 테스트를 수행하여 클라이언트 컴퓨터가 네트워크를 통해 Azure Storage 서비스에 연결할 수 있는지를 확인하려는 경우 클라이언트에서 표준 ping 도구를 통해서는 이 작업을 수행할 수 없습니다. 그러나 tcping 도구를 사용하면 연결을 확인할 수 있습니다.

대부분의 경우 스토리지 로깅 및 Storage 클라이언트 라이브러리의 로그 데이터로 문제를 충분히 진단할 수 있습니다. 그러나 이러한 네트워크 로깅 도구가 제공할 수 있는 상세 정보가 필요한 경우도 있습니다. 예를 들어 Fiddler를 통해 HTTP 및 HTTPS 메시지를 확인하면 스토리지 서비스가 보내고 받는 헤더 및 페이로드 데이터를 볼 수 있으므로 클라이언트 애플리케이션이 스토리지 작업을 다시 시도하는 방법을 검사할 수 있습니다. Wireshark 등의 프로토콜 분석기는 패킷 수준에서 작동하여 TCP 데이터를 확인할 수 있도록 합니다. 따라서 패킷 손실 및 연결 끊김 문제를 해결할 수 있습니다.

엔드투엔드 추적

다양한 로그 파일을 사용하는 엔드투엔드 추적은 잠재적 문제를 조사하는 데 유용한 기술입니다. 메트릭 데이터의 날짜/시간 정보를 사용하여 로그 파일에서 문제를 해결하는 데 도움이 되는 자세한 정보를 확인할 위치를 나타낼 수 있습니다.

로그 데이터 상관 관계 설정

클라이언트 애플리케이션, 네트워크 추적 및 서버 쪽 스토리지 로깅에서 로그를 볼 때는 여러 로그 파일 간에 요청을 상호 연결할 수 있어야 합니다. 로그 파일에는 상관 관계 식별자로 활용할 수 있는 여러 필드가 포함되어 있습니다. 다른 로그의 항목 간 상관 관계를 설정하는 데 사용할 수 있는 가장 유용한 필드는 클라이언트 요청 ID입니다. 그러나 경우에 따라 서버 요청 ID 또는 타임스탬프를 사용하는 것이 유용할 수 있습니다. 다음 섹션에서는 이러한 옵션에 대해 자세히 설명합니다.

클라이언트 요청 ID

스토리지 클라이언트 라이브러리는 모든 요청에 대해 고유한 클라이언트 요청 ID를 자동으로 생성합니다.

• 스토리지 클라이언트 라이브러리가 만드는 클라이언트 쪽 로그에서 클라이언트 요청 ID는 Client Request ID 요청과 관련된 모든 로그 항목의 필드에 표시됩니다.
• Fiddler에서 캡처한 것과 같은 네트워크 추적에서 클라이언트 요청 ID는 요청 메시지에 HTTP 헤더 값으로 x-ms-client-request-id 표시됩니다.
• 서버 쪽 스토리지 로깅 로그에서 클라이언트 요청 ID는 클라이언트 요청 ID 열에 표시됩니다.

서버 요청 ID

스토리지 서비스는 서버 요청 ID를 자동으로 생성합니다.

• 서버 쪽 스토리지 로깅 로그에서 서버 요청 ID가 열에 Request ID header 나타납니다.
• Fiddler에서 캡처한 것과 같은 네트워크 추적에서 서버 요청 ID는 응답 메시지에 HTTP 헤더 값으로 x-ms-request-id 표시됩니다.
• 스토리지 클라이언트 라이브러리가 만드는 클라이언트 쪽 로그에서 서버 요청 ID는 서버 응답의 세부 정보를 보여 주는 로그 항목의 열에 나타납니다 Operation Text .

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();
    }
}

//Parse the connection string for the storage account.
const string ConnectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

// Create an Operation Context that includes custom ClientRequestId string based on constants defined within the application along with a Guid.
OperationContext oc = new OperationContext();
oc.ClientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

try
{
    CloudBlobContainer container = blobClient.GetContainerReference("democontainer");
    ICloudBlob blob = container.GetBlobReferenceFromServer("testImage.jpg", null, null, oc);  
    var downloadToPath = string.Format("./{0}", blob.Name);
    using (var fs = File.OpenWrite(downloadToPath))
    {
        blob.DownloadToStream(fs, null, null, oc);
        Console.WriteLine("\t Blob downloaded to file: {0}", downloadToPath);
    }
}
catch (StorageException storageException)
{
    Console.WriteLine("Storage exception {0} occurred", storageException.Message);
    // Multiple results may exist due to client side retry logic - each retried operation will have a unique ServiceRequestId
    foreach (var result in oc.RequestResults)
    {
            Console.WriteLine("HttpStatus: {0}, ServiceRequestId {1}", result.HttpStatusCode, result.ServiceRequestID);
    }
}

타임스탬프

타임스탬프를 사용하여 관련 로그 항목을 찾을 수는 있지만 이 경우 클라이언트와 서버 간의 클럭 오차 가능성에 주의해야 합니다. 일치하는 서버 측 항목을 클라이언트의 타임 스탬프를 기반으로 15분 더 검색하거나 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보다 크게 높은 경우의 예를 보여 줍니다.

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

클라이언트 성능 문제 조사

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

테이블 및 큐 서비스의 경우 Nagle 알고리즘은 AverageServerLatency에 비해 AverageE2ELatency가 높을 수도 있습니다. 자세한 내용은 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;

var storageAccount = CloudStorageAccount.Parse(connStr);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(storageAccount.QueueEndpoint);
queueServicePoint.UseNagleAlgorithm = false;

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

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

일반적으로 네트워크에서 발생하는 긴 엔드투엔드 대기 시간의 원인은 일시적인 상태 때문입니다. Wireshark와 같은 도구를 사용하여 삭제된 패킷과 같은 일시적 및 영구적 네트워크 문제를 모두 조사할 수 있습니다.

Wireshark를 사용하여 네트워크 문제를 해결하는 방법에 대한 자세한 내용은 부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처를 참조하세요.

메트릭에서 AverageE2ELatency 및 AverageServerLatency는 낮게 표시되는데 클라이언트의 대기 시간이 길어짐

이 시나리오에서는 스토리지 요청이 스토리지 서비스에 도착할 때까지의 대기 시간이 길어지는 경우로 인한 가능성이 가장 높습니다. 클라이언트의 요청이 Blob 서비스에 정상적인 속도로 도착하지 않는 원인을 조사해야 합니다.

사용 가능한 연결 또는 스레드 수가 제한되는 경우 클라이언트의 요청 전송이 지연될 수 있습니다.

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

• Storage 분석 로그를 검사합니다. 여러 번의 재시도가 발생하는 경우 클라이언트 요청 ID가 동일하지만 서버 요청 ID가 다른 여러 작업이 표시됩니다.
• 클라이언트 로그를 검사합니다. 자세한 정보 로깅은 다시 시도가 발생된 것을 표시됩니다.
• 코드를 디버그하고 요청과 연결된 개체의 OperationContext 속성을 확인합니다. 작업을 다시 시도하면 RequestResults 속성에 여러 개의 고유한 서버 요청 ID가 포함됩니다. 또한 각 요청에 대한 시작 및 종료 시간을 확인할 수 있습니다. 자세한 내용은 서버 요청 ID섹션의 코드 샘플을 참조하세요.

클라이언트에 문제가 없으면 패킷 손실 등의 네트워크 문제 가능성을 조사해야 합니다. Wireshark와 같은 도구를 사용하여 네트워크 문제를 조사할 수 있습니다.

Wireshark를 사용하여 네트워크 문제를 해결하는 방법에 대한 자세한 내용은 부록 2: Wireshark를 사용하여 네트워크 트래픽 캡처를 참조하세요.

메트릭에서 AverageServerLatency가 높게 표시됨

Blob 다운로드 요청에 대해 AverageServerLatency가 높게 표시되는 경우 Storage 로깅 로그를 사용하여 같은 Blob 또는 Blob 세트에 대해 요청이 반복되는지 여부를 확인해야 합니다. Blob 업로드 요청의 경우 클라이언트가 사용하는 블록 크기를 조사해야 합니다(예: 읽기가 64K 청크 미만인 경우가 아니면 크기가 64K 미만인 블록은 오버헤드가 발생할 수 있습니다). 여러 클라이언트가 동일한 Blob에 블록을 병렬로 업로드하는 경우. 또한 초당 확장성 목표를 초과하는 요청 수의 급증에 대한 분당 메트릭을 확인해야 합니다. 자세한 내용은 PercentTimeoutError의 증가를 보여 주는 메트릭을 참조 하세요.

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

테이블이나 쿼리의 디자인이 잘못되어 검사 작업이 수행되거나 추가/앞에 추가 방지 패턴을 따르는 경우에도 AverageServerLatency 값이 높아지는 증상이 발생할 수 있습니다. 자세한 내용은 메트릭이 PercentThrottlingError의 증가를 보여 주는 것을 참조 하세요.

큐에서 메시지 배달 중에 예기치 않은 대기 시간이 발생함

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

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

메트릭에서 PercentThrottlingError가 증가하는 것으로 표시됨

스토리지 서비스의 확장성 목표를 초과하면 제한 오류가 발생합니다. 스토리지 서비스는 단일 클라이언트나 테넌트만이 서비스를 사용하는 현상을 방지하기 위해 제한 오류를 발생시킵니다. 스토리지 계정의 확장성 목표와 스토리지 계정 내 파티션의 성능 목표에 대한 자세한 내용은 표준 스토리지 계정의 확장성 및 성능 목표를 참조하세요.

PercentThrottlingError 메트릭에 제한 오류로 실패한 요청의 백분율이 증가하는 경우 다음 두 가지 시나리오 중 하나를 조사해야 합니다.

• 일시적인 PercentThrottlingError 증가
• 영구적인 PercentThrottlingError 증가

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

일시적인 PercentThrottlingError 증가

애플리케이션에 대한 높은 작업 기간과 일치하는 PercentThrottlingError 값이 급증하는 경우 클라이언트에서 다시 시도하기 위한 지수(선형이 아닌) 백오프 전략을 구현할 수 있습니다. 백오프 재시도는 파티션의 즉각적인 부하를 줄이고 애플리케이션이 트래픽 급증을 원활하게 하는 데 도움이 됩니다. 스토리지 클라이언트 라이브러리를 사용하여 다시 시도 정책을 구현하는 방법에 대한 자세한 내용은 Microsoft.Azure.Storage.RetryPolicies 네임스페이스를 참조하세요.

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 키가 원인인 경우 서버 쪽 스토리지 로깅 로그 데이터에 항목이 표시되지 않습니다. 아래 표에는 이 문제가 발생함을 나타내는 Storage 클라이언트 라이브러리에서 생성된 클라이언트 쪽 로그의 샘플이 나와 있습니다.

이 시나리오에서는 클라이언트가 서버에 토큰을 보내기 전에 SAS 토큰이 만료되는 이유를 조사해야 합니다.

• 일반적으로 클라이언트에서 즉시 사용할 SAS를 만들 때 시작 시간을 설정해서는 안 됩니다. 현재 시간을 사용하여 SAS를 생성하는 호스트와 스토리지 서비스 간에 약간의 클록 차이가 있는 경우 스토리지 서비스가 아직 유효하지 않은 SAS를 수신할 수 있습니다.
• SAS에서 매우 짧은 만료 시간을 설정하지 마세요. 다시 말하지만, SAS를 생성하는 호스트와 스토리지 서비스 간의 작은 클록 차이로 인해 SAS가 예상보다 일찍 만료될 수 있습니다.
• SAS 키의 버전 매개 변수(예: sv=2015-04-05)가 사용 중인 Storage 클라이언트 라이브러리 버전과 일치하나요? 항상 최신 버전의 Storage 클라이언트 라이브러리를 사용하는 것이 좋습니다.
• 스토리지 액세스 키를 다시 생성하면 기존 SAS 토큰이 무효화될 수 있습니다. 이 문제는 클라이언트 애플리케이션의 캐시에 대한 만료 시간이 긴 SAS 토큰을 생성하는 경우 발생할 수 있습니다.

스토리지 클라이언트 라이브러리를 사용하여 SAS 토큰을 생성하는 경우에는 유효한 토큰을 쉽게 작성할 수 있습니다. 그러나 스토리지 REST API를 사용 중이며 수동으로 SAS 토큰을 생성하는 경우에는 공유 액세스 서명을 사용하여 액세스 위임을 참조하세요.

클라이언트에 HTTP 404(찾을 수 없음) 메시지가 표시됨

클라이언트 애플리케이션이 서버에서 HTTP 404(찾을 수 없음) 메시지를 수신하는 경우 클라이언트가 사용하려는 엔터티, 테이블, Blob, 컨테이너, 큐 등의 개체가 스토리지 서비스에 없는 것입니다. 이러한 현상은 다음과 같은 여러 가지 이유로 인해 발생합니다.

• 클라이언트 또는 다른 프로세스가 이전에 개체를 삭제함
• SAS(공유 액세스 서명) 권한 부여 문제입니다.
• 클라이언트 쪽 JavaScript 코드에 개체 액세스 권한이 없습니다.
• 네트워크 오류입니다.

클라이언트 또는 다른 프로세스가 이전에 개체를 삭제함

클라이언트가 스토리지 서비스에서 데이터를 읽거나 업데이트하거나 삭제하려는 시나리오에서는 일반적으로 스토리지 서비스에서 해당 개체를 삭제한 이전 작업을 서버 쪽 로그에서 쉽게 식별할 수 있습니다. 로그 데이터에는 다른 사용자나 프로세스가 개체를 삭제한 것이 표시되는 경우가 많습니다. 서버 쪽 스토리지 로깅 로그에서 operation-type 및 requested-object-key 열에는 클라이언트가 개체를 삭제한 시기가 표시됩니다.

클라이언트가 개체를 삽입하려고 하는 시나리오에서는 클라이언트가 새 개체를 만드는 경우 HTTP 404(찾을 수 없음) 응답이 발생하는 이유를 즉시 명확하지 않을 수 있습니다. 그러나 클라이언트가 Blob을 만드는 경우 Blob 컨테이너를 찾을 수 있어야 합니다. 클라이언트가 메시지를 만드는 경우 큐를 찾을 수 있어야 합니다. 클라이언트가 행을 추가하는 경우 테이블을 찾을 수 있어야 합니다.

Storage 클라이언트 라이브러리의 클라이언트 쪽 로그를 사용하여 클라이언트가 Storage 서비스에 특정 요청을 보낸 시기를 자세하게 확인할 수 있습니다.

스토리지 클라이언트 라이브러리에서 생성한 다음 클라이언트 쪽 로그에는 클라이언트가 작성 중인 Blob에 대한 컨테이너를 찾을 수 없는 문제가 나와 있습니다. 이 로그에는 다음 스토리지 작업에 대한 세부 정보가 포함됩니다.

로그 항목:

이 예제에서 로그는 클라이언트가 메서드의 요청 CreateIfNotExists (요청 ID e2d06d78...)과 메서드의 요청 UploadFromStream (de8b1c3c-...)을 인터리빙하고 있음을 보여 줍니다. 이 인터리빙은 클라이언트 애플리케이션이 이러한 메서드를 비동기적으로 호출하기 때문에 발생합니다. 클라이언트가 컨테이너의 Blob에 데이터 업로드를 시도하기 전에 해당 컨테이너를 만들도록 클라이언트에서 비동기 코드를 수정합니다. 모든 컨테이너를 미리 만드는 것이 가장 좋습니다.

SAS(공유 액세스 서명) 권한 부여 문제

클라이언트 애플리케이션이 작업에 필요한 권한을 포함하지 않는 SAS 키를 사용하려고 하면 스토리지 서비스는 HTTP 404(찾을 수 없음) 메시지를 클라이언트에 반환합니다. 동시에 메트릭에 0이 아닌 값 SASAuthorizationError 도 표시됩니다.

아래 표에는 스토리지 로깅 로그 파일의 샘플 서버 쪽 로그 메시지가 나와 있습니다.

클라이언트 애플리케이션이 권한이 부여되지 않은 작업을 수행하려는 이유를 조사합니다.

클라이언트 쪽 JavaScript 코드에 개체 액세스 권한이 없습니다.

JavaScript 클라이언트를 사용 중인데 스토리지 서비스에서 HTTP 404 메시지를 반환하는 경우에는 브라우저에서 다음 JavaScript 오류를 확인해야 합니다.

SEC7120: http://localhost:56309 Access-Control-Allow-Origin 헤더에서 원본을 찾을 수 없습니다.
SCRIPT7002: XMLHttpRequest: 네트워크 오류 0x80070005 액세스가 거부되었습니다.

이러한 오류가 발생하는 이유는 웹 페이지가 생성된 도메인과 다른 도메인에서 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);

CloudBlobClient client = new CloudBlobClient(blobEndpoint, new StorageCredentials(accountName, accountKey));
// Set the service properties.
ServiceProperties sp = client.GetServiceProperties();
sp.DefaultServiceVersion = "2013-08-15";
CorsRule cr = new CorsRule();
cr.AllowedHeaders.Add("*");
cr.AllowedMethods = CorsHttpMethods.Get | CorsHttpMethods.Put;
cr.AllowedOrigins.Add("http://www.contoso.com");
cr.ExposedHeaders.Add("x-ms-*");
cr.MaxAgeInSeconds = 5;
sp.Cors.CorsRules.Clear();
sp.Cors.CorsRules.Add(cr);
client.SetServiceProperties(sp);

네트워크 오류

네트워크 패킷 손실로 인해 스토리지 서비스가 HTTP 404 메시지를 클라이언트에 반환하는 경우가 있습니다. 예를 들어 클라이언트 애플리케이션이 테이블 서비스에서 엔터티를 삭제하는 경우 클라이언트가 테이블 서비스에서 "HTTP 404(찾을 수 없음)" 상태 메시지를 보고하는 스토리지 예외를 throw하는 것을 볼 수 있습니다. 그런데 Table Storage 서비스에서 테이블을 조사하면 서비스가 요청대로 엔터티를 삭제했음이 확인됩니다.

클라이언트의 예외 세부 정보에는 요청에 대해 테이블 서비스에서 할당한 요청 ID(7e84f12d...)가 포함됩니다. 이 정보를 사용하여 로그 파일의 열에서 검색하여 서버 쪽 스토리지 로그에서 request-id-header 요청 세부 정보를 찾을 수 있습니다. 메트릭을 사용하여 이러한 오류가 발생하는 시기를 파악한 다음 메트릭에서 이 오류를 기록한 시간을 기준으로 로그 파일을 검색할 수도 있습니다. 이 로그 항목에는 "HTTP(404) 클라이언트 기타 오류" 상태 메시지를 반환하며 실패한 삭제 작업이 표시됩니다. 동일한 로그 항목에는 열(813ea74f...)에서 클라이언트가 client-request-id 생성한 요청 ID도 포함됩니다.

또한 서버 쪽 로그에는 동일한 엔터티 및 동일한 클라이언트의 삭제 작업에 대해 동일한 client-request-id 값(813ea74f...)이 있는 다른 항목도 포함됩니다. 이와 같은 성공한 삭제 작업은 실패한 삭제 요청 직전에 수행된 것입니다.

이 시나리오의 가장 큰 원인은 클라이언트가 엔터티에 대한 삭제 요청을 테이블 서비스로 보냈기 때문입니다. 이 요청은 성공했지만 서버에서 승인을 받지 못했습니다(아마도 임시 네트워크 문제로 인해). 그런 다음 클라이언트는 작업을 자동으로 다시 시도(동일한 client-request-id사용)하고 엔터티가 이미 삭제되었으므로 이 재시도에 실패했습니다.

이 문제가 자주 발생하는 경우 클라이언트가 테이블 서비스에서 승인을 받지 못하는 이유를 조사해야 합니다. 문제가 일시적으로 발생하는 경우 "HTTP(404) 찾을 수 없음" 오류를 트래핑하고 클라이언트에서 기록하되 클라이언트가 작업을 계속 진행하도록 허용해야 합니다.

클라이언트에 HTTP 409(충돌) 메시지가 표시됨

다음 표에서는 두 클라이언트 작업에 대한 서버 쪽 로그의 추출을 보여 줍니다 DeleteIfExists . 그 다음에는 CreateIfNotExists 즉시 동일한 Blob 컨테이너 이름을 사용합니다. 각 클라이언트 작업으로 인해 두 개의 요청이 서버로 전송되고, 먼저 GetContainerProperties 컨테이너가 있는지 확인하기 위한 요청과 그 뒤에 또는 CreateContainer 요청이 DeleteContainer 잇습니다.

클라이언트 애플리케이션의 코드는 동일한 이름을 CreateIfNotExists 사용하여 Blob 컨테이너를 삭제한 다음 즉시 다시 만듭니다. 메서드(클라이언트 요청 ID bc881924-...)는 결국 HTTP 409(충돌) 오류로 실패합니다. 클라이언트가 Blob 컨테이너, 테이블 또는 큐를 삭제하는 경우 이름을 다시 사용할 수 있게 되기까지 짧은 기간이 있습니다.

삭제/다시 만들기 패턴이 공통적으로 사용되는 경우 클라이언트 애플리케이션은 새 컨테이너를 만들 때마다 고유한 컨테이너 이름을 사용해야 합니다.

메트릭에 PercentSuccess가 낮게 표시되거나 분석 로그 항목에 트랜잭션 상태가 ClientOtherErrors 상태인 작업이 있음

PercentSuccess 메트릭은 HTTP 상태 코드를 기준으로 성공한 작업 비율을 캡처합니다. 상태 코드가 2XX인 작업은 성공한 것으로 계산되지만 상태 코드가 3XX, 4XX 및 5XX 범위인 작업은 실패한 것으로 계산되고 PercentSuccess 메트릭 값은 낮습니다. 서버 쪽 스토리지 로그 파일에서 이러한 작업은 트랜잭션 상태 ClientOtherErrors로 기록됩니다.

이러한 작업이 성공적으로 완료되었으므로 가용성과 같은 다른 메트릭에는 영향을 주지 않습니다. 정상적으로 실행되지만 작업 실패에 해당하는 HTTP 상태 코드를 표시하는 작업의 몇 가지 예는 다음과 같습니다.

• 예를 들어 ResourceNotFound(찾을 수 없음 404)는 존재하지 않는 Blob에 대한 요청입니다 GET .
• 리소스가 이미 있는 작업과 CreateIfNotExist 같은 ResourceAlreadyExists(충돌 409)입니다.
• 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 메서드 호출을 테스트합니다. 이는 사용 중인 스토리지 에뮬레이터 버전이 사용 중인 스토리지 클라이언트 라이브러리의 버전을 지원하지 않음을 나타냅니다. Storage 클라이언트 라이브러리는 헤더 x-ms-version 를 만드는 모든 요청에 추가합니다. 스토리지 에뮬레이터가 헤더의 값을 x-ms-version 인식하지 못하면 요청을 거부합니다.

스토리지 라이브러리 클라이언트 로그를 사용하여 전송하는 x-ms-version header 값을 볼 수 있습니다. Fiddler를 사용하여 클라이언트 애플리케이션의 요청을 추적하는 경우의 x-ms-version header 값을 확인할 수도 있습니다.

일반적으로는 스토리지 에뮬레이터를 업데이트하지 않고 Storage 클라이언트 라이브러리의 최신 버전을 설치하여 사용하는 경우 이 시나리오가 발생합니다. 최신 버전의 스토리지 에뮬레이터를 설치하거나 개발 및 테스트를 위해 에뮬레이터 대신 클라우드 스토리지를 사용해야 합니다.

스토리지 에뮬레이터를 실행하려면 관리 권한이 필요함

스토리지 에뮬레이터를 실행하면 관리자 자격 증명을 입력하라는 메시지가 표시됩니다. 이러한 메시지는 스토리지 에뮬레이터를 처음 초기화할 때만 표시됩니다. 스토리지 에뮬레이터를 초기화한 후에는 다시 실행하기 위한 관리 권한이 필요하지 않습니다.

자세한 내용은 개발 및 테스트에 Azure Storage 에뮬레이터 사용을 참조하세요. Visual Studio에서 스토리지 에뮬레이터를 초기화할 수도 있으며 이 작업을 위해서도 관리자 권한이 필요합니다.

Azure SDK for .NET 설치 시 문제가 발생함

SDK를 설치하려고 하면 로컬 컴퓨터에 스토리지 에뮬레이터를 설치하는 동안 실패합니다. 이 경우 설치 로그에는 다음 메시지 중 하나가 포함됩니다.

• CAQuietExec: 오류: SQL 인스턴스에 액세스할 수 없습니다.
• CAQuietExec: 오류: 데이터베이스를 만들 수 없습니다.

원인은 기존 LocalDB 설치와 관련된 문제입니다. 스토리지 에뮬레이터는 Azure Storage 서비스를 시뮬레이트할 때 기본적으로 LocalDB를 사용하여 데이터를 영구적으로 저장합니다. SDK를 설치하기 전에 명령 프롬프트 창에서 다음 명령을 실행하여 LocalDB 인스턴스를 다시 설정할 수 있습니다.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

이 delete 명령은 스토리지 에뮬레이터의 이전 설치에서 이전 데이터베이스 파일을 제거합니다.

스토리지 서비스에서 다른 문제가 발생함

이전 문제 해결 섹션에 나와 있지 않은 문제가 스토리지 서비스에서 발생한 경우에는 다음 방식을 통해 문제를 진단하고 해결해야 합니다.

• 메트릭을 확인하여 예상 기준 동작에서 변경 내용이 있는지 확인합니다. 메트릭에서 문제가 일시적인지 영구적인지, 문제가 영향을 미치는 스토리지 작업을 확인할 수 있습니다.
• 메트릭 정보를 사용하면 서버 쪽 로그 데이터에서 발생하는 오류에 대한 보다 자세한 정보를 검색할 수 있습니다. 이 정보는 문제를 해결하는 데 도움이 될 수 있습니다.
• 서버 쪽 로그의 정보가 문제를 성공적으로 해결하는 데 충분하지 않은 경우 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를 설치한 로컬 컴퓨터와 Azure Storage 서비스 간의 트래픽을 캡처하도록 Fiddler를 구성하는 방법의 간략한 연습을 제공합니다.

Fiddler를 시작하면 로컬 컴퓨터에서 HTTP 및 HTTPS 트래픽 캡처가 시작됩니다. 아래에는 Fiddler를 제어하는 몇 가지 유용한 명령이 나와 있습니다.

• 트래픽 캡처를 중지 및 시작하려면 주 메뉴에서 파일로 이동한 다음 트래픽 캡처를 선택하여 캡처를 설정/해제합니다.
• 캡처된 트래픽 데이터를 저장하려면 주 메뉴에서 파일로 이동하여 저장을 선택한 다음 모든 세션을 선택합니다. 이렇게 하면 세션 보관 파일에 트래픽을 저장할 수 있습니다. 나중에 분석을 위해 세션 보관 파일을 다시 로드하거나 Microsoft 지원에 요청된 경우 보낼 수 있습니다.

Fiddler가 캡처하는 트래픽의 양을 제한하려면 필터 탭에서 구성하는 필터를 사용할 수 있습니다. 다음 스크린샷은 스토리지 엔드포인트로 전송된 트래픽만 캡처하는 필터를 contosoemaildist.table.core.windows.net 보여 줍니다.

부록2: Wireshark를 사용하여 네트워크 트래픽 캡처

Wireshark 는 광범위한 네트워크 프로토콜에 대한 상세 패킷 정보를 확인할 수 있는 네트워크 프로토콜 분석기입니다.

다음 절차에서는 Wireshark를 설치한 로컬 컴퓨터에서 Azure Storage 계정의 테이블 서비스로 이동하는 트래픽에 대한 상세 패킷 정보를 캡처하는 방법을 설명합니다.

1. 로컬 컴퓨터에서 Wireshark를 시작합니다.

2. 시작 섹션에서 로컬 네트워크 인터페이스 또는 인터넷에 연결된 인터페이스를 선택합니다.

3. 캡처 옵션을 선택합니다.

4. 캡처 필터 텍스트 상자에 필터를 추가합니다. 예를 들어 host contosoemaildist.table.core.windows.net contosoemaildist 스토리지 계정의 테이블 서비스 엔드포인트에서 전송된 패킷만 캡처하도록 Wireshark를 구성합니다. 캡처 필터의 전체 목록을 확인하세요.

   

5. 시작을 선택합니다. 이제 Wireshark는 로컬 컴퓨터에서 클라이언트 애플리케이션을 사용할 때 테이블 서비스 엔드포인트에서 전송된 모든 패킷을 캡처합니다.

6. 완료되면 주 메뉴에서 캡처>중지를 선택합니다.

7. 캡처된 데이터를 Wireshark 캡처 파일에 저장하려면 주 메뉴에서 파일>저장을 선택합니다.

WireShark의 packetlist 창에는 발생한 모든 오류가 강조 표시됩니다. 전문가 정보 창(전문가 정보 분석>선택)을 사용하여 오류 및 경고 요약을 볼 수도 있습니다.

TCP 데이터를 마우스 오른쪽 단추로 클릭하고 TCP 스트림 확인을 선택하여 애플리케이션 계층에 표시되는 대로 TCP 데이터를 확인할 수도 있습니다. 캡처 필터를 사용하지 않고 덤프를 캡처한 경우 이와 같이 확인하면 유용합니다. 자세한 내용은 Following TCP Streams(TCP 스트림 따라 이동)를 참조하세요.

부록4: Excel을 사용하여 메트릭 및 로그 데이터 보기

다양한 도구를 통해 Azure 테이블 스토리지에서 Storage 메트릭 데이터를 구분된 형식으로 다운로드할 수 있으며, 해당 데이터를 Excel에 로드하여 쉽게 보고 분석할 수 있습니다. Azure Blob Storage의 스토리지 로깅 데이터는 이미 Excel에 로드할 수 있는 구분된 형식으로 되어 있습니다. 그러나 스토리지 분석 로그 형식 및 스토리지 분석 메트릭 테이블 스키마의 정보에 따라 적절한 열 머리글을 추가해야 합니다.

Blob Storage에서 다운로드한 스토리지 로깅 데이터를 Excel로 가져오려면 다음 단계를 수행합니다.

• 데이터 메뉴에서 텍스트에서 선택합니다.
• 보려는 로그 파일을 찾아 가져오기를 선택합니다.
• 텍스트 가져오기 마법사의 1단계에서 구분 기호를 선택합니다.

텍스트 가져오기 마법사의 1단계에서 유일한 구분 기호로 세미콜론을 선택하고 텍스트 한정자로 큰따옴표를 선택합니다. 그런 다음 마침을 선택하고 통합 문서에 데이터를 배치할 위치를 선택합니다.

부록5: Azure DevOps용 Application Insights를 사용한 모니터링

성능 및 가용성 모니터링의 일부분으로 Azure DevOps의 Application Insights 기능을 사용할 수도 있습니다. 이 도구는 다음과 같은 작업을 수행할 수 있습니다.

• 웹 서비스가 사용 가능하며 응답할 수 있는 상태인지 확인합니다. 앱이 웹 서비스를 사용하는 웹 사이트 또는 디바이스 앱이든 관계없이 전 세계 위치에서 몇 분마다 URL을 테스트하고 문제가 있는지 알려줄 수 있습니다.
• 웹 서비스의 성능 문제나 예외를 빠르게 진단합니다. CPU 또는 기타 리소스가 확대되는지 확인하고 예외에서 스택 추적을 가져오며 로그 추적을 쉽게 검색할 수 있습니다. 앱 성능이 허용 한도 미만으로 떨어지면 이메일이 전송될 수 있습니다. .NET 및 Java 웹 서비스를 모두 모니터링할 수 있습니다.

Application Insights란?에서 추가 정보를 찾을 수 있습니다.

다음 단계

Azure Storage의 분석에 대한 자세한 내용은 다음 리소스를 참조하세요.

• Azure Portal에서 스토리지 계정 모니터링
• 스토리지 분석
• 스토리지 분석 메트릭
• 스토리지 분석 메트릭 테이블 스키마
• 스토리지 분석 로그
• 스토리지 분석 로그 형식

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.

도움을 요청하십시오.

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