Amazon Web Services ブログ

デプロイの速度と安定性を DORA メトリクスで適正化する

本稿は、2024年7月31日に AWS DevOps Blog で公開された “Balance deployment speed and stability with DORA metrics” を翻訳したものです。

開発チームは、ソフトウェア配信の速度と品質を高めるため、DevOps 実践を導入しています。DevOps Research and Assessment (DORA) メトリクスは、その目的の進捗状況を測る一般的な方法です。4 つの主要なメトリクスを使って、シニアリーダーはチームの成熟度の現状を評価し、最適化する領域に取り組むことができます。

このブログ記事では、Amazon Web Services (AWS) 環境で DORA メトリクスを活用する方法を説明します。
AWS アカウントでメトリクス収集を自動的に開始できるサンプルソリューションを共有します。

DORA メトリクスを収集する利点

DORA メトリクスは、デプロイの速度と安定性の定性的側面を測定することで、開発チームのパフォーマンスと能力を把握するのに役立ちます。また、障害からの平均復旧時間を測定することで、チームの適応能力を示します。これにより、プロダクトオーナーは作業の優先順位を決定し、チームの成熟度を透明化し、現実的な作業負荷のスケジュールを立てることができます。メトリクスは経営陣とのコミュニケーションにも適しています。経営陣の支援を得て、チームの満足度とユーザーエクスペリエンスを阻害している根本的な問題を解決することができます。

ユースケース

このソリューションが適用できるユースケース:

  • 開発チームは、CI/CD ツールがホストされている ツールアカウントと、ログの集約および可視化のためのオペレーションアカウントを含む、マルチアカウントの AWS セットアップがあります。
  • 開発者は GitHub のコードリポジトリと AWS CodePipeline を使用して、コード変更をアプリケーション環境アカウントに適用しています。
  • ツール、オペレーション、アプリケーション環境アカウントは、AWS Control Tower のメンバーアカウントまたは、Landing Zone Accelerator on AWS ソリューションのワークロードアカウントです。
  • システム変更に起因するサービスの障害は、AWS Systems Manager OpsCenter の OpsItem としてログに記録されます。

ソリューションの概要

DORA の 4 つの主要メトリクス

「4 つのキー」は、チームの実績と問題への対応力を測定します:

  1. “デプロイ頻度” はプロダクション環境で変更リリースが成功する頻度を示します。
  2. “変更リードタイム” はコミットされたコードがプロダクション環境に到達するまでの平均時間を示します。
  3. “変更失敗率” はプロダクション環境における変更がサービスインシデント/障害につながる頻度を示し、平均故障間隔時間の補完的な指標です。
  4. “平均復旧時間” はサービス中断からフル復旧までの平均時間を示します。

最初の 2 つのメトリクスはデプロイの速度に焦点を当てていますが、他の 2 つはデプロイの安定性を示しています (図 1)。組織がサービスの重要性と顧客のニーズに基づいて独自の目標 (つまり DORA メトリクスのターゲット) を設定することをお勧めします。従来の DORA ベンチマークデータと、それが開発チームのパフォーマンスについて何を示しているかの議論については、DORA メトリクスが性能を測定および改善する方法を参照してください。

図 1. DORA メトリクスの概要

デプロイ速度と安定性のバランスを取るための DORA メトリクスの計算ロジックの詳細については、GitHub コードリポジトリ Balance deployment speed and stability with DORA metrics を参照してください。このロジックに変更を加える場合は、十分に注意して行ってください。

たとえば、変更障害率はプロダクション環境を損なう変更に焦点を当てています。プルリクエストのタグ (ホットフィックスなど) に計算を限定すると、ビルドプロセスに関連する問題が除外されます。実際にプロダクション環境で障害が発生するようなシステム変更記録を一致させることが重要です。デプロイパイプラインから失敗したデプロイの数に計算を限定すると、プロダクション環境に到達しなかったデプロイだけが考慮されます。変更関連の障害については、CI/CD ツールからのデータに依存するのではなく、AWS Systems Manager OpsCenter を記録システムとして使用しています。

同様に 平均復旧時間 は、プロダクション環境でのサービス障害が発生してからパイプラインが正常に実行されるまでの期間を測定します。パイプラインの障害が頻発する場合、ローカルでのテストが不十分であったり、パイプライン自体に問題がある可能性があるため、チームではパイプラインのステータスと復旧時間の両方を追跡することをお勧めします。

DORA イベントの収集

メトリクスの計算プロセスは 4 つのステップで実行されます:

  1. ツールアカウントでは、CodePipeline からイベントを Amazon EventBridge のデフォルトのイベントバスに送信します。
  2. イベントはカスタムイベントバスに転送され、定義されたメトリクスと設定したフィルタに従って処理されます。
  3. カスタムイベントバスは、AWS Lambda 関数をコールし、メトリクスデータを Amazon CloudWatch に転送します。CloudWatch では、各メトリクスの集約ビューが表示されます。Amazon CloudWatch からは、Amazon Managed Grafana などの指定したダッシュボードにメトリクスを送信できます。
  4. データ収集の一環として、Lambda 関数はリードタイム変更メトリクスを計算するための関連コミットを GitHub から照会します。変更失敗率とリカバリ平均時間のメトリクスについては、AWS Systems Manager から OpsItem データを照会します。変更管理プロセスの一部として OpsItem を手動で作成するか、CloudWatch アラームを設定して OpsItem を自動的に作成できます。

図 2 は、これらのステップを視覚化したものです。この設定は、1 つまたは複数のチームのアカウントグループに複製できます。

図 2. AWS CodePipeline デプロイ用の DORA メトリクス設定

構築手順

次の手順に従って、ご利用の AWS アカウントにこのソリューションをデプロイしてください。

前提条件

この構築手順を実行するには、以下の前提条件を満たす必要があります。

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

GitHub のコードリポジトリ Balance deployment speed and stability with DORA metrics を Clone してください。

この codebase をデプロイしたり作業する前に、cdk/ ディレクトリにある constants.py ファイルで設定する必要がある項目がいくつかあります。IDE でこのファイルを開き、次の定数を更新してください:

  1. TOOLING_ACCOUNT_ID と TOOLING_ACCOUNT_REGION: これらは、AWS CodePipeline (ツール) の AWS アカウント ID と AWS リージョンを表します。
  2. OPS_ACCOUNT_ID と OPS_ACCOUNT_REGION: これらはオペレーションアカウント用です (一元化されたログ集約とダッシュボードに使用されます)。
  3. TOOLING_CROSS_ACCOUNT_LAMBDA_ROLE: クロスアカウントアクセスを許可し、ツールアカウントからオペレーションアカウント/Amazon CloudWatch ダッシュボードへのメトリクス投稿を可能にする AWS Lambda の IAM ロールです。
  4. DEFAULT_MAIN_BRANCH: これは、プロダクション環境へのデプロイに使用されるコードリポジトリのデフォルトブランチです。デフォルトでは “main” に設定されています。これは、メインブランチで機能駆動型開発 (GitFlow) を想定しているためです。別の命名規則を使用する場合は、更新してください。
  5. APP_PROD_STAGE_NAME: これは、プロダクション環境の名前で、デフォルトでは “DeployPROD” に設定されています。トランクベースの開発を行うチームのために予約されています。

環境の設定

macOS と Linux で環境をセットアップするには:

  1. 仮想環境を作成します: 
    $ python3 -m venv .venv
  2. 仮想環境を有効にします: macOS と Linux の場合: 
    $ source .venv/bin/activate

代替案として、Windows 上で環境をセットアップするには:

  1. 仮想環境を作成します: 
    % .venv\Scripts\activate.bat
  2. 必要な Python パッケージをインストールします: 
    $ pip install -r requirements.txt

AWS コマンドライン インターフェイス (AWS CLI) を設定するには:

  1. AWS CLI ユーザーガイドの設定手順に従ってください。 
    $ aws configure sso
  2. ユーザープロファイル (オペレーションアカウントの場合は Ops、ツールアカウントの場合は Tooling など) を設定します。ユーザープロファイル名は認証情報ファイルで確認できます。

CloudFormation スタックのデプロイ

  1. ディレクトリを切り替えます 
    $ cd cdk
  2. CDK を Bootstrap します 
    $ cdk bootstrap –-profile Ops
  3. このプロジェクトの AWS CloudFormation テンプレートを合成します: 
    $ cdk synth
  4. 特定のスタックをデプロイするには (概要は図 3 を参照)、次のコマンドでスタック名と AWS アカウント番号を指定してください: 
    $ cdk deploy  --profile { Tooling, Ops }

    ツールアカウントで DoraToolingEventBridgeStack スタックを起動するには:

    $ cdk deploy DoraToolingEventBridgeStack --profile Tooling

    Operations アカウントで他のスタック (DoraOpsGitHubLogsStack、DoraOpsDeploymentFrequencyStack、DoraOpsLeadTimeForChangeStack、DoraOpsChangeFailureRateStack、DoraOpsMeanTimeToRestoreStack、DoraOpsMetricsDashboardStack を含む) を起動するには:

    $ cdk deploy DoraOps * --profile Ops

次の図は、各 CloudFormation スタックで起動するリソースを示しています。これにはオペレーション アカウントの 6 つの AWS CloudFormation スタック が含まれます。最初のスタックは GitHub のコミット活動のログ統合をセットアップします。4 つのスタックには、DORA メトリクスの 1 つを作成する Lambda 関数が含まれています。6 番目のスタックは、Amazon CloudWatch で統合ダッシュボードを作成します。

図 3. このソリューションでプロビジョニングされるリソース

デプロイのテスト

以下の手順でテストを実行してください:

$ pytest

構築したものの確認

ツールアカウントへデプロイされたリソース

DoraToolingEventBridgeStack には、オペレーションアカウントの中央イベントバスをターゲットとしている Amazon EventBridge ルールと、オペレーションアカウントにイベントをプッシュするためのクロスアカウントアクセスを持つ AWS IAM ロールが含まれています。EventBridge ルールを起動するためのイベントパターンは、AWS CodePipeline におけるデプロイの状態変化を監視します。

{
  "detail-type": ["CodePipeline Pipeline Execution State Change"],
  "source": ["aws.codepipeline"] 
}

オペレーションアカウントへデプロイされたリソース

  1. プロダクション環境へのデプロイ頻度を追跡する Lambda 関数は、成功したデプロイの回数をカウントし、その指標データを Amazon CloudWatch に投稿します。Amazon CloudWatch では、リポジトリ名の dimension を追加することで、特定のリポジトリやチームでフィルタリングすることができます。
  2. リードタイムメトリクスの Lambda 関数は、最初のコミットからプロダクション環境への成功したデプロイまでの期間を計算します。このメトリクスには、コードレビュー、ビルド、テスト、そして実際のデプロイなど、変更に関わるすべての要因が含まれています。
  3. 変更失敗率メトリクスの Lambda 関数は、プロダクション環境での成功したデプロイの回数と、システムの障害記録（OpsItems）の回数を追跡しています。この関数は、両方のメトリクスデータを Amazon CloudWatch に公開し、その比率を計算することで変更失敗率を算出しています。
  4. 平均復旧時間メトリクスの Lambda 関数は、プロダクション環境における SUCCEEDED ステータスのデプロイのうち、リポジトリのブランチ名にOpsItemのIDが含まれているものを追跡しています。該当するデプロイイベントごとに、この関数はOpsItemの作成時刻を取得し、OpsItem作成からの成功した再デプロイまでの期間をCloudWatchダッシュボードに公開しています。

すべての Lambda 関数は、PutMetricData API を使用して、メトリクスデータを Amazon CloudWatch に発行します。4 つのキーの最終計算は、CloudWatch ダッシュボードで実行されます。このソリューションには、エンドツーエンドのデータフローを検証し、正常にデプロイされたことを確認できる簡単な CloudWatch ダッシュボードが含まれています。

クリーンアップ

不要になったサンプルで作成したリソースは、将来的なコスト発生を避けるために削除を忘れないでください。これは CDK CLI から行えます:

$ cdk destroy  --profile { Tooling, Ops }

別の方法として、各 AWS アカウントの CloudFormation コンソールに移動し、DORA 関連のスタックを選択して 削除 をクリックしてください。すべての DORA スタックのステータスが DELETE_COMPLETE になっていることを確認してください。

まとめ

DORA メトリクスは、デプロイの速度と安定性を測定する一般的な方法です。このブログ記事のソリューションは、AWS アカウントでメトリクスの自動収集を開始するのに役立ちます。4 つのキーは、チームのパフォーマンスに関するコンセンサスを得るのに役立ち、改善案のデータポイントとなります。チームの満足度とユーザーエクスペリエンスを阻害する体系的な問題に対して、リーダーシップからの支援を得るためにこのソリューションを使用することをお勧めします。開発者の生産性に関する研究の詳細を学ぶには、DevEx および SPACE などの代替フレームワークをご覧ください。

参考リソース

この記事が気に入ったら、以下の記事も読んでみてください:

著者紹介

Rostislav Markov

Rostislav is principal architect with AWS Professional Services. As technical leader in AWS Industries, he works with AWS customers and partners on their cloud transformation programs. Outside of work, he enjoys spending time with his family outdoors, playing tennis, and skiing.

Ojesvi Kushwah

Ojesvi works as a Cloud Infrastructure Architect with AWS Professional Services supporting global automotive customers. She is passionate about learning new technologies and building observability solutions. She likes to spend her free time with her family and animals.