사이징
카프카 크기 조정은 간단, 세분화, 역방향, 파티션의 4가지 구성 모드로 수행할 수 있습니다.
단순한
간단 모드는 Apache Kafka를 처음 사용하는 사용자나 초기 상태 사용 사례에 적합합니다. 이 모드에서는 처리량(MBps), 읽기 팬아웃, 보존 및 리소스 활용률(기본값은 60%)과 같은 요구 사항을 제공합니다. 또한 온프레미스(베어메탈, VMware, Kubernetes 또는 OpenStack)나 클라우드와 같은 환경으로 들어갑니다. 이 정보를 기반으로 Kafka 클러스터의 크기를 조정하면 브로커, Zookeeper, Apache Kafka Connect Worker, 스키마 레지스트리, REST 프록시, ksqlDB 및 Confluent 제어 센터에 필요한 서버 수가 제공됩니다.
계층형 스토리지의 경우 Kafka 클러스터 크기를 조정하기 위한 세분화된 구성 모드를 고려하세요. 세분화 모드는 숙련된 Apache Kafka 사용자나 명확하게 정의된 사용 사례에 적합합니다. 이 섹션에서는 생산자, 스트림 프로세서, 소비자의 크기 조정에 대해 설명합니다.
프로듀서
Apache Kafka의 제작자(예: 네이티브 클라이언트, REST 프록시 또는 Kafka 커넥터)를 설명하려면 다음 정보를 제공하세요.
-
이름. 불꽃.
-
생산자 유형. 애플리케이션 또는 서비스, 프록시(REST, MQTT, 기타), 기존 데이터베이스(RDBMS, NOSQL, 기타). "모르겠습니다"를 선택할 수도 있습니다.
-
평균 처리량. 초당 이벤트 수(예: 1,000,000개).
-
최대 처리량. 초당 이벤트 수(예: 4,000,000개).
-
평균 메시지 크기. 압축되지 않은 바이트 단위(최대 1MB, 예: 1000).
-
메시지 형식. 옵션으로는 Avro, JSON, 프로토콜 버퍼, 바이너리, 텍스트, "모르겠습니다" 및 기타가 있습니다.
-
복제 인자. 옵션은 1, 2, 3(Confluent 추천), 4, 5, 6입니다.
-
보존 시간. 어느 날(예를 들어). Apache Kafka에 데이터를 얼마 동안 저장하고 싶으신가요? 무한한 시간을 원하면 -1을 아무 단위나 입력하세요. 계산기는 무한 보존을 위해 보존 기간이 10년이라고 가정합니다.
-
"계층형 스토리지를 사용하여 브로커 수를 줄이고 무한한 스토리지를 허용하시겠습니까?" 확인란을 선택하세요.
-
계층형 스토리지가 활성화되면 보존 필드는 브로커에 로컬로 저장된 핫 데이터 세트를 제어합니다. 보관 보존 필드는 데이터가 보관 개체 저장소에 저장되는 기간을 제어합니다.
-
보관 보관 (예를 들어) 1년. 귀하의 데이터를 보관 저장소에 얼마 동안 보관하고 싶으신가요? 무한한 시간을 원하면 -1을 아무 단위나 입력하세요. 계산기는 무한 보존을 위해 10년간 보존한다고 가정합니다.
-
성장 배수. 1 (예를 들어). 이 매개변수의 값이 현재 처리량을 기반으로 하는 경우 1로 설정합니다. 추가적인 성장에 따라 크기를 조정하려면 이 매개변수를 성장 배수로 설정하세요.
-
생산자 인스턴스 수. 10 (예를 들어). 몇 개의 프로듀서 인스턴스가 실행될 예정인가요? 이 입력은 CPU 부하를 크기 계산에 통합하는 데 필요합니다. 빈 값은 CPU 부하가 계산에 포함되지 않음을 나타냅니다.
이 예시 입력을 기준으로 하면 크기 조정은 생산자에게 다음과 같은 영향을 미칩니다.
-
압축되지 않은 바이트의 평균 처리량: 1GBps. 압축되지 않은 바이트의 최대 처리량: 4GBps. 압축된 바이트의 평균 처리량: 400MBps. 압축 바이트의 최대 처리량: 1.6GBps. 이는 기본 60% 압축률을 기준으로 합니다(이 값은 변경할 수 있습니다).
-
브로커 내 핫셋 스토리지에 필요한 총 용량: 복제를 포함하여 압축된 용량으로 31,104TB입니다. 필요한 총 오프브로커 보관 저장 용량: 압축 시 378,432TB. 사용"https://fusion.netapp.com" StorageGRID 크기 조정을 위해.
-
스트림 프로세서는 Apache Kafka에서 데이터를 소비하고 Apache Kafka로 다시 생성하는 애플리케이션이나 서비스를 설명해야 합니다. 대부분의 경우 이러한 기능은 ksqlDB 또는 Kafka Streams에 내장되어 있습니다.
-
이름. 스파크 스트리머.
-
처리 시간. 이 프로세서가 단일 메시지를 처리하는 데 얼마나 걸리나요?
-
1ms(단순, 상태 비저장 변환) [예], 10ms(상태 저장 메모리 내 작업).
-
100ms(상태 저장 네트워크 또는 디스크 작업), 1000ms(제3자 REST 호출).
-
저는 이 매개변수를 벤치마킹했고, 얼마나 걸리는지 정확히 알고 있습니다.
-
-
산출물 보존. 1일(예시). 스트림 프로세서는 Apache Kafka로 출력을 생성합니다. 이 출력 데이터를 Apache Kafka에 얼마 동안 저장하고 싶으신가요? 무한한 시간을 원하면 -1을 아무 단위나 입력하세요.
-
"계층형 스토리지를 사용하여 브로커 수를 줄이고 무한한 스토리지를 허용하시겠습니까?" 확인란을 선택하세요.
-
보관 보관 1년(예를 들어). 귀하의 데이터를 보관 저장소에 얼마 동안 보관하고 싶으신가요? 무한한 시간을 원하면 -1을 아무 단위나 입력하세요. 계산기는 무한 보존을 위해 10년간 보존한다고 가정합니다.
-
출력 패스스루 백분율. 100(예를 들어). 스트림 프로세서는 Apache Kafka로 출력을 생성합니다. 인바운드 처리량 중 Apache Kafka로 다시 출력되는 비율은 얼마입니까? 예를 들어, 인바운드 처리량이 20MBps이고 이 값이 10이면 출력 처리량은 2MBps가 됩니다.
-
이것은 어떤 응용프로그램에서 읽어오는 것인가요? 생산자 유형 기반 크기 조정에 사용되는 이름인 "Spark"를 선택합니다. 위의 입력을 기반으로 스트림 프로세서 인스턴스와 토픽 파티션 추정에 대한 크기 조정의 다음과 같은 효과를 기대할 수 있습니다.
-
이 스트림 프로세서 애플리케이션에는 다음과 같은 개수의 인스턴스가 필요합니다. 들어오는 주제에도 이 정도의 파티션이 필요할 가능성이 있습니다. 이 매개변수를 확인하려면 Confluent에 문의하세요.
-
성장 배수 없이 평균 처리량의 경우 1,000
-
성장 배수 없이 최대 처리량의 경우 4,000
-
성장 배수를 적용한 평균 처리량의 경우 1,000
-
성장 배수를 적용한 최대 처리량의 경우 4,000
-
소비자들
Apache Kafka에서 데이터를 사용하지만 Apache Kafka로 다시 데이터를 생성하지 않는 애플리케이션이나 서비스를 설명해 주세요. 예를 들어, 네이티브 클라이언트나 Kafka 커넥터가 있습니다.
-
이름. 소비자를 자극합니다.
-
처리 시간. 이 소비자가 단일 메시지를 처리하는 데 얼마나 걸리나요?
-
1ms(예: 로깅과 같은 간단하고 상태 없는 작업)
-
10ms(데이터 저장소에 대한 빠른 쓰기)
-
100ms(데이터 저장소에 대한 느린 쓰기)
-
1000ms(제3자 REST 호출)
-
기간이 알려진 다른 벤치마크 프로세스.
-
-
소비자 유형. 기존 데이터 저장소(RDBMS, NoSQL, 기타)에 대한 애플리케이션, 프록시 또는 싱크입니다.
-
이것은 어떤 응용프로그램에서 읽어오는 것인가요? 이 매개변수를 이전에 결정된 프로듀서 및 스트림 크기에 연결합니다.
위의 입력 내용을 기반으로 소비자 인스턴스 크기와 주제 파티션 추정치를 결정해야 합니다. 소비자 애플리케이션에는 다음과 같은 수의 인스턴스가 필요합니다.
-
평균 처리량의 경우 2,000, 성장 배수 없음
-
최대 처리량의 경우 8,000, 성장 배수 없음
-
성장 배수를 포함한 평균 처리량의 경우 2,000
-
최대 처리량의 경우 8,000(성장 배수 포함)
들어오는 주제에도 이 개수의 파티션이 필요할 가능성이 높습니다. 확인하려면 Confluent에 문의하세요.
생산자, 스트림 프로세서, 소비자에 대한 요구 사항 외에 다음과 같은 추가 요구 사항을 제공해야 합니다.
-
재건 시간입니다. 예를 들어, 4시간. Apache Kafka 브로커 호스트에 장애가 발생하여 데이터가 손실되고, 장애가 발생한 호스트를 대체하기 위해 새로운 호스트가 프로비저닝되는 경우, 이 새로운 호스트는 얼마나 빨리 자체적으로 재구축해야 합니까? 값을 알 수 없는 경우 이 매개변수를 비워 두세요.
-
자원 활용 목표(백분율). 예를 들어, 60. 평균 처리량 동안 호스트를 얼마나 활용하고 싶으신가요? Confluent는 Confluent 자체 균형 클러스터를 사용하지 않는 한 60%의 사용률을 권장하지만, Confluent 자체 균형 클러스터를 사용하는 경우 사용률이 더 높아질 수 있습니다.
주변 환경을 설명하세요
-
클러스터는 어떤 환경에서 실행되나요? Amazon Web Services, Microsoft Azure, Google Cloud Platform, 온프레미스 베어메탈, 온프레미스 VMware, 온프레미스 OpenStack, 온프레미스 Kubernates 중 어떤 것을 선택하시겠습니까?
-
호스트 정보. 코어 수: 48개(예시), 네트워크 카드 유형(10GbE, 40GbE, 16GbE, 1GbE 또는 다른 유형).
-
저장 용량. 호스트: 12(예시) 호스트당 몇 개의 하드 드라이브 또는 SSD가 지원됩니까? Confluent는 호스트당 12개의 하드 드라이브를 권장합니다.
-
저장 용량/볼륨(GB) 1000(예를 들어). 단일 볼륨은 기가바이트 단위로 얼마나 많은 저장 공간을 저장할 수 있나요? Confluent에서는 1TB 디스크를 권장합니다.
-
저장 구성. 저장 볼륨은 어떻게 구성되나요? Confluent에서는 모든 Confluent 기능을 활용하기 위해 RAID10을 권장합니다. JBOD, SAN, RAID 1, RAID 0, RAID 5 및 기타 유형도 지원됩니다.
-
단일 볼륨 처리량(MBps). 125 (예를 들어). 단일 저장 볼륨은 초당 메가바이트 단위로 얼마나 빨리 읽거나 쓸 수 있습니까? Confluent는 일반적으로 처리량이 125MBps인 표준 하드 드라이브를 권장합니다.
-
메모리 용량(GB). 64(예를 들어).
환경 변수를 결정한 후 클러스터 크기를 선택합니다. 위에 표시된 예시 매개변수를 기반으로 Confluent Kafka에 대한 다음 크기를 결정했습니다.
-
아파치 카프카. 브로커 수: 22개. 귀하의 클러스터는 저장소에 제한되어 있습니다. 호스트 수를 줄이고 무한한 저장 공간을 확보하려면 계층형 저장소를 활성화하는 것을 고려하세요.
-
아파치 동물원 관리자. 개수: 5; Apache Kafka Connect Workers: 개수: 2; 스키마 레지스트리: 개수: 2; REST 프록시: 개수: 2; ksqlDB: 개수: 2; Confluent Control Center: 개수: 1.
사용 사례가 고려되지 않은 플랫폼 팀의 경우 역방향 모드를 사용합니다. 파티션 모드를 사용하면 단일 주제에 필요한 파티션 수를 계산할 수 있습니다. 보다 https://eventsizer.io 역방향 및 파티션 모드에 따른 크기 조정을 위해.