상태 확인을 사용하여 App Service 인스턴스 모니터링

아티클
10/16/2024

참고 항목

2024년 6월 1일부터, 새로 만들어진 모든 App Service 앱에는 명명 규칙 <app-name>-<random-hash>.<region>.azurewebsites.net을 사용하여 고유한 기본 호스트 이름을 생성할 수 있는 옵션이 제공됩니다. 기존 앱 이름은 변경되지 않은 상태로 유지됩니다.

예: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

자세한 내용은 App Service 리소스의 고유 기본 호스트 이름을 참조하세요.

이 문서에서는 Azure Portal에서 상태 검사를 사용하여 App Service 인스턴스를 모니터링하는 방법을 설명합니다. 상태 검사는 비정상 인스턴스에서 요청을 다시 라우팅하고 비정상 상태로 유지되는 경우 인스턴스를 대체하여 애플리케이션의 가용성을 높입니다. 이 기능은 사용자가 선택한 경로를 통해 1분마다 웹 애플리케이션에 ping을 보냅니다.

상태 검사의 작동 방식을 보여 주는 다이어그램.

/api/health는 단지 예일 뿐입니다. 기본 상태 검사 경로가 없습니다. 선택한 경로가 애플리케이션 내에 존재하는 유효한 경로인지 확인해야 합니다.

상태 검사 작동 방식

앱에서 경로를 지정하는 경우 상태 검사는 1분 간격으로 App Service 앱의 모든 인스턴스에서 이 경로를 ping합니다.
특정 인스턴스에서 실행 중인 웹앱이 10개의 요청 후에도 200~299(포함) 사이의 상태 코드로 응답하지 않으면 App Service는 해당 인스턴스가 비정상이라고 판단하고 웹앱의 부하 분산 장치에서 제거합니다. 비정상으로 간주되는 인스턴스에 필요한 실패한 요청 수는 최소 2개 요청으로 구성할 수 있습니다.
인스턴스가 제거된 후에도 상태 검사는 해당 인스턴스에 ping을 계속 보냅니다. 인스턴스가 정상 상태 코드(200~299)로 응답하기 시작하면 인스턴스가 부하 분산 장치에 반환됩니다.
인스턴스에서 실행 중인 웹앱이 1시간 동안 비정상 상태로 유지되면 인스턴스가 새 웹앱으로 대체됩니다.
스케일 아웃할 때 App Service는 새 인스턴스가 준비되도록 상태 검사 경로를 ping합니다.

참고 항목

상태 검사는 302 리디렉션을 따르지 않습니다.
시간당 최대 하나의 인스턴스만 교체되며, App Service 요금제 당 최대 3개의 인스턴스가 있습니다.
상태 검사가 상태 Waiting for health check response를 보내는 경우 HTTP 상태 코드 307로 인해 검사가 실패할 수 있습니다. HTTPS 리디렉션을 사용하도록 설정했지만 HTTPS Only가 사용하지 않도록 설정한 경우 발생할 수 있습니다.

상태 검사 사용하도록 설정

상태 검사를 사용하도록 설정하려면 Azure Portal로 이동하여 App Service 앱을 선택합니다.
모니터링 아래에서 상태 검사를 선택합니다.
사용을 선택하고 /health 또는 /api/health와 같이 애플리케이션의 유효한 URL 경로를 제공합니다.
저장을 선택합니다.

참고 항목

상태 검사를 완전히 활용하려면 App Service 플랜을 둘 이상의 인스턴스로 확장해야 합니다.
상태 검사 경로에서는 애플리케이션의 중요한 구성 요소를 확인해야 합니다. 예를 들어 애플리케이션이 데이터베이스 및 메시지 시스템에 종속된 경우 상태 검사 엔드포인트는 해당 구성 요소에 연결해야 합니다. 애플리케이션에서 중요한 구성 요소에 연결할 수 없는 경우 이 경로는 앱이 비정상임을 나타내는 500 수준 응답 코드를 반환해야 합니다. 또한 해당 경로가 1분 이내에 응답을 반환하지 않으면 상태 검사 ping은 비정상으로 간주됩니다.
상태 확인 경로를 선택할 때 앱이 완전히 준비되었을 때만 200 상태 코드를 반환하는 경로를 선택해야 합니다.
함수 앱에서 상태 확인을 사용하려면 프리미엄 또는 전용 호스팅 플랜을 사용해야 합니다.
함수 앱의 상태 확인에 대한 자세한 내용은 상태 확인을 사용하여 함수 앱 모니터링에서 확인할 수 있습니다.

주의

상태 검사 구성을 변경하면 앱을 다시 시작합니다. 프로덕션 앱에 미치는 영향을 최소화하려면 스테이징 슬롯을 구성하고 프로덕션으로 교환하는 것이 좋습니다.

구성

상태 검사 옵션을 구성하는 외에도 다음과 같은 앱 설정을 구성할 수 있습니다.

앱 설정 이름	허용된 값	설명
`WEBSITE_HEALTHCHECK_MAXPINGFAILURES`	2 - 10	인스턴스가 비정상으로 간주되고 부하 분산 장치에서 제거되는 데 필요한 실패한 요청 수입니다. 예를 들어, 이 값을 `2`로 설정하면 ping이 2번 실패 후 인스턴스가 제거됩니다. (기본값은 `10`입니다.)
`WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT`	1 - 100	기본적으로 남아 있는 정상 인스턴스에 과부하가 걸리는 것을 방지하기 위해 한 번에 절반 이상의 인스턴스만 부하 분산 장치에서 제외됩니다. 예를 들어, App Service 요금제가 4개의 인스턴스로 확장되고 3개가 비정상이면 2개가 제외됩니다. 다른 두 인스턴스(하나는 정상이고 다른 하나는 비정상)는 계속해서 요청을 받습니다. 모든 인스턴스가 비정상인 시나리오에서는 아무것도 제외되지 않습니다. 이 동작을 재정의하려면 이 앱 설정을 `1`과 `100` 사이의 값으로 설정합니다. 값이 높을수록 더 많은 비정상 인스턴스가 제거된다는 것을 의미합니다. (기본값은 `50`입니다.)

인증 및 보안

상태 검사는 App Service 인증 및 권한 부여 기능과 통합됩니다. 이러한 보안 기능이 사용하도록 설정된 경우 다른 설정은 필요하지 않습니다.

사용자 고유의 인증 시스템을 사용하는 경우 상태 검사 경로에서 익명 액세스를 허용해야 합니다. 상태 검사 엔드포인트에 대한 보안을 제공하려면 먼저 IP 제한, 클라이언트 인증서 또는 가상 네트워크와 같은 기능을 사용하여 애플리케이션 액세스를 제한해야 합니다. 이러한 기능이 있는 있으면 헤더 x-ms-auth-internal-token을 검사하고 환경 변수 WEBSITE_AUTH_ENCRYPTION_KEY의 SHA256 해시와 일치하는지 확인하여 상태 검사 요청을 인증할 수 있습니다. 일치하는 경우 상태 검사 요청이 유효하고 App Service에서 시작됩니다.

참고 항목

Azure Functions 인증의 경우, 상태 검사 엔드포인트 역할을 하는 Functions는 익명 액세스를 허용해야 합니다.

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

참고 항목

x-ms-auth-internal-token 헤더는 Windows용 App Service에서만 사용할 수 있습니다.

인스턴스

상태 확인이 사용하도록 설정되면 인스턴스 탭을 통해 애플리케이션 인스턴스의 상태를 다시 시작하고 모니터링할 수 있습니다. 인스턴스 탭에는 인스턴스 이름과 해당 애플리케이션 인스턴스의 상태가 표시됩니다. 이 탭에서 인스턴스를 수동으로 다시 시작할 수도 있습니다.

애플리케이션 인스턴스 상태가 비정상인 경우 표에 있는 다시 시작 단추를 사용하여 인스턴스를 수동으로 다시 시작할 수 있습니다. 인스턴스와 동일한 App Service 요금제에서 호스트되는 다른 애플리케이션도 다시 시작의 영향을 받습니다. 인스턴스와 동일한 App Service 요금제를 사용하는 다른 애플리케이션이 있는 경우 다시 시작 단추의 여는 블레이드에 나열됩니다.

인스턴스를 다시 시작하고 다시 시작 프로세스가 실패하면 작업자를 바꾸는 옵션이 제공됩니다. (1시간에 하나의 인스턴스만 바꿀 수 있습니다.) 이는 동일한 App Service 요금제를 사용하는 모든 애플리케이션에도 영향을 줍니다.

Windows 애플리케이션의 경우 프로세스 탐색기를 통해 프로세스를 볼 수도 있습니다. 이렇게 하면 스레드 수, 프라이빗 메모리 및 총 CPU 시간을 포함하여 인스턴스 프로세스에 대한 추가 인사이트를 얻을 수 있습니다.

진단 정보 수집

Windows 애플리케이션의 경우 상태 검사 탭에서 진단 정보를 수집하는 옵션이 있습니다. 진단 컬렉션을 사용하도록 설정하면 비정상 인스턴스에 대한 메모리 덤프를 만들고 이를 지정된 스토리지 계정에 저장하는 자동 복구 규칙이 추가됩니다. 이 옵션을 사용하도록 설정하면 자동 복구 구성이 변경됩니다. 기존 자동 복구 규칙이 있는 경우 App Service 진단을 통해 이를 설정하는 것이 좋습니다.

진단 컬렉션이 사용하도록 설정되면 파일에 대한 스토리지 계정을 만들거나 기존 계정을 선택할 수 있습니다. 애플리케이션과 동일한 지역의 스토리지 계정만 선택할 수 있습니다. 저장하면 애플리케이션이 다시 시작됩니다. 저장 후 지속적인 ping 이후 사이트 인스턴스가 비정상인 것으로 확인되면 스토리지 계정 리소스로 이동하여 메모리 덤프를 볼 수 있습니다.

모니터링

애플리케이션의 상태 검사 경로를 제공한 후 Azure Monitor를 사용하여 사이트의 상태를 모니터링할 수 있습니다. 포털의 상태 검사 블레이드에서 상단 도구 모음에 있는 메트릭을 선택합니다. 이렇게 하면 사이트의 상태 기록을 보고 새 경고 규칙을 만들 수 있는 새 블레이드가 열립니다. 상태 검사 메트릭은 상태 검사 구성에 따라 인스턴스가 비정상으로 간주된 경우에만 성공적인 ping & 표시 실패를 집계합니다. 사이트 모니터링에 대한 자세한 내용은 Azure App Service 할당량 및 경고를 참조하세요.

제한 사항

무료 및 공유 App Service 요금제에 대해 상태 검사를 사용하도록 설정하여 사이트 상태에 대한 메트릭을 확보하고 경고를 설정할 수 있습니다. 그러나 무료 및 공유 사이트는 스케일 아웃할 수 없기 때문에 비정상 인스턴스는 바뀌지 않습니다. 두 개 이상의 인스턴스로 스케일 아웃하고 상태 검사의 모든 이점을 가져올 수 있도록 기본 계층 이상으로 스케일 업해야 합니다. 이 방법은 앱의 가용성과 성능을 높여 주므로 프로덕션용 애플리케이션에 권장됩니다.
App Service 요금제에서는 시간당 최대 1개의 비정상 인스턴스를 바꿀 수 있으며 하루에 최대 3개의 인스턴스를 바꿀 수 있습니다.
배율 단위당 상태 확인으로 바뀌는 총 인스턴스 수에는 구성할 수 없는 제한이 있습니다. 이 한도에 도달하면 비정상 인스턴스가 바뀌지 않습니다. 이 값은 12시간마다 다시 설정됩니다.

자주 묻는 질문

내 앱이 단일 인스턴스에서 실행되면 어떻게 되나요?

앱이 하나의 인스턴스로만 스케일되고 비정상 상태가 되면 애플리케이션이 완전히 중단되므로 부하 분산 장치에서 제거되지 않습니다. 그러나 비정상 ping이 1시간 동안 지속되면 인스턴스가 바뀝니다. 상태 검사의 다시 라우팅 혜택을 얻으려면 둘 이상의 인스턴스로 스케일 아웃합니다. 앱이 단일 인스턴스에서 실행되는 경우에도 상태 검사의 모니터링 기능을 사용하여 애플리케이션의 상태를 추적할 수 있습니다.

내 웹 서버 로그에 상태 검사 요청이 표시되지 않는 이유는 무엇인가요?

상태 검사 요청은 내부적으로 사이트로 전송되므로 웹 서버 로그에 요청이 표시되지 않습니다. 상태 검사 코드에 로그 문을 추가하여 상태 검사 경로가 ping될 때의 로그를 유지할 수 있습니다.

상태 검사 요청은 HTTP나 HTTPS를 통해 전송되나요?

Windows 및 Linux용 App Service에서 HTTPS만이 사이트에서 사용하도록 설정된 경우 상태 검사 요청은 HTTPS를 통해 전송됩니다. 그렇지 않으면 HTTP를 통해 전송됩니다.

상태 검사가 애플리케이션 코드로 구성된 기본 도메인과 사용자 지정 도메인 간의 리디렉션을 따르고 있나요?

아니요, 상태 검사 기능은 웹 애플리케이션의 기본 도메인 경로를 ping합니다. 기본 도메인에서 사용자 지정 도메인으로 리디렉션되는 경우, 상태 검사에서 반환하는 상태 코드는 200이 아닙니다. 작업자가 비정상으로 표시된 리디렉션(301)이 됩니다.

동일한 App Service 요금제에 여러 앱이 있는 경우 어떻게 되나요?

비정상 인스턴스는 App Service 요금제의 다른 앱에 관계없이 항상 부하 분산 장치 순환에서 제거됩니다(WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT에 지정된 비율까지). 인스턴스의 앱이 1시간 이상 비정상 상태를 유지하는 경우, 상태 검사가 사용하도록 설정된 다른 모든 앱도 비정상 상태인 경우에만 해당 인스턴스가 바뀝니다. 상태 검사를 사용하도록 설정하지 않은 앱은 고려되지 않습니다.

예시

상태 검사가 사용하도록 설정된 두 개의 애플리케이션(또는 슬롯이 있는 하나의 앱)이 있다고 가정해 보겠습니다. 이를 앱 A와 앱 B라고 합니다. 이들은 동일한 App Service 요금제에 속하며, 계획은 4개의 인스턴스로 크기 조정됩니다. 두 인스턴스에서 앱 A가 비정상이 되면 부하 분산 장치는 해당 두 인스턴스에서 앱 A에 대한 요청 전송을 중지합니다. 앱 B가 정상이라고 가정하면 요청은 해당 인스턴스의 앱 B로 계속 라우팅됩니다. 해당 두 인스턴스에서 앱 A가 1시간 이상 비정상 상태를 유지하는 경우 앱 B도 해당 인스턴스에서 비정상 상태인 경우에만 인스턴스가 바뀝니다. 앱 B가 정상이면 인스턴스는 바뀌지 않습니다.

시나리오 예의 다이어그램.

참고 항목

계획에 상태 검사가 사용하도록 설정되지 않은 다른 사이트나 슬롯(앱 C)이 있는 경우 인스턴스 대체가 고려되지 않습니다.

내 인스턴스가 모두 비정상이면 어떻게 되나요?

애플리케이션의 모든 인스턴스가 비정상이면 App Service는 부하 분산 장치에서 인스턴스를 제거하지 않습니다. 이 시나리오에서 모든 비정상 앱 인스턴스를 부하 분산 장치 순환에서 제외하면 애플리케이션이 효과적으로 중단됩니다. 하지만 인스턴스 대체는 계속 발생합니다.

상태 확인은 Azure App Service Environment에서 작동하나요?

예, 상태 검사는 App Service Environment v3에 사용할 수 있지만 버전 1 또는 2에는 사용할 수 없습니다. 이전 버전의 App Service Environment를 사용하는 경우 마이그레이션 기능을 사용하여 App Service Environment를 버전 3으로 마이그레이션할 수 있습니다.

다음을 통해 공유

상태 확인을 사용하여 App Service 인스턴스 모니터링

상태 검사 작동 방식

상태 검사 사용하도록 설정

구성

인증 및 보안

인스턴스

진단 정보 수집

모니터링

제한 사항

자주 묻는 질문

내 앱이 단일 인스턴스에서 실행되면 어떻게 되나요?

내 웹 서버 로그에 상태 검사 요청이 표시되지 않는 이유는 무엇인가요?

상태 검사 요청은 HTTP나 HTTPS를 통해 전송되나요?

상태 검사가 애플리케이션 코드로 구성된 기본 도메인과 사용자 지정 도메인 간의 리디렉션을 따르고 있나요?

동일한 App Service 요금제에 여러 앱이 있는 경우 어떻게 되나요?

예시

내 인스턴스가 모두 비정상이면 어떻게 되나요?

상태 확인은 Azure App Service Environment에서 작동하나요?

다음 단계

피드백

추가 리소스