디스크 지원 메시지 버퍼 동작 구성

Important

이 설정을 사용하려면 Broker 리소스를 수정해야 하며 Azure CLI 또는 Azure Portal을 사용하여 초기 배포 시에만 구성할 수 있습니다. 브로커 구성 변경이 필요한 경우 새 배포가 필요합니다. 자세한 내용은 기본 Broker 사용자 지정을 참조하세요.

디스크 지원 메시지 버퍼 기능은 MQTT Broker 분산 MQTT Broker 내에서 메시지 큐를 효율적으로 관리하는 데 사용됩니다. 이점은 다음과 같습니다.

• 효율적인 큐 관리: MQTT 브로커에서 각 구독자는 메시지 큐와 연결됩니다. 구독자가 메시지를 처리하는 속도는 큐의 크기에 직접적인 영향을 줍니다. 구독자가 메시지를 느리게 처리하거나 연결을 끊지만 MQTT 영구 세션을 요청하는 경우 큐가 사용 가능한 메모리보다 커질 수 있습니다.

• 영구 세션에 대한 데이터 보존: 디스크 지원 메시지 버퍼 기능은 큐가 사용 가능한 메모리를 초과할 때 디스크에 원활하게 버퍼링되도록 합니다. 이 기능은 데이터 손실을 방지하고 MQTT 영구 세션을 지원하므로 구독자는 다시 연결 시 메시지 큐를 그대로 사용하여 세션을 다시 시작할 수 있습니다. 디스크는 임시 스토리지로 사용되며 메모리에서 분산되는 역할을 합니다. 디스크에 기록된 데이터는 지속성이 없으며 Pod가 종료될 때 손실되지만 각 백 엔드 체인에서 하나 이상의 Pod가 작동하는 한 브로커 전체가 데이터를 손실하지 않습니다.

• 연결 문제 처리: 클라우드 커넥터는 네트워크 연결 끊김으로 인해 Event Grid MQTT Broker와 같은 외부 시스템과 통신할 수 없는 경우 연결 문제에 직면할 수 있는 영구 세션이 있는 구독자로 처리됩니다. 이러한 시나리오에서는 메시지(PUBLISHes)가 누적됩니다. MQTT 브로커는 연결이 복원될 때까지 이러한 메시지를 메모리 또는 디스크에 지능적으로 버퍼링하여 메시지 무결성을 보장합니다.

기본적으로 디스크 지원 메시지 버퍼 기능은 사용하지 않도록 설정됩니다. 이 경우 메시지는 메모리에 남아 있고 판독기 풀 또는 스크래치 풀이 구독자 큐 제한에 정의된 한도에 도달하면 클라이언트에 다시 압력이 적용됩니다.

디스크 지원 메시지 버퍼 구성은 특히 메시지 처리 속도 및 연결이 중요한 시나리오에서 강력하고 신뢰할 수 있는 메시지 큐 시스템을 유지하는 데 필수적입니다.

참고 항목

MQTT 브로커는 추가 암호화 없이 클라이언트에서 받은 것과 정확하게 데이터를 디스크에 씁니다. 브로커가 저장한 데이터를 보호하려면 디스크 보안이 필수적입니다.

구성 옵션

디스크 지원 메시지 버퍼를 구성하려면 Broker 리소스의 diskBackedMessageBuffer 섹션을 편집합니다. 현재 이 기능은 명령을 사용하여 Azure IoT 작업을 배포할 때만 플래그를 az iot ops create 사용하여 --broker-config-file 지원됩니다.

시작하려면 DiskBackedMessageBuffer API 참조에 따라 Broker 구성 파일을 준비합니다.

예를 들어 가장 간단한 구성에는 최대 크기만 지정하는 것이 포함됩니다. 이 경우 볼륨이 emptyDir 탑재됩니다. 이 maxSize 값은 볼륨의 emptyDir 크기 제한으로 사용됩니다. 그러나 볼륨의 제한 사항을 제공하는 가장 선호도가 낮은 옵션입니다 emptyDir .

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

디스크 지원 메시지 버퍼 구성을 개선하려면 메시지 버퍼에 대한 전용 스토리지 볼륨을 탑재할 임시 볼륨 또는 영구 볼륨 클레임을 지정합니다. 예시:

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

다음 설정을 조정하여 브로커 메시지 버퍼 옵션을 조정합니다.

• 볼륨 구성: 메시지 버퍼에 대한 전용 스토리지 볼륨을 탑재할 볼륨 클레임 템플릿을 지정합니다.

• 스토리지 클래스 선택: storageClassName 속성을 사용하여 원하는 StorageClass를 정의합니다.

• 액세스 모드 정의: 볼륨에 필요한 액세스 모드를 결정합니다. 자세한 내용은 영구 볼륨 액세스 모드를 참조하세요.

다음 섹션을 사용하여 다양한 볼륨 모드를 이해합니다.

• 사용 후 삭제 볼륨 이 기본 옵션입니다.
• 영구 볼륨 은 다음으로 선호되며,
• emptyDir 볼륨 이 가장 선호하지 않습니다.

영구 볼륨과 임시 볼륨은 모두 일반적으로 동일한 스토리지 클래스에서 제공됩니다. 두 옵션을 모두 사용할 수 있는 경우 임시 옵션을 선택합니다. 임시 볼륨에는 Kubernetes 1.23 이상이 필요합니다.

팁

EVC(임시 볼륨 클레임) 또는 PVC(영구 볼륨 클레임) 템플릿을 지정하면 선택한 스토리지 클래스를 사용하여 일부 배포 시나리오에 대한 유연성을 높일 수 있습니다. 예를 들어 PVC 템플릿을 사용하여 프로비전된 PV(영구 볼륨)는 클러스터 상태를 검사하는 데 유용할 수 있는 명령과 같은 kubectl get pv명령에 표시됩니다.

Kubernetes 노드에 메시지 버퍼에 대한 충분한 로컬 디스크 공간이 부족한 경우 Azure Blob과 같은 네트워크 스토리지를 제공하는 스토리지 클래스를 사용합니다. 그러나 메시지 버퍼는 빠른 액세스의 이점을 활용하며 내구성이 필요하지 않으므로 일반적으로 더 작은 maxSize 값으로 로컬 디스크를 사용하는 것이 좋습니다.

디스크 지원 메시지 버퍼를 사용하여 Azure IoT Operations 배포

디스크 지원 메시지 버퍼를 사용하려면 플래그가 있는 --broker-config-file 명령을 사용하여 az iot ops create Azure IoT 작업을 배포합니다. 다음 명령(간결성을 위해 생략된 다른 매개 변수)을 참조하세요.

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

배포 후에는 이 설정을 변경할 수 없습니다. 디스크 지원 메시지 버퍼 구성을 변경하려면 Azure IoT Operations 인스턴스를 다시 배포합니다.

임시 볼륨

임시 볼륨은 메시지 버퍼에 대한 기본 옵션입니다.

임시 볼륨의 경우 스토리지 공급자에 대한 고려 사항 섹션의 조언을 따릅니다.

속성 값 ephemeralVolumeClaimSpec 은 백 엔드 체인의 StatefulSet 사양에서 볼륨의 속성으로 ephemeral.volumeClaimTemplate.spec 사용됩니다.

예를 들어 용량이 1GB인 임시 볼륨을 사용하려면 Broker 리소스에 다음 매개 변수를 지정합니다.

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

영구 볼륨

영구 볼륨은 임시 볼륨 이후 메시지 버퍼에 대해 다음으로 선호되는 옵션입니다.

영구 볼륨의 경우 스토리지 공급자에 대한 고려 사항 섹션의 조언을 따르세요.

속성 값 persistentVolumeClaimSpec 은 백 엔드 체인의 StatefulSet 사양 속성으로 volumeClaimTemplates.spec 사용됩니다.

예를 들어 용량이 1GB인 영구 볼륨을 사용하려면 Broker 리소스에 다음 매개 변수를 지정합니다.

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

emptyDir 음량

emptyDir 볼륨은 영구 볼륨 이후 가장 선호도가 낮은 옵션입니다.

파일 시스템 할당량이 있는 클러스터를 사용하는 경우에만 emptyDir볼륨을 사용합니다. 자세한 내용은 파일 시스템 프로젝트 할당량 탭의 세부 정보를 참조하세요. 기능을 사용하도록 설정하지 않으면 클러스터는 제한을 적용하지 않고 호스트 노드가 디스크 공간을 채우고 전체 호스트 노드를 비정상으로 표시할 수 있도록 주기적인 검사를 수행합니다.

예를 들어 용량이 1GB인 emptyDir 볼륨을 사용하려면 Broker 리소스에 다음 매개 변수를 지정합니다.

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

스토리지 공급자에 대한 고려 사항

선택한 스토리지 공급자의 동작을 고려합니다. 예를 들어 rancher.io/local-path와 같은 공급자를 사용하는 경우입니다. 공급자가 제한을 지원하지 않는 경우 볼륨을 채우면 노드의 디스크 공간이 소비됩니다. 이로 인해 Kubernetes가 노드 및 연결된 모든 Pod를 비정상으로 표시할 수 있습니다. 이러한 시나리오에서 스토리지 공급자가 어떻게 동작하는지 이해하는 것이 중요합니다.

사용 안 함

디스크 지원 메시지 버퍼를 사용하지 않으려면 Broker 리소스에 diskBackedMessageBufferSettings 속성을 포함하지 마세요. 이 동작도 기본 동작입니다.

지속성

디스크 지원 메시지 버퍼 기능은 지속성과 동의어가 아님을 이해하는 것이 중요합니다. 이 컨텍스트에서 지속성은 Pod를 다시 시작해도 유지되는 데이터를 나타냅니다. 그러나 이 기능은 디스크에 데이터를 저장할 임시 스토리지 공간을 제공하여 Pod를 다시 시작하는 동안 메모리 오버플로와 데이터 손실을 방지합니다.