翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# データ配信のトラブルシューティング
このセクションを使用して、データ配信に関する一般的な問題を解決します。
## 配信が CREATING 状態でスタックしました
配信を作成すると、リソースのプロビジョニング中に CREATING 状態になります。プロビジョニングは通常数分以内に完了します。配信が長期間 CREATING のままである場合、または FAILED に移行した場合、設定エラーが原因である可能性があります。
`DescribeChannel` を呼び出して、現在のステータスとステータスの理由を確認します。一般的な原因には、以下が含まれます。
+ IAM ロール ARN が無効であるか、ロールポリシーのアクセス許可が不十分です。
+ 送信先 Amazon S3 バケットが存在しないか、別のリージョンにあります。
+ Schema Registry の AWS Glue スキーマ ARN を解決できません。
## FAILED 状態の配信
( によって`FAILED`返される) が `ChannelStatus` である配信を復元することはできません`DescribeChannel`。から `ChannelStatusReason`フィールド`DescribeChannel`を読み、根本原因を特定します。根本的な問題を修正し、失敗した配信を削除して、修正された設定で再作成します。
## 高いデータ鮮度
`DataFreshness` メトリクスは、最も古い未配信レコードの経過時間を測定します。高い値は、配信が取り込みに遅れていることを示します。一般的な原因:
+ 送信先テーブルのパーティション数が多いと、メタデータのオーバーヘッドが増加します。
+ 多くの小さなコミットからのテーブルメタデータの増加により、コミットスループットが低下します。
+ ストリームスループットが低く、鮮度設定が低いと、配信が頻繁に少なくなります。
解決策: Apache Iceberg でテーブルをストリーミングする場合は、Amazon S3 Tables のメンテナンス (圧縮とスナップショットの有効期限) を有効にしてメタデータの増加を管理します。低スループットストリームの場合は、 `DataFreshnessInSeconds`値を増やして、配信サイクルごとにより多くのデータをバッチ処理できるようにします。
最も厳密なデータ鮮度設定では、各サイクルで効率的な配信とインライン圧縮のために十分なデータが蓄積されるように、最小の持続的なストリームスループットが必要です。ストリームのスループットがこのスループットを下回る場合は、より高い`DataFreshnessInSeconds`値を使用します。
## 失敗したレコードが 0 より大きい
失敗したレコードメトリクスがゼロ以外の場合 (`DeliveryToS3.FailedRecordCount`Amazon S3 配信またはストリーミングテーブル配信`DeliveryToIceberg.FailedRowCount`の場合）、レコードは送信先ではなくデッドレターキューに送信されています。
**Apache Iceberg のストリーミングテーブルの場合:**
+ スキーマの不一致 – レコードが登録済みスキーマに準拠していません。
+ 必須フィールドがありません – null でない列にはレコードに値がありません。
+ GSR\_JSON 形式で AWS Glue Schema Registry シリアライザーを使用しない – プロデューサーは AWS Glue Schema Registry プロデューサーライブラリを使用する必要があります。
**汎用 Amazon S3 バケットの場合:**
+ 形式の不一致 – レコード形式が設定された入力形式と一致しません。
解決策: デッドレターキューエントリに詳細なエラー情報がないか検査します。特定の解析または検証エラーを確認するには、CloudWatch Logs で配信を確認します。適合レコードを送信するようにプロデューサーを修正しました。
## 送信先にデータが表示されない
配信が 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 になった後に書き込まれたレコードのみが配信されます。
## 配信の中断
配信先が使用不可または互換性がない場合、配信は中断状態になります。一般的な原因:
+ Apache Iceberg 送信先テーブルのストリーミングテーブルが削除されました。
+ Amazon S3 バケット所有者が、予想されるアカウントと一致しません (所有権の不一致）。
+ 宛先テーブルで互換性のないパーティション列が検出されました。
中断された配信を再開することはできません。有効な送信先設定で新しい配信を作成する必要があります。
## CloudWatch Logs のアクセス許可拒否エラー
`AccessDenied` 配信の CloudWatch Logs のエラーは、アクセス許可の問題を示します。一般的な原因:
+ IAM ロールポリシーは、配信の作成後に変更されました。
+ Amazon S3 バケットポリシーが変更され、ロールからのアクセスが拒否されました。
+ ロールの信頼ポリシーは、Kinesis Data Streams サービスがロールを引き受けることを許可しません。
+ AWS KMS キーポリシーは、配信のロールへの暗号化または復号アクセスを拒否します。
関連するポリシーを確認して修正し、配信が再開することを確認します。
## ストリームで配信が利用できない
ストリーミングテーブルと Amazon S3 配信では、Kinesis Data Streams ストリームがオンデマンドスタンダードまたはオンデマンドアドバンテージキャパシティモードである必要があります。ストリームがプロビジョンドモードを使用している場合は、配信を作成する前にオンデマンドモードに切り替える必要があります。
## スキーマの変更後に配信が停止する
配信はスキーマの進化をサポートしていません。配信の作成後に AWS Glue Schema Registry でスキーマを更新すると、新しいスキーマバージョンで生成されたレコードが検証に失敗し、デッドレターキューにルーティングされる可能性があります。
解決するには: プロデューサーでスキーマの変更を元に戻すか、既存の配信を削除して、更新されたスキーマで再作成します。
## ストリームを削除できません
ストリームに 1 つ以上のアクティブな配信`ResourceInUseException`がある場合、`DeleteStream`リクエストは で失敗します。配信がアタッチされている間は、ストリームを削除することはできません。
解決するには: `ListChannels` (ストリームフィルターを使用して) でストリームの配信を一覧表示し、 で各配信を削除してから`DeleteChannel`、ストリームを削除します。