kintone レコード操作の遅延を防ぐアクセス権設定

目次

はじめに

kintoneではアプリ、レコード、フィールドに対し アクセス権の設定 (External link) が可能です。
アクセス権設定は便利な機能ですが、性能面への影響を考慮して利用する必要があります。
性能についての詳細は、 kintone の性能 Vol.1 - リクエストの処理時間を確認してください。
本記事は、アクセス権設定が与える性能への影響をテーマに、次の2点を解説します。

  • 注意が必要なケース
  • 最適化方法
information

本記事は、アクセス権設定が与えるレコード操作への影響に焦点を当てた内容となります。
アクセス権設定による「アプリ更新」への影響については以下の記事に記載しているため、併せて確認してください。
アクセス権の事前評価とアプリの更新時間について

kintone のアクセス権評価のしくみ

kintoneには、アクセス権評価による性能への影響を減らすために、「アクセス権の事前評価」というしくみがあります。
これは、アクセス権の評価を「レコードの取得処理時」ではなく「レコードの保存処理時」に実行するしくみです。
レコード保存されたタイミングで、「レコード数 × アクセス権の設定数 × アクセス権をもつユーザー/組織/グループの数」のぶんだけアクセス権の事前評価が実行されます。 そして、計算結果が事前評価データとしてデータベースに保存されます。

このしくみにより、レコードの取得処理時は、事前評価データからアクセス権を調べるのみとなり、即座に結果を返すことができます。

詳しくは アクセス権の事前評価とアプリの更新時間についてを参照してください。

アクセス権設定に注意が必要なケース

アクセス権設定がもたらす影響と要因

アクセス権の事前評価は、計算のしくみ上「レコード数」や「アクセス権設定」などが増加すると、データベースに保存される事前評価データも増えます。
事前評価データが大量になると、「事前評価結果を調べる処理」に必要な時間が長くなり、レコード一覧表示の遅延につながる可能性があります。

また、以下のような条件下では、より大きな影響を受ける可能性があります。

  • レコード取得、更新処理のリクエストが集中する。
  • レコード一括取得、一括更新処理を行う。(CSVやkintone REST APIを利用)

具体例の紹介

ここからは、運用開始時には顕在化しにくいケースを中心に、次の内容について、具体例を交えて紹介します。

  • どのような場合にアクセス権評価の負荷が高くなるのか。
  • どのような影響を受けるのか。
ケース①:アクセス権設定 × レコード増加
具体例
  • 利用しているアプリ
    • 問い合わせ管理アプリ
  • アプリの運用状況
    • 40人のオペレーター × 20 ~ 30件/日の対応履歴を管理している。
    • 個人情報を登録するため、レコードやフィールドのアクセス権を細かく設定している。
    • 運用開始から5年経ち、レコード数が100万件に近付いた。
  • 発生した問題
    • 運用当初は問題なかったが、一覧画面表示が遅延するようになった。
解説

数ヵ月~数年運用することで、レコード数が数件から数十万件に増加していくようなケースです。
アクセス権を細かく設定した場合、運用開始当初は問題なくても、レコード増加によって問題が顕在化する可能性があります。
特に数ヵ月など短い期間でレコードが大量に増加する場合、性能への影響が一気に顕在化し、対応を急務とするリスクがあります。


ケース②:アクセス権の複雑化
具体例
  • 利用しているアプリ
    • 案件進捗アプリ
  • アプリの運用状況
    • 「組織A」が担当する注文情報を保存している。
    • 数年前から運用を開始しており、レコード数は数十万件となっている。
    • 新たに「組織B」は担当する注文情報も同アプリで管理することとなった。
    • 一般社員と管理職社員で担当外の注文情報へのアクセス権限が異なるため、レコードやフィールドのアクセス権を細かく設定し直した。
  • 発生した問題
    • 「組織B」の利用開始前と比較し、レコード表示が著しく遅延するようになった。
解説

アプリの利用範囲拡大に伴い、アクセス権設定が複雑化するケースです。
アプリを運用する中で対応業務範囲や、利用者の拡大を実施すると、合わせて権限の追加や変更を必要とする場合があります。
その結果、レコード数や設定内容によっては、レコード操作に影響することがあります。

例のように運用中のアプリに追加する形式で利用範囲を拡大する場合、既存利用者の運用に問題が生じ、対応を急務とするリスクがあります。


ケース③:アクセス権設定 × 一括操作 × アクセス集中
具体例
  • 利用しているアプリ
    • 案件進捗アプリ
  • アプリの運用状況
    • 約1000人でアプリを利用している。
    • 毎始業時に案件進捗アプリにて進捗や申し送り事項を確認する運用となっている。
    • レコード一覧にkintone REST APIを利用したプラグインを適用しており、一覧の表示に数秒程度必要としている。
    • この度案件の取り扱いルールが変更になり、レコードやフィールドのアクセス権設定を増やした。
  • 発生した問題
    • 一覧表示時のkintone REST APIの実行に必要な時間が、さらに数秒伸びるようになった。
    • これにより、アクセスが集中する始業時にkintone REST APIの処理が滞留し、同時接続数の制限値を超過しエラーが発生するようになった。
解説

アクセス権設定が複雑でなくても、kintone REST APIを利用した一括処理やアクセス集中などが重なると、大きな影響を受ける可能性があります。

アクセス権の最適化方法

前述したとおり、アクセス権の事前評価は「レコード数 × アクセス権の設定数 × アクセス権をもつユーザー/組織/グループの数」のぶんだけ実行され、結果がデータベースに保存されます。
そのため、計算の変数となる次を減らすことで、アクセス権評価の負荷を軽減できます。

  • レコード数
  • アクセス権の設定数
  • アクセス権をもつユーザー/組織/グループの数

アクセス権設定の基本的な考え方については、 最軽量のアクセス権設定 (External link) を参照してください。
ここでは、後者の2つ「アクセス権の設定数」が多い場合と「アクセス権をもつユーザー/組織/グループの数」が多い場合について、原因や最適化方法などを説明します。

「アクセス権の設定数」が多い場合

レコード/フィールドのアクセス権が多い場合には、スペース、アプリのアクセス権で代用できないか、そもそもアクセス権を削除できないか検討します。
次にいくつか具体例と対応案を記載します。

例①:全社共通アプリを利用していて、アクセス権で表示制御している
  • 状況
    • 全社で共通の「掲示/通知アプリ」を利用しており、所属部門や役職ごとに細かくアクセス権で表示範囲の制御をしている。
  • 対応策
    • 「【全社用】掲示/通知アプリ」「【部門別】掲示/通知アプリ」など、利用範囲別にアプリをそれぞれ作成して、アプリのアクセス権で公開範囲を制御する。
例②:特定のフィールドを特定の役職のみ編集可能としている
  • 状況
    • 「営業日報アプリ」のレコード編集画面で「上司コメント」フィールドに上司だけが編集できるようにアクセス権を設定している。
  • 対応策
    • ラベルやグループフィールドを利用して入力項目を明確にする。
    • 表示を制御するプラグイン/連携サービス/カスタマイズで、編集画面では「上司コメント」フィールドは上司がログインした場合のみ表示されるように制御する。
例③:項目数が多いため、必要な項目のみ表示されるようにしている
  • 状況
    • 「受注管理アプリ」を営業と経理が利用している。
    • 各部署が利用するフィールドを明確化するため、フィールドごとにアクセス権を設定している。
  • 対応策
    • ラベルやグループフィールドを利用して入力項目を明確にする。
    • タブ表示プラグイン/連携サービス/カスタマイズを利用して担当者ごとに表示を分ける。
    • 営業と経理で利用するアプリを分け、アクションや関連レコード一覧などで連携させる。

「アクセス権をもつユーザー/組織/グループの数」が多い場合

「アクセス権をもつユーザー/組織/グループの数」が多くなる原因として以下の設定が考えられます。

  • レコード/フィールドのアクセス権で、アクセス権の対象者に多数の「ユーザー/組織/グループ」を設定している。
  • レコード/フィールドのアクセス権で、アクセス権の対象者にレコード内のフィールド値を利用している。
レコード/フィールドのアクセス権で、アクセス権の対象者に多数の「ユーザー/組織/グループ」を設定している場合

この場合、アクセス権に指定する「ユーザー/組織/グループ」に不要な設定が含まれていないか確認してください。

たとえば、次の「変更前」の画像のように、特定のフィールドについて各部門のマネージャーだけ閲覧可能にしたい場合、ユーザー単位で設定していると「アクセス権をもつユーザー/組織/グループの数」は設定したユーザー分増えてしまいます。
そのため、複数のユーザーを登録している場合は、対象をグループや組織にまとめて設定できないか検討してください。

画像の例では、管理者のユーザーをまとめた「マネージャーグループ」を作成して、アクセス権設定には「マネージャーグループ」に指定します。

【変更前】マネージャーのユーザーが、ユーザー単位でアクセス権設定されている。

【変更後】マネージャーのユーザーを「管理職グループ」にまとめ、グループ単位でアクセス権を設定する。

フィールドのアクセス権で、アクセス権の対象者にレコード内のフィールド値を利用している場合

レコードとフィールドのアクセス権で利用可能な「フォームのフィールドを追加」機能は、利用者のレコードのフォーム入力内容で権限を動的に制御できます。

参照: ユーザー選択・組織選択フィールドを指定する (External link)

「レコードに指定されたユーザーのみ閲覧を許可する」などを実現できる便利な機能ですが、レコードの作成・編集時にアクセス権をもつ対象を追加できるため、レコードが増えるたびに「アクセス権をもつユーザー/組織/グループの数」が増加します。
そのため、アクセス権の設定自体は少なくても、レコードのフォームに指定された「ユーザー/組織/グループ」の数だけ権限の評価が必要となるため、むやみに設定数を増やさないよう注意が必要です。

【アクセス権設定画面】アクセス権設定自体はシンプルとなっている。

【レコード作成・編集画面】対象ユーザー・組織を追加できるため、追加した分実行回数が増える。

おわりに

本記事では、kintoneならではのアクセス権について、注意が必要なケースとアクセス権の最適化方法について説明しました。
アクセス権の評価対象が増えると、アプリ変更だけでなく、レコード表示・作成・削除や一括処理などのレコード操作も影響を受ける可能性があります。
本記事を参考に、性能を考慮したアクセス権設定設計を行い、kintoneを快適に利用いただけると幸いです。

information

このTipsは、2023年7月版kintoneで動作を確認しています。