こんにちは、QAエンジニアのカンパチロックです。
今回は、テストフェーズにおいてQAの価値を向上させる方法の1つとして、分散トレーシングおよびその標準規格であるOpenTelemetryについて説明します。これにより、システム内で発生する問題をより迅速かつ正確に特定し、開発プロセスをより迅速かつ効率的に進めることができます。
分散トレーシングとは
まず、分散トレーシングにという用語について皆さん聞いたことはありますでしょうか？
商用の製品としては、Dynatrace、NewRelic、DatadogなどのAPM（Application Performance Management）製品に実装されている為、こちらの名前を聞いた事がある方もいらっしゃるかもしれません。
分散トレーシングの概要は、ユーザーからのリクエストに伴う様々なサービス呼び出しやデータストアへのアクセスなど、一連の処理（トランザクション）をパラメータやログと組み合わせて追跡・管理することです。これにより、従来のログ管理では分析に時間がかかる問題の原因を特定するプロセスが劇的に高速化されます。分散トレーシングの利点は、まさにこの迅速な問題解決能力にあります。
特にマイクロサービス環境下では、多くのサービスが複雑な関係性を持って連携しており、問題発生時に、問題の発生元となるサービスの特定に多くの時間を要するリスクがあり、その対策としての分散トレーシングの導入についても注目されております。
分散トレーシングのOSSとして有名なJeagerのサイトでは、分散トレーシングで収集したデータの可視化イメージとして下記のようなイメージが掲載されています。
左側のグラフのように、取得したデータからサービス間の連携状況を可視化したり、右側のウォータフォールチャートのように、ユーザのリクエストから発生する一連の処理について、どのサービスでどの程度の時間が掛かっているかや、処理実施時のパラメータ情報やエラー発生時のエラーログなどをトランザクション毎に確認できることができます。これらの可視化機能により、システム全体のパフォーマンスや問題の特定が容易になります。
引用元: https://www.jaegertracing.io/docs/1.33/architecture/#span
詳細については、以下のサイトで説明されていますので、ご参照下さい。
分散トレーシングとは メリット、仕組みなどを解説 | Splunk
OpenTelemetryについて
ここからは、より具体的な内容として、OpenTelemetryについて説明します。
OpenTelemetryは、分散トレーシングの共通規格を提供するプロジェクトで、2019年にそれまで別々の規格であったが統合されて誕生しました。これにより、分散トレーシングの標準化が一層進んでいます。
分散トレーシングにおいて、ベンダーロックインが課題となっていました。これは、別のAPM製品に乗り換える際に、新しいAPM製品に合わせたエージェントの再配置やソースコードの修正が必要だったためです。しかし現在、多くのAPM製品がOpenTelemetry規格に対応しているため、APM製品の乗り換え時のインパクトが大幅に軽減されています。極端な例として、接続先サービスの切り替えのみで乗り換えが完了するケースもあります。
今後、分散トレーシングを導入する際には、標準規格であるOpenTelemetryについて理解を深めることが重要であると考えられます。これにより、より効率的なトレーシングシステムの構築や、さまざまなAPM製品との互換性が向上し、将来的な拡張性も確保されます。
OpenTelemetryで出来ること
OpenTelemetryでは、主要な取得情報としてTrace、Metrics、Logの3要素があります。言語ごとに対応状況は異なりますが、以下にそれぞれの要素について簡単に説明します。
- Trace：ユーザのリクエストを起因とした各種サービスでの処理内容や処理時間を記録したもの
- Metrics：サービス実行時の各種統計情報（サービスの実行回数やレスポンスの平均値など）
- Log：サービスで発生したイベントを記録したもの（Traceと紐付け可能）
詳細については、OpenTelemetryのSignalsドキュメントを参照してください。
なお、大規模なアクセスが想定されるサービスの分散トレーシングにおいて、全てのリクエスト情報を取得・保存すると、分散トレーシングの仕組み自体が負荷のボトルネックとなる可能性があります。そのため、一般的には取得・保存するリクエストをサンプリングします。ただし、サンプリングされたTrace情報からは全体の統計情報を取得できないため、別途Metrics機能が提供されています。
OpenTelemetryでは、将来的にProfilingのサポートを追加することが計画されており、コードベースでの実行機能や処理時間をより詳細に取得できるようになる可能性があります。
https://github.com/open-telemetry/oteps/issues/139
OpenTelemetry規格とは別に、Apache SkyWalkingのような一部のAPM製品では、すでにプロファイル情報をトレーシングの一部として組み込む機能が実装されています。
SkyWalking Python Agent Supports Profiling Now
OpenTelemetryでは、各言語用のライブラリが提供されており、多くの場合、自動計装（自動インストゥルメンテーション）によってアプリケーションへのトレーシング機能の導入が容易になっています。自動計装により、手動でコードに計測ポイントを追加することなく、既存のアプリケーションに対してトレーシングやメトリクスの収集が可能となります。言語ごとの対応状況や自動計装の詳細については、以下のリンクを参照してください。
また、JavaScriptに関しては、Node.js用とBrowser用のライブラリが用意されており、ブラウザ側からTrace情報を送信する事も可能となっています。
OpenTelemetryを活用した可視化のレベル
上記で説明したTrace、Metrics、Logの情報を各サービスから収集することにより、システム全体の可視化が実現可能です。ここでは、どのようなレベルの可視化が可能かを検討してみたいと思います（あくまで可能性を示すものであり、現時点では実現が難しい事柄も含まれるかもしれません）。
前項でも少し触れましたが、OpenTelemetryのJavaScriptライブラリには、ブラウザ用のライブラリも提供されています。これにより、ブラウザから送信された情報をトレーシングのエンドポイントとして扱うことが可能です。
npm: @opentelemetry/auto-instrumentations-web
さらに、リクエストだけでなく、ユーザの操作（フォームへの入力やボタンのクリックなど）もトレーシングできるため、ブラウザ上でユーザが行った操作からバックエンドの処理までの一連の動作をトレースすることが可能です。これらの機能を利用することで、エンドユーザーの体験とシステム全体のパフォーマンスをより詳細に把握することができます。
これらを組み合わせて得られる情報のイメージは、以下のような形になるでしょう。
- ユーザがトップ画面で検索キーワードを入力し、検索ボタンを押下した。
- 検索ボタンの押下により、XXX APIのリクエストが発生し、その際の検索パラメータはXXXだった。
- バックエンドサーバがリクエストを受け付け、外部サービスBのAPIを実行した。その際のパラメータはYYYだった。
- サービスBではデータストアに検索クエリを発行し、取得した結果をもとにバックエンドサービスにレスポンスを返した。
- バックエンド側で未処理のエラーが発生した。その際のスタックトレース及びエラーメッセージはZZZだった。
従来のログ管理では、個々のサービスのログをそれぞれ分析し、原因箇所を特定する必要がありましたが、OpenTelemetryを各サービスに実装することにより、上記のような情報取得が可能になります。
OpenTelemetryの各種ライブラリが提供するAuto Instrumentation機能を活用することで、主要なトレース情報（外部サービスのAPIコールやデータストアへのクエリ実行など）は簡単な設定とライブラリのインストールだけで実現可能です。これにより、個別のプログラムを修正してトレースを実装する必要が大幅に減り、効率的な可視化が実現できます。
分散トレーシングとQAについて
ここまで、分散トレーシングおよびその標準規格であるOpenTelemetryの概要について説明させていただきましたが、我々AGESTのようなQAを主業務とする企業において、これらの機能がどのように活用できるかを考察してみたいと思います。
分散トレーシングは、運用目的のツールや性能テストでのボトルネック調査といったイメージが強いですが、それだけではなく、その導入の容易さや、原因調査能力の高さや、収集情報の有用性から、一般的なテストにおいてもバグ発生時の原因究明を迅速に行える可能性もあります。このように、分散トレーシングはテストプロセスにおいても重要な役割を果たすことができるのです。
従来、QAと開発の関係では、不具合が発生した場合、QA側が発生手順、発生日時、再現率などの情報を開発者に伝え、開発者がログ解析や原因調査を行うのが一般的でした。しかし、分散トレーシングの導入によって、QA側が開発者により詳細な情報を提供できるようになりますし、開発の実態やサービス内容をより深く理解した上でのQA実施が可能となります。
この変化によって、従来のQAの枠組みを超えた、新しい形のQAサービスが提供できる可能性があります。
最後に
以上、分散トレーシングとQAについてでした。
分散トレーシングは、現代の複雑なシステム開発において欠かせない技術の一つです。QAの観点から見ると、テスト工程においてトレーシング機能を活用することで、システムの挙動を正確に把握し、品質管理をより効果的に行うことができます。
しかし、この技術を活用するためには、開発チームとの密なコミュニケーションが必要です。開発チームと共に、テスト戦略を練り上げることが、高品質なソフトウェアの開発につながります。
今後も、常に最新のテスト技術に目を向け、学び続けることが大切です。皆さんもぜひ、分散トレーシングをはじめとする最新のテスト技術を取り入れ、より高度な品質管理に取り組んでみてはいかがでしょうか
