エンジニアBLOG

はじめに

こんにちは。
現在アサインしているプロジェクトで、アプリケーションの監視に関する
実装に触れる機会があったので、社内向けに紹介したいと思い記事を書きます。

今回はサービスの可観測性について
OpenTelemetryを例に、簡単にまとめたいと思います。

observability(可観測性)

マイクロサービスなどで顕著ですが、
アプリケーションの一つの機能を提供するだけでも複数のサービスを経由します。
そうなると、例えばシステムの処理時間に問題がある場合など、どのサービスが原因なのか分からず、全体のパフォーマンスを管理することが難しくなります。
そういった問題を解決するために、アプリケーションからテレメトリデータを出力させることで可観測性を高め、パフォーマンスや信頼性の改善に役立てようというアプローチです。

テレメトリデータとは

• トレース（分散トレーシング）
• メトリック
• ログ

などを指します。それぞれのデータの性質については、以下の記事がわかりやすかったので参照してください。

Metrics, Events, Logs, Traces ってなんだ？

OpenTelemetryとは

OpenTelemetry : https://opentelemetry.io/

トレース、メトリック、ログなどのテレメトリデータを収集するすることで
アプリケーションのインストゥルメント化を実現し、様々な種類のバックエンド（ブラウザで視覚的に表示可能なツール）へデータを送る方法を標準化する目的のサービスです。

Cloud Native Computing Foundation がスポンサーとなり開発されています。

最終的に何ができる？

最終的に何ができるのか、分かり易い例としてバックエンドのUIを見ていこうと思います。

アプリケーションに組み込み、JAEGER や Zipkin などのバックエンドにデータを送ると
送信先でトレースなどのデータを視覚的に把握することができるようになります。

UIの例を見てみましょう。

画像引用元：https://zipkin.io/

画像はZipkinのUIです。
こちらは分散トレーシングのデータを視覚的に表示してくれます。

ROUTINGからMAIN_APIとMOBILE_APIへリクエストが遷移している様子が追跡できており、
どのAPIにどれくらい時間がかかっているかがひと目でわかりますね。

OpenTelemetryは、こういったトレースデータを追跡、収集してバックエンドへ送信してくれます。

このように、インストゥルメント化したアプリケーションのデータを便利に確認できるバックエンドですが、ツールごとにデータの形式などがバラバラで、送信する方法が標準化されていませんでした。

OpenTelemetryは、言語に依らないインストゥルメンテーションをサポートするライブラリと、
バックエンドへデータを送信する形式の標準化などを提供しています。
我らがGo言語はもちろん、様々な言語、ベンダーをサポートしているようです。

ベンダーの例

AWS Sistro for OpenTelemetry

How it works

画像引用元：https://aws-otel.github.io/

OpenTelemetryで収集したテレメトリデータをAWS内のサービスで可視化できる旨が確認できます。

まとめ

今回はアプリケーションの可観測性とテレメトリデータ、
これを実現するためのツールとしてOpenTelemetryを調べて紹介しました。

実際に導入して使用してみた経験から、あまり難しくなく、一度実装してしまえば
貴重なデータを収集できるようになるため、選択肢として検討してみるのもいいかもしれません。

参考

https://newrelic.com/jp/blog/best-practices/what-is-opentelemetry
https://www.splunk.com/ja_jp/data-insider/what-is-opentelemetry.html
https://newrelic.com/jp/blog/how-to-relic/metrics-events-logs-and-traces