이 문서에서는 Azure App Service의 느린 앱 성능 문제를 해결하는 데 도움을 줍니다.
이 문서의 어느 시점에서든 더 많은 도움이 필요한 경우 Azure 커뮤니티 지원의 Azure 전문가에게 문의하세요. 또는 Azure 기술 지원 인시던트를 제출할 수 있습니다. Azure 지원으로 이동하여 지원 티켓 제출을 선택합니다.
증상
앱을 탐색할 때 페이지가 느리게 로드되고 때로는 시간이 초과되는 경우가 있습니다.
원인
이 문제는 애플리케이션 수준 문제가 원인이 되는 경우가 많습니다. 예를 들어:
- 시간이 오래 걸리는 네트워크 요청
- 비효율적인 애플리케이션 코드 또는 데이터베이스 쿼리
- 높은 메모리/CPU를 사용하는 애플리케이션
- 예외로 인한 애플리케이션 충돌
문제 해결 단계
문제 해결은 해결하는 순서대로 세 가지로 구분할 수 있습니다.
App Service는 각 단계별로 다양한 옵션을 제공합니다.
애플리케이션 동작 관찰 및 모니터링
서비스 상태 추적
Azure는 각 서비스 중단 또는 성능 저하를 공개합니다. Azure Portal에서 서비스의 상태를 추적할 수 있습니다. 자세한 내용은 Azure Portal을 사용하여 서비스 상태 알림 보기를 참조하세요.
앱 모니터링
Azure Portal에서 모니터링 도구를 사용하여 애플리케이션에 문제가 있는지 확인할 수 있습니다. 사이드바 메뉴의 모니터링 에서 메트릭을 선택합니다. 메트릭 드롭다운 메뉴에는 추가할 수 있는 모든 메트릭이 표시됩니다.
앱에 대해 모니터링할 수 있는 몇 가지 메트릭은 다음과 같습니다.
- 평균 메모리 작업 집합
- CPU 시간
- 메모리 작업 집합
- 요청
- 응답 시간
자세한 내용은 다음을 참조하세요.
웹 엔드포인트 상태 모니터링
앱이 표준 가격 책정 계층에서 실행되는 경우 App Service를 사용하면 세 지리적 위치에서 두 개의 엔드포인트를 모니터링할 수 있습니다.
엔드포인트 모니터링은 지리적으로 분산된 위치에서 웹 URL의 응답 시간 및 가동 시간을 테스트하는 웹 테스트를 구성합니다. 테스트는 웹 URL에 HTTP GET 작업을 수행하여 각 위치에서 응답 시간과 가동 시간을 확인합니다. 구성된 각 위치에서는 5분마다 테스트를 실행합니다.
가동 시간은 HTTP 응답 코드를 사용하여 모니터링되며 응답 시간은 밀리초로 측정됩니다. HTTP 응답 코드가 400 이상이거나 응답에 30초 넘게 걸리는 경우 모니터링 테스트가 실패합니다. 지정된 모든 위치에서 모니터링 테스트가 성공하는 경우 엔드포인트는 사용 가능한 것으로 간주됩니다.
설정하려면 Azure App Service 할당량 및 메트릭을 참조하세요.
확장을 사용한 애플리케이션 성능 모니터링
사이트 확장을 사용하여 애플리케이션 성능을 모니터링할 수도 있습니다.
각 App Service 앱은 사이트 확장으로 배포된 강력한 도구 집합을 사용할 수 있는 확장 가능한 관리 엔드포인트를 제공합니다. 확장은 다음을 포함합니다.
- GitHub Codespaces와 같은 소스 코드 편집기입니다.
- 앱에 연결된 MySQL 데이터베이스와 같은 연결된 리소스에 대한 관리 도구
Azure Application Insights도 사용할 수 있는 성능 모니터링 사이트 확장입니다. Application Insights를 사용하려면 SDK를 통해 코드를 다시 빌드합니다. 추가 데이터에 대한 액세스를 제공하는 확장을 설치할 수도 있습니다. SDK를 통해 앱의 사용과 성능을 보다 자세하게 모니터링하기 위한 코드를 작성할 수 있습니다. 자세한 내용은 Application Insights 소개 - OpenTelemetry 관찰 가능성을 참조하세요.
데이터 수집
App Service는 웹 서버와 웹 애플리케이션 모두의 정보에 로깅할 수 있도록 진단 기능을 제공합니다. 이 정보는 웹 서버 진단 및 애플리케이션 진단으로 구분됩니다.
웹 서버 진단 사용
다음과 같은 종류의 로그를 사용하거나 사용하지 않도록 설정할 수 있습니다.
- 자세한 오류 로깅: 오류를 나타내는 HTTP 상태 코드에 대한 자세한 오류 정보입니다(상태 코드 400 이상). 여기에는 서버가 오류 코드를 반환한 이유를 확인하는 데 도움이 되는 정보가 포함될 수 있습니다.
- 실패한 요청 추적: 요청을 처리하는 데 사용되는 IIS 구성 요소의 추적 및 각 구성 요소에서 소요된 시간을 포함하여 실패한 요청에 대한 자세한 정보입니다. 이는 앱 성능을 개선하거나 특정 HTTP 오류를 일으키는 원인을 격리하려는 경우에 유용할 수 있습니다.
- 웹 서버 로깅: W3C 확장 로그 파일 형식을 사용하는 HTTP 트랜잭션에 대한 정보입니다. 이 기능은 처리된 요청의 수 또는 특정 IP 주소에서 넘어온 많은 요청처럼 전반적인 앱 메트릭을 결정할 때 유용합니다.
애플리케이션 진단 사용
App Service에서 애플리케이션 성능 데이터를 수집하고, Visual Studio에서 애플리케이션 라이브를 프로파일링하거나 자세한 내용 및 추적을 기록하도록 애플리케이션 코드를 수정하는 다양한 옵션이 있습니다. 애플리케이션에 대해 보유한 액세스 양 및 모니터링 도구에서 관찰한 내용에 따라 옵션을 선택할 수 있습니다.
Application Insights Profiler 사용
Application Insights Profiler를 활성화하여 자세한 성능 추적 캡처를 시작할 수 있습니다. 문제를 조사해야 하는 경우 과거 최대 5일 동안 캡처된 추적에 액세스할 수 있습니다. Azure Portal에서 앱의 Application Insights 리소스에 액세스할 수 있는 한 이 옵션을 선택할 수 있습니다.
Application Insights Profiler는 각 웹 호출에 대한 응답 시간에 대한 통계와 느린 응답을 발생시킨 코드 줄을 나타내는 추적을 제공합니다. 경우에 따라 특정 코드가 성능이 좋은 방식으로 작성되지 않기 때문에 App Service 앱이 느려지는 경우가 있습니다. 예를 들어 병렬로 실행될 수 있는 순차 코드와 원하지 않는 데이터베이스 잠금 경합이 있습니다. 코드에서 이러한 병목 상태를 제거하면 앱의 성능이 향상되지만 정교한 추적 및 로그를 설정하지 않고는 검색하기가 어렵습니다. Application Insights Profiler에 의해 수집된 추적은 애플리케이션의 속도를 낮추는 코드 줄을 식별하는 데 도움이 되고 App Service 앱에 대한 이 과제를 해결합니다.
자세한 내용은 Windows에서 Azure App Service 앱에 대한 .NET Profiler 사용 설정을 참조하세요.
진단 추적을 수동으로 설정
웹 애플리케이션 소스 코드에 액세스할 수 있는 경우 애플리케이션 진단을 사용하면 웹 애플리케이션에서 생성된 정보를 캡처할 수 있습니다. ASP.NET 애플리케이션은 정보를 애플리케이션 진단 로그에 기록하기 위해 System.Diagnostics.Trace 클래스를 사용할 수 있습니다. 그러나 코드를 변경하고 애플리케이션을 다시 배포해야 합니다. 테스트 환경에서 앱을 실행 중인 경우 이 메서드를 권장합니다.
로깅을 위해 애플리케이션을 구성하는 방법에 대한 자세한 지침은 Azure App Service에서 앱에 대한 진단 로깅 사용을 참조하세요.
진단 도구 사용
App Service는 앱 문제를 해결하는 데 도움이 되는 지능적인 대화형 환경으로, 구성이 필요하지 않습니다. 앱에 문제가 발생할 경우 진단 도구는 문제를 보다 쉽고 빠르게 해결하고 해결할 수 있도록 올바른 정보를 안내하는 데 무엇이 잘못되어 있는지를 지적합니다.
App Service 진단에 액세스하려면 Azure Portal의 App Service 앱 또는 App Service 환경으로 이동합니다. 사이드바 메뉴에서 진단 및 문제 해결을 선택합니다.
Kudu 디버그 콘솔 사용
App Service는 사용자 환경에 대한 정보를 얻을 수 있는 JSON 엔드포인트 및 파일 디버그, 탐색, 업로드에 사용할 수 있는 디버그 콘솔과 함께 제공됩니다. 이 콘솔은 Kudu 콘솔 또는 사용자 앱에서는 SCM 대시보드라고 합니다.
Kudu 사이트로 이동하여 이 대시보드에 액세스할 수 있습니다.
Kudu가 제공하는 것은 다음과 같습니다.
- 애플리케이션에 대한 환경 설정
- 로그 스트림
- 진단 데이터 덤프
- PowerShell cmdlet 및 기본 DOS 명령을 실행할 수 있는 디버그 콘솔
Kudu의 또 다른 유용한 기능은 애플리케이션에 첫 번째 예외가 발생할 경우, 메모리 덤프를 만들기 위해 Kudu와 SysInternal 도구 Procdump를 사용할 수 있습니다. 메모리 덤프는 프로세스의 스냅샷이며 앱의 더욱 복잡한 문제를 해결하는 데 많은 도움을 줍니다.
Kudu에서 사용할 수 있는 기능에 대한 자세한 내용은 알아야 할 Windows Azure Websites 온라인 도구를 참조하세요.
문제 완화
앱 크기 조정
App Service에서 성능 및 처리량 향상을 위해 애플리케이션을 실행하는 규모를 조정할 수 있습니다. 앱을 확장하려면 App Service 계획을 더 높은 가격 책정 계층으로 변경하고 더 높은 가격 책정 계층으로 전환한 후 특정 설정을 구성하는 두 가지 관련 작업이 포함됩니다.
크기 조정에 대한 자세한 내용은 Azure App Service에서 앱 크기 조정을 참조하세요.
또한 둘 이상의 인스턴스에서 애플리케이션을 실행할 수 있습니다. 크기 확장은 더 많은 처리 기능을 제공할 뿐만 아니라, 어느 정도의 내결함성을 제공합니다. 하나의 인스턴스에서 프로세스가 다운되면, 또 다른 인스턴스에서 계속 요청을 처리합니다.
크기 조정을 수동 또는 자동으로 설정할 수 있습니다.
자동 치유 사용
자동 복구는 구성 변경, 요청, 메모리 기반 제한 또는 요청을 실행하는 데 필요한 시간과 같이 선택한 설정에 따라 앱의 작업자 프로세스를 재활용합니다. 대부분의 경우 프로세스를 재활용하는 것이 문제에서 복구하는 가장 빠른 방법입니다. 항상 Azure Portal 내에서 직접 앱을 다시 시작할 수 있지만 자동 복구는 자동으로 수행됩니다. 앱의 루트 web.config에 일부 트리거를 추가하기만 하면 됩니다. 이러한 설정은 애플리케이션이 .NET 앱이 아니더라도 동일한 방식으로 작동합니다.
자세한 내용은 Auto-Healing Azure Websites를 참조하세요.
앱을 다시 시작합니다.
재시작은 일회성 문제를 해결하는 가장 간단한 방법입니다. Azure Portal에서 앱을 중지하거나 다시 시작하는 옵션이 있습니다.
또한 Azure PowerShell을 사용하여 앱을 관리할 수 있습니다. 자세한 내용은 Azure PowerShell사용하여 Azure 리소스 관리