참고 항목
다음 지침 중 일부는 Windows 또는 Linux App Services에서만 작동할 수 있습니다. 예를 들어 Linux App Services는 기본적으로 64비트 모드로 실행됩니다.
이 문서에서는 Azure App Service의 Web Apps 기능에서 가용성, 성능 및 애플리케이션 문제 해결에 대한 일반적인 질문에 답변합니다. 이 가이드를 사용하여 문제를 신속하게 해결하고 앱의 안정성을 최적화할 수 있습니다.
다양한 App Service 계획의 할당량 및 한도에 대한 자세한 내용은 어디서 알아볼 수 있나요?
할당량 및 한도에 대한 자세한 내용은 App Service 한도를 참조하세요.
모든 Web Apps가 중지된 경우에도 CPU/메모리 사용량을 표시하는 내 App Service 계획
Azure 앱 Service에는 보안 업데이트, SCM 콘솔의 가용성, 애플리케이션 모니터링, 인증 및 웹앱의 다른 많은 중요한 기능과 같은 여러 플랫폼 작업 및 기능을 처리하는 지속적인 시스템 프로세스가 필요합니다.
실행 중인 Web Apps가 없거나 App Service 계획에 Web Apps가 없는 경우에도 시스템 프로세스가 App Service 계획에서 실행됩니다.
플랫폼 프로세스는 최소한의 리소스(예: CPU, 메모리 및 디스크 공간)를 사용하며 App Service 계획의 용량 계획, 모니터링 및 자동 크기 조정 트리거 구성 중에도 동일하게 고려해야 합니다.
내 앱 성능이 느림
여러 요인으로 인해 앱 성능이 저하될 수 있습니다. 자세한 문제 해결 단계는 느린 웹앱 성능 문제 해결을 참조하세요.
팁 (조언)
- 구성>에서 Always On 설정을 사용하도록 설정하여 앱을 따뜻하게 유지하고 콜드 시작을 방지합니다. 이렇게 하면 특히 기본 및 상위 계획에서 유휴 시간 후 지연을 줄일 수 있습니다.
- 앱 상태를 모니터링하고 응답하지 않는 인스턴스를 자동으로 대체하도록 상태 검사 경로를 구성합니다. 이렇게 하면 가용성 및 성능을 유지할 수 있습니다. 자세한 내용은 상태 검사를 사용하여 App Service 인스턴스 모니터링을 참조하세요.
높은 CPU 사용량 문제를 해결하려면 어떻게 해야 하나요?
CPU 사용량이 많은 일부 시나리오에서는 앱에 실제로 더 많은 컴퓨팅 리소스가 필요할 수 있습니다. 이 경우 애플리케이션이 필요한 모든 리소스를 가져오도록 더 높은 서비스 계층으로 확장하는 것이 좋습니다. 다른 경우에는 CPU 사용량이 높으면 잘못된 루프 또는 코딩 사례로 인해 발생할 수 있습니다. CPU 사용 증가를 트리거하는 항목을 파악하는 프로세스는 두 부분으로 구성됩니다. 먼저 프로세스 덤프를 만든 다음 프로세스 덤프를 분석합니다. 자세한 내용은 Web Apps에 대한 높은 CPU 사용량에 대한 덤프 파일 캡처 및 분석을 참조 하세요.
높은 메모리 사용 문제를 해결하려면 어떻게 해야 하나요?
일부 높은 메모리 사용 시나리오에서는 앱에 실제로 더 많은 컴퓨팅 리소스가 필요할 수 있습니다. 이 경우 애플리케이션이 필요한 모든 리소스를 가져오도록 더 높은 서비스 계층으로 확장하는 것이 좋습니다. 코드의 버그로 인해 메모리 누수가 발생할 수 있는 경우도 있습니다. 코딩 방법을 통해 메모리 사용량도 증가할 수 있습니다. 높은 메모리 소비를 트리거하는 요소에 대한 인사이트를 얻는 것은 두 부분으로 구성된 프로세스입니다. 먼저 프로세스 덤프를 만든 다음 프로세스 덤프를 분석합니다. Azure 사이트 확장 갤러리의 크래시 진단기는 이러한 두 단계를 효율적으로 수행할 수 있습니다. 자세한 내용은 Web Apps에 대한 간헐적인 높은 메모리에 대한 덤프 파일 캡처 및 분석을 참조 하세요.
PowerShell을 사용하여 App Service 웹앱을 자동화할 어떻게 할까요? 있나요?
PowerShell cmdlet을 사용하여 App Service 웹앱을 관리하고 유지 관리할 수 있습니다. PowerShell을 사용하여 Azure 앱 Service에서 호스트되는 웹앱 자동화 블로그 게시물에서 Azure Resource Manager 기반 PowerShell cmdlet을 사용하여 일반적인 작업을 자동화하는 방법을 설명합니다.
참고 항목
현재 자동화 스크립트의 경우 최신 Az.Websites 모듈을 사용합니다. 이전 AzureRM 모듈은 더 이상 사용되지 않습니다.
웹앱 문제를 해결하기 위해 정보를 수집해야 합니다.
웹앱의 이벤트 로그를 보려면
-
Kudu 웹 사이트(
https://*yourwebsitename*.scm.azurewebsites.net)에 로그인합니다. - 메뉴에서 콘솔
- LogFiles 폴더를 선택합니다.
- 이벤트 로그를 보려면 eventlog.xml 옆에 있는 연필 아이콘을 선택합니다.
- 로그를 다운로드하려면 PowerShell cmdlet
Save-AzureWebSiteLog -Name webappname을 실행합니다.
웹앱의 사용자 모드 메모리 덤프를 캡처하려면
-
Kudu 웹 사이트(
https://*yourwebsitename*.scm.azurewebsites.net)에 로그인합니다. - 프로세스 탐색기 메뉴를 선택합니다.
- w3wp.exe 프로세스 또는 WebJob 프로세스를 마우스 오른쪽 단추로 클릭합니다.
- 메모리 덤프 전체 덤프> 다운로드를 선택합니다.
웹앱에 대한 프로세스 수준 정보를 보는 방법
웹앱에 대한 프로세스 수준 정보를 보는 데는 두 가지 옵션이 있습니다.
- Azure Portal에서 다음을 수행합니다.
- 웹앱에 대한 프로세스 탐색기를 엽니다.
- 세부 정보를 보려면 w3wp.exe 프로세스를 선택합니다.
- Kudu 콘솔에서:
-
Kudu 웹 사이트(
https://*yourwebsitename*.scm.azurewebsites.net)에 로그인합니다. - 프로세스 탐색기 메뉴를 선택합니다.
- w3wp.exe 프로세스에 대한 속성을 선택합니다.
-
Kudu 웹 사이트(
App Service의 로컬 캐시 기능을 사용할 때 내 웹앱의 폴더 구조에서 내 로그 파일을 찾을 수 없습니다.
App Service의 로컬 캐시 기능을 사용할 경우 App Service 인스턴스에 대한 LogFiles 및 Data 폴더의 폴더 구조에 영향을 미칩니다. 로컬 캐시를 사용하면 스토리지 LogFiles 및 데이터 폴더에 하위 폴더가 만들어집니다. 하위 폴더는 명명 패턴 "고유 식별자" + 타임스탬프를 사용합니다. 각 하위 폴더는 웹앱이 실행 중이거나 실행된 VM 인스턴스에 해당합니다.
로컬 캐시를 사용하고 있는지 확인하려면 App Service 애플리케이션 설정 탭을 확인합니다. 로컬 캐시를 사용하는 경우 앱 설정 WEBSITE_LOCAL_CACHE_OPTION 이 .로 Always설정됩니다.
실패한 요청 추적을 켜려면
실패한 요청 추적을 켜려면 다음 단계를 수행합니다.
Azure Portal에서 웹앱으로 이동합니다.
모든 설정>진단 로그를 선택합니다.
실패한 요청 추적의 경우 켜기(On)를 선택합니다.
저장을 선택합니다.
웹앱 블레이드에서 도구를 선택합니다.
Visual Studio Online을 선택합니다.
설정이 켜지지 않은 경우 켜기를 선택합니다.
이동을 선택합니다.
Web.config를 선택합니다.
system.webServer에서 다음 구성을 추가합니다(특정 URL 캡처).
<system.webServer> <tracing> <traceFailedRequests> <remove path="*api*" /> <add path="*api*"> <traceAreas> <add provider="ASP" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" /> <add provider="ISAPI Extension" verbosity="Verbose" /> <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" /> </traceAreas> <failureDefinitions statusCodes="200-999" /> </add> </traceFailedRequests> </tracing>성능 저하 문제를 해결하려면 이 구성을 추가합니다(캡처 요청이 30초 이상 걸리는 경우).
<system.webServer> <tracing> <traceFailedRequests> <remove path="*" /> <add path="*"> <traceAreas> <add provider="ASP" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" /> <add provider="ISAPI Extension" verbosity="Verbose" /> <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" /> </traceAreas> <failureDefinitions timeTaken="00:00:30" statusCodes="200-999" /> </add> </traceFailedRequests> </tracing>실패한 요청 추적을 다운로드하려면 포털에서 웹 사이트로 이동합니다.
도구
메뉴에서 콘솔
LogFiles 폴더를 선택한 다음 W3SVC로 시작하는 이름의 폴더를 선택합니다.
XML 파일을 보려면 연필 아이콘을 선택합니다.
성능 및 복원력에 대한 추가 권장 사항
원격 분석, 종속성 추적 및 라이브 메트릭을 포함하여 App Service 앱의 전체 스택 관찰 가능성을 위해 Application Insights 및 Azure Monitor를 사용합니다.
가용성 영역을 지원하는 지역에 배포하는 경우 지역 가동 중단 시 복원력을 향상시키기 위해 영역 중복성을 사용하도록 설정하는 것이 좋습니다. 자세한 내용은 Azure 앱 Service의 안정성을 참조하세요.
App Service는 플랫폼 안정성을 보장하기 위해 일상적인 유지 관리를 수행합니다. 특히 App Service Environment v3에서 업데이트 동작을 더 자세히 제어하려면 업그레이드 기본 설정을 구성합니다. 자세한 내용은 Azure App Service에 대한 루틴(계획된) 유지 관리를 참조하세요.