オブザーバビリティのスタートはアプリケーションやインフラストラクチャの状態の可視化から、というのが一般的ですが、更に広げるとDevOpsの中のCI/CDサイクル自体も可視化・分析する事が可能です。Jenkinsに代表されるCI/CDツールも一つのシステムですので、データを取得し可視化や分析ができます。SplunkではJenkins用のインテグレーションを用意しており、Open Telemetry Collectorによるデータの取得とSplunk Observability Cloudに用意されたダッシュボードの利用で、誰でも簡単にCI/CDサイクル内に何が起きているかを明確にすることが可能になります。そして、そのJenkinsに対する高いオブザーバビリティはCI/CDサイクル自体の改善にもつながる重要なインサイトを与えてくれることになるでしょう。
クラウドネイティブな時代において、システムは常に変化し成長し続けるものですが、その変化や成長を支えるのがCI/CDのサイクルとも言えます。その意味においては、CI/CDサイクルの健全性を把握し、改善につなげられるようにする事は開発の効率性の向上にもつながる非常に重要な事だと考えられます。
以下「Jenkins, OpenTelemetry, Observability」の抄訳になりますが、これからDevOpsを計画しCI/CDツールを検討される日本のお客様にも役に立つ内容になっています。ぜひSplunk Observability Cloudでの高いオブザーバビリティがあるCI/CD環境を構築できるようご検討ください。
今日、多くの組織がJenkinsを使用しています。その用途は、デプロイのパイプライン構築から、APIの自動テスト、cronジョブの代替まで、多岐にわたります。
Jenkins(ジェンキンス)とは？
Jenkins(ジェンキンス)とは、Javaで作られているオープンソースのCI (継続的インテグレーション(CI)や継続的デリバリー(CD))ツールです。プラグイン機能が充実していることが特徴のひとつです。現在のところ2000近くのプラグインが提供されています。また、Jenkinsは汎用性が非常に高いことから、今後に期待されるCIツールです。
Jenkinsは、「ソフトウェアのリリーススピードの向上」「開発プロセスの自動化」「開発コストの削減」といった目的とするオープンソースのツールです。現在、プロジェクトはLinux Foundationによって管理されています。
さまざまなタイプのパイプラインからインサイトを得る方法
- ビルドログ：監査やトラブルシューティングに役立ちます。ただし、メトリクスの長期的な傾向を把握することはできません。
- 時系列メトリクス：Jenkinsインスタンスの健全性を監視し、長期にわたる問題を特定することができます。ただし、カーディナリティが高いため、特定のジョブやジョブのステップに関するデータを収集するのには不向きです。
- トレーシング/APM：まだあまり一般的なアプローチではありませんが、個々の実行やステップに関する詳細なウォーターフォール図が提供され、結果と各ステップのデータを一目で確認できます。ビルドログの詳細な情報と時系列メトリクスの長期的な視点の両方の利点が得られます。
現在のJenkinsでのトレーシングとAPMは、OpenTelemetryプロジェクトの取り組みとOpenTelemetry Jenkinsプラグイン(保守管理者：Cyrille Le Clerc氏)の登場によってかなり容易になっています。設定が完了すれば、Jenkinsジョブからワンクリックで、パイプライン全体の実行状況を示す詳細なウォーターフォール図を表示できます。
JenkinsからAPMデータを収集するメリット
OpenTelemetry (OTEL)、Jenkins、Splunk APMの能力を組み合わせれば、粒度の高い分散トレーシングを実現して、以前は把握が難しかったJenkinsの使用状況を詳細に監視すると同時に、データをフル活用できます。
ビルドの待ち時間が許容範囲を超えている：
Jenkinsで処理時間が異常に長いビルドやステップをすばやく特定できます。
組織全体でパイプラインの実行時間が少しずつ長くなっている：
JenkinsのAPMデータをSplunk Log Observer経由で送信すれば、データがAPMの対象期間を過ぎた後でも、すべてのステップの時系列メトリクスを生成して、すべてのジョブの個々のステップにかかった処理時間の増減を簡単に可視化できます。
外部サービスの呼び出しに平均以上に時間がかかる：
gitのチェックアウトに平均以上の時間がかかっているか、特定のAPIのレスポンスタイムが徐々に長くなっている可能性があります。Splunk APMのTag Spotlightを使用すれば、パイプライン内での外部サービスの呼び出しにかかる時間をP50、P90、P99値で可視化して、時間がかかっている処理を特定できます。
他のチームのビルドが自身の管理するサービスに影響しているかどうかを知りたい：
デプロイにディテクターを設定して、ダッシュボードでイベントマーカーを表示すれば、他のチームのデプロイが自身のサービスのパフォーマンスに影響しているかどうかをすばやく確認できます。
APMや分散トレーシングは、特定のプロセス(この場合はJenkinsデプロイ)のライフサイクル全体を通じて処理の流れを把握するための強力なツールです。Jenkinsデプロイの各ステップにかかった時間が一目でわかるウォーターフォール図を参照できるだけでなく、より一般的な時系列メトリクスや従来のビルドログに取り込むことのできる追加データも提供されます。Jenkinsのトレースデータを次のような新しい方法で活用すれば、組織内のさまざまなチームが問題を解決できます。
- IT運用/サポートアナリスト：IT運用チームのメンバーやリーダーは、重要なサービスに関する最新のビルド情報を取得して、最近のデプロイがサービス障害の直接的または間接的な原因になっていないかどうかをソフトウェアチームに伝えることができます。
- DevOps/SRE：DevOpsまたはSREチームのメンバーやリーダーは、サービスの健全性を維持し、問題がある場合は迅速に原因を追跡する責任があります。アプリケーションやインフラのデプロイによって起きる問題を可視化して関係者に報告できれば、ソフトウェアの開発やデプロイプロセスを改善して全体のMTTD短縮につなげることができます。
- ソフトウェア開発：ソフトウェア開発チームのメンバーやリーダーは、自身が開発したソフトウェアや上流サービスのデプロイによって問題が起きていないかどうかを、顧客に影響が及ぶ前に把握できます。UIが異なる複数のツールを頻繁に切り替える必要もありません。
- CI/CD：CI/CD (継続的インテグレーション/継続的デリバリー)ソリューションを管理するチームのメンバーやリーダーは、CI/CDパイプラインのパフォーマンスが低下している箇所と原因をすばやく突き止め、問題への最適な対処方法を特定して、DevOps、SRE、ソフトウェア開発チームに提供するCI/CDサービスを改善できます。
Splunk APMなら、ツールが増加してもJenkinsに関するこれらの課題に1カ所からすばやく対応できます。複数のツールの異なるインターフェイスを行き来することなく、Jenkinsやログを管理し、データを監視して、状況を正確に把握することができます。
セットアップ：すばやくJenkinsを開始する方法
すばやくセットアップするには、GitHubリポジトリでOpenTelemetry Collectorの設定例、ドキュメント、2つのSplunk Observability Cloudダッシュボードのエクスポートを確認してください。これらのアーティファクトとOpenTelemetry Collectorを導入すれば、Jenkinsに関する詳細なインサイトをすぐに取得して、IT運用、CI/CD、DevOpsに役立てることができます。
図1-1.JenkinsのAPMデータから取得したJenkinsパイプラインの詳細なメトリクス
すぐに使えるJenkinsダッシュボード
こちらのGitHubリポジトリには、個々のJenkinsパイプラインとJenkins全体の健全性を把握するための2つのダッシュボードが用意されています。これをそのまま使用することも、カスタマイズしてより詳細なデプロイダッシュボードを作成することもできます。
このGitHubリポジトリには、デプロイの失敗を通知するようにディテクターを設定するための手順とSignalFlowの例も記載されています。このタイプのディテクターは、デプロイ自体の問題だけでなく、デプロイの失敗(または成功)によって発生した上流の依存サービスの問題を検出するためにも役立ちます。関連するイベントをダッシュボードに表示することで、ツールを新たに導入しなくても詳細なコンテキストを取得できます。
他の方法でこれだけのインサイトを取得するのは容易ではありません。
図1-2.Jenkins全体の健全性：Jenkinsの重要エージェント、ビルドキュー、ステップの詳細メトリクス(Log Observer経由)を1つの画面で監視
Jenkinsの今後の展望
OpenTelemetry、APM、Infrastructure Monitoringは一体であり、ツールとして現状は別々であっても、サービスの状況を把握するためにはいずれも欠かせません。それぞれの能力を1つのツールに統合すれば、デプロイの影響やJenkinsのパフォーマンスをすばやく把握し、ソフトウェアのビルドやリリースが原因で発生したサービスの問題を各チームに迅速に伝えることができます。しかも、それだけではありません。Jenkinsについてより多くのインサイトを取得できれば、メトリクスに基づいて、組織のDevOpsプロセス全体に対する影響をより正確に把握することもできます。
JenkinsとDORAがDevOpsにもたらす効果
DORA (DevOps Research and Assessment)メトリクスは、DevOpsのアクティビティやパフォーマンスの測定に関する基本的なニーズに対応します。Jenkinsの追加コンテキストが有用または必要な場合のDORA関連の重要なメトリクスには以下の4つがあります。
- デプロイの頻度：Jenkinsでコードをどのくらいの頻度でデプロイしているか、皆さんは把握しているでしょうか。すでにある程度の手間をかけてこのデータを収集し、レポートを作成しているかもしれません。Jenkinsから送られるAPMデータやLog Observerデータを活用すれば、デプロイ頻度を組織、チーム、サービスごとにグラフにまとめたダッシュボードを作成できます。
- 変更の失敗率：デプロイの頻度と密接に関係するのが変更の失敗率です。エラー率のような一般的な監視メトリクスと同様に、JenkinsのAPMデータを活用すれば、組織の複雑さに関係なく変更の失敗率をすばやく可視化できます。このメトリクスは特に、ソフトウェアのデリバリーとデプロイの改善につながるDevOps作業の特定と優先順位付けに役立ちます。
- 変更の平均リードタイム：チケット発行から本番環境への最終デプロイまで、変更リクエストを受けたときのデプロイ全体にかかる時間は、デプロイの状況を理解するために重要な指標の1つです。Observability Cloudで得られる新しいJenkinsデータと、JiraやGitHubなどのソフトウェアから得られるいくつかの追加のシグナルを組み合わせれば、チケット発行から開発、デプロイまでの流れを追跡して状況を適切に把握できます。
- 復旧時間：最後にもう1つ、オブザーバビリティに直接に関係する重要なDORAメトリクスが平均復旧時間(MTTR)です。MTTRを把握するには、破壊的変更を伴うデプロイがいつ行われ、本番環境にいつ修正が最終デプロイされたかがわかるJenkinsメトリクスが必要です。
次のステップ
新しいJenkinsメトリクスとAPMデータをもっと活用して、パイプラインの状況を正確に把握し、デプロイを評価して、組織全体でDevOps Magic™を最大限に引き出しましょう！
Jenkinsデプロイの監視能力を短期間で高めたいなら、Splunk Observability Cloud製品スイートの無料トライアルをぜひお試しください。
このブログ記事はSplunkのオブザーバビリティフィールドソリューションエンジニアであるJeremy Hicksが執筆しました。ご協力いただいた以下の同僚に感謝申し上げます(敬称略)：Doug Erkkila、Adam Schalock、Todd DeCapua、Tom Martin、Marie Duran、Joel Schoenberg
