外部関数のトラブルシューティング

このトピックでは、外部関数のトラブルシューティング方法について説明します。

一部のクラウドプラットフォームでは、そのクラウドプラットフォームで外部関数を作成する手順に、追加のトラブルシューティング情報が含まれている場合があります。

このトピックの内容:

一般的なトラブルシューティング

外部関数の引数がリモートサービスの引数に対応していることを確認

独自のリモートサービスを作成し、リモートサービスへの引数の数、データ型、または順序を変更する場合は、外部関数に対応する変更を加えることを忘れないでください。現在、 ALTER EXTERNAL FUNCTION コマンドにはパラメーターを変更するオプションがないため、引数を変更するには、外部関数を削除して再作成する必要があります。

パフォーマンス

以下のヒントは、パフォーマンスの問題のデバッグに役立つ場合があります。

スケーラビリティ のトラブルシューティングセクションもご参照ください。

スケーラビリティ

以下のヒントは、スケーラビリティの問題のデバッグに役立つ場合があります。

  • クエリプロファイルページ ページを使用して、リクエストごとの平均レイテンシを確認します。

  • クエリプロファイルページ ページを使用して、 リモートサービスが各行に1回だけ渡されると思い込まない というタイトルのセクションにリストされたものを含む一時的なエラーが原因により、リクエストが再試行された回数を確認します。

  • リモートサービスのリソース使用状況をモニターして、負荷に合わせてスケーリングする方法を確認し、リモートサービスにピーク負荷に対応できる十分な容量があることを確認します。

  • Amazon API Gatewayまたはリモートサービスのロギングを利用して、リクエストごとの詳細を取得します。

  • Snowflakeがリモートサービスにリクエストを送信する際の同時実行性を制御します。詳細については、 同時実行 をご参照ください。

  • リモートサービスが過負荷状態のときに、リモートサービスから HTTP 応答コード429を返します。レイテンシが長くなるのを待つのではなく、できるだけ早くこれを返します。

  • プロキシサービスのタイムアウトを考慮してください。たとえば、2020年7月現在、Amazon API Gatewayのタイムアウトは30秒です。タイムアウトは、リモートサービスの過負荷など、さまざまな要因によって発生する可能性があります。

Snowflakeは妥当な時間内に一時的なエラー/タイムアウトを再試行しますが、サービスが引き続き過負荷になり、再試行が成功しない場合、最終的にクエリは中止されます。

パフォーマンス のトラブルシューティングセクションもご参照ください。

特定の症状

プラットフォームに依存しない症状

症状:外部関数を呼び出そうとすると、「エラー解析 JSON :無効な応答」というメッセージが表示

考えられる原因

最も可能性の高い原因は、リモートサービスから返された JSON (例: AWS Lambda関数)が正しく構築されていないことです。

考えられる解決策

配列中の配列1つを返すとともに、受け取った入力行ごとに1つの内部配列が返すことを確認します。 Snowflakeが受信するデータ形式 で出力形式の説明を確認します。

症状:戻り値の形式が JSON ではないことを示すエラーメッセージ

考えられる原因

考えられる原因の1つは、戻り値の中に二重引用符が含まれていることです。

考えられる解決策

JSON 文字列は二重引用符で区切られますが、ほとんどの場合、文字列自体は引用符で開始および終了できません。埋め込まれた二重引用符が正しくない場合は、削除してください。

症状:関数が間違った行数を受け取ることを示すエラーメッセージ

考えられる原因

リモートサービスが受信した行よりも多いか少ない行を返そうとした可能性があります。(関数は名目上スカラーではあるものの、「イベント」パラメーターの「本体」フィールドに複数の行を受け取る可能性があり、受け取ったのとまったく同じ数の行を返す必要あり。)

考えられる解決策

リモートサービスが、受信する行ごとに1行を返すことを確認します。

AWS

症状: SQL から関数を呼び出すと、行番号が故障しているというメッセージが表示

考えられる原因

返される行番号は、0から始まる単調な昇順の整数でなければならないことに注意してください。入力行番号もその規則に従う必要があり、各出力は対応する入力行と一致する必要があります。たとえば、出力行0の出力は、入力行0の入力に対応する必要があります。

考えられる解決策
  1. 返される行番号が受け取った行番号と同じであること、および各出力値が対応する入力の行番号を使用していることを確認してください。これで うまくいくはずです。解決できない場合は、入力行番号が正しくなかったか、行を正しい順序で返していない可能性があるため、以下のステップ2に進みます。

  2. 出力行番号が0から始まり、1ずつ増加し、順番に並んでいることを確認します。

症状:エンドポイントがLambdaプロキシ統合を使用しているときに、Amazon API Gatewayがエラー502を返す

考えられる原因

Lambda関数が、次の状態である可能性があります。

  • タイムアウト。

  • 例外をスロー。

  • 他の方法で失敗。

考えられる解決策

Lambdaまたは API Gatewayログが利用できる場合は、それらを調べます。

Lambda関数のソースコードが利用できる場合は、Lambda関数のコードを分析してデバッグします。場合によっては、そのコードのコピーをより簡単なコンテキスト(AWS の外)で実行してデバッグを支援できる可能性があります。

Lambda関数に送信されるデータが、Lambda関数が予期する形式であることを確認します。小さくて単純なデータセットを送信して、それが成功するかどうかを確認することをお勧めします。

一度に大量のデータを送信していないことを確認します。

特にLambda関数が多くの CPU リソースを必要とする時や、Lambda関数自体が他のリモートサービスを呼び出してより多くの時間を必要とする時には、タイムアウトを増やすと問題が解決する場合があります。

EXTERNAL_FUNCTIONS_HISTORY 関数

症状: EXTERNAL_FUNCTIONS_HISTORY が「...無効な識別子...」を返し

考えられる原因

関数の署名を一重引用符で囲まなかった可能性があります。たとえば、次の例は引用符が含まれていないため間違っています。

select *
  from table(information_schema.external_functions_history(
    function_signature => mydb.public.myfunction(integer, varchar)));
考えられる解決策

関数の署名を引用符で囲んで、これを修正します。

select *
  from table(information_schema.external_functions_history(
    function_signature => 'mydb.public.myfunction(integer, varchar)'));

症状: EXTERNAL_FUNCTIONS_HISTORY は出力の1行のみを返し、列の多くは NULL

考えられる原因

関数の署名が含まれていない可能性があります。関数の署名を指定しない場合、 EXTERNAL_FUNCTION_HISTORY() は、 INVOCATIONS、 SENT ROWS などの列に集計値を返し、関数名、引数リストなどの列に NULL を返します。

考えられる解決策

1つの関数の情報を取得する場合は、関数の署名を含めます。

すべての関数の情報を取得する場合は、一部の列の NULL 値が正しいため、クエリを修正する必要はありません。