Azure IoT Hub의 안정성

이 문서에서는 Azure IoT Hub의 안정성 지원에 대해 설명합니다. 가용성 영역 및 다중 지역 배포를 통해 지역 내 복원력을 다룹니다.

안정성은 사용자와 Microsoft 간의 공동 책임입니다. 이 가이드를 사용하여 특정 비즈니스 목표 및 가동 시간 목표를 충족하는 안정성 옵션을 결정할 수 있습니다.

안정성 옵션을 평가할 때 다음 항목 간의 장차도 평가해야 합니다.

• 필요한 복원력 수준
• 구현 및 유지 관리 복잡성
• 다양한 옵션을 구현하는 비용

자세한 내용은 안정성 절충안을 참조하세요.

일시적인 오류

일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리하는 것이 중요합니다.

모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.

IoT Hub는 합리적으로 높은 가동 시간 보장을 제공하지만 분산 컴퓨팅 플랫폼에서 일시적인 오류가 발생할 수 있습니다. 일시적인 오류를 처리하려면 클라우드 애플리케이션과 상호 작용하는 구성 요소에서 적절한 재시도 패턴을 빌드합니다.

가용성 영역 지원

가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.

IoT Hub는 다음과 같은 두 가지 유형의 가용성 영역 지원을 지원합니다.

• 디바이스 ID 레지스트리 및 디바이스-클라우드 메시지를 저장하는 기본 스토리지 구성 요소에 대한 여러 가용성 영역 간에 데이터를 자동으로 복제하는 데이터의 영역 중복성입니다.

• 컴퓨팅에 대한 영역 중복성- 디바이스 관리 및 메시지 라우팅을 담당하는 구성 요소에서 복원력을 제공합니다.

지역 지원

IoT Hub에 대한 가용성 영역 지원 유형은 배포된 지역에 따라 달라집니다.

지역	데이터의 영역 중복성	컴퓨팅에 대한 영역 중복성
오스트레일리아 동부
브라질 남부
캐나다 중부
인도 중부
미국 중부
미국 동부
프랑스 중부
독일 중서부
일본 동부
한국 중부
북유럽
노르웨이 동부
카타르 중부
미국 중남부
동남아시아
영국 남부
서유럽
미국 서부 2
미국 서부 3

이 목록에 없는 지역에서 만드는 IoT Hub는 영역 중단에 대한 복원력이 없습니다.

비용

IoT Hub를 사용한 영역 중복에 대한 추가 비용은 없습니다.

가용성 영역 지원 구성

IoT Hub 리소스는 지원되는 지역에 배포될 때 영역 중복을 자동으로 지원합니다. 추가 구성은 필요하지 않습니다.

일반 작업

이 섹션에서는 영역 중복을 위해 IoT Hub 리소스가 구성되고 모든 가용성 영역이 작동할 때 예상되는 사항에 대해 설명합니다.

• 영역 간 데이터 복제: 데이터에 대한 영역 중복성을 지원하는 지역에 IoT Hub가 배포되면 가용성 영역 간에 데이터의 변경 내용이 자동으로 복제됩니다. 복제는 동기적으로 발생합니다.

• 영역 간의 트래픽 라우팅: 컴퓨팅 구성 요소에 대한 영역 중복성을 지원하는 지역에 IoT Hub가 배포되면 요청은 가용성 영역 중 하나에 있는 서비스의 기본 인스턴스로 라우팅됩니다. Azure는 활성 인스턴스 및 영역을 자동으로 선택합니다.

영역 축소 경험

이 섹션에서는 영역 중복을 위해 IoT Hub 리소스가 구성되고 가용성 영역 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

• 검색 및 응답: IoT Hub 서비스는 가용성 영역에서 오류를 감지하는 역할을 담당합니다. 영역 장애 조치(failover)를 시작하기 위해 어떤 작업도 수행할 필요가 없습니다.

• 활성 요청: 영역 실패 시 활성 요청이 삭제될 수 있습니다. 클라이언트와 디바이스에는 일시적인 오류를 처리하기 위해 구현된 충분한 재시도 논리 가 있어야 합니다.

• 예상 데이터 손실: 데이터에 대한 영역 중복을 지원하는 지역에 IoT Hub를 배포하는 경우 영역 오류로 인해 데이터가 손실되지 않아야 합니다.

• 예상 가동 중지 시간: 컴퓨팅 및 데이터 구성 요소 모두에 대한 영역 중복을 지원하는 지역에 IoT Hub를 배포하는 경우 영역 오류로 인해 IoT Hub 리소스에 가동 중지 시간이 발생하지 않아야 합니다.

• 트래픽 경로 변경: 컴퓨팅 구성 요소에 대한 영역 중복성을 지원하는 지역에 IoT Hub가 배포되면 IoT Hub는 영역 손실을 감지합니다. 그런 다음 모든 새 요청은 정상 가용성 영역 중 하나에 있는 서비스의 새 기본 인스턴스로 자동으로 리디렉션됩니다.

장애 복구

가용성 영역이 복구되면 IoT Hub는 가용성 영역의 인스턴스를 자동으로 복원하고 인스턴스 간의 트래픽을 정상적으로 다시 라우팅합니다.

영역 오류 테스트

IoT Hub는 영역 오류에 대한 트래픽 라우팅, 장애 조치(failover) 및 장애 복구(failback)를 완벽하게 관리하므로 가용성 영역 오류 프로세스의 유효성을 검사하거나 추가 입력을 제공할 필요가 없습니다.

다중 지역 지원

IoT Hub는 단일 지역 서비스입니다. 지역을 사용할 수 없게 되면 IoT Hub 리소스도 사용할 수 없습니다.

그러나 리소스가 쌍을 이루는 지역에 있는 경우 IoT Hub의 데이터가 쌍을 이루는 지역에 복제됩니다.

다음과 같은 시나리오에서는 IoT 허브가 쌍을 이루는 지역으로 장애 조치(failover)될 수 있습니다.

• 고객이 시작한 장애 조치(failover): 지역에 가동 중지 시간이 발생했는지 여부에 관계없이 쌍을 이루는 지역에 대한 수동 장애 조치(failover)를 직접 트리거할 수 있습니다. 이 방법을 사용하여 계획된 장애 조치(failover) 및 훈련을 수행할 수 있습니다.

• Microsoft에서 시작한 장애 조치(failover): 지역이 손실되면 Microsoft는 쌍을 이루는 지역에 대한 IoT Hub의 장애 조치(failover)를 시작할 수 있습니다. 그러나 상당한 지연 후와 최선의 노력을 기준으로 하는 경우를 제외하고는 Microsoft에서 장애 조치(failover)를 시작할 가능성은 낮습니다. IoT Hub 리소스의 장애 조치(failover)는 다른 Azure 서비스의 장애 조치보다 다른 시간에 발생할 수 있습니다. 이 프로세스는 기본 옵션이며 사용자가 개입할 필요가 없습니다.

리소스가 페어링되지 않은 지역에 있는 경우 Microsoft는 지역 간에 구성 및 데이터를 복제하지 않으며 기본 제공 지역 간 장애 조치(failover)가 없습니다. 그러나 여러 지역에 별도의 리소스를 배포할 수 있습니다. 이 시나리오에서는 복제, 트래픽 배포 및 장애 조치(failover)를 관리해야 합니다.

IoT Hub가 복구되지 않은 지역에 있거나 기본 복제 및 장애 조치(failover) 동작이 요구 사항을 충족하지 않는 경우 대체 다중 지역 접근 방식을 사용하여 장애 조치(failover)를 계획하고 시작할 수 있습니다.

지역 지원

기본 복제 및 장애 복구는 서로 연결된 지역에서만 지원됩니다.

요구 사항

쌍을 이루는 지역 복제 및 장애 조치(failover) 옵션은 모든 IoT Hub 계층에 사용할 수 있습니다.

고려 사항

고객 주도의 장애 조치를 사용하여 Azure의 쌍으로 연결된 지역 간에 허브를 영구적으로 마이그레이션하지 마세요. 일반적으로 디바이스는 허브의 주 지역 가까이에 있습니다. 허브를 보조 지역으로 이동하면 디바이스와 보조 위치의 IoT Hub 간의 작업에 대한 대기 시간이 증가합니다.

비용

쌍을 이루는 지역의 허브의 경우 지역 간 데이터 복제 또는 장애 조치(failover)에 대한 추가 비용이 없습니다.

IoT Hub가 비연결된 지역에 있는 경우, 비용 정보를 알아보려면 대체 다중 지역 방법을 참조하세요.

복제 구성 및 장애 조치 준비

기본적으로 지역 간 데이터 복제는 쌍을 이루는 지역에 IoT Hub를 만들 때 자동으로 구성됩니다. 이 프로세스는 기본 옵션이며 사용자가 개입할 필요가 없습니다. 브라질 남부 및 동남 아시아(싱가포르)를 제외한 지역에서는 고객 데이터가 서비스 인스턴스를 배포하는 지리 외부에 저장되거나 처리되지 않습니다.

IoT Hub가 브라질 남부 또는 싱가포르(동남 아시아) 지역에 있는 경우 데이터 복제를 사용하지 않도록 설정하고 장애 조치(failover)를 옵트아웃할 수 있습니다. 자세한 내용은 DR(재해 복구) 사용 안 함을 참조하세요.

IoT Hub가 페어링되지 않은 지역에 있는 경우 자체 지역 간 복제 및 장애 조치(failover) 방법을 계획해야 합니다. 자세한 내용은 대체 다중 지역 접근 방식을 참조하세요.

일반 작업

이 섹션에서는 지역 간 복제 및 장애 조치(failover)를 위해 IoT Hub가 구성되고 주 지역이 작동할 때 예상되는 사항에 대해 설명합니다.

• 지역 간 데이터 복제: 데이터는 쌍을 이루는 지역에 자동으로 복제됩니다. 복제는 비동기적으로 발생합니다. 따라서 장애 조치 전환이 발생할 경우 일부 데이터 손실이 예상됩니다. 비페어 지역에서 IoT Hub에 대한 지역 간에는 데이터 복제가 없습니다.

• 지역 간 트래픽 라우팅: 정상적인 작업에서 트래픽은 주 지역으로만 흐릅니다.

지역 중단 환경

이 섹션에서는 지역 간 복제 및 장애 조치(failover)를 위해 IoT Hub가 구성되고 주 지역에 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

• 검색 및 응답: 주 지역의 중단을 감지하고 대응하는 책임은 다를 수 있습니다.

  • 고객 주도 장애 조치: 지역 손실을 감지하고, 언제 장애 조치를 수행할지 결정하는 역할을 맡고 있습니다. 쌍을 이루는 지역 간에 고객이 시작한 장애 조치(failover)를 수행하는 방법에 대한 자세한 내용은 IoT Hub에 대한 수동 장애 조치(failover) 수행을 참조하세요.

    고객이 시작한 장애 조치(failover) 또는 장애 복구(failback)를 수행할 수 있는 빈도에는 제한이 있습니다.

    • 사용자는 하루에 두 번의 성공적인 장애 조치(failover) 작업과 두 번의 성공적인 장애 복구 작업을 수행할 수 있습니다.

    • 연속적인 장애 조치(failover) 또는 장애 복구(failback) 작업은 허용되지 않습니다. 이러한 작업 사이에 1시간 동안 기다려야 합니다.

  • Microsoft에서 시작한 장애 조치(failover): Microsoft는 주 지역이 손실된 경우 장애 조치(failover)를 수행할 수 있습니다. 이 프로세스는 주 지역이 손실된 후 몇 시간 또는 일부 시나리오에서 더 오래 걸릴 수 있습니다. IoT Hub 리소스의 장애 조치(failover)는 다른 Azure 서비스와 동시에 발생하지 않을 수 있습니다.

• 활성 요청: 장애 조치(failover) 중에 주 지역이 처리 중인 모든 요청은 손실될 수 있습니다. 클라이언트는 장애 조치(failover)가 완료된 후 요청을 다시 시도해야 합니다.

• 예상 데이터 손실: 쌍을 이루는 지역의 경우 데이터는 쌍을 이루는 지역에 비동기적으로 복제됩니다. 따라서 장애 전환 후 일부 데이터 손실이 예상됩니다. 이 프로세스는 Microsoft 관리 및 고객 관리 장애 조치에 모두 적용됩니다. 다음 표에서는 IoT Hub가 저장하는 각 데이터 형식의 RPO(복구 지점 목표) 또는 예상 데이터 손실에 대해 간략하게 설명합니다.

  데이터 형식	리쿠르트먼트 프로세스 아웃소싱 (RPO)
  ID 레지스트리	0-5분 데이터 손실
  디바이스 쌍 데이터	0-5분 데이터 손실
  클라우드에서 디바이스로 메시지 1	0-5분 데이터 손실
  부모 1 및 디바이스 작업	0-5분 데이터 손실
  기기에서 클라우드로의 메시지	읽지 않은 메시지가 모두 손실됨
  클라우드-디바이스 피드백 메시지	읽지 않은 메시지가 모두 손실됨

  ¹ 클라우드에서 디바이스로 보내는 메시지와 상위 작업은 고객이 시작한 장애 조치 전환의 일부로 복구되지 않습니다.

• 예상 가동 중지 시간: 지역 장애 조치(failover) 중에 예상되는 가동 중지 시간은 장애 조치 유형에 따라 달라집니다.

  • 고객이 시작한 장애 조치: 지역이 손실된 시점부터 쌍을 이루는 지역에서 리소스가 작동할 때까지 약 10분에서 2시간의 다운타임을 예상합니다. 장애 조치(failover)되는 IoT Hub 인스턴스에 대해 등록된 디바이스의 수는 복구 시간에 영향을 줍니다. 약 100,000개의 디바이스를 호스트하는 허브의 복구 시간은 약 15분이 될 것으로 예상할 수 있습니다.

  • Microsoft에서 시작한 장애 조치(failover): 지역이 손실된 시점부터 쌍을 이루는 지역에서 리소스를 사용할 수 있는 시점까지 약 2~26시간의 가동 중지 시간이 예상됩니다.

    복구 시간이 긴 이유는 Microsoft가 해당 지역의 영향을 받는 모든 고객을 대신하여 장애 조치 작업을 수행해야 하기 때문입니다. 중요한 시스템의 경우 고객이 시작한 장애 조치(failover)를 사용하여 가동 중지 시간을 줄여야 합니다. 그러나 약 하루의 가동 중지 시간을 유지할 수 있는 덜 중요한 IoT 솔루션을 실행하는 경우 Microsoft 시작 옵션에 종속되어 IoT 솔루션의 전체 DR 목표를 충족할 수 있습니다.

  • 두 장애 조치(failover) 형식의 경우 장애 조치(failover) 후 IoT Hub 인스턴스의 정규화된 도메인 이름이 동일하게 유지되므로 연결 문자열도 동일하게 유지됩니다. 그러나 기본 IP 주소가 변경되므로 클라이언트는 장애 조치(failover) 후 IoT Hub에 액세스하기 전에 DNS(Domain Name System) 레코드가 업데이트되기를 기다려야 합니다.

    중요합니다

    IoT Hub SDK는 IoT Hub의 IP 주소를 캐시하지 않습니다. SDK와 상호 작용하는 사용자 코드는 IoT Hub의 IP 주소를 캐시해서는 안 됩니다.

    이러한 요인으로 인해 다음 함수를 사용하여 장애 조치(failover) 프로세스를 수행한 후 IoT Hub 인스턴스에 대해 수행되는 런타임 작업이 완전히 작동하는 시간을 표현할 수 있습니다.

    복구 시간 = RTO [고객이 시작한 장애 조치(failover)의 경우 10분에서 2시간, Microsoft 시작 장애 조치(failover)의 경우 2~26시간] + DNS 전파 지연 + 클라이언트 애플리케이션이 캐시된 IoT Hub IP 주소를 새로 고치는 데 걸리는 시간

• 트래픽 경로 변경: 장애 조치(failover) 프로세스 중에 IoT Hub는 DNS 레코드를 업데이트하여 쌍을 이루는 지역을 가리킵니다. 모든 후속 요청은 쌍을 이루는 지역으로 전송됩니다.

  IoT Hub에 대한 장애 조치(failover) 작업이 완료되면 디바이스 및 백 엔드 애플리케이션의 모든 작업이 수동 개입 없이 계속 작동해야 합니다. 이러한 연속성을 통해 디바이스-클라우드 메시지가 계속 작동하고 전체 디바이스 레지스트리가 그대로 유지됩니다. Azure Event Grid를 통해 이벤트를 내보내는 경우 Event Grid 구독을 계속 사용할 수 있는 한 이전에 구성한 것과 동일한 구독을 통해 이벤트를 사용할 수 있습니다. 사용자 지정 엔드포인트에는 더 이상 처리가 필요하지 않습니다.

장애 조치(failover) 후 구성 필요

IoT Hub의 메시지를 라우팅하는 위치에 따라 장애 조치(failover)가 완료된 후 추가 단계를 수행해야 할 수 있습니다.

• Azure Event Hubs: 장애 조치(failover) 후 IoT Hub의 기본 제공 이벤트 엔드포인트 변경에 대한 Event Hubs 호환 이름 및 엔드포인트입니다. 이 변경은 Event Hubs 클라이언트에 IoT Hub 이벤트에 대한 가시성이 없기 때문에 발생합니다.

  Event Hubs 클라이언트 또는 이벤트 프로세서 호스트를 사용하여 기본 제공 엔드포인트에서 원격 분석 메시지를 수신하는 경우 IoT Hub의 연결 문자열을 사용하여 연결을 설정합니다. 이 방법을 사용하면 장애 조치(failover) 후 수동 개입 없이 백 엔드 애플리케이션이 계속 작동합니다.

  애플리케이션에서 Event Hubs 호환 이름 및 엔드포인트를 직접 사용하는 경우 작업을 계속하려면 장애 조치(failover) 후 새 Event Hubs 호환 엔드포인트를 가져와 야 합니다. 엔드포인트 및 이름을 검색하려면 Azure Portal 또는 .NET SDK를 사용할 수 있습니다.

  • Azure Portal: 포털을 사용하여 Event Hubs 호환 엔드포인트 및 Event Hubs 호환 이름을 검색하는 방법에 대한 자세한 내용은 기본 제공 엔드포인트에 연결을 참조하세요.

  • .NET SDK: IoT Hub 연결 문자열을 사용하여 Event Hubs 호환 엔드포인트를 다시 캡처하려면 샘플 코드를 사용합니다. 이 코드 예제에서는 연결 문자열을 사용하여 새 Event Hubs 엔드포인트를 가져와 연결을 다시 설정합니다. Visual Studio가 설치되어 있어야 합니다.

• Azure Functions 및 Azure Stream Analytics: Azure Functions 또는 Stream Analytics를 사용하여 기본 제공 이벤트 엔드포인트에 연결하는 경우 이전 글머리 기호에 설명된 것과 동일한 프로세스에 따라 함수 또는 작업이 연결하는 Event Hubs 엔드포인트를 업데이트해야 합니다. 그런 다음, 장애 조치(failover) 후 이벤트 스트림 오프셋이 유효하지 않으므로 다시 시작 작업을 수행합니다.

• Azure Storage: Azure Storage로 라우팅할 때 Blob 또는 파일을 먼저 나열합니다. 그런 다음, 분할을 가정하지 않고 모든 Blob 또는 파일을 읽도록 반복합니다. 파티션 범위는 Microsoft에서 시작한 장애 조치(failover) 또는 고객이 시작한 장애 조치(failover) 중에 변경될 수 있습니다. Blob 나열 API를 사용하여 Blob 목록을 열거하거나 Azure Data Lake Storage 나열 API를 사용하여 파일 목록을 열거할 수 있습니다. 자세한 내용은 Azure Storage를 라우팅 엔드포인트로 참조하세요.

장애 복구

주 지역으로 장애 복구하려면 장애 조치(failover) 작업을 수동으로 두 번째로 트리거할 수 있습니다. 장애 조치(failover) 빈도에 대한 제한을 기억해야 합니다.

원래 장애 조치(failover) 작업이 원래 주 지역에서 장기간의 중단으로부터 복구하기 위해 수행된 경우, 주 지역이 중단에서 복구된 후 주 지역으로 장애 복구를 수행합니다.

지역 오류 테스트

지역 중단 시 오류를 시뮬레이션하려면 IoT Hub의 수동 장애 조치(페일오버)를 트리거할 수 있습니다. 그러나 지역 장애 조치(failover)로 인해 가동 중지 시간과 데이터가 모두 손실되므로 비프로덕션 환경에서만 테스트 장애 조치(failover)를 수행해야 합니다. 자세한 내용은 지역 하향 경험을 참조하세요. 계획된 장애 조치(failover) 옵션을 주기적으로 시작하도록 테스트 IoT Hub 인스턴스를 설정하는 것이 좋습니다. 정기적인 테스트를 통해 실제 재해가 발생할 때 엔드 투 엔드 솔루션을 효과적으로 복원하고 운영하는 기능에 대한 신뢰를 구축할 수 있습니다.

대체 다중 지역 접근 방식

IoT Hub의 지역 간 장애 조치 기능은 다음 시나리오에 적합하지 않습니다.

• 당신의 IoT 허브는 페어링되지 않은 지역에 있습니다.

• 기본 제공 장애 조치(failover) 옵션이 제공하는 복구 시간 또는 데이터 손실로 인해 비즈니스 가동 시간 목표가 충족되지 않습니다.

• 주 지역의 쌍이 아닌 지역으로 장애 조치(failover)를 취해야 합니다.

각 개별 디바이스에 맞게 조정된 지역 간 장애 조치(failover) 솔루션을 디자인할 수 있습니다. IoT 솔루션에서 배포 토폴로지의 전체 처리는 이 문서의 범위를 벗어나지만 다중 지역 배포 모델을 고려할 수 있습니다. 이 모델에서 기본 IoT 허브 및 솔루션 백 엔드는 주로 한 Azure 지역에서 실행됩니다. 보조 IoT Hub 및 백 엔드는 다른 Azure 지역에 배포됩니다. 주 지역의 IoT Hub에서 중단이 발생하거나 디바이스에서 주 지역으로의 네트워크 연결이 중단되면 디바이스는 보조 서비스 엔드포인트를 사용합니다.

• 예상 가동 중지 시간: 이 방법은 가동 중지 시간이 1분 미만이지만 구현이 복잡할 수 있습니다.

• 예상 데이터 손실: 데이터 손실의 양은 사용하는 특정 데이터 저장소 및 데이터 저장소 간에 지역에서 복제를 구성하는 방법에 따라 달라집니다.

• 비용: 이 방법을 사용하려면 하나 이상의 추가 IoT Hub를 프로비전해야 하므로 전체 비용이 증가합니다.

상위 수준에서 IoT Hub를 사용하여 지역 장애 조치(failover) 모델을 구현하려면 다음 조치를 취해야 합니다.

• 보조 IoT 허브 및 디바이스 라우팅 논리: 주 지역의 서비스가 중단된 경우 디바이스는 보조 지역에 연결하기 시작해야 합니다. 관련된 대부분의 서비스의 상태 인식 특성으로 인해 솔루션 관리자는 일반적으로 지역 간 장애 조치(failover) 프로세스를 수동으로 트리거합니다. 프로세스를 제어하면서 디바이스에 새 엔드포인트를 전달하는 가장 좋은 방법은 현재 활성 엔드포인트에 대한 컨시어지 서비스를 정기적으로 확인하는 것입니다. 컨시어지 서비스는 Azure Traffic Manager와 같은 DNS 리디렉션 기술을 사용하여 복제되고 계속 연결할 수 있는 웹 애플리케이션일 수 있습니다.

  비고

  Traffic Manager에는 IoT Hub에 대한 기본 제공 지원이 없습니다. 각 IoT Hub에 대한 사용자 지정 Traffic Manager 엔드포인트를 구성할 수 있습니다. IoT Hub의 엔드포인트를 사용하도록 Traffic Manager 엔드포인트의 상태 프로브를 구성합니다.

• ID 레지스트리 복제: 사용 가능하려면 보조 IoT Hub에 솔루션에 연결할 수 있는 모든 디바이스 ID가 포함되어야 합니다. 솔루션은 디바이스 ID의 지역 복제 백업을 유지하고 디바이스에 대한 활성 엔드포인트를 전환하기 전에 보조 IoT Hub에 업로드해야 합니다. 이 경우 IoT Hub의 디바이스 ID 내보내기 기능은 유용합니다. 자세한 내용은 IoT 허브의 ID 레지스트리 이해를 참조하세요.

• 병합 논리: 주 지역을 다시 사용할 수 있게 되면 보조 지역에서 만든 모든 상태 및 데이터를 주 지역으로 다시 마이그레이션해야 합니다. 이러한 상태 및 데이터는 주로 디바이스 ID 및 애플리케이션 메타데이터와 관련되며 기본 IoT Hub 및 주 지역의 기타 가능한 애플리케이션별 스토리지에 병합되어야 합니다.

  이 단계를 간소화하려면 멱등 연산을 사용합니다. 멱등 연산은 최후의 일관적인 이벤트 배포 및 중복되거나 비순차적인 이벤트 배달로 인한 부작용을 최소화합니다. 또한 애플리케이션 논리는 잠재적인 불일치 또는 약간 오래된 상태를 허용하도록 설계되어야 합니다. 이 시나리오는 시스템이 RPO를 기반으로 치유하는 데 걸리는 추가 시간 때문에 발생할 수 있습니다.

백업

대부분의 솔루션의 경우 백업에만 의존해서는 안 됩니다. 대신 이 가이드에 설명된 다른 기능을 사용하여 복원력 요구 사항을 지원합니다. 그러나 백업은 다른 방법이 사용하지 않는 일부 위험으로부터 보호합니다. 자세한 내용은 중복성, 복제 및 백업을 참조하세요.

IoT Hub 서비스를 사용하면 대량 내보내기 작업을 수행할 수 있으므로 IoT Hub의 전체 ID 레지스트리를 내보낼 수 있습니다. 이 데이터는 공유 액세스 서명을 사용하여 Azure Storage Blob 컨테이너로 전송됩니다. 이 메서드를 사용하면 사용자가 제어하는 blob 컨테이너에 디바이스 정보의 신뢰할 수 있는 백업을 만들 수 있습니다. 자세한 내용은 IoT Hub 디바이스 ID를 대량으로 가져오고 내보내는 것을 참조하세요.

기존 IoT Hub의 ARM 템플릿(Azure Resource Manager 템플릿)을 내보내 IoT Hub 구성의 백업을 만들 수도 있습니다. 자세한 내용은 ARM 템플릿을 사용하여 IoT Hub 수동 마이그레이션을 참조하세요.

서비스 수준 약정

IoT Hub에 대한 SLA(서비스 수준 계약)는 서비스의 예상 가용성 및 해당 가용성 기대치를 달성하기 위해 충족해야 하는 조건을 설명합니다. 이러한 조건을 이해하려면 온라인 서비스에 대한 SLA를 검토하는 것이 중요합니다.

관련 콘텐츠

• Azure의 안정성
• IoT 솔루션 확장성, 고가용성 및 DR