吉澤氏の自己紹介
吉澤巧氏（以下、吉澤）：それでは「Amazonにおけるダッシュボードのベストプラクティス」というタイトルで、アマゾンウェブサービスジャパン、ソリューションアーキテクトの吉澤からお話しします。
まずは簡単に自己紹介です。私は2022年に新卒で入社した吉澤といいます。現在はソリューションアーキテクトというポジションで働いています。好きなAWSサービスはAWSリソースを節約する方法、これを教えてくれるTrusted Advisor。また、特技として学生時代に気象予報士（の資格）を取って、民間の気象会社で「明日のお天気は晴れですよ」といった仕事をしていた時もありました。
気象予報もダッシュボードも、大切なところは共通している
3つ目の発表でみなさんそろそろお疲れの頃かなと思いますので、本題に入る前に気分転換として気象予報士時代の少しお話をさせてください。
みなさんに少し想像してほしいのですが、朝起きて天気予報を見ているとします。ここで「気温18度」と言われました。さて、みなさんならどんな服を着て行きますか。
恐らく、案外思い浮かばないんじゃないかなと思っています。同様に、例えば「降水量が5ミリ」とか「風速が15メートル」とか聞いても、恐らく案外思い浮かばないんじゃないかなと思っています。
気象予報士としてしばしば考えているのが、ユーザーが本当に知りたい情報って、実はこういう「気温が何度」とかいうお話ではなくて、「どんな服を着て行けばよいのか」「傘を持って行くべきなのか」。もっと極端な話をすると、「避難したほうがよいのか」（こういった）よりユーザー目線の情報を私たちは求めているんじゃないかと思っていました。
一方で、これはITシステムでも同じことが言えませんか。例えばCPUの使用率、ディスクの使用量といったメトリクスの収集も大切です。ただ、システムがきちんと動作をしている、レスポンスタイムが正常である、ユーザーエクスペリエンスを損なっていないのかという観点の監視も大切であると考えています。
本題に戻して、ダッシュボードの話でも同様です。ユーザー目線の情報を含んだようなダッシュボード。インフラのメトリクスを表示したようなダッシュボード。目的に合わせて複数種類のダッシュボードを使いこなすべきというお話が、本日のポイントとなってきます。
本セッションのアジェンダ
ということで、今回はThe Amazon Builders' Libraryの中から「運用を可視化するためのダッシュボードの構築」という記事についてお話しします。（スライドを示して）こちらのQRコードにアクセスしてもらうと記事に飛ぶことができます。
AWSのサービスは、世界中に展開された31ヶ所のリージョンにおいて実行されています。（スライドを示して）これらの動作を確認するためのポイントとなるのが、このダッシュボードです。Amazonではダッシュボードをどのように活用して世界中に展開されたサービスの動作を確認しているのか。今日はそのノウハウをお話しできたらと思っています。
（スライドを示して）ということで、こちらが本日のアジェンダです。まずAmazonにおいてダッシュボードを活用する手法、Dashboardingについてお話ししていきます。その中でどんなダッシュボードを作っているのか、どのようなレイアウトで作っているのかといったお話をした後、最後にダッシュボードを作った後の保守・運用についてお話しできたらと思っています。
なぜAmazonはダッシュボードを重要視しているのか
まず、今回そもそもなぜダッシュボードについて取り上げているのかについて説明していきます。Amazonではこの6つの要素、サービスの設計やコーディング、構築やテスト、デプロイ、スケーリング、これらの要素と並んでダッシュボードが大切であると考えています。
これらの要素と同じぐらいダッシュボードが大切であると考えたことがある人は、恐らくそう多くないのかなと思っています。
じゃあどうしてAmazonはここまでダッシュボードを大切であると考えているのか。それは、どこで何が起こっているのか、システムの動作をリアルタイムで把握したいからです。
例えばあるシステムがあるとします。その中ではメトリクスなどのモニタリングやアラートをトリガーとした、トラフィックのシフトといった自動修復、また新しい機能の継続的デプロイメントなどを行なっています。
これらの要素が独立して動いていると、結局のところどこで何が起こっているのかわからないような状態になってしまって、なにか障害があった時に対処できない。いわゆるオブザーバビリティが低いような状態になってしまいます。
そこで出てくるのがこのDashboardingです。Dashboardingというのは、システムで行われる処理・現状をダッシュボードを使って確認できるようにすることだと言えます。
「ダッシュボードを使ってシステムを監視している」と聞くと、恐らくアニメやドラマかなにかの影響で、「なんとなくたくさんのモニターに囲まれた担当者がそれを24時間体制で交代で監視している」みたいな光景を想像される方が一定数いるのかなと思っています。
一方で、Amazonでは運用メンバーが常に張り付いてダッシュボードを見ているような運用はしていません。なぜなら、手動での運用は人為的なエラー、要はうっかりミスでうまくいかないということを知っているからです。
Amazonのダッシュボード活用のポイント2つ
じゃあAmazonはどのようにしてこのダッシュボードを活用しているのか。ポイントは2つあります。まず1つ目がアラートの作成です。常にダッシュボードを見ることができないからこそ、最も大事なデータを評価するアラートを作成しておいて、アラートが出た時には自動で修復するようなワークロードを走らせます。
このタイミングで運用メンバーに通知が行くのですが、このタイミングで活用されるのがダッシュボードです。アラートに関連するダッシュボードをあらかじめ作成しておいてすぐに開けるようにしておく状態が大切で、障害時にはダッシュボードを使って、クライアントへの影響や障害の根本原因を迅速に検証することが可能になります。
2つ目が、役割・用途に応じた複数枚のダッシュボードを用意しておくということです。先ほども少しお話ししましたが、障害というシチュエーションなら、運用メンバーは根本原因を特定するためのより詳細なダッシュボード、ビジネスの関係者にとってはミーティングなどで使ったり、もしくは対外的にこの障害を発表するための影響範囲をモニタリングするためのダッシュボードが必要となってきます。
高レベル・低レベルの2つのダッシュボード
じゃあ複数種類用意する必要のあるダッシュボードは、どのように考えて作る（のか、どのように）ダッシュボードを決めているのかというお話をしていきます。
「Amazonという会社は『地球上で最もお客さまを大切にする会社』という言葉を掲げている、顧客志向である」ということを聞いたことがあるかもしれません。ダッシュボードの作成にもこの顧客志向という考え方が活きていて、どのようなユーザーがどのような用途でこのダッシュボードを使うのかを考えてダッシュボードを作っていきます。
そのようにして作ったダッシュボードは大きく分けて2つ。高レベルなダッシュボード、そして低レベルなダッシュボードに分類されます。システムの全体像、具体的にはクライアント目線や管理人目線といった、比較的抽象度の高い内容の高レベルなダッシュボード。そして運用メンバーが使うような、特に機能にフォーカスしたような低レベルなダッシュボード。この2つが存在しています。
高レベルなダッシュボードの具体例
この高レベル・低レベルなダッシュボードについて、Amazonではどのようなものを必要としてどのようなものを作っているのか、より具体的に見ていきます。まずは高レベルなダッシュボードです。
1つ目はカスタマーエクスペリエンスダッシュボードということで、Amazonで最も重要かつ運用メンバーを含む多くの関係者、幅広いユーザーグループに使用されるダッシュボードとなっています。
全体的な健全性といった情報や外形監視、いわゆるSynthetic Monitoringやリアルユーザーモニタリング、RUM（Real User Monitoring）といったよりユーザー目線の情報ですね。こちらは最初の天気予報の例でもお話ししました。
これらの組み込んだダッシュボードを使うことによって、影響を受ける顧客の数、もしくはどのような顧客が影響を受けているのかといった、クライアント目線の質問に答えることが可能になります。
2つ目がシステムレベルでのダッシュボードということで、こちらは運用メンバーがシステムとその顧客向けエンドポイントの2つの動作を確認するためのダッシュボードです。
ここでは認証の失敗、もしくはリクエスト数といった入力関連の情報、バックエンドマイクロサービスへの成功率もしくはレイテンシーといった処理関連の情報、そして応答サイズ、応答時間といった出力関連の情報を表示しています。
この2つの高レベルのダッシュボードについては、情報が多すぎると、伝える必要のある重要なメッセージを妨げてしまう可能性があるという共通点があります。ですので、この2つのダッシュボードでは情報が増えすぎてしまうことを避けるようにしています。
低レベルなダッシュボードの具体例
次に、低レベルなダッシュボードの具体例です。1つ目はマイクロサービス固有のダッシュボードです。こちらはサービスの深い知識を必要とするような実装に特化した情報、例えばモニタリングデータ、エラーレートやレスポンスタイムといったものを表示して、サービスチームはこれらのダッシュボードを使って原因や異常を特定します。
2つ目がインフラストラクチャーのダッシュボードということで、AWSでいうところのAmazon EC2やECS、Lambda関数といった、コンピューティングリソースが生成するメトリクス。例えばCPU使用率やネットワークトラフィックなどを記録しています。
3つ目が依存関係のダッシュボードということで、こちらは他のマイクロサービスと連携している場合に作成します。特に相手のチームがすでにそのマイクロサービスについてダッシュボードを作っていたとしても、この依存関係に特化したようなダッシュボードを作成してあげます。
これによって、自分たちのチームのマイクロサービスから見てその相手のチームのサービスが動いているのか、レスポンスタイムは正常なのかといった、自分たちの視点に特化したダッシュボードを見ることができます。
（次回に続く）
