運用を可視化するためのアイデア
運用を可視化する
The Amazon Builders' Libraryに、運用を可視化するためのダッシュボードの構築という記事が掲載されていました。読んで見ると「可視化」という非常に曖昧なことばをうまく噛み砕けていたので、是非参考にしたいと思ったのでメモとして残しておきます。
顧客や社内の上層部から「可視化が課題なんだよね」といったことばをかけられた経験は誰しもあると思いますが、なんとなくわかっちゃいるけどそれを提案につなげていくのは非常に難しいです。なぜ難しいかというと、「可視化」というキーワードはあまりにも抽象度が高いことばだからです。記事ではダッシュボードというツールを軸に話が行われていますが、「可視化」されるべきポイントが何か明確になっているので、「可視化」に課題を感じたことがある人はぜひ読んでみてほしい記事です。
Amazonのダッシュボード活用方法
Amazonではクラウドサービスで行われる処理を常に把握するという課題へ対処するために「ダッシュボード」を活用しているそうです。ダッシュボードを使うことで、システムの動き・状況を人間が理解できるかたちで表示することができるため、判断の助けになるわけです。
Amazonでは、ダッシュボードの作成、使用、継続的な管理を行うことを「ダッシュボード化」と呼び、大変重要なタスクとして捉えているとのことです。Amazonではさまざまなダッシュボードを作成しています。これは、1つですべてのユースケースにマッチさせることは不可能です。各々のユースケースに合ったダッシュボードを作成し、異なる視点からシステムの確認を行うことで、さまざまな視点からさまざまな時間間隔でシステムがどのように動作しているかを把握できるようになります。
Amazonが使用するダッシュボードとそれらのダッシュボードを使って誰が、何のデータを、何のために見るのかをマトリクスでまとめると下表のようになります。（一部の項目は明記されていなかったため、当方[@skksky_tech]の推測で入れています）
| レベル | ダッシュボード | 誰が | 何を | 何のために見たいのか |
|---|---|---|---|---|
| 高 | カスタマーエクスペリエンスダッシュボード | サービスオペレーターや他の多くの関係者を含む幅広いユーザーグループ | ユーザーが知りたい影響の深さや広がりについて知るのに役立つデータ | 「影響を受ける顧客の数は？」、「どの顧客がもっとも影響を受けるか？」といった疑問に答えるため |
| 高 | システムレベルダッシュボード | サービスオペレーター | システムへの入力、システム上での処理、システムからの出力に関連するデータ | オペレーターがシステムとその顧客向けエンドポイントの動作を確認するため |
| 高 | サービスインスタンスダッシュボード | サービスオペレーター | 単一のサービスインスタンス（パーティションまたはセル）内のカスタマーエクスペリエンス | 他のサービスインスタンスからの関係のないデータのせいで過負荷にならず、カスタマーエクスペリエンスを迅速かつ包括的に評価するため |
| 高 | サービス監査ダッシュボード | サービスオペレーター | あらゆるサービスのインスタンスのデータ | カスタマーエクスペリエンスや、主要なサービスレベル目標の達成状況を確認するため |
| 高 | キャパシティプランニングと予測ダッシュボード | サービスオペレーター | システムに関するキャパシティ | 長期的な目線で、キャパシティプランニングと予測を行うため |
| 低 | マイクロサービス固有のダッシュボード | サービスを所有するチーム | サービスの深い知識を必要とする実装に特化したモニタリングデータ | 集約されたデータの異常を特定すると、通常、他のいろいろなツールを使ってさらに深く掘り下げ、基礎となるモニタリングデータに対してアドホッククエリを実行し、データの集約、リクエストのトレース、関連するまたは相関するデータの開示ができるようにするため |
| 低 | インフラストラクチャダッシュボード | インフラチーム | CPU使用率、ネットワークトラフィック、ディスク IO、スペース使用率などコンピューティングリソースに関連するすべてのメトリクスデータ | AWS インフラストラクチャの状況を観測し、異常がないか確認するため。 |
| 低 | 依存関係ダッシュボード | サービスを所有するチーム | 上流の依存関係（プロキシやロードバランサーなど）と下流の依存関係（データストア、キュー、ストリームなど）の両方がどのように動作しているかの情報 | セキュリティ証明書の有効期限やその他の依存関係の割り当ての使用状況など、他の重要なメトリクスを追跡するため |
個人的理解
「可視化」ということばが使われる文脈には、たとえば、「システム障害の根本原因がわからない」や「構成管理ができておらずEOL等の対応がいつもギリギリとなっている」など必ず何かしらの課題があるのだと思います。そういった課題を解決することが可視化の目的になるのだと考えます。ラフスケッチではありますが、思いつく限りで図示してみました。
可視化の目的と必要とされるデータの関係性
可視化の目的は大きく3つに分かれると考えます。なお、これらの上位には「システムを安定稼働させる」や「コストや収益を最適化する」といったビジネス目標があるはずです。
- システム障害時の影響確認：システムを安定稼働させる上で取得しておくべきメトリクスを取得し、正常値に対する異常値を検知・可視化することで、5W1Hの文脈で影響範囲を特定&解決に向けて取り組むことができる状態を目指す目的。
- キャパシティ管理や需要予測：需要に応じたキャパシティを用意し、システム障害や高コスト体質化を未然に防ぐ目的。
- システム監査：事前定義されたサービスレベル目標を満たしているか、また想定異常のシステム維持コストが発生していないかなど、想定通りの動きをしているかを確認する目的。
ただし、一口にシステム障害時の影響確認といっても、役割によって見たい情報は変わってきます。
- エンドユーザー：システムの利用可否、使い勝手が知りたい
- 顧客／サービスオーナー：サービスとしての健全性（安定稼働、コスト、目標達成度、収益性）が知りたい
- サポートセンター：システム障害の影響範囲や復旧目処が知りたい
- 監視オペレーター：異常発生箇所や解消するための手順が知りたい
- エンジニア：システムとしての健全性（異常発生箇所、システム間の関連性）が知りたい
このように、同じ目的を持っていても、必要とする情報が異なることから、それぞれの目的と役割に最適化されたダッシュボードや検知ロジックが必要になります。
以上
Discussion