Azure에서 Web Apps 애플리케이션 성능 FAQ

참고

아래 지침 중 일부는 Windows 또는 Linux App Services에서만 작동할 수 있습니다. 예를 들어 Linux App Services는 기본적으로 64비트 모드로 실행됩니다.

이 문서에서는 Azure App Service Web Apps 기능에 대한 애플리케이션 성능 문제에 대한 FAQ(질문과 대답)에 대한 답변을 제공합니다.

이 문서에서 Azure 문제가 해결되지 않으면 MSDN 및 Stack Overflow의 Azure 포럼을 방문하세요. 이러한 포럼에 문제를 게시하거나 Twitter에 @AzureSupport 게시할 수 있습니다. Azure 지원 요청을 제출할 수도 있습니다. 지원 요청을 제출하려면 Azure 지원 페이지에서 지원 받기를 선택합니다.

모든 Web Apps 중지된 경우에도 App Service 플랜에 CPU/메모리 사용량이 표시되는 이유는 무엇인가요?

Azure App Service 보안 업데이트, SCM 콘솔의 가용성, 애플리케이션 모니터링, 인증 및 웹앱의 다른 많은 중요한 기능과 같은 여러 플랫폼 작업 및 기능을 처리하는 지속적인 시스템 프로세스가 필요합니다.

시스템 프로세스는 실행 중인 Web Apps 없거나 App Service 계획에 Web Apps 없는 경우에도 App Service 계획에서 실행됩니다.

플랫폼 프로세스는 최소 리소스(예: CPU, 메모리 및 디스크 공간)를 소비하며, App Service 계획의 용량 계획, 모니터링 및 자동 크기 조정 트리거 구성 중에 동일한 리소스를 고려해야 합니다.

내 앱이 느린 이유는 무엇인가요?

여러 요인으로 인해 앱 성능이 저하될 수 있습니다. 자세한 문제 해결 단계는 느린 웹앱 성능 문제 해결을 참조하세요.

높은 CPU 사용량 시나리오 문제를 해결할 어떻게 할까요? 있나요?

일부 높은 CPU 사용 시나리오에서는 앱에 실제로 더 많은 컴퓨팅 리소스가 필요할 수 있습니다. 이 경우 애플리케이션이 필요한 모든 리소스를 가져오도록 더 높은 서비스 계층으로 스케일링을 고려합니다. 다른 경우에는 높은 CPU 사용량이 나쁜 루프 또는 코딩 사례로 인해 발생할 수 있습니다. CPU 사용량을 증가시키는 요소에 대한 인사이트를 얻는 것은 두 부분으로 구성된 프로세스입니다. 먼저 프로세스 덤프를 만든 다음 프로세스 덤프를 분석합니다. 자세한 내용은 Web Apps 높은 CPU 사용량을 위해 덤프 파일 캡처 및 분석을 참조하세요.

높은 메모리 사용 시나리오 문제를 해결할 어떻게 할까요? 있나요?

일부 높은 메모리 사용 시나리오에서는 앱에 실제로 더 많은 컴퓨팅 리소스가 필요할 수 있습니다. 이 경우 애플리케이션이 필요한 모든 리소스를 가져오도록 더 높은 서비스 계층으로 스케일링을 고려합니다. 코드의 버그로 인해 메모리 누수가 발생할 수 있는 경우도 있습니다. 코딩 방법은 메모리 사용량을 증가시킬 수도 있습니다. 높은 메모리 소비를 트리거하는 것에 대한 인사이트를 얻는 것은 두 부분으로 구성된 프로세스입니다. 먼저 프로세스 덤프를 만든 다음 프로세스 덤프를 분석합니다. Azure 사이트 확장 갤러리의 크래시 진단기는 이러한 두 단계를 효율적으로 수행할 수 있습니다. 자세한 내용은 Web Apps 대한 일시적인 높은 메모리에 대한 덤프 파일 캡처 및 분석을 참조하세요.

PowerShell을 사용하여 App Service 웹앱을 자동화할 어떻게 할까요? 있나요?

PowerShell cmdlet을 사용하여 App Service 웹앱을 관리하고 유지 관리할 수 있습니다. PowerShell을 사용하여 Azure App Service 호스트되는 웹앱 자동화 블로그 게시물에서 Azure Resource Manager 기반 PowerShell cmdlet을 사용하여 일반적인 작업을 자동화하는 방법을 설명합니다. 블로그 게시물에는 다양한 웹앱 관리 작업에 대한 샘플 코드도 있습니다. 모든 App Service 웹앱 cmdlet에 대한 설명 및 구문은 Az.Websites를 참조하세요.

내 웹앱의 이벤트 로그를 볼 어떻게 할까요? 있나요?

웹앱의 이벤트 로그를 보려면 다음을 수행합니다.

  1. Kudu 웹 사이트(https://*yourwebsitename*.scm.azurewebsites.net)에 로그인합니다.
  2. 메뉴에서 디버그 콘솔>CMD를 선택합니다.
  3. LogFiles 폴더를 선택합니다.
  4. 이벤트 로그를 보려면 eventlog.xml옆에 있는 연필 아이콘을 선택합니다.
  5. 로그를 다운로드하려면 PowerShell cmdlet Save-AzureWebSiteLog -Name webappname을 실행합니다.

내 웹앱의 사용자 모드 메모리 덤프를 캡처할 어떻게 할까요? 있나요?

웹앱의 사용자 모드 메모리 덤프를 캡처하려면 다음을 수행합니다.

  1. Kudu 웹 사이트(https://*yourwebsitename*.scm.azurewebsites.net)에 로그인합니다.
  2. 프로세스 Explorer 메뉴를 선택합니다.
  3. w3wp.exe 프로세스 또는 WebJob 프로세스를 마우스 오른쪽 단추로 클릭합니다.
  4. 메모리 덤프 전체 덤프> 다운로드 선택합니다.

내 웹앱에 대한 프로세스 수준 정보를 볼 어떻게 할까요? 있나요?

웹앱에 대한 프로세스 수준 정보를 볼 수 있는 두 가지 옵션이 있습니다.

  • Azure 포털에서 다음을 수행합니다.
    1. 웹앱에 대한 프로세스 Explorer 엽니다.
    2. 세부 정보를 보려면 w3wp.exe 프로세스를 선택합니다.
  • Kudu 콘솔에서 다음을 수행합니다.
    1. Kudu 웹 사이트(https://*yourwebsitename*.scm.azurewebsites.net)에 로그인합니다.
    2. 프로세스 Explorer 메뉴를 선택합니다.
    3. w3wp.exe 프로세스에서 속성을 선택합니다.

내 앱으로 이동하면 "오류 403 - 이 웹앱이 중지되었습니다."가 표시됩니다. 어떻게 할까요? resolve?

다음 세 가지 조건으로 인해 이 오류가 발생할 수 있습니다.

  • 웹앱이 청구 한도에 도달했으며 사이트가 비활성화되었습니다.
  • 포털에서 웹앱이 중지되었습니다.
  • 웹앱이 무료 또는 공유 크기 조정 서비스 계획에 적용될 수 있는 리소스 할당량 제한에 도달했습니다.

오류의 원인을 확인하고 문제를 resolve Web Apps 단계를 수행합니다. "오류 403 – 이 웹앱이 중지되었습니다.".

다양한 App Service 계획에 대한 할당량 및 제한에 대해 자세히 알아볼 수 있는 위치는 어디인가요?

할당량 및 제한에 대한 자세한 내용은 App Service 제한을 참조하세요.

유휴 시간 후 첫 번째 요청에 대한 응답 시간을 줄일 어떻게 할까요? 있나요?

기본적으로 웹앱은 일정 기간 동안 유휴 상태이면 언로드됩니다. 이렇게 하면 시스템에서 리소스를 보존할 수 있습니다. 단점은 웹앱이 언로드된 후 첫 번째 요청에 대한 응답이 더 길어 웹앱이 응답 제공을 로드하고 시작할 수 있다는 것입니다. 기본 및 표준 서비스 계획에서 Always On 설정을 켜서 앱을 항상 로드할 수 있습니다. 이렇게 하면 앱이 유휴 상태가 된 후 로드 시간이 길어집니다. Always On 설정을 변경하려면 다음을 수행합니다.

  1. Azure Portal 웹앱으로 이동합니다.
  2. 구성 선택
  3. 일반 설정을 선택합니다.
  4. Always On켜기 를 선택합니다.

실패한 요청 추적을 켤 어떻게 할까요? 있나요?

실패한 요청 추적을 켜려면 다음 단계를 수행합니다.

  1. Azure Portal 웹앱으로 이동합니다.

  2. 모든 설정>진단 로그를 선택합니다.

  3. 실패한 요청 추적의 경우 켜기 를 선택합니다.

  4. 저장을 선택합니다.

  5. 웹앱 블레이드에서 도구를 선택합니다.

  6. Visual Studio Online을 선택합니다.

  7. 설정이 지지 않은 경우 기를 선택합니다.

  8. 이동을 선택합니다.

  9. Web.config선택합니다.

  10. 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>
    
  11. 성능 저하 문제를 해결하려면 이 구성을 추가합니다(캡처 요청이 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>
    
  12. 실패한 요청 추적을 다운로드하려면 포털에서 웹 사이트로 이동합니다.

  13. 도구>Kudu>Go를 선택합니다.

  14. 메뉴에서 디버그 콘솔>CMD를 선택합니다.

  15. LogFiles 폴더를 선택한 다음 W3SVC로 시작하는 이름의 폴더를 선택합니다.

  16. XML 파일을 보려면 연필 아이콘을 선택합니다.

"작업자 프로세스가 '백분율 메모리' 제한으로 인해 재활용을 요청했습니다." 메시지가 표시됩니다. 이 문제를 해결할 어떻게 할까요? 있나요?

32비트 프로세스(64비트 운영 체제에서도)에 사용 가능한 최대 메모리 양은 2GB입니다. 기본적으로 작업자 프로세스는 레거시 웹 애플리케이션과의 호환성을 위해 App Service 32비트로 설정됩니다.

웹 작업자 역할에서 사용할 수 있는 추가 메모리를 활용할 수 있도록 64비트 프로세스로 전환하는 것이 좋습니다. 이 작업은 웹앱 다시 시작을 트리거하므로 그에 따라 예약합니다.

또한 64비트 환경에는 기본 또는 표준 서비스 계획이 필요합니다. 무료 및 공유 플랜은 항상 32비트 환경에서 실행됩니다.

자세한 내용은 App Service 웹앱 구성을 참조하세요.

230초 후에 요청 시간이 초과된 이유는 무엇인가요?

Azure Load Balancer 기본 유휴 시간 제한 설정은 4분입니다. 이 설정은 일반적으로 웹 요청에 대한 적절한 응답 시간 제한입니다. 따라서 애플리케이션이 약 240초(Windows 앱에서 230초, Linux 앱에서 240초) 이내에 응답을 반환하지 않는 경우 App Service 클라이언트에 시간 제한을 반환합니다. 웹앱에 백그라운드 처리가 필요한 경우 Azure WebJobs를 사용하는 것이 좋습니다. Azure 웹앱은 WebJobs를 호출하고 백그라운드 처리가 완료되면 알림을 받을 수 있습니다. 큐 및 트리거를 포함하여 WebJobs를 사용하기 위한 여러 방법 중에서 선택할 수 있습니다.

WebJobs는 백그라운드 처리를 위해 설계되었습니다. WebJob에서 원하는 만큼 백그라운드 처리를 수행할 수 있습니다. WebJobs에 대한 자세한 내용은 WebJobs를 사용하여 백그라운드 작업 실행을 참조하세요.

App Service 호스트되는 ASP.NET Core 애플리케이션은 때때로 응답을 중지합니다. 이 문제를 해결할 어떻게 할까요? 있나요?

이전 Kestrel 버전의 알려진 문제로 인해 App Service 호스트되는 ASP.NET Core 1.0 앱이 간헐적으로 응답을 중지할 수 있습니다. "지정된 CGI 애플리케이션에 오류가 발생하여 서버에서 프로세스를 종료했습니다."라는 메시지가 표시될 수도 있습니다.

이 문제는 Kestrel 버전 1.0.2에서 해결되었습니다. 이 버전은 ASP.NET Core 1.0.3 업데이트에 포함되어 있습니다. 이 문제를 resolve Kestrel 1.0.2를 사용하도록 앱 종속성을 업데이트해야 합니다. 또는 App Service 웹앱에서 1.0 느린 성능 문제를 ASP.NET Core 블로그 게시물에 설명된 두 가지 해결 방법 중 하나를 사용할 수 있습니다.

내 웹앱의 파일 구조에서 로그 파일을 찾을 수 없습니다. 어떻게 찾을 수 있나요?

App Service 로컬 캐시 기능을 사용하는 경우 App Service instance LogFiles 및 Data 폴더의 폴더 구조가 영향을 받습니다. 로컬 캐시를 사용하면 스토리지 LogFiles 및 Data 폴더에 하위 폴더가 만들어집니다. 하위 폴더는 명명 패턴 "고유 식별자" + 타임스탬프를 사용합니다. 각 하위 폴더는 웹앱이 실행 중이거나 실행된 VM instance 해당합니다.

로컬 캐시를 사용하고 있는지 여부를 확인하려면 App Service 애플리케이션 설정 탭을 검사. 로컬 캐시를 사용하는 경우 앱 설정 WEBSITE_LOCAL_CACHE_OPTION 이 로 Always설정됩니다.

로컬 캐시를 사용하지 않고 이 문제가 발생하는 경우 지원 요청을 제출합니다.

"액세스 권한으로 금지된 방식으로 소켓에 액세스하려고 했습니다."라는 메시지가 표시됩니다. 이 오류를 어떻게 할까요? resolve?

이 오류는 일반적으로 VM instance 아웃바운드 TCP 연결이 모두 소진된 경우에 발생합니다. App Service 각 VM instance 대해 수행할 수 있는 최대 아웃바운드 연결 수에 대한 제한이 적용됩니다. 자세한 내용은 VM 간 숫자 제한을 참조하세요.

이 오류는 애플리케이션에서 로컬 주소에 액세스하려는 경우에도 발생할 수 있습니다. 자세한 내용은 로컬 주소 요청을 참조하세요.

웹앱의 아웃바운드 연결에 대한 자세한 내용은 Azure 웹 사이트에 나가는 연결에 대한 블로그 게시물을 참조하세요.

Visual Studio를 사용하여 App Service 웹앱을 원격으로 디버그할 어떻게 할까요? 있나요?

Visual Studio를 사용하여 웹앱을 디버그하는 방법을 보여 주는 자세한 연습은 App Service 웹앱 원격 디버그를 참조하세요.

도움을 요청하십시오.

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