애저 앱 서비스가 다시 시작된 이유를 확인할 수 있는 방법이 있습니까?

애저 앱 서비스가 다시 시작된 이유를 확인할 수 있는 방법이 있습니까?

Azure App Service의 단일 인스턴스에서 실행 중인 웹 사이트가 여러 개 있는데 모두 항상 켜져 있습니다.모든 것이 동시에 갑자기 다시 시작되어 모든 것이 콜드 요청에 부딪히면서 몇 분 동안 모든 것이 느려졌습니다.

만약 서비스가 저를 새로운 호스트로 이동시켰다면, 저는 이것을 예상했을 것입니다. 하지만 그것은 일어나지 않았습니다. 저는 여전히 같은 호스트 이름을 가지고 있습니다.

다시 시작할 때 CPU와 메모리 사용량은 정상이었고, 배포를 시작하지도 않았습니다.다시 시작해야 할 뚜렷한 이유가 보이지 않습니다.

왜 다시 시작했는지 알 수 있는 기록이 있나요?아니면 앱 서비스가 가끔 하는 일반적인 일입니까?

그래서, 이것에 대한 답은 "아니요, 당신은 정말 이유를 알 수 없습니다, 당신은 단지 그것이 그랬다고 추론할 수 있습니다."인 것 같습니다.

애플리케이션 인사이트 로그를 추가할 수 있습니다.

    private void Application_End()
    {
        log.Warn($"The application is shutting down because of '{HostingEnvironment.ShutdownReason}'.");

        TelemetryConfiguration.Active.TelemetryChannel.Flush();

        // Server Channel flush is async, wait a little while and hope for the best
        Thread.Sleep(TimeSpan.FromSeconds(2)); 
    }

그리고 당신은 결국"The application is shutting down because of 'ConfigurationChange'."또는"The application is shutting down because of 'HostingEnvironment'."호스트 수준에서 무슨 일이 일어나고 있는지는 알 수 없습니다.

제가 받아들여야 했던 것은 앱 서비스가 때때로 다시 시작할 것이라는 것입니다. 그리고 왜 제가 신경을 썼는지 자문해 보세요.앱 서비스는 애플리케이션 풀에 요청을 보내기 전에 애플리케이션 풀이 준비될 때까지 기다릴 수 있을 정도로 똑똑해야 합니다(예: 중복 재활용).하지만, 제 앱은 재활용 후 1-2분 동안 CPU를 작동하며 앉아 있을 것입니다.

제가 알아내는데 시간이 좀 걸렸지만, 제 모든 앱이 HTTP에서 HTTPS로 리디렉션하는 다시 쓰기 규칙을 가지고 있다는 것이 범인이었습니다.응용 프로그램 초기화 모듈에서는 작동하지 않습니다. 루트에 요청을 보내고 URL 다시 쓰기 모듈 및 ASP에서 301 리디렉션을 받는 것이 전부입니다.NET 파이프라인은 전혀 타격을 받지 않았고, 힘든 작업도 실제로 이루어지지 않았습니다.앱 서비스/그런 다음 IIS는 작업자 프로세스가 준비되었다고 생각하고 트래픽을 전송합니다.그러나 첫 번째 "실제" 요청은 실제로 301을 HTTPS URL로 리디렉션한 후 사용자가 콜드 스타트의 고통을 경험합니다.

응용 프로그램 초기화 모듈에 HTTPS가 필요하지 않도록 하기 위해 여기에 설명된 다시 쓰기 규칙을 추가했습니다. 따라서 응용 프로그램 초기화 모듈이 사이트의 루트에 도달하면 실제로 페이지 로드가 트리거되어 전체 파이프라인이 트리거됩니다.

<rewrite>
  <rules>
    <clear />
    <rule name="Do not force HTTPS for application initialization" enabled="true" stopProcessing="true">
      <match url="(.*)" />
      <conditions>
        <add input="{HTTP_HOST}" pattern="localhost" />
        <add input="{HTTP_USER_AGENT}" pattern="Initialization" />
      </conditions>
      <action type="Rewrite" url="{URL}" />
    </rule>
    <rule name="Force HTTPS" enabled="true" stopProcessing="true">
      <match url="(.*)" ignoreCase="false" />
      <conditions>
        <add input="{HTTPS}" pattern="off" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

오래된 애플리케이션을 Azure로 이동하는 일지의 많은 항목 중 하나입니다. 기존 VM에서 실행 중인 작업 중에는 거의 다시 시작하지 않는 작업이 많지만 클라우드의 새로운 환경으로 마이그레이션할 때 발생하는 문제를 해결하려면 TLC가 필요합니다.

--

2017년 10월 27일 업데이트: 이 글을 작성한 이후 Azure는 "문제 진단 및 해결" 아래에 새로운 도구를 추가했습니다."Web App 재시작됨"을 클릭하면 일반적으로 스토리지 지연 시간 또는 인프라 업그레이드 때문에 발생하는 이유를 알 수 있습니다.그러나 Azure App Service로 전환할 때 가장 좋은 방법은 앱을 임의로 재시작하여 편안하게 만드는 것입니다.

--

2018년 2월 11일 업데이트: 여러 레거시 시스템을 중간 규모 애플리케이션 서비스 계획의 단일 인스턴스(CPU 및 메모리 오버헤드가 충분함)로 마이그레이션한 후 스테이징 슬롯에서 구현이 원활하게 진행되는 번거로운 문제가 발생했지만, Azure 인프라 유지 보수로 인해 새 호스트로 부팅될 때마다2-3분의 다운타임으로 모든 것이 엉망이 될 것입니다.앱 서비스는 새 호스트로 부팅하기 전에 앱에서 성공적인 응답을 받을 때까지 기다려야 하기 때문에 왜 이런 일이 발생하는지 알아내려고 미친 듯이 노력했습니다.

이에 실망하여 App Service를 엔터프라이즈 쓰레기로 분류하고 IaaS 가상 머신으로 돌아갈 준비가 되었습니다.

여러 문제로 밝혀졌고, 다른 사람들이 자신의 야수 같은 레거시 ASP를 포팅하는 동안 그 문제들을 마주칠 것이라고 생각합니다.앱 서비스에 NET 앱을 연결하기 때문에 여기 있는 모든 앱을 살펴보아야겠다고 생각했습니다.

가장 먼저 확인해야 할 것은 당신이 실제로 업무를 수행하고 있다는 것입니다.Application_Start를 들어,사용하고 , 을 잘 하는 데 , 저를는데있는용고하많은만잘지하것을구성을합로다드니하데생야해는실꽤성는로까때제롭다기문에사▁the▁create▁for▁at▁toiberiber▁i▁its▁sure▁so▁i▁▁nh,▁good▁while합다▁which,니▁make▁things▁quite예야생▁example,▁a를해▁loading▁isn성많'실▁usingm▁config로,▁pig제구ate▁at▁manyn은때에어를들꽤문성까을하SessionFactory 시대에Application_Start그 힘든 일을 확실히 하기 위해.

위에서 언급한 것처럼 두 번째로 확인해야 할 사항은 앱 서비스의 워밍업 확인을 방해하는 SSL에 대한 다시 쓰기 규칙이 없다는 것입니다.위에서 언급한 대로 준비 검사를 다시 쓰기 규칙에서 제외할 수 있습니다.또는 App Service에서 web.config 파일이 아닌 로드 밸런서에서 HTTPS 리디렉션을 수행할 수 있는 HTTPS 전용 플래그를 처음 작성한 이후로 추가했습니다.당신의 애플리케이션 코드 위의 간접적인 계층에서 처리되기 때문에, 당신은 그것에 대해 생각할 필요가 없기 때문에, 저는 HTTPS Only 플래그를 추천합니다.

세 번째로 고려해야 할 사항은 App Service Local Cache 옵션을 사용하고 있는지 여부입니다.간단히 말해, 앱 서비스가 앱의 파일을 네트워크 공유 외부가 아닌 실행 중인 인스턴스의 로컬 스토리지에 복사하는 옵션이며, 앱이 로컬 파일 시스템에 기록된 변경 사항을 손실하더라도 상관하지 않는 경우 사용할 수 있는 좋은 옵션입니다.애플리케이션 서비스가 감자에서 실행되기 때문에 중요한 I/O 성능을 높이고 네트워크 공유 유지 관리로 인해 발생하는 재시작을 제거합니다.그러나 App Service의 인프라 업그레이드와 관련하여 문서화되지 않은 세부 사항이 있으므로 주의해야 합니다.특히, 로컬 캐시 옵션은 첫 번째 요청 후 별도의 앱 도메인의 백그라운드에서 시작되며, 로컬 캐시가 준비되면 앱 도메인으로 전환됩니다.즉, App Service가 사이트에 대해 준비 요청을 수행하고 성공적인 응답을 얻어 트래픽을 해당 인스턴스로 가리킵니다. 그러나 이제 Local Cache는 백그라운드에서 I/O를 분쇄하고 있으며, 이 인스턴스에 많은 사이트가 있는 경우 App Service I/O가 끔찍하기 때문에 중단할 수 있습니다.이러한 상황이 발생하고 있다는 것을 모르는 경우, 애플리케이션이 동일한 인스턴스에서 두 번 시작되는 것처럼(그렇기 때문에) 로그에서 으스스하게 표시됩니다.솔루션은 이 Jet 블로그 게시물을 따라 로컬 캐시 준비 시간을 알려주는 환경 변수를 모니터링하는 애플리케이션 초기화 준비 페이지를 만드는 것입니다.이렇게 하면 App Service가 로컬 캐시가 완전히 준비될 때까지 새 인스턴스로 부팅하는 것을 지연시킬 수 있습니다.데이터베이스와 대화할 수 있도록 하기 위해 사용하는 것은 다음과 같습니다.

public class WarmupHandler : IHttpHandler
{
    public bool IsReusable
    {
        get
        {
            return false;
        }
    }

    public ISession Session
    {
        get;
        set;
    }

    public void ProcessRequest(HttpContext context)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }

        var request = context.Request;
        var response = context.Response;

        var localCacheVariable = Environment.GetEnvironmentVariable("WEBSITE_LOCAL_CACHE_OPTION");
        var localCacheReadyVariable = Environment.GetEnvironmentVariable("WEBSITE_LOCALCACHE_READY");
        var databaseReady = true;

        try
        {
            using (var transaction = this.Session.BeginTransaction())
            {
                var query = this.Session.QueryOver<User>()
                    .Take(1)
                    .SingleOrDefault<User>();
                transaction.Commit();
            }
        }
        catch
        {
            databaseReady = false;
        }

        var result = new
        {
            databaseReady,
            machineName = Environment.MachineName,
            localCacheEnabled = "Always".Equals(localCacheVariable, StringComparison.OrdinalIgnoreCase),
            localCacheReady = "True".Equals(localCacheReadyVariable, StringComparison.OrdinalIgnoreCase),
        };

        response.ContentType = "application/json";

        var warm = result.databaseReady && (!result.localCacheEnabled || result.localCacheReady);

        response.StatusCode = warm ? (int)HttpStatusCode.OK : (int)HttpStatusCode.ServiceUnavailable;

        var serializer = new JsonSerializer();
        serializer.Serialize(response.Output, result);
    }
}

경로를 하십시오.web.config:

<applicationInitialization doAppInitAfterRestart="true">
  <add initializationPage="/warmup" />
</applicationInitialization>

네 번째로 고려해야 할 사항은 때때로 앱 서비스가 겉보기에 쓰레기 같은 이유로 앱을 다시 시작한다는 것입니다.설정은 다음과 같습니다.fcnMode의 Disabled다른 사용자가 서버의 구성 파일 또는 코드를 조작하는 경우 런타임이 앱을 다시 시작하지 못하도록 합니다.스테이징 슬롯을 사용하고 그러한 방식으로 배포를 수행하는 경우에는 문제가 되지 않습니다.그러나 FTP를 사용하여 파일을 처리하고 운영 환경에 변경 사항이 반영될 것으로 예상되는 경우에는 이 옵션을 사용하지 마십시오.

     <httpRuntime fcnMode="Disabled" targetFramework="4.5" />

고려해야 할 다섯 번째 사항은 주로 처음부터 제 문제였습니다. 스테이징 슬롯을 사용하고 있는지 여부입니다.AlwaysOn옵션이 활성화되었습니다. 그AlwaysOn옵션은 사이트가 따뜻한지 확인하여 IIS가 사이트의 속도를 줄이지 않도록 하는 방식으로 작동합니다.설명할 수 없이 이 설정은 고정 설정이 아니므로 설정을 설정했을 수 있습니다.AlwaysOn제작 및 스테이징 슬롯 모두에서 사용할 수 있기 때문에 매번 문제를 일으키지 않아도 됩니다.따라서 새 호스트로 부팅할 때 App Service 인프라 업그레이드에 문제가 발생합니다.다음과 같은 일이 발생합니다. 예를 들어 7개의 사이트가 인스턴스에서 호스팅되고 있으며, 각 사이트에는 자체 준비 슬롯이 있으며, 모든 사이트에는AlwaysOn가능한.App Service는 운영 슬롯 7개에 대해 준비 및 애플리케이션 초기화를 수행하고 트래픽을 리디렉션하기 전에 해당 슬롯이 성공적으로 응답할 때까지 의무적으로 기다립니다.하지만 스테이징 슬롯에서는 이렇게 하지 않습니다.트래픽을 새 인스턴스로 유도하지만,AlwaysOn1-2분 후에 스테이징 슬롯에서 시작되므로 이제 7개의 사이트가 동시에 시작됩니다.App Service는 감자를 기반으로 실행되므로 동시에 발생하는 모든 추가 I/O로 인해 운영 슬롯의 성능이 저하되고 다운타임으로 인식됩니다.

해결책은 유지하는 것입니다.AlwaysOn인프라 업데이트 후 동시에 발생하는 I/O 폭주로 인해 문제가 발생하지 않도록 스테이징 슬롯을 사용할 수 있습니다.PowerShell을 통해 스왑 스크립트를 사용하는 경우 이 "Staging에서 해제, 운영에서 설정"을 유지하는 것은 의외로 자세한 작업입니다.

Login-AzureRmAccount -SubscriptionId {{ YOUR_SUBSCRIPTION_ID }}

$resourceGroupName = "YOUR-RESOURCE-GROUP"
$appName = "YOUR-APP-NAME"
$slotName = "YOUR-SLOT-NAME-FOR-EXAMPLE-STAGING"

$props = @{ siteConfig = @{ alwaysOn = $true; } }

Set-AzureRmResource `
    -PropertyObject $props `
    -ResourceType "microsoft.web/sites/slots" `
    -ResourceGroupName $resourceGroupName `
    -ResourceName "$appName/$slotName" `
    -ApiVersion 2015-08-01 `
    -Force

Swap-AzureRmWebAppSlot `
    -SourceSlotName $slotName `
    -ResourceGroupName $resourceGroupName `
    -Name $appName

$props = @{ siteConfig = @{ alwaysOn = $false; } }

Set-AzureRmResource `
    -PropertyObject $props `
    -ResourceType "microsoft.web/sites/slots" `
    -ResourceGroupName $resourceGroupName `
    -ResourceName "$appName/$slotName" `
    -ApiVersion 2015-08-01 `
    -Force

슬롯에 이스립준슬설정다니합을롯비를 합니다.AlwaysOn 상태가 스테이징 을 "", "", "", ""로 합니다.AlwaysOn인프라 업그레이드 후에 폭발하지 않도록 전원이 꺼졌습니다.

일단 이 작업이 완료되면 보안 업데이트 및 하드웨어 오류를 처리하는 PaaS가 있으면 정말 좋습니다.하지만 마케팅 자료가 시사하는 것보다 실제로 달성하는 것이 조금 더 어렵습니다.이것이 누군가에게 도움이 되기를 바랍니다.

--

업데이트 07/17/2020: 위의 흐림에서 스테이징 슬롯을 사용하는 경우 슬롯과 스왑할 수 있으므로 "AlwaysOn"을 사용해야 하며 모든 슬롯에 설치하면 성능 문제가 발생할 수 있습니다.제가 잘 모르는 부분이 있는데, "AlwaysOn"(항상 켜져 있음)이 스왑되지 않도록 수정한 것 같습니다.내 스크립트는 실제로 AlwaysOn을 여전히 처리하지만, 실제로는 이제 No-Op이 됩니다.따라서 스테이징 슬롯에 대해 항상 설정을 해제하라는 조언은 여전히 유효하지만 스크립트에서 이 작은 저글링을 더 이상 수행할 필요는 없습니다.

메모리 부족으로 인해 서비스가 다시 시작된 경우예외 애플리케이션_종료가 앱 충돌로 인해 실행되지 않을 수 있습니다.

ASP를 옮겼습니다.NET 4.8 MVC 5 앱을 Azure App Services(윈도우 컨테이너 포함)에 적용하여 라이브로 진행하자 OOM에 직면했습니다.응용 프로그램 충돌이 너무 심하여 Application_End 이벤트에서 메시지를 기록할 수 없습니다.앱 인사이트가 재시작하기 전에 배포할 수 있는 OOME를 간헐적으로 받았습니다.

당사의 엔지니어들은 웹 사이트의 메모리를 늘리기 위해 (이전 환경에서 많이 사용했던 것처럼) 검색했지만 사용 가능한 참조를 찾을 수 없었습니다.메모리를 늘리기 위해 이 애플리케이션 설정(구성에 추가)을 사용할 것을 제안한 마이크로소프트 지원팀이 마침내 우리를 구했습니다.

WEBSITE_MEMORY_LIMIT_MB = 3072

그들은 Azure 문서에 이 참조를 추가했습니다: https://github.com/MicrosoftDocs/azure-docs/issues/13263#issuecomment-655051828

현재 당사의 애플리케이션은 피크 시간대에 약 4200M을 실행하고 있습니다.나의 서비스 플랜은 32G, 2개의 앱 서비스, 총 5개의 슬롯을 가지고 있으며, 그 중 하나는 5120M을 사용하도록 구성되어 있습니다.스테이징 슬롯을 회전시키는 데 필요한 메모리가 아직 40% 정도 남아 있습니다.

언급URL : https://stackoverflow.com/questions/45021644/is-there-way-to-determine-why-azure-app-service-restarted