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


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


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

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

このようなケースでは、処理したいレコードを処理できるサイズに分けて処理するテクニックが必要になります。


 こちらの記事では、やること「検索用文字列を作成する」を例にこのテクニックをご紹介したいと思います。

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


アプリ概要

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

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


カスタマイズの内容

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


カスタマイズ


アクショングラフ




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

このようなループを作成することで、大量のレコードを一部ずつ処理していくことが可能です。 


シンプルなカスタマイズですが、注目していただきたいポイントは次の箇所になります。

  • アクション番号2のクエリは、処理が終わった場合、最後のレコード取得件数は0件にならなければいけない。
    ※「レコード全行が準備できた時」はレコードの取得結果が0件の時は動かないため、取得結果が0件になるとループを抜ける動きになります（逆に0件にずっとならない場合は、無限ループになってしまいます）。

  • アクション番号2の条件が「いずれかのアクションの実行が完了した時」となります。ここでループの起点になり、入り口とループの終点を設定することになります。


どのぐらいの処理速度になるの？

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


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


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

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

検索用フィールド = ""

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


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


まとめ

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


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


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