ダッシュボードの標準化したレイアウト
吉澤巧氏（以下、吉澤）：ここまでで、ダッシュボードの使い方やその種類なんかはなんとなく伝わったのかなと思っています。一方で、良質なダッシュボードを設計するには、表現に一貫性を持たせることが大切であるとAmazonは考えています。
なぜなら、例えば新しいメンバーがそのチームに入ってきたという時に、ダッシュボードを素早く使いこなしてもらって、そのサービスの仕組みについて学習スピードを上げてほしいからです。
そのために、Amazonではダッシュボードのレイアウトについて、標準化したレイアウトを作成しています。標準化したレイアウト、つまりAmazonが培ってきたベストプラクティスがこの記事（The Amazon Builders' Libraryの「運用を可視化するためのダッシュボードの構築」）に紹介されており、今回はその一部について紹介できたらと思います。もし興味があれば原文、日本語訳もあるので、併せて確認してもらえると幸いです。
最重要なデータを一番上に配置する
まずは1つ目ですね。「最重要なデータを一番上に配置する」ということで、ダッシュボードはブラウザなどで読み込むケースが多いと思いますが、その時に、ダッシュボードのウィジェット、一つひとつのコンポーネントについては上から描画されていくことが多いと思います。
一方で、ユーザーははじめに出てきたものを大切と判断する傾向があります。だからこそ、上のほうに最重要なデータを持ってきます。このデータとレイテンシーや可用性、リクエスト数といった情報のすべてのAPIに関する情報について、これらを配置しています。
グラフのレイアウトは想定できる最小のディスプレイサイズに合わる
2つ目です。「グラフのレイアウトは想定できる最小のディスプレイサイズに合わせます」ということで、こちらは日本語の原文と少し変更したのですが、要はこのチームのメンバーの中で一番小さいモニターを使う人にダッシュボードのサイズを合わせましょうというお話です。
この小さいディスプレイの人に合わせることで何がうれしいのか。それは、横スクロールが不要になることが挙げられています。なぜ横スクロールをなくしたいのか。少し想像してみてほしいのですが、もし朝3時にアラートが鳴ってたたき起こされたという時に、このダッシュボードの横スクロールに気付けますか。恐らくほとんどの社員が気付けなかったという経験から、このようなベストプラクティスが策定されたんじゃないかなと思っています。
アラートを設定する際は、グラフに閾値を表示する
3つ目ですね。「アラートを設定する際は、グラフに閾値を表示する」というもので、例えば「レイテンシーがこの値を超えたらまずいというアラートを設定している場合は、その閾値を水平線でグラフで表示してあげましょう」というものです。
ただ、この静的な閾値を設定できないという場合は、よくマシンラーニングを使った異常検知を使っている場合も多いと思います。ML（Amazon ML）の検知を使う場合も同様で、可能な限りグラフに数字、測定したメトリクスに合わせて正常範囲を合わせてプロットしてあげることが推奨されています。
幸いにもAWSが提供するモニタリングツール、Amazon CloudWatchにはMLを使った異常検知機能と、正常範囲を描画するような機能が備わっています。
メトリクスやウィジェットの真の意味をユーザーが理解していることを前提にしない
4つ目ですね。「各メトリクス、もしくはウィジェットの真の意味をユーザーが理解していることを前提にしない」と。ちょっと仰々しい格好いい文章かなと思っていますが、こちらを一言でまとめると、グラフの横や下に説明文を追加しましょうというものになっています。
このようなテキストを読むことによって、オペレーターはメトリクスの意味を理解できます。それによって運用メンバーは正常な状態がどのように見えるのか、そしてグラフが正常じゃない場合はどのような意味を持つのかを解釈できるようになります。
これによって、誰がこのダッシュボードを見たとしても同じような解釈をすることが可能になります。また、この状態の説明に加えて複数のリンクですね。例えば詳細検証を行う際のダッシュボードのリンク、もしくは復旧を行うための手順書のリンク、もしくはデプロイをロールバックするためのデプロイパイプラインへのリンクなどが併せて用意されています。
システムの特性に応じて、状況に応じた複数のウィジェットを用意する
5つ目ですね。「システムの特性に応じて、状況に応じた複数のウィジェットを用意する」ということで、こちらは少し難しいので今回この発表で補足できたらなと思っています。
（スライドを示して）具体例をベースに話していくのが一番わかりやすいかなと思っていますが、例えばこの画像を見ると、API全体の可用性を表示するだけではなくて、Get、Put、それぞれについて可用性のウィジェットを追加しています。
このようにシステムの特徴に応じて状況を場合分けしてあげて、ウィジェットをそれぞれの場合ごとに用意してあげることによって、なにかあった時、障害があった時に原因を切り出しやすくなります。
他の例としては、リクエストサイズごとに場合分けをしてあげたり、もしくは入力パラメーターごとにこの場合分けをしてあげるといった例が書かれていました。
ダッシュボードをアップデートしていくための2つのプロセス
最後に、ダッシュボードは作成した後も保守を続けていく必要があるというお話をしていきたいと思います。ダッシュボードを作ったはいいけれど、そのダッシュボードがいつの間にか時代遅れになってしまっていたということを避けるために行います。そのために、Amazonでは開発者が自分自身でこのダッシュボードをアップデートしていくプロセスが備わっています。
まず、デプロイしていくため、改善していくための実践方法がブログで2つ紹介されていました。1つ目が新しい機能をデプロイする前です。こちらは新機能をデプロイする際のコードレビューの時点で、「ダッシュボードになんらかの変更はありますか」といった質問をします。これによって基盤レベルで変更がデプロイされる前に、ダッシュボードに修正が走るような仕組み。これが開発プロセスに組み込まれています。
なので、デプロイをした後に「この機能が足りなかった」「このダッシュボードが足りなかった」「だから障害に気付けなかった」といった混乱を避けることが可能になります。
この実践方法には2つのポイントがあって、1つ目にステージング環境、テスト環境にも同様のダッシュボードを用意するということです。これによって、テスト環境でもダッシュボードを使った変更点の検証が可能になります。
また、同様のレイヤーと複数の環境に用意してあげるために、IaC、Infrastructure as Code、要はこのダッシュボードのレイアウトをコード、例えばJSONなどで定義してあげることを行なっています。これによって複数の環境に同じダッシュボードをデプロイすることが簡単になるほか、ダッシュボードのレイアウトをリポジトリ、バージョン管理システムで管理することが可能になります。
2つ目の実践方法です。これは障害が発生した後のふりかえり、デブリーフにおいてです。デブリーフというのは、もちろん個人を責めるために行うものではありません。将来似た障害を発生させないために行うものです。経験から学んで、それをチームと共有するために行うものとなっています。
詳しくは同じくThe Amazon Builders' Libraryに「Amazon's approach to falling successfully」という動画があるので、こちらも併せて確認してください。
ここでもダッシュボードをふりかえっています。具体的には3つの質問ですね。ダッシュボードはお客さまへの影響を明確にしたのか、障害原因を明確にしたのか、修復時間を短くしたのかといった質問をしています。
デブリーフにおいて、この3つの質問に1つでもノーとなった場合は、このダッシュボードを改善する。みんなでダッシュボードを変えていくようなアクションを実施します。この2つのプロセスのように、Amazonではダッシュボードを常に改善するようなプロセスが備わっています。
Amazonではアラートと複数のダッシュボードで監視をしている
ということで、本日のまとめに移りたいと思います。Amazonでは24時間液晶を見ているような属人的な監視をしているわけではなく、アラートを活用しています。そしてアラートが鳴った際は利用者・目的に応じた複数枚のダッシュボードを使い分けるような運用をしています。
また、Amazonでは誰でも見てわかるように、標準化されたダッシュボードのレイアウトというものを用意していて、そのベストプラクティスとしてこのような記事で公開しています。
また、ダッシュボードは一度作ったら終わりではなくて、常に開発者が自分自身で改良していくようなプロセスをAmazonでは用意しています。
ということで、本日の発表は以上になります。ご清聴ありがとうございました。
