배포 스탬프로 IoT 솔루션 확장 및 관리

Azure Event Hubs
Azure IoT Hub
Azure Traffic Manager

이 문서에서는 IoT(사물 인터넷) 솔루션에서 연결된 디바이스 수를 확장할 수 있도록 지원하는 배포 스탬핑 전략에 대해 설명합니다. 이 문서에서는 배포 스탬프 간에 IoT 디바이스 및 애플리케이션을 배포하는 방법에 대해서도 자세히 설명합니다.

IoT 솔루션에 대한 배포 스탬핑 전략은 배포 스탬프 디자인 패턴을 기반으로 합니다. 배포 스탬프는 정의된 디바이스 모집단을 지원하는 다른 유형의 구성 요소로 구성된 단위입니다. 배포 스탬핑은 솔루션의 여러 부분을 독립적으로 확장하는 대신 스탬프를 복제하여 연결된 IoT 디바이스 수를 확장합니다.

배포 스탬핑 혜택:

  • 지리적 종속성, 수명 주기 또는 릴리스 상태와 같은 기준에 따라 디바이스를 배치하고 배포합니다.
  • 특정 스탬프에 대한 중단 또는 서비스 저하 영향을 포함합니다.
  • 새 기능, 기능 및 아키텍처 변경 내용을 지원할 수 있는 특정 스탬프에 배포합니다.
  • 기능 및 서비스를 지정된 디바이스 모집단에 맞춰 다세대 디바이스 관리를 지원합니다.
  • 향후 성장을 예측할 수 있도록 스탬프를 기반으로 하는 크기 조정 및 비용 모델을 제공합니다.

IoT 배포 스탬핑 아키텍처

Azure IoT에서 사용하기 위한 배포 스탬핑 전략을 보여 주는 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

앞의 다이어그램은 Azure IoT에 대한 배포 스탬핑 전략을 보여 줍니다. 이 솔루션은 각각 다음으로 구성된 원자 스탬프를 빌드합니다.

스탬프는 항상 명시적 용량을 지원하도록 설계되어야 합니다. 지원할 디바이스의 정확한 수를 확인하려면 디바이스에서 예상되는 통신 트래픽의 양을 고려합니다. 이 솔루션에서 각 스탬프는 1,000~1,000,000개의 디바이스에서 정의된 디바이스 모집단을 최적으로 지원합니다. 디바이스 모집단이 증가함에 따라 추가된 스탬프 인스턴스는 증가를 수용합니다.

스탬프 간에 디바이스 및 애플리케이션 이동

배포 스탬프는 원자성 배포를 위한 것이지만 스탬프 간에 디바이스 모집단을 이동해야 하는 경우가 있습니다. 예를 들어, 다음을 수행해야 합니다.

  • 릴리스 주기의 일부로 디바이스 모집단을 테스트 스탬프에서 프로덕션 스탬프로 이동합니다.
  • 고가용성 시나리오에서 가동 중단 수정 작업의 일환으로 디바이스와 사용자를 다른 스탬프로 이동합니다.
  • 부하 분산을 통해 스탬프 간에 디바이스 모집단을 더 균등하게 분산합니다.

허브 간에 디바이스 이동

스탬프 구성 요소가 디바이스-클라우드 동작만 포함하는 경우 허브 간에 디바이스를 이동하는 것으로 디바이스를 한 스탬프에서 다른 스탬프로 마이그레이션하기에 충분합니다. Azure IoT DPS(Device Provisioning Service)는 IoT Hub 인스턴스 간에 디바이스를 이동하는 방법을 제공합니다. 스탬핑 전략에서 DPS를 사용하려면 IoT Hub DPS(Device Provisioning Service) 용어 및 개념을 이해해야 합니다.

참고

DPS는 등록 ID를 사용하고 IoT Hub는 디바이스 ID를 사용합니다. 이러한 ID는 동일한 값인 경우가 많지만 다를 수도 있습니다. DPS API를 사용하여 디바이스를 쿼리하거나 관리하는 경우 등록 ID를 사용해야 합니다.

자체 포함 스탬프 간에 디바이스 및 애플리케이션 이동

배포 스탬프에 IoT Hub를 통해 통신하는 웹 프런트 엔드 또는 API 애플리케이션이 포함된 경우, 해당 구성 요소도 이동한 디바이스와 계속 통신하려면 새 허브로 마이그레이션해야 합니다. 스탬프 간에 전체 애플리케이션과 디바이스를 이동할 수 있습니다.

각 스탬프가 엔드투엔드 애플리케이션을 포함하는 경우 Azure Traffic Manager는 한 스탬프에서 다른 스탬프로 트래픽을 이동할 수 있습니다. 이 전략에는 각각 자체 URL을 사용하여 전체 애플리케이션을 포함하는 여러 스탬프를 만드는 작업이 포함됩니다. 디바이스 및 애플리케이션 사용자의 전체 모집단은 한 스탬프에서 다른 스탬프로 이동합니다.

이러한 완전 자체 포함 전략은 다음과 같습니다.

  • 구현이 간편합니다.
  • 고가용성 전략의 일부로 적합합니다.
  • 테스트에서 프로덕션 환경으로 디바이스 및 사용자를 마이그레이션하는 데 유용합니다.

한 스탬프에서 다른 스탬프로 디바이스 세트를 이동하는 방법을 보여 주는 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

위의 다이어그램은 스탬프 1에서 스탬프 2로 디바이스 세트를 이동하는 프로세스를 보여줍니다.

  1. 디바이스는 알 수 없거나 더 이상 유효하지 않은 경우 DPS를 통해 IoT Hub 엔드포인트를 획득합니다.
  2. 디바이스가 스탬프 2로 이동하면 Traffic Manager는 애플리케이션 URL이 애플리케이션 2 인스턴스를 가리킵니다.
  3. DPS는 전체 디바이스 세트를 한 스탬프에서 다른 스탬프로 이동합니다.
  4. 각 애플리케이션 스탬프는 애플리케이션 프런트 엔드를 포함하며 해당 스탬프에 해당하는 IoT Hub를 참조합니다.

단일 앱 게이트웨이 뒤의 스탬프 간에 디바이스 이동

단일 애플리케이션 프런트 엔드가 여러 디바이스 스탬프를 지원하는 경우 애플리케이션 프런트 엔드는 클라우드-디바이스 통신을 유지하기 위해 디바이스-허브 매핑을 동적으로 업데이트해야 합니다. 다른 스탬프 및 IoT Hub로 이동하는 디바이스를 지원하기 위해 게이트웨이는 디바이스-허브 매핑에 캐싱 메커니즘을 사용할 수 있습니다. 서비스 클라이언트는 공유 조회 루틴을 사용하여 디바이스 호출을 동적으로 검색하고 새 IoT Hub로 마이그레이션할 수 있습니다.

앱 게이트웨이를 사용하여 디바이스를 허브에서 다른 허브로 이동하는 방법을 보여 주는 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

이 모델에서 게이트웨이는 캐시를 사용하여 디바이스를 IoT Hubs에 매핑하고 캐시된 엔드포인트로 기본 설정합니다. 게이트웨이가 디바이스를 찾을 수 없음 오류를 수신하는 경우 DPS 서비스 SDK를 사용하여 개별 디바이스 등록을 쿼리하고 디바이스에서 현재 사용하는 IoT Hub를 결정합니다. 그런 다음, 게이트웨이는 새 매핑으로 캐시를 업데이트합니다.

다음은 이 전력에 대해 고려해야 할 몇 가지 사항입니다.

  • 공유 조회에서 캐싱하면 모든 호출에서 엔드포인트를 다시 협상하지 않아도 되지만 캐시 엔드포인트가 실패할 수 있습니다. DPS와 재협상하는 보조 캐시 또는 대체 계획은 솔루션 안정성을 향상시킬 수 있습니다.

  • 디바이스 등록이 진행 중인 경우에는 디바이스에 연결할 수 없습니다. 디바이스 등록 상태 가져오기와 같은 DPS API를 사용하여 디바이스의 할당된 IoT Hub 및 현재 등록 상태를 가져옵니다.

  • 디바이스 전용의 경우 디바이스가 한 스탬프에서 다른 스탬프로 이동할 때 IoT Hub에서 연결이 끊어집니다. 애플리케이션-디바이스의 경우 앱이 IoT Hub를 통해 디바이스에 연결하려고 할 때 오류가 발생합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

다음 단계