今日のソフトウェアは、20年以上前のソフトウェアに比べて桁違いに複雑で、コードのトラブルシューティングに新たな課題をもたらしています。幸いなことに、オブザーバビリティをシステムに実装することで、当社ではアプリケーションのパフォーマンスや問題の発生箇所を把握することができています。
しかし、進化したのはソフトウェアだけではなく、それを作り、開発するプロセスも変化しています。そのため、DevOpsではCI/CDの概念が導入されました。デリバリーのサイクルが月単位から四半期単位に短縮され、現在では毎週あるいは1日に複数回リリースされるようになったため、ソフトウェア配信パイプライン全体で自動化が取り入れられています。
残念ながら、CI/CDパイプラインのオブザーバビリティは、アプリケーションソフトウェアに比べてあまり進歩していません。これらのパイプラインがソフトウェア配信プロセスのバックボーンであることを考えると、これは驚くべきことです。可視性がなく、何か問題が発生してソフトウェアを本番環境に導入できない場合、問題をどのようにトラブルシューティングすればよいでしょうか？
このブログで焦点を当てるのは、CI/CDパイプラインのオブザーバビリティです。最初にいくつかのことを定義し、次にパイプラインを監視できることが重要な理由と、パイプラインを監視可能にする方法について詳しく説明します。
主要コンセプト
以下に、知っておくべき定義をいくつか示します。
オブザーバビリティ
オブザーバビリティには複数の定義があるため、ここではNew Relicが考える o11yに絞ります。
オブザーバビリティ、つまりo11y（「オーリー」と発音します）は、システムの内部構造を知らなくても質問できるようにすることで、システムを外側から理解できるようにします。
つまり、システムの根底にあるビジネスロジックをすべて理解できなくても、パンくずリストをたどって「なぜこのようなことが起こるのか？」に答えるのに十分な情報がシステムから発せられるということです。ただし、システムが情報を発しなければ、オブザーバビリティを確保することはできません。その情報はどうやって入手するのでしょうか。ひとつの方法はOpenTelemetryを使うことです。
面白い事実：「o11y」の「11」は、「オブザーバビリティ」という単語の「o」と「y」の間の文字数を表します。
OpenTelemetry
OpenTelemetry（OTel）は、テレメトリデータを生成、収集、変換、エクスポートするためのオープンソースのオブザーバビリティフレームワークです。そのための一連のAPI、ソフトウェア開発キット（SDK）、インストゥルメンテーションライブラリ、ツールを提供しています。2019年に正式に開始されて以来、アプリケーションの計装とテレメトリの生成と収集のデファクトスタンダードとなり、eBayやSkyscannerなどの企業で使用されています。
その最大のメリットの1つは、ベンダーロックインから解放されることです。アプリケーションを一度計装すると、最適なバックエンドにテレメトリを送信できます。Collectorなどの非常に優れたツールも用意しています。
Collectorは、データを取り込み、変換し、1つまたは複数のオブザーバビリティバックエンドのエクスポートに使用されるベンダーニュートラルなサービスです。Collectorは、テレメトリにアクセスする4つの主要コンポーネントで構成されています。
- レシーバーは、アプリケーションコードからであれ、インフラからであれ、データを取り込みます。
- プロセッサはデータを変換します。プロセッサは、データの難読化、属性の追加、属性の削除、データのフィルタリングなどを行うことができます。
- エクスポーターは、データを選択したオブザーバビリティバックエンドと互換性のある形式に変換します。
- コネクターを使用すると、2つのパイプラインを接続することができます。
OTelコレクターはデータパイプラインと考えることができます。
CI/CDパイプライン
CI/CDは、次の2つの重要な実践を活用した、ソフトウェア配信の自動化アプローチです。
- 継続的インテグレーション（CI）とは、コードに変更が加えられるたびに、ソフトウェアをビルドし、パッケージングし、テストすることです。
- 継続的配信（CD）とは、ソフトウェアパッケージをすぐに本番環境にデプロイすることです。
自動化されたパイプラインは、新機能、バグ修正、一般的なアップデートをより迅速に顧客に提供できるため、製品の迅速なイテレーションが可能になります。手作業によるエラーのリスクがなくなり、開発者へのフィードバックループが標準化されます。
CI/CDパイプラインのオブザーバビリティが重要な理由
パイプラインが健全であれば、チームはコードを作成、構築、テストし、コードと設定の変更を本番環境に継続的にデプロイできます。また、開発の俊敏性を向上したり達成したりすることもできます。つまり、運用を変更し、その変更がアプリケーションの健全性にプラスの影響を与えたか、マイナスの影響を与えたかを把握するのにかかる時間を最小限に抑えることができます。
逆に、パイプラインが十分ではない場合、以下のような問題が発生する可能性があります。
- デプロイメントの遅延：バグの修正が、ユーザーの不満を抑制するのに十分な速さで行われず、問題が致命的になる可能性があります。
- テストの問題：テストが完了するのを待たなければならなかったり、異なる設定に対してテストする十分な時間がなかったりすると、デプロイメントが遅れ、ユーザーベース全体で十分なアプリケーションパフォーマンスを達成するのが困難になる可能性があります。
- 技術的負債：根本的な問題を特定することが困難な場合、技術的負債が発生する可能性があります。
パイプラインはDevOpsエンジニアの本番環境システム
パイプラインは外部ユーザーが扱う本番環境ではないかもしれませんが、ソフトウェアエンジニアやサイト信頼性エンジニア（SRE）などの内部ユーザーが扱う本番環境であることは間違いありません。本番環境を観察できるということは、次のことを意味します。
- コミットが本番環境に移行するまでの時間に影響を与える、不必要に長いサイクルタイム、つまり変更のリードタイムを防止する
- 新機能やバグ修正のプッシュアウトの遅延を軽減する
- ユーザーの待ち時間を短縮する
コードは失敗する可能性がある
CI/CDパイプラインは、その動作方法を定義するコードによって実行され、最善かつ細心の注意を払っても、コードが失敗する可能性があります。アプリケーションコードを監視可能にすることで、本番で問題が発生した際に、状況を理解するのに役立ちます。同様に、パイプラインを可視化すると、失敗したときに何が起こっているのかを理解することができます。
トラブルシューティングが容易に
監視可能なパイプラインを持つことは、次のような疑問に答えるのに役立ちます。
- 何が失敗したのか？
- なぜ失敗したのか？
- 以前にも失敗したことがあるのか？
- 最も頻繁に失敗したのは何か？
- パイプラインの通常のランタイムはどれくらいか？
- ボトルネックはあるか？ある場合、それは何なのか？
- パイプラインの問題を解決するリードタイムを短縮できるか？
どのような種類のデータを収集したいですか？
これらの質問に答えるには、パイプラインに関する情報を収集する必要があります。しかし、その情報はどのようなものであるべきでしょうか？次のようなものを取得します。
- Branch名
- コミットのハッシュ文字列（SHA）
- マシンIP
- 実行タイプ（スケジュール実行かマージ/プッシュなどによる手動実行）
- 失敗したステップ
- ステップの掛かった時間
- ビルド番号
パイプラインの監視方法
「なぜこのようなことが起こるのか？」という問いに答えるのに十分な情報を発するとき、システムは監視可能であることを思い出してください。まず、その情報を発信する手段が必要であり、次に、その情報を送る場所が必要であり、最後に、その情報を分析し修正すべき点を見つけ出す必要があります。
そこで登場するのがOpenTelemetryです。OpenTelemetryをシステムに実装すると、システムのオブザーバビリティを実現するために必要な情報を発信することができます。アプリケーションに使うように、CI/CDパイプラインにも使えます。生成されたテレメトリは、分析のためにNew Relicのようなバックエンドに送信する必要があります。
OpenTelemetryの使用
OpenTelemetryは、多くの人が既にアプリケーションに組み込んでいるため、CI/CDパイプラインの計装は非常に理にかなっています。ここ数年、採用と実装は着実に増えています。
New Relicの使用
New RelicでCI/CDパイプラインを監視する場合、次のような選択肢があります。
CircleCIのログをNew Relicに転送する
CI/CDログをNew Relicに送信するために、CircleCI Webhookサービスを設定することができます。
GitHub Actions Exporter
このエクスポーターを使ってGitHub Actionsをモニターすることで、CI/CDワークフローの健全性やパフォーマンスを簡単に把握することができます。GitHub Actionステップからログを取得し、トレースとスパンIDを追加してトレースと関連付けます。
エクスポーターでできることを以下に挙げます。
- ワークフロー/ジョブ/ステップにかかる時間や、失敗する頻度など、GitHub Actionsの主要なメトリクスを可視化します。
- ワークフロー/ジョブやステップを、コンテキスト内のログを含む分散トレースとして可視化し、New Relicを使ってOpenTelemetryサービスエンティティに報告します。
- ワークフローにおける問題の原因を突き止めます。
- ワークフローにアラートを作成します。
このツールは当社のフィールドチームによって開発され、実験リポジトリに格納されていることに注意してください。これは、コードが必ずしも本番で使われているわけではなく、オープンに開発されていることを意味します。併せて、お客様の貢献も有益です。
New Relicによる変更追跡機能
また、New RelicはChange Tracking (変更追跡機能)を提供しており、変更が顧客やシステムに与える影響をモニターすることができます。どの変更をモニターするかを指定し、その結果をNew Relicアカウントで確認します。これにより、リリースパイプライン中に環境に加えられた変更を追跡することができます。
この機能は、GitHub Actions（例はこちら）やJenkins（チュートリアルはこちら）を使って、UIで変更内容を表示・分析する方法を学ぶことができます。
他の選択肢はありますか？
現在のところ、これは少し複雑な状況ですが、あります。以下に挙げます。
- 商用のSaaS型監視ソリューション
- ベンダーが作成したツールを既存のCI/CDツールにプラグインすることで、CI/CDのオブザーバビリティを実現（Honeycomb buildeventsなど）
- CI/CDパイプラインでオブザーバビリティを可能にするGitHubの自作アクション（例はこちら、こちら、こちらを参照）
- OTel用の自作CircleCI Webhook
- OTel用の自作Drone CI Webhook
- JenkinsとTektonへのネイティブOpenTelemetryインテグレーション。
また、これらのツールをCI/CDパイプラインに統合することもできます。これらのツールはOpenTelemetryシグナルを発するので、パイプラインを監視可能にする上で役立ちます。
- MavenビルドOTel拡張機能は、Javaビルドの分散トレースを発行します。
- Ansible OpenTelemetryコールバックはAnsible Playbookをトレースします。
- DynatraceのJUnit Jupiter OpenTelemetry Extensionは、OpenTelemetry経由でJUnitテストの実行データを収集するためのGradleプラグインです。Mavenバージョンもあります。
- pytest-otelは実行されたPythonテストの分散トレースを記録します。
- otel-cliはGoで書かれたコマンドラインインターフェイス（CLI）ツールで、シェルスクリプトからトレースを出力することができます。
- ファイルログレシーバー（OTelコレクター）は、ファイルからのログを追跡し、解析します。
- Git Provider Receiver（OTelコレクター）はGitベンダーからデータをスクレイピングします。
監視可能なパイプラインの例
この図は、上記のいくつかのツールを使ってパイプラインオブザーバビリティを獲得する方法を示しています。Javaアプリケーションをビルドしてデプロイしているとしましょう。Jenkinsを使ってビルドとデプロイメントをオーケストレーションしています。
- Jenkins CI/CDパイプラインは、Jenkins OTelプラグインを介してテレメトリシグナルを送信できます。
- ビルドの段階で：
- Maven OTel拡張機能を使用すると、Javaビルドの分散トレースを作成できます。
- ビルドにシェルスクリプトが含まれている場合、otel-cliツールを使ってシェルスクリプトがトレースを出力できるようにすることができます。
- テスト段階では、Maven用のJUnit Jupiterプラグインを使えば、OpenTelemetry経由でJUnitテストの実行データを収集できます。
- パッケージングの段階で、アーティファクトを使用してアプリケーションをパッケージ化すると、ファイルログレシーバーを介してOTelコレクターにログを送信することができます。
- デプロイメントをオーケストレーションするためにAnsibleを使用するデプロイメント段階では、Ansible OpenTelemetryコールバックはAnsible Playbookにトレースを追加します。Ansible Playbookがシェルスクリプトも使用している場合、otel-cliツールを利用することで、シェルスクリプトが追加のトレースデータを出力できるようになります。
- さまざまなプラグインから発せられるシグナルは、OTelコレクターによって取り込まれます。データの取り込みには、テレメトリデータを取り込むための標準的なOTLPレシーバーと、Git Providerレシーバー、Filelogレシーバーを使用することができます。テレメトリシグナルは、コレクターによってオブザーバビリティバックエンドに送信されます。
- データがオブザーバビリティバックエンドに到着すると、データの表示とクエリ、アラートの設定などを行うことができます。
監視可能なパイプラインを実現するための課題
CI/CDパイプラインのオブザーバビリティを可能にするためにOpenTelemetryを使うことは理にかなっていますが、標準化が欠けており、ツール環境は整理されていません。
OpenTelemetryはほとんどのCI/CDツールには組み込まれていません。また、GitLabやGitHub ActionsのようなCI/CDツールにオブザーバビリティ機能を追加したいという要望もありますが、こうした取り組みは遅々として進んでいません。たとえば、OTelとのパイプラインのオブザーバビリティを求めるGitLabのリクエストに動きがありましたが、その項目は2年前から未解決のままです。CI/CDパイプラインのオブザーバビリティに関するOTelの提案は、2023年1月に開始されましたが、（2023年11月現在）2023年7月以降、活動は行われていません。
そのため、そのツールを使用したい場合は、独自のものを作る個人や組織のなすがままになります。これらのツールを今後メンテナンスしないことに決めた場合はどうなりますか？
詳細情報
CI/CDパイプラインを監視可能にすることで、より効果的にトラブルシューティングを行い、開発の俊敏性を実現し、内部構造に関する洞察を得ることができます。
健全なパイプラインとは、新しいコードを継続的に作成、構築、テストし、デプロイできることを意味します。逆に、不健全なパイプラインでは、デプロイメントの遅れ、テストの問題、技術的負債が発生する可能性があります。
OpenTelemetryを使って、パイプラインにオブザーバビリティを追加することができます。現時点では選択肢は限られていますが、事態は正しい方向に進んでおり、当社はCI/CDの未来を楽しみにしています。
さらに読む：
以下を試すこともできます。
- New RelicのCircleCIクイックスタート
- New RelicへのCircleCIログの転送
このブログ記事はThe New Stackに掲載されたものです。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
