Amazon MSK 클러스터에 있는 하나 이상의 브로커에서 CPU 사용량이 높아지는 문제를 해결하려면 어떻게 해야 하나요?

5분 분량
0

Amazon Managed Streaming for Apache Kafka(Amazon MSK) 클러스터에 있는 하나 이상의 브로커에서 CPU 사용률이 높아지는 문제를 해결해야 합니다.

해결 방법

Amazon MSK 클러스터의 총 CPU 사용률은 다음의 합계로 계산됩니다.

  • 지표 CpuUser로 정의된 사용자 스페이스에서의 CPU 비율
  • CpuSystem으로 정의된 커널 스페이스에서의 CPU 비율

클러스터 CPU의 40%를 사용할 수 있도록 총 CPU 사용률을 60% 미만으로 유지하는 것이 좋습니다. Apache Kafka는 필요에 따라 클러스터의 브로커 간에 CPU 부하를 재분배할 수 있습니다. 예를 들어, Amazon MSK가 브로커 장애를 복구할 때 사용 가능한 CPU를 사용하여 패치 적용과 같은 자동 유지 관리를 수행할 수 있습니다.

다음은 Amazon MSK 클러스터에서 CPU 사용률이 높아지는 가장 일반적인 원인 중 일부입니다.

  • 수신 또는 발신 트래픽이 많습니다.
  • 브로커당 파티션 수가 초과되어 클러스터에 과부하가 걸렸습니다.
  • T 유형 인스턴스를 사용하고 있습니다.

수신 또는 발신 트래픽이 많습니다

Amazon CloudWatch 지표 BytesInPerSecBytesOutPerSec을(를) 사용하여 클러스터의 수신 및 발신 트래픽을 모니터링할 수 있습니다. 브로커의 이러한 지표 값이 높거나 편향된 경우 브로커의 CPU 사용량이 높을 수 있습니다. 다음은 수신 및 발신 트래픽이 높은 원인 중 일부입니다.

  • 트래픽이 많은 토픽의 파티션 수가 브로커에 균등하게 분산되지 않습니다. 또는 프로듀서가 모든 파티션에 데이터를 균등하게 전송하지 않습니다. 프로듀서 파티셔닝 키를 확인하고 그에 따라 클러스터 구성을 업데이트해야 합니다. 한 파티션이 나머지 파티션보다 더 많은 데이터를 가져가지 않도록 파티션 키를 구성해야 합니다.
  • 소비자 그룹이 매우 빈번하게 오프셋 커밋을 수행하고 있습니다. 오프셋 커밋의 트래픽은 브로커에 영향을 미칩니다. 이러한 경우 _consumer_offset 토픽 파티션의 리더인 브로커의 MessagesInPerSec 값이 상당히 높게 표시됩니다. 소비자 그룹 오프셋이 커밋되는 파티션입니다. 이 문제를 해결하려면 소비자 그룹의 수를 줄이거나 인스턴스 크기를 업그레이드하십시오.

브로커당 파티션 수가 초과되었습니다

브로커당 파티션 수가 권장 값을 초과하면 클러스터가 과부하됩니다. 이 경우 다음 작업을 수행하지 못할 수 있습니다.

  • 클러스터 구성을 업데이트합니다.
  • 클러스터에 대한 Apache Kafka 버전을 업데이트합니다.
  • 클러스터를 더 작은 브로커 유형으로 업데이트합니다.
  • AWS Secrets Manager 시크릿을 SASL/SCRAM 인증이 있는 클러스터와 연결합니다.

파티션이 너무 많으면 CPU 사용률이 높아지고 성능이 저하됩니다. 이는 트래픽이 거의 없어도 각 파티션은 일정량의 브로커 리소스를 사용합니다. 이 문제를 해결하려면 다음을 시도해 보십시오.

  • 오래되거나 사용하지 않는 토픽을 삭제하여 파티션 수를 권장 한도 이내로 유지합니다.
  • 브로커 인스턴스 유형을 필요한 파티션 수를 수용할 수 있는 유형으로 스케일 업합니다. 또한 브로커를 더 추가하고 파티션을 다시 할당해보십시오.

참고로 브로커를 추가할 때 파티션이 자동으로 다시 할당되지는 않습니다. kafka-reassign-partitions 명령을 실행해야 합니다. 자세한 내용은 클러스터 크기 변경 후 클러스터 다시 할당을 참조하십시오.

T 유형 인스턴스를 사용하고 있습니다

참고로 T 유형 인스턴스에는 기준 성능과 함께 버스트 가능한 몇 가지 기능이 있습니다. 이 인스턴스는 기준 성능으로 CPU 사용률 20%를 사용할 수 있습니다. 이 값을 초과하면 인스턴스 유형이 CPU 크레딧을 사용하기 시작합니다. 사용률이 20% 미만이면 CPU 크레딧이 누적됩니다.

Amazon CloudWatch에서 CPU 크레딧 잔액 지표를 모니터링해야 합니다. 크레딧을 적립하면 크레딧 잔액에 누적되며 사용하면 크레딧 잔액에서 제거됩니다. 크레딧 잔액의 최대 한도는 인스턴스 크기에 따라 결정됩니다. 이 한도에 도달하면 새로 획득한 크레딧이 모두 폐기됩니다. T2 Standard 인스턴스 유형의 경우 시작 크레딧은 한도에 포함되지 않습니다.

CPUCreditBalance 지표로 표시되는 CPU 크레딧은 인스턴스가 기준 CPU 사용률을 초과 소비하는 데 사용할 수 있습니다. 인스턴스가 실행 중일 때는 CPUCreditBalance의 크레딧이 만료되지 않습니다. T4g, T3a 또는 T3 인스턴스가 중지되도 CPUCreditBalance 값은 7일 동안 유지됩니다. 7일이 지나면 누적된 크레딧이 모두 손실됩니다. T2 인스턴스가 중지되면 CPUCreditBalance 값이 유지되지 않으며 누적된 크레딧도 모두 손실됩니다. CPU 크레딧 지표는 5분 간격으로 제공됩니다.

T 유형 인스턴스에서 실행 중인 모든 클러스터의 기준 CPU 사용량과 크레딧 잔액을 모니터링해야 합니다. CPU 사용량이 기준보다 많고 더는 사용할 크레딧이 없으면 클러스터에 성능 문제가 발생합니다.

기타 원인

  • 클라이언트에 대한 연결 수가 많습니다. 다음 CloudWatch 지표 중 하나라도 급증하면 브로커 CPU 사용량이 증가할 수 있습니다. 이 문제를 해결하려면 CloudWatch에서 다음 지표를 모니터링하십시오. 그런 다음 필요에 따라 연결 수를 줄이거나 브로커 유형을 스케일 업하십시오.
    • ConnectionCount
    • ConnectionCreationRate
    • ConnectionCloseRate
  • 소비자 그룹의 수가 많습니다. 소비자 그룹의 수가 많으면(예: 1000개 이상) 브로커의 CPU 사용량이 증가할 수 있습니다. 소비자 그룹이 오프셋을 너무 자주 커밋해도 CPU 사용량이 높아질 수도 있습니다. 이 문제를 해결하려면 소비자 그룹의 수를 줄이거나 인스턴스 크기를 업그레이드하십시오.
  • Amazon MSK가 브로커 장애를 감지하고 복구합니다. 이 경우 Amazon MSK가 패치 적용과 같은 자동 유지 관리 작업을 수행하므로 CPU 사용량이 증가합니다.
  • 사용자가 브로커 유형 변경 또는 버전 업그레이드를 요청합니다. 이 경우 Amazon MSK는 브로커를 하나씩 오프라인으로 전환하는 롤링 워크플로를 배포합니다. 리드 파티션을 사용하는 브로커가 오프라인이 되면 Apache Kafka가 파티션 리더십을 다시 할당하여 클러스터의 다른 브로커에 작업을 다시 분배합니다. 이러한 브로커의 CPU 사용량을 모니터링하고 클러스터에 운영 이벤트를 감당할 충분한 CPU 여유가 있는지 확인하십시오.
  • 데이터 분배가 편향되어 하나 이상의 브로커에서 CPU 사용량이 높습니다. 예를 들어 브로커 6개 중 2개가 가장 많이 쓰이고 소비되는 경우 CPU 사용량이 더 많아집니다. 이 문제를 해결하려면 클러스터의 파티션 간에 잘 분산되도록 라운드 로빈 기법을 사용해야 합니다. 클러스터의 파티션 간에 어떻게 분산되고 있는지 보려면 topic describe 명령을 실행합니다. 출력은 다음과 비슷합니다.
bin/kafka-topics.sh -bootstrap-server $MYBROKERS --describe --topic my-topic
    Topic:my-topic    PartitionCount:7 ReplicationFactor:3 Configs:
    Topic: my-topic    Partition: 0 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
    Topic: my-topic    Partition: 1 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
    Topic: my-topic    Partition: 2 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
    Topic: my-topic    Partition: 3 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
    Topic: my-topic    Partition: 4 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
    Topic: my-topic    Partition: 5 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
  • 개방형 모니터링을 켰습니다. Prometheus로 개방형 모니터링을 켜고 스크랩 간격이 짧은 경우 지표가 많이 방출될 수 있습니다. 이로 인해 CPU 사용량이 많아집니다. 이 문제를 해결하려면 스크랩 간격을 늘립니다.
AWS 공식
AWS 공식업데이트됨 일 년 전