상태 검사를 사용하여 App Service 인스턴스 모니터링

이 문서에서는 Azure Portal의 상태 검사를 사용하여 App Service 인스턴스를 모니터링합니다. 상태 검사는 비정상 인스턴스에서 요청을 다시 라우팅하고 비정상 상태로 유지되는 경우 인스턴스를 대체하여 애플리케이션의 가용성을 높입니다. 선택한 웹 애플리케이션의 경로를 매분 ping하여 이를 수행합니다.

/api/health는 설명 목적으로 추가된 예일 뿐입니다. 기본적으로 상태 확인 경로는 만들어지지 않습니다. 선택하는 경로가 애플리케이션 내에 존재하는 유효한 경로인지 확인해야 합니다.

App Service에서 상태 검사를 통해 수행하는 기능

• 앱에서 경로를 지정하는 경우 상태 검사는 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가 사용하지 않도록 설정한 경우 발생할 수 있습니다.

상태 검사 사용하도록 설정

1. 상태 검사를 사용하도록 설정하려면 Azure Portal로 이동하여 App Service 앱을 선택합니다.
2. 모니터링 아래에서 상태 검사를 선택합니다.
3. 사용을 선택하고 애플리케이션에서 /health나 /api/health와 같은 올바른 URL 경로를 입력합니다.
4. 저장을 선택합니다.

참고 항목

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

주의

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

구성

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

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

인증 및 보안

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

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

참고 항목

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

.NET

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;
}

Python

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

Java

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);
}

Node.JS

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 애플리케이션에는 프로세스 Explorer를 통해 프로세스를 볼 수 있는 옵션도 있습니다. 이렇게 하면 스레드 수, 프라이빗 메모리 및 총 CPU 시간을 포함하여 인스턴스 프로세스에 대한 추가 인사이트를 얻을 수 있습니다.

진단 정보 수집

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

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

모니터링

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

제한 사항

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

질문과 대답

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

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

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

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

상태 검사 요청이 HTTP와 HTTPS 중에서 어떤 프로토콜을 통해 전송되나요?

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

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

아니요, 상태 확인 기능은 웹 애플리케이션의 기본 도메인 경로를 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으로 마이그레이션할 수 있습니다.

다음 단계

• 구독의 모든 자동 크기 조정 엔진 작업을 모니터링하기 위한 활동 로그 경고를 만듭니다.
• 구독에서 실패한 모든 자동 크기 조정 규모 감축/규모 확장 작업을 모니터링하기 위한 활동 로그 경고를 만듭니다.
• 환경 변수 및 앱 설정 참조