マイクロサービス型システムの監視におけるダッシュボードUI設計に起因する状況認識への影響 / Impact of Dashboard UI Design on Cognitive Accuracy and Load in Monitoring Microservice-based Systems

第56回情報処理学会インターネットと運用技術研究会（ https://www.iot.ipsj.or.jp/meeting/56-program/#iot5 ）で発表した際のスライドです。

スライド番号19～22ページに動画を使用していますが、無くても最低限の内容は伝わると思い、そのままPDF化しています。動画を確認したい場合はOneDrive版の共有リンクをご確認ください。↓
https://1drv.ms/p/s!Aje55ITxOO5e1icmLPwVnML5YAU0?e=ob5QH5

Transcript

1. マイクロサービス型システムの監視における ダッシュボードUI設計に起因する状況認識への影響 Impact of Dashboard UI Design on Cognitive Accuracy and Load in Monitoring Microservice-based Systems 林 友佳*，松原 克弥*，鷲北 賢**，坪内 佑樹** * 公立はこだて未来大学 **さくらインターネット株式会社 2022年3月8日 第56回インターネットと運用技術研究会
2. • 複数の機能コンポーネントを組み合わせることでシステムを実現 • サービスの状態や利用可能な計算資源の状況などの変化に応じて、 コンポーネントの構成や配置などの稼働状況が部分ごとに動的に変化 2022/3/8 2 背景 | マイクロサービス型システムと動的な変化
3. 障害発生時の状態がわかりにくく対処に時間がかかる 動的変化が起こるマイクロサービス型システムの特徴が影響している 1. 依存関係がある 2. 状態が頻繁に変化する 2022/3/8 3 マイクロサービス型システムの課題
4. 障害の根本的な原因を 依存関係をもとに追求する必要がある • ユーザからのアクセスに対して、複数のコンポーネントが連携して処理 • 複数の要因の組み合わせにより障害が発生する傾向* - 大量のアラートが発生 → なにが障害の原因かわかりにくい 2022/3/8 4 特徴1 | 依存関係がある * Yuan, D., Luo, Y., Zhuang, X., et al.: Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems, Proc. 11th USENIX Symposium on OSDI ‘14, pp. 249-265 (2014).
5. 時間変化する情報を素早く認識する必要がある • 地理的・時間的な状態変化が起こる - 地理的：コンポーネントの置かれる状況の変化、依存関係の変化 - 時間的：各コンポーネントに関する定量的な値の変化 - 例）別のマシン上で新たなコンポーネントが起動* 既存のコンポーネントとの間に新たな依存関係が生まれ（地理的変化） リクエスト数やCPU使用率が変化する（時間的変化） → どのような変化が起きているのかわからないと 障害のきっかけや今後何が起こるのかがわかりにくい 2022/3/8 5 特徴2 | 状態が頻繁に変化 * Matsumoto, R., Kondo, U. and Kuribayashi, K.: FastContainer: A Homeostatic System Architecture High-Speed Adapting Execution Environment Changes, 2019 IEEE 43rd Annual Computer Software and Applications Conference (COMPSAC), IEEE Computer Society, pp. 270-275 (2019).
6. マイクロサービス型システム内で発生した障害の 状況把握や発生要因の特定を支援する 支援する内容 • システムのコンポーネントの依存関係を把握すること • システムの状態の時間的な変化を把握すること • 依存関係と時間変化する状態を素早く認識すること 2022/3/8 6 本研究の目的
7. 監視ダッシュボードのUI設計が 障害の状況把握や発生要因の特定に与える影響の調査 本研究で作成しているツール（提案ツール）と既存の監視ツールで それぞれ障害対応をシミュレーションする実験 2022/3/8 7 本発表のスコープとアプローチ 提案ツール Grafana Weave Scope
8. Situation Awarenessや認知心理学の理論に着目し、 素早く情報を認識するためのUIの要件を検討 2022/3/8 8 提案ツールの詳細 | 検討過程 ⑦操作の複雑性を軽減 ⑧直接的な インタラクション ⑤情報変化の提示 ⑥情報の比較 ①グループ化・ フィルタリング ②一貫性 ③強調 ④重要情報の配置 認知的負荷を軽減した上で 依存関係の把握を支援する 時間変化する情報の把握を支援する 素早い認識を支援する
9. 各コンポーネントの状態変化を 地理的・時間的に比較できるダッシュボードのUI設計 2022/3/8 9 提案ツールの詳細 | UI設計の特徴 地理的・時間的な 状態変化を同時に表示 視覚的示唆による 強調表現と 俯瞰的表示の両立
10. 2022/3/8 10 提案ツールのメイン画面（地理的な状態変化の可視化） 要件② 一貫性 要件① グループ化
11. 2022/3/8 10 提案ツールのメイン画面（地理的な状態変化の可視化） 依存関係 多 依存関係 少 リクエストの流れ 要件④ 重要情報の配置
12. 2022/3/8 10 提案ツールのメイン画面（地理的な状態変化の可視化） 要件⑦ 操作の複雑性を軽減
13. 2022/3/8 11 時間的な状態変化の可視化 要件⑤ 情報変化の提示 要件⑦ 操作の複雑性を軽減 要件⑧ 直接的なインタラクション 要件⑥ 情報の比較
14. 2022/3/8 12 視覚的示唆による強調表現 要件③ 強調表現 負荷 高 負荷 中 負荷 低 CPU使用率と メモリ使用率
15. • 目的：提案ツールとWeave ScopeのUI設計に関する比較 • 対象：システム監視ツールを使用したことのある 学生2名、企業のエンジニア6名 • 形式：提案ツールの画像やWeave Scopeのスクリーンショットを提示する アンケート形式 2022/3/8 13 実験1 | アンケートによる比較 Weave Scope 提案ツール
16. • 「最初に目に入った/視線が向いた箇所」について - 提案ツールのUIでは、100%の人が負荷の高いコンポーネントを選択 - Weave ScopeのUIでは、50%の人が左上のロゴを選択 → 提案ツールのほうが、素早くシステムの状況認識が可能 • 「障害が発生しているとして、画面上のどこから調べたいか」について - 提案ツールのUIでは、100%の人が負荷の高いコンポーネントを選択 - Weave ScopeのUIでは、25%の人が「わからない」を選択 → 提案ツールのほうが、障害箇所を示唆できている 2022/3/8 14 実験1の結果と考察 | 提案ツールとWeave ScopeのUIの比較
17. • 目的： 提案ツールとGrafanaのUI設計に関する比較 - 提案ツールで表示する時系列データ（折れ線グラフ）や枠線の色の判断基準を変更 CPU使用率とメモリ使用量→アクセス数とCPU使用率 • 被験者： 実務経験を有する監視エンジニア1名 - 障害対応で用いる監視対象アプリケーションを把握済み • 形式： オンライン（Zoom経由）での観察と アンケート/インタビューの併用 2022/3/8 15 実験2 | 障害対応シミュレーション実験
18. 2022/3/8 16 実験環境 | 監視テストベッドの構築 Masterノード Workerノード1 Workerノード2 Workerノード3 Kubernetesクラスタ 監視対象のデモアプリ（Sock Shop） 被験者 監視ツール • Grafana • 提案ツール 操作/評価 監視情報取得ツール • Prometheus • Weave Scope 負荷生成ツール • Locust 監視情報 アクセス（負荷生成） 監視
19. 2022/3/8 17 実験の流れ * Jordan, P. W., Thomas, B., Weerdmeester, B. A., McClelland, I. L. (Eds.): Usability evaluation in industry, pp.189-194, Taylor & Francis (1996) ② ④ ① ③ ⑤ ⑥ 手順① 教示事項などを伝える • Zoomで画面共有しながら監視ツールを操作 • 監視ツール操作時に、視線移動に合わせてマウスカーソルを移動させる • 監視ツール操作時に、考えていることをできるだけ口に出す（独り言）
20. 2022/3/8 17 実験の流れ * Jordan, P. W., Thomas, B., Weerdmeester, B. A., McClelland, I. L. (Eds.): Usability evaluation in industry, pp.189-194, Taylor & Francis (1996) ② ④ ① ③ ⑤ ⑥ 手順② 提案ツールを操作 • 提案ツールでは、障害注入のタイミングから一定時間分のデータを再現 • 合図したタイミングで障害注入が始まった想定、操作開始 • 障害の根本原因が特定できた時点で操作終了
21. 2022/3/8 17 実験の流れ * Jordan, P. W., Thomas, B., Weerdmeester, B. A., McClelland, I. L. (Eds.): Usability evaluation in industry, pp.189-194, Taylor & Francis (1996) ② ④ ① ③ ⑤ ⑥ 手順③ 操作したツールについてアンケート・インタビュー • 特定した障害の根本原因（障害注入をしたサービス） • System Usability Scale*に沿った質問（ツールの使いやすさについて10問/5段階） • その他自由記述、インタビューによる聞き込み
22. 2022/3/8 17 実験の流れ * Jordan, P. W., Thomas, B., Weerdmeester, B. A., McClelland, I. L. (Eds.): Usability evaluation in industry, pp.189-194, Taylor & Francis (1996) ② ④ ① ③ ⑤ ⑥ 手順④⑤ Grafanaについて同様に操作/アンケート/インタビュー • Grafanaでは実際の監視情報を表示 • 障害注入のタイミングで合図をし、操作開始 • 根本原因が特定できた時点で操作終了、アンケート/インタビュー
23. 2022/3/8 17 実験の流れ * Jordan, P. W., Thomas, B., Weerdmeester, B. A., McClelland, I. L. (Eds.): Usability evaluation in industry, pp.189-194, Taylor & Francis (1996) ② ④ ① ③ ⑤ ⑥ 手順⑥ 事後アンケート/インタビュー • 障害の根本原因を探しやすいと感じたのはどちらか • 全体を通して意見や感想
24. • 提案ツール、Grafanaの両方で障害注入されたサービスを特定できた → 障害の根本原因を推測することは可能 • System Usability Scaleにそって計算したユーザビリティのスコアが 提案ツールでは30点、Grafanaでは40点（100点満点中） → どちらも十分に使いやすいとはいえない • 「障害の根本原因を探しやすいのはどちらか」について Grafanaのほうが良いと判断された → ユーザビリティスコアがそのまま反映されている • それぞれのツールで異なる長所や問題点が存在 2022/3/8 18 実験2の結果と考察 | 概要
25. • 一度に画面に表示できるグラフ数が少ないため、 障害の根本原因を探すためには上下移動の操作が多くなる - 全体を俯瞰的に見る手段やグラフ同士を比較する手段がないため、 詳細情報を順に見ていく必要がある • 重要なサービスに関するグラフは上部に表示することで、 迅速にシステムの変化を認識することができた → 要件4*に沿って、重要なコンポーネントのグラフほど画面上部に 配置しつつ、上下移動を減らすための工夫が必要 2022/3/8 19 実験2の結果と考察 | Grafanaでの障害調査について *要件4：ダッシュボード上の強調される位置である左上や中央に、重要度の高い情報が表示されている
26. コンポーネントの枠線の色が緑色から黄色に変化することで、 システムの状態が悪化していることを迅速に認識できた → 要件3*に則った強調が効果的に働いている 2022/3/8 20 実験2の結果と考察 | 提案ツールでの障害調査について *要件3：強調したい要素は、他の要素とは異なる色、形、動きなどをつけることで他の要素と区別
27. 画面を大きく移動させることなくグラフの比較が可能であるものの、 グラフを重ねる機能に気づくことができない - 監視ツールでは、グラフ同士はダッシュボード上で縦や横に並べるもの - 一般的なツールで、このような操作を体験したことがない → 操作方法の説明が必要 2022/3/8 21 実験2の結果と考察 | 提案ツールの操作方法について
28. 複数の項目があるグラフから、特定の項目のみを表示する操作が 面倒に感じられる - 複数コンポーネントの監視メトリクスが1つのグラフに集約されている際、 特定のコンポーネントの情報を抜き出すためには、 グラフ下のテーブルからコンポーネント名を探し、クリックする必要がある → コンポーネントとグラフの項目を より直感的に結びつける工夫が必要 2022/3/8 22 実験2の結果と考察 | Grafanaの操作方法について
29. コンポーネントとグラフの関連性は直感的にわかるものの、 グラフを表示した後に閉じる操作がわかりにくい/やりにくい - 提案ツールでは、コンポーネントを再度クリックすることでしか 閉じることができない → 一般的なウィンドウに合わせ、 閉じるためのボタンがあるUI設計にする 2022/3/8 23 実験2の結果と考察 | 提案ツールの操作方法について × モーダルウィンドウ Yes ポップアップウィンドウ No 一般的なウィンドウ
30. 依存関係を表す線の太さを、通信量に合わせて変動させると より認識しやすいのではないか → 提案ツールの特徴である「視覚的示唆による強調表現」を 依存関係にも適用する 2022/3/8 24 実験2の結果と考察 | 提案ツールの可視化方法について
31. 提案ツールにもGrafanaのように 障害内容を把握する手がかりとなる時系列データを取り入れつつ、 時系列データの効果的な可視化方法を検討する必要がある • 提案ツール：全体を見渡した状態から変化が起きているコンポーネントに素早く 着目できる一方で、どのような変化が起きているかを確認する操作が煩雑である - 障害の根本原因である可能性があるコンポーネントを直感的に把握することができるが、 具体的な変化や障害内容が把握しにくい • Grafana：具体的に発生した変化を確認することは容易であるが、 変化が起きているコンポーネントに着目するまでの速度や根本原因特定までの速度は グラフの配置に影響される - 重要なコンポーネントを把握した上でグラフを構成すれば根本原因や障害内容を 把握しやすくなるが、事前知識がないと情報を探すために時間がかかる可能性がある 2022/3/8 25 実験2の結果と考察 | 2つのツールの比較
32. UI設計と障害対応時の状況認識方法の関連性について調査を深める • 他の既存の監視ツールでは 障害対応の流れ/操作にどのような特徴があるか • 被験者の監視業務経験年数などによってどのような違いがあるか • 提案手法のツールと既存の監視ツールで条件をより統一し、 障害対応の時間などの差を計測する 2022/3/8 26 今後の展望
33. 目的 マイクロサービス型システム内で発生した障害の 状況把握や発生要因の特定を支援する スコープ 監視ダッシュボードのUI設計が 障害の状況把握や発生要因の特定に与える影響の調査 実験1 • Weave Scopeよりも提案ツールのほうが素早くシステムの状況認識を開始できる • Weave Scopeよりも提案ツールのほうが障害箇所を示唆できている 実験2 • Grafanaも提案ツールもユーザビリティのスコアは低い • 提案ツールで障害の根本原因を絞り込む/どのような障害が発生したかを把握する ためには、時系列データの可視化方法を改善する必要がある 今後の 展望 • 他の監視ツールや他の被験者条件との比較 • 提案ツールと他の監視ツールの条件を揃え、障害対応にかかる時間の計測 2022/3/8 27 まとめ