이 참조는 유휴 상태(활성 워크로드 없음)에서 Azure IoT 작업 배포에 대한 측정된 기준 리소스 사용량을 제공합니다. 이러한 프로필을 사용하여 하드웨어가 최소 요구 사항을 충족하는지 확인하고 리소스 모니터링 기준을 설정합니다.
Overview
Azure IoT 작업 여러 Kubernetes 네임스페이스에 여러 구성 요소를 배포합니다. 총 리소스 공간은 MQTT 브로커 메모리 프로필 (Pod당 메모리 할당을 제어하는)과 broker 카디널리티 (배포되는 Pod 수를 제어하는 프런트 엔드 복제본 수, 백 엔드 파티션 및 중복 요소)의 두 가지 요인에 따라 달라집니다. 카디널리티가 높을수록 Pod가 더 많고, 메모리 프로필이 높으면 각 Pod에서 더 많은 메모리를 사용함을 의미합니다.
세 가지 구성은 유휴 상태의 단일 노드 클러스터에서 측정되었습니다(연결된 자산 없음, 활성 데이터 흐름 없음, 거의 0에 가까운 트래픽). 이는 최댓값이 아닌 기준 숫자입니다. 프로덕션 워크로드의 사용량이 크게 증가합니다.
| 구성 / 설정 | 메모리 프로필 | Cardinality | 노드 최대 메모리 | Azure IoT 작업 네임스페이스 피크 RSS | 전체 Pod 피크 RSS | Pod 개수 |
|---|---|---|---|---|---|---|
| 설정 A | 아주 작음 | 1 프론트엔드 파티션 1 중복 요소 2 |
~4,979MiB | ~1,298MiB | ~5,409MiB | 55 |
| 설정 B | 낮음 | 2개의 프런트엔드 파티션 2개 중복 요소 2 |
~5,130MiB | ~1,559MiB | ~5,695MiB | 58 |
| 설정 C | 중간 | 2개의 프런트엔드 파티션 2개 중복 요소 2 |
~6,088MiB | ~2,407MiB | ~6,564MiB | 58 |
메모
Config A와 Config B의 차이는 더 높은 카디널리티(더 많은 broker Pod)와 다른 메모리 프로필에서 비롯됩니다. Config B와 Config C의 차이는 메모리 프로필(동일한 카디널리티, 동일한 Pod 수)과만 다릅니다. 로드된 시나리오 에 대한 프로덕션 배포 예제 를 참조하세요.
네임스페이스 세분화
다음 표에서는 유휴 상태의 세 가지 구성에서 네임스페이스별 최대 RSS 메모리를 보여 줍니다.
| 네임스페이스 | 구성 A, 초소형 (MiB) | 구성 B, 낮음(MiB) | Config C, 중간 (MiB) | Description |
|---|---|---|---|---|
| azure-iot-operations | 1,298 | 1,559 | 2,407 | Azure IoT 작업 핵심 서비스(브로커, 데이터 흐름, 커넥터, 가시성) |
| azure-arc | 1,964 | 1,985 | 1,990 | Azure Arc 에이전트 및 컨트롤러 |
| cert-manager | 1,351 | 1,357 | 1,362 | 인증서 관리 |
| gatekeeper-system | 338 | 338 | 350 | 정책 적용 |
| azure-extensions-usage-system | 279 | 277 | 278 | 청구 사업자 |
| arc-workload-identity | 90 | 90 | 91 | 워크로드 아이덴티티 웹훅 |
| azure-secret-store | 87 | 88 | 87 | 비밀 동기화 컨트롤러 |
| 합계 | ~5,409 | ~5,695 | ~6,564 |
메모
- Azure Arc, cert-manager, gatekeeper 및 기타 인프라 네임스페이스는 브로커 구성에 관계없이 최대 3.8-4.1GB를 사용합니다. 이 오버헤드는 Azure IoT 작업 사용하여 Arc 지원 클러스터를 실행하는 고정 비용입니다.
-
azure-iot-operations네임스페이스만 메모리 프로필 및 카디널리티 선택에 따라 확장되며, 약 1.3GB(Tiny, 최소 카디널리티)에서 약 2.4GB(Medium, 더 높은 카디널리티)까지입니다. - 워크로드를 고려하기 전에, 유휴 상태에서 Azure IoT 작업 인프라용으로 전용되는 6 GB 이상의 메모리를 계획하세요.
MQTT 브로커 파드 리소스 사용량
MQTT broker는 가장 큰 변수 구성 요소입니다. 구성 간의 메모리 차이는 메모리 프로필(Pod당 할당) 및 카디널리티(Pod 수) 모두에서 발생합니다. 다음 표는 파드별 유휴 RSS를 보여줍니다. 이러한 숫자는 트래픽에 따라 증가합니다.
| 포드 | 구성 A, 초소형 (MiB) | 구성 B, 낮음(MiB) | Config C, 중간 (MiB) | 비고 |
|---|---|---|---|---|
| aio-broker-frontend-0 | 이십구 | 33 | 169 | Pod당 메모리는 프로필에 따라 확장됩니다 |
| aio-broker-frontend-1 | N/A | 33 | 169 | 구성 A에 존재하지 않음 (프런트엔드 복제본 1개) |
| aio-broker-backend-1-0 | 41 | 66 | 211 | Pod당 메모리는 프로필에 따라 확장됩니다 |
| aio-broker-backend-1-1 | 41 | 65 | 210 | 중복 계수 복제본 |
| aio-broker-backend-2-0 | N/A | 66 | 212 | 구성 A에 없음(하나의 파티션) |
| aio-broker-backend-2-1 | N/A | 65 | 211 | 구성 A에 없음(하나의 파티션) |
| aio-broker-health-manager-0 | 41 | 41 | 42 | 프로필 간 동일 |
| aio-broker-operator-0 | 60 | 60 | 56 | 프로필 간 동일 |
| aio-broker-diagnostics-probe-0 | 24 | 43 | 43 | |
| aio-broker-diagnostics-service-0 | 49 | 66 | 66 | |
| aio-broker-authentication-0 | 24 | 24 | 24 | 프로필 간 동일 |
| aio-broker-webhook-0 | 33 | 35 | 32 | 프로필 간 동일 |
테스트를 거친 프로필별 브로커 구성
| Setting | 구성 A(초소형) | 구성 B (낮음) | 구성 C(보통) |
|---|---|---|---|
| 프론트엔드 복제본 | 1 | 2 | 2 |
| 백 엔드 파티션 | 1 | 2 | 2 |
| 백엔드 중복성 비율 | 2 | 2 | 2 |
| 총 브로커 Pod 수 | 10 | 13 | 13 |
| Pod별 유휴 프런트엔드 메모리 | ~29MiB | ~33 MiB | ~169MiB |
| Pod별 유휴 백엔드 메모리 | ~41MiB | ~66MiB | ~211 MiB |
| 최대 메시지 크기 | 4MB | 16MB | 64MB |
기타 Azure IoT 작업 구성 요소 사용
이러한 구성 요소는 메모리 프로필 또는 카디널리티에 관계없이 일관된 유휴 리소스 사용량을 갖습니다.
| Component | 최대 RSS (MiB) | 최고 CPU(코어) | 비고 |
|---|---|---|---|
| adr-schema-registry (x2) | 각 ~52개 | 0.002 | 스키마 레지스트리 Pod |
| aio-akri-operator-0 | ~39 | 0.001 | Akri 장치 검색 |
| aio-akri-adr-service-0 | ~30 | 0.001 | Akri Azure ADR(Device Registry) 서비스 |
| aio-dataflow-dev-0 | ~67 | 0.002 | 데이터 흐름 런타임 |
| aio-dataflow-operator-0 | ~56 | 0.001 | 데이터 흐름 연산자 |
| aio 연산자 | ~114 | 0.003 | Azure IoT 작업 운영자 |
| aio-observability (x2) | 각각 약 125개 | 0.005 | OpenTelemetry 수집기 |
| aio-observability-operator | ~106 | 0.003 | 관찰 연산자 |
| aio-observability-cluster-metrics-agent | ~114 | 0.004 | 메트릭 에이전트 |
| aio-wasm-graph-controller-0 | ~30 | 0.001 | WEBAssembly(WASM) 그래프 컨트롤러 |
CPU 사용량
CPU 사용량은 테스트된 모든 구성에서 유휴 상태로 최소화됩니다.
| 구성 / 설정 | Azure IoT 작업 네임스페이스 최대 CPU 사용량 | 클러스터 전체 최대 CPU | 노드 비율 |
|---|---|---|---|
| 구성 A(초소형) | 0.025 코어 | 0.099 코어 | 1.3% |
| 구성 B(낮음) | 0.044 코어 | 0.104 코어 | 1.3% |
| 구성 C(보통) | 0.048 코어 | 0.093 코어 | 1.2% |
CPU 사용량은 유휴 상태일 때 무시할 수 있습니다. 프로덕션 부하에서 메시지 처리량과 구성된 프런트 엔드/백 엔드 작업자 수에 비례하여 CPU 사용량이 훨씬 더 많이 필요합니다.
하드웨어 크기 조정 지침
이러한 유휴 기준 측정값에 따라 단일 노드 배포에는 다음과 같은 최소 하드웨어 권장 사항이 적용됩니다. 실제 요구 사항은 프로덕션 트래픽에서 더 높습니다.
| 메모리 프로필 | 최소 RAM(헤드룸 포함) | 권장 RAM | 사용 사례 |
|---|---|---|---|
| 작은 | 8GB | 8~10GB | 트래픽이 적고 작은 패킷만 |
| Low | 10GB | 12~16GB | 제한된 메모리, 작은 패킷 |
| Medium | 12GB | 16~32GB | 트래픽 및 메시지 크기 조정 |
| High | 16GB | 32GB 이상 | 높은 처리량, 대용량 메시지 |
Important
이러한 권장 사항은 약 4GB의 고정 인프라 오버헤드(Azure Arc, cert-manager, gatekeeper)와 가변적인 Azure IoT 작업 구성 요소의 사용 공간을 고려합니다. 프로덕션 워크로드에는 MQTT 메시지 버퍼링, 데이터 흐름 처리 및 OPC UA 커넥터 작업을 위한 추가 헤드룸이 필요합니다.