オブザーバビリティの最前線~OpenTelemetryで下げる認知負荷~活用事例4選~

コードブロック

{ "a": "b"}

- a
- b

見出し2

これは例の段落です。この段落には、リンクや太字のテキストを含めることができます。

見出し3

コードスニペットはインラインで使用できます。または以下のようにブロックで表示することもできます。

console.log('Hello, world!');

• リストアイテム1
• リストアイテム2
  • ネストされたリストアイテム

これは引用です。引用は左側に線が引かれます。

テーブルも作成できます:

最後に、水平線を追加してセクションを区切ることができます。

OpenTelemetryとは

従来のオブザーバビリティの課題を解決するOpenTelemetry

従来のオブザーバビリティにおける重要な3本柱としては「メトリクス」、「ログ」、「トレース」が提唱されてきました。しかし、従来の3本柱ではメトリクス、ログ、トレースが別々のシステムとして扱われ、データが分断されているため相関関係を見つけるのが難しくなっています。現実のシステムはトランザクションとリソースで構成されており、その相互作用から問題は生じています。従来のオブザーバビリティシステムではその関連性を自動的に特定することができず課題となっていました。

そこで、OpenTelemetryではメトリクス、ログ、トレースを一つの一貫したグラフにまとめ、あらゆるテレメトリーのあらゆる形態を相関させることで、統一された分析を可能にし、遠く離れた重要な関連性をも見つけ出すことを可能にします。


A braid of signals, making it easier to find correlations between them より引用

OpenTelemetryとは

OpenTelemtryはメトリクス、ログ、トレースのようなテレメトリーデータを作成し、管理するために設計されたオブザーバビリティの標準仕様であり、ツールキットです。
OpenTelemetryでは、仕様に基づいて各言語向きライブラリが実装されており、アプリケーションやシステムを、その言語やインフラストラクチャー、ランタイム環境に関係なく、簡単に計装することができます。

OpenTelemetryではオブザーバビリティを①テレメトリーの作成と転送②分析の２つの段階に分けた時の、①テレメトリーの作成と転送を行うための各種ツール、API、SDKのコレクションを提供しています。

ここで重要なことは、テレメトリーの保存と可視化は意図的に他のツールに任せていることです。 会員限定コンテンツ無料登録してアーキテクチャを見る 『OpenTelemetryが気になってるけど実際に始めて「なるほどね」ってなるにはどうしたらいいかについて15分でまとめて喋ります』大谷和紀さん　より引用

詳細はこちらの資料を是非お読みください
『OpenTelemetryのこれまでとこれから』　山口能迪さん

OpenTelemetryの現在

OpenTelemetryは、複雑化・大規模化する現在のシステムの把握を行い、インシデントが起こった際の速やかな原因特定・適切な対処を行うための鍵を握る、オブザーバビリティの分野で大きな可能性を持つプロジェクトです。
しかし一方で、オブザーバビリティ自体がここ数年で広まり始めた概念であり、OpenTelemetryについては認知もまだ広がっておらず、Web系企業であっても導入事例はまだまだ少ないのが現状です。
そんな中でOpenTelemetryを導入し、自社の課題解決やシステム運営に成功している企業の事例を次からの章で紹介します。

株式会社AbemaTV

事業内容

「ABEMA」はテレビのイノベーションを目指し"新しい未来のテレビ"として展開する動画配信事業。登録は不要で、24時間編成のニュース専門チャンネルをはじめ、オリジナルのドラマや恋愛番組、アニメ、スポーツなど、多彩なジャンルの約25チャンネルを24時間365日放送しています。

OpenTelemetry導入の背景

Open Telemetry 導入前は Amazon Web Services と Google Cloud でそれぞれ提供している分散トレーシングプラットフォームを利用していました。
各クラウドのサービスを利用することで運用コストなどは抑えることができていたのですが、 ABEMA の特性上、複数のクラウドを跨いだワークロードがあります。これらのワークロードでもトレース情報を可視化したい要件があったり、開発者からもそれぞれのクラウドに合わせて実装や利用方法の認知負荷が高いので統一したいなどの要望がありました。
これらの課題を解決するためにクラウドベンダーに依存しない形で分散トレーシングを行う基盤を作成するに至りました。

アーキテクチャ図

会員限定コンテンツ無料登録してアーキテクチャを見る

OpenTelemetry導入・活用の工夫ポイント

Open Telemetry の導入にあたり、開発者が利用するクラウドを意識せずに分散トレーシングを利用することができるようにアプリケーションの実装で使う処理を社内 SDK へ実装しました。
また、各クラウドの挙動を調査し、クラウドを跨いだ際にも可能な限りトレース情報が途切れないようなプロトコル選定 ( B3 multiple header ) を行いました。
導入の際にも全てのコンポーネントに強制するのではなく、可視化する価値の高いマイクロサービスを選定し、段階的な導入を行っています。

OpenTelemetry導入によって得られた成果、解決できた課題

今までは、障害時にコンポーネントに応じて確認するクラウドやダッシュボードが別れていましたが Open Telemetry の導入で 1 ヶ所にデータを集めることで、開発者の認知負荷を削減し、課題や問題の発見をスムーズに行えるようになりました。

著者

株式会社AbemaTV
Engineering Manager, AbemaTV Platform Division, Developer Productivity
山本 哲也　@_tetsuya28

Sansan株式会社

事業内容

インボイス管理サービス「Bill One」
Bill Oneは、あらゆる請求書をオンラインで受け取り、企業全体の請求書業務を加速するインボイス管理サービスです。

OpenTelemetry導入の背景

本番環境で発生するレスポンス遅延の原因特定が困難であり、かつ、特定に時間がかかっていたことです。
個々のエラーであれば、TraceIDをCloud Loggingに送っているため複数サービスに跨った状態であっても調査できていました。しかし、環境全体が遅延している状況では原因を追う手段が乏しく、プロダクト内部を深く理解しているメンバーによる職人芸的なアプローチになってしまっていました。
そこで、当時注目され始めていた「可観測性」の向上により、原因特定の高速化、原因特定に向き合えるメンバーの増加を期待して、ベンダーやツールにとらわれない点も踏まえてOpenTelemetryを導入しました。

アーキテクチャ図

会員限定コンテンツ無料登録してアーキテクチャを見る

OpenTelemetry導入・活用の工夫ポイント

導入時は、主要なマイクロサービスのうち、自動計装を利用可能な言語で実装されているサービスに絞って自動計装を導入することで、プロダクトコードに影響を与えずに計装のメリットを感じられるようにしました。
導入以後は、主要サービス以外へ自動計装の導入、自動計装ではカバーできない部分（ユーザIDなどの重要なデータ、非同期処理、重要な機能等）の計装を順次進めました。
また、OpenTelemetryにはSemantic Conventions（意味上の規約）というものがあります。例えば、Messaging処理に関してどのような値をどのような名前で計装したら良いのか書いてあるので、一通り目を通すと良いと思います。

OpenTelemetry導入によって得られた成果、解決できた課題

OpenTelemetryの導入と同時にAPMツールを導入しました。計装した結果をAPMツールで可視化することで、プロダクトのレイテンシ悪化時にどの部分が悪化しているのかの特定が素早くなり、ユーザから問い合わせが来る前に対処できるようになりました。
また、主要機能である請求書検索機能で指定されたパラメータに対して計装を実施したことで、当該パラメータ指定の頻度やレイテンシの差などが可視化されました。それに基づいて改善を実施し、結果として90パーセンタイルのレイテンシを従来の半分にまで削減し、改善結果の測定もリリース直後から実施できる状態になりました。

著者

Sansan株式会社
技術本部 Bill One Engineering Unit
前田 英司

FRAIM株式会社

事業内容

クラウド ドキュメント ワークスペース LAWGUE の研究・開発・提供。

OpenTelemetry導入の背景

元々クラウド(AWS)でサービスを提供していましたが、インターネットへのアクセスが制限された閉域網でもサービスを提供する必要が生じました(以下オンプレミス)。 そのため、外部のベンダーが提供するサービスを利用することができない状況でした。
また、クラウドとオンプレミスでの差異をできるだけ少なくして、開発速度を維持する必要もありました。
そこで、OpenTelemetryのアプリケーションがベンダーに依存しない形でtelemetryの出力を計装できる点に着目し、導入を検討しました。
公式でKubernetes operatorが提供されているだけでなく、AWS、Grafana、ElasticといったベンダーやコミュニティでもOpenTelemetryとの連携を進めている動きも追い風となりました。

アーキテクチャ図

会員限定コンテンツ無料登録してアーキテクチャを見る

OpenTelemetry導入・活用の工夫ポイント

OpenTelemetry Collectorの活用がポイントであると考えています。用途に応じて、sidecar, deployment, daemonsetといったworkloadでcollectorを運用しています。
Collectorではpipelineという形で、telemetryの処理プロセスを定義できるのですが、その中でprocessorを活用することで、アプリケーションレイヤーや分析ツールレイヤーで行う処理を委譲することができます。
例えば、不要な処理のフィルターや、機密情報のリダクション、metadataの加工等が行えます。
また、tracesやlogsをmetricsに変換することで、observabilityに関するコストを調整することもできます。
Collectorの運用についてはオライリーのLearning OpenTelemetryの8章 Designing Telemetry Pipelinesや公式ブログのOpenTelemetry Collector Antipatternsが参考になりました。

OpenTelemetry導入によって得られた成果、解決できた課題

Applicationが互換性の保証されたApiでtelemetryを出力できるようになりました。同じApiが利用しているライブラリでも利用されているので、hookやthird party pluginを利用することなく、telemetryを得ることができます。例えば、非同期runtimeのmetricsやgraphqlのresolver単位のtraces等です。OpenTelemetryが特定のベンダーに依拠していないことで、ミドルウェアやライブラリーが積極的にopentelemetryを計装してくれるのは魅力的です。

著者

FRAIM株式会社
SREチーム
山口 裕太　@YAmaguchixt

株式会社ヘンリー

事業内容

私たちは超高齢化社会の中で持続可能な医療の仕組みを作るため、医療現場で働く方にとっての使いやすさを追求した業界唯一の病院向けクラウド型電子カルテHenryを開発しています。

OpenTelemetry導入の背景

電子カルテと聞くと多くの方が医師や看護師が入力している画面を想像するかと思いますが、Henry は基幹システムとしてレセプト計算と提出の機能を兼ね備えています。レセプト計算では地方自治体ごとに計算基準が異なったり、医療機関ごとに必要とされる機能に濃淡があるので、システムとしての複雑性が高くなるという特色があり、高水準なシステム要件が求められます。

そのため、システムの可観測性を向上することで開発者全員が障害対応時はもちろん、普段からパフォーマンスチューニングができるような基盤整備が必要でした。

さらに、今後のサービス規模の拡大などで Observability ツールの乗り換えなども十分あり得るシナリオなので、現時点でのベンダーロックインは極力避けたいと考えました。

このような状況で複数のテレメトリーデータをあつかえる OpenTelemetry であればベンダーロックインを避けつつ、様々な Observability サービスを使えそうだったので導入を決めました。

アーキテクチャ図

会員限定コンテンツ無料登録してアーキテクチャを見る

OpenTelemetry導入・活用の工夫ポイント

Henry は OpenTelemetry 構成図にあるとおり Google Cloud の Cloud Run でアプリケーションを構築して運用しています。OpenTelemetry Collector も Cloud Run のサービスとして構築しています。Cloud Run はサイドカーで OpenTelemetry Collector を動かすという選択肢もありますが、導入前の検証時にコストと構成の柔軟性について調査したところ、OpenTelemetry Collector は独立した Cloud Run サービスで構築することにしました。

詳細については以下の資料に書いています。

ヘンリーにおける可観測性獲得への取り組み - Speaker Deck

OpenTelemetry導入によって得られた成果、解決できた課題

OpenTelemetry Collector を独立した Cloud Run サービスで構築したことで、複数の Observability ツールを目的別に使い分けることができているということが大きなメリットだと考えています。

とくに当初は Datadog で分散トレースと分散ログも扱うことを考えていましたが、使っていくうちに我々の要件では Cloud Trace と Cloud Logging のほうがマッチするということがわかりました。そこで、OpenTelemetry Collector の設定を変更するだけで、トレースの保存先を Datadog から Cloud Trace に切り替えることができました。また、Cloud Trace でも一部の不満は残っているため、他のバックエンドを試す目的で構成を柔軟に変更できています。

著者

株式会社ヘンリー
製品部門 製品本部
CTO室
SRE
渡辺 道和 (nabeo)　@nabeo

OpenTelemetry特集
企画協力
Senior Solutions Architect, Observability
Splunk Services Japan合同会社
大谷 和紀　@katzchang

執筆・編集
山口 紗英　 E-mail：sae.yamaguchi[アットマーク]findy.co.jp　@yamasa_fin