gusuku Customine Job Runnerでは、ブラウザを利用した画面上では出来ないような、大量のレコードを更新するようなカスタマイズを作成することが可能です。


ただし、1つのジョブの実行時間が最大15分という制限や、そもそもシステム上のメモリに収まりきらないほど大量のレコードを処理しようとすると、メモリエラーになります。


メモリを使い切った場合、このようなエラーメッセージが記録されます。

ジョブは強制終了しました。メモリを使い切った可能性があります。 The job has crashed. Probably out of memory.

このようなケースでは、処理したいレコードを処理できるサイズに分けて処理するテクニックが必要になります。 こちらの記事では、「検索文字列を作成する」を例にこのテクニックをご紹介したいと思います。


※注記：大量レコードの操作はAPIリクエスト数も大量に消費しますのでご注意ください。


アプリ概要

ここでは例として、全国の住所データのようなアプリがあり、そのフィールドを一文字でも検索にヒットするようにするため、「検索用文字列を作成する」を利用するようなケースを考えてみます。

このサンプルでは、1つのアプリに15万レコード弱のレコードがあるとします。 例として、各レコードの市区町村を「検索用文字列を作成する」を使って検索用フィールドにセットしてみます。


カスタマイズの内容

カスタマイズの内容は以下のとおりです。今回はアクショングラフも掲載します。2-3-4番がループになっていることをご確認ください。

カスタマイズの流れは以下のようになります。

このようなループを作成することで、大量のレコードを一部ずつ処理していくことが可能です。 シンプルなカスタマイズですが、注目していただきたいポイントは以下の箇所になります。

  • アクション番号2のクエリは、必ず処理が終わったら最後は0件取得の結果にならなければいけない（こうならないと、無限ループになってしまいます）。
  • アクション番号2の条件が「いずれかのアクションの実行が完了した時」。ここでループの起点になり、入り口とループの終点を設定することになります。


処理速度はどのくらいが可能か？

作成したカスタマイズの内容や、kintoneレコードの中身、ネットワークの状況やkintoneの負荷などにもよるので一概にお話することが出来ません。テスト用のアプリとレコードを用意して、時間帯を変えて何度か計測してみるとよいかと思います。


参考までに弊社の環境でこちらのカスタマイズ計測したところ、15分のタイムアウトまでに約10万レコード前後程度は処理できていた模様です。


15分で収まりきらない場合どうするか

今回のケースですと、検索条件を単純に

検索用フィールド = ""

とし、「検索用文字列を作成する」でこのフィールドに結果をセットしていますので、タイムアウトしたとしてもそこまでの結果は保存されていますので、同じジョブを何度か実行すれば、いつかは全レコードの処理が終わることになります。


明示的に処理範囲を何回かに分けて実行したい場合は、この検索条件を必要な単位で分かれるように調整してください。


まとめ

以上で大量のレコードを安全に処理する方法のご紹介を終わります。


kintoneはあまり大量のレコード処理は得意ではないのですが、場合によってはこのような処理を行う必要があるかもしれません。そのようなケースでご活用ください。


Job Runnerもチャットサポートを承っておりますので、ご不明な点がございましたら、チャットサポートまでお気軽にお問い合わせください。