상태 엔드포인트 모니터링 패턴

애플리케이션 및 서비스가 올바르게 수행되고 있는지 확인하려면 상태 엔드포인트 모니터링 패턴을 사용할 수 있습니다. 이 패턴은 애플리케이션에서 기능 검사 사용을 지정합니다. 외부 도구는 노출된 엔드포인트를 통해 정기적으로 이러한 검사 액세스할 수 있습니다.

컨텍스트 및 문제점

웹 애플리케이션 및 백 엔드 서비스를 모니터링하는 것이 좋습니다. 모니터링은 애플리케이션 및 서비스를 사용할 수 있고 올바르게 수행하는 데 도움이 됩니다. 비즈니스 요구 사항에는 모니터링이 포함되는 경우가 많습니다.

온-프레미스 서비스보다 클라우드 서비스를 모니터링하는 것이 더 어려운 경우도 있습니다. 한 가지 이유는 호스팅 환경을 완전히 제어할 수 없기 때문입니다. 또 다른 하나는 서비스가 일반적으로 플랫폼 공급업체 및 다른 사용자가 제공하는 다른 서비스에 의존한다는 것입니다.

많은 요소가 클라우드 호스팅 애플리케이션에 영향을 줍니다. 네트워크 대기 시간, 기본 컴퓨팅 및 스토리지 시스템의 성능 및 가용성, 네트워크 대역폭을 예로 들 수 있습니다. 이러한 요인으로 인해 서비스가 완전히 또는 부분적으로 실패할 수 있습니다. 필요한 수준의 가용성을 보장하려면 서비스가 올바르게 수행되는지 정기적으로 확인해야 합니다. SLA(서비스 수준 계약)는 충족해야 하는 수준을 지정할 수 있습니다.

솔루션

애플리케이션의 엔드포인트에 요청을 전송하여 상태 모니터링을 구현합니다. 애플리케이션은 필요한 검사 수행한 다음 해당 상태 표시를 반환해야 합니다.

상태 모니터링 검사는 대개 다음의 두 요인을 조합합니다.

• 상태 확인 엔드포인트에 대한 요청에 대한 응답으로 애플리케이션 또는 서비스가 수행하는 검사(있는 경우)
• 상태 확인을 수행하는 도구 또는 프레임워크의 결과 분석 검사

응답 코드는 애플리케이션의 상태 나타냅니다. 필요에 따라 응답 코드는 앱에서 사용하는 구성 요소 및 서비스의 상태 제공합니다. 모니터링 도구 또는 프레임워크는 대기 시간 또는 응답 시간 검사 수행합니다.

다음 그림에서는 패턴의 개요를 제공합니다.

애플리케이션의 상태 모니터링 코드는 다른 검사 실행하여 다음을 확인할 수도 있습니다.

• 클라우드 스토리지 또는 데이터베이스의 가용성 및 응답 시간입니다.
• 애플리케이션에서 사용하는 다른 리소스 또는 서비스의 상태. 이러한 리소스 및 서비스는 애플리케이션 또는 외부에 있을 수 있습니다.

구성 가능한 엔드포인트 집합에 요청을 제출하여 웹 애플리케이션을 모니터링하는 서비스 및 도구를 사용할 수 있습니다. 그런 다음 이러한 서비스 및 도구는 구성 가능한 규칙 집합에 대해 결과를 평가합니다. 시스템에서 일부 기능 테스트를 수행하는 용도로만 서비스 엔드포인트를 만드는 것은 비교적 쉽습니다.

모니터링 도구가 수행하는 일반적인 검사 다음과 같습니다.

• 응답 코드의 유효성 검사. 예를 들면 200 (OK)의 HTTP 응답은 애플리케이션이 오류 없이 응답했다는 것을 의미합니다. 모니터링 시스템은 더 포괄적인 결과를 제공하기 위해 다른 응답 코드도 검사할 수 있습니다.
• 상태 코드가 200(OK)인 경우에도 응답 내용을 확인하여 오류를 검색합니다. 콘텐츠를 검사 반환된 웹 페이지 또는 서비스 응답의 섹션에만 영향을 주는 오류를 검색할 수 있습니다. 예를 들어 페이지 제목을 검사 앱이 올바른 페이지를 반환했음을 나타내는 특정 구를 찾을 수 있습니다.
• 응답 시간 측정 이 값에는 네트워크 대기 시간 및 애플리케이션이 요청을 발급하는 데 걸린 시간이 포함됩니다. 값이 증가하면 애플리케이션 또는 네트워크에 문제가 발생했다는 것을 의미할 수 있습니다.
• 애플리케이션 외부에 있는 리소스 또는 서비스 확인 예를 들어 애플리케이션이 글로벌 캐시에서 콘텐츠를 배달하는 데 사용하는 콘텐츠 배달 네트워크가 있습니다.
• TLS 인증서의 만료를 확인합니다.
• 애플리케이션의 URL에 대한 DNS 조회의 응답 시간 측정 이 검사 DNS 대기 시간 및 DNS 오류를 측정합니다.
• DNS 조회가 반환하는 URL의 유효성을 검사합니다. 유효성을 검사하여 항목이 올바른지 확인할 수 있습니다. DNS 서버에 대한 공격 후 발생할 수 있는 악의적인 요청 리디렉션을 방지할 수도 있습니다.

가능한 경우 다른 온-프레미스 또는 호스트된 위치에서 이러한 검사 실행한 다음 응답 시간을 비교하는 것도 유용합니다. 이상적으로는 고객과 가까운 위치에서 애플리케이션을 모니터링해야 합니다. 그런 다음 각 위치에서 성능을 정확하게 볼 수 있습니다. 이 방법은 보다 강력한 검사 메커니즘을 제공합니다. 결과는 다음과 같은 결정을 내리는 데 도움이 될 수도 있습니다.

• 애플리케이션을 배포할 위치
• 둘 이상의 데이터 센터에 배포할지 여부

애플리케이션이 모든 고객에 대해 올바르게 작동하는지 확인하려면 고객이 사용하는 모든 서비스 인스턴스에 대해 테스트를 실행합니다. 예를 들어 고객 스토리지가 둘 이상의 스토리지 계정에 분산된 경우 모니터링 프로세스는 각 계정을 검사 합니다.

문제 및 고려 사항

이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.

• 응답의 유효성을 검사하는 방법을 생각해 보세요. 예를 들어 200(OK) 상태 코드가 애플리케이션이 제대로 작동하는지 확인하기에 충분한지 확인합니다. 상태 코드를 확인하는 것이 이 패턴의 최소 구현입니다. 상태 코드는 애플리케이션 가용성의 기본 측정값을 제공합니다. 그러나 코드는 애플리케이션에서 작업, 추세 및 예정된 문제에 대한 정보를 거의 제공하지 않습니다.

• 애플리케이션에 노출할 엔드포인트 수를 결정합니다. 한 가지 방법은 애플리케이션에서 사용하는 핵심 서비스에 대해 하나 이상의 엔드포인트를 노출하고 다른 엔드포인트는 우선 순위가 낮은 서비스에 노출하는 것입니다. 이 방법을 사용하면 각 모니터링 결과에 다양한 수준의 중요도를 할당할 수 있습니다. 또한 추가 엔드포인트를 노출하는 것이 좋습니다. 각 핵심 서비스에 대해 하나씩 노출하여 모니터링 세분성을 높일 수 있습니다. 예를 들어 상태 확인 검사 애플리케이션에서 사용하는 데이터베이스, 스토리지 및 외부 지오코딩 서비스를 검사 수 있습니다. 각각 다른 수준의 가동 시간 및 응답 시간이 필요할 수 있습니다. 지오코딩 서비스 또는 다른 백그라운드 작업을 몇 분 동안 사용할 수 없을 수 있습니다. 그러나 애플리케이션은 여전히 정상일 수 있습니다.

• 모니터링 및 일반 액세스에 동일한 엔드포인트를 사용할지 여부를 결정합니다. 둘 다에 대해 동일한 엔드포인트를 사용할 수 있지만 상태 확인 검사 대한 특정 경로를 디자인할 수 있습니다. 예를 들어 일반 액세스 엔드포인트에서 /health를 사용할 수 있습니다. 이 방법을 사용하면 모니터링 도구가 애플리케이션에서 몇 가지 기능 테스트를 실행할 수 있습니다. 예를 들어 새 사용자 등록, 로그인 및 테스트 순서 지정 등이 있습니다. 동시에 일반 액세스 엔드포인트를 사용할 수 있는지 확인할 수도 있습니다.

• 모니터링 요청에 대한 응답으로 서비스에서 수집할 정보의 유형을 결정합니다. 또한 이 정보를 반환하는 방법을 결정해야 합니다. 대부분의 기존 도구와 프레임워크는 엔드포인트가 반환하는 HTTP 상태 코드만 확인합니다. 추가 정보를 반환하고 유효성을 검사하려면 사용자 지정 모니터링 유틸리티 또는 서비스를 생성해야 합니다.

• 수집할 정보의 양을 파악합니다. 검사 동안 과도한 처리를 수행하면 애플리케이션이 오버로드되고 다른 사용자에게 영향을 줄 수 있습니다. 처리 시간이 모니터링 시스템의 시간 제한을 초과할 수도 있습니다. 결과적으로 시스템에서 애플리케이션을 사용할 수 없음으로 표시할 수 있습니다. 대부분의 애플리케이션에는 오류 처리기 및 성능 카운터와 같은 계측이 포함됩니다. 이러한 도구는 성능 및 자세한 오류 정보를 기록할 수 있으며, 이는 충분할 수 있습니다. 상태 확인 검사 추가 정보를 반환하는 대신 이 데이터를 사용하는 것이 좋습니다.

• 엔드포인트 상태 캐싱하는 것이 좋습니다. 상태 검사 자주 실행하는 것은 비용이 많이 들 수 있습니다. 예를 들어 상태 상태 대시보드를 통해 보고되는 경우 대시보드에 대한 모든 요청이 상태 검사 트리거하지 않도록 합니다. 대신 시스템 상태를 주기적으로 검사 상태 캐시합니다. 캐시된 상태를 반환하는 엔드포인트 노출.

• 모니터링 엔드포인트에 대한 보안을 구성하는 방법을 계획합니다. 보안을 구성하면 다음을 수행할 수 있는 공용 액세스로부터 엔드포인트를 보호할 수 있습니다.

  • 악의적인 공격에 애플리케이션을 노출합니다.
  • 중요한 정보가 노출될 위험이 있습니다.
  • DoS(서비스 거부) 공격을 유치합니다.

  일반적으로 애플리케이션 구성에서 보안을 구성합니다. 그런 다음 애플리케이션을 다시 시작하지 않고도 설정을 쉽게 업데이트할 수 있습니다. 다음 기법 중 하나 이상의 사용을 고려해야 합니다.

  • 인증을 통한 엔드포인트의 보안. 모니터링 서비스 또는 도구가 인증을 지원하는 경우 요청 헤더에서 인증 보안 키를 사용할 수 있습니다. 요청과 함께 자격 증명을 전달할 수도 있습니다. 인증을 사용하는 경우 상태 검사 엔드포인트에 액세스하는 방법을 고려합니다. 예를 들어 Azure 앱 Service에는 App Service 인증 및 권한 부여 기능과 통합되는 기본 제공 상태 검사 있습니다.

  • 은닉되거나 숨겨진 엔드포인트의 사용. 예를 들어 기본 애플리케이션 URL에서 사용하는 것과 다른 IP 주소에 엔드포인트를 노출합니다. 비표준 HTTP 포트에서 엔드포인트를 구성합니다. 또한 테스트 페이지에 복잡한 경로를 사용하는 것이 좋습니다. 일반적으로 애플리케이션 구성에서 추가 엔드포인트 주소 및 포트를 지정할 수 있습니다. 필요한 경우 이러한 엔드포인트에 대한 항목을 DNS 서버에 추가할 수 있습니다. 그런 다음 IP 주소를 직접 지정하지 않아도 됩니다.

  • 엔드포인트에서 키 값 또는 작동 모드 값과 같은 매개 변수를 수락하는 메서드의 노출. 요청이 도착하면 코드는 매개 변수 값에 따라 특정 테스트를 실행할 수 있습니다. 이 코드는 매개 변수 값을 인식하지 못하는 경우 404(찾을 수 없음) 오류를 반환할 수 있습니다. 애플리케이션 구성에서 매개 변수 값을 정의할 수 있도록 합니다.

  • 애플리케이션 작업을 손상시키지 않고 기본 기능 테스트를 수행하는 별도의 엔드포인트를 사용합니다. 이 방법을 사용하면 DoS 공격의 영향을 줄일 수 있습니다. 민감한 정보를 노출시킬 수 있는 테스트는 사용하지 않는 것이 좋습니다. 경우에 따라 공격자에게 유용할 수 있는 정보를 반환해야 합니다. 이 경우 엔드포인트 및 데이터를 무단 액세스로부터 보호하는 방법을 고려합니다. 모호성에 의존하는 것만으로는 충분하지 않습니다. 또한 HTTPS 연결을 사용하고 중요한 데이터를 암호화하는 것이 좋습니다. 이 방법은 서버의 부하를 증가시키는 방법입니다.

• 모니터링 에이전트가 올바르게 수행되는지 확인하는 방법을 결정합니다. 한 가지 방법은 애플리케이션 구성에서 값을 반환하는 엔드포인트 또는 에이전트를 테스트하는 데 사용할 수 있는 임의 값을 노출하는 것입니다. 또한 모니터링 시스템에서 자체 검사 수행하도록 합니다. 자체 테스트 또는 기본 제공 테스트를 사용하여 모니터링 시스템이 가양성 결과를 발급하지 못하도록 방지할 수 있습니다.

이 패턴을 사용해야 하는 경우

이 패턴은 다음의 경우에 유용합니다.

• 가용성을 확인하기 위한 웹 사이트와 웹 애플리케이션의 모니터링
• 올바른 작동을 검사하기 위한 웹 사이트와 웹 애플리케이션의 모니터링
• 중간 계층 또는 공유 서비스를 모니터링하여 다른 애플리케이션을 방해할 수 있는 오류를 감지하고 격리합니다.
• 애플리케이션에서 성능 카운터와 오류 처리기 같은 기존 계측의 보완. 상태 확인 검사 로깅 및 감사에 대한 애플리케이션 요구 사항을 대체하지는 않습니다. 계측은 장애 또는 다른 문제를 검색하기 위해 카운터와 오류 로그를 모니터링하는 기존 프레임워크에 대한 귀중한 정보를 제공할 수 있습니다. 그러나 애플리케이션을 사용할 수 없는 경우 계측에서 정보를 제공할 수 없습니다.

워크로드 디자인

설계자는 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하기 위해 워크로드 디자인에 상태 엔드포인트 모니터링 패턴을 사용하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.

예시

ASP.NET 상태 검사 미들웨어 및 라이브러리를 사용하여 앱 인프라 구성 요소의 상태를 보고할 수 있습니다. 이 프레임워크는 일관된 방식으로 상태 검사 보고하는 방법을 제공합니다. 이 문서에서 설명하는 많은 사례를 구현합니다. 예를 들어 ASP.NET 상태 검사 데이터베이스 연결과 같은 외부 검사 및 활동성 및 준비 상태 프로브와 같은 특정 개념을 포함합니다.

ASP.NET 상태 검사 사용하는 몇 가지 예제 구현은 GitHub에서 사용할 수 있습니다.

Azure 호스팅 애플리케이션에서 엔드포인트 모니터링

Azure 애플리케이션에서 엔드포인트를 모니터링하는 옵션은 다음과 같습니다.

• Azure Monitor와 같은 Azure의 기본 제공 모니터링 기능을 사용합니다.
• 타사 서비스 또는 Microsoft System Center Operations Manager와 같은 프레임워크를 사용합니다.
• 사용자 고유의 서버 또는 호스트된 서버에서 실행되는 사용자 지정 유틸리티 또는 서비스를 만듭니다.

Azure는 포괄적인 모니터링 옵션을 제공하지만 추가 서비스 및 도구를 사용하여 추가 정보를 제공할 수 있습니다. Monitor의 기능인 Application Insights는 개발 팀을 위해 설계되었습니다. 이 기능은 앱의 성능 및 사용 방법을 이해하는 데 도움이 됩니다. Application Insights는 요청 속도, 응답 시간, 실패율 및 종속성 속도를 모니터링합니다. 외부 서비스의 속도가 느려지는지 여부를 확인하는 데 도움이 될 수 있습니다.

모니터링할 수 있는 조건은 애플리케이션에 대해 선택한 호스팅 메커니즘에 따라 달라집니다. 이 섹션의 모든 옵션은 경고 규칙을 지원합니다. 경고 규칙은 서비스의 설정에서 지정하는 웹 엔드포인트를 사용합니다. 이런 엔드포인트는 애플리케이션이 올바르게 작동하고 있다는 것을 경고 시스템이 감지할 수 있도록 시기적절한 방식으로 응답해야 합니다. 자세한 내용은 새 경고 규칙 만들기를 참조 하세요.

큰 중단이 발생하는 경우 클라이언트 트래픽은 다른 지역 또는 영역에서 사용할 수 있는 애플리케이션 배포로 라우팅할 수 있어야 합니다. 이 상황은 크로스-프레미스 연결 및 전역 부하 분산에 적합한 경우입니다. 선택은 애플리케이션이 내부 또는 외부 연결인지에 따라 달라집니다. Azure Front Door, Azure Traffic Manager 또는 콘텐츠 배달 네트워크와 같은 서비스는 상태 프로브가 제공하는 데이터를 기반으로 지역 간에 트래픽을 라우팅할 수 있습니다.

Traffic Manager 는 라우팅 및 부하 분산 서비스입니다. 다양한 규칙 및 설정을 사용하여 애플리케이션의 특정 인스턴스에 요청을 배포할 수 있습니다. Traffic Manager는 라우팅 요청 외에도 URL, 포트 및 상대 경로를 정기적으로 ping할 수 있습니다. 애플리케이션의 인스턴스가 활성 상태이고 요청에 응답하는 것을 목표로 ping 대상을 지정합니다. Traffic Manager가 상태 코드 200(확인)을 검색하면 애플리케이션을 사용 가능한 것으로 표시합니다. 다른 상태 코드의 경우 Traffic Manager는 애플리케이션을 오프라인으로 표시합니다. Traffic Manager 콘솔에는 각 애플리케이션의 상태 표시됩니다. 응답하는 애플리케이션의 다른 인스턴스로 요청을 다시 라우팅하도록 각 규칙을 구성할 수 있습니다.

Traffic Manager는 모니터링 URL에서 응답을 받기 위해 일정 시간 동안 대기합니다. 현재 상태 확인 코드가 실행되는지 확인합니다. Traffic Manager에서 애플리케이션으로의 왕복에 대한 네트워크 대기 시간을 허용하고 다시 돌아갑니다.

다음 단계

다음 지침은 이 패턴을 구현하는 데 유용합니다.

• 마이크로 서비스 기반 애플리케이션의 상태 모니터링 지침
• Azure Well-Architected Framework의 일부인 안정성에 대한 애플리케이션 상태 모니터링
• 새 경고 규칙 만들기

관련 참고 자료

• 외부 구성 저장소 패턴
• 회로 차단기 패턴
• 게이트웨이 라우팅 패턴
• 게이트키퍼 패턴