Skip to main content
NetApp Solutions
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

AFF A900 온프레미스 성능 개요 및 검증

기여자
PDF

사내에서 NetApp AFF A900 스토리지 컨트롤러와 ONTAP 9.12.1 RC1을 사용하여 Kafka 클러스터의 성능 및 확장성을 검증했습니다. ONTAP 및 AFF의 이전 계층형 스토리지 모범 사례와 동일한 테스트 베드를 사용했습니다.

AFF A900을 평가하기 위해 Confluent Kafka 6.2.0을 사용했습니다. 클러스터에는 8개의 브로커 노드와 3개의 Zookeeper 노드가 있습니다. 성능 테스트를 위해 OMB 작업자 노드 5개를 사용했습니다.

입력/출력 대화 상자 또는 작성된 내용을 표시하는 그림

스토리지 구성

NetApp FlexGroups 인스턴스를 사용하여 로그 디렉토리에 단일 네임스페이스를 제공하여 복구 및 구성을 간소화했습니다. NFSv4.1 및 pNFS를 사용하여 로그 세그먼트 데이터에 직접 액세스할 수 있습니다.

클라이언트 튜닝

각 클라이언트는 다음 명령을 사용하여 FlexGroup 인스턴스를 마운트했습니다.

mount -t nfs -o vers=4.1,nconnect=16 172.30.0.121:/kafka_vol01 /data/kafka_vol01

또한, 을 늘렸습니다 max_session_slots` 를 선택합니다 64 를 선택합니다 180. 이는 ONTAP의 기본 세션 슬롯 제한과 일치합니다.

Kafka 브로커 튜닝

테스트 중인 시스템의 처리량을 극대화하기 위해 특정 주요 스레드 풀에 대한 기본 매개 변수를 크게 늘렸습니다. 대부분의 구성에 대해 Confluent Kafka 모범 사례를 따르는 것이 좋습니다. 이 튜닝은 스토리지에 대한 미해결 입출력의 동시성을 극대화하는 데 사용되었습니다. 이러한 매개 변수는 브로커의 컴퓨팅 리소스 및 스토리지 속성에 맞게 조정할 수 있습니다.

num.io.threads=96
num.network.threads=96
background.threads=20
num.replica.alter.log.dirs.threads=40
num.replica.fetchers=20
queued.max.requests=2000

워크로드 생성기 테스트 방법

처리량 드라이버 및 주제 구성에 대한 클라우드 테스트와 동일한 OMB 구성을 사용했습니다.

  1. AFF 클러스터에서 Ansible을 사용하여 FlexGroup 인스턴스를 프로비저닝했습니다.

    ---
- name: Set up kafka broker processes
  hosts: localhost
  vars:
    ntap_hostname: ‘hostname’
    ntap_username: 'user'
    ntap_password: 'password'
    size: 10
    size_unit: tb
    vserver: vs1
    state: present
    https: true
    export_policy: default
    volumes:
      - name: kafka_fg_vol01
        aggr: ["aggr1_a", "aggr2_a", “aggr1_b”, “aggr2_b”]
        path: /kafka_fg_vol01
  tasks:
    - name: Edit volumes
      netapp.ontap.na_ontap_volume:
        state: "{{ state }}"
        name: "{{ item.name }}"
        aggr_list: "{{ item.aggr }}"
        aggr_list_multiplier: 8
        size: "{{ size }}"
        size_unit: "{{ size_unit }}"
        vserver: "{{ vserver }}"
        snapshot_policy: none
        export_policy: default
        junction_path: "{{ item.path }}"
        qos_policy_group: none
        wait_for_completion: True
        hostname: "{{ ntap_hostname }}"
        username: "{{ ntap_username }}"
        password: "{{ ntap_password }}"
        https: "{{ https }}"
        validate_certs: false
      connection: local
      with_items: "{{ volumes }}"

  2. ONTAP SVM에서 pNFS를 사용할 수 있게 되었습니다.

    vserver modify -vserver vs1 -v4.1-pnfs enabled -tcp-max-xfer-size 262144

  3. 워크로드는 Cloud Volumes ONTAP와 동일한 워크로드 구성을 사용하는 처리량 드라이버에서 트리거되었습니다. 자세한 내용은 " 단원을 참조하십시오안정적인 성능"아래에 있습니다. 워크로드는 복제 계수 3을 사용했습니다. 즉 NFS에서 로그 세그먼트의 복제본 3개가 유지되었습니다.

    sudo bin/benchmark --drivers driver-kafka/kafka-throughput.yaml workloads/1-topic-100-partitions-1kb.yaml

  4. 마지막으로, 백로그를 사용하여 소비자가 최신 메시지를 따라잡을 수 있는 능력을 측정하는 측정을 완료했습니다. OMB는 측정을 시작하는 동안 소비자를 일시 중지하여 백로그를 생성합니다. 이 경우 백로그 생성(생산자 전용 트래픽), 백로그 드레이닝(소비자가 주제에서 놓친 이벤트를 포착하는 소비자 중심 단계), 안정적 상태 등 세 가지 단계가 발생합니다. 자세한 내용은 " 단원을 참조하십시오성능을 극대화 및 스토리지 제한 탐색"를 참조하십시오.

안정적인 성능

NetApp은 OpenMessaging 벤치마크를 사용하여 AFF A900을 평가하여 AWS의 Cloud Volumes ONTAP 및 AWS의 DAS와 유사한 비교를 제공했습니다. 모든 성능 값은 생산자 및 소비자 수준에서 Kafka 클러스터 처리량을 나타냅니다.

Confluent Kafka 및 AFF A900의 안정적인 상태 성능은 생산자와 소비자 모두의 평균 3.4GBps 처리량을 달성했습니다. 이는 Kafka 클러스터에서 340만 개 이상의 메시지입니다. BrokerTopicMetrics의 지속적인 처리량을 초당 바이트 단위로 시각화함으로써 AFF A900이 지원하는 뛰어난 안정적인 상태 성능과 트래픽을 확인할 수 있습니다.

이 그래프는 브로커 네트워크 처리량을 보여 줍니다.

이것은 주제별로 전달되는 메시지의 보기에 잘 부합됩니다. 다음 그래프는 주제별 분석을 제공합니다. 테스트를 거친 구성에서 4개 주제에 대해 주제당 약 900,000개의 메시지가 나타났습니다.

이 그래프는 브로커 네트워크 처리량을 보여 줍니다.

성능을 극대화 및 스토리지 제한 탐색

AFF의 경우 백로그 기능을 사용하여 OMB를 테스트했습니다. 백로그 기능은 Kafka 클러스터에 이벤트 백로그가 구축된 동안 소비자 가입을 일시 중지합니다. 이 단계에서는 프로듀서 트래픽만 발생하므로 로그에 커밋되는 이벤트가 생성됩니다. 이렇게 하면 일괄 처리 또는 오프라인 분석 워크플로를 가장 긴밀하게 에뮬레이트할 수 있습니다. 이러한 워크플로에서는 소비자 구독이 시작되고 브로커 캐시에서 이미 제거된 내역 데이터를 읽어야 합니다.

이 구성에서 소비자 처리량에 대한 저장소 제한을 이해하기 위해 A900이 흡수할 수 있는 쓰기 트래픽의 양을 파악하기 위해 생산자 전용 단계를 측정했습니다. 다음 섹션 " 을 참조하십시오사이징 지침"이 데이터를 활용하는 방법을 이해합니다.

생산자 전용 측정 과정에서 A900 성능의 한계를 넘어선 높은 피크 처리량을 볼 수 있었습니다(다른 브로커 리소스가 생산자 및 소비자 트래픽을 지원하는 데 포화 상태가 되지 않았을 때).

입력/출력 대화 상자 또는 작성된 내용을 표시하는 그림

참고 이 측정을 위해 메시지당 오버헤드를 제한하고 NFS 마운트 지점에 대한 스토리지 처리량을 최대화하기 위해 메시지 크기를 16K로 늘렸습니다. 
messageSize: 16384
consumerBacklogSizeGB: 4096

Confluent Kafka 클러스터는 4.03GBps의 피크 프로듀서 처리량을 달성했습니다.

18:12:23.833 [main] INFO WorkloadGenerator - Pub rate 257759.2 msg/s / 4027.5 MB/s | Pub err     0.0 err/s …

OMB가 eventbacklog를 채운 후 소비자 트래픽이 다시 시작되었습니다. 백로그 드레이닝으로 측정하는 동안 모든 항목에서 20Gbps 이상의 최고 소비자 처리량을 관찰했습니다. OMB 로그 데이터를 저장하는 NFS 볼륨에 대한 총 처리량이 최대 30Gbps에 근접했습니다.

사이징 지침

Amazon Web Services에서 제공합니다 "사이징 가이드" Kafka 클러스터의 사이징 및 확장에 사용됩니다.

이 사이징은 Kafka 클러스터의 스토리지 처리량 요구 사항을 결정하는 데 유용한 공식을 제공합니다.

복제 계수가 r인 tcluster 클러스터로 생성되는 총 처리량의 경우 브로커 스토리지에서 수신한 처리량은 다음과 같습니다.

t[storage] = t[cluster]/#brokers + t[cluster]/#brokers * (r-1)
          = t[cluster]/#brokers * r

이 작업은 더욱 단순화될 수 있습니다.

max(t[cluster]) <= max(t[storage]) * #brokers/r

이 공식을 사용하여 Kafka 핫 티어 요구에 적합한 ONTAP 플랫폼을 선택할 수 있습니다.

다음 표에는 여러 복제 요소를 사용하는 A900의 예상 생산자 처리량이 설명되어 있습니다.

복제 계수 생산자 처리량(GPPS)

3(측정)

3.4

2

5.1

1

10.2