이 문서에서는 에지에서 데이터를 수집하고 클라우드로 전송하는 두 가지 Azure IoT 작업 배포 예제를 설명합니다. 이러한 예는 하드웨어 기능과 데이터 볼륨을 고려한 실제 시나리오를 기반으로 합니다. 이러한 예제를 사용하여 Azure IoT 작업 특정 하드웨어에서 처리할 수 있는 데이터의 양을 더 잘 이해할 수 있습니다.
Microsoft 유사한 구성 및 데이터 볼륨을 사용하여 Azure IoT 작업 유효성을 검사하고 성능을 측정했습니다.
단일 노드 클러스터
이 예제에서는 하드웨어 사양이 상대적으로 낮은 호스트에서 실행되는 경우 Azure IoT 작업 기능을 보여줍니다. 이 예제에서는 Azure IoT 작업 단일 노드 클러스터에 배포됩니다. 자산에서 생성된 데이터는 먼저 PLC를 사용하여 집계된 다음 OPC UA용 Azure IoT 작업 커넥터로 전송됩니다.
구성
하드웨어 사양 예:
Azure VM의 K3(Intel Xeon Platinum 8370C를 사용하는 Standard_D4ds_v5), 4코어(4개 vCPU), 16GB 메모리, 30GB 스토리지.
P3 Tiny Workstation(13세대 Intel® Core™ i7-13700 vPro® 프로세서), 16Core(24스레드), 32GB 메모리, 1TB 스토리지를 탑재한 AKS-EE.
중요합니다
현재 Ubuntu 24.04 및 Tanzu Kubernetes의 K3s는 프로덕션에서 Azure IoT 작업 배포하기 위한 유일한 플랫폼입니다. 자세한 내용은 지원되는 환경을 참조하세요.
다음 표는 단일 노드 예에 대한 MQTT 브로커 구성을 보여 줍니다.
| 매개 변수 | 값 |
|---|---|
| frontendReplicas | 1 |
| 프론트엔드 작업자 | 2 |
| 백 엔드 중복도 계수 | 2 |
| 백엔드 작업자들 | 1 |
| 백엔드 파티션 | 1 |
| 메모리 프로파일 | low |
이 예의 엔드투엔드 데이터 흐름은 다음과 같습니다.
Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs
예의 데이터 볼륨은 다음과 같습니다.
- 단일 OPC UA 서버에 의해 집계된 125개 자산.
- 각 자산에 대한 50개의 태그를 기준으로 하는 6,250개의 태그. 각 태그는 초당 2회 업데이트되며 평균 크기는 20바이트입니다.
- OPC UA 커넥터는 초당 125개의 메시지를 MQTT 브로커로 전송합니다.
- 하나의 데이터 흐름 파이프라인은 6,250개의 태그를 Event Hubs 엔드포인트로 푸시합니다.
이 예제에서 Microsoft 4코어 CPU를 사용하여 하나의 데이터 흐름 인스턴스만 만들 수 있으므로 Event Hubs를 사용하는 것이 좋습니다. Event Grid를 선택하면 초당 100개의 메시지만 처리할 수 있습니다.
성능
이 사례의 주요 성능 메트릭은 다음과 같습니다.
- Azure IoT 작업 및 해당 종속성은 6GB에서 8GB RAM 사이를 사용합니다.
- Azure IoT 작업 및 그 종속성은 평균적으로 2,400-2,600밀리코어를 사용합니다.
- 데이터의 100%가 Event Hubs로 푸시됩니다.
- 이상적인 네트워크 조건에서는 엔드투엔드 데이터 처리 대기 시간이 10초 미만입니다.
다중 노드 클러스터
Azure IoT 작업 다중 노드 클러스터에서 실행되는 경우 더 많은 데이터를 처리하고 Kubernetes의 고가용성 기능을 활용할 수 있습니다. 이 예제에서 Azure IoT 작업 5노드 클러스터에서 호스트되고 두 개의 서로 다른 데이터 원본에서 초당 약 50,000개의 데이터 요소를 처리합니다.
구성
하드웨어 사양 예:
Azure VM이 있는 5노드 K3(Intel Xeon Platinum 8370C Standard_D8d_v5), 8코어(8개 vCPU), 32GB 메모리, 30GB.
P3 Tiny Workstation(13세대 Intel® Core™ i7-13700 vPro® 프로세서), 16Core(24스레드), 32GB 메모리, 1TB 스토리지를 탑재한 5노드 K3S.
중요합니다
현재 Ubuntu 24.04 및 Tanzu Kubernetes의 K3s는 프로덕션에서 Azure IoT 작업 배포하기 위한 유일한 플랫폼입니다. 자세한 내용은 지원되는 환경을 참조하세요.
다음 표는 다중 노드 예에 대한 MQTT 브로커 구성을 보여 줍니다.
| 매개 변수 | 값 |
|---|---|
| frontendReplicas | 5 |
| 프론트엔드 작업자 | 4 |
| 백 엔드 중복도 계수 | 2 |
| 백엔드 작업자들 | 4 |
| 백엔드 파티션 | 5 |
| 메모리 프로파일 | 높음 |
이 예에는 두 가지 형식의 데이터 원본이 있습니다. 하나는 OPC UA 커넥터를 통해 연결하고, 다른 하나는 MQTT 브로커를 통해 연결합니다.
이 예에서 자산은 실제 장비를 나타내는 것이 아니라 데이터 포인트를 집계하고 메시지를 보내는 논리적 그룹입니다.
이 예에서 첫 번째 엔드투엔드 데이터 흐름은 다음과 같습니다.
Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs
예의 첫 번째 데이터 흐름의 데이터 볼륨은 다음과 같습니다.
- 5개의 OPC UA 서버에 의해 집계된 85개 자산.
- 각 자산에 대한 1,000개의 태그를 기준으로 하는 85,000개의 태그. 각 태그는 초당 1회 업데이트되며 평균 크기는 8바이트입니다. 태그 값의 약 50%가 주기마다 변경됩니다. 데이터 포인트 업데이트 속도는 초당 45,000개입니다.
- OPC UA 커넥터는 초당 85개의 메시지를 MQTT 브로커로 전송합니다.
- 하나의 데이터 흐름 파이프라인은 85,000개의 태그를 Event Hubs 엔드포인트로 푸시합니다.
예의 두 번째 엔드투엔드 데이터 흐름은 다음과 같습니다.
MQTT client (Paho) -> MQTT Broker -> Data flows -> Event Hubs
예의 두 번째 데이터 흐름의 데이터 볼륨은 다음과 같습니다.
- 두 개의 MQTT 클라이언트가 MQTT 브로커에 직접 연결되어 있습니다.
- 각 클라이언트는 초당 10,000개의 값을 게시합니다.
- 태그 값의 약 1/3이 주기마다 변경됩니다.
- JSON 형식으로 인코딩됩니다. 각 항목(값)의 크기는 약 180바이트입니다.
성능
이 사례의 주요 성능 메트릭은 다음과 같습니다.
- Azure IoT 작업 및 해당 종속성은 25GB에서 30GB RAM 사이를 사용합니다.
- Azure IoT 작업 및 종속성은 평균 2,500-3,000 밀리코어를 사용합니다.
- 데이터의 100%가 Event Hubs로 푸시됩니다.
- 이상적인 네트워크 조건에서는 엔드투엔드 데이터 처리 대기 시간이 10초 미만입니다.