こんにちは。
現在アサインしているプロジェクトで、アプリケーションの監視に関する
実装に触れる機会があったので、社内向けに紹介したいと思い記事を書きます。
今回はサービスの可観測性について
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言語はもちろん、様々な言語、ベンダーをサポートしているようです。
ベンダーの例
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