一般的な問題 - Amazon Data Firehose
Firehose ストリームを使用できません宛先にデータがありませんデータの鮮度メトリクスの増加または未発行Apache Parquet へのレコード形式変換が失敗するLambda のために変換されたオブジェクトのフィールドが欠落しています

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

一般的な問題

Firehose ストリームの使用中に一般的な問題を解決するのに役立つトラブルシューティングのヒントを次に示します。

Firehose ストリームを使用できません

一部のサービスは同じ にある Firehose ストリームにのみメッセージとイベントを送信できるため、Firehose ストリームは CloudWatch Logs、CloudWatch Events、または AWS IoT アクション AWS のターゲットとして使用できません AWS リージョン。Firehose ストリームが他のサービスと同じリージョンにあることを確認します。

宛先にデータがありません

データ取り込みの問題がなく、Firehose ストリームに関して生成されるメトリクスが正常と思われる場合でも、宛先にデータが表示されないときは、リーダーロジックを確認します。リーダーがすべてのデータを正しく解析していることを確認します。

データの鮮度メトリクスの増加または未発行

データの鮮度は、Firehose ストリーム内のデータがどの程度最新であるかを示す指標です。これは、Firehose ストリーム内の最も古いデータレコードの経過時間であり、Firehose がそのデータを取り込んだ時点から現在の時刻までの時間で測定されます。Firehose は、データの鮮度をモニタリングするために使用できるメトリクスを提供します。特定の配信先に関するデータの鮮度メトリクスを確認するには、「CloudWatch メトリクスを使用して Amazon Data Firehose をモニタリングする」を参照してください。

すべてのイベントまたはすべてのドキュメントのバックアップを有効にする場合は、メイン配信先用とバックアップ用に 2 つのデータの鮮度メトリクスを別個にモニタリングします。

データの鮮度メトリクスが生成されていない場合は、Firehose ストリームにアクティブな配信がないことを意味します。これは、データ配信が完全にブロックされているか、着信データがない場合に発生します。

データの鮮度メトリクスが増え続けている場合は、データ配信が遅れていることを意味します。これは、次のいずれかの理由で発生します。

  • 配信先が配信率に対応できない。トラフィックが多いために Firehose で一時的なエラーが発生すると、配信が遅れる場合があります。これは、Amazon S3 以外の配信先で発生しがちです (OpenSearch Service、Amazon Redshift、または Splunk で発生することがあります)。配信先に、着信トラフィックを処理するための十分な容量があることを確認します。

  • 配信先が遅い。Firehose で高レイテンシーが発生すると、データ配信が遅れることがあります。配信先のレイテンシーメトリクスをモニタリングします。

  • Lambda 関数が遅い。これにより、データ配信レートが Firehose ストリームのデータ取り込みレートよりも低くなる場合があります。可能であれば、Lambda 関数の効率を向上させます。たとえば、関数がネットワーク IO を実行する場合は、複数のスレッドまたは非同期 IO を使用して並列処理を増やします。また、Lambda 関数のメモリサイズを大きくすることで CPU 割り当てを相応に増やします。これにより、Lambda 呼び出しが高速化される場合があります。Lambda 関数の設定については、AWS 「Lambda 関数の設定」を参照してください。

  • データ配信中に障害が発生した。Amazon CloudWatch Logs を使用してエラーをモニタリングする方法については、「CloudWatch Logs を使用して Amazon Data Firehose をモニタリングする」を参照してください。

  • Firehose ストリームのデータソースが Kinesis データストリームである場合、スロットリングが発生している可能性があります。ThrottledGetRecords メトリクス、ThrottledGetShardIterator メトリクス、および ThrottledDescribeStream メトリクスを確認します。Kinesis データストリームに複数のコンシューマがアタッチされている場合は、以下を考慮してください。

    • ThrottledGetRecords メトリクスと ThrottledGetShardIterator メトリクスが高い場合は、データストリーム用にプロビジョニングするシャードの数を増やすことをお勧めします。

    • ThrottledDescribeStream が高い場合、KinesisStreamSourceConfiguration で設定されたロールに対する kinesis:listshards アクセス許可を追加することをお勧めします。

  • 配信先のバッファリングヒントが低い。これにより、宛先に対して Firehose が行う必要があるラウンドトリップの数が増える場合があります。バッファリングヒントの値を大きくすることを検討します。詳細については、「BufferingHints」を参照してください。

  • 再試行期間が長くなると、エラーの発生数が増えたときに配信が遅れる場合があります。再試行期間を短縮することを検討してください。また、エラーをモニタリングし、エラーを減らしてください。Amazon CloudWatch Logs を使用してエラーをモニタリングする方法については、「CloudWatch Logs を使用して Amazon Data Firehose をモニタリングする」を参照してください。

  • 配信先が Splunk である場合、DeliveryToSplunk.DataFreshness が高くても DeliveryToSplunk.Success が適切であると思われるときは、Splunk クラスターがビジー状態である可能性があります。可能であれば Splunk クラスターを解放します。または、 AWS サポートに連絡して、Splunk クラスターとの通信に Firehose が使用するチャネルの数の増加をリクエストしてください。

Apache Parquet へのレコード形式変換が失敗する

これは、 Setタイプを含む DynamoDB データを取得し、Lambda 経由で Firehose ストリームにストリーミングし、 AWS Glue Data Catalog を使用してレコード形式を Apache Parquet に変換した場合に発生します。

AWS Glue クローラが DynamoDB セットのデータ型 (StringSet、NumberSet、および BinarySet) にインデックスを作成するとSET<BINARY>、それぞれ SET<STRING>、SET<BIGINT>、および としてデータカタログに保存されます。ただし、Firehose がデータレコードを Apache Parquet 形式に変換するには、Apache Hive データ型が必要です。セット型は有効な Apache Hive データ型ではないため、変換は失敗します。変換を機能させるには、Apache Hive データ型でデータカタログを更新します。そのためには、データカタログの set を array に変更します。

AWS Glue データカタログarrayで 1 つ以上のデータ型を から set に変更するには

  1. にサインイン AWS マネジメントコンソール し、https://console.aws.amazon.com/glue/ で AWS Glue コンソールを開きます。

  2. 左側のペインの [データカタログ] 見出しにある [テーブル] を選択します。

  3. テーブルのリストで、1 つ以上のデータ型を変更する必要があるテーブルの名前を選択します。そのテーブルの詳細ページが表示されます。

  4. 詳細ページの右上隅にある [Edit schema] ボタンを選択します。

  5. [データ型] 列で、最初のデータ型 set を選択します。

  6. [Column type] ドロップダウンリストで、set から array に型を変更します。

  7. [ArraySchema] に、array<string>、 array<int>、または array<binary> と入力します。これは、シナリオの適切なデータ型によって異なります。

  8. [更新] を選択します。

  9. 他の set 型を array 型に変換するには、前のステップを繰り返します。

  10. [保存] を選択します。

Lambda のために変換されたオブジェクトのフィールドが欠落しています

Lambda データ変換を使用して JSON データを Parquet オブジェクトに変換すると、変換後に一部のフィールドが欠落している可能性があります。これは、JSON オブジェクトに大文字があり、大文字と小文字の区別が false に設定されている場合に発生します。これにより、データ変換後に JSON キーに不一致が発生し、S3 バケット内の、結果として得られる Parquet オブジェクトでデータが欠落する可能性があります。

これを修復するには、変換後に JSON キーが一致するように、ホース設定で deserializationOption: case.insensitive が true に設定されていることを確認してください。