慎重に検討した結果、Amazon Kinesis Data Analytics for SQL アプリケーションを中止することにしました。
1. **2025 年 9 月 1** 日以降、Amazon Kinesis Data Analytics for SQL アプリケーションのバグ修正は提供されません。これは、今後の廃止によりサポートが制限されるためです。
2. **2025 年 10 月 15** 日以降、新しい Kinesis Data Analytics for SQL アプリケーションを作成することはできません。
3. **2026 年 1 月 27 日**以降、アプリケーションは削除されます。Amazon Kinesis Data Analytics for SQL アプリケーションを起動することも操作することもできなくなります。これ以降、Amazon Kinesis Data Analytics for SQL のサポートは終了します。詳細については、「[Amazon Kinesis Data Analytics for SQL アプリケーションのサポート終了](discontinuation.md)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Kinesis Data Analytics for SQL アプリケーションのトラブルシューティング
以下は、Amazon Kinesis Data Analytics for SQL アプリケーションで発生する可能性のある問題を解決するために役立ちます。
**Topics**
+ [停止したアプリケーション](#idle-applications)
+ [SQL コードを実行できません](#sql-statement)
+ [スキーマを検出または発見できない](#detect-schema)
+ [リファレンスデータが古い](#reference-reload)
+ [アプリケーションが送信先に書き込まれない](#output)
+ [モニタリングする重要なアプリケーションの状態パラメータ](#parameters)
+ [アプリケーションを実行するときの無効なコードエラー](#invalid-code)
+ [アプリケーションによってエラーがエラーストリームに書き込まれている](#error-stream)
+ [スループット不足または高い MillisBehindLatest](#insufficient-throughput)
## 停止したアプリケーション
+ **Amazon Kinesis Data Analytics for SQL アプリケーションとは何ですか?**
停止されたアプリケーションとは、最低 3 か月間レコードを処理していないことが確認されたアプリケーションのことです。つまり、顧客が使用していない Kinesis Data Analytics for SQL のリソースに対して料金を支払っているということです。
+ **はアイドル状態のアプリケーションの停止をいつ AWS 開始しますか？**
AWS は、2023 年 11 月 14 日にアイドル状態のアプリケーションの停止を開始し、2023 年 11 月 21 日までに完了します。そのリージョンのタイムゾーンの営業時間に、アイドル状態のアプリケーションを停止します。
+ **停止した Kinesis Data Analytics for SQL アプリケーションを再起動できますか?**
はい。アプリケーションを再起動する必要がある場合は、通常どおり再起動できます。サポートチケットを提出する必要はありません。
+ **がアイドル状態のアプリケーション AWS を停止すると、クエリ結果も削除されますか？**
いいえ。まず、アプリケーションはアイドル状態なので、クエリを処理しません。次に、クエリ結果は Kinesis Data Analytics for SQL には保存されません。Kinesis Data Analytics for SQL アプリケーションに、計算結果が送信されるシンクの宛先 (Amazon S3 または別のデータストリームなど) を設定します。そのため、お客様がデータの完全な所有権を保持し、ストレージサービスの条件に基づいてデータを引き続き取得できます。
+ **アプリケーションを停止したくない場合はどうすれば良いですか?**
2023 年 11 月 10 日までにアプリケーションを停止しないように要請するメールをサービスチーム (kda-sql-questions@amazon.com) に送信してください。メールには、アカウント ID とアプリケーション ARN を記載する必要があります。
## SQL コードを実行できません
特定の SQL ステートメントを正しく動作させる方法を判断する必要がある場合は、Kinesis Data Analytics を使用するときにさまざまなリソースを使用できます。
+ SQL ステートメントの詳細については、「[Kinesis Data Analytics for SQL の例](examples.md)」を参照してください。このセクションでは、使用可能な SQL の例が多数紹介されています。
+ [Amazon Kinesis Data Analytics SQL Reference](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sqlrf_Preface.html) では、ストリーミング SQL ステートメントの記述に関する詳細なガイドを提供しています。
+ それでも問題が解決しない場合は、「[Kinesis Data Analytics フォーラム](https://forums.aws.amazon.com/ann.jspa?annID=4153)」に質問することをお勧めします。
## スキーマを検出または発見できない
場合によっては、Kinesis Data Analytics でスキーマを検出または発見できないことがあります。このような場合の多くは、Kinesis Data Analytics をそのまま使用できます。
区切り文字を使用しない UTF-8 エンコードデータ、カンマ区切り値 (CSV) 以外の形式を使用するデータ、またはスキーマを検出しなかった検索 API があると想定します。このような場合は、スキーマを手動で定義するか、文字列操作関数を使用して、データを構造化できます。
ストリームのスキーマを検出するために、Kinesis Data Analytics はランダムにストリームの最新データをサンプリングします。ストリームに継続的にデータを送信していない場合、Kinesis Data Analytics はサンプルの取得やスキーマの検出を行えないことがあります。詳細については、「[ストリーミングデータのスキーマ検出機能の使用](sch-dis.md)」を参照してください。
## リファレンスデータが古い
リファレンスデータは、アプリケーションの起動または更新時、あるいはサービスの問題によって発生したアプリケーションの中断時に、Amazon Simple Storage Service (Amazon S3) オブジェクトからアプリケーションにロードされます。
基になる Amazon S3 オブジェクトが更新された場合、リファレンスデータはアプリケーションにロードされません。
アプリケーション内のリファレンスデータが最新ではない場合、次のステップに従ってデータを再ロードできます。
1. Kinesis Data Analytics コンソールで、リストからアプリケーション名を選択し、[**アプリケーションの詳細**] を選択します。
1. [**SQL エディタに移動**] を選択し、アプリケーションの [**リアルタイム分析**] ページを開きます。
1. [**ソースデータ**] ビューで、リファレンスデータテーブル名を選択します。
1. [**アクション**]、[**リファレンスデータテーブルの同期**] の順に選択します。
## アプリケーションが送信先に書き込まれない
データが送信先に書き込まれない場合は、以下を確認してください。
+ アプリケーションのロールに、送信先へのアクセスに十分なアクセス許可があることを確認します。詳細については、[Kinesis ストリームに書き込むためのアクセス権限ポリシー](iam-role.md#iam-role-permissions-policy-ak-stream) または [Firehose 配信ストリームに書き込むためのアクセス権限ポリシー](iam-role.md#iam-role-permissions-policy-af-delivery-stream) を参照してください。
+ アプリケーションの送信先が正しく設定されていることと、アプリケーションの出力ストリームに正しい名前が使用されていることを確認します。
+ データが書き込まれているかどうかを確認するには、出力ストリームの Amazon CloudWatch メトリクスを確認します。CloudWatch メトリクスの詳細については、「[Amazon CloudWatch によるモニターリング](monitoring-cloudwatch.md)」を参照してください。
+ [AddApplicationCloudWatchLoggingOption](API_AddApplicationCloudWatchLoggingOption.md) を使用して CloudWatch ログストリームを追加します。アプリケーションはログストリームに設定エラーを書き込みます。
ロールと送信先が正しく設定されている場合は、アプリケーションを再起動し、`LAST_STOPPED_POINT` に [InputStartingPositionConfiguration](API_InputStartingPositionConfiguration.md) を指定します。
## モニタリングする重要なアプリケーションの状態パラメータ
アプリケーションが正しく実行されていることを確認するには、特定の重要なパラメータをモニタリングすることをお勧めします。
最も重要なパラメータとして、Amazon CloudWatch メトリクス (`MillisBehindLatest`) をモニタリングする必要があります。このメトリクスは、ストリームの読み込みが現在時刻からどの程度遅延しているかを表します。このメトリクスは、ソースストリームからのレコードの処理が十分に高速かどうかを判断するのに役立ちます。
一般的に、1 時間以上遅れる場合は、CloudWatch アラームのトリガーを設定する必要があります。ただし、これにかかる時間はユースケースによって異なります。時間は必要に応じて調整することができます。
詳細については、「[ベストプラクティス](best-practices.md)」を参照してください。
## アプリケーションを実行するときの無効なコードエラー
Amazon Kinesis Data Analytics アプリケーションの SQL コードを保存および実行できない場合、一般的な原因は次のとおりです。
+ **ストリームが SQL コードで再定義された** – ストリームと、ストリームに関連付けられたポンプを作成した後で、コードで同じストリームを再定義することはできません。ストリームの作成の詳細については、Amazon Kinesis Data Analytics SQL Reference の「[CREATE STREAM](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-create-stream.html)」を参照してください。ポンプの作成の詳細については、「[CREATE PUMP](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-create-pump.html)」を参照してください。
+ **GROUP BY 句で複数の ROWTIME 列を使用している** – GROUP BY 句には、1 つの ROWTIME 列のみ指定できます。詳細については、Amazon Kinesis Data Analytics SQL Reference の「[GROUP BY](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-group-by-clause.html)」および「[ROWTIME](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-rowtime.html)」を参照してください。
+ **1 つ以上のデータ型に無効なキャストがある** – この場合は、コードに無効で暗黙的なキャストがあります。たとえば、コードの `bigint` に `timestamp` をキャストする場合があります。
+ **ストリームに、サービスの予約済みストリーム名と同じ名前がある** – ストリームに、サービスの予約済みストリーム (`error_stream`) と同じ名前を付けることはできません。
## アプリケーションによってエラーがエラーストリームに書き込まれている
アプリケーションによってエラーがアプリケーション内のエラーストリームに書き込まれている場合は、標準ライブラリを使用して、`DATA_ROW` フィールドの値をデコードします。エラーストリームの詳細については、「[エラー処理](error-handling.md)」を参照してください。
## スループット不足または高い MillisBehindLatest
アプリケーションの [MillisBehindLatest](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) メトリクスが常に増加しているか、継続的に 1000 (1 秒) を超える場合は、次のような理由が考えられます。
+ アプリケーションの [InputBytes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) CloudWatch メトリクスを確認します。取り込みが 4 MB/秒を超えている場合は、これが `MillisBehindLatest` が増加する原因となっている可能性があります。アプリケーションのスループットを向上させるため、`InputParallelism` パラメータの値を増やします。詳細については、「[スループットの増加に合わせた入力ストリームの並列処理](input-parallelism.md)」を参照してください。
+ 送信先への配信の失敗について、アプリケーションの出力配信の [Success](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) メトリクスを確認します。出力を正しく設定済みで、出力ストリームに十分な容量があることを確認します。
+ アプリケーションで事前処理または出力に AWS Lambda 関数を使用している場合は、アプリケーションの [InputProcessing.Duration](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) または [LambdaDelivery.Duration](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) CloudWatch メトリクスを確認します。Lambda 関数の呼び出し所要時間が 5 秒より長い場合は、次のことを検討してください。
+ Lambda 関数の**メモリ**割り当てを増やします。この操作は、 AWS Lambda コンソールの [**設定**] ページの [**基本設定**] で行うことができます。詳細については、[https://docs.aws.amazon.com/lambda/latest/dg/resource-model.html](https://docs.aws.amazon.com/lambda/latest/dg/resource-model.html) 開発者ガイド*の「AWS Lambda Lambda 関数の設定*」を参照してください。
+ アプリケーションの入力ストリームで、シャードの数を増やします。これにより、アプリケーションが呼び出す並行関数の数が増え、スループットが向上する可能性があります。
+ 関数が、外部リソースに対する同時リクエストなど、パフォーマンスに影響を与えるようなブロック呼び出しを実行していないことを確認します。
+ AWS Lambda 関数を調べて、パフォーマンスを向上させることができる他の領域があるかどうかを確認してください。アプリケーション Lambda 関数の CloudWatch Logs を確認します。詳細については、AWS Lambda デベロッパーガイドの「[ の Amazon CloudWatch メトリクスへのアクセス](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html)」を参照してください。
+ アプリケーションが、Kinesis 処理単位 (KPU) のデフォルトの制限に達していないことを確認します。アプリケーションがこの制限に達している場合は、制限の引き上げをリクエストできます。詳細については、「[アプリケーションを自動的にスケーリングしてスループットを向上させる](how-it-works-autoscaling.md)」を参照してください。
+ KPU の上限を引き上げてもアプリケーションの問題が解決しない場合は、アプリケーションの入力スループットが 100 MB/秒を超えていないことを確認してください。100 MB/秒を超える場合は、Kinesis Data Analytics SQL アプリケーションが読み取るデータソースに送信されるデータ量を減らすなど、アプリケーションを安定させるために全体のスループットを下げるよう、変更を行うことをお勧めします。また、アプリケーションの並列処理を増やす、計算時間を短縮する、列指向データタイプを VARCHAR からサイズの小さいデータ型 (INTEGER、LONG など) に変更する、サンプリングやフィルタリングによって処理されるデータを減らすなど、他のアプローチも推奨していました。
**注記**
アプリケーションの予測入力スループットが 100 MB/秒を超えることになる場合は、複数の SQL アプリケーションを使用する計画を事前に立てたり、managed-flink/latest/java/ に移行したりできるように、アプリケーションの `InputProcessing.OkBytes` メトリックを定期的に確認することをお勧めします。