Azure IoT 작업 대한 배포 계획

많은 Azure IoT 작업 설정은 배포 시 수정되며 다시 배포해야만 변경할 수 있습니다. 배포하기 전에 클러스터 토폴로지, broker 카디널리티, 메모리 프로필 및 필요한 선택적 broker 설정을 계획합니다. 이 문서에서는 결정해야 하는 사항을 요약합니다.

아키텍처 이해

Azure IoT 작업 Azure Arc 지원 클러스터에 배포된 모듈식 Kubernetes 네이티브 서비스 집합입니다. 주요 구성 요소는 다음과 같습니다.

설명서 전체에서 두 용어가 사용됩니다.

• 배포 - 인스턴스, Arc 확장, 사용자 지정 위치 및 구성 가능한 모든 리소스(자산, 디바이스, 데이터 흐름)입니다.
• 인스턴스 - 서비스를 번들로 묶는 부모 리소스입니다.

클러스터 토폴로지 선택

배포하기 전에 단일 노드 또는 다중 노드 클러스터가 필요한지 여부를 결정합니다. 이 결정은 하드웨어 요구 사항 및 broker 카디널리티 설정을 결정합니다.

브로커 카디널리티 이해

카디널리티는 broker 배포에서의 프런트엔드 복제본 수, 프런트엔드 작업자 수, 백엔드 파티션 수, 백엔드 작업자 수를 의미합니다. 카디널리티는 브로커가 수평 확장되는 방식과 pod 또는 노드 장애에 대한 복원력을 제어합니다.

MQTT 브로커에는 프런트 엔드 Pod가 클라이언트 연결 및 프로토콜 처리를 처리하는 반면 백 엔드 Pod는 메시지 스토리지 및 배달을 처리하는 2계층 아키텍처가 있습니다. 용량 계획에는 각 계층 크기 조정 방법을 이해하는 것이 중요합니다.

Frontend

프런트 엔드 Pod는 MQTT 클라이언트 연결을 수락하고 백 엔드에 메시지를 전달합니다. 프런트 엔드 Pod는 메시지 자체를 저장하지 않습니다. 프런트 엔드 계층에는 다음 두 가지 기본 설정이 있습니다.

• 레플리카: 배포할 프런트엔드 파드의 수입니다. 프런트 엔드 복제본을 더 추가하면 브로커가 처리할 수 있는 동시 클라이언트 연결 수가 증가하고 프런트 엔드 Pod 중 하나가 실패할 경우 고가용성을 제공합니다.
• 작업자: 프런트엔드 Pod당 논리적 작업자 수입니다. 작업자를 더 추가하면 프런트 엔드 Pod에서 더 많은 CPU 코어를 사용할 수 있습니다. 각 작업자는 최대 하나의 CPU 코어를 사용할 수 있습니다.

백엔드 체인

백 엔드 Pod는 메시지 스토리지 및 배달을 처리합니다. 백 엔드 계층에 대한 세 가지 기본 설정이 있습니다.

• 파티션: 배포할 파티션 수입니다. 파티션은 메시지 처리량에 대한 수평 크기 조정 단위입니다. 분할이라는 프로세스를 통해 각 파티션은 토픽 및 세션별로 분할된 메시지의 일부를 처리합니다. 프런트 엔드 Pod는 파티션 간에 메시지 트래픽을 분산합니다. 파티션을 더 추가하면 Broker에서 처리할 수 있는 총 메시지 처리량이 증가합니다.
• 중복 요소: 파티션당 배포할 백 엔드 Pod 수입니다. 중복 요소를 늘리면 데이터 복사본 수가 증가하여 클러스터의 노드 오류에 대한 복원력을 제공합니다.
• 작업자: 백 엔드 Pod당 작업자 수입니다. 작업자는 파티션 내에서 수직 크기 조정의 단위입니다. 작업자를 더 추가하면 백 엔드 Pod가 동일한 노드에서 더 많은 CPU 코어를 사용할 수 있습니다. 각 작업자는 최대 2개의 CPU 코어를 사용할 수 있으므로 복제본당 작업자 수를 늘려 클러스터의 CPU 코어 수를 초과하지 않도록 주의해야 합니다.

처리량 예측

개별 파티션의 성능은 실행 중인 노드의 CPU 특성에 따라 크게 달라집니다. 경험상, 2GHz CPU(~4GHz 터보)에서 8KB 페이로드 기준 파티션당 초당 약 5,000~6,000개의 QoS 1 메시지를 처리할 수 있습니다. 실제 성능은 여러 요인에 따라 달라지므로 이 숫자를 용량 계획의 시작점으로만 사용합니다.

자세한 벤치마크 데이터는 MQTT Broker 성능 벤치마킹을 참조하세요.

단일 노드 권장 사항

• 프런트 엔드 복제본: 1로 설정합니다.
• 프런트 엔드 작업자: 노드당 CPU 코어 수의 절반으로 설정합니다.
• 백 엔드 복제본(중복 비율): Broker가 롤링 업데이트를 수행할 수 있도록 최소 2 로 설정합니다.

예: 단일 노드, 4개의 CPU 코어

다중 노드 권장 사항

최적의 성능을 위해 다음 값을 사용하는 것이 좋습니다. 트래픽이 적은 대규모 클러스터의 경우 이러한 값은 문제를 일으키지 않고 권장 사항보다 낮게 설정할 수 있습니다. 메모리(RAM) 및 성능 특성과 같은 추가 고려 사항은 다음 섹션에서 설명합니다. 항상 예상 워크로드를 사용하여 구성을 테스트하여 성능을 확인합니다.

• 프런트 엔드 복제본: 클러스터 의 노드 수와 동일하게 설정합니다.
• 프런트 엔드 작업자: 노드당 CPU 코어 수의 절반으로 설정합니다.
• 백 엔드 복제본(중복 요소): 중복성 및 롤링 업데이트 지원을 위해 2 로 설정합니다.
• 백 엔드 파티션: 클러스터 의 노드 수와 동일하게 설정합니다.
• 백 엔드 작업자: 노드당 CPU 코어 수의 절반으로 설정합니다.

예: 3노드 클러스터, 노드당 8개의 CPU 코어

예: 5노드 클러스터, 노드당 CPU 코어 16개

CPU 리소스 제한

클러스터의 리소스 부족 방지를 위해 broker는 카디널리티 설정에 따라 Kubernetes CPU 리소스 제한을 요청 하도록 구성할 수 있습니다. 사용하도록 설정하면 복제본 또는 작업자 수를 비례적으로 늘리면 필요한 CPU 리소스가 증가합니다.

REST API, Bicep 및 ARM 템플릿의 기본값은 Broker API 사양 정의되어 있습니다.

MQTT 브로커는 구성된 작업자 수에 따라 Pod당 CPU 리소스를 요청합니다.

• 프론트엔드 파드: 작업자당 1.0 CPU
• 백엔드 Pods: 작업자당 2.0 CPU

다음 수식을 사용하여 총 CPU 요구 사항을 계산합니다.

예: 작은 클러스터

다음 카디널리티를 사용하여 노드당 CPU 코어가 4개(총 8개 코어)인 2노드 클러스터를 고려합니다.

{
  "cardinality": {
    "frontend": {
      "replicas": 2,
      "workers": 2
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

브로커는 다음을 요청합니다.

• 프론트엔드 CPU: 2 레플리카 × 2 명의 작업자 × 1.0 = 4.0 CPU
• 백엔드 CPU: 1개 파티션 × 2 RF × 1개 작업자 × 2.0 = 4.0 CPU
• 총 브로커 CPU: 8.0 CPU

이 구성은 8코어만 있는 클러스터에서 8.0 CPU를 요청하며, 다른 Azure IoT 작업 구성 요소(200-300m) 또는 Kubernetes 시스템 Pod에는 아무 것도 남기지 않습니다. 브로커 Pod가 Pending 오류와 함께 Insufficient cpu 상태를 유지하고 있습니다.

이 문제를 해결하려면 노드를 더 추가하거나 노드당 코어를 늘리거나 broker 카디널리티를 줄입니다.

예: 대규모 배포

다음 카디널리티는 훨씬 더 많은 CPU 리소스를 요청합니다.

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

• 프런트엔드 CPU: 리플리카 3개 × 작업자 2명 × 1.0 = 6.0 CPU
• 백 엔드 CPU: 3개의 파티션 × 2개의 RF × 2명의 작업자 × 2.0 = 24.0 CPU
• 총 브로커 CPU: 30.0 CPU

클러스터에는 broker Pod에만 사용할 수 있는 CPU 코어가 30개 이상 필요하며 다른 Azure IoT 작업 구성 요소 및 Kubernetes 시스템 Pod에 대한 헤드룸도 필요합니다.

CPU 리소스 제한 구성

CPU 리소스 제한은 Broker 리소스의 generateResourceLimits.cpu 필드에 의해 제어됩니다. 이 구성은 --broker-config-file 명령을 사용하여 Azure IoT 작업 배포할 때 az iot ops create 플래그를 사용해야만 지원됩니다. 자세한 내용은 고급 MQTT broker 구성에 대한 Azure CLI 지원을 참조하세요.

GenerateResourceLimits API 참조에 따라 Broker 구성 파일을 준비합니다. 다음 예제에서는 두 가지 가능한 값을 보여 줍니다.

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

또는

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

메모리 프로필 선택

메모리 프로필은 broker가 허용하는 최대 MQTT 메시지 크기, 유휴 메모리 사용량 및 각 Pod의 최대 메모리 사용량을 제어합니다. 예상된 메시지 크기 및 처리량에 따라 배포 전에 올바른 메모리 프로필을 결정합니다.

입력 버퍼 및 백프레셔

각 메모리 프로필은 백 엔드 작업자당 PUBLISH 데이터에 대해 들어오는 최대 버퍼 크기를 정의합니다. 버퍼가 75% 용량에 도달하면 broker는 역압 메커니즘을 활성화하고 들어오는 메시지를 거부하기 시작합니다. 거부된 패킷은 할당량 초과 오류 코드와 함께 PUBACK 응답을 받습니다.

다음 표에서는 각 프로필에 대한 작업자당 들어오는 버퍼 크기를 보여 줍니다.

메모리 프로필을 선택할 때 다음을 고려합니다.

• 작은: 하나의 프런트 엔드만 사용해야 합니다. 4MiB보다 작은 패킷만 보냅니다.
• 낮음: 하나 또는 두 개의 프런트 엔드만 사용해야 합니다. 16MiB보다 작은 패킷만 보냅니다.
• 중간: 메시지 크기가 보통인 대부분의 프로덕션 워크로드에 적합합니다.
• 높음: 큰 메시지 또는 큰 버퍼로 높은 처리량을 처리해야 하는 경우에 사용합니다.

총 broker 메모리는 메모리 프로필 과 카디널리티(프런트 엔드 복제본 수, 백 엔드 파티션 및 중복 비율)에 따라 달라집니다. Pod가 많을수록 총 메모리가 늘어나게 됩니다. 다양한 구성에서 측정된 기준 리소스 사용량은 초기 계획 리소스 프로필을 참조하세요.

총 메모리 사용량 계산

다음 수식을 사용하여 총 메모리 사용량을 계산할 수 있습니다.

M_total = (R_fe × M_fe) + (P_be × RF_be × M_be × W_be)

Where:

예를 들어 중간 메모리 프로필을 선택하는 경우 프로필의 프런트 엔드 메모리 사용량은 1.9GiB이고 백 엔드 메모리 사용량은 1.5GiB입니다. broker 구성이 프런트 엔드 복제본 2개, 백 엔드 파티션 2개, 백 엔드 중복 요소 2개라고 가정합니다. 총 메모리 사용량은 다음과 같습니다.

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

이에 비해 Tiny 메모리 프로필의 프런트 엔드 메모리 사용량은 99MiB이고 백 엔드 메모리 사용량은 102MiB입니다. 동일한 broker 구성을 사용하면 총 메모리 사용량은 다음과 같습니다.

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

메모리 프로필 구성

명령을 사용하여 az iot ops create IoT 작업을 배포하는 경우 매개 변수는 --broker-mem-profile 메모리 프로필 설정을 지정합니다.

예를 들어 다음 명령은 메모리 프로필을 Tiny 로 설정합니다(간단히 하기 위해 다른 매개 변수는 생략됨).

az iot ops create ... --broker-mem-profile Tiny

자세한 내용은 선택적 매개 변수를 참조 az iot ops create 하세요.

선택적 브로커 설정

다음 브로커 설정은 배포 시에도 구성되며 나중에 변경할 수 없습니다. 시나리오에 적용되는 경우 다음을 검토합니다.

• 디스크 지원 메시지 버퍼 - 구독자 큐가 사용 가능한 메모리를 초과할 때 디스크에 메시지를 버퍼링합니다. 영구 세션 및 연결 문제에 유용합니다.
• 지속성 — 중요한 브로커 데이터를 디스크에 기록하여 재시작 후에도 보존합니다.
• 진단 - MQTT 브로커에 대한 메트릭, 로그 및 자체 검사 프로브를 구성합니다.
• 고급 MQTT 옵션 - 세션 만료, 메시지 만료, 구독자 큐 제한 및 연결 유지 설정을 사용자 지정합니다.
• 내부 트래픽 암호화 - broker 프런트 엔드와 백 엔드 Pod 간의 내부 트래픽 암호화를 구성합니다(기본적으로 켜기).

다음 단계

• 클러스터 준비
• 프로덕션 클러스터에 배포
• 가시성 구성
• 배포 보안