Custom Scriptsの開発手順およびデバッグ

2021年6月7日

プログラム作成

pythonプログラムを実行するときにはpython xxxx.pyというように実行し、ファイルの先頭から順に実行されていきます。しかし、Custom ScriptではWorkflowファイルから関数を指定し、実行する形になりますのでプログラム実行のスタートポイントが異なることを意識する必要があります。そのため、以下のようにプログラムを記述しておくと便利になります。

1: os.system(f"{sys.executable} -m pip install --upgrade pip")
2: os.system(f"{sys.executable} -m pip install pytd")
    :
3: def func1(arg1, arg2):
4:    :
5:    :
6: if __name__=='__main__':
7:    func1('foo', 100)

上記の例ではworkflowから呼び出す関数func1の定義とそれを呼び出す部分である6,7行目を記述しています。これを記述することで、python xxxx.pyとした場合にfunc1を呼び出してくれます。つまり、ローカル実行時は1,2,6,7行目->3行目(func1)の実行となり、workflowによる実行の場合は6,7行目の実行がなくなり、3行目の関数部分からの実行となります(もちろん1,2行目は実行されますが)。

開発時にメインとなる部分は3〜5行目の関数部分となり、6行目以降はテストドライバです。上記のようにCustom Scriptの実行プロセスを意識しておきますと、自分のテストがどの部分の確認になっているかと把握しやすくなりますのでエラーが生じた際の切り分けが楽になりますので把握しておくとよいかと思います。

単体ローカル実行確認1(without docker)

プログラムを作成して、自身のローカル環境でpython xxxx.pyとしてまずは実行確認することになるかと思います。このローカル実行による動作確認とTreasure Data CDP環境でのCustom Script上での実行ではどの部分が一致しており、どの部分が一致していないのかをしっかりと認識しておくことが重要です。 pythonプログラム単体で実行した場合に確認できる部分は関数本体のみになります。(もちろんmain部分で呼び出した関数が他の関数を呼び出している場合はそちらも動作確認できます。)

実際の本番環境との違いはOS、ネットワークに依存している部分やworkflowからの呼び出し部分が異なります。また、pythonの実行環境も異なります。本番環境ではpythonの実行環境をpyオペレータを呼び出すたびに新規構築しますので環境は1度の実行で失われます。そのため、上記のサンプルコードの1,2行目のモジュールインストールは毎回実行されます。しかし、ローカルでの実行の場合は最初の1回目は動作することになりますが、一旦モジュールをアップデートすると2回目以降はローカルの環境は本番と異なり、リフレッシュされないことに注意が必要です。

まとめますと以下のようになります。

動作確認できる部分

関数本体

動作確認できない部分

pythonモジュールのインストール/アップデートに関する部分(最初の1回目は動作確認できます)
OS、ネットワークに依存している部分
workflowからの呼び出し部分

pythonプログラム単体でのローカル実行は非常に簡単にプログラムの動作確認ができるのですが、実際のCustom Script実行環境と異なる部分が大きいという点は注意する必要があります。

ローカル実行確認2(with docker and digdag)

自身のローカル環境にDigdagおよびdockerを入れることで、本番環境とほぼ同一の動作確認をすることが可能です。もちろん、dockerのイメージにTreasure DataのCustom Scriptで使用しているイメージを利用することが前提となります。この実行環境の本番環境との違いはネットワーク環境のみとなります。(インターネットのアクセスにproxyサーバが必要であるとか)

そのため、以下のポイントで動作確認が可能です。

動作確認できる部分

関数本体
pythonモジュールのインストール/アップデートに関する部分(最初の1回目は動作確認できます)
OSに依存している部分(pythonコード内)
workflowからの呼び出し部分

動作確認できない部分

ネットワークに依存している部分

ここまで確認しましたら、ほぼ本番環境と同じになりますので仮に本番環境で何らかのエラーが生じても、ネットワークの問題である可能性が高く、そちらを重点的に確認してみてください。ただし、pythonプログラム単体の実行確認と比べるとターンアラウンドが少々かかるのは事実ですので、プログラム単体の動作確認の後のWorkflowとの結合動作テストとして実施するのがよいかと思います。

最後にこちらを参考にTreasure Data CDP側にアップロードして、本番環境での実行確認をすることになります。Treasure Data CDP側へのアップロードおよび実行に関しましてはこちらのドキュメントをご参照ください。