AWS DevOps Monitoring Dashboard ソリューションを使用して CI/CD メトリクスのキャプチャと分析を自動化する方法

この記事は 2021年4月14日に Solutions Builder and Data Analytics SME の Aijun Peng と Technical Program Manager の Rakshana Balakrishnan により投稿された How to automate capture and analysis of CI/CD metrics using AWS DevOps Monitoring Dashboard solution を翻訳したものです。

世界中の企業が、ソフトウェア・デリバリー・プロセスの生産性を向上させるために、DevOps ツールに投資しています。お客様からは、継続的インテグレーション／継続的デリバリ (CI/CD) パイプラインのパフォーマンスや運用に関するメトリクスを収集して、DevOps の自動化から得られる価値を定量化し、ソフトウェアデリバリーの効率化を行える箇所を特定したい、という声が寄せられています。しかし、お客様の中には、適切なメトリクスを特定し、CI/CD パイプラインのさまざまなコンポーネントからメトリクスを集約することは、複雑で時間のかかるものであるため、困難であると感じている方もいらっしゃいます。

この記事では、AWS DevOps Monitoring Dashboard ソリューションを使うことで、DevOps メトリクスを収集して可視化するためのセットアッププロセスを自動化し、時間と労力を節約する方法を紹介します。このソリューションは、あらゆる規模の組織がソフトウェア・デリバリー・プロセスにおける主要な運用指標を収集、分析、可視化することを容易にするリファレンス実装です。

そして、このソリューションは DevOps リーダーが DevOps における取り組みの影響を測定し、開発チームの継続的な改善を推進するためのデータに基づく意思決定を支援します。

なお、本ソリューションは、AWS Developer Tools (AWS CodeCommit、AWS CodeDeploy) および Amazon CloudWatch Synthetics からのデータの取り込み、分析、可視化をサポートし、平均修復時間 (MTTR) 、変更失敗率、デプロイメント、コード変更量などの主要な DevOps メトリクスを算出します。

ソリューションの概要

次のアーキテクチャ図は、このソリューションのワークフローを示しています。なお、画像は翻訳元と異なり翻訳時点2021年11月1日での最新版をもとにしています。

ワークフローには以下のステップがあります。

開発者は、AWS CodeCommit にコード変更をプッシュしたり、AWS CodeDeploy を使ってアプリケーションをデプロイするなど、CI/CD パイプラインのアクティビティを開始します。これらのアクティビティはイベントを生成します。
Amazon CloudWatchのMetric Stream および Amazon EventBridge のルールは、事前に定義されたイベントパターンに基づいてイベントを検出し、イベントデータを Amazon Kinesis Data Firehose の配信ストリームに送信します。イベントソースごとに1つのルールが作成されます。
お客様が Amazon CloudWatch Synthetics の Canary とその Amazon CloudWatch アラームをアカウントに設定している場合、別のイベントルールが Canary の状態を監視するアラームからのイベントをキャプチャします。これらのリソースは、 MTTR メトリクスを計算するためのデータを収集するために必要です。
Kinesis Data Firehose では、データ変換に Lambda 関数を使用しています。Lambda 関数は生のイベントデータを解析して関連するデータを Firehose 配信ストリームに返し、Firehose 配信ストリームはデータを Amazon Simple Storage Service (Amazon S3) のバケットに送り、以降のプロセスに繋げます。
Amazon Athena のデータベースが Amazon S3 のデータに対してクエリを実行し、クエリ結果を Amazon QuickSight に返します。
Amazon QuickSight は、クエリの結果を取得しマネジメント層向けのダッシュボードとしてビジュアライゼーションを構築します。

ソリューションの前提条件

1. AWS CodeCommit 、AWS CodeBuild 、AWS CodeDeploy 、AWS CodePipeline で構成される CI/CD パイプラインがあなたのアカウントにセットアップされている必要があります。現在 AWS で CI/CD パイプラインをセットアップしていない場合は、「AWS で CI/CD パイプラインをセットアップする」を参照してください。

2. Amazon QuickSight の可視化機能を使用したい場合は、ソリューションをデプロイするアカウントで Amazon QuickSight Enterprise 版をサブスクライブする必要があります。QuickSight Enterprise アカウントを設定していない場合、Amazon QuickSight User Guide の Amazon QuickSight サブスクリプションへのサインアップを参照してください。

QuickSight Principal Amazon Resource Name (ARN)をメモしておきます。これはソリューションを展開する際に必要となります。Amazon QuickSight Principal ARN を取得するには、AWS CLI がインストールされたシェルまたはターミナルにアクセスする必要があります。インストール手順については、AWS CLI ユーザーガイドの AWS Command Line Interface とはを参照してください。また、AWS CloudShell を使用して AWS CLI コマンドを実行することもできます。

list-users コマンドを実行するとユーザーのリストとその QuickSight ユーザーの ARN (arn:aws:quicksight: <aws-region>:<account-id>:user/<namespace-name>/<quicksight-user-name>) が返されます。デフォルトの namespace-name は default です。

ARN の例: arn:aws:quicksight:us-east-1:1111111111111:user/default/myquicksightuser

aws quicksight list-users --region <aws-region> --aws-account-id <account-id> --namespace <namespace-name>

ARN が複数出力される場合は、本ソリューションを動かす AWS アカウントと AWS リージョン内で、QuickSight リソースを作成する権限を持つユーザーを選択してください。これは例えば QuickSight の「admin」ユーザーのようなユーザーです。

Step 1: ソリューションのデプロイ

提供されている AWS CloudFormation テンプレートを使用して、ソリューションをあなたのAWSアカウントにインストールします。このテンプレートには、以下の入力パラメーターがあります。必要に応じて変更することができます。

パラメーター	デフォルト	説明
Athena Query Data Duration (Days)	90	Athena クエリがデータを検索する際に使用する期間 (日数) を入力します。デフォルトでは Athena クエリは過去 90 日間のデータを検索します。パフォーマンスを最大化し、コストを最小化するために、期間を制限することをお勧めします。
AWS CodeCommit Repository List	‘ALL’	監視対象となる AWS CodeCommit リポジトリの名前のリストです。名前はシングルクォーテーションで囲み、カンマで区切る必要があります (例: ‘MyRepository1′,’MyRepository2’) 。すべてのリポジトリを監視する場合は、デフォルトの ‘ALL’ のままにします。
S3 Transition Days	365	Amazon S3 オブジェクトを Amazon S3 Glacier ストレージクラスに移行させる日数を入力します。デフォルトでは、オブジェクトは作成から365日 (1年) 後に Amazon S3 Glacier に移行します。
Amazon QuickSight Principal ARN	<空白>	QuickSight ダッシュボードを自動的に作成するために、QuickSight admin ユーザーARN (arn:aws:quicksight:AWSRegion:AWSAccountId:user/default/QuickSightUserName) を提供します。そのアカウントで QuickSight Enterprise 版が有効になっている必要があります。QuickSight ダッシュボードの作成を無効にするには、空白にします。

スタックの展開には約10分かかります。デプロイに成功すると、AWS CloudFormation コンソールでステータスが CREATE_COMPLETE になっていることが確認できます。

備考: Amazon QuickSight Principal ARN を提供した場合、このソリューションは、提供したアカウントに QuickSight リソースを作成するためのネストされたスタックを起動します。

Step 2: Amazon QuickSight の設定

このソリューションでは、データの視覚化に Amazon QuickSight を使用しています。パーミッションを設定し、Amazon QuickSight でデータセット、分析、およびダッシュボードを表示するには、以下の手順に従ってください。

備考: 必要に応じて、独自の可視化ツールを設定することができます。詳細については、「AWS DevOps Monitoring Dashboard Imprementation Guide」を参照してください。

スタックが正常にデプロイされたら、スタックの出力タブに行き、QSAnalysisURL、QSDashboardURL、DevOpsMetricsS3Bucket の値をメモしておきます。
AWS マネジメントコンソールにサインインし、Amazon QuickSight コンソールに移動します。
ソリューションをデプロイしたリージョンに合わせて QuickSight の URL を変更します。例えば、ソリューションを us-east-1 リージョンに展開した場合、QuickSight の URL は次のパスを反映したものになります。https://us-east-1.quicksight.thinkwithwp.com/sn
右上でユーザー名を選択し、「QuickSight の管理」を選択します。
左のナビゲーションペインから、「セキュリティとアクセス権限」を選択します。
「QuickSight の AWS サービスへのアクセス」で、「Manage」を選択します。
「IAM」、「Amazon S3」、「Amazon Athena」をチェックします。これらのオプションがすでにチェックされている場合は、一度チェックを外してから再度チェックしてください。
「Amazon S3」をチェックした際に、「Amazon S3 バケットの選択」が現れなかった場合は「S3 バケットを選択する」リンクをクリックします。
スタックの出力の「DevOpsMetricsS3Bucket」の値にあったバケット名のチェックボックスをチェックし、「Athena Workgroup の書き込みアクセス許可」のチェックボックスにもチェックします。
「保存」を選択します。
スタックの出力タブで、QSAnalysisURL と QSDashboardURL を選択して、ダッシュボードと分析を開きます。なお、QuickSight コンソールからそれらに移動することもできます。このソリューションでは、1つの分析、1つのダッシュボード、およびいくつかのデータセットが作成されます。ソリューションによって作成されたすべての QuickSight リソースには、スタック名が前に付いています (例: <stackname>-dashboard) 。

備考: ソリューションの起動直後に Amazon S3 のメトリクスバケットが空になると、No Data メッセージが表示されることがあります。CI/CD アクティビティがソリューションに送信されるまで時間がかかります。ソリューションがデータの処理を終え、Amazon S3 にメトリクスを送信した後に、データやビジュアルを表示するページを更新することができます。

Step 3: Canary とアラームの設定

このソリューションでは、Amazon CloudWatch Synthetics の Canary と Amazon CloudWatch のアラームを使用して、MTTR メトリクスの計算に必要なデータを収集します。Canary はエンドポイントやAPIを監視するためにスケジュールに沿って実行される設定可能なスクリプトです。Canary のジョブの状態が変化 (失敗または成功) すると、アラームがトリガーされます。このソリューションでは、アラームデータを使用して、失敗イベントと成功イベントの間隔に基づいて、サービスの復旧にかかる時間を計算します。

Canary とそのアラームを設定する方法を次の中から選んでください。

自動設定 (推奨)

このソリューションには canary-alarm.template が用意されており、これを利用してアカウントにアラームや Canary を作成することができます。

手動設定

Canary を作成していない方は、この手順で作成してください。それ以外の方は次のステップに進んでください。
この手順で Canary のジョブの状態を監視するアラームを作成します。メトリクスを選択するステップに到達したら、次の2つの図に示すように、Canary である CloudWatchSynthetics と SuccessPercent メトリクスが選択されていることを確認します。
アラームには、CloudWatchSynthetics のメトリクスを選択します。

[Browse]タブで、CloudWatchSyntheticsがアラームとして選択されています。

Browse タブで Canary で検索し、メトリクス名が SuccessPercentのCanary を選択します。

[Browse]タブで、メトリクス名がSuccessPercentのmycanaryという名前のカナリアが選択されています。これは、アラームのメトリックです。

アラーム名には以下のパターンを使用してください。SO0143-[my-application-name]-[my-repository-name]-MTTR (例えば、SO0143-[MyDemoApplication]-[MyDemoRepo]-MTTR) 。なお「SO0143」は今回利用している AWS DevOps Monitoring Dashboard ソリューションを示す ID となります。アプリケーション名は Canary が監視しているアプリケーションの名前です。リポジトリ名はアプリケーションのソースコードが存在するリポジトリの名前です。このソリューションではアラーム名を使用して、MTTR メトリクスにアラームが使用されているかどうか、どのアプリケーションとリポジトリがメトリクスに関連付けられているかを判断します。

「条件」セクションの「しきい値の種類」では、「静的」を選択します。「SuccessPercent が次の時…」では「より低い」を選択し、ユースケースに合ったしきい値を入力します (例: 100) 。

次の図は、アラームを示しています。

この例ではCanaryジョブの成功率が5分以内に100％を下回るとアラームがトリガーされます。

Amazon QuickSight ダッシュボードによる可視化

初期設定が完了し、ソリューションがイベントデータの処理を開始した後、Amazon QuickSight ダッシュボードを使用してメトリクスの視覚化を見ることができます。
Amazon Athena からクエリされたデータを使用して、Amazon QuickSight で利用可能なダッシュボードを見てみましょう。Amazon Athena のクエリは、DevOps メトリクスを分析して視覚化するために、デフォルトで過去90日以内のデータを取得します。これは CloudFormation テンプレートでユーザーが設定できる入力パラメータです。パフォーマンスを最大化しコストを最小化するために、データ期間を制限することをお勧めします。

Code Change Volume ダッシュボード

これらのダッシュボードでは、Author やリポジトリごとに行われたコード変更の数を表示します。Author やリポジトリごとのメトリクスを週次、月次、全体で集計して表示します。カスタムフィルタを使用して、Author、リポジトリ、または期間でデータをフィルタリングすることができます。DevOps リーダーは、このダッシュボードを使用して、開発チームのコーディング活動の可視性を向上させることができます。誰が最も多くのコード変更を行っているか、どのリポジトリが時間の経過とともに最も活発になっているかなどの質問に答えることができます。

ダッシュボードにはAuthorごとの週次変更量、リポジトリごとの週次変更量、Authorごとの月次変更量、リポジトリごとの月次変更量、Authorごとの合計変更量、およびリポジトリごとの合計変更量のグラフが含まれます。

Mean Time to Recover ダッシュボード

これらのダッシュボードには、アプリケーション別の停止時間 (分) と、アプリケーションが障害状態から成功状態に復旧するまでの平均時間が表示されます。これらのダッシュボードでは、アプリケーション別のメトリクスを週次、月次、全体で集計して表示します。また、カスタムフィルタを使用して、アプリケーションや期間でデータをフィルタリングすることができます。これらのダッシュボードは、DevOps リーダーが、変更アクティビティとシステムの安定性を関連付け、アプリケーションの安定性を向上させる機会を追跡、特定するのに役立ちます。

ダッシュボードにはアプリケーションごとの週平均停止時間、アプリケーションごとの週ごとの停止数、アプリケーションごとの月ごとの停止分、アプリケーションごとの月ごとの停止数、アプリケーションごとの合計停止分、およびアプリケーションごとの合計停止数のグラフが表示されます。

Change failure rate ダッシュボード

これらのダッシュボードでは、アプリケーションごとのデプロイメントの失敗の頻度を、デプロイメント全体に対する失敗の比率を測定することで表示します。これらのダッシュボードでは、アプリケーションごとのメトリクスを週次、月次、全体で集計して表示します。カスタムフィルタを使用して、アプリケーションまたは期間でメトリクスをフィルタリングすることができます。これらのダッシュボードは、DevOps リーダーが開発チームのコード品質を追跡し、変更失敗率を長期的に削減するための改善を促進するのに役立ちます。

ダッシュボードにはアプリケーションごとの全体的な変更失敗率、アプリケーションごとの週ごとの変更失敗率、週ごとの変更失敗率の内訳、週ごとの変更失敗率の傾向、月ごとの変更失敗率の傾向、アプリケーションごとの月ごとの変更失敗率、および月ごとの変更失敗率のグラフが表示されます。

Deployment ダッシュボード

これらのダッシュボードは、アプリケーション別にデプロイメントの頻度と状態 (成功／失敗) を表示します。これらのダッシュボードでは、アプリケーション別のメトリクスを週次、月次、全体で集計して表示します。カスタムフィルタを使用して、アプリケーションまたは期間でメトリクスをフィルタリングすることができます。これらのダッシュボードにより、DevOps リーダーは、エンドユーザへの継続的なソフトウェア・リリースの頻度と品質を追跡することができます。

ダッシュボードにはアプリケーションごとの合計デプロイ数、週ごとのデプロイ傾向、月ごとのデプロイ傾向、アプリケーションごとの週ごとのデプロイ数、アプリケーションごとの月ごとのデプロイ数、アプリケーションごとのデプロイ状態、およびアプリケーションと状態ごとのデプロイの表形式のグラフが表示されます。

クリーンアップ

アカウントへの課金を避けるため、ソリューションをテストした後は、スタックとリソースを削除してください。

コンソールを使用する場合

AWS CloudFormation コンソールで、ソリューションのルートスタックを選択し、「削除」を選択します。

AWS CLI を使用する場合

AWS CLI 環境で以下のコマンドを実行します。

$ aws cloudformation delete-stack —stack-name <installation-stack-name>

備考: ソリューションスタックを削除すると、ソリューションで作成された S3 バケットの保持ポリシーが「保持」に設定されているため、それを除くすべてのリソースが削除されます。この S3 バケットは手動で削除することができます。

まとめ

このブログ記事では、AWS DevOps Monitoring Dashboard ソリューションを AWS CloudFormation テンプレートを使って展開し、AWS Developer Tools からデータを収集し、Amazon QuickSight を使って可視化する方法を紹介しました。このソリューションはチームの CI/CD 活動を監視することができるので、DevOps リーダーは開発チームのパフォーマンスを追跡し、ソフトウェアデリバリーの継続的な改善に関するビジネス目標を推進することができます。

ソリューションの詳細については AWS DevOps Monitoring Dashboard Implementation Guide で、ソリューションのコンポーネントの説明、ステップバイステップの手順、コストの見積もりなどをご覧いただけます。このソリューションのソースコードをダウンロードしたり、必要に応じてカスタマイズしたものを他の人と共有するには、GitHub リポジトリをご覧ください。さらに詳しい情報は、AWS ソリューションライブラリをご覧ください。

この記事の翻訳はソリューションアーキテクト光吉隆雄が担当しました。原文はこちらです。

Amazon Web Services ブログ