IoT Hub 디바이스 다시 프로비전 개념
IoT 솔루션의 수명 주기 동안 IoT Hub 간에 디바이스를 이동하는 것이 일반적입니다. 이러한 이동의 이유에는 다음과 같은 시나리오가 포함될 수 있습니다.
지리적 위치/지리적 대기 시간: 여러 위치 간에 디바이스를 이동함으로써 디바이스가 더 가까운 IoT Hub로 마이그레이션되면 네트워크 대기 시간이 짧아집니다.
다중 테넌트: 디바이스 하나를 같은 IoT 솔루션 내에서 사용하고 새 고객 또는 고객 사이트에 다시 할당할 수 있습니다. 이러한 새 고객은 별도의 IoT 허브를 사용하여 서비스를 제공받을 수 있습니다.
솔루션 변경: 디바이스는 새롭거나 업데이트된 IoT 솔루션으로 이동할 수 있습니다. 이와 같이 디바이스를 다시 할당할 때는 디바이스가 다른 백 엔드 구성 요소에 연결된 새 IoT Hub와 통신해야 할 수 있습니다.
격리: 솔루션 변경과 비슷합니다. 제대로 작동하지 않거나 손상되었거나 오래된 디바이스는 IoT Hub에 다시 할당할 수 있습니다. IoT Hub에서는 이러한 모든 디바이스를 업데이트하여 규정 준수 상태로 다시 되돌릴 수 있습니다. 디바이스가 정상적으로 작동하면 해당 주 허브로 다시 마이그레이션됩니다.
Device Provisioning Service 내에서는 다시 프로비전이 지원되므로 이러한 요구를 충족할 수 있습니다. 디바이스의 등록 항목에 구성된 다시 프로비전 정책에 따라 새 IoT Hub에 디바이스를 자동으로 다시 할당할 수 있습니다.
디바이스 상태 데이터
디바이스 상태 데이터는 디바이스 쌍 및 디바이스 기능으로 구성됩니다. 이 데이터는 디바이스가 할당된 IoT Hub 및 Device Provisioning Service 인스턴스에 저장됩니다.
Device Provisioning Service 인스턴스를 사용하여 디바이스를 처음 프로비전하면 다음 단계가 수행됩니다.
디바이스에서 Device Provisioning Service 인스턴스에 프로비전 요청을 보냅니다. 서비스 인스턴스는 등록 항목을 기준으로 하여 디바이스 ID를 인증하고 디바이스 상태 데이터의 초기 구성을 만듭니다. 서비스 인스턴스는 등록 구성을 기준으로 IoT Hub에 디바이스를 할당하고 해당 IoT Hub 할당을 디바이스에 반환합니다.
Provisioning Service 인스턴스에서 초기 디바이스 상태 데이터의 복사본을 할당된 IoT Hub에 제공합니다. 디바이스가 할당된 IoT Hub에 연결하여 작업을 시작합니다.
시간이 지남에 따라 디바이스 작업 및 백 엔드 작업에 의해 IoT Hub의 디바이스 상태 데이터가 업데이트될 수 있습니다. Device Provisioning Service 인스턴스에 저장된 초기 디바이스 상태 정보는 그대로 보존됩니다. 그대로 보존된 이 디바이스 상태 데이터는 초기 구성입니다.
시나리오에 따라서는 디바이스를 IoT Hub 간에 이동할 때 이전 IoT Hub에서 업데이트된 디바이스 상태도 새 IoT Hub로 마이그레이션해야 할 수 있습니다. Device Provisioning Service의 다시 프로비전 정책은 이러한 마이그레이션을 지원합니다.
다시 프로비전 정책
시나리오에 따라 디바이스는 다시 부팅 시 프로비전 서비스 인스턴스에 요청을 보낼 수 있습니다. 또한 요청 시 수동으로 프로비전을 트리거하는 메서드를 지원합니다. 등록 항목에 대한 다시 프로비전 정책은 디바이스 프로비저닝 서비스 인스턴스에서 이러한 프로비전 요청을 처리하는 방식을 결정합니다. 또한 프로비전 중에 디바이스 상태 데이터를 마이그레이션해야 하는지 여부를 결정합니다. 개별 등록 및 등록 그룹에 대해 동일하ㄴ 정책을 사용할 수 있습니다.
다시 프로비전하고 데이터 마이그레이션: 새 등록 항목의 기본 정책입니다. 이 정책은 등록 항목과 연결된 디바이스가 새 요청을 제출(1)하면 작업을 수행합니다. 등록 항목 구성에 따라 디바이스가 다른 IoT 허브에 다시 할당될 수 있습니다. 디바이스에서 IoT 허브가 변경되면 초기 IoT 허브에 대한 디바이스 등록이 제거됩니다. 그러면 초기 IoT Hub에서 업데이트된 디바이스 상태 정보는 새 IoT Hub로 마이그레이션됩니다(2). 마이그레이션 중에는 디바이스가 할당 중으로 보고됩니다.
다시 프로비전 및 초기 구성으로 다시 설정: 이 정책은 등록 항목과 연결된 디바이스에서 새 프로비전 요청을 제출하면 작업을 수행합니다 (1). 등록 항목 구성에 따라 디바이스가 다른 IoT 허브에 다시 할당될 수 있습니다. 디바이스에서 IoT 허브가 변경되면 초기 IoT 허브에 대한 디바이스 등록이 제거됩니다. 디바이스를 프로비전할 때 Provisioning Service 인스턴스가 받은 초기 구성 데이터가 새 IoT Hub에 제공됩니다(2). 마이그레이션 중에는 디바이스가 할당 중으로 보고됩니다.
이 정책은 IoT Hub를 변경하지 않는 초기화에 사용되는 경우가 많습니다.
다시 프로비전 안 함: 디바이스가 다른 허브에 다시 할당되지 않습니다. 이 정책은 이전 버전과 호환성을 관리하기 위한 용도로 제공됩니다.
참고 항목
DPS는 디바이스에 대한 새 ReturnData가 있는 경우 재프로비저닝 정책에 관계 없이 항상 사용자 지정 할당 웹후크를 호출합니다. 다시 프로비전 정책이 다시 프로비전 안 함으로 설정된 경우 웹후크가 호출되지만 디바이스는 할당된 허브를 변경하지 않습니다.
솔루션을 설계하고 다시 프로비전 논리를 정의할 때 고려해야 할 몇 가지 사항이 있습니다. 예시:
- 디바이스가 다시 시작될 것으로 예상되는 빈도
- DPS 할당량 및 한도
- 집합에 대한 예상 배포 시간(단계적 롤아웃과 한 번에 모두 비교)
- Azure 아키텍처 센터의 다시 시도 일반 지침에 설명된 대로 클라이언트 코드에 구현된 다시 시도 기능
팁
한 번에 수천 또는 수백만 대의 디바이스를 다시 프로비전할 때 일부 문제가 발생할 수 있으므로 디바이스를 다시 부팅할 때마다 프로비전하지 않는 것이 좋습니다. 대신 Device Registration Status Lookup API를 사용하고 해당 정보를 IoT Hub에 연결해야 합니다. 실패하면 IoT Hub 정보가 변경되었을 수 있으므로 다시 프로비전을 시도합니다. 등록 상태를 쿼리하면 새 디바이스 등록으로 간주되므로 디바이스 등록 한도를 고려해야 합니다. 또한 다시 시도 일반 지침에 설명된 대로 임의 추출을 사용한 지수 백오프와 같은 적절한 다시 시도 논리 구현을 고려합니다. 경우에 따라 디바이스 기능에 따라 DPS를 사용한 최초 프로비전이 발생한 후 IoT Hub에 직접 연결하기 위해 디바이스에 직접 IoT Hub 정보를 저장할 수 있습니다. 이렇게 하려면 허브에서 특정 오류가 발생하는 경우 대체 메커니즘을 구현해야 합니다. 예를 들어 다음 시나리오를 고려하세요.
- 결과 코드가 429(너무 많은 요청)이거나 5xx 범위의 오류인 경우 허브 작업을 다시 시도하세요. 다른 오류의 경우에는 재시도하지 마세요.
- 429 오류의 경우 Retry-After 헤더에 표시된 시간 이후에만 다시 시도합니다.
- 5xx 오류의 경우 응답 후 최소 5초 후에 첫 번째 다시 시도와 함께 지수 백오프를 사용합니다.
- 429 및 5xx 이외의 오류의 경우 DPS를 통해 다시 등록합니다.
- 이상적으로는 요청 시 수동으로 프로비전을 트리거하는 메서드도 지원해야 합니다.
또한 업데이트를 집합에 푸시하는 등의 활동을 계획할 때 서비스 한도를 고려해 두는 것이 좋습니다. 예를 들어 플릿을 한꺼번에 업데이트하면 모든 디바이스가 DPS를 통해 다시 등록될 수 있습니다(등록 할당량 한도를 쉽게 초과할 수 있음). 이러한 시나리오의 경우 전체 플릿을 동시에 업데이트하는 대신 단계적으로 디바이스 업데이트를 계획하는 것이 좋습니다.
이전 버전과의 호환성 관리
2018년 9월 이전에는 IoT Hub에 디바이스를 할당할 때 스티키 동작이 적용되었습니다. 즉, 프로비전 프로세스를 거친 디바이스는 같은 IoT Hub에만 다시 할당되었습니다.
이 동작을 사용했던 솔루션의 경우에는 Provisioning Service에서 이전 버전과의 호환성을 제공합니다. 현재는 다음 기준을 충족하는 디바이스에서 이 동작을 계속 사용할 수 있습니다.
디바이스가 Device Provisioning Service에서 다시 프로비전 지원이 기본적으로 제공되기 전의 API 버전에 연결합니다. API 버전은 아래의 API 표를 참조하세요.
디바이스의 등록 항목에 다시 프로비전 정책이 설정되어 있지 않습니다.
이처럼 이전 버전과의 호환성이 유지되므로 이전에 배포된 디바이스에 초기 테스트 중에 확인된 것과 동일한 동작이 계속 적용됩니다. 이전 동작을 유지하려면 이러한 등록에 다시 프로비전 정책을 저장하지 마세요. 다시 프로비전 정책을 설정하면 해당 정책이 이전 동작보다 우선적으로 적용됩니다. 다시 프로비전 정책이 우선적으로 적용되도록 하는 경우 고객이 디바이스를 이미지로 다시 설치하지 않고도 디바이스 동작을 업데이트할 수 있습니다.
다음 순서도에는 해당 동작이 적용되는 시기가 표시되어 있습니다.
아래 표에는 Device Provisioning Service에서 다시 프로비전 지원이 기본적으로 제공되기 전의 API 버전이 나와 있습니다.
| REST API | C SDK | Python SDK | Node SDK | Java SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 이하 | 1.2.8 이하 | 1.4.2 이하 | 1.7.3 이하 | 1.13.0 이하 | 1.1.0 이하 |
참고 항목
이러한 값과 링크는 변경될 수 있습니다. 이 정보는 고객이 버전을 확인할 수 있는 위치와 필요한 버전을 표시하기 위한 자리 표시자로만 사용됩니다.