Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マイクロサービス型システムの監視におけるダッシュボードUI設計に起因する状況認識への影響 / ...

Tomoka
March 08, 2022

マイクロサービス型システムの監視におけるダッシュボード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

Tomoka

March 08, 2022
Tweet

More Decks by Tomoka

Other Decks in Research

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 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).
  3. 時間変化する情報を素早く認識する必要がある • 地理的・時間的な状態変化が起こる - 地理的:コンポーネントの置かれる状況の変化、依存関係の変化 - 時間的:各コンポーネントに関する定量的な値の変化 - 例)別のマシン上で新たなコンポーネントが起動* 既存のコンポーネントとの間に新たな依存関係が生まれ(地理的変化)

    リクエスト数や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).
  4. Situation Awarenessや認知心理学の理論に着目し、 素早く情報を認識するためのUIの要件を検討 2022/3/8 8 提案ツールの詳細 | 検討過程 ⑦操作の複雑性を軽減 ⑧直接的な

    インタラクション ⑤情報変化の提示 ⑥情報の比較 ①グループ化・ フィルタリング ②一貫性 ③強調 ④重要情報の配置 認知的負荷を軽減した上で 依存関係の把握を支援する 時間変化する情報の把握を支援する 素早い認識を支援する
  5. • 「最初に目に入った/視線が向いた箇所」について - 提案ツールのUIでは、100%の人が負荷の高いコンポーネントを選択 - Weave ScopeのUIでは、50%の人が左上のロゴを選択 → 提案ツールのほうが、素早くシステムの状況認識が可能 •

    「障害が発生しているとして、画面上のどこから調べたいか」について - 提案ツールのUIでは、100%の人が負荷の高いコンポーネントを選択 - Weave ScopeのUIでは、25%の人が「わからない」を選択 → 提案ツールのほうが、障害箇所を示唆できている 2022/3/8 14 実験1の結果と考察 | 提案ツールとWeave ScopeのUIの比較
  6. • 目的: 提案ツールとGrafanaのUI設計に関する比較 - 提案ツールで表示する時系列データ(折れ線グラフ)や枠線の色の判断基準を変更 CPU使用率とメモリ使用量→アクセス数とCPU使用率 • 被験者: 実務経験を有する監視エンジニア1名 -

    障害対応で用いる監視対象アプリケーションを把握済み • 形式: オンライン(Zoom経由)での観察と アンケート/インタビューの併用 2022/3/8 15 実験2 | 障害対応シミュレーション実験
  7. 2022/3/8 16 実験環境 | 監視テストベッドの構築 Masterノード Workerノード1 Workerノード2 Workerノード3 Kubernetesクラスタ

    監視対象のデモアプリ(Sock Shop) 被験者 監視ツール • Grafana • 提案ツール 操作/評価 監視情報取得ツール • Prometheus • Weave Scope 負荷生成ツール • Locust 監視情報 アクセス(負荷生成) 監視
  8. 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で画面共有しながら監視ツールを操作 • 監視ツール操作時に、視線移動に合わせてマウスカーソルを移動させる • 監視ツール操作時に、考えていることをできるだけ口に出す(独り言)
  9. 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) ② ④ ① ③ ⑤ ⑥ 手順② 提案ツールを操作 • 提案ツールでは、障害注入のタイミングから一定時間分のデータを再現 • 合図したタイミングで障害注入が始まった想定、操作開始 • 障害の根本原因が特定できた時点で操作終了
  10. 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段階) • その他自由記述、インタビューによる聞き込み
  11. 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では実際の監視情報を表示 • 障害注入のタイミングで合図をし、操作開始 • 根本原因が特定できた時点で操作終了、アンケート/インタビュー
  12. 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) ② ④ ① ③ ⑤ ⑥ 手順⑥ 事後アンケート/インタビュー • 障害の根本原因を探しやすいと感じたのはどちらか • 全体を通して意見や感想
  13. • 提案ツール、Grafanaの両方で障害注入されたサービスを特定できた → 障害の根本原因を推測することは可能 • System Usability Scaleにそって計算したユーザビリティのスコアが 提案ツールでは30点、Grafanaでは40点(100点満点中) →

    どちらも十分に使いやすいとはいえない • 「障害の根本原因を探しやすいのはどちらか」について Grafanaのほうが良いと判断された → ユーザビリティスコアがそのまま反映されている • それぞれのツールで異なる長所や問題点が存在 2022/3/8 18 実験2の結果と考察 | 概要
  14. • 一度に画面に表示できるグラフ数が少ないため、 障害の根本原因を探すためには上下移動の操作が多くなる - 全体を俯瞰的に見る手段やグラフ同士を比較する手段がないため、 詳細情報を順に見ていく必要がある • 重要なサービスに関するグラフは上部に表示することで、 迅速にシステムの変化を認識することができた →

    要件4*に沿って、重要なコンポーネントのグラフほど画面上部に 配置しつつ、上下移動を減らすための工夫が必要 2022/3/8 19 実験2の結果と考察 | Grafanaでの障害調査について *要件4:ダッシュボード上の強調される位置である左上や中央に、重要度の高い情報が表示されている
  15. 提案ツールにもGrafanaのように 障害内容を把握する手がかりとなる時系列データを取り入れつつ、 時系列データの効果的な可視化方法を検討する必要がある • 提案ツール:全体を見渡した状態から変化が起きているコンポーネントに素早く 着目できる一方で、どのような変化が起きているかを確認する操作が煩雑である - 障害の根本原因である可能性があるコンポーネントを直感的に把握することができるが、 具体的な変化や障害内容が把握しにくい •

    Grafana:具体的に発生した変化を確認することは容易であるが、 変化が起きているコンポーネントに着目するまでの速度や根本原因特定までの速度は グラフの配置に影響される - 重要なコンポーネントを把握した上でグラフを構成すれば根本原因や障害内容を 把握しやすくなるが、事前知識がないと情報を探すために時間がかかる可能性がある 2022/3/8 25 実験2の結果と考察 | 2つのツールの比較
  16. 目的 マイクロサービス型システム内で発生した障害の 状況把握や発生要因の特定を支援する スコープ 監視ダッシュボードのUI設計が 障害の状況把握や発生要因の特定に与える影響の調査 実験1 • Weave Scopeよりも提案ツールのほうが素早くシステムの状況認識を開始できる

    • Weave Scopeよりも提案ツールのほうが障害箇所を示唆できている 実験2 • Grafanaも提案ツールもユーザビリティのスコアは低い • 提案ツールで障害の根本原因を絞り込む/どのような障害が発生したかを把握する ためには、時系列データの可視化方法を改善する必要がある 今後の 展望 • 他の監視ツールや他の被験者条件との比較 • 提案ツールと他の監視ツールの条件を揃え、障害対応にかかる時間の計測 2022/3/8 27 まとめ