복원력 있는 애플리케이션을 만들기 위한 디바이스 다시 연결 관리
이 문서에서는 디바이스 다시 연결 전략을 추가하여 복원력 있는 애플리케이션을 설계하는 데 도움이 되는 개략적인 지침을 제공합니다. 디바이스 연결을 끊고 다시 연결해야 하는 이유를 설명합니다. 또한 개발자가 연결이 끊긴 디바이스를 다시 연결하는 데 사용할 수 있는 특정 전략을 설명합니다.
연결 끊김의 원인
다음은 디바이스가 IoT Hub에서 연결을 끊는 가장 일반적인 이유입니다.
- 만료된 SAS 토큰 또는 X.509 인증서입니다. 디바이스의 SAS 토큰 또는 X.509 인증 인증서가 만료되었습니다.
- 네트워크 중단. 네트워크에 대한 디바이스의 연결이 중단됩니다.
- 서비스 중단. Azure IoT Hub 서비스에서 오류가 발생하거나 일시적으로 사용할 수 없습니다.
- 서비스 재구성. IoT Hub 서비스 설정을 다시 구성한 후 디바이스에서 다시 프로비전하거나 다시 연결해야 할 수 있습니다.
다시 연결 전략이 필요한 이유
다음 섹션에 설명된 대로 디바이스를 다시 연결하는 전략을 갖도록 하는 것이 중요합니다. 다시 연결 전략이 없으면 솔루션의 성능, 가용성 및 비용에 부정적인 영향을 미칠 수 있습니다.
대량 재연결 시도로 인해 DDoS가 발생할 수 있습니다.
초당 많은 수의 연결 시도로 인해 DDoS(분산 서비스 거부 공격)와 유사한 조건이 발생할 수 있습니다. 이 시나리오는 수백만 개의 번호가 매겨지는 대규모 디바이스와 관련이 있습니다. 이 문제는 플릿을 소유한 테넌트 이상으로 확장되고 전체 배율 단위에 영향을 줄 수 있습니다. DDoS를 사용하면 규모 확장이 필요하기 때문에 Azure IoT Hub 리소스에 대한 비용이 크게 증가할 수 있습니다. 또한 DDoS는 리소스 부족으로 인해 솔루션의 성능을 저하시킬 수 있습니다. 더 나쁜 경우 DDoS는 서비스 중단을 일으킬 수 있습니다.
허브 오류 또는 재구성으로 인해 많은 디바이스의 연결이 끊어지게 될 수 있습니다.
IoT Hub에서 오류가 발생하거나 IoT Hub에서 서비스 설정을 다시 구성한 후 디바이스의 연결이 끊어질 수 있습니다. 적절한 장애 조치(failover)의 경우 연결이 끊긴 디바이스를 다시 프로비전해야 합니다. 장애 조치(failover) 옵션에 대한 자세한 내용은 IoT Hub 고가용성 및 재해 복구를 참조하세요.
많은 디바이스를 다시 프로비전하면 비용이 증가할 수 있습니다.
디바이스가 IoT Hub에서 연결을 끊은 후 최적의 솔루션은 디바이스를 다시 프로비전하지 않고 다시 연결하는 것입니다. DPS와 함께 IoT Hub 사용하는 경우 DPS에는 프로비저닝당 비용이 있습니다. DPS에서 많은 디바이스를 다시 프로비전하면 IoT 솔루션의 비용이 증가합니다. DPS 프로비저닝 비용에 대한 자세한 내용은 IoT Hub DPS 가격 책정을 참조하세요.
복원력을 위한 디자인
IoT 디바이스는 주로 불연속 네트워크 연결 또는 불안정한 네트워크 연결(예: GSM 또는 위성)을 사용합니다. 일시적인 서비스 가용성 및 인프라 수준 또는 일시적 오류 때문에 디바이스가 클라우드 기반 서비스와 상호 작용할 때 오류가 발생할 수 있습니다. 디바이스에서 실행되는 애플리케이션이 연결 및 다시 연결에 대한 메커니즘과 메시지 전송 및 수신에 대한 재시도 논리를 관리해야 합니다. 또한 다시 시도 전략 요구 사항은 디바이스의 IoT 시나리오, 컨텍스트, 기능에 따라 크게 달라집니다.
Azure IoT Hub 디바이스 SDK의 목적은 클라우드-디바이스 및 디바이스-클라우드에서 연결 및 통신을 간소화하는 데 있습니다. 이러한 SDK는 Azure IoT Hub에 연결하는 강력한 방법 및 메시지 송신 및 수신에 대한 포괄적인 옵션 세트를 제공합니다. 개발자가 기존 구현을 수정하여 지정된 시나리오에 대한 향상된 재시도 전략을 사용자 지정할 수도 있습니다.
연결 및 신뢰할 수 있는 메시징을 지원하는 관련 SDK 기능은 다음 IoT Hub 디바이스 SDK에서 사용할 수 있습니다. 자세한 내용은 API 설명서 또는 특정한 SDK를 참조하세요.
다음 섹션에서는 연결을 지원하는 SDK 기능에 대해 설명합니다.
연결 및 재시도
이 섹션에서는 연결을 관리할 때 사용할 수 있는 다시 연결 및 재시도 패턴의 개요를 제공합니다. 또한 디바이스 애플리케이션에서 서로 다른 재시도 정책을 사용하기 위한 구현 지침에 대해 자세히 설명하고 디바이스 SDK에서 관련 API를 나열합니다.
오류 패턴
연결 실패는 다음과 같은 여러 수준에서 발생할 수 있습니다.
네트워크 오류: 연결이 끊어진 소켓 및 이름 확인 오류
HTTP, AMQP 및 MQTT 전송에 대한 프로토콜 수준 오류: 연결 분리 또는 세션 만료
로컬 실수에서 발생하는 애플리케이션 수준 오류: 잘못된 자격 증명 또는 서비스 동작(예: 할당량 또는 제한 초과)
디바이스 SDK는 세 수준의 오류를 모두 검색합니다. 그러나 디바이스 SDK는 OS 관련 오류 및 하드웨어 오류를 검색하고 처리하지 않습니다. SDK 디자인은 Azure 아키텍처 센터의 일시적 오류 처리 지침을 기반으로 합니다.
재시도 패턴
연결 오류가 검색되면 다음 단계에서 재시도 프로세스에 대해 설명합니다.
SDK가 네트워크, 프로토콜 또는 애플리케이션에서 오류 및 관련 오류를 검색합니다.
SDK는 오류 필터를 사용하여 오류 유형을 결정하고 재시도가 필요한지를 결정 합니다.
SDK가 치명적인 오류를 검색하는 경우 연결, 송신 및 수신과 같은 작업은 중지됩니다. SDK는 사용자에게 알립니다. 복구할 수 없는 오류의 예제에는 인증 오류 및 잘못된 엔드포인트 오류가 포함됩니다.
SDK가 복구할 수 있는 오류를 검색하는 경우 정의된 제한 시간이 경과할 때까지 지정된 재시도 정책에 따라 다시 시도합니다. SDK는 기본적으로 지터 재시도 정책과 함께 지수 백오프를 사용합니다.
정의된 시간 제한이 만료되면 SDK는 연결 또는 전송 시도를 중지하고 사용자에게 알립니다.
SDK를 사용하면 사용자가 콜백을 연결하여 연결 상태 변경을 수신할 수 있습니다.
SDK는 다음 세 가지 재시도 정책을 제공합니다.
지터를 사용한 지수적 백오프: 이 기본 재시도 정책은 적극적으로 시작하고 최대 지연 시간에 도달할 때까지 시간이 지남에 따라 저하되는 경향이 있습니다. 이 디자인은 Azure 아키텍처 센터의 재시도 지침을 기반으로 합니다.
사용자 지정 재시도: 일부 SDK 언어의 경우 시나리오에 더 적합한 사용자 지정 재시도 정책을 설계한 다음, RetryPolicy에 삽입할 수 있습니다. 사용자 지정 다시 시도는 C SDK에서 사용할 수 없으며, 현재 Python SDK에서 지원되지 않습니다. Python SDK는 필요에 따라 다시 연결합니다.
재시도 안 함: 재시도 정책을 “재시도 안 함”으로 설정하여 재시도 논리를 사용하지 않도록 설정할 수 있습니다. SDK는 한 번 연결을 시도하고, 연결이 설정되면 한 번 메시지를 보냅니다. 이 정책은 일반적으로 대역폭 또는 비용 문제가 있는 시나리오에 사용됩니다. 이 옵션을 선택하면 보내지 못한 메시지가 손실되며 복구될 수 없습니다.
재시도 정책 API
SDK | SetRetryPolicy 메서드 | 정책 구현 | 구현 지침 |
---|---|---|---|
C | IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy | 참조: IOTHUB_CLIENT_RETRY_POLICY | C# 구현 |
Java | SetRetryPolicy | 기본값: ExponentialBackoffWithJitter 클래스 사용자 지정: RetryPolicy 인터페이스 구현 재시도 없음: NoRetry 클래스 |
Java 구현 |
.NET | DeviceClient.SetRetryPolicy | 기본값: ExponentialBackoff 클래스 사용자 지정:IRetryPolicy 인터페이스 구현 재시도 없음: NoRetry 클래스 |
C# 구현 |
노드 | setRetryPolicy | 기본값: ExponentialBackoffWithJitter 클래스 사용자 지정:RetryPolicy 인터페이스 구현 재시도 없음: NoRetry 클래스 |
Node 구현 |
Python | 현재 지원되지 않음 | 현재 지원되지 않음 | 기본 제공 연결 다시 시도: 삭제된 연결은 기본적으로 고정된 10초 간격으로 다시 시도됩니다. 원하는 경우 이 기능을 사용하지 않도록 설정할 수 있으며 간격을 구성할 수 있습니다. |
허브 다시 연결 흐름
DPS 없이만 IoT Hub를 사용하는 경우 다음 다시 연결 전략을 사용합니다.
디바이스가 IoT Hub에 연결하지 못하거나 IoT Hub에서 연결이 끊어진 경우:
- 지터 지연 함수와 함께 지수 백오프를 사용합니다.
- IoT Hub에 다시 연결합니다.
다음 다이어그램에는 필요한 연결 흐름이 요약되어 있습니다.
DPS 다시 연결 흐름이 있는 허브
DPS에서 IoT Hub를 사용하는 경우 다음 다시 연결 전략을 사용합니다.
디바이스가 IoT Hub에 연결하지 못하거나 IoT Hub 연결이 끊어지면 다음 경우에 따라 다시 연결합니다.
다시 연결 시나리오 | 다시 연결 전략 |
---|---|
연결 재시도를 허용하는 오류의 경우(HTTP 응답 코드 500) | 지터 지연 함수와 함께 지수 백오프를 사용합니다. IoT Hub에 다시 연결합니다. |
재시도 가능하지만 다시 연결이 10회 연속 실패했음을 나타내는 오류의 경우 | 디바이스를 DPS로 다시 프로비전합니다. |
연결 재시도를 허용하지 않는 오류의 경우(HTTP 응답 401, 권한 없음 또는 403, 금지됨 또는 404, 찾을 수 없음) | 디바이스를 DPS로 다시 프로비전합니다. |
다음 다이어그램에는 필요한 연결 흐름이 요약되어 있습니다.
다음 단계
제안된 다음 단계는 다음과 같습니다.