Apache Kafka용 관리형 서비스 클러스터의 크기 계획

이 문서에서는 Managed Service for Apache Kafka 클러스터에 필요한 용량을 추정하는 방법과 기존 클러스터의 크기를 조정하는 방법을 설명합니다.

Managed Service for Apache Kafka 클러스터를 만들 때 클러스터 크기에 대해 다음 매개변수를 선택합니다.

  • vCPUs: 클러스터의 vCPU 수입니다. 최소 vCPU 수는 3개입니다.

  • 메모리: vCPU당 메모리 양입니다. vCPU당 1GiB에서 8GiB 사이를 프로비저닝해야 합니다.

클러스터가 생성된 후에는 이 값을 업데이트할 수 있습니다.

초기 클러스터 크기 선택

초기 클러스터 크기를 선택하려면 특정 워크로드를 기반으로 다음 값을 추정하는 것으로 시작합니다.

  • 쓰기 처리량: 프로듀서가 클러스터에 데이터를 전송하는 총 속도(MBps)입니다.
  • 읽기 처리량: 소비자가 클러스터에서 데이터를 읽는 총 속도(MBps)입니다.

이 처리량을 처리하는 데 필요한 클러스터 크기를 추정하려면 다음 단계를 수행하세요.

  1. 복제를 포함한 총 쓰기 대역폭을 계산합니다.

    Total write bandwidth = produce rate * replicas

    이 값에는 클라이언트에서 리더 브로커로, 리더에서 복제본 브로커로의 대역폭이 포함됩니다. 기본 복제본 수는 3개입니다.

  2. 복제를 포함한 총 읽기 대역폭을 계산합니다.

    Total read bandwidth = consume rate + produce rate * ( replicas - 1)

    이 값에는 클라이언트의 읽기 작업 (소비 속도)을 위한 대역폭과 복제본이 동기화 상태를 유지하는 데 필요한 대역폭이 포함됩니다. 복제본은 파티션 리더에서 데이터를 읽어 동기화합니다. 파티션 리더는 복제본에서 읽지 않으므로 (replicas - 1) 항이 사용됩니다.

  3. 쓰기 등가 데이터 속도를 계산합니다.

    일반적으로 읽기 대역폭은 쓰기 대역폭보다 처리 효율성이 4배 더 높습니다. 이 차이를 고려하려면 다음과 같이 쓰기 등가 데이터 속도를 계산합니다.

    Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)

  4. 타겟 vCPU 사용률을 결정합니다. 이 값은 vCPU 용량의 비율로 평균 vCPU 사용률을 나타냅니다. 실제 사용률은 시간이 지남에 따라 급증하거나 급락할 수 있습니다.

    • 기준으로 사용률 타겟을 50%로 시작합니다.
    • 예상 트래픽 패턴을 알고 있는 경우 사용률 타겟을 수용해야 하는 최대 대역폭에 대한 평균 쓰기 등가 대역폭의 비율과 같게 설정합니다.

    일반적으로 사용률을 높이면 클러스터 크기가 줄어들어 비용이 절감되지만 트래픽이 추정치를 초과하면 위험도 높아집니다. 과도한 vCPU 사용률은 지연 시간이 길어지고 오류가 발생할 수 있습니다.

  5. vCPU 수를 계산합니다.

    vCPU count = ceiling (write-equivalent rate / 20 MBps / utilization)

    단일 영역의 단일 vCPU에 대한 예상 용량은 20MBps입니다. 따라서 vCPU가 100% 사용률로 실행되는 경우 (write-equivalent rate / 20) vCPU가 필요합니다. 실제 수를 얻으려면 해당 값을 타겟 사용률로 나누고 올림합니다.

    또한 10KB보다 작은 배치로 메시지를 전송하면 여기의 벤치마크에 비해 CPU당 처리량이 줄어듭니다. 이 경우 처리량 용량 감소를 고려하거나 더 큰 배치를 전송하는 것이 좋습니다.

  6. 필요한 메모리를 추정합니다. 각 vCPU에 4GiB의 RAM을 사용하는 것이 좋습니다.

    Memory = vCPU count * 4 GiB

가장 정확한 크기 조정을 위해 실제 워크로드로 테스트합니다. 클러스터의 리소스 사용량을 모니터링하고 필요한 경우 확장합니다.

크기 계산 예

워크로드의 쓰기 속도가 50MBps이고 읽기 속도가 100MBps이며 복제본이 3개이고 타겟 vCPU 사용률이 50%라고 가정합니다.

  1. Total write bandwidth = 50 MBps * 3 replicas = 150 MBps
  2. Total read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBps
  3. Write-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBps
  4. Target utilization = 0.5
  5. Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUs
  6. Memory = 20 vCPUs * 4 GiB = 80 GiB

중개업체

클러스터를 만들면 시스템은 3개 영역 각각에 하나 이상의 브로커를 프로비저닝합니다. 브로커는 영역 전체에 최대한 균등하게 분산되며 모든 브로커의 vCPU 수는 동일합니다. 브로커 수는 다음 수식으로 계산할 수 있습니다.

number of brokers = max(3, ceiling(vCPUs / 15))

예를 들어 vCPU가 75개인 클러스터는 브로커 5개로 시작합니다.

vCPU 수를 변경하면 브로커당 최대 15개의 vCPU까지 기존 브로커에 분산됩니다. 클러스터 크기를 브로커당 15개의 vCPU를 초과하여 늘리면 시스템에서 새 브로커를 프로비저닝합니다. 새 브로커가 프로비저닝되면 1개의 vCPU로 축소할 수 있지만 삭제할 수는 없습니다.

파티션 복제본 한도

클러스터 크기를 조정할 때 고려해야 할 클러스터당 및 브로커당 파티션 복제본 수에 한도가 있습니다.

클러스터당 한도는 파티션 복제본 100,000개입니다. 이는 엄격한 한도이며 클러스터의 브로커 수와는 무관합니다. 워크로드에 100,000개가 넘는 파티션 복제본이 필요한 경우 두 개 이상의 클러스터로 분할하는 것이 좋습니다.

브로커당 한도는 파티션 복제본 4,000개입니다. 이는 엄격한 한도가 아닙니다. 이보다 많은 복제본을 처리해야 하는 경우 브로커를 더 프로비저닝하는 것이 좋습니다. 최대 브로커 크기만큼 클러스터의 vCPU 크기를 늘려 브로커 수를 늘릴 수 있습니다. 파티션을 처리할 수 있는 충분한 수의 브로커가 있으면 처리량을 수용하도록 브로커 크기를 조정할 수 있습니다.

클러스터 크기 업데이트

Managed Service for Apache Kafka 클러스터를 만든 후에는 필요에 따라 vCPU 수와 메모리를 조정할 수 있습니다. 기존 클러스터를 업데이트할 때 다음 규칙이 적용됩니다.

  • 클러스터의 전체 vCPU 대 메모리 비율은 항상 1:1에서 1:8 사이를 유지해야 합니다.

  • 축소하는 경우 기존 브로커마다 vCPU 1개와 메모리 1GiB가 있어야 합니다. 브로커 수는 줄어들지 않습니다.

  • 확장하고 변경으로 인해 새 브로커가 추가되는 경우 브로커당 평균 vCPU 및 메모리는 업데이트 전 평균에 비해 10% 이상 감소할 수 없습니다.

    예를 들어 클러스터를 vCPU 45개 (브로커 3개)에서 vCPU 48개 (브로커 4개)로 확장하려고 하면 작업이 실패합니다. 이는 브로커당 평균 vCPU가 15개에서 12개로 20% 감소하여 10% 한도를 초과하기 때문입니다.

CPU 수를 10% 이상 줄여야 하는 경우 여러 단계로 줄이는 것이 좋습니다. 각 업데이트 후에는 리소스 사용률을 모니터링하고 필요한 경우 파티션의 균형을 다시 맞춥니다.

하지만 업데이트 후 브로커에 충분한 용량이 있다고 확신하는 경우 이 체크를 사용 중지할 수 있습니다. 체크를 사용 중지하려면 gcloud managed-kafka clusters update 명령어에서 allow_broker_downscale_on_cluster_upscale 플래그를 true로 설정합니다. 이 플래그는 잠재적인 성능 위험을 수락한다는 신호입니다.

클러스터를 업데이트하려면 Apache Kafka용 관리형 서비스 클러스터 업데이트를 참고하세요.

업데이트 작업 예

다음 예는 vCPU 75개, RAM 130GiB, 브로커 5개가 있는 클러스터로 시작합니다.

실패한 확장 작업의 예

클러스터를 vCPU 80개 및 RAM 140GiB 로 확장합니다.

  • 서비스는 새 브로커가 필요한지 확인합니다.

    • ceiling (80 vCPUs / 15) = 6 brokers

    클러스터가 브로커 5개에서 6개로 증가하므로 10% 안전 체크가 트리거됩니다.

  • 브로커당 현재 평균은 다음과 같습니다.

    • 75 vCPUs / 5 brokers = 15 vCPUs per broker

    • 130 GiB / 5 brokers = 26 GiB per broker

  • 브로커가 6개인 경우 새 평균은 다음과 같습니다.

    • 80 vCPUs / 6 brokers = 13.33 vCPUs per broker, 11.1% 감소

    • 140 GiB / 6 brokers = 23.33 GiB per broker, 10.2% 감소

    이러한 평균이 10%를 초과하므로 작업이 실패합니다.

성공적인 확장 작업의 예

클러스터를 vCPU 85개 및 RAM 150GiB 로 확장합니다.

  • 서비스는 새 브로커가 필요한지 확인합니다.

    • ceiling (85 vCPUs / 15) = 6 brokers

    클러스터가 브로커 5개에서 6개로 증가하므로 10% 안전 체크가 트리거됩니다.

  • 브로커당 현재 평균은 다음과 같습니다.

    • 75 vCPUs / 5 brokers = 15 vCPUs per broker

    • 130 GiB / 5 brokers = 26 GiB per broker

  • 브로커가 6개인 경우 새 평균은 다음과 같습니다.

    • 85 vCPUs / 6 brokers = 14.17 vCPUs per broker, 5.5% 감소

    • 150 GiB / 6 brokers = 25 GiB per broker, 3.8% 감소

브로커당 평균 vCPU 및 메모리 감소가 10% 한도 내에 있으므로 이 작업은 성공합니다.

다음 단계