이 문서에는 IoT 솔루션을 프로덕션 환경으로 이동할 때 고려해야 하는 항목 목록이 포함되어 있습니다.
배포 스탬프 사용
스탬프는 정의된 수의 디바이스를 지원하는 핵심 솔루션 구성 요소의 개별 단위입니다. 각 복사본을 스탬프 또는 배율 단위라고 합니다. 예를 들어 스탬프는 설정된 디바이스 채우기, IoT Hub, 이벤트 허브 또는 기타 라우팅 엔드포인트 및 처리 구성 요소로 구성될 수 있습니다. 각 스탬프는 정의된 디바이스 채우기를 지원합니다. 스탬프에 보관할 수 있는 최대 디바이스 수를 선택합니다. 디바이스 채우기가 증가함에 따라 솔루션의 여러 부분을 독립적으로 확장하는 대신 스탬프 인스턴스를 추가합니다.
스탬프를 추가하는 대신 IoT 솔루션의 단일 인스턴스를 프로덕션으로 이동하는 경우 다음과 같은 제한 사항이 발생할 수 있습니다.
크기 조정 제한: 단일 인스턴스에 크기 조정 제한이 발생할 수 있습니다. 예를 들어 솔루션은 인바운드 연결 수, 호스트 이름, TCP 소켓 또는 기타 리소스 수에 제한이 있는 서비스를 사용할 수 있습니다.
비선형 크기 조정 또는 비용: 솔루션 구성 요소는 요청 수 또는 수집된 데이터 양과 선형적으로 확장되지 않을 수 있습니다. 대신 일부 구성 요소의 경우 임계값을 충족하면 성능이 저하되거나 비용이 증가할 수 있습니다. 더 많은 용량으로 스케일 업하는 것은 스탬프를 추가하여 스케일 아웃하는 전략만큼 좋지 않을 수 있습니다.
고객 분리: 특정 고객의 데이터를 다른 고객의 데이터와 격리해야 할 수 있습니다. 마찬가지로, 다른 고객보다 서비스에 더 많은 시스템 리소스가 필요한 일부 고객이 있을 수 있으며 다른 스탬프에 그룹화할 것을 고려할 수 있습니다.
단일 및 다중 테넌트 인스턴스: 솔루션의 자체 독립 인스턴스가 필요한 일부 대규모 고객이 있을 수 있습니다. 다중 테넌트 배포를 공유할 수 있는 소규모 고객 풀이 있을 수도 있습니다.
복잡한 배포 요구 사항: 제어된 방식으로 서비스에 업데이트를 배포하고 다른 시간에 다른 스탬프에 배포해야 할 수 있습니다.
업데이트 빈도: 시스템에 자주 업데이트하는 것을 용인하는 고객이 있을 수 있지만, 다른 고객은 위험에 반대하고 서비스에 대한 업데이트를 자주 원하지 않을 수 있습니다.
지리적 또는 지정학적 제한 사항: 대기 시간을 줄이거나 데이터 주권 요구 사항을 준수하려면 일부 고객을 특정 지역에 배포할 수 있습니다.
이전 문제를 방지하려면 서비스를 여러 스탬프로 그룹화하는 것을 고려하세요. 스탬프는 서로 독립적으로 작동하며 독립적으로 배포 및 업데이트할 수 있습니다. 단일 지리적 지역에는 단일 스탬프가 포함되거나 지역 내에서 수평 확장을 허용하는 여러 스탬프가 포함될 수 있습니다. 각 스탬프에는 고객의 하위 집합이 포함됩니다.
일시적인 오류가 발생할 때 백오프 사용
원격 서비스 및 리소스와 통신하는 모든 애플리케이션은 일시적인 오류에 민감해야 합니다. 특히 클라우드에서 실행되는 애플리케이션의 경우는 더욱 그렇습니다. 이러한 애플리케이션에서는 환경 및 인터넷을 통한 연결이라는 특성으로 인해 이러한 유형의 오류가 더 자주 발생할 수 있습니다. 일시적인 오류에는 다음이 포함됩니다.
- 구성 요소 및 서비스에 대한 네트워크 연결의 순간적인 손실
- 서비스를 일시적으로 사용할 수 없음
- 서비스가 사용 중일 때 발생하는 시간 제한
- 디바이스가 동시에 전송될 때 발생하는 충돌
이러한 오류는 종종 자체 수정되며 적절한 지연 후에 작업이 반복되면 성공할 가능성이 높습니다. 그러나 다시 시도 사이의 적절한 간격을 결정하는 것은 어렵습니다. 일반적인 전략에서는 다음과 같은 유형의 다시 시도 간격을 사용합니다.
- 지수적 백오프. 애플리케이션이 첫 번째 재시도 전까지 짧은 시간 동안 대기한 다음, 이후 각 재시도 사이의 시간을 기하급수적으로 늘립니다. 예를 들어 3초, 12초, 30초 등 후에 작업을 재시도할 수 있습니다.
- 정기적 간격. 애플리케이션이 각 시도 사이에 동일한 기간 동안 대기합니다. 예를 들어 3초마다 작업을 재시도할 수 있습니다.
- 즉시 재시도. 네트워크 패킷 충돌 또는 하드웨어 구성 요소의 스파이크와 같은 이벤트로 인해 일시적인 오류가 일시적인 경우가 있습니다. 이런 경우 애플리케이션이 다음 요청을 어셈블하여 보내는 데 걸리는 시간 동안 오류가 해결되어 성공할 수 있으므로 작업을 즉시 재시도하는 것이 적합합니다. 그러나 즉시 다시 시도 횟수는 두 번 이상이면 안 되므로 즉시 다시 시도가 실패할 경우 지수적 백오프 또는 대체 작업과 같은 다른 전략으로 전환해야 합니다.
- 불규칙. 앞의 다시 시도 전략에는 여러 클라이언트 인스턴스에서 이후 다시 시도 횟수를 동시에 보낼 수 없도록 하는 불규칙이 포함될 수 있습니다.
다음과 같은 안티패턴도 사용하지 않도록 합니다.
- 구현에는 중복된 다시 시도 코드 계층이 포함되어서는 안 됩니다.
- 무한 재시도 메커니즘을 구현하지 않습니다.
- 즉시 재시도를 두 번 이상 수행하지 않습니다.
- 정기적인 다시 시도 간격을 사용하지 마세요.
- 동일한 클라이언트의 여러 인스턴스 또는 다른 클라이언트의 여러 인스턴스에서 동시에 재시도를 보내지 않도록 합니다.
제로 터치 프로비전 사용
프로비전은 디바이스를 Azure IoT Hub에 등록하는 작업입니다. 프로비전을 통해 IoT Hub는 디바이스 및 디바이스에서 사용하는 증명 메커니즘을 인식할 수 있습니다. Azure IoT Hub DPS(Device Provisioning Service)를 사용하거나 IoT Hub 레지스트리 관리자 API를 통해 직접 프로비전할 수 있습니다. DPS를 사용하면 디바이스 소프트웨어를 변경하지 않고 필드 디바이스를 IoT Hub로 제거하고 다시 프로비저닝할 수 있는 지연 바인딩의 이점을 얻을 수 있습니다.
다음 예제에서는 DPS를 사용하여 테스트-프로덕션 환경 전환 워크플로를 구현하는 방법을 보여줍니다.
- 솔루션 개발자는 테스트 및 프로덕션 IoT 클라우드를 프로비저닝 서비스에 연결합니다.
- 디바이스는 더 이상 프로비전되지 않는 경우 DPS 프로토콜을 구현하여 IoT Hub를 찾습니다. 디바이스는 처음에 테스트 환경에 프로비전됩니다.
- 디바이스가 테스트 환경에 등록되어 있기 때문에 디바이스에 연결하여 테스트를 수행합니다.
- 개발자는 디바이스를 프로덕션 환경에 다시 프로비전하고 테스트 허브에서 제거합니다. 테스트 허브는 다음에 다시 연결할 때 디바이스를 거부합니다.
- 디바이스는 프로비저닝 흐름을 연결하고 다시 협상합니다. 이제 DPS는 디바이스를 프로덕션 환경으로 연결하고 디바이스가 연결 및 인증됩니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Matthew Cosner | 수석 소프트웨어 엔지니어링 관리자
- Ansley Yeo | 수석 프로그램 관리자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.