OpenTelemetryで実現するベンダーロックレスなObservability

Transcript

1. 1 1 OpenTelemetryで実現するベンダーロックレスな Observability ドリーム・アーツ Shopらん 開発チーム 宮下
2. 2 2
3. 3 3 突然ですが… ベンダーロックされるの嫌じゃないですか？？？
4. 4 4 突然ですが… え、でも監視ツールのエージェントのコードは どうしようもないじゃないですか…
5. 5 5 突然ですが… ベンダーロックレスなサービス監視… そう、OpenTelemetryならね！
6. 6 6 OpenTelemetryで実現するベンダーロックレスな Observability ドリーム・アーツ Shopらん 開発チーム 宮下
7. 7 7 ⽬次 n OpenTelemetryとは何なのか？ n OpenTelemetryを利⽤するメリットとは？ n OpenTelemetry導⼊事例 n ベンダーロックレスなのに… なぜNewRelicを選ぶのか？
8. 8 8 テレメトリーの取得⽅法 アプリケーション (サービス、関数) テレメトリー （ログ、メトリクス、トレース）
9. 9 9 テレメトリーの取得⽅法 アプリケーション (サービス、関数) テレメトリー （ログ、メトリクス、トレース） 計測器 instrumentation エクスポーター
10. 10 10 テレメトリーの取得⽅法 n 実装する必要があるもの - 計測器 - エクスポーター n 得られるもの - ログ - メトリクス - トレース（分散トレース）
11. 11 11 n 実装する必要があるもの - 計測器 - エクスポーター n 得られるもの - ログ - メトリクス - トレース（分散トレース） テレメトリーの取得⽅法 仕様は？ 実装は？ 互換性は？
12. 12 12 テレメトリーの取得⽅法 n ⾔語の数と出⼒⽅式の数だけ実装しなきゃいけない 計測器 計測器 計測器 Exporter Exporter テレメトリ テレメトリ テレメトリ
13. 13 13
14. 14 14 OpenTelemetryの経緯 n 分散トレースの需要の拡⼤ n 分散トレーシングのバックエンドの登場 Zipkin, Jaeger n 計測器の共通化を進めるプロジェクトの登場 CNCFプロジェクト Google プロジェクト OpenCensus
15. 15 15 OpenTelemetryの経緯 n 同じプロジェクトは2つあっても仕⽅ない n 2019年3⽉ 2つのプロジェクトのマージが決定 n 5⽉ OpenTelemetryと名付けられ、CNCF Sandboxプロジェクトへ +
16. 16 16 OpenTelemetryとは？ h6ps://opentelemetry.io/docs/ 計測器 エクスポーター （コレクター）
17. 17 17 OpenTelemetryとは？ n ログ、メトリクス、トレースというテレメトリーの計測器、エクス ポーターの標準仕様 n ライブラリとエージェントも提供してくれる
18. 18 18 OpenTelemetryのメリット n 標準的な仕様であること - ベンダーに依存されない - 依存の少ないクリーンなシステムになる - エンドポイントを変更するだけで異なるベンダーに切り替え可能
19. 19 19 OpenTelemetryのメリット n Openなプロジェクトであること - CNCFプロジェクトの⼀つ - 多くの⼈、多くの企業が関わっており、いろいろな⾔語、フレームワークで の対応がされている。 - 広く深いところで使⽤が可能
20. 20 20 テレメトリーの取得⽅法 n ⾔語の数と出⼒⽅式の数だけ実装しなきゃいけない 計測器 計測器 計測器 Exporter Exporter テレメトリ テレメトリ テレメトリ
21. 21 21 テレメトリーの取得⽅法 n OpenTelemetryで共通な仕様に 計測器 テレメトリ エクスポーター
22. 22 22 OpenTelemetry n 計測器の未来 - アプリケーションを把握する上でトレースデータが重要になっている - 多くの異なるシステムからデータを収集するのは⼤変 - 統⼀された⽅法で⼿法でデータ収集ができる！ - シンプルなテレメトリエコシステム
23. 23 23 導⼊事例
24. 24 24 ※ドリーム・アーツ調べ
25. 25 25 システム概要 n 13年近く稼働し続けているシステム n マルチテナント n メインのアプリケーションはVMで構成 n 新機能をマイクロサービスとして構成 n Java 8、Tomcat、MySQL n Go、 Java 11、Spring boot
26. 26 26 導⼊前の課題 n ログの解析、簡単なメトリクスの情報では限界を感じる - 不具合調査、修正 - パフォーマンス改善 - 異常状態の検知 n ⾼いスキルが必要で属⼈化してしまう
27. 27 27 トレースデータを取得したい n NewRelicなどのAgentを⼊れて解析したい n でも他社のロジックが⼊ってくるのはなるべく避けたい n マイクロサービスとの分散トレーシングもやりたい n OpenTelemetryならできるじゃん！
28. 28 28 導⼊にあたって n Java版導⼊には2通りの⽅法がある - OTELのAgentを⼊れて⾃動でやってもらう⽅法 - SDKを使⽤して観測したい部分に⼿動でSpanを⼊れる⽅法 n ⼿動での導⼊を選択 - アプリケーションが⼤きいので⾃動だとゴミデータが発⽣してしまう。 - 気になる部分にどんどんSpanを追加した
29. 29 29 実装箇所
30. 30 30 実装箇所 Exporterの作成
31. 31 31 実装箇所 TracerProviderの作成
32. 32 32 実装箇所 Tracerの作成
33. 33 33 実装箇所 Spanの作成
34. 34 34 導⼊で困った部分 n Exporterの選択 - 当時はOpenTelemetry Protocol(OTLP)が安定版ではなかった - NewRelic OpenTelemetry Exporterを使⽤ - 弊社の出⼒側とNewRelicの受け側でSpanがロストする問題があった。 - OpenTelemetry Protocolの正式版登場によってアーカイブされる n データ量 - 全データを表⽰したかったが、コスト的に断念し、サンプリングを⾏なって いる
35. 35 35 導⼊されて n OpenTelemetryのみでトレースを⾒れるように
36. 36 36 ログのカスタマイズ カスタムログアペンダー Logs API trace id, span id Logs in Contextが使える！
37. 37 37 導⼊されて n OpenTelemetryのコードのみを追加してトレースデータの取得、 送信ができるように n 分散トレーシングもできる n ログにも⼿を加えて Logs in Context も利⽤可能 n NewRelicの画⾯上でメンバー誰でもシステムの状態を確認可能 - 開発に必要なデータも誰でも調べれる - NewRelicの機能で事前検知できるもの増える - サポートの対応スピードも上がった
38. 38 38 NewRelic × OpenTelemetry
39. 39 39 なぜNewRelicなのか n OpenTelemetryへの⼒の⼊れ⽅がすごい - 機能の実装がすごく早い - 2021春にはほとんど使える状態（2021秋にGAされた） n OpenTelemetryプロジェクトにを推進している - 専任のエンジニアリングリソースを提供するアップストリームチームがある - プロジェクト内で5つの正式なリーダーシップの役割を持っている - NewRelic Agentのノウハウを活かしている
40. 40 40 なぜNewRelicなのか？ n 簡単かつ適切な監視ツールの導⼊が可能 n システムの監視を全⽅位からサポートしてくれる n AIによる異常検知で予想外にも対応可能 n APMの⽼舗であるため充実した機能 n …etc
41. 41 41 OpenTelemetryで快適なObservabilityを！