【ITニュース解説】バッチジョブの監視、諦めてない？New Relic APMで短命プロセスを捉える方法（Cloud Run編）

システムエンジニアが開発する情報システムには、ユーザーが直接操作する画面を持つアプリケーションだけでなく、システムの裏側で自動的に実行される「バッチ処理」と呼ばれるプログラム群が存在する。バッチ処理とは、例えば夜間に大量のデータを集計してレポートを作成したり、データベースのバックアップを取ったり、定時にシステムの状態をチェックしたりと、人間が直接操作しない時間帯や特定のタイミングでまとめて実行される処理のことである。これらの処理は、システムが円滑に動作するために不可欠であり、安定して正確に実行されることが求められる。

しかし、このバッチ処理、特に数秒から数分といった短時間で実行を終える「短命バッチ」の監視には特有の難しさがある。一般的なWebアプリケーションのように常時稼働し、継続的にユーザーからのリクエストを受け付けるサービスであれば、監視ツールを使って常にその性能やエラー状況を把握しやすい。ところが短命バッチは、処理が開始され、目的を達成するとすぐに終了してしまう。もしその短時間の間に何らかの問題が発生しても、バッチが終了してしまうと問題の痕跡が消えてしまい、何が起きたのか、どこで時間がかかったのかといった詳細な情報を後から追跡するのが非常に困難になるのだ。エラーが発生していても、誰もそのバッチのログをリアルタイムで見ていない限り、気づくのが遅れる可能性もある。これが、多くのシステム開発者が短命バッチの監視に頭を悩ませる大きな理由である。

ここで登場するのが、アプリケーションの性能監視を専門とする「New Relic APM（Application Performance Monitoring）」のようなツールである。New Relic APMは、通常、Webサービスなどの常時稼働するアプリケーションに組み込んで利用され、ユーザーからのリクエストがどのように処理され、データベースアクセスにどれくらいの時間がかかり、どの関数がボトルネックになっているかといった詳細な情報をリアルタイムで収集・分析する。これにより、アプリケーションのパフォーマンス低下やエラーの原因を素早く特定し、改善に役立てることができる。しかし、短命バッチのように起動から終了までが非常に短いプロセスに対して、New Relic APMをどのように適用すれば良いのだろうか。今回の記事では、その具体的なアプローチが紹介されている。

New Relic APMがアプリケーションの性能データを収集する際の基本的な概念に「トレース」と「スパン」がある。トレースとは、一つの処理（例えばWebリクエスト）が開始されてから完了するまでの一連の流れ全体を指す。このトレースの中には、データベースへの問い合わせや外部サービスへの連携、特定の関数呼び出しといった個々の操作が含まれており、これらが「スパン」と呼ばれる。通常、New Relic APMはWebリクエストの開始を自動的に検知し、そこからトレースを開始し、リクエストの終了までを自動で追跡してくれる。しかし、バッチ処理の場合、外部からのリクエストがないため、この自動的なトレース開始の仕組みが機能しない。

そこで重要なのは、New Relic APMに対して、バッチ処理の開始と終了を「手動で」明確に伝えることである。具体的には、バッチ処理のプログラム内でNew Relicが提供するAPIを利用し、「ここから新しいトランザクション（トレースのこと）を開始します」と宣言し、処理が完了したら「トランザクションを終了し、これまでの性能データをNew Relicに送信します」と明示的に指示する。これにより、短命バッチであっても、その実行時間、内部での処理ごとの所要時間、発生したエラーといった詳細なデータをNew Relicに収集させることが可能になる。

今回の記事では、GCP（Google Cloud Platform）の「Cloud Run」というサービスを例に挙げている。Cloud Runは、コンテナ化されたアプリケーションをサーバーレス環境で実行できるサービスであり、必要な時にだけ起動して処理を行い、終わればすぐに終了するというバッチ処理の実行形態に非常に適している。Cloud Run上でバッチ処理を行うアプリケーションをNew Relicで監視するには、アプリケーションコードにNew Relicのエージェント（監視用の小さなプログラム）を組み込み、バッチ処理の開始時にNew RelicのAPIでトランザクションを開始し、処理の終了時にそのトランザクションを明示的に終了させる設定を行う。特に注意が必要なのは、バッチ処理が終了する前に、New Relicエージェントが収集した性能データをNew Relicのサーバーに確実に送信し終えていることである。もしデータ送信が完了する前にバッチプロセスが終了してしまうと、せっかく集めたデータが失われてしまい、監視の目的が達成できなくなる。そのため、処理の最後にデータ送信が完了するまで待つ、といった工夫が必要になる場合もある。

このようにNew Relic APMを短命バッチ処理に適用することで、システムエンジニアは大きなメリットを得られる。まず、バッチ処理が期待通りに動作しているか、どのくらいの時間がかかっているかを可視化できるようになる。これにより、もしバッチの実行時間が予想以上に長くなったり、エラーが発生したりした場合でも、New Relicのダッシュボードを通じてその異常を早期に検知できる。さらに、New Relicが提供する詳細なトレース情報を見れば、バッチ処理のどのステップで時間がかかっているのか、どのようなエラーが発生したのかを具体的に特定できるため、問題の根本原因を突き止め、改善策を講じることが格段に容易になる。これは、システムの安定稼働を維持し、万一のトラブル発生時にも迅速な対応を可能にする上で極めて重要なことである。短命バッチの監視は一見難しい課題に思えるが、適切なツールと手法を用いることで、その実行状況を詳細に把握し、システム全体の信頼性を向上させることが可能なのだ。