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

아티클
02/14/2025

Important

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

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

효율적인 큐 관리: MQTT 브로커에서 각 구독자는 메시지 큐와 연결됩니다. 구독자의 메시지 처리 속도는 큐 크기에 직접 영향을 줍니다. 구독자가 메시지를 느리게 처리하거나 연결을 끊지만 MQTT 영구 세션을 요청하는 경우 큐가 사용 가능한 메모리보다 커질 수 있습니다.
영구 세션에 대한 데이터 보존: 디스크 지원 메시지 버퍼 기능은 큐가 사용 가능한 메모리를 초과할 때 디스크에 원활하게 버퍼링되도록 합니다. 이 기능은 데이터 손실을 방지하고 MQTT 영구 세션을 지원하므로 구독자는 다시 연결할 때 메시지 큐를 그대로 사용하여 세션을 다시 시작할 수 있습니다. 디스크는 임시 스토리지로 사용되며 메모리에서 분산되는 역할을 합니다. 디스크에 기록된 데이터는 지속성이 없으며 Pod가 종료되면 손실됩니다. 각 백 엔드 체인에서 하나 이상의 Pod가 계속 작동하는 경우 브로커 전체가 데이터를 손실하지 않습니다.
연결 문제 처리: 클라우드 커넥터는 네트워크 연결 끊김으로 인해 Azure Event Grid MQTT 브로커와 같은 외부 시스템과 통신할 수 없는 경우 연결 문제에 직면할 수 있는 영구 세션이 있는 구독자로 취급됩니다. 이러한 시나리오에서는 메시지(PUBLISHes)가 누적됩니다. MQTT 브로커는 연결이 복원될 때까지 이러한 메시지를 메모리 또는 디스크에 지능적으로 버퍼링하여 메시지 무결성을 보장합니다.

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

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

참고 항목

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

구성 옵션

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

시작하려면 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 .
액세스 모드 정의: 볼륨에 필요한 액세스 모드를 결정합니다. 자세한 내용은 영구 볼륨 액세스 모드를 참조 하세요.

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

임시 볼륨이 기본 옵션입니다.
영구 볼륨 은 다음으로 기본 설정 옵션입니다.
emptyDir 볼륨 은 가장 선호도가 낮은 옵션입니다.

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

팁

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

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

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

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

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

배포 후에는 이 설정을 변경할 수 없습니다. 디스크 지원 메시지 버퍼 구성을 변경하려면 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 클러스터를 사용하는 경우에만 볼륨을 사용합니다. 자세한 내용은 파일 시스템 프로젝트 할당량 탭을 참조 하세요. 기능을 사용하도록 설정하지 않으면 클러스터는 제한을 적용하지 않고 호스트 노드가 디스크 공간을 채우고 전체 호스트 노드를 비정상으로 표시할 수 있도록 주기적인 검사를 수행합니다.

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

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

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

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

사용 안 함

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

지속성

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

다음을 통해 공유