結論

関数の run_on_startup 設定は True ではなく基本的に False にすること

Python TimerTrigger 例

@app.schedule(schedule="0 0 15 19 * *", arg_name="myTimer", run_on_startup=False, #ココ
              use_monitor=False) 
def timer_trigger_sample(myTimer: func.TimerRequest) -> None:
    # 以下略

調べたこと

実際に関数の run_on_startup 属性を True 設定にすると、指定した時間以外に実行されてしまったり、ローカル環境からのデプロイ時に動作してしまうなどの状況が見られました。

Microsoft 自体もドキュメントにて、run_on_startup 属性を True に設定することはしないよう以下のように注意喚起しています。

運用環境では、runOnStartup を true に設定しないでください。この設定を使用すると、まったく予期できないときにコードが実行されます。特定の運用環境の設定では、これらの追加の実行によって、従量課金プランでホストされるアプリのコストが大幅に高くなる可能性があります。たとえば、runOnStartup を有効にすると、ご利用の関数アプリがスケーリングされるたびに、トリガーが呼び出されます。 runOnStartup を運用環境で有効にする前に、ご利用の関数の運用環境での動作を十分に理解しておく必要があります。

例外的に、Azure Functions Core Tools を使ったローカル環境での開発時には、True 設定にすることで、func start コマンドによる Functions 環境立ち上げ時に実行されるなど、即時確認ができるため便利ですが、設定に注意が必要なポイントです。

なぜ書いたか

私は、作業環境として、VSCode の拡張に Azure Functions、WindowsPC に Azure Functions Core Tools を入れて、関数の実行テストが行えるような状況を構築していました。

func new コマンドにより、Pythonのタイマートリガーテンプレートを選択し、作成されたテンプレートが以下です。

Python TimerTrigger テンプレート例

@app.schedule(schedule="0 0 15 19 * *", arg_name="myTimer", run_on_startup=True,
              use_monitor=False) 
def timer_trigger_sample(myTimer: func.TimerRequest) -> None:
    if myTimer.past_due:
        logging.info('The timer is past due!')
    logging.info('Python timer trigger function executed')

見ていただくと、run_on_startup=Trueになっているのです。

これをrun_on_startup=Falseに直すことで、推奨されている設定になるわけですが、気づかずに大規模な処理をデプロイしてしまうと、予期せぬ実行により多額の請求に繋がる可能性もあります。

私の場合、従量課金ではなく検証に用意しているAppServiceプラン上で動作させていたため、影響はありませんでした。

デフォルトでFalseとなっているというのも目にしたので、環境によるのかもしれませんが、私の環境上ではこのようにテンプレートが出力されたため、どなたかの役に立てば幸いです。

ご参考