パターン実践ガイド

性能上の考慮点と改善策

はじめに

Index

はじめに
- 想定読者
内容
- 1. 性能を考慮する上で重要な3つのポイント
- 2. 1を踏まえて設計時に検討すべきこと
おわりに
更新履歴
関連パターン

当ガイドは、「性能への気遣い」パターンとあわせてご利用ください。

この「性能への気遣い」パターンを使う場面において、参考にしていただけるkintoneの性能に関する情報を以下に記載します。
kintoneを使った業務システムの導入・設計時にご利用ください。

（※この記事は2022年10月1日時点のkintoneをもとに執筆しています。）

想定読者

IT部門・kintone開発者の方向け

内容

1. 性能を考慮する上で重要な3つのポイント

kintoneでそれなりの規模のシステムを構築する場合、性能面のリスクを考慮しておく必要があります。ここで「それなり」という言葉で表しているように、kintoneは利用者によって構成が大きく変わる為、明確な性能上限が設けられません。

一方で、kintoneの性能は以下3点の掛け合わせで考えられるため、これらの点に着目することが、性能に考慮した設計に繋がります。

①データ量　x　②複雑度　x　③アクセス数

この3点が、以下にあげた条件に該当する場合は、特に設計時に性能面を考慮することを推奨します。

※なお「①データ量　x　②複雑度　x　③アクセス数」とあるようにこれらは単体で考えるのではなく、複合的に影響し合った結果、性能上のリスクとなるという点に留意してください。

①データ量

まずデータ量として「レコード数」「フィールド数」に気をつけましょう。

レコード数が数十万~数百万件になる場合
レコード総数が多ければ、その分レコード一覧の取得やAPIの結果取得に時間がかかります。
利用者の快適さを考慮すると、レコード数は多くても100万レコードが目安となります。
絞り込み・ソート条件やアクセス権の複雑さによっては数万レコードでも性能に影響が出る場合もあります。

参考：kintoneでは、絞り込みやアクセス権の設定を行っていない1つのアプリに、100万件を登録した状態で快適に使用できることを確認しています。
https://jp.cybozu.help/k/ja/admin/limitation/limit.html
フィールド数が数百件になる場合
フィールド数が多ければ、その分1レコードに蓄積するデータ量は増えます。
1アプリの最大フィールド数は500ですが、100を超えるとレコード一覧/詳細画面の表示などに遅延が生じる可能性があります。

特に、以下に当てはまる場合は注意が必要です。
• テーブル、関連レコード一覧が多い
• テーブルのフィールド数や行数が多い

②複雑度

①の総データ量に掛け合わせる形で、次の条件の複雑度が性能に影響を及ぼす要因の1つとなります。

絞り込み・ソートの条件が複雑な場合
絞り込み・ソートの条件が複雑なほど、判定に時間がかかり処理は遅延します。

特に、以下に当てはまる場合は注意が必要です。
- 絞り込み条件で「いずれかの条件を満たす」を利用している
- 絞り込み条件で「次のキーワードを含む/含まない」を利用している
- 文字列（複数行）、リッチエディター、テーブルを条件に利用している
- ドロップダウンまたはラジオボタンをソート条件に利用している
アクセス権の設定条件が複雑な場合
レコード一覧/詳細画面の表示時にアクセス権判定も行われますので、その判定条件も複雑なほど判定に時間がかかり処理は遅延します。

特に、以下に当てはまる場合は注意が必要です。
- アクセス権の設定数が多い
- レコード/フィールドのアクセス権で、アクセス権の対象者に多数のユーザー・組織・グループを設定している
- レコード/フィールドのアクセス権で、アクセス権の対象者にレコード内のフィールド値を利用している

③アクセス数

①②に懸念がある場合、アクセス数に関してもあわせて確認しておきましょう。

ユーザーアクセスが集中する場合
アクセス数が始業/終業時など一定の時間にピンポイントに偏る利用方法の場合、アクセスが集中することでサイボウズが管理するkintoneのサーバー側へ負荷がかかり、処理が遅延する場合があります。特にそのアプリが上記のようにデータ量や複雑度が大きい場合は注意しましょう。
kintone REST API による同時接続が集中する場合
kintone REST APIでのアクセスもユーザーアクセスと同様に、集中すればサーバー側へ負荷がかかり、処理が遅延する場合があります。
例えば、ポータルをカスタマイズしてAPIで取得したデータを表示する設計の場合、注意が必要です。
ポータルは最も利用者が通りやすい動線なので、ユーザーアクセスの度にAPIがリクエストされる設計にすると、リクエスト数が必要以上に多くなります。あわせて、リクエストの条件（クエリ）が複雑であったり、データ量が多いアプリに対してリクエストを実行している場合などは尚更、性能への考慮が必要です。

特にAPI処理の場合、ループ処理や並列処理を頻繁に行うようなカスタマイズを行うと、アクセスが集中せずとも負荷がかかる場合もありますので、カスタマイズプログラムの設計時には、kintone REST APIは出来るだけコール数が少なくなるように設計してください。

参考：kintone REST APIの同時接続数上限は1つのドメインにつき100です。
https://jp.cybozu.help/k/ja/admin/limitation/limit.html

※これら3点は、冒頭「①データ量　x　②複雑度　x　③アクセス数」とあるように複合的に影響し合う特徴があります。

2. 1を踏まえて設計時に検討すべきこと

次に、1で扱った性能への影響を回避するために、設計時にどのような検討をすればよいのかについてご紹介します。
適切な設計・実装をすることで、kintoneで大量データや複雑な処理を行う場合でも性能上のリスクを回避しつつ、安全で使いやすいシステムが構築できます。

「①データ量」に問題が考えられる場合の改善策

まずはアプリ内で改善できる部分が無いか検討を進めましょう。

保管対象データの見直し
そもそも、不要なデータがないかという部分を再確認します。
不要なレコードを削除できないか、利用頻度の低いレコードをCSVに書き出して保管できないか検討してください。
アプリの設定変更による軽量化
あわせて、アプリの設定変更による軽量化ができる部分がないかを確認します。
- テーブルの行が長くなる場合は、子アプリを作って関連レコードでリレーションする方法を検討する。
- レコード一覧画面に表示させるフィールドはできるだけ少なくしておく。
- データ量の多いリッチエディターは一覧画面に出さないようにする。

次にこれらに限界がある場合、データ量を性能に影響が出ない程度に分ける必要があります。

アプリ分割
分割方法の案を3つ紹介します。
- 時系列で分割
  例：○○アプリ（2020年版）、○○アプリ（2019年版）、○○アプリ（2018年版）・・・など
  年ごと、もしくは複数年ごとにアプリを分ける。
  ※過去データは気になったら調べる程度の利用の場合に有効です。
- 所属で分割
  例：○○アプリ（東京エリア）、○○アプリ（大阪エリア）、○○アプリ（第一営業部）、○○アプリ（第二営業部）・・・など
  利用者の所属でアプリを分ける。
  ※他所属のデータを参照する必要がない場合に有効です。
- レコード件数で分割
  上記の様な括りではなく、単にレコード数が一定数を超えた場合にアプリを分割する。

ただしアプリ分割を行う場合、集計・分析をアプリごとに行う必要があったり、カスタマイズ開発をした際に同一の内容を複数のアプリに適用する必要があったりと、手間が増えるデメリットも認識しておきましょう。

「②複雑度」に問題が考えられる場合の改善策

絞り込み・ソート条件、アクセス権の見直し
データ量同様に、不要な絞り込み・ソート条件やアクセス権を掛けていないかという部分を再確認します。
アプリの設定変更による軽量化
あわせて、アプリの設定変更による軽量化ができる部分がないかを確認します。
- レコード一覧のデフォルト表示の変更
  複雑な条件のレコード一覧を扱う場合、レコード一覧のデフォルト表示は条件をシンプルにしておき、複雑な条件のレコード一覧は切り替えて表示する運用にする
- アクセス権
  アクセス権の軽量化には「最軽量のアクセス権」パターンを参照のもと、設定
  参考：最軽量のアクセス権
- ソート条件
  最も判定に時間が掛からないソート条件はレコード番号なので、指定がない場合はレコード番号の降順を設定参考：ソート条件に適用するフィールドの種類による処理時間の違い
  https://cybozu.dev/ja/kintone/tips/best-practices/sort-condition-time-differences/

「③アクセス数」に問題が考えられる場合の改善策

ユーザーアクセスが集中する場合
特定の時間にユーザーアクセスが集中する場合は、次の点で改善できる部分がないかを確認します。
- 「お知らせ」のアプリは必要最低限にする
  ポータルやスペースの「お知らせ」にアプリを貼り付けている場合、アクセス時にアプリへのリクエストが発生します。
  貼り付けるアプリ数が多い場合は不要なものがないか検討します。

kintone REST API による同時接続が集中する場合
特定の時間にkintone REST APIの接続が集中する場合は、次の点で改善できる部分がないかを確認します。
- アクセスする度にAPIリクエストする仕組みを防ぐ
  ユーザーアクセスの際ではなく、意識的にデータが見たい場合にのみAPIがリクエストされる仕組みを設計します。具体的には、ボタンを押下した際にデータが最新化される仕組みやページを幾つかのタブに分け、見たいタブを開いた際にAPIがコールされ、取得したデータを表示するような仕組みが理想です。
- 定期処理化
  必ずしも最新のデータが表示される必要がない場合は、定期処理化により表示されるデータの更新頻度を下げることでAPIリクエスト数を抑制することが出来ます。定期的に処理する場合は、実行時間の見直し（例：業務時間外や夜間など、利用者の少ない時間帯に実行する）や、差分処理（例：毎回全レコードを対象にするのではなく、前回実行分との差分のみを処理する）も検討します。
- 中間処理結果の保存
  大量データを集計、加工して表示するような場合は、中間結果を別のkintoneアプリに保存します。
  これによりkintone REST APIによる総リクエスト数を減らせないか検討します。
- キャッシュ化
  同じユーザーが何度もアクセスする場合は、データをセッションストレージなどに保存します。
  2回目以降のアクセス時はセッションストレージのデータを参照します。

おわりに

このように構成や設定に気をつけることでそれなりの規模のシステムでもリスクに備えつつ構築ができます。
利用者にスムーズにkintoneを使ってもらえるようスマートな設計を行いましょう。

cybozu developer networkでは本記事をエンジニア向けに編集・追記した記事が公開されています。エンジニア職の方はこちらもあわせてご覧ください。
参考：
kintoneの性能 Vol.1 - リクエスト処理時間
https://cybozu.dev/ja/kintone/tips/best-practices/performance-of-kintone-vol1/
kintoneの性能 Vol.2 - 同時リクエスト数
https://cybozu.dev/ja/kintone/tips/best-practices/performance-of-kintone-vol2/