サマリ

新しいバックエンドアプリの Observability（以降 O11y と省略）を検討する際、ベンダーロックインを避けるため標準仕様の OpenTelemetry の Java Agent を採用した。
しかし運用が停滞・・・
- 組織全体が新機能の仮説検証やサービスの安定稼働にリソースを集中しており、OpenTelemetry の運用に伴って発生するタスクの優先順位を上げる余裕がなかった
- さらに OpenTelemetry を扱えるメンバーが限られていた
技術選定をする際に O11y にかかる運用コスト削減 > ベンダーロックインのリスク という点を考慮すべきだった
その上で今回の最適解は NewRelic プラットフォームを利用していることもあるため、OpenTelemetry の Java エージェントではなく、NewRelic の APM Agent を選択するのが適切だった

つまり組織の方針や体制、メンバースキルを考慮した技術選定が大事 という話しです。

技術選定と事前検証

asken では NewRelic プラットフォームを利用して運用環境の O11y を推進しており、

フロントエンド（iOS / Android / 一部の WEB）
バックエンド
インフラ ( AWS )

から取得するテレメトリは NewRelic に集約しています。

また asken バックエンドではリアーキテクチャという活動を進めており、技術的負債が蓄積された PHP から DDD を取り入れ設計・実装した Kotlin のアプリケーションへ移行しています。この初回リリースが今年の３月にありました (リアーキテクチャに関しては asken が開催した勉強会の動画がありますので是非御覧ください)。

この３月のリリースにあたってバックエンドの O11y をどうするか検討したのですが、以下の点をふまえ OpenTelemetry の Java Agent を採用しました。

将来的なことを考慮しベンダーロックイン（ NewRelic への依存）を避けたい
- コスト問題等でベンダーを切り替える必要が出た際のインパクトを減らしたい
Kotlin / Java 用の SDK や Agent が用意されている
- Kotlin は JVM 言語なので Java 系のツールセットが利用可能
NewRelic がプラットフォームとして OpenTelemetry の可視化をサポートしている

また本番へのリリースをするにあたって下記のような検証を行い、問題がないことを確認しました。

運用するにあたって必要なメトリクス・ログ・トレース等の情報が不足なく取得できるか
- 特に Kotlin は JVM 系の言語のため GC ( Garbage Collection ) の情報が問題なく取れているか
  GCグラフ
- AWS ECS ( Fargate ) 上でアプリケーションを起動するため、どの ECS Task で問題が発生したかトレースできるか
  - service.instance.id に AWS ECS Task メタデータエンドポイントから DockerId を取得して対応
負荷試験で発生したエラーや性能のボトルネックを、収集した情報から特定できるかどうか
OpenTelemetry APM

トレース情報

上記の評価で大きな問題がなく、導入にあたって技術的に難しいこともなかったためそのまま本番環境へ適用し運用を開始しました。

運用開始後に問題発生

ところが運用開始して数ヶ月経ってから以下のような問題があることが判明しました。

問題１. OpenTelemetry で収集したテレメトリの保持期間が短い

OpenTelemetry から送られたデータは非メトリックデータ（生データ）のため30日で参照ができなくなることがわかりました。これでは過去に遡って確認や比較する用途として不十分です。保存期間を長くするためには、メトリックデータとして保存できるように NerdGraph API ツールを使ってメトリックデータへ変換・保存する、もしくは契約しているプランを DataPlus オプションに変える必要がありました。前者をとる場合は調査および実装・運用コストが発生し、後者を取った場合は運用費用がまたかかるようになるため、何とか回避したいと考えました。

問題２. OpenTelemetry の運用を担える人材の育成不足

OpenTelemetry の導入にあたって技術検証などをほぼ自分ひとりでやっており、他のバックエンドエンジニアに知識や実装方式などのトランスファーを十分に実施できていませんでした。運用しながら他のメンバーに共有していけば良いと考えていたのですが、少ない人数でリアーキテクチャや新機能の仮説検証、サービス運用を担っている状況下にあって全然進めることができず、結果かなり甘い考えだったのだと認識させられました。私一人で運用を継続するのは（人間 SPOF になってしまい）組織的に不健全な状態になるため、より運用負荷の少ない代替案を考える必要がでました。

問題３. トレース情報の一部欠落

OpenTelemetry で送信しているトレース情報の一部が取得できず不完全な状態となっていました。これは運用当初から気付いていましたが、そこまで大きな問題ではなかったため、優先度を下げて後で対応しようとしていました。ただやはりこちらも、対応する時間を確保できず数ヶ月運用したあとでも解決されないままとなっていました。

発生した問題への対処

技術的な問題は解決すれば良い、のですが今回の本質的な問題は問題２.の背景にある運用上発生する問題を解決するためのリソースが確保ができないことでした。私がソロで気合と根性と残業で発生する技術的な問題を解決していくのは個人的に避けたいですし、サステナブルではありません（笑）。

そのため、当初重視していたベンダーロックインを回避するということを諦め、NewRelic の APM Agent を導入することにしました。 NewRelic の APM Agent で収集すれば自動的にメトリックデータになりますし、トレース情報も確認したところ欠落が発生していませんでした。また運用負荷については流石になくなるということはありませんが、OpenTelemetry をゼロから学ぶコストに比べると大分インパクトは小さくなったと思います。

結果として、NewRelic の APM Agent を使うことで、先に上げた問題はほぼ解決し、さらに NewRelic プラットフォームに最適化された APM の情報を見れるようになりました。

OpenTelemetry で収集したテレメトリでも NewRelic プラットフォーム上で可視化され運用するにあたって十分な情報が得られていましたが、純正の APM Agent から得られた情報と比較すると機能の洗練さや充実さにギャップがあると感じました（2024年5月あたりの感触）。

asken には今年の１月に入社し、２月くらいでこのタスクを進めていたのですが、今振り返ると開発組織の状況や他のエンジニアのスキルセットをしっかり把握せずに OpenTelemetry でいくぜ！って決めたのはちょっと強引だったなと反省です。また最初に NewRelic APM Agent と OpenTelemetry Agent を使った方式を比較すべきでした。技術選定をするにあたって考慮すべき観点や検証項目をあげ ADR (Architectural Decision Record ) として整理していたらまた違う結果になったかもしれません。

おわりに

技術選定をする際には様々な観点があると思いますが、その技術を採用した時に組織が開発・運用を問題なく回せるか冷静に検討し判断しないとですね。今回の話は比較的小さな技術選定の失敗話でしたが、今後より影響の大きい技術選定をすることになっていきますので同じ轍を踏まないよう気をつけようと思います！

また、ここまで書いてみるとただただ私が遠回りして無駄なコストかけてしまっただけになるのですが、その一方で OpenTelemetry について理解が深まりましたし、えてしてこういうチャレンジを通して人は成長していくよね！とポジティブに考えてます。これにこりずまた面白い・触ってみたい技術が出たら色々試していこうと思いまーす！

※ 技術選定については同僚が過去にも記事を書いています。よければこちらもご覧ください。

askenでは「あすけん」を一緒に盛り上げてくれる仲間を絶賛募集中です！！

興味を持った方は是非！