연습 - 웹 애플리케이션 상태 검사 추가
Contoso Shoes에는 API 수준에서 웹 애플리케이션의 상태와 종속성을 확인하는 방법이 필요합니다. 정기적으로 API의 상태를 보고하는 전용 상태 검사 엔드포인트를 애플리케이션에 구현하고자 합니다.
현재 상태 및 문제
현재 설계에서 애플리케이션은 API 코드에 런타임 문제가 있거나 실패한 데이터베이스 쿼리와 같이 종속 서비스에 대한 호출이 실패할 때 오류를 로그합니다. 이 방법은 인시던트가 발생한 후 문제를 해결하는 데 유용합니다.
하지만 선제적이지는 않습니다. Azure App Service 및 외부 모니터링 도구에는 애플리케이션 자체의 상태를 검사할 수 있는 방법이 없습니다. 이러한 격차는 부하 분산 방식과 같은 많은 사용 사례에 영향을 미칩니다. 현재 구현은 애플리케이션의 상태를 확인하지 않고 인스턴스 간에 트래픽을 균등하게 분산하기 위한 App Service 계획에만 의존합니다. 보고된 인시던트에서 트래픽이 비정상 App Service 인스턴스로 라우팅되어 요청이 실패했습니다.
규격
이미 배포된 코드에 대한 확장으로 전용 상태 서비스를 빌드합니다.
애플리케이션에서 상태 검사 API를 도입합니다. API는 애플리케이션의 상태와 해당 종속성을 확인하고 상태 표시를 반환해야 합니다. 예를 들어 API는 Azure Cosmos DB에 대한 읽기 및 쓰기 작업을 주기적으로 검사해야 합니다. 읽기 및 쓰기가 독립적으로 검사되도록 이러한 기능을 별도의 프로브로 구현합니다.
팁
상태 검사를 Azure Key Vault 및 Azure Container Registry와 같은 비기능 서비스로 확장합니다. 이 단계는 이러한 서비스가 중단되면 스케일 아웃 또는 App Service 인스턴스 재시작이 가능한 기능에 영향을 미칠 수 있으므로 중요합니다.
상태 검사 API 엔드포인트는 여러 원본에서 자주 호출해야 하며, API의 성능을 저하시키지 않아야 합니다. 예를 들어 Azure App Service 계획은 1분에 두 번 엔드포인트에 요청을 보내고 어떤 App Service 인스턴스에 트래픽을 분산할지에 대해 정보를 기반으로 결정을 내려야 합니다.
결과를 메모리에 10초 동안 캐싱하여 상태 검사 API의 성능을 최적화합니다. 상태 검사 엔드포인트에 대한 모든 쿼리에서 백 엔드 호출이 발생하는 것은 아닙니다. 이러한 응답 중 일부는 캐시에서 제공될 수 있습니다.
향후 분석을 위해 Azure Monitor에서 상태 검사 데이터를 사용할 수 있도록 합니다.
권장 접근 방식
설계를 시작하려면 이 방법을 사용하는 것이 좋습니다.
1 - 상태 검사
상태 검사 API에서 보낸 모든 쿼리는 비동기 및 병렬로 수행해야 합니다. 데이터베이스와 같은 중요한 구성 요소에 대한 상태 검사를 설계합니다. API는 주기적으로 읽기 및 쓰기 작업을 확인해야 합니다. 읽기 및 쓰기가 독립적으로 검사되도록 이러한 기능을 별도의 프로브로 구현합니다.
상태 프로브에서 서비스에 너무 많은 부하를 두지 않고 실제 애플리케이션 동작을 모방하는 요청을 사용합니다. 또한 쓰기 요청을 테스트하기 위해 실제 사용자 데이터와 혼합되지 않도록 테스트 데이터를 효율적으로 제거하는 방법을 설계해야 합니다.
2 - 캐싱 패턴
상태 검사로 다운스트림 서비스가 오버로드되는 것을 방지하기 위해 상태 검사 API는 구성 가능한 시간(초) 동안 결과를 캐시해야 합니다. 이 목표를 달성할 수 있는 방법을 생각해 보세요.
작업 확인
다음은 Application Health Service 예제입니다. 설계의 모든 측면을 다루었나요?
- 상태 검사 엔드포인트가 Azure 앱 서비스의 상태 검사 기능과 호환되나요?
- 런타임 종속성에 대한 검사를 포함했나요? 프록시/테스트로 무엇을 사용했나요?
- Cosmos DB 읽기/쓰기
- 타사 API
- 성능 오버헤드를 줄이기 위해 상태 검사 결과를 캐시했나요?
- 상태 검사에 이벤트를 로그했나요? 성공과 실패를 기록했나요?
- 상태 검사 로그에 Azure Application Insights 로그 샘플링을 적용했나요?