今日から始める CI/CD Observability / CICD Observability for Google Cloud

Google Cloud Next Tokyo'25 Developer Stage の内容です。

https://googlecloudevents.com/next-tokyo/sessions?session_id=3123776

1. Proprietary 今日から始める CI/CD Observability
2. Proprietary 02 Google Cloud Next Tokyo Annosuke Yokoo Sales Engineer, Datadog Google Cloud Partner Top Engineer 2025 Fellow
3. Proprietary 03 Google Cloud Next Tokyo 今日話すこと ❏ CI/CD にもオブザーバビリティ の考えを適用しよう ❏ CI/CD でも 安全性 と 可視性 を意識しよう
4. Proprietary 04 Google Cloud Next Tokyo CI/CD にもオブザーバビリティの考えを適用しよう
5. “ オブザーバビリティ ” は運用フェーズだけではない tag-observability /whitepaper.md https://github.com/cncf/tag-observability/blob/main/whitepaper.md
6. “ オブザーバビリティ ” は運用フェーズだけではない tag-observability /whitepaper.md https://github.com/cncf/tag-observability/blob/main/whitepaper.md Observability（可観測性）は、システム開発ライフサイクルのあらゆるフェーズ で活用することができます。 新機能のテスト中、プロダクション環境のレジリエンスの監視、顧客がどのように製品を利用して いるかのインサイト取得、あるいは製品ロードマップに関するデータ主導の意思決定を行う際にも 利用可能です。 いずれかの目的が明確になれば、次に考えるべきは 「出力」、つまり私たちが 「シグナル」 と呼ん でいるものになります。
7. Development QA Staging Production Shifting left より開発初期段階の環境におけるテ ストとパイプラインにも可視性（可観 測性）をもたらす これまでは Prod だけで オブザーバビリティを考える オブザーバビリティのシフトレフト
8. Development QA Staging Production Shifting left より開発初期段階の環境における テストとパイプラインにも可視性 をもたらす これまでは Prod だけで オブザーバビリティを考える オブザーバビリティのシフトレフト “ 運用 ”だけでなく ” 開発 ”におけるオブザーバビリティ のシフトレフトを考えることで、より生産的かつ安全にソ フトウェアをデリバリーできる
9. 継続的な改善には、 CI/CD オブザーバビリティが重要 「計測による継続的な CI/CDの改善」より引用 https://speakerdeck.com/sansantech/20250514
10. Otel Community でも CI/CD Observability SIG が爆誕 「OpenTelemetry Is expanding into CI/CD observability」より引用 https://www.cncf.io/blog/2024/11/04/opentelemetry-is-expanding-into-ci-cd-observability/ 「CI/CD Observability SemanticConventions SIG」より引用 https://github.com/open-telemetry/community/blob/main/projects/ci-cd.md
11. Proprietary 011 Google Cloud Next Tokyo CI/CD でも 安全性 と 可視性 を意識しよう
12. CI における課題 🔑 CI の安全性 • CI Ops では すべての権限が CI に集中する ◦ 例えば Google Cloud へのデプロイの場合には、 Service Account の Key がすべての権限を持 つためセキュリティリスクが一定以上ある 📈 CI の可視性 • コードが大規模になり、 CI の Job が増えて、Pipeline が複雑化すると所用時間長い、 CI エラーの根本原 因か不明 ◦ 各 Step の所要時間を把握しづらい（ or 出来ない） • CI の実行時間の肥大化はエンジニアの生産性の低下につながる ◦ CI の待ち時間が絶妙に何も出来ない時間となる ...コーヒーブレイク ☕ / 雑談 🗣 / 休憩 😴
13. CI における課題 🔑 CI の安全性 • CI Ops では すべての権限が CI に集中する ◦ 例えば Google Cloud へのデプロイの場合には、 Service Account の Key がすべての権限を持 つためセキュリティリスクが一定以上ある 📈 CI の可視性 • コードが大規模になり、 CI の Job が増えて、Pipeline が複雑化すると所用時間長い、 CI エラーの根本原 因か不明 ◦ 各 Step の所要時間を把握しづらい（ or 出来ない） • CI の実行時間の肥大化はエンジニアの生産性の低下につながる ◦ CI の待ち時間が絶妙に何も出来ない時間となる ...コーヒーブレイク ☕ / 雑談 🗣 / 休憩 😴 ▶ CI には 安全性 と可視性 を担保する仕組みが必要
14. Workload Identity 「Workload Identity Federation とは何ですか ?」より引用 https://www.youtube.com/watch?v=4vajaXzHN08 安全性 Workload Identity • OIDC ( OpenID Connect ) を用いて期限付きのトークンを発行 することで、セキュアに認証と認可の両方を行い、外部 ID に対し て任意のサービスアカウントになりすますことができるロールを付 与する仕組み • Cloud Run や GKE などのワークロードと統合されたものも存在 する • アプリケーションや外部サービスが Google Cloud のリソースに アクセスする場合に使用可能 2 種類の認証方法が存在する • Direct Workload Identity Federation • Workload Identity Federation through a Service Account
15. Direct Workload Identity Federation 「Github google-github-actions / auth」より引用 https://github.com/google-github-actions/auth 安全性 • Workload Identity Pool が Google Cloud リソースに対して直 接 IAM Permission を持つため、 Service Account（SA） を使用 せずに直接認証可能 • SA は組織ポリシーによっては Key を発行できてしまったり、権限 次第では意図しないリソースで利用される可能性もありため、使 用しないことでセキュリティリスクの削減につながる • Github Actions では google-github-actions / auth が提供され ている
16. CI における課題 🔑 CI の安全性 • CI Ops では すべての権限が CI に集中する ◦ 例えば Google Cloud へのデプロイの場合には、 Service Account の Key がすべての権限を持 つためセキュリティリスクが一定以上ある 📈 CI の可視性 • コードが大規模になり、 CI の Job が増えて、Pipeline が複雑化すると所用時間長い、 CI エラーの根本原 因か不明 ◦ 各 Step の所要時間を把握しづらい（ or 出来ない） • CI の実行時間の肥大化はエンジニアの生産性の低下につながる ◦ CI の待ち時間が絶妙に何も出来ない時間となる ...コーヒーブレイク ☕ / 雑談 🗣 / 休憩 😴 ▶ CI には 安全性 と可視性 を担保する仕組みが必要 再掲
17. CI ツールにもモニタリング View はあるけど ... 可視性 • どの CI ツールでも Job の実行時間やログは大体見れる • 知りたいのは、実行時間/エラーのボトルネックがどこにあり、どのよう に改善できそうかという可視化された情報 • 継続的改善につなげられる相関性のある連続的な情報
18. CI ツールにもモニタリング View はあるけど ... 可視性 • どの CI ツールでも Job の実行時間やログは大体見れる • 知りたいのは、実行時間/エラーのボトルネックがどこにあり、どのよう に改善できそうかという可視化された情報 ▶ トレースの需要 • 継続的改善につなげられる相関性のある連続的な情報 ▶ テレメトリーシグナル（ ログ、トレース、メトリクス） の収集による多 角的アプローチ
19. github-actions-opentelemetry 可視性 • GitHub Actions のワークフロー・ジョブ・ステップの結果を収 集し、OpenTelemetry Protocol（OTLP）エンドポイントに送信 する仕組みを提供する Actions • トレースとメトリクスの形で収集し、任意の OTLP バックエンド を通して、CI の各ステップを可視化 • 既存のワークフローにほとんど手を加えることなく使用可能 「paper2 / github-actions-opentelemetry」より引用 https://github.com/google-github-actions/auth
20. テレメトリーシグナルの収集 可視性 • Cloud Trace は OTLP エンドポイントに対応してい る （最近では、Telemetry API もリリースした） • トレースは Cloud Trace から、メトリクスはGMP を 通じて、Metrics Explorer から確認可能 • CI/CD における可視性（可観測性）は収集して終わ りではなく、継続的改善 へと繋げることが重要
21. Datadog - CI Visibility • 内容 「Continuous Integration Visibility」より引用 https://docs.datadoghq.com/continuous_integration/ 可視性
22. 各 Step の Trace を Flame Graph で表示 • Job は並列実行されることが多いため、依存関係が明確化 クリティカルパス（Critical Path）の特定 • 依存関係により順番に実行されるステップ • 最も長くかかる経路 Exclusive Time（排他時間） の特定 • パイプラインの完了をそのステップだけがブロックしている時間 CI の実行時間を短縮するにはクリティカルパス上の Job の実行時間を 短縮する必要がある ▶ ビルドキャッシュ使用 ▶ ビルドアーティファクト / テストの再使用 ▶ Job の並列化 / 順序変更 クリティカルパ スを特定 Log との相関 Exclusive Time Datadog - CI Visibility 可視性
23. otel-cicd-action 「corentinmusard / otel-cicd-action」より引用 https://github.com/corentinmusard/otel-cicd-action 可視性
24. Proprietary 024 Google Cloud Next Tokyo まとめ ❏ CI/CD にもオブザーバビリティ の考えを適用しよう ▶ オブザーバビリティのシフトレフト ❏ CI/CD でも 安全性 と 可視性 を意識しよう ▶ Workload Identity で 安全性 を高め、 テレメトリーシグナルを可視化するプロダクト で 可視性 を高める
25. Proprietary 025 Google Cloud Next Tokyo Thank you 👋
26. Proprietary 026 Google Cloud Next Tokyo Ask the Expert にぜひお越しください Google Cloud に関する技術的なご質問に GDE（ Google Developers Experts ）がお答えします！ Stage Ask the Expert 本ステージの後方にございますので、 ぜひお立ち寄りくださいませ！