다음을 통해 공유

이벤트 허브(Apache Kafka 토픽)에 동적으로 파티션 추가

  • 아티클

Event Hubs는 각 소비자가 메시지 스트림의 특정 하위 집합 또는 파티션만 읽는 분할된 소비자 패턴을 통해 메시지 스트리밍을 제공합니다. 이 패턴은 이벤트 처리를 위한 수평적 확장을 가능하게 하고 큐 및 토픽에서 사용할 수 없는 다른 스트림 중심 기능을 제공합니다. 파티션은 Event Hub에서 보유하는 순서가 지정된 이벤트 시퀀스입니다. 최신 이벤트가 도착하면 이 시퀀스의 끝에 추가됩니다. 일반적으로 파티션에 대한 자세한 내용은 파티션을 참조 하세요.

이벤트 허브를 만들 때 파티션 수를 지정할 수 있습니다. 일부 시나리오에서는 이벤트 허브를 만든 후 파티션을 추가해야 할 수 있습니다. 이 문서에서는 기존 이벤트 허브에 파티션을 동적으로 추가하는 방법을 설명합니다.

Important

파티션의 동적 추가는 Event Hubs의 프리미엄 및 전용 계층에서만 사용할 수 있습니다.

참고 항목

Apache Kafka 클라이언트의 경우 이벤트 허브는 Kafka 토픽에 매핑됩니다. Azure Event Hubs와 Apache Kafka 간의 추가 매핑은 Kafka 및 Event Hubs 개념 매핑을 참조 하세요.

파티션 수 업데이트

이 섹션에서는 다양한 방식으로 이벤트 허브의 파티션 수를 업데이트하는 방법을 보여 줍니다(PowerShell, CLI 등).

PowerShell

Set-AzEventHub PowerShell 명령을 사용하여 이벤트 허브에서 파티션을 업데이트합니다.

Set-AzEventHub -ResourceGroupName MyResourceGroupName -Namespace MyNamespaceName -Name MyEventHubName -partitionCount 12

CLI

az eventhubs eventhub update CLI 명령을 사용하여 이벤트 허브에서 파티션을 업데이트합니다.

az eventhubs eventhub update --resource-group MyResourceGroupName --namespace-name MyNamespaceName --name MyEventHubName --partition-count 12

Resource Manager 템플릿

Resource Manager 템플릿에서 속성 값을 partitionCount 업데이트하고 템플릿을 다시 배포하여 리소스를 업데이트합니다.

    {
        "apiVersion": "2017-04-01",
        "type": "Microsoft.EventHub/namespaces/eventhubs",
        "name": "[concat(parameters('namespaceName'), '/', parameters('eventHubName'))]",
        "location": "[parameters('location')]",
        "dependsOn": [
            "[resourceId('Microsoft.EventHub/namespaces', parameters('namespaceName'))]"
        ],
        "properties": {
            "messageRetentionInDays": 7,
            "partitionCount": 12
        }
    }

Apache Kafka

AlterTopics API(예: kafka-topics CLI 도구를 통해)를 사용하여 파티션 수를 늘립니다. 자세한 내용은 Kafka 항목 수정을 참조 하세요.

Event Hubs 클라이언트

이벤트 허브에서 파티션 수를 업데이트할 때 Event Hubs 클라이언트가 어떻게 동작하는지 살펴보겠습니다.

기존 짝수 허브에 파티션을 추가하면 이벤트 허브 클라이언트는 서비스로부터 엔터티 메타데이터(엔터티는 이벤트 허브이고 메타 데이터는 파티션 정보임)가 변경되었음을 알리는 MessagingException을 받습니다. 클라이언트는 AMQP 링크를 자동으로 다시 열고 변경된 메타데이터 정보를 선택합니다. 그러면 클라이언트가 정상적으로 작동합니다.

발신자/생산자 클라이언트

Event Hubs는 세 가지 보낸 사람 옵션을 제공합니다.

  • 파티션 보낸 사람 – 이 시나리오에서 클라이언트는 파티션에 직접 이벤트를 보냅니다. 파티션을 식별할 수 있고 이벤트를 직접 보낼 수 있지만 이 패턴은 권장하지 않습니다. 파티션을 추가해도 이 시나리오에는 영향을 주지 않습니다. 새로 추가된 파티션을 검색할 수 있도록 애플리케이션을 다시 시작하는 것이 좋습니다.
  • 파티션 키 보낸 사람 – 이 시나리오에서 클라이언트는 해당 키에 속하는 모든 이벤트가 동일한 파티션에 있도록 키와 함께 이벤트를 보냅니다. 이 경우 서비스는 키를 해시하고 해당 파티션으로 라우팅합니다. 파티션 수 업데이트로 인해 해시 변경으로 인해 순서가 바뀐 문제가 발생할 수 있습니다. 따라서 순서 지정에 관심이 있는 경우 파티션 수를 늘리기 전에 애플리케이션이 기존 파티션의 모든 이벤트를 사용하는지 확인합니다.
  • 라운드 로빈 발신자(기본값) – 이 시나리오에서는 Azure Event Hubs 서비스가 파티션 간에 이벤트를 라운드 로빈하고 부하 분산 알고리즘도 사용합니다. Azure Event Hubs 서비스는 파티션 수 변경 내용을 인식하고 파티션 수를 변경한 후 몇 초 내에 새 파티션으로 보냅니다.

수신자/소비자 클라이언트

Event Hubs는 직접 수신기와 이벤트 프로세서라는 쉬운 소비자 라이브러리를 제공합니다.

  • 직접 수신기 – 직접 수신기는 특정 파티션을 수신 대기합니다. 해당 런타임 동작은 이벤트 허브에 대해 파티션을 확장할 때 영향을 받지 않습니다. 직접 수신자를 사용하는 애플리케이션이 새 파티션을 선택하고 그에 따라 수신자를 할당해야 합니다.

  • 이벤트 프로세서 호스트 – 이 클라이언트는 엔터티 메타데이터를 자동으로 새로 고치지 않습니다. 따라서 파티션 수 증가를 선택하지 않습니다. 이벤트 프로세서 인스턴스를 다시 만들면 엔터티 메타데이터 가져오기가 발생하며, 그러면 새로 추가된 파티션에 대한 새 Blob이 만들어집니다. 기존 Blob은 영향을 받지 않습니다. 모든 이벤트 프로세서 인스턴스를 다시 시작하면 모든 인스턴스가 새로 추가된 파티션을 인식하고 부하 분산이 소비자 간에 올바르게 처리되도록 하는 것이 좋습니다.

    이전 버전의 .NET SDK(WindowsAzure.ServiceBus)를 사용하는 경우 이벤트 프로세서 호스트는 검사point의 파티션 수가 서비스에서 가져온 파티션 수와 일치하지 않는 경우 다시 시작할 때 기존 검사포인트를 제거합니다. 이 동작은 애플리케이션에 영향을 줄 수 있습니다.

    2026년 9월 30일에 Azure SDK 지침을 따르지 않는 Azure Service Bus SDK 라이브러리 WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus 및 com.microsoft.azure.servicebus를 사용 중지합니다. 또한 SBMP 프로토콜에 대한 지원이 종료되므로 2026년 9월 30일 이후에는 더 이상 이 프로토콜을 사용할 수 없습니다. 해당 날짜 마이그레이션에 중요한 보안 업데이트와 개선된 기능을 제공하는 최신 Azure SDK 라이브러리로 마이그레이션합니다.

    이전 라이브러리는 2026년 9월 30일 이후에도 계속 사용할 수 있지만 더 이상 Microsoft로부터 공식 지원 및 업데이트를 받을 수 없습니다. 자세한 내용은 사용 중지 공지 지원을 참조하세요.

Apache Kafka 클라이언트

이 섹션에서는 Azure Event Hubs의 Kafka 엔드포인트를 사용하는 Apache Kafka 클라이언트가 이벤트 허브에 대한 파티션 수가 업데이트될 때 어떻게 동작하는지 설명합니다.

Apache Kafka 프로토콜과 함께 Event Hubs를 사용하는 Kafka 클라이언트는 AMQP 프로토콜을 사용하는 이벤트 허브 클라이언트와 다르게 동작합니다. Kafka 클라이언트는 밀리초마다 metadata.max.age.ms 한 번씩 메타데이터를 업데이트합니다. 클라이언트 구성에서 이 값을 지정합니다. 라이브러리도 librdkafka 동일한 구성을 사용합니다. 메타데이터 업데이트는 파티션 수 증가를 포함하여 서비스 변경 내용을 클라이언트에 알릴 수 있습니다. 구성 목록은 Azure Event Hubs에 대한 Apache Kafka 구성을 참조하세요.

발신자/생산자 클라이언트

생산자는 항상 전송 요청에 생성된 각 레코드 집합에 대한 파티션 대상이 포함되도록 지시합니다. 따라서 모든 생성 분할은 브로커의 메타데이터에 대한 생산자의 뷰를 사용하여 클라이언트 쪽에서 수행됩니다. 새 파티션이 생산자의 메타데이터 보기에 추가되면 생산자 요청에 사용할 수 있습니다.

소비자/수신자 클라이언트

소비자 그룹 멤버가 메타데이터 새로 고침을 수행하고 새로 만든 파티션을 선택하면 해당 멤버가 그룹 재조정을 시작합니다. 그러면 소비자 메타데이터가 모든 그룹 멤버에 대해 새로 고쳐지고 할당된 리밸런스 리더가 새 파티션을 할당합니다.

권장 사항

  • 생산자 애플리케이션에서 파티션 키를 사용하고 파티션에서 순서를 확인하기 위해 키 해시를 사용하는 경우 파티션을 동적으로 추가하는 것은 권장되지 않습니다.

    Important

    기존 데이터는 순서를 유지하지만 파티션 추가로 인해 파티션 수가 변경된 후 해시된 메시지에 대해 파티션 해시가 끊어집니다.

  • 다음 경우 기존 토픽 또는 이벤트 허브 인스턴스에 파티션을 추가하는 것이 좋습니다.

    • 이벤트를 보내는 기본 메서드를 사용하는 경우
    • Kafka 기본 분할 전략(예 – Sticky Assignor 전략)

다음 단계

파티션에 대한 자세한 내용은 파티션을 참조 하세요.