배포 계획 - 디스크 기반 메시지 버퍼

디스크 지원 메시지 버퍼는 MQTT 브로커가 사용 가능한 메모리를 초과할 때 구독자 메시지 큐를 디스크에 분산할 수 있게 하는 기능입니다. 배포 전에 MQTT 브로커에 대한 디스크 지원 메시지 버퍼링이 필요한지 여부를 결정합니다.

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

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

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

디스크 기반 메시지 버퍼 구성

디스크 기반 메시지 버퍼를 구성하려면 Broker 리소스의 diskBackedMessageBuffer 섹션을 편집하십시오. 현재 이 구성은 --broker-config-file 명령을 사용하여 Azure IoT 작업 배포할 때 az iot ops create 플래그를 사용해야만 지원됩니다. 자세한 내용은 고급 MQTT broker 구성에 대한 Azure CLI 지원을 참조하세요.

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

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

그런 다음 플래그를 --broker-config-file 사용하여 IoT 작업을 배포합니다(간단히 하기 위해 생략된 다른 매개 변수).

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

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

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

더 나은 디스크 기반 메시지 버퍼 구성을 위해 메시지 버퍼용 전용 스토리지 볼륨을 마운트하도록 임시 볼륨 또는 영구 볼륨 클레임을 지정하세요. 다음은 그 예입니다.

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

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

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

• 볼륨 구성: 메시지 버퍼에 대한 전용 스토리지 볼륨을 탑재할 볼륨 클레임 템플릿을 지정합니다.
• 스토리지 클래스 선택: 속성을 사용하여 원하는 스토리지 클래스를 정의합니다 storageClassName .
• 액세스 모드 정의: 볼륨에 필요한 액세스 모드를 결정합니다. 자세한 내용은 영구 볼륨 액세스 모드를 참조하세요.

임시 볼륨

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

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

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

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

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

영구 볼륨

영구 볼륨 은 임시 볼륨 이후 메시지 버퍼에 대한 다음 기본 설정 옵션입니다.

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

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

예를 들어 용량이 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 속성을 포함하지 마세요. 이 동작도 기본값입니다.

디스크 버퍼와 지속성 비교

디스크 기반 메시지 버퍼와 브로커 지속성은 모두 데이터를 디스크에 쓰지만, 용도는 서로 다릅니다:

다음 단계

• 지속성 설정 검토
• 진단 설정 검토
• 고급 MQTT 옵션 검토
• 클러스터 준비