기존 상태 확인에서 분할 상태 확인으로 마이그레이션

2019년 9월 15일부터 기존 상태 확인을 사용할 경우 애플리케이션은 계속 실행되고 상태 확인을 수신하지만 애플리케이션의 새 버전을 배포할 수 없습니다.

이 페이지에서는 기존 상태 확인에서 분할 상태 확인으로 업그레이드하는 방법을 설명합니다.

상태 확인 유형 확인

애플리케이션에서 사용 중인 상태 확인 유형을 확인하려면 다음 명령어를 실행합니다.

gcloud app describe

애플리케이션에서 분할 상태 확인을 사용하는 경우 설명에 다음 정보가 포함됩니다.

featureSettings:
    splitHealthChecks: true

분할 상태 확인으로 업그레이드하기 전에 다음과 같은 기존 상태 확인과 분할 상태 확인 간의 중요 차이점을 알고 있어야 합니다.

기본적으로 분할 상태 확인의 HTTP 요청은 전달되지 않습니다. 이와 반대로 기존 상태 확인은 기본적으로 애플리케이션의 /_ah/health 경로로 전달됩니다.
전달된 분할 상태 확인이 정상 및 준비 상태이면 200 OK를 반환해야 합니다. 기존 상태 확인은 200, 301, 302, 303, 307, 401, 402, 403, 404, 405 HTTP 코드를 정상 상태로 간주합니다.

활성 확인 경로 또는 준비 확인 경로를 지정하지 않으면 분할 상태 확인은 기본적으로 VM 인스턴스와 Docker 컨테이너 실행 여부만 확인합니다. 이러한 조건이 유지되는 한 VM은 트래픽을 계속 수신하고 앱의 내부 상태에 관계없이 활성 상태로 유지됩니다.

이와 반대로 기존 상태 확인이 사용 설정된 경우 앱의 /_ah/health 경로가 비정상 HTTP 오류 코드(예: 5XX)를 반환하기 시작하면 기존 상태 확인이 실패하기 시작하고 VM이 트래픽 수신을 중지하고 다시 시작됩니다.

앱이 기존 상태 확인의 기본 동작에 종속되는 경우 이에 맞게 활성 확인 경로와 준비 확인 경로를 설정합니다.

다음과 같이 분할 상태 확인을 사용하여 각 기존 상태 확인 옵션을 다시 쓸 수 있습니다.

옵션	분할 상태 확인에서 동일한 동작 유지
`enable_health_check`	`True`이거나 설정되지 않은 경우 `liveness_check.path` 및 `readiness_check.path`를 앱이 정상 상태일 때 `200 OK`를 반환하는 앱의 경로로 구성합니다.
`check_interval_sec`	`liveness_check.check_interval_sec` 및 `readiness_check.check_interval_sec`를 같은 값으로 구성합니다.
`timeout_sec`	`liveness_check.timeout_sec` 및 `readiness_check.timeout_sec`를 같은 값으로 구성합니다.
`unhealthy_threshold`	`readiness_check.failure_threshold`를 같은 값으로 구성합니다.
`healthy_threshold`	`liveness_check.success_threshold` 및 `readiness_check.success_threshold`를 같은 값으로 구성합니다.
`restart_threshold`	`liveness_check.failure_threshold`를 같은 값으로 구성합니다. `check_interval_sec` 옵션 값에 `failure_threshold` 옵션을 곱한 값이 비정상 VM을 종료하는 데 소요되는 시간입니다.

기존 상태 확인에서 분할 상태 확인으로 마이그레이션하고 승격된 5xx 상태 코드가 발생하지 않도록 하려면 다음 단계를 완료합니다.

기존 상태 확인과 분할 상태 확인 간의 중요 차이점을 이해합니다.
애플리케이션의 버전별로 기존 상태 확인 옵션을 변환합니다.

또는 버전별로 app.yaml 파일에서 liveness_check 또는 readiness_check 섹션을 맞춤설정할 수 있습니다. 예시는 활성 확인과 준비 확인을 참조하세요.

다음 명령어를 실행합니다.

gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]