カテゴリー内の他の記事

アクセス権の事前評価とアプリの更新時間について

フォローする

はじめに

kintoneはサービスの性質上、リアルタイムでアクセス権評価を行うとレコード取得の時間が遅くなってしまう、といった問題がありました。
そこでkintoneでは、レコード参照時に高速にアクセス権の評価ができるよう、事前に計算可能な部分を計算しています。

この「アクセス権の事前評価」により、kintoneの高速なレコードの参照を実現しているのですが、レコード件数やアクセス権の設定件数によっては「アプリの更新」が遅くなってしまう場合もあります。

本記事では、kintoneの「アクセス権の事前評価」の処理概要と、アプリの更新が遅くなる理由及びその緩和策について説明します。

アクセス権の事前評価とは

kintoneでは『アクセス権の設定 - kintoneヘルプ』にあるとおり、アプリ、レコード、フィールドに対しアクセス権の設定が可能です。
アクセス権設定はkintoneの重要な機能の一つですが、性能面への影響を最小限にするために内部では複雑な処理をしています。

kintoneにはレコードの検索や一括取得といったリクエストが大量にやってきます。
これらのリクエスト内でアクセス権評価をするのですが、ナイーブに実装すると処理が重くなりユーザー体験の悪化につながります。
これを防ぐために「アクセス権の事前評価」として、事前に計算可能な部分についてはアプリのレコードを保存する時に計算するようにしています。

「アクセス権の事前評価」の動作イメージは以下の図のとおりです(図はレコードアクセス権でのイメージ)。
レコードを保存(追加や編集)をする時に "アクセス権の設定されたレコード/フィールド" と "アクセス権の設定されたユーザー/組織/グループ" の組み合わせで決まるアクセス権を事前に計算してデータベースに保存します。

これにより "アクセス先のレコード/フィールド" と "ログインユーザーの情報" を元に事前評価結果を調べれば、即座にアクセス権の有無が分かるようになります。

アクセス権の事前評価のデメリット

上記のようにkintoneではアクセス権を事前に評価し、その結果をデータベースに保存しています。
そのため、レコード/フィールドのアクセス権を変更した場合、アクセス権の事前評価結果を再計算しなければいけません。
そして、レコード数やアクセス権の設定件数が多くなると、以下の問題が発生する場合があります。

  • 「アプリの更新」で時間がかかる
  • アクセス権の事前評価処理中にデータベースロックエラーとなる処理がある

アプリの更新で時間がかかる

通常なら事前評価結果の再計算もすぐに終わるのですが、レコード数やアクセス権の設定件数が多いと時間がかかってしまいます。
そのため、アプリによっては設定した内容がすぐに運用環境に反映できない場合もあります。
(過去の例では更新処理に一時間以上かかるケースもありました。)

なお、事前評価結果が再計算されるタイミングは以下3点です。

  1. アプリの設定画面でレコード/フィールドのアクセス権を変更し、「アプリの更新」を実行した場合
  2. kintone REST APIでテスト環境のレコード/フィールドのアクセス権を変更し、テスト環境の設定を運用環境に反映した場合
  3. kintone REST APIで運用環境のレコード/フィールドのアクセス権を変更した場合

アクセス件の事前評価処理で時間がかかっている場合、アプリの設定画面では以下のように表示されます。

もしこの表示がされた場合は、もうしばらくお待ちいただければと思います。

アクセス権の事前評価処理中にデータベースロックエラーとなる処理がある

アクセス権の事前評価結果を再計算している間は、データベースの書込み競合を防ぐために以下の処理ができなくなります。

  1. アクセス権の変更をしたアプリに対するレコードの追加・更新
  2. 同一ドメイン内の全てのアプリでのアプリの設定変更

この場合、処理を行なった画面で以下のようなデータベースロックエラーが表示されます。

データベースロックエラー自体はアクセス権の事前評価以外でも発生する可能性がありますが、過去の例ではアプリの更新がきっかけになっているケースが多いです。
こういった場合は、時間をおいてから処理をやり直していただければと思います。

測定

以下では、アプリの更新時間が実際にどの程度変わるのかを測定しました。

アプリのレコード数とアプリの更新時間の関係

以下のアプリ設定で、レコード数別にアプリの更新時間を計測しました。

  • アクセス権:レコード
    • アクセス権を設定したユーザー数(1レコードあたり):60ユーザー
  • レコード数:1000件、3000件、5000件

グラフのとおり、レコード数が増えるほどアプリの更新時間が増加します。

アクセス権を設定するフィールド数とアプリの更新時間の関係

以下のアプリ設定で、アクセス権を設定するフィールド数別にアプリの更新時間を計測しました。

  • アクセス権:フィールド
    • アクセス権を設定したユーザー数(1フィールドあたりの):60ユーザー
    • アクセス権を設定したフィールド数:1個、2個、3個
  • レコード数:3000件

グラフのとおり、アクセス権を設定するフィールドが増えるほどアプリの更新時間が増加します。

アクセス権を設定するユーザー(/組織/グループ)数とアプリの更新時間の関係

以下のアプリ設定で、アクセス権を設定されるユーザ数別にアプリの更新時間を計測しました。

  • アクセス権:フィールド
    • アクセス権を設定したユーザー数(1フィールドあたり):1~100ユーザー
    • アクセス権を設定したフィールド数:1個
  • レコード数:3000件

グラフのとおり、1アクセス権あたり設定されるユーザー数が増えるほどアプリの更新時間が増加します。
フィールドアクセス権だけでなく、レコードアクセス権でも同様の傾向となります。
また、ユーザーだけではなく組織やグループでも、1アクセス権あたりの設定数が増えるほどアプリの更新時間が増加しました。

これらの測定からわかるとおり、レコード/フィールドのアクセス権を設定した場合、レコード数やアクセス権の設定数が増えるほど、
アクセス権の事前評価処理の時間が増えて、アプリの更新時間が長くなる傾向にあります。

緩和策

上記でアクセス権の事前評価に関する問題について説明しましたが、この節ではその緩和策について説明します。

アクセス権の事前評価は、簡単に言うと "レコード数" × "アクセス権の設定数" × "アクセス権を持つユーザー/組織/グループの数" の分だけ実行されます。
そのため、次のような方法でこれらの数を減らすことができればアクセス権の事前評価処理の時間を短縮することができます。

  • アプリのレコード数を減らす(レコード数が多くなった場合はアプリを分割するのも手)
  • アクセス権の数を減らす(条件をまとめる、アクセス権の粒度を緩くする等)
  • アクセス権を持つユーザー/組織/グループの数を減らす(複数のユーザーを登録している場合、グループや組織にする)

またあくまで目安ですが、10万レコードを超えるデータを扱っている場合はアクセス権の設定変更に時間がかかることが想定されるので、夜間に行うことをおすすめします。

おわりに

今回の記事では、kintoneの「アクセス権の事前評価」について説明しました。
アクセス権の事前評価によりkintoneの高速なレコード参照を実現していますが、条件によってはアプリの更新が遅くなる場合があります。
もし「アプリの更新」に時間がかかり困っているということでしたら、本記事を参考に設定の見直しをご検討ください。

このTipsは、2019年3月版 kintoneで確認したものになります。

記事に関するフィードバック

直接的に記事と関連がないご質問はcybozu developer コミュニティをご活用ください。

ログインしてコメントを残してください。