Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

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

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

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

vCPUs: 클러스터의 vCPU 수입니다. 최소 vCPU 수는 3개입니다.
메모리: vCPU당 메모리 양입니다. vCPU당 1GiB에서 8GiB 사이로 프로비저닝해야 합니다.

클러스터를 만든 후 이러한 값을 업데이트할 수 있습니다.

초기 클러스터 크기 선택

초기 클러스터 크기를 선택하려면 특정 워크로드를 기반으로 다음 값을 추정하세요.

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

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

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

Total write bandwidth = produce rate * replicas

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

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

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

일반적으로 읽기 대역폭은 쓰기 대역폭보다 처리 효율이 4배 더 높습니다. 이 차이를 고려하려면 다음과 같이 쓰기 해당 데이터 전송률을 계산하세요.

Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)
타겟 vCPU 사용률을 결정합니다. 이 값은 vCPU 용량의 백분율로 표시된 평균 vCPU 사용률을 나타냅니다. 실제 사용률은 시간이 지남에 따라 급증하거나 급락할 수 있습니다.
- 기준으로 사용률 목표를 50%로 시작합니다.
- 예상 트래픽 패턴을 알고 있다면 평균 쓰기 등가 대역폭과 수용해야 하는 최대 대역폭의 비율과 동일한 사용률 타겟을 설정합니다.
일반적으로 사용률을 높이면 클러스터 크기가 줄어 비용이 절감되지만 트래픽이 예상치를 초과하면 위험도 커집니다. vCPU 사용률이 과도하면 지연 시간이 길어지고 오류가 발생할 수 있습니다.
vCPU 수를 계산합니다.

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

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

또한 10KB보다 작은 배치로 메시지를 보내면 여기의 벤치마크에 비해 CPU당 처리량이 줄어듭니다. 이 경우 처리량 용량 감소를 고려하거나 더 큰 배치 전송을 고려하세요.
필요한 메모리를 추정합니다. vCPU당 4GiB의 RAM을 사용하는 것이 좋습니다.

Memory = vCPU count * 4 GiB

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

크기 계산 예시

워크로드의 쓰기 속도가 50MBps이고 읽기 속도가 100MBps이며 복제본이 3개이고 목표 vCPU 사용률이 50%라고 가정해 보겠습니다.

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

파티션 복제본 한도

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

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

브로커당 한도는 파티션 복제본 4,000개입니다. 이는 엄격한 한도가 아닙니다. 이 수보다 많은 복제본을 처리해야 하는 경우 클러스터 크기를 늘려 브로커를 더 프로비저닝하는 것이 좋습니다. 서비스에서 브로커 수를 결정하는 방법에 대한 자세한 내용은 브로커 프로비저닝을 참고하세요.

파티션을 처리할 수 있는 브로커가 충분히 있으면 처리량을 수용하도록 브로커 크기를 조정할 수 있습니다.

클러스터 크기 업데이트

Managed Service for Apache Kafka 클러스터를 만든 후 필요에 따라 vCPU 수와 메모리를 조정할 수 있습니다. 자세한 내용은 Managed Service for Apache Kafka 클러스터 업데이트를 참고하세요.

기존 클러스터를 업데이트할 때는 다음 규칙이 적용됩니다.

클러스터의 전체 vCPU 대 메모리 비율은 항상 1:1~1:8 사이여야 합니다.
기존 브로커마다 vCPU가 1개 이상이고 메모리가 1GiB 이상이어야 합니다. 브로커 수는 줄어들지 않습니다.
클러스터에 맞춤 디스크 구성이 있는 경우 업데이트는 로컬 스토리지의 디스크 구성 요구사항을 충족해야 합니다.
스케일업하는 경우 업데이트 전 평균에 비해 브로커당 평균 vCPU와 메모리가 10% 이상 감소할 수 없습니다. 예를 들어 클러스터를 vCPU 45개 (브로커 3개)에서 vCPU 48개 (브로커 4개)로 확장하려고 하면 브로커당 평균 vCPU가 15에서 12로 감소하여 20% 감소하므로 10% 한도를 초과합니다.

vCPU 수를 10% 이상 줄여야 하는 경우 여러 단계에 걸쳐 줄이는 것이 좋습니다. 각 업데이트 후 리소스 사용률을 모니터링하고 필요한 경우 파티션을 리밸런싱합니다.

하지만 업데이트 후 브로커의 용량이 충분하다고 확신하는 경우 allow_broker_downscale_on_cluster_upscale=true 플래그와 함께 gcloud managed-kafka clusters update 명령어를 실행하여 이 검사를 사용 중지할 수 있습니다. 이 플래그는 잠재적인 성능 위험을 수락한다는 신호를 보냅니다.

업데이트 작업 예시

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

실패한 업스케일 작업의 예

클러스터를 vCPU 80개 및 RAM 140GiB로 업스케일링합니다.

서비스는 새 브로커가 필요한지 확인합니다.
- ceiling (80vCPU / 15) = 6개 브로커
클러스터가 브로커 5개에서 6개로 증가하므로 10% 안전 확인이 트리거됩니다.
브로커별 현재 평균은 다음과 같습니다.
- 75vCPU / 5브로커 = 브로커당 15vCPU
- 130GiB/5브로커 = 26GiB/브로커
브로커가 6개인 경우 새로운 평균은 다음과 같습니다.
- vCPU 80개 / 브로커 6개 = 브로커당 vCPU 13.33개, 11.1% 감소
- 140GiB / 6브로커 = 브로커당 23.33GiB, 10.2% 감소
이러한 평균이 10%를 초과하므로 작업이 실패합니다.

성공적인 업스케일 작업의 예

클러스터를 85개 vCPU 및 150GiB RAM으로 업스케일링합니다.

서비스는 새 브로커가 필요한지 확인합니다.
- 상한 (vCPU 85개 / 15) = 브로커 6개
클러스터가 브로커 5개에서 6개로 증가하므로 10% 안전 확인이 트리거됩니다.
브로커별 현재 평균은 다음과 같습니다.
- 75vCPU / 5브로커 = 브로커당 15vCPU
- 130GiB/5브로커 = 26GiB/브로커
브로커가 6개인 경우 새로운 평균은 다음과 같습니다.
- 85vCPU / 6브로커 = 브로커당 14.17vCPU, 5.5% 감소
- 150GiB/6개 브로커 = 25GiB/브로커, 3.8% 감소

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

필요한 디스크 크기 추정

기본적으로 Managed Service for Apache Kafka는 각 브로커에 vCPU당 100GiB를 할당합니다. 기본 할당은 대부분의 워크로드에 충분한 로컬 스토리지를 제공하지만 특정 요구사항에 맞게 브로커 디스크 크기를 구성할 수 있습니다. 이 섹션에서는 필요한 디스크 용량을 추정하는 방법을 설명합니다.

브로커가 메시지를 수신하면 메시지를 로컬 세그먼트 파일에 씁니다. 세그먼트 파일이 최대 크기 또는 기간에 도달하면 닫히고('롤링') 원격 저장소로 이동합니다. 세그먼트 파일의 최대 크기는 log.roll.bytes 설정으로 지정되고 최대 기간은 log.segment.ms 설정으로 지정됩니다.

세그먼트 파일이 롤링되면 브로커가 새 세그먼트 파일을 엽니다. 브로커가 원격 스토리지에 복사하는 동안 롤링된 세그먼트는 로컬 스토리지에 남아 있습니다. 따라서 각 파티션에는 롤링된 세그먼트 파일을 저장할 공간과 롤링된 세그먼트가 원격 저장소로 이동하는 동안 새 세그먼트 파일을 저장할 공간이 충분해야 합니다.

기본적으로 세그먼트 파일의 최대 크기는 230MiB입니다. 사용률이 보통인 클러스터의 경우 롤링된 세그먼트가 이동하는 동안 추가 버퍼 공간을 제공하기 위해 파티션당 250MiB가 필요하다고 가정할 수 있습니다. 이 가정을 사용하면 브로커당 최소 디스크 크기는 다음과 같습니다.

250 MiB * partition count * replication factor / broker count

하지만 필요한 크기는 최대 세그먼트 파일 크기, 클러스터의 부하, 새 데이터가 기록되는 비율, 장기 스토리지에 대한 쓰기 지연 시간과 같은 요인에 따라 달라집니다.

각 브로커에서 사용하지 않는 디스크 용량을 유지하는 것이 중요합니다. 디스크 용량이 없는 브로커의 동작은 예측할 수 없으며 데이터 손실과 클러스터 불안정으로 이어질 수 있습니다. 총 사용 가능한 디스크 크기(disk/limit)에 대한 디스크 사용량(disk/used_bytes)을 모니터링합니다. 디스크 사용량이 총 사용 가능한 디스크 크기의 80% 를 초과하면 더 큰 디스크 크기를 구성합니다. 자세한 내용은 클러스터 용량 모니터링을 참고하세요.

다음 단계

Apache Kafka®는 미국 및/또는 다른 국가에서 사용되는 Apache Software Foundation 또는 해당 계열사의 등록 상표입니다.

Apache Kafka용 관리형 서비스 클러스터의 크기 계획 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.