ストリームの失敗のデバッグ

ストリーミングパイプラインを作成する際、ストリーミングの失敗が発生することがあります。このページでは、失敗したストリームのデバッグを行うためのお勧めのワークフローを提案し、ストリームが失敗した理由を理解するのに役立つ Foundry の利用可能なツールについて説明します。

失敗の種類

失敗は、失敗の種類に分類することができ、それぞれの失敗の種類は異なる根本的な原因を示すことができます。以下は、最も一般的な失敗の種類と、それらが発生する理由です。

直ちに発生する失敗: ストリームが開始してから5分以内に失敗します。
一時的な失敗: ストリームが一定期間実行され、一度失敗し、再起動に成功して実行が続行されます。
持続的な失敗: ストリームが一定期間実行され、その後、ストリームが再起動してから5～10分以内に発生する一連の直ちに発生する失敗があります。

直ちに発生する失敗

すぐに失敗するストリームは、通常、ユーザーが作成したロジックに問題があります。例えば、失敗は無効なキャストや解析の例外など、ストリーミングクラスターが正常に起動できない問題によるものです。

以前は成功していたストリームが今では失敗する場合、ロジックや上流のストリームの変更を調べて、潜在的な問題を見つけます。

これらの問題の根本原因を特定するには、以下のストリーミングクラスターログの確認ワークフローで説明されている手順に従ってください。

一時的な失敗

以前に成功していたストリームが失敗し、再起動後に再度実行される場合、通常はネットワークの停止によるインフラの問題が原因です。停止は、Foundry インスタンスが実行されているクラウドプロバイダーによってよく引き起こされます（例：AWS、Azure、GCP の停止）。ストリームにスケジュールを適用すると、Foundry は自動的にストリームを再実行し、中断したところから処理を続行することができます。

持続的な失敗

以前は成功していたストリームが、ロジックの変更がないにも関わらず繰り返し失敗する場合、通常は最も特定が難しいものです。ただし、一般的には2つの要因のいずれかが原因です：新しい入力データがストリームの進行を妨げている（例：無効なタイプ、破損したデータなど）、または持続的なインフラ問題がある（AWS の停止など）。

パイプラインのロジックがエラーの原因であるかどうかを確認するには、以下のストリーミングクラスターログの確認ワークフローで説明されている手順に従ってください。

一般的なデバッグワークフロー

以下では、一般的なストリーミング問題を解決するために使用できるいくつかのワークフローを概説します。これらのチェックは特定の順序で行う必要はありません。

ストリーミングクラスターログの確認

ストリームログの取得の手順に従い、ログ内の例外やエラー、または「スロウ可能」を検索します。これらのログは通常、「ERROR」、「スロウ可能」、または「Exception」といったキーワードを通じて潜在的な根本的問題の説明を提供します。

パイプラインロジックの確認

パイプラインロジックの変更は、ユーザーが作成したコードのバグが原因で破損が発生することがよくあります。通常、前のステップで得られたログの例外は、問題を引き起こしている特定のコードを指摘します。そうであれば、問題が修正されるかどうかを確認するために、変更をロールバックしてみてください。

入力データの確認

ストリーミングパイプラインのロジックは、予期しないデータに遭遇すると例外をスローすることがあります。このような動作の例は、パイプラインが2つの列を互いに割り、除数が 0 または null の値を返す場合です。入力ストリームの最後のレコードを確認し、ストリーミングパイプラインに問題を引き起こす可能性のあるデータが変更されているかどうかを確認します。変更されたデータを見つけた場合、データをクリーニングしたり削除したりするフィルターやロジックを追加することを検討してください。