

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 데이터 전송 문제 해결
<a name="data-delivery-troubleshooting"></a>

 이 섹션을 사용하여 데이터 전송과 관련된 일반적인 문제를 해결합니다.

## 전송이 CREATING 상태에서 멈춤
<a name="troubleshooting-creating"></a>

 전송을 생성하면 리소스가 프로비저닝되는 동안 전송이 CREATING 상태로 전환됩니다. 프로비저닝은 일반적으로 몇 분 내에 완료됩니다. 전송이 장기간 CREATING 상태로 유지되거나 FAILED로 전환되면 구성 오류가 원인일 수 있습니다.

 를 호출`DescribeChannel`하여 현재 상태 및 상태 이유를 확인합니다. 일반적인 사용 사례는 다음과 같습니다.
+ IAM 역할 ARN이 잘못되었거나 역할 정책에 권한이 부족합니다.
+ 대상 Amazon S3 버킷이 존재하지 않거나 다른 리전에 있습니다.
+ 스키마 레지스트리의 AWS Glue 스키마 ARN을 확인할 수 없습니다.

## FAILED 상태의 전송
<a name="troubleshooting-failed"></a>

 `FAILED`이 (에서 반환한 대로)인 전송`ChannelStatus`은 복구할 수 없습니다`DescribeChannel`. 에서 `ChannelStatusReason` 필드를 읽고 근본 원인을 `DescribeChannel` 식별합니다. 기본 문제를 수정하고 실패한 전송을 삭제한 다음 수정된 구성으로 다시 생성합니다.

## 높은 데이터 신선도
<a name="troubleshooting-high-data-freshness"></a>

 `DataFreshness` 지표는 전송되지 않은 가장 오래된 레코드의 수명을 측정합니다. 값이 높으면 전송이 수집에 뒤쳐지고 있음을 나타냅니다. 일반적인 원인: 
+ 대상 테이블의 파티션 수가 많으면 메타데이터 오버헤드가 증가합니다.
+ 많은 소규모 커밋에서 테이블 메타데이터가 증가하면 커밋 처리량이 줄어듭니다.
+ 스트림 처리량이 낮고 신선도 설정이 낮으면 소량의 전송이 자주 발생합니다.

 해결 방법: Apache Iceberg의 테이블 스트리밍의 경우 Amazon S3 Tables 유지 관리(압축 및 스냅샷 만료)를 활성화하여 메타데이터 증가를 관리합니다. 처리량이 적은 스트림의 경우 각 전송 주기에 대해 더 많은 데이터가 배치 처리되도록 `DataFreshnessInSeconds` 값을 늘립니다.

 가장 엄격한 데이터 최신성 설정에는 최소 지속적인 스트림 처리량이 필요하므로 각 주기마다 효율적인 전송 및 인라인 압축을 위해 충분한 데이터가 누적됩니다. 스트림이 해당 처리량보다 적게 생성되는 경우 더 높은 `DataFreshnessInSeconds` 값을 사용합니다.

## 0보다 큰 실패한 레코드
<a name="troubleshooting-failed-records"></a>

 실패한 레코드 지표가 0이 아닌 경우(`DeliveryToS3.FailedRecordCount`Amazon S3 전송 또는 스트리밍 테이블 전송`DeliveryToIceberg.FailedRowCount`의 경우) 레코드가 대상 대신 배달 못한 편지 대기열로 전송됩니다.

 **Apache Iceberg에서 테이블을 스트리밍하는 경우:** 
+ 스키마 불일치 - 레코드가 등록된 스키마를 준수하지 않습니다.
+ 필수 필드 누락 - null할 수 없는 열에는 레코드에 값이 없습니다.
+ GSR\_JSON 형식에 AWS Glue Schema Registry 직렬 변환기를 사용하지 않음 - 생산자는 AWS Glue Schema Registry 생산자 라이브러리를 사용해야 합니다.

 **범용 Amazon S3 버킷의 경우:** 
+ 형식 불일치 - 레코드 형식이 구성된 입력 형식과 일치하지 않습니다.

 해결 방법: 배달 못한 편지 대기열 항목을 검사하여 자세한 오류 정보를 확인합니다. CloudWatch Logs에서 전송을 확인하여 특정 구문 분석 또는 검증 오류를 확인합니다. 적합한 레코드를 전송하도록 생산자를 수정합니다.

## 대상에 데이터가 표시되지 않음
<a name="troubleshooting-no-data"></a>

 전송이 ACTIVE 상태이지만 대상에 데이터가 표시되지 않는 경우 가장 일반적인 원인은 다음과 같습니다.
+ 권한 문제 - IAM 역할이 대상에 쓸 수 없습니다. CloudWatch Logs에서 `AccessDenied` 오류를 확인합니다.
+ 출력 키 접두사 불일치(범용 Amazon S3 버킷) - `s3:PutObject` 권한 범위가와 같은 접두사로 지정된 경우 출력 `arn:aws:s3:::my-bucket/data*`키 템플릿에서 생성된 키는 로 시작해야 합니다`data/`. 일치하지 않으면 모든 쓰기가 거부됩니다.
+ 테이블 권한 누락(스트리밍 테이블) - 고객 관리형 AWS KMS 키로 대상 테이블을 암호화하는 경우 서비스 실행 역할에 다른 `s3tables` 작업 `s3tables:PutTableEncryption` 외에도가 포함되어 있는지 확인합니다. 그렇지 않으면가 `CreateTable` 성공하지만 테이블 암호화가 실패하고 테이블이 생성되지 않으며 데이터가 전송되지 않습니다.
+ 로깅 권한 누락 - 서비스 실행 역할에 `logs:CreateLogStream` 및가 없는 경우 `logs:PutLogEvents`전송 실패가 CloudWatch Logs에 기록되지 않으므로 권한 문제가 자동 실패로 나타날 수 있습니다. 로그가 없는 경우 먼저 로깅 권한을 확인합니다.
+ 생성 후 새 데이터 없음 - 전송이 스트림의 기존 데이터를 채우지 않습니다. 전송이 ACTIVE가 된 후 작성된 레코드만 전송됩니다.

## 전송 일시 중지됨
<a name="troubleshooting-suspended"></a>

 대상을 사용할 수 없거나 호환되지 않으면 전송이 일시 중지 상태로 전환됩니다. 일반적인 원인: 
+ Apache Iceberg 대상 테이블의 스트리밍 테이블이 삭제되었습니다.
+ Amazon S3 버킷 소유자가 예상 계정과 일치하지 않습니다(소유권 불일치).
+ 대상 테이블에서 호환되지 않는 파티션 열이 감지되었습니다.

 일시 중지된 전송은 재개할 수 없습니다. 유효한 대상 구성으로 새 전송을 생성해야 합니다.

## CloudWatch Logs의 권한 거부 오류
<a name="troubleshooting-permission-denied"></a>

 `AccessDenied` 전송 CloudWatch Logs의 오류는 권한 문제를 나타냅니다. 일반적인 원인: 
+ 전송이 생성된 후 IAM 역할 정책이 수정되었습니다.
+ 역할의 액세스를 거부하도록 Amazon S3 버킷 정책이 변경되었습니다.
+ 역할의 신뢰 정책은 Kinesis Data Streams 서비스가 이를 수임하도록 허용하지 않습니다.
+  AWS KMS 키 정책은 전송 역할에 대한 암호화 또는 복호화 액세스를 거부합니다.

 관련 정책을 검토하고 수정한 다음 전송이 재개되는지 확인합니다.

## 스트림에서 전송을 사용할 수 없음
<a name="troubleshooting-not-available"></a>

 스트리밍 테이블 및 Amazon S3 전송을 사용하려면 Kinesis Data Streams 스트림이 온디맨드 표준 또는 온디맨드 어드밴티지 용량 모드여야 합니다. 스트림이 프로비저닝된 모드를 사용하는 경우 전송을 생성하려면 먼저 스트림을 온디맨드 모드로 전환해야 합니다.

## 스키마 변경 후 전송 중지
<a name="troubleshooting-schema-change"></a>

 배달은 스키마 진화를 지원하지 않습니다. 전송을 생성한 후 AWS Glue Schema Registry에서 스키마를 업데이트하면 새 스키마 버전으로 생성된 레코드가 검증에 실패하고 배달 못한 편지 대기열로 라우팅될 수 있습니다.

 해결하려면 생산자에서 스키마 변경 사항을 되돌리거나 기존 전송을 삭제하고 업데이트된 스키마로 다시 생성합니다.

## 스트림을 삭제할 수 없음
<a name="troubleshooting-cannot-delete-stream"></a>

 스트림에 하나 이상의 활성 전송이 있는 `ResourceInUseException` 경우에서 `DeleteStream` 요청이 실패합니다. 전송이 연결되어 있는 동안에는 스트림을 삭제할 수 없습니다.

 해결하려면:를 사용하여 스트림의 전송을 나열`DeleteChannel`하고`ListChannels`(스트림 필터 사용),를 사용하여 각 전송을 삭제한 다음 스트림을 삭제합니다.