dora-team/fourkeysというOSSでFour Keysを計測してみた
はじめに
DORA (DevOps Research and Assesment)が提唱したFour Keys という言葉もかなり浸透してきましたね。最近ではFour Keysを自動的に計測してくれるツールもいくつか市場に出てきています。
今回はそういったツールの中から、OSSとして配布されている dora-team/fourkeys を使ってみたいと思います。
完成形はこんな感じです。
アーキテクチャ
リポジトリの README.mdに書かれていますが、以下のようなアーキテクチャになっています。
Google Cloud上に展開されています。
リソース数は少なく、AWSしか触ったことがない私でも問題なく理解できたので、大丈夫です。
なお、各リソースのAWSとの対応イメージは以下です。（※あくまでイメージです。）
| Google Cloud | AWS |
|---|---|
| Cloud Run | Lambda, ECS |
| BigQuery | RDS, RedShift |
| Pub / Sub | SNS, SQS |
| Cloud Build | CodeBuild |
| Container Registry | ECR |
| Secret Manager | Secrets Manager, Parameter Store |
内容をまとめると、
- Four Keys計測のもととなる生データが
BigQueryにどんどん蓄えられていく。そこからFour Keysに必要なデータだけを抜き出したViewを作る -
Cloud Run上に展開されたGrafanaがViewにSQLを投げ、ダッシュボードに表示する - 生データはGitHubのWebhook Eventである （※GitHubを使う場合）
- Parserでほんの若干だけデータ整形がされる
この記事ではGitHubのみを扱いますが、 ArgoCD, CircleCI, GitLab, etcなどからもデータを集めることができるようです。
設定方法
setup/README.mdに書かれてあります。
特に解説が必要なほど複雑なものはなく、ほんの15分ほどで作ることができました。
1. インフラ作成
README.md通りです。
１つ上げるなら、そのまま terraform を実行すると state管理はlocalになっているので、適切な場所に保管しましょう。
2. webhookの設定
GitHubからイベントを受け取れるように、GitHub側に設定します。
Payload URLには、Cloud Runにあるevent-handlerのURLを設定します。
Content-Typeはapplication/jsonです。
SecretにはSecret Managerにあるevent-handlerに設定された値を入力します。
終わりです。早い。
3. データを挿入する
GitHubリポジトリでいろんな操作をして、データを用意していきます。
雰囲気を見たいだけれあれば、data-generator/generate_date.pyを実行すると自動的にモックデータを入れてくれます。
それぞれのメトリクスに影響を与えるGitHub操作に関しては次に書いていきます。
dora-team/fourkeysで計測できるメトリクスの意味
それぞれのメトリクスの意味と、データの入れ方を書いていきます。
1. 変更のリードタイム系
Lead Time for Changes
意味
コミットを作成した時間 ~ deployment_statusがsuccessになるまでの時間 を日ごとにグルーピングし、中央値をグラフに打っている。単位はHour。
反映方法
- コミットする
- コミットに対してdeploymentを作成する
- deploymentのstatusを
successに変更する
気になる点
計算のためには理論上、すべてのコミットとdeploymentを紐付ける必要がある。
そのためには、マージコミットに対してdeploymentを生成すると良い（マージコミットのEventは変更コミットをすべて含むため）
ただし、マージコミット（変更のリードタイムがほぼノータイム）もSQLの計算対象になっていので、中央値でグラフを打つなら問題ないが、例えば平均値を出したい場合には注意。
Lead Time to Change Bucket
意味
過去3ヶ月のLead Time for Changesの中央値に対して、大まかに場合分けして傾向を表示
24時間以内: One Day
7日以内: One Week
30.4日以内: One Month
6ヶ月以内: Six Months
2. デプロイ頻度系
Daily Deployment
意味
deploymentのstatusがsuccessになった数をカウントし、日でグルーピングしてグラフを打つ
反映方法
Lead Time for Changes と同じ。
Deployment Frequency
意味
過去3ヶ月にわたり、deploymentのstatusがsuccessになった日（数ではない！）を判別して傾向を表示
週に3日以上: Elete Performance
週に1日以上: Weekly
月に1日以上: Monthly
それ以外: Yearly
3. 復旧時間系
Daily Median Time to Restore Services
意味
Incidentラベルを持つGitHub Issueのオープンからクローズまでの時間を、オープン日でグルーピングして中央値をグラフに打つ
反映方法
- GitHub Issueをオープンし、ラベルを
Incidentにする - ※本文に
root cause: ${commit hash}を書く
3. 復旧時間系メトリクスの計算には不要だが、後述の変更失敗率系メトリクスに必要。 - クローズする
気になる点
Issueがクローズした際に、オープン日のデータとしてグラフに反映されるので、直感と合わない（クローズ日のデータとして入れたい気がする）。
中央値を使うため、複数のIssueが同時にオープンした場合に中央値以外の計測データは見えなくなる。
例えば、以下の場合にグラフに表示されるのは ○月✗日 2hという情報で、27hかかったIssueはグラフ上見えないのでIssue解決は順調に見えることになる。
- IssueA: 1h クローズ
- IssueB: 2h クローズ
- IssueC: 27h クローズ
Median Time to Restore Services
意味
過去3ヶ月にわたり、↑のIssueクローズ時間の中央値を出し、傾向を表示
24h以内: One day
168h以内: One week
730h以内: One month
730*6h以内: Six months
それ以外: One year
4. 変更失敗率系
Daily Change Failure Rate
意味
日ごとに、「Incidentラベルを持つGitHub Issueがオープンした数 / デプロイ数」をグルーピング舌値をグラフに打つ
反映方法
これまでに述べた方法を行っていれば自ずと計算されている。
気になる点
100%の百分率ではなく、0~1である。
root cause: ${commit hash}に対して複数のIssueを開けば、割合が100%を超える場合がありうる
Change Failure Rate
過去3ヶ月にわたって先ほどの計算を行い、傾向を表示
<= 0.15: 0~15%
< 0.46: 16~45%
それ以外: 46%~
dora-team/fourkeysが良いなと思った点
1. お手軽すぎる
基盤作成までたったの15分でした。
OSSなので契約作業や振込手続きもないので、ぱっとFour Keysを取得する体制を作れるのは良いと思います。
2. カスタマイズ性が高い
OSSだからというのもあって、何でもできてカスタマイズ性が高いのが良いです。
市場に出ているものはカスタマイズができず、提供されているメトリクスの定義に従うしかない場合が多いためですね。（2023/08/04）
GrafanaのSQLやViewのSQLを少し変えれば自分たちが欲しいメトリクスを用意することも可能です。
複雑だったり、独自のフローを持っていたりする組織はFour Keysのメトリクスを独自に定義したいと思いますので、カスタマイズ性が刺さると思います。
GitHubのWebhook Eventを生データとしていますが、例えば自分たちでAPIとパーサーを開発すれば独自のデータ収集基盤を用意できます。
3. 安い
まともに比較はしていませんが、市場に出ているサブスク型Four Keys取得基盤より圧倒的に安いと思わます。ただし、後述しますがそのままでは使いにくいため開発コストがかかります。
※アーキテクチャや、内部でやっていることはそこまで複雑ではないので、保守コストは低いかもしれないです？
やや気になる点
1. デフォルトでは使いにくい
市場に売り出されているFour Keys計測ツール（有料）は、機能が豊富でぱっと使えて設定が不要だったりします。
一方このdora-team/fourkeysでは、Incidentラベルがついていてroot cause: ${commit hash}が書かれたIssueをオープンする必要があったり、GitHubのdeployment APIを呼ぶ必要があったりと、使い方に癖があります。
各組織で、デプロイフローや障害対応フローがあると思いますので、かみ合わせが難しいこともあるのではないでしょうか。
※もちろんカスタマイズ性が高いのでカスタマイズさえすれば使えますが。
また、デフォルトで用意されているメトリクスで良いのかどうかを吟味する必要があります。
そもそもFour Keysのそれぞれのメトリクスの定義は曖昧なので、組織内で明確に定義する必要があります。
組織にとっての、
- 変更のリードタイムとはなにか？
- デプロイ頻度とはなにか？
- 復旧時間とはなにか？
- 変更失敗率とはなにか？
を定義した上で、今dora-team/fourkeysで取っているメトリクスは意味があるのか？をしっかり考えていきたいところです。
2. 改善活動に繋げにくい
ダッシュボードから調査できないなぁと感じました。例えば、
- 変更のリードタイムの時間がかかっているけど、それはなぜか？
- 変更失敗率が高い日があるけど、何があったのか？
に対してまったく情報が紐づいていないです。
このあたりの紐づけを行い、Four Keysを開発するサイクルを回せるようなダッシュボードになるように自分たちで改良していく必要があると感じます。
3. リポジトリごとのメトリクスが取れない
リポジトリでフィルターできません。
大抵の組織はプロダクトごとにリポジトリが別れているはずで、プロダクトごとのFour Keysを取りたいと思うので、デフォルトのまま使っていくのは厳しいです。
ただ、GrafanaのVariable機能を使ったり、ViewのSQLを改変してリポジトリIDを入れるカラムを用意したりすればすぐに解決できそうではあります。
4. ダッシュボードの永続化がされていない
データはBigQueryで永続化されていますが、ダッシュボード設定の永続化が存在しないので、あらゆる設定変更がすぐに失われます。
例えば grafana.iniで databaseの設定を入れるなどして永続化する事が必要です。
5. セキュリティ
手順通りに作成した場合、ダッシュボードはパブリックです。全世界公開です。
ダッシュボードのパスワードもないので誰でもアクセスできますし、GrafanaからSQLも実行し放題です。
Grafanaには簡単に認証をかけることができるので、ドキュメントに従って簡単なパスワード認証でもいいのでかけていたほうが良いと思います。（永続化されないので注意。先に永続化を。）
さいごに
dora-team/fourkeys を使ってFour Keysを計測してみました。
用意自体は簡単でカスタマイズ性もあるのですが、そのままでは使いにくい印象でした。
- サードパーティーツールを購入するか
- dora-team/fourkeysを改造するか
- フルスクラッチか
このあたりをしっかり検討していきたいところですね。
dora-team/fourkeysはしばらく実験していくので、また何かあれば追加更新していきます。
気になる方はぜひ使ってみてください。使った感想コメントもお待ちしてます。
Discussion