はじめに
kintoneのワイドコースは、大規模利用向けにアプリ数・スペース数・APIリクエスト数を拡張し、専用機能で円滑な運用を支援します。
本記事では、kintoneのエンタープライズ企業への導入支援で得られた性能カスタマイズオプションの事例を紹介します。
本事例では、性能カスタマイズオプションの導入により、システム負荷を約1/3まで減少させることができました。
目的
レコード一覧の表示の遅さや、利用ユーザーの増加に伴うシステム負荷の高まりといった課題を抱えるアプリの管理者、およびワイドコースの導入を検討している方に向けて、本記事と同様の性能課題を解決する際の判断材料の一助となることを目指しています。
Before:オプション導入前
概要
「設備管理」アプリの利用ユーザー数が増加したことにより、データベース処理時間が遅延し、結果としてシステム全体の負荷増大の要因となっていました。
「設備管理」アプリのレコード一覧へのアクセスは、分間最大90アクセスにもかかわらず、多くのリクエストが10秒以上かかり、長いリクエストで240秒を超えてしまう場合もありました。
レコード一覧の画面操作の成功/失敗のリクエスト数、平均/最大の応答時間(秒)およびイベント発生状況がグラフとして表示されています。
システムへの影響
「設備管理」アプリのレコード一覧の表示に時間がかかるだけでなく、データベース処理遅延の影響で、時間あたりのリクエスト並列処理数は3,000を超えていました。
その結果、システム全体の負荷増大の要因となっていました。
時間あたりのリクエストの並列処理数の平均値(応答時間の平均×リクエスト数/集計時間)がグラフとして表示されます。
負荷状況の値が高い場合は並列処理数も多く、システムに高い負荷をかけている可能性があります。
レコード一覧設定内容
「設備管理」アプリ起動時に表示されるデフォルトのレコード一覧において、設定されている絞り込み条件が複雑な内容となっていました。
「設備管理」アプリのデフォルトのレコード一覧に、「複数選択系フィールド」に分類される「組織」「ユーザー」を指定する絞り込みが設定されている状況でした。
複数選択系フィールドについて補足します。
- 「ユーザー」「組織」「グループ」選択フィールドを使った絞り込みは「複数選択系フィールド」に分類されます。
「複数選択系フィールド」を使った絞り込みでは、データベースで実行されるクエリが複雑になります。 - 「複数選択系フィールド」に該当するフィールドには、「ユーザー」「組織」「グループ」以外にも、「チェックボックス」「複数選択」があります。
After:オプション導入後
状況と対応内容
状況
性能ダッシュボードに表示される「性能改善のヒント」において、「ユーザー/グループ/組織選択を絞り込み条件に指定している」「レコード数が多い」の警告が表示されている状況でした。
対応内容
「設備管理」アプリのデフォルトのレコード一覧において、絞り込み条件などアプリの構成や使い方を大きく変更することなくボトルネックを解消することを目的としました。
そのため、性能カスタマイズオプションの中から、レコード一覧に関する3つの性能カスタマイズオプションを適用しました。
オプション導入結果
性能カスタマイズオプション適用後、レコード一覧表示の遅延が大幅に改善されました。
「設備管理」アプリのレコード一覧の平均応答時間は約7秒から約1秒に短縮され、システム全体の負荷も大幅に減少しました。
また、「設備管理」アプリのレコード一覧へのアクセスは、負荷状況が減少したことで、240秒を超えてしまうリクエスト数が大幅に減少しました。
性能課題:レコード一覧の複雑な絞り込みがシステム負荷を生む理由
kintoneアプリのレコード一覧に複雑な絞り込みを設定すると、データベースの処理に時間がかかります。
また、アクセス数が増えることで、データベースで同時に実行される処理も増加し、レコード一覧表示の遅延やシステムの高負荷につながります。
アプリのレコード一覧に設定された絞り込みが、1秒未満で処理が完了するような設定の場合、分間アクセス数が90でも問題はありません。
一方で、アプリのレコード一覧に設定した絞り込みの処理が10秒以上かかる場合は、同時実行される処理数が増加し、システムに大きな負荷を与える可能性があります。
分間90回アプリのレコード一覧へアクセスする場合、秒間では約1.5回のアクセスが発生している計算になります。
このとき、1回の処理時間が10秒の場合、同時実行数の目安は次のようになります。
1.5処理/秒×10秒=約15処理
つまり、常に約15個の処理が同時に実行されている状態になります。
時間軸で見ると、次のように処理が開始されます。
- 0秒:処理A開始
- 0.7秒後:処理B開始
- 1.4秒後:処理C開始
それぞれの処理は10秒間終了しないため、結果としてデータベースには約15個の処理が積み重なった状態になります。
処理の重なりによりデータベースの負荷が高まり、システム負荷増大の要因となります。
kintoneでは、信頼性と実績をもつリレーショナルデータベースを採用していますが、製品特性上、レコード件数が大規模になる場合には、レコード一覧の絞り込みなど事前の設計および運用面での配慮が重要となります。
kintoneの性能に関する詳細は、kintone SIGNPOSTの「性能上の考慮点と改善策」および、エンジニア向けに詳細な検証結果を公開している「パフォーマンス」シリーズも合わせて参照してください。
おわりに
エンタープライズ向けに提供している「ワイドコース」では、リクエスト数や応答時間などのメトリクスを可視化できるため、システムのボトルネックを把握できます。
また、性能カスタマイズオプションを適用することで、kintoneアプリのレコード削除やアプリ設定の見直しといった運用変更を行うことなく、既存の業務構成を維持したまま大幅なパフォーマンス改善を実現できる点が大きな特長です。
業務プロセスやデータ蓄積方針を変更せずに性能課題へ対応できるため、現場への影響を最小限に抑えながら、エンタープライズ規模の利用にも耐えうる安定した運用基盤を提供できました。
