オブザーバビリティの未来 OpenTelemetry を使ってみた
この記事はPioneer Advent Calendar 2022の3日目の記事です。
今回は、データ可観測性（オブザーバビリティ）の分野で昨今注目されている、OpenTelemetryを導入した試みについて、ご紹介します。
はじめに
こんにちは。パイオニア株式会社のSaaS Technology Center（以下、STC）でSREをしている布宮です。
現在所属しているSREチームでは、ビークルアシスト基盤最適化のインフラ構築や、サービス監視の仕組みづくりなどを行っています。
今回、バックエンドアプリケーションのAPM（※1）を目的として、OpenTelemetryを採用しましたので、その導入事例についてご紹介したいと思います。
※1：Application Performance Management の略。アプリケーションの応答性能やエラー率を監視し、サービスの稼働状況やサービスレベル指標を管理すること。
OpenTelemetryとは
OpenTelemetryは、テレメトリーデータ（※2）の収集・転送方法を共通化する統一仕様です。
Gartner 社が発表している「先進テクノロジのハイプ・サイクル：2022年」では黎明期の位置にあり、まだまだ新しい技術です。
※2：一般的にはシステムの状態を表す用語で、以下の情報を指す。
・トレース（Trace）：処理フローに関するデータ。どの処理がどの順番で実行され、どのくらい時間がかかっているかなど。
・メトリクス（Metrics）：ある期間のデータを集計した値。平均処理時間、パーセンタイル処理時間など。
・ログ（Log）：個々のイベントの記録。
OpenTelemetryはオープンソースで、さまざまな言語に対応したライブラリやAPIが公開されています。特定のモニタリングツールに依存しないため、OpenTelemetryを使って収集・送信したテレメトリデータは、いろいろなモニタリングツール・プラットフォームで使うことが可能です。
将来、OpenTelemetryが普及した際には、自前でパフォーマンス計測用のライブラリを作成することや、特定のモニタリングツールに依存するライブラリを使用する機会は少なくなるかもしれません。
背景
元々ビークルアシストでは、バックエンドの開発言語にJava、モニタリングツールにNew Relicを使用し、バックエンドAPMとしてJava用のNew Relicエージェントを組み込んで監視を行っていました。
その後、サービス基盤の刷新に伴い、バックエンドの開発言語にRustが採用されることになりました。（詳しくは、以下の弊社note２記事をご参照ください）
Rustは、C/C++と同様にネイティブコンパイル言語であるため、コンパイル後に外から介入してアプリケーションの詳細をトレースすることは、言語仕様上不可能です。そのため、Javaのようにエージェントを組み込む方法が使えませんでした。
そこで、代替手段として採用したのが、OpenTelemetryです。New Relic製のRust向けSDKを使う選択肢もありましたが、昨今、アプリケーションの計測について標準化の動きが出てきていることと、モニタリングツールのベンダー依存を避けることを考慮し、OpenTelemetryを採用しました。
やってみた
実際にOpenTelemetryを導入するために行ったことは、大きく3つです。
Rust実装のバックエンドに対して、OpenTelemetryのライブラリを組み込み、トレースデータを収集する処理を実装する（アプリ面の対応）
バックエンドからトレースデータを収集してNew Relicへ送信する、OpenTelemetry Collectorを設置する（インフラ面の対応）
送られてきたトレースデータを使ってモニタリングできるように、New Relicの設定を行う（サービス監視面の対応）
トレースデータ収集からNew Relicへの送信までの構成図を以下に示します。
今回は、SLI/SLOといったサービスレベルの監視を目的としていたため、バックエンドのレスポンス時間、レスポンスコードが5xxエラーかどうかの確認、およびエラーの詳細といった情報を、トレースデータとして収集するような実装を行いました。
また、OpenTelemetryには、OpenTelemetry Collectorという各種モニタリングツールにエクスポートするためのコンポーネントが用意されています。上記構成図のように、CollectorのDockerイメージをAWS Fargate上で動かし、バックエンドの各種アプリケーションからトレースデータを収集し、一括してNew Relicに送信するインフラ構成としています。
最後に、送られてきたトレースデータをサービスの監視として利用するために、New Relic のダッシュボードの作成や、エラー時にアラートとして通知する設定を行いました。
やってみて苦労したところ
・そもそも情報が少ない
新しい技術なので仕方ないことですが、日本語、英語問わず情報が少なかったです。最初は公式のサンプルコードを参考に手探りで実装し、挙動を確認しながらあれこれ推測して動かしました。また、OpenTelemetryのRustコードを直接見ないと解決できない問題もありました。
・トレースデータ収集処理の実装に関しては、一部バックエンド開発者に実装を依頼する必要がありました。加えて、バックエンドのコードに直接データ収集のための処理を追加するため、元のオリジナルのコードが少なからず‟汚れ”ます。
そのため、バックエンドへの処理の追加を最小限にするなど、バックエンド開発者の実装コストを下げるための配慮が必要でした。
・収集したデータは最終的に「サービスの監視」という目的を満たすものでなければなりません。どのようにサービスを監視し、そのためにどのようなデータを収集する必要があるのか。また、そのためにOpenTelemetryのどの機能を使ってどのように実装するのかを決め、アプリ開発者に依頼する。サービスの監視方法からアプリの具体的な実装方法、必要なインフラの構築までをトータルで見る必要があり、SREとしてとてもチャレンジングな経験となりました。
終わりに
弊社では、SRE、およびRustでバックエンド開発をしたいエンジニアを募集中です。もし興味を持ってくれた方がいらっしゃいましたら、採用ページをご覧ください。
Pioneer Advent Calendar 2022 の4日目は、SaaS Technology Center データインテリジェンス部 室水 仁 さんの「 KPIマネジメントを成功に導くためにデータアナリストが大切にしていること」です。
是非お楽しみに！