パターン実践ガイド

性能上の考慮点と改善策

はじめに

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

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

(※この記事は2021年11月1日時点のkintoneをもとに執筆しています。)

想定読者

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

内容

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

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

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

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

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

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

①データ量

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

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

    参考:kintoneでは、絞り込みやアクセス権の設定を行っていない1つのアプリに、100万件を登録した状態で快適に使用できることを確認しています。 https://jp.cybozu.help/k/ja/admin/limitation/limit.html

  • フィールド数が数百件になる場合
    フィールド数が多ければ、その分1レコードに蓄積するデータ量は増えます。
    1アプリの最大フィールド数は500ですが、100を超えてくるとレコード一覧/詳細画面の表示などに遅延が生じる可能性があります。

  • 保存データの文字数が多くなる場合
    文字数の多いデータを格納することはもちろんですが、注意が必要な点はサブテーブルとリッチエディターです。

    • サブテーブル
      サブテーブルは5,000行まで増やすことができ、数が決まっていないデータを保管する際に便利ですが、その分1レコードのデータ量が大きくなるので、アプリの処理に影響を及ぼしやすいです。
      中でも、絞り込みでサブテーブル内フィールドを条件に指定している場合は、各レコードの全ての行を判定するので、絞り込み結果が出るまで時間がかかりやすく注意が必要です。

    • リッチエディター
      リッチエディターは保存データをHTMLとして保存しますので、他のフィールドに比べてデータ量が大きくなりやすい傾向にあります。
      リッチエディターに添付ファイルフィールドのサムネイル画像をコピー&ペーストで保存すると、 非常に多いデータ量にもなるので注意が必要です。

②複雑度

①の総データ量に掛け合わせる形で、次の条件の複雑度が性能に影響を及ぼす要因の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で大量データや複雑な処理を行う場合でも性能上のリスクを回避しつつ、安全で使いやすいシステムが構築できます。

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

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

  • 保管対象データの見直し
    そもそも、要らないデータを持ちすぎていないかという部分を再確認します。

  • アプリの設定変更による軽量化
    あわせて、アプリの設定変更による軽量化ができる部分がないかを確認します。

    • レコード詳細の設定変更

      • 利用頻度の低いフィールドはグループで閉じておく。
        参考:グループ化による画面表示速度の改善方法
        https://developer.cybozu.io/hc/ja/articles/360021729851
      • サブテーブルの行が長くなる場合は、子アプリを作って関連レコードでリレーションする方法も検討する。
    • レコード一覧の設定変更

      • レコード一覧画面に表示させるフィールドはできるだけ少なくしておく。
      • データ量の多いリッチエディターは一覧画面に出さないようにする。

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

  • アプリ分割
    主な分割方法として、以下の3つを紹介します。

    • 時系列で分割
      例:○○アプリ(2020年版)、○○アプリ(2019年版)、○○アプリ(2018年版)・・・など
      年ごと、もしくは複数年ごとにアプリを分ける。
      新しいレコードに、凡その利用が偏る際に有効。(過去データは気になったら調べる程度の利用)

    • 所属で分割
      例:○○アプリ(東京エリア)、○○アプリ(大阪エリア)、○○アプリ(第一営業部)、○○アプリ(第二営業部)・・・など
      利用者の所属でアプリを分ける。他所属のデータを参照する必要がない際に有効。
      所属の人数に偏りがある場合は、多い部分で影響が出ない様に注意が必要。

    • レコード件数で分割
      上記の様な括りではなく、単にレコード数が一定数を超えた場合にアプリを分割する。
      利用者に使わせるアプリを変えたくない場合、後述の自動アーカイブ機能が有効だ。

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

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

  • 絞り込み/ソート条件、アクセス権の見直し
    データ量同様に、絞り込み/ソート条件やアクセス権を不必要に厳重に掛けていないかという部分を再確認します。

  • アプリの設定変更による軽量化
    あわせて、アプリの設定変更による軽量化ができる部分がないかを確認します。

    • ソート条件
      最も判定に時間が掛からないソート条件はレコード番号なので、 指定がない場合はレコード番号の降順を設定
    • アクセス権
      アクセス権の軽量化には「最軽量のアクセス権」パターンを参照のもと、設定
      参考:最軽量のアクセス権
    • レコード一覧のデフォルト表示の変更
      複雑な条件のレコード一覧を扱う場合、レコード一覧のデフォルト表示は条件をシンプルにしておき、 複雑な条件のレコード一覧は切り替えて表示する運用にする

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

特定の時間にkintone REST APIの接続が集中する場合は、次の対処方法が有効です。

  • アクセスする度にAPIリクエストする仕組みを防ぐ
    ユーザーアクセスの際ではなく、意識的にデータが見たい場合にのみAPIがリクエストされる仕組みを設計しましょう。
    具体的には、ボタンを押下した際にデータが最新化される仕組みやページを幾つかのタブに分け、見たいタブを開いた際にAPIがコールされ、取得したデータを表示するような仕組みが理想です。
  • 定期処理化
    必ずしも最新のデータが表示される必要がない場合は、定期処理化により表示されるデータの更新頻度を下げることでAPIリクエスト数を抑制することが出来ます。

最後に、kintoneのパフォーマンス改善に関しては、次のページにもまとめが用意されています。こちらもあわせてご覧ください。
参考:パフォーマンス改善(cybozu developer network)
https://developer.cybozu.io/hc/ja/articles/360028520311

おわりに

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