生成AIは、ソフトウェアの開発、保護、運用を容易にし、ソフトウェア開発業界に重要な変化をもたらしています。GitLabの製品チームとエンジニアリングチームが手掛ける新しいブログシリーズでは、企業全体に統合すべきAI機能をどのように作成、テスト、そしてデプロイするか明らかにし、DevSecOpsチームがよりよいソフトウェアを顧客に届ける上で、GitLab Duoの新機能がどのように役立つのかご理解いただける内容になっています。
CI/CDパイプラインがエラーを起こして、その根本原因を突き止めるために、やむを得ずDevSecOpsワークフローを停止したり、ソフトウェアのデプロイを遅らせたりした経験はありませんか？従来のアプローチでは、ソフトウェア開発で問題が発生した場合、デベロッパーはトラブルシューティングやログファイルの分析を行い、多くの場合で、試行錯誤を繰り返しながら開発を進める必要があります。GitLab Duo根本原因分析はGitLabの一連のAI搭載機能に含まれるもので、類推に頼ることなくCI/CDパイプラインで発生した失敗の根本原因を特定します。この記事では、根本原因分析について、また、GitLab DuoのAI搭載機能をDevSecOpsワークフローに適用する方法についてご説明します。
デモ動画公開！GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか？（今すぐ登録する）
根本原因分析とは？
GitLab Duoの根本原因分析は、ログを分析してCI/CDジョブログにおける失敗の根本原因を特定し、修正方法を提案してくれるAI搭載機能です。
根本原因分析はソフトウェア開発のインシデント管理によく用いられますが、そのワークフローやデバッグの手法はあらゆるDevSecOpsワークフローにも活用されています。パイプラインの失敗を調査する際、運用チーム、管理者、そしてプラットフォームエンジニアは、Infrastructure as Code（IaC）のデプロイエラー、KubernetesやGitOpsの問題、そして長いスタックトレースなどに対処しなければなりません。
GitLab Duoの根本原因分析は、全員を同じインターフェイスに集め、AIを活用して要約、分析、修正提案を行うことで、組織がより迅速に安全なソフトウェアをリリースできるように支援します。
パイプラインの失敗の原因としては、コードの構文エラー、パイプラインに使用される依存関係の欠落、ビルドプロセスにおけるテストの失敗、KubernetesやIaCのデプロイタイムアウト、その他多くの問題が考えられます。そのような失敗が発生した場合、関係者全員が、パイプラインで生成されたログを慎重に確認する必要があります。こうしたログの確認には、詳細な出力情報を精査してエラーを特定し、パイプラインにおける失敗の根本原因を特定したりする作業が伴います。たとえば、次のパイプラインには、調査と修正が必要なジョブの失敗が複数あります。
こうした失敗の修正に要する時間は、次のような要因によって大きく異なります。
- プロジェクトに関するデベロッパーの熟知度
- 同様の問題の対処に関するデベロッパーの経験値
- パイプラインにおけるトラブルシューティングと問題解決に関するデベロッパーの全体的なスキルレベル
手動での分析は非常に困難で時間がかかることがあります。これは、ログデータを構成するアプリケーションログとシステムメッセージに、さまざまな失敗の原因が含まれている可能性があるためです。一般的なパイプライン修正のプロセスでは、複数回にわたるイテレーションや、（作業を行ったり来たりすることによる）頭の切り替えが必要になります。ログの複雑さや非構造的な性質に対しては、生成AIを使うことで作業を高速化できます。AIを活用することで、パイプラインのエラーを特定して修正する時間を大幅に短縮でき、上記のようなパイプラインを修正するために必要な専門知識のハードルも下げられます。
以下の動画で、実際にGitLab Duoの根本原因分析を使用する流れをご覧ください。
根本原因分析の仕組み
根本原因分析は、CI/CDジョブログの一部をGitLab AIゲートウェイに転送することで機能します。GitLabでは、転送される内容が大規模言語モデル（LLM）のトークン制限内に収まるように調整されます。また、ジョブの失敗原因に関する洞察を提供するよう指示する既定のプロンプトも併せて送信されます。また、このプロンプトは、破損したジョブの修正方法の例をユーザーに提示するよう、LLMに指示します。
ここでは、根本原因分析を活用できるシナリオの例を2つご紹介します。
1. Pythonの依存関係エラーを分析する
Pythonのアプリケーションでは、標準ライブラリには備わっていない機能を含むパッケージモジュールをインポートできます。プロジェクト「Challenge - Root Cause Analysis - Python Config（演習 - 根本原因分析 - Pythonの構成）」では、構成の解析とSQLiteデータベースの初期化を実行するアプリケーションが実装されており、いずれも依存関係なしで正常に動作しています。また、このプロジェクトでは、Python環境とキャッシュを用いて、CI/CDのベストプラクティスを採用しています。最新の機能追加でRedisのキャッシュクライアントが導入されましたが、これを機にCI/CDビルドが何らかの理由で失敗するようになりました。
根本原因分析を使用すれば、ModuleNotFoundErrorテキストの内容が、モジュールが実際にはPython環境にインストールされていないことを意味しているとすぐにわかります。また、GitLab Duoによって「PIPパッケージマネージャーを介してRedisモジュールをインストールする」ことが修正方法として提案されます。
失敗しているパイプラインはこちらでご確認いただけます。
根本原因分析のプロンプトに問題のサマリーが表示されており、redisモジュールが欠落していることが問題のようです。では、redisモジュールをインストールして問題を解決できるか試してみましょう。CI/CDジョブのスクリプトセクションでpip install redisを呼び出すか、requirements.txtファイルを使用した、より高度なアプローチも選択できます。後者の方法は、開発環境とCI/CDパイプラインにインストールされている依存関係に関連した信頼できる唯一の情報源を確立するのに有効です。
test:
extends: [.python-req]
stage: test
before_script:
# [🦊] hint: Root cause analysis.
# Solution 1: Install redis using pip
- pip install redis
# Solution 2: Add redis to requirements.txt, use pip
- pip install -r requirements.txt
script:
- python src/main.py
欠落しているPythonの依存関係を修正した後、CI/CDジョブが再び失敗します。根本原因分析をもう一度使用すると、ジョブでRedisサービスが実行されていないことがわかります。GitLab Duoチャットに切り替え、How to start a Redis service in CI/CD（CI/CDでRedisサービスを開始する方法）というプロンプトを使用して、CI/CDジョブでservices属性を構成する方法を確認します。
.gitlab-ci.ymlをtestジョブで修正し、redisサービスを指定します。
test:
extends: [.python-req]
stage: test
before_script:
# [🦊] hint: Root cause analysis.
# Solution 1: Install redis using pip
- pip install redis
# Solution 2: Add redis to requirements.txt, use pip
- pip install -r requirements.txt
script:
- python src/main.py
# Solution 3 - Running Redis
services:
- redis
Redisサーバーを実行すると、Pythonアプリケーションを正常に実行し、その出力をCI/CDジョブログに出力できます。
この解決策は、solution/ ディレクトリで確認できます。
ヒント：以下のようなプロンプトを使用して、GitLab Duoチャットに発生リスクのある問題のフォローアップを依頼することもできます。
How to lint Python code? Which tools are recommended for CI/CD.
How to pin a package version in Python requirements file?
What are possible ways that this exception stacktrace is triggered in the future?
Are there ways to prevent the application from failing?
次の例はより高度で、複数の失敗が含まれています。
2. 不足しているGoランタイムを分析する
CI/CDジョブは、指定されたイメージから生成されたコンテナ内で実行できます。コンテナがプログラミング言語のランタイムを提供していない場合、goバイナリを参照する実行スクリプトセクションは失敗します。たとえば、/ bin/sh: eval: line 149: go: not foundというエラーメッセージが表示されたら、これを理解して修正する必要があります。
コンテナ内でgoコマンドが見つからない場合、以下のような複数の理由が考えられます。
- ジョブが最小限のコンテナイメージ（
alpineなど）を使用しており、Go言語ランタイムがインストールされていない。 - ジョブが誤ったデフォルトのコンテナイメージを使用している。これには、CI/CD構成の先頭で指定されたイメージや
defaultキーワードを使用して指定されたイメージなどが該当する。 - ジョブがコンテナイメージではなく、Shell executorで実行されている。ホストのオペレーティングシステムにGo言語ランタイムがインストールされていない、または設定が壊れているか正しく構成されていない。
プロジェクト「Challenge - Root Cause Analysis - Go GitLab Release Fetcher（演習 - 根本原因分析 - GoのGitLabリリースフェッチャー）」は、Goで構築されたGitLabリリースフェッチャーアプリケーションのCI/CD問題を分析し、修正するための演習課題です。このプロジェクトでは、buildとdocker-buildのCI/CDジョブが失敗しています。この問題を解決するには、2つのポイントを抑える必要があります。ひとつはGoランタイムがインストールされていない理由を理解すること、もうひとつはDockerfile構文について学ぶことです。
solution/ ディレクトリでは、根本原因分析の次に試す2つの解決策が確認できます。
根本原因分析の練習
以下のシナリオを想定して、根本原因分析を練習してみましょう。
-
Kubernetesデプロイメントのエラーやタイムアウトが発生した場合。
-
OpenTofuやTerraformのIaCパイプラインがクラウドリソースのプロビジョニングに失敗した場合。
-
AnsibleプレイブックがCI/CDで不可解な権限エラーで失敗した場合。
-
Javaのスタックトレースが10ページにも及ぶ場合。
-
シェルスクリプトが実行エラーを示している場合。
-
Perlスクリプトが1行（スクリプト内の唯一の行）で失敗した場合。
-
CI/CDジョブがタイムアウトし、どの部分が原因なのか不明な場合。
-
ネットワーク接続のタイムアウトが発生し、DNSが原因でないと思われる場合。
GitLab Duoの根本原因分析の次のステップ
GitLabは、最小限のイテレーションでパイプラインの問題を修正できるようユーザーを支援したいと考えています。根本原因分析が目指す次のステップでは、根本原因分析はGitLab Duoチャット（AIアシスタント）で結果を表示します。ユーザーは、提案された内容を基に、さらに具体的な質問（例：プログラミング言語に特化した修正方法を尋ねる）をしたり、根本原因に基づいた代替の修正方法を尋ねたりすることで、より正確な修正方法を確立できます。
たとえば、失敗したジョブの根本原因分析は次のとおりです。
ユーザーは、AIが生成した回答に対し、掘り下げた質問ができます。
-
独自のDockerイメージを作成したくありません。問題を解決するための別の方法を説明してください。
-
Dockerイメージの作成にアクセスできません。Goバイナリが見つからないようです。代替のイメージを提案できますか？
GitLabでは、生成された回答の品質ベンチマークを実行し、使いやすさの改善も行います。
詳しくは、根本原因分析の一般提供（GA）エピックをご参照ください。機能に関するフィードバックをお寄せいただける方は、根本原因分析のフィードバック用イシューにコメントを投稿してください。
根本原因分析を開始する
GitLab Ultimateプランで利用可能な機能を有効化する方法を説明するGitLabドキュメントをご参照ください。また、GitLab Duoの根本原因分析は、GitLab Self-ManagedとGitLab Dedicatedでまもなく利用可能になります。
GitLab Ultimateをご利用でない場合は、30日間無料トライアルを今すぐ開始していただけます。
監修：佐々木 直晴 @naosasaki （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）
