「kintoneの性能」シリーズではkintoneの特性を知り、kintoneを快適に利用するための考慮事項と改善策を案内しています。

kintoneの性能は、「リクエストの処理時間」と「同時リクエスト数」の2つの要素に影響を受けるため、リクエストの処理時間を短くし同時リクエスト数も減らす構成が理想です。
Vol.1では、そのうちの1つ「リクエストの処理時間」を紹介しました。
kintone の性能 Vol.1  - リクエストの処理時間

本記事では、「同時リクエスト数」におけるkintone REST APIの同時リクエスト数に焦点を当て、APIのリクエスト数の制限とリクエスト数を減らすためのポイントを説明します。

「同時リクエスト数」は、ユーザーアクセスによるリクエスト数と、カスタマイズによるREST APIリクエスト数の合計です。
ユーザーアクセスによるリクエスト数は、アクセスするページやカスタマイズの状況によって変わりますが、kintoneを同時に利用する人数と読み替えてください。

性能への影響を抑えるために、カスタマイズによるREST APIリクエストには制限を設けています。

1つのドメインにつき100件まで同時実行が許可されており、101件目以降のリクエストはエラーになります。
制限値を超過した場合、原因となったアプリだけではなく、ドメイン全体でREST APIのリクエストがエラーとなるため、注意が必要です。
参考： kintone REST API 同時接続数の制限値はなぜあるのか

アクセスが始業/終業時など一定の時間に偏る場合、同時リクエスト数が増えます。
REST APIによるリクエストが大量に送信されるシステム・カスタマイズを構築されている場合も同様に同時リクエスト数が増えます。
同じアプリや同じレコードにリクエストが集中する場合は、特に注意が必要です。

同時リクエスト数を減らせるかどうかは要件や運用に依存します。
ここでは同時リクエスト数を減らすアイデアを紹介します。

お知らせのアプリは必要最低限にする

ポータルやスペースのお知らせにアプリを貼り付けている場合、アクセス時にアプリへのリクエストが発生します。
貼り付けるアプリ数が多い場合は、不要なものがないか検討します。

実行時間の見直し

業務時間中に実行する必要のない処理は業務時間外や夜間など、利用者の少ない時間帯に実行します。

中間処理結果の保存

大量データを集計、加工して表示するような場合は中間結果を別のkintoneアプリに保存します。
これによりREST APIによる総リクエスト数を減らせないか検討します。

差分処理

定期的に処理する場合は毎回全レコードを対象にするのではなく、前回実行分との差分のみを処理します。
たとえばレコード取得を「更新日時が前回の実行日時以降」という条件で実行します。

キャッシュ化

同じユーザーが何度もアクセスする場合はデータをセッションストレージなどに保存します。
2回目以降のアクセス時はセッションストレージのデータを参照します。

アクセス時にリクエストしない

画面表示時にREST APIを実行する場合はボタンクリックなどの操作を挟み、意識的にデータを見たい場合のみREST APIを実行します。

リクエストの処理時間を短くする

Vol.1で紹介した「リクエストの処理時間を短くするための改善策」を実施します。
リクエストの処理時間が短くなると同時リクエスト数の減少にもつながります。
kintoneの性能 Vol.1 - リクエストの処理時間

Vol.1とVol.2を通してkintoneの性能や考慮事項、改善策を案内しました。

Vol.1でもお伝えしたとおり、kintoneは数千ユーザーでの利用実績も増え、一般的な業務システムやコミュニケーション用途で性能問題が発生することはほとんどありません。
しかし、同時リクエスト数が多い場合やアプリの設定が複雑な場合はその限りではありません。

kintoneの特性を知り、適切に設計・実装することで、kintoneを快適に使いましょう！