継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

Amazon の監視ダッシュボードの取り組みを学べる『Building dashboards for operational visibility』を読んだ

タダです.

新しい「Amazon Builders’ Library」の記事として「Building dashboards for operational visibility(運用の可視化のためのダッシュボードの構築)」が追加されました.このページを読んで Amazon での監視ダッシュボード構築・運用の取り組みを学んでいきます.

aws.amazon.com

記事目次および著者

記事の目次としては以下の通りです

  1. Amazon でのダッシュボード
  2. ダッシュボードの種類
  3. ダッシュボードのデザイン
  4. ダッシュボードのメンテナンス

著者はJohn O’Shea さんです.CloudWatch および Amazon 内部の監視と監視サービスを担当されているようです.

Amazon での監視ダッシュボード構築・運用の取り組み

記事内では Amazon がどんな種類のダッシュボードを持っているか,どんな風にダッシュボードをデザインし,運用しているのかを知ることができます.簡単にまとめていきます.

どんな種類のダッシュボードを持っているか

Amazon ではクラウドサービスの状態を常に把握する課題に対処するためにダッシュボードを作っていて,ダッシュボードでは時系列でのメトリック,ログ,トレース情報,アラームデータを表示しています.ダッシュボードは普段のオペレーションの中だけでなく毎週の運用レビュー会議でも使われ,利害関係者と確認するほどに重要なツールです.

そんなダッシュボードは用途ごとに存在しており,記事内の画像を引用させていただいていますが,用途ごとに図解化されておりわかりやすいです.

  • 顧客向けダッシュボード
  • 顧客体験のダッシュボード
    • 最も使われており,サービス自体,AWS SDK メトリック,CloudWatch Synthetics Canary,自動修復システムのデータが表示される
    • サービス全体の正常性と目標の順守に関するメトリックを効率的に提示
  • システムレベルのダッシュボード
    • API の監視データが表示され3つのカテゴリに分類される
      • 入力関連の監視データ: キュー/ストリームから受信またはリクエストされたリクエストの数およびリクエストのバイトサイズのパーセンタイル,認証/承認の失敗数が含まれる
      • 処理関連の監視データ: マルチモーダルビジネスロジックパス/ブランチ実行カウント,バックエンドマイクロサービスリクエストカウント/失敗/レイテンシパーセンタイル,障害およびエラーログ出力,リクエストトレースデータが含まれる
      • 出力関連の監視データ: レスポンスタイプカウント(顧客によるエラー/障害応答の内訳付き),レスポンスサイズ、および最初の書き込み時間の書き込みバイトとレスポンスタイムの書き込みのパーセンタイルが含まれる
  • サービスインスタンスダッシュボード
  • サービス監査ダッシュボード
    • Availabity Zone やリージョンレベルでのサービスに関するインスタンス群の監視データが表示される
  • キャパシティプランニングおよびその予測ダッシュボード
    • キャパシティプランニングと予測のためのダッシュボード
  • 依存関係のダッシュボード
    • マイクロサービスの依存関係(プロキシやロードバランサー,データストア,キュー,およびストリーム)を見れる
    • セキュリティ証明書の有効期限やその他の依存関係の割り当ての使用状況など他の重要なメトリックを追跡するためにも使用できる
  • マイクロサービスのダッシュボード
  • インフラのダッシュボード
    • EC2,ECS,EKS,Lambda などのメトリックを表示

f:id:sadayoshi_tada:20200813145424p:plain ※Building dashboards for operational visibilityの記事内の画像より引用

どんなデザインをしているか

ダッシュボードを設計する時にはダッシュボードの利用者起点で設計します.データのレイアウト設計原則としてダッシュボードは上から下にレンダリングされ,ユーザーは最初にレンダリングされたグラフを最も重要であると解釈し,最も重要なデータをダッシュボードの上部に配置することを推奨しています*.他にも次のようなデザインの考慮点があります.

  • グラフの凡例が表示されているグラフデータを垂直方向または水平方向に圧迫しないようにする
  • グラフで検索クエリを使用している時はメトリックの結果が通常より大きく表示するようにする
  • GUI のスクロールバーに気づかない人もいるかもしれないので,最小表示解像度のグラフをレイアウトする
  • タイムゾーンUTCに設定して表示する
  • ダッシュボードにはデータの表示間隔とメトリックの期間を調整できるようにする
  • ダッシュボードに多くのデータピントを表示させない
  • 必要に応じて、アラームステータス、単純な数値、および/または時系列グラフウィジェットを使用

どう運用しているのか

ほとんどのシステムは時間の経過に伴うスケーリングに対応して進化を続けて行く一方で,ダッシュボード IaC プロセスに従ってダッシュボードを維持・管理しています.このプロセスによりダッシュボードがバージョン管理システムで維持され,開発者とオペレーターがサービスに使用するのと同じツールを使用して変更がダッシュボードにデプロイされます.

予期しないイベントの事後分析し,チームはダッシュボード(および自動アラーム)の改善によりイベントを先取りしたり,根本原因をより早く特定や平均復旧時間を短縮したりできるかどうかを確認します.その際に「ダッシュボードは顧客への影響を明確に示し,オペレーターが最終的な根本原因を特定し,復旧までの時間を測定するのを助けたか」と自問します.これらの質問に対する回答が「いいえ」の場合,事後分析でこれらのダッシュボードを調整します.

まとめ

Building dashboards for operational visibility」を読んでその学びをまとめました.Amazon ではダッシュボードの使い手が作業するシーンをイメージしてダッシュボードのデザインをしはじめ,使いやすくすることに努めているのはデータを可視化する時に大事な視点だなと感じます.また,運用していく中で振り返りをしていく時に自分たちが提供したダッシュボードが役に立ったかを自問し,改善するプロセスも継続的な改善上必要なことだと思いました.自分自身データのダッシュボードを作成・維持管理することはしたことはないものの関わった時の指標にして行きたいと感じました.監視ダッシュボードに関われている人やこれから関わっていく人,データの可視化に興味がある人は是非一読してみてはと思った内容でした.

関連記事

kdnakt.hatenablog.com

sadayoshi-tada.hatenablog.com

kdnakt.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com