Amazon MSK 클러스터 문제 해결

다음 정보는 Amazon MSK 클러스터와 관련된 문제를 해결하는 데 도움이 될 수 있습니다. 또한 AWS re:Post에 문제를 게시할 수 있습니다. Amazon MSK Replicator 문제 해결은 섹션을 참조하세요MSK 복제기 문제 해결.

볼륨 교체 때문에 복제 과부하로 인해 디스크 포화 발생

예기치 않은 볼륨 하드웨어 장애 시 Amazon은 볼륨을 새 인스턴스로 교체할 MSK 수 있습니다. Kafka는 클러스터의 다른 브로커에서 파티션을 복제하여 새로운 볼륨을 다시 채웁니다. 파티션이 복제되고 포착되면 리더십 및 동기화 중 복제본(ISR) 멤버십을 받을 수 있습니다.

문제

볼륨 교체에서 복구하는 브로커의 경우 크기가 다양한 일부 파티션이 다른 파티션보다 먼저 온라인 상태로 다시 전환될 수 있습니다. 이러한 파티션은 여전히 다른 파티션을 추적하고 있는(복제하고 있는) 동일한 브로커의 트래픽을 제공할 수 있으므로 문제가 될 수 있습니다. 이 복제 트래픽은 경우에 따라 기본 볼륨 처리량 한도를 포화시킬 수 있습니다. 기본 사례에서는 초당 250MiB입니다. 이 포화가 발생하면 이미 포착된 모든 파티션이 영향을 받아 해당 파티션ISR과 공유하는 모든 브로커(원격 ack으로 인한 리더 파티션뿐만 아니라)에 대한 클러스터 전반의 지연 시간이 발생합니다acks=all. 이 문제는 다양한 크기의 파티션 수가 많은 더 큰 클러스터에서 더 일반적입니다.

권장 사항

• 복제 I/O 상태를 개선하려면 모범 사례 스레드 설정이 마련되어 있어야 합니다.

• 기본 볼륨 포화 가능성을 줄이려면 처리량이 더 높은 프로비저닝된 스토리지를 활성화합니다. 처리량이 많은 복제 사례의 경우 최소 처리량 값 500MiB/s가 권장되지만 필요한 실제 값은 처리량 및 사용 사례에 따라 달라집니다. Amazon MSK 클러스터의 표준 브로커에 대한 프로비저닝 스토리지 처리량

• 복제 압력을 최소화하려면 num.replica.fetchers를 기본값인 2로 낮춥니다.

PreparingRebalance 상태에 멈춘 소비자 그룹

하나 이상의 소비자 그룹이 영구 리밸런싱 상태에 있는 경우 원인은 Apache Kafka 문제 KAFKA-9752일 수 있으며, 이는 Apache Kafka 버전 2.3.1 및 2.4.1에 영향을 미칩니다.

문제를 해결하려면 문제에 대한 수정 사항이 포함된 Amazon MSK 버그 수정 버전 2.4.1.1로 클러스터를 업그레이드하는 것을 권장합니다. 기존 클러스터를 Amazon MSK bug-fix 버전 2.4.1.1로 업데이트하는 방법에 대한 자세한 내용은 섹션을 참조하세요Apache Kafka 버전 업데이트.

클러스터를 Amazon MSK 버그 수정 버전 2.4.1.1로 업그레이드하지 않고이 문제를 해결하기 위한 해결 방법은를 사용하도록 Kafka 클라이언트를 설정하거나 중단된 소비자 그룹의 식별 및 재부팅 조정 고정 멤버십 프로토콜 브로커 노드로 설정하는 것입니다.

정적 멤버십 프로토콜 구현

클라이언트에서 정적 멤버십 프로토콜을 구현하려면 다음을 수행합니다.

1. Kafka Consumers 구성의 group.instance.id 속성을 그룹 내 소비자를 식별하는 정적 문자열로 설정합니다.

2. 구성의 다른 인스턴스가 정적 문자열을 사용하도록 업데이트되었는지 확인합니다.

3. 변경 사항을 Kafka 소비자에게 배포합니다.

클라이언트 구성에서 세션 시간 제한을 소비자 그룹 재조정을 조기에 트리거하지 않고 소비자가 복구할 수 있는 기간으로 설정하는 경우 정적 멤버십 프로토콜을 사용하는 것이 더 효과적입니다. 예를 들어 소비자 애플리케이션이 5분 동안의 사용 불가 상태를 견딜 수 있는 경우 세션 시간 제한의 합리적인 값은 기본값인 10초가 아닌 4분이 될 수 있습니다.

참고

정적 멤버십 프로토콜을 사용하면 해당 문제가 발생할 확률이 줄어듭니다. 정적 멤버십 프로토콜을 사용하는 경우에도 이 문제가 발생할 수 있습니다.

조정 브로커 노드 재부팅

조정 브로커 노드를 재부팅하려면 다음을 수행합니다.

1. kafka-consumer-groups.sh 명령을 사용하여 그룹 코디네이터를 식별합니다.

2. RebootBroker API 작업을 사용하여 중단된 소비자 그룹의 그룹 조정자를 다시 시작합니다.

Amazon CloudWatch Logs로 브로커 로그 전송 오류

브로커 로그를 Amazon CloudWatch Logs로 전송하도록 클러스터를 설정하려고 하면 두 가지 예외 중 하나가 발생할 수 있습니다.

InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded 예외가 발생하는 경우 다시 시도하되 /aws/vendedlogs/로 시작하는 로그 그룹을 사용하십시오. 자세한 내용은 특정 Amazon Web Services에서 로깅 활성화를 참조하세요.

InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded 예외가 발생하면 계정에서 기존 Amazon CloudWatch Logs 정책을 선택하고 다음 JSON 정책을 추가합니다.

{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}

기존 정책에 JSON 위의를 추가하려고 하지만 선택한 정책의 최대 길이에 도달했다는 오류가 발생하는 경우 Amazon CloudWatch Logs 정책 중 다른 하나에 JSON를 추가해 보세요. 기존 정책에 JSON를 추가한 후 다시 한 번 시도하여 Amazon CloudWatch Logs에 대한 브로커 로그 전송을 설정합니다.

기본 보안 그룹 없음

클러스터를 생성하려고 하는데 기본 보안 그룹이 없음을 나타내는 오류가 발생하는 경우 공유VPC된를 사용 중이기 때문일 수 있습니다. 관리자에게 이에 대한 보안 그룹을 설명할 수 있는 권한을 부여VPC하고 다시 시도하도록 요청합니다. 이 작업을 허용하는 정책의 예는 Amazon EC2: Allow Managing EC2 Security Groups Associated With a Specific VPC, Programmatically and in the Console을 참조하세요.

클러스터가 CREATING 상태에서 멈춘 것처럼 보임

간혹 클러스터 생성에 최대 30분이 소요될 수 있습니다. 30분 동안 기다렸다가 클러스터의 상태를 다시 확인하십시오.

클러스터 상태가에서 CREATING 로 전환됨 FAILED

클러스터를 다시 생성해 보십시오.

클러스터 상태는 ACTIVE 이지만 생산자는 데이터를 전송할 수 없거나 소비자가 데이터를 수신할 수 없음

• 클러스터 생성에 성공했지만(클러스터 상태는 ACTIVE) 데이터를 보내거나 받을 수 없는 경우, 생산자 및 소비자 애플리케이션이 클러스터에 액세스할 수 있는지 확인합니다. 자세한 내용은 3단계: 클라이언트 머신 생성의 지침을 참조하십시오.

• 생산자와 소비자가 클러스터에 액세스할 수 있지만 여전히 데이터를 생성하고 소비하는 데 문제가 있는 경우 원인은 KAFKA-7697일 수 있으며, 이는 Apache Kafka 버전 2.1.0에 영향을 미치고 하나 이상의 브로커에서 교착 상태로 이어질 수 있습니다. 이 버그의 영향을 받지 않는 Apache Kafka 2.2.1로 마이그레이션하는 것을 고려하십시오. 마이그레이션 방법에 대한 자세한 내용은 Amazon MSK 클러스터로 마이그레이션 단원을 참조하십시오.

AWS CLI 가 Amazon을 인식하지 못함 MSK

가 AWS CLI 설치되어 있지만 Amazon MSK 명령을 인식하지 못하는 경우 AWS CLI 를 최신 버전으로 업그레이드합니다. 업그레이드 방법에 대한 자세한 지침은 설치를 AWS CLI참조하세요. AWS Command Line Interface 를 사용하여 Amazon MSK 명령을 실행하는 방법에 대한 자세한 내용은 섹션을 참조 AWS CLI 하세요Amazon MSK 주요 기능 및 개념.

파티션이 오프라인으로 전환되거나 복제본이 동기화되지 않음

디스크 공간 부족 증상일 수 있습니다. 디스크 공간이 부족함을 참조하세요.

디스크 공간이 부족함

디스크 공간 관리의 모범 사례인 디스크 공간 모니터링 및 데이터 보존 파라미터 조정 단원을 참조하십시오.

메모리 부족

MemoryUsed 지표가 높거나 MemoryFree가 낮다고 해서 문제가 있다는 뜻은 아닙니다. Apache Kafka는 최대한 많은 메모리를 사용하도록 설계되었으며 최적으로 관리합니다.

생산자 가져오기 NotLeaderForPartitionException

종종 발생하는 일시적인 오류입니다. 생산자의 retries 구성 파라미터를 현재 값보다 큰 값으로 설정합니다.

0보다 큰 복제되지 않은 파티션(URP)

UnderReplicatedPartitions 지표는 모니터링해야 하는 중요한 지표입니다. 정상 MSK 클러스터에서이 지표의 값은 0입니다. 0보다 크면 다음 이유 중 하나 때문일 수 있습니다.

• UnderReplicatedPartitions가 급증하는 경우, 클러스터가 수신 트래픽과 발신 트래픽을 처리하기에 적합한 크기로 프로비저닝되지 않았기 때문일 수 있습니다. 표준 브로커 모범 사례을 참조하세요.

• 트래픽이 적은 기간을 포함하여 UnderReplicatedPartitions가 일관되게 0보다 큰 경우, 브로커에 주제 액세스 권한을 부여하지 ACLs 않는 제한을 설정했을 수 있습니다. 파티션을 복제하려면 브로커가 READ 및 DESCRIBE 주제 모두에 대한 권한을 부여받아야 합니다. READ DESCRIBE는 권한 부여를 통해 기본적으로 부여됩니다. 설정에 대한 자세한 내용은 Apache Kafka 설명서의 권한 부여 및 ACLs 섹션을 ACLs참조하세요.

클러스터에는 __amazon_msk_canary와 __amazon_msk_canary_state라는 주제가 있습니다.

MSK 클러스터에 이름이 인 주제__amazon_msk_canary와 이름이 인 주제가 있을 수 있습니다__amazon_msk_canary_state. 다음은 Amazon이 클러스터 상태 및 진단 지표에 대해 MSK 생성하고 사용하는 내부 주제입니다. 이러한 주제는 크기가 무시할 수 있을 정도로 작으며 삭제할 수 없습니다.

파티션 복제 실패

CLUSTER_ACLs에를 설정하지 않았는지 확인합니다ACTIONS.

퍼블릭 액세스가 활성화된 클러스터에 액세스할 수 없음

클러스터에 공용 액세스가 활성화되어 있지만 여전히 인터넷에서 클러스터에 액세스할 수 없는 경우 다음 단계를 수행합니다.

1. 클러스터의 보안 그룹 인바운드 규칙이 IP 주소와 클러스터의 포트를 허용하는지 확인합니다. 클러스터 포트 번호 목록은 포트 정보 섹션을 참조하세요. 또한 보안 그룹의 아웃바운드 규칙이 아웃바운드 통신을 허용하는지 확인합니다. 보안 그룹과 해당 인바운드 및 아웃바운드 규칙에 대한 자세한 내용은 Amazon VPC 사용 설명서의의 보안 그룹을 참조하세요VPC.

2. IP 주소와 클러스터의 포트가 클러스터 VPC 네트워크의 인바운드 규칙에 허용되는지 확인합니다ACL. 보안 그룹과 달리 네트워크ACLs는 상태 비저장입니다. 즉, 인바운드 및 아웃바운드 규칙을 모두 구성해야 합니다. 아웃바운드 규칙에서 모든 트래픽(포트 범위: 0~65535)을 사용자 IP 주소로 허용합니다. 자세한 내용은 Amazon VPC 사용 설명서의 규칙 추가 및 삭제를 참조하세요.

3. 퍼블릭 액세스 부트스트랩 브로커 문자열을 사용하여 클러스터에 액세스하고 있는지 확인합니다. 퍼블릭 액세스가 활성화된 MSK 클러스터에는 퍼블릭 액세스용 문자열과 내부에서 액세스용 부트스트랩 브로커 문자열이라는 두 개의 서로 다른 문자열이 있습니다 AWS. 자세한 내용은 를 사용하여 부트스트랩 브로커 가져오기 AWS Management Console 단원을 참조하십시오.

내에서 클러스터에 액세스할 수 없음 AWS: 네트워킹 문제

MSK 클러스터와 성공적으로 통신할 수 없는 Apache Kafka 애플리케이션이 있는 경우 먼저 다음 연결 테스트를 수행합니다.

1. Amazon MSK 클러스터의 부트스트랩 브로커 가져오기에 설명된 방법 중 하나를 사용하여 부트스트랩 브로커의 주소를 가져옵니다.

2. 다음 명령에서를 이전 단계에서 얻은 브로커 주소 중 bootstrap-broker 하나로 바꿉니다. 클러스터가 TLS 인증을 사용하도록 설정된 경우를 9094port-number로 바꿉니다. 클러스터가 TLS 인증을 사용하지 않는 경우를 9092port-number로 바꿉니다. 클라이언트 시스템에서 명령을 실행합니다.

   telnet bootstrap-broker port-number

   포트 번호는 다음과 같습니다.

   • 클러스터가 TLS 인증을 사용하도록 설정된 경우 9094입니다.

   • 9092 클러스터가 TLS 인증을 사용하지 않는 경우.

   • 퍼블릭 액세스가 활성화된 경우에는 다른 포트 번호가 필요

   클라이언트 시스템에서 명령을 실행합니다.

3. 모든 부트스트랩 브로커에 대해 이전 명령을 반복합니다.

클라이언트 머신이 브로커에 액세스할 수 있는 경우 이는 연결 문제가 없음을 의미합니다. 이 경우 다음 명령을 실행하여 Apache Kafka 클라이언트가 올바르게 설정되어 있는지 확인합니다. 를 가져오려면에 설명된 방법 중 하나를 bootstrap-brokers사용합니다Amazon MSK 클러스터의 부트스트랩 브로커 가져오기. topic를 주제 이름으로 바꿉니다.

<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic

이전 명령이 성공하면 클라이언트가 올바르게 설정되었음을 의미합니다. 여전히 애플리케이션에서 생성 및 소비할 수 없는 경우 애플리케이션 수준에서 문제를 디버그하십시오.

클라이언트 머신이 브로커에 액세스할 수 없는 경우 클라이언트 시스템 설정에 따른 지침은 다음 하위 섹션을 참조하세요.

동일한의 Amazon EC2 클라이언트 및 MSK 클러스터 VPC

클라이언트 머신이 MSK 클러스터VPC와 동일한에 있는 경우 클러스터의 보안 그룹에 클라이언트 머신의 보안 그룹의 트래픽을 수락하는 인바운드 규칙이 있는지 확인합니다. 이러한 규칙 설정에 대한 자세한 내용은 보안 그룹 규칙을 참조하십시오. 클러스터와 동일한에 있는 Amazon EC2 인스턴스에서 클러스터에 액세스하는 방법VPC의 예는 섹션을 참조하세요Amazon 사용 시작하기 MSK.

서로 다른의 Amazon EC2 클라이언트 및 MSK 클러스터 VPCs

클라이언트 시스템과 클러스터가 서로 다른 두에 있는 경우 다음을 VPCs확인합니다.

• 두 VPCs는 피어링됩니다.

• 피어링 연결의 상태가 활성 상태입니다.

• 두 테이블의 라우팅 테이블VPCs이 올바르게 설정되었습니다.

VPC 피어링에 대한 자세한 내용은 VPC 피어링 연결 작업을 참조하세요.

온프레미스 클라이언트

를 사용하여 MSK 클러스터에 연결하도록 설정된 온프레미스 클라이언트의 경우 다음을 AWS VPN확인합니다.

• VPN 연결 상태는 입니다UP. VPN 연결 상태를 확인하는 방법에 대한 자세한 내용은 VPN 터널의 현재 상태를 확인하려면 어떻게 해야 합니까?를 참조하세요.

• 클러스터의 라우팅 테이블에는 대상의 형식CIDR이 인 온프레미스에 대한 경로가 VPC 포함되어 있습니다Virtual private gateway(vgw-xxxxxxxx).

• MSK 클러스터의 보안 그룹은 포트 2181, 포트 9092(클러스터가 일반 텍스트 트래픽을 수락하는 경우) 및 포트 9094(클러스터가 TLS암호화 트래픽을 수락하는 경우)에서 트래픽을 허용합니다.

자세한 AWS VPN 문제 해결 지침은 클라이언트 문제 해결을 참조하세요VPN.

AWS Direct Connect

클라이언트가를 사용하는 경우 문제 해결을 AWS Direct Connect참조하세요. AWS Direct Connect

이전 문제 해결 지침으로 문제가 해결되지 않으면 네트워크 트래픽을 차단하는 방화벽이 없는지 확인하십시오. 추가 디버깅을 위해 tcpdump 및와 같은 도구를 사용하여 트래픽을 Wireshark 분석하고 MSK 클러스터에 도달하는지 확인합니다.

인증 실패: 연결 횟수가 너무 많음

Failed authentication ... Too many connects 오류는 하나 이상의 IAM 클라이언트가 공격적인 속도로 연결하려고 하기 때문에 브로커가 자신을 보호하고 있음을 나타냅니다. 브로커가 더 높은 비율의 새 IAM 연결을 수락할 수 있도록 reconnect.backoff.ms 구성 파라미터를 늘릴 수 있습니다.

브로커별 새 연결 속도 제한에 대한 자세한 내용은 Amazon MSK 할당량 페이지를 참조하세요.

MSK 서버리스: 클러스터 생성 실패

MSK 서버리스 클러스터를 생성하려고 하는데 워크플로가 실패하면 VPC 엔드포인트를 생성할 권한이 없을 수 있습니다. ec2:CreateVpcEndpoint 작업을 허용하여 관리자가 VPC 엔드포인트를 생성할 수 있는 권한을 부여했는지 확인합니다.

모든 Amazon MSK 작업을 수행하는 데 필요한 전체 권한 목록은 섹션을 참조하세요AWS 관리형 정책: mazonMSKFull액세스.