AWSは先頃、運用可視化のためのダッシュボード構築に関わる自社のベストプラクティスを、Amazon Builder's Libraryに追加した。新たなドキュメントには、Amazonに存在するさまざまなタイプのダッシュボードに関する詳細な説明に加えて、ダッシュボードの開発で使用される設計上のベストプラクティスに関する議論が含まれている。
AWSのプリンシパルエンジニアであるJohn O'Shea氏が、Builder's Libraryについて記事を書いている。それによれば、AWSでは、サービス状態に関する情報を常時入手可能なメカニズムのひとつとして、ダッシュボードを位置付けている。システムの運用状況の対人的なビューを提供するものがダッシュボードなのだ。しかしO'Shea氏は、"ダッシュボードを人が監視する必要のある運用プロセスでは、どれほど頻繁に監視を行ったとしても、人的エラーによる失敗が発生することが分かっている"、と明言している。これに対処するために氏らが力を入れているのが、システムが出力する最重要データを評価するアラームの自動生成機能だ。これらのアラームが自動修復ワークフローを起動する場合もある。
Amazonでは、オンコールインシデント時にダッシュボードを活用して、運用担当者がトラブルシュートや問題の切り分けを行っている。その他のおもな用途としてO'Shea氏が言及するのは、週次で行う運用レビューミーティングだ。このミーティングにはシニアリーダ、マネージャ、エンジニアらが出席し、彼らが"運命の輪(wheel of fortune)"と呼ぶツールを使ってランダムに選択されたチームのカスタマエクスペリエンスやサービスレベル目標について、システムダッシュボードを使って表示し、議論する。
一貫性と利便性のあるダッシュボードの設計を支援するため、Amazonでは、従うべき一連の共通設計原則を用意している。それらを改善し発展させる手段として、同社では、その効果を測定する方法を見つけ出した。そのような測定のひとつが、新たにダッシュボードを使用するオペレータが、いかに短時間でダッシュボードを理解して習熟するか、というものだ。このようなメトリクス駆動のアプローチは、Camille Fournier氏が先日のInfoQとのインタビューで論じた、社内プラットフォームチームがより効果的なプロダクトを提供するためのテクニックやストラテジとも整合する。
原則のひとつは、想定するエンドユーザから逆算的に作業して、ダッシュボードがユーザのニーズを満足できるようにすることだ。O'Shea氏の言うように、"作成する側が納得できるようなダッシュボードを構築するのは簡単ですが、このダッシュボードがユーザに価値を提供できるという保証はない"のだ。ユーザには最初にレンダリングされるグラフが最も重要だと解釈する傾向があることが分かっているので、規則では、最も重要なグラフを先頭に置くように定めている。Webサービスにおいては、集約あるいは要約された可用性のグラフや、エンドツーエンドの遅延パーセンタイルグラフが重視される傾向がある。
その他の設計原則としては、次のようなものがある。
- 表示のタイムゾーンが一貫していること(かつ、それがダッシュボードに表示されていること)
- 予想される最低の画面解像度を想定してグラフをレイアウトすること
- 測定時間と周期を調整する機能を用意すること
- グラフには警告しきい値と目標値を表示すること
- アラーム状態、単純な数値、時系列グラフの各ウィジェットを状況に応じて使い分けること
O'Shea氏は次に、Amazonで使用されているさまざまなタイプのダッシュボードについて論じている。最も重要かつ広く使用されているタイプはカスタマエクスペリエンスダッシュボードで、サービスオペレータからマネジメントまで、幅広いステークホルダが使用するようにデザインされている。このスタイルのダッシュボードは、サービス状態全般や目標に対する現時点での進捗に関するメトリクスを中心に、"影響を受けるユーザの数"や"最も大きく影響するユーザ"といった疑問に答えるようなデータをセットアップしている。
ダッシュボードはシステムレベルやサービルレベル、およびサービス監査の目的でも、すべてのリージョンにわたって作成されて、システムやサービスの運用に関するさまざまなビューを実現している。システムダッシュボードには、システムや任意のエンドポイントの動作を確認する上で十分な情報を含む必要がある。一方でサービスレベルのダッシュボードは、ひとつのサービスインスタンスを詳細に探索することで、より深いトラブルシューティングを可能にするような、範囲の狭いビューを提供しなければならない。
ガイドの最後では、ダッシュボードのメンテナンスについて論じている。O'Shea氏によると、
ダッシュボードのメンテナンスとアップデートは、私たちの開発プロセスに強く根付いています。変更を完了する前に、そしてコードレビュー中に、当社の開発者たちは"ダッシュボードの更新が必要だろうか？"と質問します。彼らには、その基盤となった変更をデプロイする前に、ダッシュボードの変更を行う権限が与えられているのです。
このアプローチは、ダッシュボードの開発やメンテナンスを文化の一部として植え付けることを目的とするものだ。Tyler Treat氏が先日のInfoQとのインタビューで語ったように、"ほとんどのものがそうであるように、始まりは文化です。可観測性の文化を促進しなければなりません。計装をシステムのトップクラスの関心事として捉えなければ、いくらツールがあっても役には立たないのです。"
さらに、実施後の議論で、ダッシュボードとそれに続く自動警告の改善によって、問題の先取りや、より迅速な特定が可能になったかどうか、検討することを推奨する。これらダッシュボードの変更は、バージョン管理やインフラストラクチャ・アズ・コードといったコアプラクティスを使用して、サービスで使うものと同じツーリングでデプロイする。
紹介した記事全体は、Amazon Builder's Libraryの一部である。このライブラリには、Amazonがソフトウェアを構築し、メンテナンスし、運用する方法について調査した結果を記述した、さまざまなドキュメントが含まれている。