定量的計測の実装方法(AWS編)

ガバメントクラウド利用組織が定量的計測のためのダッシュボード等の実装を理解するための文書である。
またデジタル庁が行うガバメントクラウド利用システム全体の定量的計測で公開するデータの閲覧方法を理解するための文書である。

定量的計測の全体像

ガバメントクラウド利用組織は各利用システム毎に定量的計測を行う必要がある。
各利用システムで計測したデータの一部はデジタル庁が集約し定量的計測を行う。計測したデータの一部はガバメントクラウド利用組織が閲覧可能である。

図01　定量的計測の全体像

定量的計測の考え方

• サービス／アプリケーションとしてのKPIとコストを監視する
• リソースの使用量(CPU, Memoryなど)を中心とした監視設計はしない
  • サービス／アプリケーションを中心とした監視を行う
• 1ヶ月遅れの状況を見ても意味がないため、Word/Excelで月次運用報告書を作らない
  • 準リアルタイムに状況を可視化するダッシュボードを用意する
• 運用監視要員の貼り付け（常駐）を前提としない
  • 手順化できるものは自動化できるため、すべての監視とその対応を人間不要の自動化する
• Word/Excelの月次報告書を成果物や納品物として定義しない
  • 報告する側と報告を受けるだけの側に役割を固定せず、ダッシュボードで一緒に監視していく
  • 監視項目や可視化は運用中つねに相談しながら見直していく
  • 報告書が不可欠の場合は、ダッシュボードを報告書として整理する

ガバメントクラウド利用組織における定量的計測

KGI、KPIの定義

各利用システムにてビジネス価値に応じたKGI,KPIを定義すること。
またガバメントクラウドを利用する上で計測必須のKPIがある可能性があり、その場合は確定次第本書を更新する。

ダッシュボードの実装

ダッシュボードを実装するにあたり、デジタル庁より提供されるサンプルIaCファイルを参考にして実装することが可能である。

サンプルIaCファイル構成

• サンプル申請アプリケーション
  計測対象の簡単なサンプルアプリケーション。 単純な申請が行えるフォーム画面、一覧表示画面と、同様のことが行える API で構成。API はテスト用に作成されているため、最低限の形で実装。
  ALB + ECS(Fargate) + Aurora(PostgreSQL) にて構成。 ECS 上で動作するアプリケーションは、 Java + Spring Boot にて作成。
  ※ オートインストルメンテーションエージェントを起動時に指定することで、 X-Ray にも対応することが可能
• トラフィックジェネレータ
  サンプル申請アプリケーションへインターネット越しに API リクエストを送り続けるアプリケーション。 BtoB でありそうなトレンドのトラフィックを生成する。 ECS(Fargate) にて構成されており、アプリケーションは Golang にて作成されている常駐型のアプリケーション。
• CloudWatch ダッシュボード
  サンプル申請アプリケーションのログやメトリクスをベースに作成したダッシュボード。 一部、Lambda ベースのカスタムウィジェットもサンプルとして実装。
  
  図02:定量的計測サンプルIaCファイル構成

サンプルIaCファイルダッシュボード構成

• ビジネスメトリクス領域
  このシステムの価値が発揮できているかを見るための指標を表示する領域。アプリケーションから出力したログをベースに指標値化することが必要。ログをベースにクエリで表示する、カスタムメトリクスを送るなどの方法がある。このテンプレートでは、ログをベースに CloudWatch Logs Insights のログを利用して可視化するようにサンプル実装をしている。
  この領域が最も重要な領域になるため、最も上に位置している。
  
  図03:ビジネスメトリクス領域
• 主要アラーム領域
  直接サービスや UX に影響があるメトリクスをベースに作成したアラームを定義する領域。このアラームが発生したときには、なんらかのアクションを取る必要があるということになる。そのため、厳選したアラームを設定し、アラームが起きたときのアクションを前もって定義しておく必要がある。特に、自動でスケールできるインスタンスの CPU やメモリなどに対してのアラームは基本的に不要。「ユーザー」にとって意味のあるアクションを前もって定義できる場合のみアラームの設定を行う。
  
  図04:主要アラーム領域
• 主要システムメトリクス領域
  UX に直接影響が出るシステムのメトリクスや、ビジネスメトリクスに準ずるメトリクスを定義する領域。主にレスポンスタイムや可用性に関する指標、エラーに関する指標、リクエスト数などが中心となる。レスポンスタイムなどの値は、提供するシステムが広いユーザー向けでユーザーが能動的に再実行をしてくれることが期待できるシステムなどの場合は、99 パーセンタイルなどの集計を用いる方が有益。平均値、中央値、最大値などの値ではユーザーへの影響を正しく判断できない可能性があるため、99 パーセンタイルなどの値とともに合わせて確認することが良い場合がある。
  
  図05:主要システムメトリクス領域
• 主要ログ領域
  アプリケーションの状況やエラーの状況を確認するために、アプリケーションやシステムのログを表示する領域。ログは、きちんとパースできるように設計します。JSON 形式であれば、特殊なパースを必要とせずに容易にフィルタがかけられるため、可能であれば JSON による構造化を行ったログにする方が良い。パースしフィルタをかけ、必要なログだけをここに表示するようにするのがポイントになる。
  
  図06:主要ログ領域
• コスト領域
  インフラコストも常に意識すべき項目になる。このテンプレートでは Lambda によるカスタムウィジェットを用いて AWS サービスごとのコストを表示しているが、実運用では見たいコストの形によって変更が必要。
  
  図07:コスト領域
• セキュリティ領域
  インフラのセキュリティ状況も意識すべき項目。BLEA ではダッシュボードとは別にアラームが上がる仕組みもあるが、ダッシュボードで一元的に現状確認もできるようにしておいたほうが良い。このテンプレートでは Lambda によるカスタムウィジェットを用いて Trusted Advisor, Security Hub, GuardDuty, CloudTrail の状況を表示している。
  
  図08:セキュリティ領域
• システムメトリクス領域
  ここまでの領域において問題が発生したときに、調査をするための各種メトリクスを定義しておく。ダッシュボードに並べて表示しておくことにより、同じタイムラインでの事象を同時に確認することができ、メトリクス間の関連を見ることができる。たとえば、リソースの圧迫によりレスポンスタイムが長くなり、 UX が下がり、申請数が減っている、というような考察ができるようになる。
  
  図09:システムメトリクス領域
• その他サンプル領域
  カスタムウィジェットを使ったサンプルの領域。 Lambda を使うことにより、いろいろな機能を動的に実行することが可能。また、 HTML を利用することができるため表形式などでの表示を行うことも可能。しかし、より複雑な分析や表示を行いたい場合は、ここで無理に Lambda で実装するよりも QuickSight などのサービスを別途活用したほうが良い。
  
  図10:その他サンプル領域

　

サンプルIaCファイル実装方法

詳細は、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されている定量的計測サンプルIaCファイル（メンバー専用ページ→ガバメントクラウドテンプレート/ポリシー→ガバメントクラウドテンプレート/ポリシーのダウンロードページ）の内容を確認すること。

デジタル庁における定量的計測

以下、デジタル庁における定量的計測は仕様が確定次第更新予定である。

ガバメントクラウドのKGI、KPI

ガバメントクラウド利用組織が閲覧可能なKPI

KPIの閲覧方法

改訂履歴