Azure 애플리케이션에 대한 오류 모드 분석

FMA(오류 모드 분석)는 가능한 오류 지점을 식별하여 시스템에 안정성을 구축하는 프로세스입니다. FMA는 아키텍처 및 디자인 단계의 일부여야 하므로 복원력(오류를 견딜 수 있는 기능) 및 복구 기능(오류 후 기능을 복원하는 기능)을 처음부터 시스템에 빌드할 수 있습니다.

FMA를 수행하는 일반적인 프로세스는 다음과 같습니다.

1. 시스템의 모든 구성 요소를 식별합니다. ID 공급자 및 타사 서비스와 같은 외부 종속성을 포함합니다.

2. 각 구성 요소마다 발생할 수 있는 잠재적 장애를 식별합니다. 단일 구성 요소에 둘 이상의 오류 모드가 있을 수 있습니다. 예를 들어 영향력 및 가능한 완화 단계가 서로 다르기 때문에 읽기 오류와 쓰기 오류를 별도로 고려해야 합니다.

3. 전체적인 위험도에 따라 각 장애 모드를 평가합니다. 다음 항목을 고려합니다.

   • 장애의 가능성은 무엇인가요? 비교적 일반적인가요? 매우 드문가요? 우선 순위를 지정하기 위한 것이므로 정확한 숫자는 필요하지 않습니다.
   • 가용성, 데이터 손실, 금전적 비용 및 비즈니스 중단과 관련하여 애플리케이션에 미치는 영향은 무엇인가요?

4. 각 장애 모드에 대해 애플리케이션에서 응답하고 복구하는 방법을 결정합니다. 비용 및 애플리케이션 복잡성의 장단점을 고려합니다.

FMA 프로세스에 대한 시작점으로, 이 문서에는 잠재적인 장애 모드의 카탈로그 및 해당 완화 단계가 포함되어 있습니다. 카탈로그는 기술 또는 Azure 서비스와 애플리케이션 수준 디자인을 위한 일반 범주로 구성됩니다. 카탈로그는 완전하지는 않지만 많은 핵심 Azure 서비스를 다룹니다.

Microsoft Entra ID (마이크로소프트 엔트라 ID)

OpenID Connect 인증이 실패합니다.

탐지. 가능한 장애 모드는 다음과 같습니다.

1. Microsoft Entra ID를 사용할 수 없거나 네트워크 문제로 인해 연결할 수 없습니다. 인증 엔드포인트로의 리디렉션이 실패하고, OpenID Connect 미들웨어에서 예외가 발생합니다.
2. Microsoft Entra 테넌트가 없습니다. 인증 엔드포인트로 리디렉션하면 HTTP 오류 코드가 반환되고, OpenID Connect 미들웨어는 예외를 발생시킵니다.
3. 사용자가 인증할 수 없습니다. 검색 전략이 필요하지 않으며, Microsoft Entra ID에서 로그인 실패를 처리합니다.

복구:

1. 미들웨어에서 처리되지 않은 예외를 잡습니다.
2. AuthenticationFailed 이벤트를 처리합니다.
3. 사용자를 오류 페이지로 리디렉션합니다.
4. 사용자가 다시 시도합니다.

Azure AI 검색

Azure AI Search에 데이터 쓰기가 실패합니다.

탐지. Microsoft.Rest.Azure.CloudException 오류를 포착합니다.

복구:

일시적 장애 후에 Search .NET SDK에서 자동으로 다시 시도합니다. 클라이언트 SDK에서 throw된 모든 예외는 일시적이지 않은 오류로 처리되어야 합니다.

기본 다시 시도 정책은 지수 백오프를 사용합니다. 다른 다시 시도 정책을 사용하려면 SetRetryPolicy 또는 SearchIndexClient 클래스에서 SearchServiceClient를 호출합니다. 자세한 내용은 자동 다시 시도를 참조하세요.

진단. Search 트래픽 분석을 사용합니다.

Azure AI Search에서 데이터를 읽는 데 실패합니다.

탐지. Microsoft.Rest.Azure.CloudException 오류를 포착합니다.

복구:

일시적 장애 후에 Search .NET SDK에서 자동으로 다시 시도합니다. 클라이언트 SDK에서 throw된 모든 예외는 일시적이지 않은 오류로 처리되어야 합니다.

기본 다시 시도 정책은 지수 백오프를 사용합니다. 다른 다시 시도 정책을 사용하려면 SetRetryPolicy 또는 SearchIndexClient 클래스에서 SearchServiceClient를 호출합니다. 자세한 내용은 자동 다시 시도를 참조하세요.

진단. Search 트래픽 분석을 사용합니다.

카산드라

노드에서 읽거나 쓰는 작업이 실패합니다.

탐지. 예외를 잡습니다. .NET 클라이언트의 경우 일반적으로 System.Web.HttpException입니다. 다른 클라이언트에는 다른 예외 유형이 있을 수 있습니다. 자세한 내용은 올바른 Cassandra 오류 처리를 참조하세요.

복구:

• 각 Cassandra 클라이언트에는 자체의 다시 시도 정책 및 기능이 있습니다. 자세한 내용은 올바른 Cassandra 오류 처리를 참조하세요.
• 데이터 노드가 장애 도메인에 분산되어 있는 랙 인식 배포를 사용합니다.
• 로컬 쿼럼 일관성을 사용하여 여러 지역에 배포합니다. 일시적이지 않은 장애가 발생하면 다른 지역으로 전환합니다.

진단. 애플리케이션 로그

큐 저장소

Azure Queue storage에 메시지를 쓰는 작업이 일관되게 실패합니다.

탐지. N회의 다시 시도를 수행한 후에도 쓰기 작업이 계속 실패합니다.

복구:

• 로컬 캐시에 데이터를 저장하고, 나중에 서비스를 사용할 수 있게 되면 스토리지에 쓰기를 전달합니다.
• 보조 큐를 만들고, 기본 큐를 사용할 수 없는 경우 이 보조 큐에 씁니다.

진단. 스토리지 메트릭을 사용합니다.

애플리케이션에서 큐의 특정 메시지를 처리할 수 없습니다.

탐지. 애플리케이션 특정입니다. 예를 들어 메시지에 유효하지 않은 데이터가 있거나 비즈니스 논리가 어떤 이유로 실패합니다.

복구:

메시지를 별도의 큐로 이동합니다. 별도의 프로세스를 실행하여 해당 큐의 메시지를 검사합니다.

이 목적을 위해 배달 못 한 편지 큐 기능을 제공하는 Azure Service Bus 메시지 큐를 사용하는 것이 좋습니다.

진단. 애플리케이션 로깅을 사용합니다.

SQL 데이터베이스

주 지역의 데이터베이스에 연결할 수 없습니다.

탐지. 연결이 실패합니다.

복구:

• 영역 중복을 사용하도록 설정합니다. 영역 중복을 사용하도록 설정하면 Azure SQL Database는 지원되는 지역 내의 여러 Azure 가용성 영역에 쓰기를 자동으로 복제합니다. 자세한 내용은 영역 중복 가용성을 참조하세요.

• 지리적 복제를 활성화하다. 다중 지역 솔루션을 디자인하는 경우 SQL Database 활성 지역 복제를 사용하도록 설정하는 것이 좋습니다.

  필수 구성 요소: 활성 지역 복제를 위한 데이터베이스를 구성해야 합니다. SQL Database 활성 지역 복제를 참조하세요.

  • 쿼리의 경우 보조 복제본에서 읽습니다.
  • 삽입 및 업데이트의 경우 수동으로 보조 복제본으로 장애 조치합니다. Azure SQL Database에 대해 계획되거나 계획되지 않은 장애 조치(failover) 시작을 참조하세요.

  복제본은 다른 연결 문자열을 사용하므로 애플리케이션에서 연결 문자열을 업데이트해야 합니다.

클라이언트가 연결 풀에서 연결이 고갈되었습니다.

탐지. System.InvalidOperationException 오류를 포착합니다.

복구:

• 작업을 다시 시도하세요.
• 완화 계획으로, 각 사용 사례에 대한 연결 풀을 격리하여 하나의 사용 사례에서 모든 연결을 점유할 수 없도록 합니다.
• 최대 연결 풀 수를 늘립니다.

진단. 애플리케이션 로그.

데이터베이스 연결 제한에 도달했습니다.

탐지. Azure SQL Database는 동시 작업자, 로그인 및 세션의 수를 제한합니다. 이 제한은 서비스 계층에 따라 다릅니다. 자세한 내용은 Azure SQL Database 리소스 제한을 참조하세요.

이러한 오류를 감지하기 위해서는 System.Data.SqlClient.SqlException을 catch하고, SQL 오류 코드에서 SqlException.Number 값이 맞는지 확인하세요. 관련 오류 코드 목록은 SQL Database 클라이언트 애플리케이션의 SQL 오류 코드: 데이터베이스 연결 오류 및 기타 문제를 참조하세요.

복구. 이러한 오류는 일시적인 것으로 간주되므로 다시 시도하면 문제가 해결될 수 있습니다. 이러한 오류가 지속적으로 발생하면 데이터베이스 크기를 조정하는 것이 좋습니다.

진단. sys.event_log 쿼리에서 성공적인 데이터베이스 연결, 연결 실패 및 교착 상태를 반환합니다.

• 실패한 연결에 대한 경고 규칙을 만듭니다.
• SQL Database 감사를 사용하도록 설정하고 실패한 로그인을 확인합니다.

서비스 버스 메시징

Service Bus 큐에서 메시지를 읽는 작업이 실패합니다.

탐지. 클라이언트 SDK에서 예외를 처리합니다. Service Bus 예외에 대한 기본 클래스는 MessagingException입니다. 일시적인 오류인 경우 IsTransient 속성이 true입니다.

자세한 내용은 Service Bus 메시징 예외를 참조하세요.

복구:

1. 일시적 장애 시 다시 시도합니다.
2. 받는 사람에게 배달할 수 없는 메시지는 배달 못 한 편지 큐에 넣습니다. 이 큐를 사용하여 수신할 수 없는 메시지를 확인합니다. 배달 못한 편지 큐의 자동 정리는 없습니다. 메시지는 명시적으로 검색할 때까지 남아 있습니다. Service Bus 데드레터 큐의 개요를 참조하세요.

Service Bus 큐에 메시지를 쓰는 작업이 실패합니다.

탐지. 클라이언트 SDK에서 예외를 처리합니다. Service Bus 예외에 대한 기본 클래스는 MessagingException입니다. 일시적인 오류인 경우 IsTransient 속성이 true입니다.

자세한 내용은 Service Bus 메시징 예외를 참조하세요.

복구:

• 일시적인 오류 후에 Service Bus 클라이언트에서 자동으로 다시 시도합니다. 기본적으로 지수 백오프 방식을 사용합니다. 최대 재시도 횟수 또는 최대 제한 시간이 초과되면 클라이언트에서 예외가 발생합니다.

• 큐 할당량이 초과되면 클라이언트에서 QuotaExceededException을 throw합니다. 예외 메시지에서 자세한 정보를 제공합니다. 다시 시도하기 전에 큐에서 일부 메시지를 배출하고, 회로 차단기 패턴을 사용하여 할당량이 초과되는 동안 계속 다시 시도하지 않도록 방지하는 것이 좋습니다. 또한 BrokeredMessage.TimeToLive 속성이 너무 높게 설정되지 않았는지 확인합니다.

• 지역 내에서 분할된 큐 또는 토픽을 사용하여 복원력을 향상시킬 수 있습니다. 분할되지 않은 큐나 항목은 하나의 메시징 저장소에 할당됩니다. 이 메시지 저장소를 사용할 수 없게 되면 해당 큐 또는 항목의 모든 작업이 실패하게 됩니다. 분할된 큐 또는 토픽은 여러 메시지 저장소로 분할됩니다.

• 영역 중복을 사용하여 여러 가용성 영역 간의 변경 내용을 자동으로 복제합니다. 하나의 가용성 영역이 실패하면 장애 조치(failover)가 자동으로 수행됩니다. 자세한 내용은 Service Bus 가동 중단 및 재해로부터 애플리케이션을 보호하기 위한 모범 사례를 참조하세요.

• 다중 지역 솔루션을 디자인하는 경우 서로 다른 지역에 두 개의 Service Bus 네임스페이스를 만들고 메시지를 복제합니다. 활성 복제 또는 수동 복제를 사용할 수 있습니다.

  • 활성 복제: 클라이언트에서 모든 메시지를 두 큐로 보냅니다. 수신기는 두 대기열 모두에서 수신 대기합니다. 고유 식별자를 사용하여 메시지에 태그를 지정하면 클라이언트에서 중복 메시지를 버릴 수 있습니다.
  • 수동 복제: 클라이언트에서 하나의 큐에 메시지를 보냅니다. 오류가 발생하면 클라이언트는 다른 큐로 대체됩니다. 수신기는 두 대기열 모두에서 수신 대기합니다. 이 방식은 전송되는 중복 메시지의 수를 줄입니다. 그러나 여전히 수신기에서 중복 메시지를 처리해야 합니다.

  자세한 내용은 GeoReplication 샘플 및 Service Bus 가동 중단 및 재해로부터 애플리케이션을 보호하기 위한 모범 사례를 참조하세요.

메시지가 중복되었습니다.

탐지. 메시지의 MessageId 및 DeliveryCount 속성을 검사합니다.

복구:

• 가능한 경우, 메시지 처리 작업이 반복 실행되어도 결과가 변하지 않도록 설계합니다. 그렇지 않으면 이미 처리된 메시지의 메시지 ID를 저장하고, 메시지를 처리하기 전에 이 ID를 확인합니다.

• RequiresDuplicateDetection을(를) true로 설정하여 큐를 생성하고 중복 검색을 활성화합니다. 이 설정을 사용하면 Service Bus에서 이전 메시지와 동일한 MessageId로 보낸 모든 메시지를 자동으로 삭제합니다. 다음 사항에 유의하세요.

  • 이 설정은 중복 메시지를 큐에 넣지 않도록 방지합니다. 수신기에서 동일한 메시지를 두 번 이상 처리하지 않도록 방지합니다.
  • 중복 검색에는 시간 창이 있습니다. 중복 메시지가 이 기간을 초과하여 전송되면 검색되지 않습니다.

진단. 중복 메시지를 기록합니다.

애플리케이션에서 큐의 특정 메시지를 처리할 수 없습니다.

탐지. 애플리케이션 특정입니다. 예를 들어 메시지에 유효하지 않은 데이터가 있거나 비즈니스 논리가 어떤 이유로 실패합니다.

복구:

고려해야 할 두 가지 장애 모드가 있습니다.

• 수신기에서 장애를 검색합니다. 이 경우, 메시지를 데드레터 큐로 이동합니다. 나중에 데드레터 큐의 메시지를 검사하기 위해 별도의 프로세스를 실행합니다.
• 예를 들어 처리되지 않은 예외로 인해 수신기가 메시지를 처리하는 중에 실패합니다. 이 경우를 처리하려면 PeekLock 모드를 사용합니다. 이 모드에서는 잠금이 만료되는 경우 다른 수신기에서 메시지를 사용할 수 있게 됩니다. 메시지가 최대 배달 횟수 또는 TTL(Time to Live)을 초과하면 메시지는 자동으로 배달 못 한 편지 큐로 이동됩니다.

자세한 내용은 Service Bus 데드-레터 큐 개요를 참조하세요.

진단. 애플리케이션에서 메시지를 데드레터 큐로 이동할 때마다 애플리케이션 로그에 이벤트를 기록합니다.

스토리지

Azure Storage에 데이터를 쓰는 작업이 실패합니다.

탐지. 쓰기 작업 중에 클라이언트에서 오류를 받습니다.

복구:

1. 작업을 다시 시도하여 일시적인 장애로부터 복구합니다. 클라이언트 SDK의 다시 시도 정책에서 이 작업을 자동으로 처리합니다.

2. 스토리지의 과부하를 방지하도록 회로 차단기 패턴을 구현합니다.

3. N번 다시 시도했지만 실패할 경우, 원활한 대체를 수행합니다. 예를 들면 다음과 같습니다.

   • 로컬 캐시에 데이터를 저장하고, 나중에 서비스를 사용할 수 있게 되면 스토리지에 쓰기를 전달합니다.
   • 쓰기 작업이 트랜잭션 범위에 있는 경우 트랜잭션을 보정합니다.

진단. 스토리지 메트릭을 사용합니다.

Azure Storage에서 데이터를 읽는 작업이 실패합니다.

탐지. 읽기 작업 중에 클라이언트에서 오류를 받습니다.

복구:

1. 작업을 다시 시도하여 일시적인 장애로부터 복구합니다. 클라이언트 SDK의 다시 시도 정책에서 이 작업을 자동으로 처리합니다.
2. RA-GRS 스토리지의 경우 기본 엔드포인트에서 읽기 작업이 실패하면 보조 엔드포인트에서 읽기 작업을 시도합니다. 클라이언트 SDK에서 이 작업을 자동으로 처리할 수 있습니다. Azure Storage 복제를 참조하세요.
3. N회의 재시도가 실패하면 대체 작업을 수행하여 순조롭게 성능을 저하시킵니다. 예를 들어 제품 이미지를 스토리지에서 검색할 수 없는 경우 일반적인 자리 표시자 이미지가 표시됩니다.

진단. 스토리지 메트릭을 사용합니다.

가상 머신

백 엔드 VM에 대한 연결이 실패합니다.

탐지. 네트워크 연결 오류입니다.

복구:

• 부하 분산 장치 뒤에 있는 가용성 집합에 둘 이상의 백 엔드 VM을 배포합니다.
• 일시적인 연결 오류이면 TCP에서 메시지 전송을 성공적으로 다시 시도하는 경우가 있습니다.
• 애플리케이션에서 다시 시도 정책을 구현합니다.
• 영구 오류 또는 일시적이지 않은 오류의 경우 회로 차단기 패턴을 구현합니다.
• 호출하는 VM에서 네트워크 송신 제한을 초과하면 아웃바운드 큐가 채워집니다. 아웃바운드 큐가 항상 가득 차 있다면 확장을 고려해보세요.

진단. 서비스 경계에서 이벤트를 로깅합니다.

VM 인스턴스가 사용할 수 없거나 비정상적인 상태가 됩니다.

탐지. VM 인스턴스가 정상인지 여부를 나타내는 Load Balancer 상태 프로브를 구성합니다. 프로브를 통해 중요한 기능이 올바르게 응답하는지 여부를 확인해야 합니다.

복구. 각 애플리케이션 계층에 대해 여러 VM 인스턴스를 동일한 가용성 집합에 배치하고, VM 앞에 Load Balancer를 배치합니다. 상태 프로브가 실패하면 Load Balancer에서 비정상 인스턴스에 대한 새 연결 전송을 중지합니다.

진단. Load Balancer 로그 분석을 사용합니다.

• 모든 상태 모니터링 엔드포인트를 모니터링하도록 모니터링 시스템을 구성합니다.

운영자가 실수로 VM을 종료합니다.

탐지. 해당 없음

복구. ReadOnly 수준의 리소스 잠금을 설정합니다. Azure Resource Manager를 사용하여 리소스 잠그기를 참조하세요.

진단. Azure 활동 로그를 사용합니다.

다음 단계

Azure Well-Architected Framework에서 의존성 식별을 참조하세요. 시스템에 오류 복구를 빌드하는 것은 실패의 위험을 피하기 위해 처음부터 아키텍처 및 디자인 단계에 포함되어야 합니다.