중요 업무용 워크로드의 상태 모델링

애플리케이션 및 인프라 모니터링은 인프라 배포에서 중요한 부분입니다. 중요 업무용 워크로드의 경우 모니터링은 배포에서 매우 중요한 부분입니다. Azure 리소스의 애플리케이션 상태 및 주요 메트릭을 모니터링하면 환경이 예상대로 작동하는지 파악하는 데 도움이 됩니다.

이러한 메트릭을 완전히 이해하고 워크로드의 전반적인 상태를 평가하려면 모니터링되는 모든 데이터를 전체적으로 이해해야 합니다. 상태 모델은 원시 메트릭 대신 워크로드의 상태를 명확하게 표시하여 전반적인 상태 평가를 도와줄 수 있습니다. 상태를 빨간색, 녹색, 노란색과 같은 "신호등" 지표로 표시하는 경우가 많습니다. 명확한 지표로 상태 모델을 표현하면 직관적으로 알아볼 수 있으므로 운영자가 워크로드의 전반적인 상태를 이해하고 발생하는 문제에 신속하게 대응할 수 있습니다.

상태 모델링을 중요 업무용 배포를 위한 다음 운영 작업으로 확장할 수 있습니다.

• Application Health Service - 스탬프 상태를 확인하는 API를 제공하는 컴퓨팅 클러스터의 애플리케이션 구성 요소입니다.

• 모니터링 - 애플리케이션 및 인프라의 상태와 성능을 평가하는 성능 및 애플리케이션 카운터 컬렉션입니다.

• 경고 - 인프라 및 애플리케이션의 문제 또는 중단에 대한 실행 가능한 경고입니다.

• 오류 분석 - 근본 원인 문서화를 포함하여 모든 오류를 분류 및 분석합니다.

이러한 작업은 중요 업무용 인프라의 포괄적인 상태 모델을 구성합니다. 상태 모델의 개발은 중요 업무용 배포의 완전하고 필수적인 부분일 수 있으며 그래야만 합니다.

자세한 내용은 Azure의 중요 업무용 워크로드 상태 모델링 및 가시성을 참조하세요.

애플리케이션 상태 관리 서비스

애플리케이션 상태 관리 서비스(HealthService)는 컴퓨팅 클러스터 내의 카탈로그 서비스(CatalogService) 및 백그라운드 프로세서(BackgroundProcessor)에 상주하는 애플리케이션 구성 요소입니다. HealthService는 Azure Front Door에서 스탬프 상태를 확인하기 위해 호출하는 REST API를 제공합니다. HealthService는 자체 상태뿐 아니라 종속성의 상태까지 반영하는 복잡한 구성 요소입니다.

컴퓨팅 클러스터가 다운되면 상태 관리 서비스가 응답하지 않습니다. 서비스가 실행 중이면 서비스는 인프라의 다음 구성 요소를 정기적으로 검사합니다.

• Azure Cosmos DB를 쿼리하려고 시도합니다.

• Event Hubs에 메시지를 보내려고 시도합니다. 메시지는 백그라운드 작업자에 의해 필터링됩니다.

• 스토리지 계정에서 상태 파일을 조회합니다. 다른 검사가 여전히 올바르게 작동하는 경우에도 이 파일을 사용하여 지역을 해제할 수 있습니다. 이 파일은 다른 프로세스와 통신하는 데 사용할 수 있습니다. 예를 들어 유지 관리를 위해 스탬프를 비우는 경우 이 파일을 삭제하여 비정상 상태를 강제로 적용하고 트래픽을 다시 라우팅할 수 있습니다.

• 상태 모델을 쿼리하여 모든 운영 메트릭이 미리 결정된 임계값 내에 있는지 확인합니다. 상태 모델이 스탬프를 비정상으로 표시하는 경우 HealthService가 수행하는 다른 테스트가 성공하더라도 트래픽을 스탬프로 라우팅하면 안 됩니다. 상태 모델은 보다 완전한 상태 보기를 고려합니다.

모든 상태 검사 결과는 메모리에 캐시되는데, 이 시간(초)을 구성할 수 있으며, 기본값은 10입니다. 이 작업으로 인해 중단 탐지의 대기 시간이 약간 늘어날 수 있지만, 모든 HealthService 쿼리에 백 엔드 호출이 필요한 것은 아니므로 클러스터 및 다운스트림 서비스의 부하가 감소합니다.

Azure Front Door와 같은 전역 라우터를 사용할 때 HealthService 쿼리 수가 크게 증가하므로 이 캐싱 패턴이 중요합니다. 요청을 처리하는 모든 Azure 데이터 센터의 모든 에지 노드는 HealthService를 호출하여 정상 작동하는 백 엔드 연결이 있는지 확인합니다. 결과를 캐싱하면 상태 검사에서 생성된 추가 클러스터 부하가 감소합니다.

구성

HealthService에서 독점적으로 사용하는 다음 설정을 제외하고 HealthService와 CatalogService의 설정은 구성 요소 간에 공통적입니다.

설정	값
HealthServiceCacheDurationSeconds	메모리 캐시의 만료 시간(초)을 제어합니다.
HealthServiceStorageConnectionString	상태 파일이 있어야 하는 스토리지 계정의 연결 문자열입니다.
HealthServiceBlobContainerName	상태 파일이 있어야 하는 스토리지 컨테이너입니다.
HealthServiceBlobName	상태 파일의 이름입니다. 상태 검사에서 이 파일을 찾습니다.
HealthServiceOverallTimeoutSeconds	전체 검사의 시간 제한입니다. 기본값은 3초입니다. 이 시간 후에도 검사가 완료되지 않으면 서비스가 비정상 상태를 보고합니다.

구현

모든 검사는 비동기적으로, 그리고 병렬로 수행됩니다. 검사 중 하나라도 실패하면 전체 스탬프를 사용할 수 없는 것으로 간주합니다.

검사 결과는 표준 비분산 ASP.NET Core MemoryCache를 사용하여 메모리에 캐시됩니다. 캐시 만료는 SysConfig.HealthServiceCacheDurationSeconds를 통해 제어하며 기본적으로 10초로 설정됩니다.

참고

모든 요청이 종속 서비스에 대한 다운스트림 호출로 이어지는 것은 아니므로 SysConfig.HealthServiceCacheDurationSeconds 구성 설정은 상태 검사에서 생성되는 추가 부하를 줄입니다.

다음 표에서는 인프라 내 구성 요소의 상태 검사를 자세히 설명합니다.

구성 요소	상태 확인
스토리지 계정 Blob	Blob 검사는 현재 다음과 같은 두 가지 용도로 사용됩니다. 1. Blob Storage에 연결할 수 있는지 테스트합니다. 스토리지 계정은 스탬프의 다른 구성 요소에서 사용되며 중요한 리소스로 간주됩니다. 2. 상태 파일을 삭제하여 지역을 수동으로 "해제"합니다. 검사에서 지정된 Blob 컨테이너에 상태 파일이 있는지만 확인하도록 디자인이 결정되었습니다. 파일의 내용은 처리되지 않습니다. 파일 내용을 읽고 파일 내용에 따라 다른 상태를 반환하는 보다 정교한 시스템을 설정할 수 있습니다. 내용 예제는 정상, 비정상 및 유지 관리입니다. 상태 파일을 제거하면 스탬프가 사용되지 않습니다. 애플리케이션을 배포한 후 상태 파일이 있는지 확인해야 합니다. 상태 파일이 없으면 서비스가 항상 비정상으로 응답합니다. Front Door는 백 엔드를 사용 가능한 것으로 인식하지 않습니다. 파일은 Terraform에서 생성되며 인프라 배포 후에 파일이 있어야 합니다.
이벤트 허브	Event Hubs 상태 보고는 EventHubProducerService를 통해 처리됩니다. 이 서비스는 Event Hubs에 새 메시지를 보낼 수 있는 경우 정상 상태를 보고합니다. 필터링을 위해 이 메시지에 추가된 식별 속성이 있습니다. HEALTHCHECK=TRUE 이 메시지는 수신 끝에서 무시됩니다. AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() 구성 설정은 HEALTHCHECK 속성을 검사합니다.
Azure Cosmos DB	Azure Cosmos DB 상태 보고는 다음과 같은 경우에 정상 상태를 보고하는 CosmosDbService를 통해 처리됩니다. 1. Azure Cosmos DB 데이터베이스에 연결하고 쿼리를 수행할 수 있습니다. 2. 데이터베이스에 테스트 문서를 쓸 수 있습니다. 테스트 문서의 TTL(Time to Live)이 짧게 설정되었으며, Azure Cosmos DB가 테스트 문서를 자동으로 제거합니다. HealthService는 2개의 별도 프로브를 수행합니다. Azure Cosmos DB가 읽기는 작동하지만 쓰기는 작동하지 않는 상태에 있는 경우 두 프로브는 경고가 트리거되도록 합니다.

Azure Cosmos DB 쿼리

읽기 전용 쿼리의 경우 데이터를 가져오지 않으며 전체 부하에 큰 영향을 주지 않는 다음 쿼리가 사용됩니다.

SELECT GetCurrentDateTime ()

쓰기 쿼리는 최소 콘텐츠가 포함된 ItemRating 더미를 만듭니다.

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

모니터링

Azure Log Analytics는 모든 애플리케이션과 인프라 구성 요소에 대한 로그와 메트릭을 저장하는 중앙 저장소로 사용됩니다. Azure Application Insights는 모든 애플리케이션 모니터링 데이터에 사용됩니다. 인프라의 각 스탬프에는 전용 Log Analytics 작업 영역 및 Application Insights 인스턴스가 있습니다. Front Door 및 Azure Cosmos DB와 같은 전역 공유 리소스에는 별도의 Log Analytics 작업 영역이 사용됩니다.

모든 스탬프는 수명이 짧으며 새 릴리스가 출시될 때마다 지속적으로 대체됩니다. 스탬프별 Log Analytics 작업 영역은 별도의 모니터링 리소스 그룹에 속한 전역 리소스로써 스탬프 Log Analytics 리소스로 배포됩니다. 이러한 리소스는 스탬프의 수명 주기를 공유하지 않습니다.

자세한 내용은 상관 관계 분석을 위한 통합 데이터 싱크를 참조하세요.

모니터링: 데이터 원본

• 진단 설정: Azure Mission-Critical에 사용되는 모든 Azure 서비스는 로그 및 메트릭을 포함한 모든 진단 데이터를 배포별(전역 또는 스탬프) Log Analytics 작업 영역으로 보내도록 구성됩니다. 이 프로세스는 Terraform 배포 과정에서 자동으로 수행됩니다. 새 옵션은 자동으로 식별되어 terraform apply의 일부로 추가됩니다.

• Kubernetes 모니터링: 진단 설정은 AKS(Azure Kubernetes Service) 로그 및 메트릭을 Log Analytics에 보내는 데 사용됩니다. AKS는 Container Insights를 사용하도록 구성됩니다. Container Insights는 Kubernetes DaemonSet를 통해 AKS 클러스터의 각 노드에 OMSAgentForLinus를 배포합니다. OMSAgentForLinux는 Kubernetes 클러스터 내에서 추가 로그와 메트릭을 수집하여 해당 Log Analytics 작업 영역으로 보낼 수 있습니다. 이러한 추가 로그 및 메트릭에는 Pod, 배포, 서비스, 전체 클러스터 상태에 대한 더 세분화된 데이터가 포함됩니다. Prometheus 스크래핑을 사용하면 ingress-nginx, cert-manager, 중요 업무용 워크로드 옆에 있는 Kubernetes에 배포된 기타 구성 요소와 같은 다양한 구성 요소에서 더 많은 인사이트를 얻을 수 있습니다. Prometheus 스크래핑은 클러스터 내의 다양한 엔드포인트에서 Prometheus 메트릭을 스크래핑하도록 OMSAgentForLinux를 구성합니다.

• Application Insights 원격 분석 데이터: Application Insights는 애플리케이션에서 원격 분석 데이터를 수집하는 데 사용됩니다. 코드는 Application Insights SDK를 사용하여 애플리케이션의 성능 데이터를 수집하도록 작성되었습니다. 최종 상태 코드 및 종속성 호출 기간, 미처리 예외 카운터와 같은 중요한 정보가 수집됩니다. 이 정보는 상태 모델에서 사용되며 경고 및 문제 해결에 사용할 수 있습니다.

모니터링: Application Insights 가용성 테스트

외부 관점에서 개별 스탬프 및 전체 솔루션의 가용성을 모니터링하기 위해 Application Insights 가용성 테스트가 다음 두 위치에 설정됩니다.

• 지역 가용성 테스트: 이 테스트는 지역 Application Insights 인스턴스에서 설정되며 스탬프의 가용성을 모니터링하는 데 사용됩니다. 이러한 테스트는 스탬프의 클러스터 및 정적 스토리지 계정을 직접 대상으로 삼습니다. 클러스터의 수신 지점을 직접 호출하려면 요청이 올바른 Front Door ID 헤더를 전달해야 합니다. 그렇지 않으면 수신 컨트롤러가 거부합니다.

• 전역 가용성 테스트: 이 테스트는 전역 Application Insights 인스턴스에서 설정되며 Front Door를 ping하여 전체 솔루션의 가용성을 모니터링하는 데 사용됩니다. 두 가지 테스트가 사용됩니다. 하나는 CatalogService를 대상으로 API 호출을 테스트하고, 다른 하나는 웹 사이트의 홈페이지를 테스트합니다.

모니터링: 쿼리

Azure Mission-Critical은 여러 KQL(Kusto 쿼리 언어) 쿼리를 사용하여 Log Analytics에서 데이터를 검색하는 함수로 작동하는 사용자 지정 쿼리를 구현합니다. 이러한 쿼리는 전역 및 스탬프 배포를 위해 분리된 코드 리포지토리에 개별 파일로 저장됩니다. 각 인프라 파이프라인이 실행될 때 Terraform을 통해 자동으로 가져오고 적용됩니다.

이 방식은 쿼리 논리를 시각화 레이어와 분리합니다. Log Analytics 쿼리는 코드에서(예: HealthService API에서) 직접 호출됩니다. 또 다른 예로 Azure 대시보드, Monitor 통합 문서 또는 Grafana와 같은 시각화 도구가 있습니다.

모니터링: 시각화

Log Analytics 상태 쿼리 결과를 시각화하기 위해 참조 구현에서 Grafana를 사용했습니다. Grafana는 Log Analytics 쿼리 결과를 표시하는 데 사용되며 논리 자체를 포함하지 않습니다. Grafana 스택은 솔루션 배포 수명 주기에 포함되지 않으며 별도로 릴리스됩니다.

자세한 내용은 시각화를 참조하세요.

경고

경고는 전체 운영 전략에서 중요한 부분입니다. 즉시 문제에 주의를 기울이라는 경고와 함께 대시보드 사용과 같은 선제적 모니터링을 사용해야 합니다.

이러한 경고는 정상 상태가 성능 저하/노란색 상태 또는 비정상/빨간색 상태로 바뀌면 운영자에게 경고하여 상태 모델을 확장합니다. 경고를 상태 모델의 루트 노드로 설정하면 운영자는 솔루션 상태에 미치는 비즈니스 수준의 영향을 즉시 인지할 수 있습니다. 결국 기본 사용자 흐름 또는 리소스가 노란색 또는 빨간색 메트릭을 보고하면 이 루트 노드가 노란색 또는 빨간색으로 바뀝니다. 운영자는 상태 모델 시각화에 주의를 기울여 문제를 해결할 수 있습니다.

자세한 내용은 자동화된 인시던트 대응을 참조하세요.

실패 분석

실패 분석을 구성하는 것은 대부분 이론적 계획 연습입니다. 이 이론적 연습은 연속 유효성 검사 프로세스의 일부인 자동 실패 주입의 입력으로 사용해야 합니다. 여기에 정의된 실패 모드를 시뮬레이션하면 이러한 실패와 대조하여 솔루션의 복원력을 검증하고 서비스가 중단되지 않게 예방할 수 있습니다.

다음 표에는 Azure Mission-Critical 참조 구현의 다양한 구성 요소 실패 사례가 나열되어 있습니다.

서비스	위험	영향/완화 방법/주석	Outage
Microsoft Entra ID	Microsoft Entra ID를 사용할 수 없게 됩니다.	현재 가능한 완화 방법이 없습니다. 다중 지역 접근 방식은 전역 서비스이기 때문에 중단을 완화할 수 없습니다. 이 서비스는 강한 종속 요소입니다. Microsoft Entra ID는 새 AKS 노드 만들기, ACR에서 컨테이너 이미지 가져오기 또는 Pod 시작 시 Key Vault에 액세스하는 것과 같은 컨트롤 플레인 작업에 사용됩니다. Microsoft Entra ID에 문제가 발생할 때 기존 실행 중인 구성 요소가 계속 실행될 수 있어야 합니다. 새 Pod 또는 AKS 노드를 생성할 수 없을 가능성이 높습니다. 이 시간 동안 스케일링 작업이 필요하면 사용자 환경이 감소하고 결국 중단될 가능성이 있습니다.	부분
Azure DNS	Azure DNS를 사용할 수 없게 되고 DNS 확인이 실패합니다.	Azure DNS를 사용할 수 없게 되면 사용자 요청과 애플리케이션의 여러 구성 요소 간에 DNS 확인이 실패할 수 있습니다. 현재는 이 시나리오를 해결하는 완화 방법이 없습니다. 다중 지역 접근 방식은 전역 서비스이기 때문에 중단을 완화할 수 없습니다. Azure DNS는 강한 종속 요소입니다. 사용되는 모든 PaaS 구성 요소가 Azure DNS에 의존하므로 백업으로서의 외부 DNS 서비스는 도움이 되지 않습니다. IP로 전환하여 DNS를 우회하는 방법은 사용할 수 없습니다. Azure 서비스에는 보장된 고정 IP 주소가 없습니다.	전체
Front Door	일반 Front Door 중단.	Front Door가 완전히 다운되면 완화 방법이 없습니다. 이 서비스는 강한 종속 요소입니다.	예
Front Door	라우팅/프런트 엔드/백 엔드 구성 오류.	배포할 때 구성이 일치하지 않아 발생할 수 있습니다. 테스트 단계에서 발견해야 합니다. DNS를 사용하는 프런트 엔드 구성은 환경에 따라 다릅니다. 완화 방법: 이전 구성으로 롤백하면 대부분의 문제가 해결됩니다. Front Door에서 변경 내용을 배포하는 데 몇 분 정도 걸리므로 중단이 발생합니다.	전체
Front Door	관리형 TLS/SSL 인증서가 삭제됩니다.	배포할 때 구성이 일치하지 않아 발생할 수 있습니다. 테스트 단계에서 발견해야 합니다. 기술적으로 사이트는 여전히 작동하지만, TLS/SSL 인증서 오류로 인해 사용자가 사이트에 액세스할 수 없습니다. 완화 방법: 인증서를 다시 발급하고 파이프라인을 수정하고 다시 실행하는 데 약 20분이 걸릴 수 있습니다.	전체
Azure Cosmos DB	데이터베이스/컬렉션의 이름이 변경됩니다.	배포할 때 구성이 일치하지 않아 발생할 수 있습니다. Terraform은 전체 데이터베이스를 덮어쓰며, 이로 인해 데이터가 손실될 수 있습니다. 데이터베이스/컬렉션 수준 잠금을 사용하여 데이터 손실을 방지할 수 있습니다. 애플리케이션이 데이터에 액세스할 수 없습니다. 앱 구성을 업데이트하고 Pod를 다시 시작해야 합니다.	예
Azure Cosmos DB	지역 가동 중단	Azure Mission-Critical에서 다중 지역 쓰기를 사용하도록 설정했습니다. 읽기 또는 쓰기에 오류가 있는 경우 클라이언트는 현재 작업을 다시 시도합니다. 모든 후속 작업은 우선 순위에 따라 다음 지역으로 영구적으로 라우팅됩니다. 기본 설정 목록에 항목이 하나 있지만(또는 비어 있지만) 계정에서 다른 지역을 사용할 수 있으면 계정 목록의 다음 지역으로 라우팅됩니다.	예
Azure Cosmos DB	RU 부족으로 인한 광범위한 제한.	Front Door 수준에서 사용되는 RU 수와 부하 분산에 따라 어떤 스탬프는 Azure Cosmos DB 사용률에서 핫으로 실행되고 또 어떤 스탬프는 더 많은 요청을 처리할 수 있습니다. 완화 방법: 부하 분산을 향상하거나 RU를 늘립니다.	예
Azure Cosmos DB	파티션이 가득 참	Azure Cosmos DB 논리적 파티션 크기 제한은 20GB입니다. 컨테이너 내의 파티션 키에 대한 데이터가 이 크기에 도달하면 "파티션 키가 최대 크기에 도달했습니다" 오류와 함께 추가 쓰기 요청이 실패합니다.	부분적(DB 쓰기 사용 안 함)
Azure Container Registry	지역 가동 중단	컨테이너 레지스트리는 Traffic Manager를 사용하여 복제본 지역 간에 장애 조치(failover)합니다. 모든 요청은 자동으로 다른 지역으로 다시 라우팅되어야 합니다. 최악의 경우 DNS 장애 조치(failover)가 발생하는 동안 AKS 노드가 Docker 이미지를 몇 분 동안 끌어올 수 없습니다.	예
Azure Container Registry	이미지가 삭제됨	이미지를 끌어올 수 없습니다. 이 중단은 새로 생성된/다시 부팅된 노드에만 영향을 줍니다. 기존 노드는 이미지가 캐시되어 있을 것입니다. **완화 방법: 이 문제가 발견될 경우 최신 빌드 파이프라인을 신속하게 다시 실행하면 이미지가 다시 레지스트리로 돌아옵니다.	예
Azure Container Registry	제한	제한 때문에 스케일 아웃 작업이 지연되어 일시적으로 성능이 저하될 수 있습니다. 완화 방법: Azure Mission-Critical은 분당 10k 읽기 작업을 제공하는 프리미엄 SKU를 사용합니다. 컨테이너 이미지는 최적화되어 있으며 소수의 레이어만 있습니다. ImagePullPolicy는 로컬로 캐시된 버전을 먼저 사용하도록 IfNotPresent로 설정됩니다. 주석: 컨테이너 이미지 끌어오기는 레이어 수에 따라 여러 읽기 작업으로 구성됩니다. 분당 읽기 작업 수가 제한되며 ACR SKU 크기에 따라 달라집니다.	예
Azure Kubernetes Service	클러스터 업그레이드 실패	AKS 노드 업그레이드는 모든 스탬프에서 서로 다른 시간에 발생해야 합니다. 한 업그레이드가 실패해도 다른 클러스터는 영향을 받지 않아야 합니다. 모든 노드를 사용할 수 없게 되는 일이 없도록 클러스터 업그레이드를 롤링 방식으로 노드에 배포해야 합니다.	예
Azure Kubernetes Service	요청을 처리할 때 애플리케이션 Pod가 종료됩니다.	이로 인해 최종 사용자가 오류에 직면하고 사용자 환경이 나빠질 수 있습니다. 완화 방법: Kubernetes는 기본적으로 정상적인 방식으로 Pod를 제거합니다. 먼저 Pod가 서비스에서 제거되고, 워크로드는 열려 있는 요청을 완료하고 데이터를 쓴 이후에 종료하도록 유예 기간이 주어지는 SIGTERM을 받습니다. 애플리케이션 코드는 SIGTERM을 이해해야 하며 워크로드를 종료하는 데 시간이 더 오래 걸리는 경우 유예 기간을 조정해야 할 수도 있습니다.	예
Azure Kubernetes Service	지역의 컴퓨팅 용량이 부족하여 노드를 더 추가할 수 없습니다.	스케일 업/아웃 작업이 실패하겠지만 기존 노드 및 해당 작업에 영향을 주지 않아야 합니다. 부하 분산을 위해 트래픽이 자동으로 다른 지역으로 이동하는 것이 가장 이상적입니다.	예
Azure Kubernetes Service	구독이 CPU 코어 할당량에 도달하여 새 노드를 추가합니다.	스케일 업/아웃 작업이 실패하겠지만 기존 노드 및 해당 작업에 영향을 주지 않아야 합니다. 부하 분산을 위해 트래픽이 자동으로 다른 지역으로 이동하는 것이 가장 이상적입니다.	예
Azure Kubernetes Service	TLS/SSL 인증서 암호화하여 발급/갱신할 수 없습니다.	클러스터가 Front Door의 상태를 비정상으로 보고해야 하며 트래픽은 다른 스탬프로 이동해야 합니다. 완화 방법: 발급/갱신 실패의 근본 원인을 조사합니다.	예
Azure Kubernetes Service	리소스 요청/제한이 잘못 구성되면 Pod가 CPU 사용률 100%에 도달하여 요청을 실패할 수 있습니다. 애플리케이션 재시도 메커니즘은 실패한 요청을 복구할 수 있어야 합니다. 다시 시도하면 클라이언트에 오류를 표시하지 않고 요청 기간이 길어질 수 있습니다. 과도한 로드는 결국 실패로 이어집니다.	없음(부하가 과도하지 않은 경우)
Azure Kubernetes Service	타사 컨테이너 이미지/레지스트리를 사용할 수 없음	cert-manager 및 ingress-nginx와 같은 일부 구성 요소는 외부 컨테이너 레지스트리(아웃바운드 트래픽)에서 컨테이너 이미지 및 helm 차트를 다운로드해야 합니다. 하나 이사의 이러한 리포지토리 또는 이미지를 사용할 수 없는 경우 새 노드(이미지가 아직 캐시되지 않은)의 새 인스턴스를 시작하지 못할 수 있습니다. 가능한 완화: 일부 시나리오에서는 타사 컨테이너 이미지를 솔루션별 컨테이너 레지스트리로 가져오는 것이 합리적 일 수 있습니다. 이렇게 하면 복잡성이 추가되며 신중하게 계획하고 운영해야 합니다.	부분적(스케일링 및 업데이트/업그레이드 작업 중에)
이벤트 허브	Event Hubs에 메시지를 보낼 수 없습니다.	스탬프를 쓰기 작업에 사용할 수 없게 됩니다. 상태 관리 서비스는 자동으로 이를 감지하고 스탬프를 순환에서 제외해야 합니다.	예
이벤트 허브	BackgroundProcessor가 메시지를 읽을 수 없습니다.	메시지가 큐에 추가됩니다. 메시지는 지속되므로 손실되지 않습니다. 현재 이 오류는 상태 관리 서비스에서 다루지 않습니다. 메시지 읽기 오류를 탐지하는 모니터링/경고가 작업자에 있어야 합니다. 완화 방법: 문제가 해결될 때까지 스탬프를 수동으로 사용하지 않도록 설정해야 합니다.	예
스토리지 계정	작업자가 Event Hubs 검사 포인팅에 스토리지 계정을 사용할 수 없게 됩니다.	스탬프가 Event Hubs의 메시지를 처리하지 않습니다. 스토리지 계정은 HealthService에서도 사용됩니다. 스토리지 문제를 HealthService가 탐지하고 스탬프를 순환에서 제외해야 합니다. 스탬프의 다른 서비스가 동시에 영향을 받을 것으로 예상할 수 있습니다.	예
스토리지 계정	정적 웹 사이트에 문제가 발생합니다.	정적 웹 사이트의 서비스 제공에 문제가 발생하면 Front Door가 오류를 탐지합니다. 트래픽은 이 스토리지 계정으로 전송되지 않습니다. Front Door에서 캐싱하는 방법도 이 문제를 완화하는 대안이 될 수 있습니다.	아니요
Key Vault	GetSecret 작업에 Key Vault를 사용할 수 없습니다.	새 Pod가 시작될 때, AKS CSI 드라이버는 Key Vault의 모든 비밀을 가져오고 실패합니다. Pod를 시작할 수 없습니다. 현재 5분마다 자동 업데이트가 수행됩니다. 이 업데이트가 실패합니다. kubectl describe pod에 오류가 표시되지만 Pod가 계속 작동합니다.	아니요
Key Vault	GetSecret 또는 SetSecret 작업에 Key Vault를 사용할 수 없습니다.	새 배포를 실행할 수 없습니다. 현재 이 오류가 한 지역에만 영향을 미치더라도 전체 배포 파이프라인이 중지될 수 있습니다.	아니요
Key Vault	Key Vault 제한	Key Vault는 10초당 1000개의 작업으로 제한됩니다. 비밀이 자동으로 업데이트되므로 스탬프에 Pod가 많이(수천 개) 있는 경우 이론적으로 이 제한에 도달할 수 있습니다. 가능한 완화 방법: 업데이트 빈도를 대폭 줄이거나 완전히 끕니다.	예
애플리케이션	잘못된 구성	잘못된 연결 문자열 또는 비밀이 앱에 삽입됩니다. 자동 배포(파이프라인이 구성을 자동으로 처리) 및 업데이트의 파란색-녹색 롤아웃으로 완화해야 합니다.	예
애플리케이션	만료된 자격 증명(스탬프 리소스)	예를 들어 Pod에 사용할 수 있도록 Key Vault에서 이벤트 허브 SAS 토큰 또는 스토리지 계정 키를 올바르게 업데이트하지 않고 변경하면 해당 애플리케이션 구성 요소가 실패합니다. 이 오류는 상태 관리 서비스에 영향을 미치며, 스탬프를 순환에서 자동으로 제거해야 합니다. 완화: Microsoft Entra ID 기반 인증을 지원하는 모든 서비스에 사용합니다. AKS를 사용하려면 Pod가 Microsoft Entra 워크로드 ID(미리 보기)를 사용하여 인증해야 합니다. Pod ID를 사용하는 방안은 참조 구현에서 검토했습니다. 현재는 Pod ID의 안정성이 충분하지 않은 것으로 확인되었으며, 현재 참조 아키텍처에 사용하지 않기로 결정했습니다. 나중에는 Pod ID가 솔루션이 될 수도 있습니다.	예
애플리케이션	만료된 자격 증명(전역적으로 공유된 리소스)	예를 들어 Pod에 사용할 수 있도록 모든 스탬프 Key Vault에서 Azure Cosmos DB API 키를 올바르게 업데이트하지 않고 변경하면 해당 애플리케이션 구성 요소가 실패합니다. 이 오류로 인해 모든 스탬프가 동시에 다운되고 워크로드 전체가 중단됩니다. Microsoft Entra 인증을 사용하여 키 및 비밀이 필요한 경우 가능한 방법은 이전 항목을 참조하세요.	전체
가상 네트워크	서브넷 IP 주소 공간이 소진됨	서브넷의 IP 주소 공간이 소진되면 새 AKS 노드 또는 Pod 만들기와 같은 스케일 아웃 작업이 발생하지 않습니다. 운영 중단으로 이어지지는 않지만 성능이 저하되고 사용자 환경에 영향을 줄 수 있습니다. 완화 방법: IP 공간을 늘립니다(가능한 경우). 늘릴 수 없는 경우에는 각 Pod가 더 많은 트래픽을 처리할 수 있도록 노드당 리소스(더 큰 VM SKU) 또는 Pod당 리소스(더 많은 CPU/메모리)를 늘리면 스케일 아웃의 필요성을 감소하므로 도움이 될 수 있습니다.	예

다음 단계

참조 구현을 배포하여 이 아키텍처에 사용되는 리소스와 해당 구성을 완전히 이해하세요.

구현: 중요 업무용 온라인