고가용성, 크기 조정 및 메모리 사용량에 대한 broker 설정 구성

브로커 리소스는 MQTT 브로커에 대한 전체 설정을 정의하는 주요 리소스입니다. 또한 프런트 엔드 및 백 엔드와 같이 Broker 구성을 실행하는 Pod의 수와 유형을 결정합니다. 브로커 리소스를 사용하여 메모리 프로필을 구성할 수도 있습니다. 자동 복구 메커니즘이 브로커에 기본 제공되며 종종 구성 요소 오류에서 자동으로 복구할 수 있습니다. 예를 들어 고가용성을 위해 구성된 Kubernetes 클러스터에서 노드가 실패합니다.

프런트 엔드 복제본 및 백 엔드 파티션을 추가하여 MQTT 브로커의 수평 크기를 조정할 수 있습니다. 프런트 엔드 복제본은 클라이언트에서 MQTT 연결을 수락하고 백 엔드 파티션으로 전달해야 합니다. 백 엔드 파티션은 클라이언트에 메시지를 저장하고 전달하는 작업을 담당합니다. 프런트 엔드 Pod는 백 엔드 Pod에 메시지 트래픽을 분산하고 백 엔드 중복 요소는 클러스터의 노드 오류에 대한 복원력을 제공하기 위해 데이터 복사본 수를 결정합니다.

사용 가능한 설정 목록은 Broker API 참조를 참조하세요.

스케일링 설정 구성

MQTT broker의 크기 조정 설정을 구성하려면 Azure IoT Operations 배포 중에 Broker 리소스 사양에 카디널리티 필드를 지정합니다.

자동 배포 카디널리티

배포 중에 초기 카디널리티를 자동으로 확인하려면 Broker 리소스의 카디널리티 필드를 생략합니다.

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

az iot ops create ... --broker-config-file <FILE>.json

MQTT broker 연산자는 배포 시 사용 가능한 노드 수에 따라 적절한 수의 Pod를 자동으로 배포합니다. 이는 고가용성 또는 규모가 필요하지 않은 비프로덕션 시나리오에 유용합니다.

그러나 이는 자동 크기 조정이 아닙니다 . 연산자는 부하에 따라 Pod 수를 자동으로 조정하지 않습니다. 운영자는 클러스터 하드웨어를 기반으로 배포할 초기 Pod 수만 결정합니다. 앞에서 설명한 것처럼 카디널리티는 초기 배포 시간에만 설정할 수 있으며 카디널리티 설정을 변경해야 하는 경우 새 배포가 필요합니다.

카디널리티 직접 구성

카디널리티 설정을 직접 구성하려면 각 카디널리티 필드를 지정합니다.

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

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

az iot ops create ... --broker-config-file <FILE>.json

카디널리티 이해

카디널리티는 집합에 있는 특정 엔터티의 인스턴스 수를 의미합니다. MQTT broker의 컨텍스트에서 카디널리티는 배포할 프런트 엔드 복제본, 백 엔드 파티션 및 백 엔드 작업자 수를 나타냅니다. 카디널리티 설정은 broker를 가로로 확장하고 Pod 또는 노드 오류가 있는 경우 고가용성을 개선하는 데 사용됩니다.

카디널리티 필드는 프런트 엔드 및 backendChain에 대한 하위 필드가 있는 중첩 필드입니다. 이러한 각 하위 필드에는 고유한 설정이 있습니다.

프론트엔드

프런트 엔드 하위 필드는 프런트 엔드 Pod에 대한 설정을 정의합니다. 두 가지 주요 설정은 다음과 같습니다.

• 복제본: 배포할 프런트 엔드 복제본(Pod) 수입니다. 프런트 엔드 복제본 수를 늘리면 프런트 엔드 Pod 중 하나가 실패할 경우 고가용성이 제공됩니다.

• 작업자: 복제본당 논리적 프런트 엔드 작업자 수입니다. 각 작업자는 최대 하나의 CPU 코어를 사용할 수 있습니다.

백 엔드 체인

백 엔드 체인 하위 필드는 백 엔드 파티션에 대한 설정을 정의합니다. 세 가지 주요 설정은 다음과 같습니다.

• 파티션: 배포할 파티션 수입니다. 분할이라는 프로세스를 통해 각 파티션은 메시지의 일부를 토픽 ID 및 세션 ID로 나눕니다. 프런트 엔드 Pod는 파티션 간에 메시지 트래픽을 분산합니다. 파티션 수를 늘리면 브로커가 처리할 수 있는 메시지 수가 증가합니다.

• 중복 요소: 파티션당 배포할 백 엔드 복제본(Pod) 수입니다. 중복 요소를 늘리면 데이터 복사본 수가 증가하여 클러스터의 노드 오류에 대한 복원력을 제공합니다.

• 작업자: 백 엔드 복제본당 배포할 작업자 수입니다. 백 엔드 복제본당 작업자 수를 늘리면 백 엔드 Pod에서 처리할 수 있는 메시지 수가 증가할 수 있습니다. 각 작업자는 최대 2개의 CPU 코어를 사용할 수 있으므로 복제본당 작업자 수를 늘려 클러스터의 CPU 코어 수를 초과하지 않도록 주의해야 합니다.

고려 사항

카디널리티 값을 늘리면 더 많은 연결 및 메시지를 처리하는 broker의 용량이 일반적으로 향상되고 Pod 또는 노드 오류가 있는 경우 고가용성이 향상됩니다. 그러나 이로 인해 리소스 소비가 증가합니다. 따라서 카디널리티 값을 조정할 때 메모리 프로필 설정 및 브로커의 CPU 리소스 요청을 고려합니다. 프런트 엔드 CPU 사용률이 병목 상태임을 발견하면 프런트 엔드 복제본당 작업자 수를 늘리면 CPU 코어 사용률을 높일 수 있습니다. 백 엔드 CPU가 병목 상태인 경우 백 엔드 작업자 수를 늘리면 메시지 처리량에 도움이 될 수 있습니다.

예를 들어 클러스터에 각각 8개의 CPU 코어가 있는 3개의 노드가 있는 경우 노드 수(3)와 일치하도록 프런트 엔드 복제본 수를 설정하고 작업자 수를 1로 설정합니다. 노드 수(3)와 일치하도록 백 엔드 파티션 수를 설정하고 백 엔드 작업자 수를 1로 설정합니다. 중복 요소를 원하는 대로 설정합니다(2 또는 3). 프런트 엔드 CPU가 병목 상태임을 발견하면 프런트 엔드 작업자 수를 늘입니다. 백 엔드 및 프런트 엔드 작업자는 서로 다른 Pod와 CPU 리소스를 놓고 경쟁할 수 있습니다.

메모리 프로필 구성

메모리 프로필 설정 MQTT broker를 구성하려면 Azure IoT Operations 배포 중에 Broker 리소스 사양에 메모리 프로필 필드를 지정합니다.

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

각각 다른 메모리 사용 특성을 가진 몇 가지 메모리 프로필 중에서 선택할 수 있습니다.

매우 작음

이 프로필을 사용하는 경우:

• 각 프런트 엔드 복제본의 최대 메모리 사용량은 약 99MiB이지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.
• 각 백 엔드 복제본의 최대 메모리 사용량은 약 102MiB이고 백 엔드 작업자 수를 곱하지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.

이 프로필을 사용하는 경우 권장 사항:

• 프런트 엔드는 하나만 사용해야 합니다.
• 클라이언트는 대용량 패킷을 보내면 안 됩니다. 4MiB보다 작은 패킷만 보내야 합니다.

낮음

이 프로필을 사용하는 경우:

• 각 프런트 엔드 복제본의 최대 메모리 사용량은 약 387MiB이지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.
• 각 백 엔드 복제본의 최대 메모리 사용량은 백 엔드 작업자 수에 약 390MiB를 곱한 값이지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.

이 프로필을 사용하는 경우 권장 사항:

• 하나 또는 두 개의 프런트 엔드만 사용해야 합니다.
• 클라이언트는 대용량 패킷을 보내면 안 됩니다. 10MiB보다 작은 패킷만 보내야 합니다.

중간

중간은 기본 프로필입니다.

• 각 프런트 엔드 복제본의 최대 메모리 사용량은 약 1.9GiB이지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.
• 각 백 엔드 복제본의 최대 메모리 사용량은 약 1.5GiB에 백 엔드 작업자 수를 곱한 값이지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.

높음

• 각 프런트 엔드 복제본의 최대 메모리 사용량은 약 4.9GiB이지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.
• 각 백 엔드 복제본의 최대 메모리 사용량은 약 5.8GiB에 백 엔드 작업자 수를 곱한 값이지만 실제 최대 메모리 사용량은 더 높을 수 있습니다.

카디널리티 및 Kubernetes 리소스 제한

클러스터에서 리소스가 부족하지 않도록 브로커는 기본적으로 Kubernetes CPU 리소스 제한을 요청하도록 구성됩니다. 복제본 또는 작업자 수를 비례적으로 늘리면 필요한 CPU 리소스가 증가합니다. 클러스터에서 사용할 수 있는 CPU 리소스가 부족한 경우 배포 오류가 발생합니다. 이렇게 하면 요청된 broker 카디널리티에 최적으로 실행하기에 충분한 리소스가 부족한 상황을 방지할 수 있습니다. 또한 잠재적인 CPU 경합 및 Pod 제거를 방지하는 데 도움이 됩니다.

MQTT broker는 현재 프런트 엔드 작업자당 1개(1.0) CPU 단위와 백 엔드 작업자당 2개(2.0) CPU 단위를 요청합니다. 자세한 내용은 Kubernetes CPU 리소스 단위를 참조하세요.

예를 들어 아래 카디널리티는 다음 CPU 리소스를 요청합니다.

• 프런트 엔드의 경우: 프런트 엔드 Pod당 2개의 CPU 단위, 총 6개의 CPU 단위.
• 백 엔드의 경우: 백 엔드 Pod당 4개 CPU 단위(백 엔드 작업자 2개), 시간 2(중복 계수), 3번(파티션 수), 총 24개의 CPU 단위입니다.

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

이 설정을 사용하지 않도록 설정하려면 Broker 리소스에서 필드를 Disabled 설정합니다generateResourceLimits.cpu.

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

az iot ops create ... --broker-config-file <FILE>.json

다중 노드 배포

다중 노드 배포를 통해 고가용성 및 복원력을 보장하기 위해 Azure IoT Operations MQTT 브로커는 백 엔드 Pod에 대한 선호도 방지 규칙을 자동으로 설정합니다.

이러한 규칙은 미리 정의되어 있으며 수정할 수 없습니다.

선호도 방지 규칙의 목적

선호도 방지 규칙은 동일한 파티션의 백 엔드 Pod가 동일한 노드에서 실행되지 않도록 합니다. 이렇게 하면 부하를 분산하고 노드 오류에 대한 복원력을 제공합니다. 특히 동일한 파티션의 백 엔드 Pod는 서로 선호도를 방지합니다.

선호도 방지 설정 확인

백 엔드 Pod에 대한 선호도 방지 설정을 확인하려면 다음 명령을 사용합니다.

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

출력은 다음과 유사한 선호도 방지 구성을 표시합니다.

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

브로커에 대해 설정된 유일한 선호도 방지 규칙입니다.

다음 단계

• MQTT 브로커에 대한 수신기 구성