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 지표 BytesInPerSec 및 BytesOutPerSec을 사용하십시오. 브로커의 이러한 지표 값이 높거나 편향된 경우 브로커의 CPU 사용량이 높을 수 있습니다.

대용량 토픽의 파티션 분포가 고르지 않은 경우 브로커에 트래픽이 많이 발생할 수 있습니다. 또는 생산자가 모든 파티션에 데이터를 균등하게 분배하지 않습니다. 이 문제를 해결하려면 생산자 파티셔닝 키를 확인하고 클러스터 구성을 업데이트하십시오. 그런 다음 한 파티션이 나머지 파티션보다 더 많은 데이터를 가져오지 않도록 파티션 키를 구성합니다.

소비자 그룹이 오프셋을 매우 자주 커밋하는 경우에도 트래픽이 많이 발생할 수 있습니다. 오프셋 커밋의 트래픽은 브로커에 영향을 미칩니다. 이 문제를 해결하려면 소비자 그룹의 수를 줄이거나 인스턴스의 인스턴스 크기를 업그레이드하십시오.

브로커당 파티션 수가 권장 값을 초과함

브로커당 파티션 수가 권장 값을 초과하면 클러스터에 과부하가 걸립니다. 클러스터에 과부하가 걸리면 다음 작업을 수행할 수 없습니다.

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

파티션이 너무 많으면 CPU 사용률이 높아져 성능이 저하될 수 있습니다.

이 문제를 해결하려면 다음 작업을 수행하십시오.

• 오래되거나 사용하지 않는 토픽을 삭제하여 파티션 수를 권장 한도 이내로 유지합니다. 사용하지 않는 토픽을 식별하려면 토픽 수준 모니터링을 켜고 토픽 수준에서 BytesInPerSec 및 BytesOutPerSec 지표를 확인하여 토픽을 통과하는 트래픽이 있는지 확인합니다. 통과하는 트래픽이 없는 경우 사용하지 않는 토픽을 삭제할 수 있습니다.
• 브로커 인스턴스 유형을 필요한 파티션 수를 수용할 수 있는 유형으로 스케일 업합니다. 또한 브로커를 더 추가하고 파티션을 재할당합니다.

참고: 파티션을 재할당하려면 kafka-reassign-partitions 명령을 실행해야 합니다. Amazon MSK는 사용자가 브로커를 추가해도 파티션을 자동으로 재할당하지 않습니다.

T 인스턴스 유형을 사용함

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

Amazon CloudWatch에서 버스트 가능 인스턴스의 CPU 크레딧 잔액 지표를 모니터링해야 합니다.

T 인스턴스 유형에서 실행되는 모든 클러스터의 기준 CPU 사용량 및 크레딧 잔액을 모니터링합니다. CPU 사용량이 기준보다 많고 사용할 크레딧이 더 이상 남아 있지 않으면 클러스터에 성능 문제가 발생합니다.

기타 가능한 원인

클라이언트에 대한 연결 수가 많음

다음 Amazon CloudWatch 지표 중 하나라도 급증하면 브로커 CPU 사용량이 증가할 수 있습니다.

• ConnectionCount
• ConnectionCreationRate
• ConnectionCloseRate

이 문제를 해결하려면 Amazon CloudWatch에서 다음 지표를 모니터링하십시오. 그런 다음 필요에 따라 연결 수를 줄이거나 브로커 유형을 스케일 업하십시오.

Amazon MSK가 브로커 장애를 감지하고 복구함

Amazon MSK가 브로커 장애를 감지하고 패치와 같은 자동 유지 관리 작업을 수행하면 CPU 사용량이 증가합니다. CPU 사용량은 Amazon MSK가 클러스터 작업을 완료하는 즉시 정상 사용량 수준으로 떨어집니다.

사용자가 브로커 유형 변경 또는 버전 업그레이드를 요청함

사용자가 브로커 유형 변경 또는 버전 업그레이드를 요청하면 Amazon MSK가 한 번에 하나의 브로커를 오프라인 상태로 전환하는 롤링 워크플로를 배포합니다. 리드 파티션을 사용하는 브로커가 오프라인이 되면 Apache Kafka가 파티션 리더십을 다시 할당하여 클러스터의 다른 브로커에 작업을 다시 분배합니다. 이러한 브로커의 CPU 사용량을 모니터링하고 클러스터에 운영 이벤트를 감당할 충분한 CPU 여유가 있는지 확인하십시오.

데이터 분배가 편향되어 하나 이상의 브로커에서 CPU 사용량이 높음

데이터 분배가 편향되어 하나 이상의 브로커에서 CPU 사용량이 높을 수 있습니다. 예를 들어 브로커 6개 중 2개가 가장 많이 쓰이고 소비되는 경우 해당 브로커의 CPU 사용량이 더 많아집니다. 이 문제를 해결하려면 클러스터의 파티션 간에 잘 분산되도록 라운드 로빈 기법을 사용해야 합니다.

Apache Kafka 클러스터 컨트롤러가 클러스터 전체에 파티션을 배포하는 방법을 보려면 다음 명령을 실행합니다.

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 사용량이 증가할 수 있습니다. 이 문제를 해결하려면 스크랩 간격을 늘리십시오. Amazon MSK 클러스터의 성능을 보존하려면 브로커별로 분당 1스크랩을 초과하지 않는 것이 가장 좋습니다. 기본적으로 스크랩 간격은 10~15초입니다.