紙のワークフローをDX化する際に行った 多階層データ処理の高速化について

ユーザーの利便性を考えた結果、データ構造が多階層・ツリー構造になってしまい、サーバー側での性能低下や、クライアント側での描画性能の低下に繋がったことは無いですか？

カミナシはユーザーが現場で使用する紙のチェックリスト（ワークフロー）をノーコードでDX化するサービスです。ワークフローの構成で「条件分岐」「繰り返し」などをロジカルに実現するためには多階層のノード・データを扱う必要があり、カミナシでは多段階テーブルからデータ取得する際の速度低下や、クライアント側の多段階描画による速度低下の問題を抱えていました。こちらの問題について、カミナシがどのような高速化を行ったかご紹介します。

Transcript

1. 紙のワークフローをDX化する際に行った 多階層データ処理の高速化について 株式会社カミナシ アプリケーションエンジニア 　　　 　　　　浦岡 祥平
2. サービス 現場改善プラットフォーム カミナシ 『カミナシ』は、現場のルーティンワークや事務作業を自動化 する現場管理アプリです。 手書き情報のデータから集計、報告など、これまで紙やエクセルで行ってい た作業をデジタル化し、 食品、小売、製造などのあらゆる現場のノンデスクワーカーの 働き方をスマートにしています。
3. 1.製造現場のDXとは？ 2.製造現場を変えるための、カミナシのアプローチ 3. 外的/内的の制約 4.開発エピソード 　（帳票の記録部分で速度低下に対して、解決に至ったまでのストーリー ） まとめ 本日、話すこと
4. 1.製造現場のDXとは
5. 出典：経済産業省　「IT システム「2025 年の崖」の克服と DX の本格的な展開」 https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf 　そもそもDXって何？
6. ✨ ✨ ✨ 　では、「製造現場のDX」って何をイメージしますか？
7. まだまだ紙が主役 　製造現場のリアルはどうなってる？
8. 　なぜ、自動化/高度化できない？ ・設備、人材への投資が必要 ・特に少量/多品種での製造では、自動化が難しい etc
9. 2.カミナシのアプローチ
10. ◯×チェック表 紙のチェックリスト（ワークフロー） カミナシでデジタル化 ノーコードで現場管理アプリを作ることができる 　業務フローをデジタル化する
11. 条件分岐 繰り返し 多様なデータ型 　ノーコードだけど、痒い所に手が届く
12. 繰り返し１ 繰り返し２ 繰り返し３ 親ノード 回答 YESの場合 Noの場合 木構造で表現 　内部のデータは木構造で定義している
13. ３.外的/内的の制約
14. カミナシのユーザーは、「ノンデスクワーカー」と呼ばれます 対デスクワーカー向けのサービスとは違う制約がある ・現場では、iPadだけ見ている訳ではない ・時には移動しながら記録（入力）する ライン① 　製造現場における制約 ライン② ライン③ 少なくとも、紙に書いていた時の体験に負けてはいけない！！
15. サービスリリース後の 半年で、 DB定義変更（alter ~）を実施した回数 回 サービス開始後も頻繁なデータ構造の変更を行う必要があった →キャッシュ戦略は一旦、採用を見送り、 　愚直にRDB一本で勝負した 　スタートアップとしての制約
16. ４.開発エピソード
17. （クライアント側） ②描画での性能低下 （サーバー側） ① RDBでの性能低下 RDB 　ぶち当たった課題 サーバー側、クライアント側のそれぞれで性能低下の課題あり
18. 　①RDBでの性能低下 ・多階層かつロジカルな構造のデータをRDBで管理するために、関連テーブルが増大した ・関連テーブルが増大したことによって、アプリケーション⇄RDB間の通信回数が増えた ・アプリケーション⇄RDB間の通信速度がボトルネックのため、性能低下に直結した RDB 木構造JSON table ①階層構造（親子関係）を表現するためのテーブル ②データの型ごとにテーブル 　（例えば、数値型と日付型はテーブル定義が異なる） 　　etc...
19. 　①RDBでの性能低下 ・多階層かつロジカルな構造のデータをRDBで管理するために、関連テーブルが増大した ・関連テーブルが増大したことによって、アプリケーション⇄RDB間の通信回数が増えた ・アプリケーション⇄RDB間の通信速度がボトルネックのため、性能低下に直結した gtx. Preload("Rel-A"). Preload("Rel-B"). Preload("Rel-C"). Find(s.ctx, &mainTable).Error; ORMを使ったコード select ~~~ select ~~~ select ~~~ 実クエリ ① ORMで使用して実装を行う場合、 　 ORM側で大量にクエリを発行してしまう ②再帰処理内でDBアクセス処理を書いてしまい、 　大量にクエリ発行していた
20. ・多階層かつロジカルな構造のデータをRDBで管理するために、関連テーブルが増大した ・関連テーブルが増大したことによって、アプリケーション⇄RDB間の通信回数が増えた ・アプリケーション⇄RDB間の通信速度がボトルネックのため、性能低下に直結した 　①RDBでの性能低下 golangでのループ 処理のスピード 大量のDBクエリの 処理スピード 個々は数十ミリ秒のクエリーでも積み重なると。。
21. 　①対応 「アプリケーション側での最適化」と「DB側で行えるチューニング」の両軸で対応した アプリケーション側 ①クエリ発行処理と再帰処理のようなアプリ側の処理を分離 ②ORMの使用 -> 生クエリ（テーブル結合を行うような）に変更した 　→ボトルネックとなるDBクエリの発行回数を抑えることができた DB側 ③テーブル結合で使用される外部キーに対する index付与 　　→クリエ単体の性能を改善
22. 　①これからの課題 まだまだ小手先の対応しかできていない！ →ユーザー増加、機能拡張に耐えうる抜本的な改善が必要 機能拡張に伴い増える関連テーブル サービスの成長に伴い増えるユーザー数 課題
23. 　②クライアント描画での性能低下 ・ロジカルなUIを実現するために、UIコンポーネントでの状態監視の範囲が大きくなる ・状態監視の範囲が大きくなることで、UIコンポーネントの再レンダリングの回数が増えた ・クライアントにとって、レンダリングコストがボトルネックのため、性能低下に直結した Reducer （状態） component1の回答 component1 component2 component2の回答 UI ・例えば、条件分岐を実現する上で、 　component2はcomponent1の回答によって、再描画を行わないといけない 　　 =>他コンポーネントの回答の状態を監視する必要がありました 👀 👀 はい いいえ 原因の記入
24. 　②クライアント描画での性能低下 ・ロジカルなUIを実現するために、UIコンポーネントでの状態監視の範囲が大きくなる ・状態監視の範囲が大きくなることで、UIコンポーネントの再レンダリングの回数が増えた ・クライアントにとって、レンダリングコストがボトルネックのため、性能低下に直結した component1 component2 component3 Reducer （状態） ・・・ component 100個 component 3個 component1 component2 component100 Reducer （状態） ・・・ 再描画 再描画
25. 　②クライアント描画での性能低下 ・ロジカルなUIを実現するために、UIコンポーネントでの状態監視の範囲が大きくなる ・状態監視の範囲が大きくなることで、UIコンポーネントの再レンダリングの回数が増えた ・クライアントにとって、レンダリングコストがボトルネックのため、性能低下に直結した JSでの内部処理 画面レンダリングの処理
26. 　②対策 ①不要なレンダリング箇所の特定 why-did-you-render ②memo化でのレンダリングの抑止 参考： https://kaminashi-developer.hatenablog.jp/entry/2020/11/25/093000 何が起因で再 Rendering が 起こったのかを確認 const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]); コンポーネントが再レンダリングされるプロパティを必要最低限 にする
27. 　②これからの課題 ・開発スピード優先だったので、まだまだ壊れやすいアプリ 　→テストの強化含め、安定したアプリを提供したい ・と同時に、ユーザーの熱狂度合いを高めたい 課題
28. まとめ
29. ・製造業のDXでは人が主役 ・カミナシは、ノーコードで作成できる現場管理アプリにより、 　現場のDXを加速させようとしている ・その実現にはサーバー、クライアントそれぞれで継続的な改善が必要 　まとめ
30. EM/アプリエンジニア/SRE 積極採用中