Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building Observability Infrastructure with Open...

Avatar for Y.Matsuda Y.Matsuda
November 20, 2024
760

Building Observability Infrastructure with OpenTelemetry and SaaS

Avatar for Y.Matsuda

Y.Matsuda

November 20, 2024
Tweet

Transcript

  1. Kaigi on Rails 2024+関連イベントで登 壇 資料:モノリスでも使える! OpenTelemetryでRailsアプリのパフォーマンス分 析を始めてみよう from Kaigi

    on Rails 2024 資料:OpenTelemetryによるRailsアプリの計装を支える ActiveSupport::Notifications from Kaigi on Rails 2024事後勉強会 6
  2. 柔軟かつお手軽 is … オブザーバビリティ基盤における • 柔軟さ with OpenTelemetry ◦ Agility:不確実性やリスクに素早く対応できる

    ◦ Flexibility:ベンダーやプロダクトの違いを吸収 (Agilityの前提) • お手軽さ with SaaS ◦ 運用の手間がかからない 9
  3. 特に”柔軟さとお手軽さ”が求められるフェーズ 出典:AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査

    トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 11
  4. 特に”柔軟さとお手軽さ”が求められるフェーズ 出典:AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査

    トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 テレメトリの関連付け トレース導入 12
  5. 補足:オブザーバビリティ成熟度モデル from AWS (Observability Maturity Model) Stage 1:基礎的なモニタリング (テレメトリデータの収集) 各チームが各自でテレメトリを収集している(利用製品も統一されていない)。メトリクスとログを定義

    し、収集を行っている。 推測に頼ったアラート対応。 Stage 2:中級モニタリング (テレメトリ分析とインサイト) トレースを含むテレメトリ収集を行い、それを用いたアクション可能なアラート戦略が存在する。しか し、デバッグに時間がかかり、アラート疲れの兆候もある。 このステージに留まっている企業や組織は多い。 Stage 3:高度なオブザーバビリ ティ(相関関係と異常検知) テレメトリやコンポーネント間が相関し、問題の根本原因を即座に特定できる。アノマリーの検知も行 い、問題もリアルタイムに発見し対応できる。 Stage 4:プロアクティブなオブザー バビリティ (自動的かつ事前の根本原因特 定) 問題が起こる「前」にその発生を予測し未然に防止する。システムにより自動的にテレメトリを分析 し、動的なダッシュボードにより必要な情報が提供され、関連チームは情報の取捨選択の作業が不 要になる。 出典:AWS オブザーバビリティ成熟度モデル ※表の内容は本登壇資料の作成者による要約 13
  6. Let’s play with OpenTelemetry! • 事例1:OpenTelemetryとDatadog APMで最小限のリスクでオブザーバビリティを使 い始めて普及させる [某事業会社] ◦

    概要と背景 ◦ OpenTelemetryによる計装を選ぶ理由 ◦ 構成とその注意点 ◦ 導入成果と普及活動 ◦ OpenTelemetry+Datadogの難しいところ • 事例2:ベンダーの壁をOpenTelemetry Collectorの仕組みでシュッと乗り越える [SmartHR] ◦ 概要と背景 ◦ 直面した課題 ◦ OpenTelemetry Collectorの導入(Reveiver, Exporter, Processor) ◦ 導入成果 Agility Flexibility 16
  7. 当時の成熟度:1.5くらい? 出典:AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査

    トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 26
  8. コンテナ テレメトリ収集(計装) 従来のログ収集と比べて 計装はベンダーへの実装依存度が高い 実装コード( Golang) SDK コンテナ Agent /

    Collector OTLP or Other formats 計装ライブラリ( net/http) 計装ライブラリ( sqlx) 計装ライブラリ( redigo) 32
  9. ベンダー切り替え時の想定作業 • 必ず生じる作業 ◦ Agentの切り替え ◦ 環境変数の変更など • 実装に依存している場合に必要な作業 ◦

    実装の修正や検証 ◦ アプリレイヤーの性能試験 ▪ テレメトリのバッファリング、送信ロ ジックの差異より 監視ベンダー切り替えや構成変更時の 移行コストが大きくなる サービス数 34
  10. 計装のうち、実装に関わる部分を 標準仕様(OTel)にしておく ベンダー切り替え時の想定作業 • 必ず生じる作業 ◦ Agentの切り替え ◦ 環境変数の変更など •

    実装に依存している場合に必要な作業 ◦ 実装の修正や検証 ◦ アプリレイヤーの性能試験 ▪ テレメトリのバッファリング、送信ロ ジックの差異より サービス数 37
  11. ベンダー切り替え時の想定作業 • 必ず生じる作業 ◦ Agentの切り替え ◦ 環境変数の変更など • 実装に依存している場合に必要な作業 ◦

    実装の修正や検証 ◦ アプリレイヤーの性能試験 ▪ テレメトリのバッファリング、送信ロ ジックの差異より 計装のうち、実装に関わる部分を 標準仕様(OTel)にしておく サービス数 38 移行先がOTel互換であ れば実装修正不要
  12. プロトコルの差異 出典:OTLP Ingestion by the Datadog Agent • プロトコルの違い ◦

    Datadog:独自プロトコル ◦ OpenTelemetry:OpenTelemetr y Protocol(OTLP) • Datadog AgentはOTLP互換👏 ◦ 特段障壁にならず ◦ 環境変数設定で終わり 47
  13. • できれば標準仕様のW3C Trace Contextを使いたい • 当時はDatadog計装では非対応… トレースコンテキストフォーマットの差異 51 W3C Trace

    Contextによるヘッダー例 Datadog計装 (モノリス App) Inject, Extract不可 (≒トレース繋がらない)
  14. Nginx(openresty) • Datadog形式への変換どうする? ◦ Luaを書くorz ◦ confでmoduleとLuaを読み込ん でLogに出力(記憶が完全に揮発し たのでコード割愛) •

    負荷試験をした上でリリース(CPU使用 率が微増した程度) 血と涙の結晶2(記憶を頼りにLuaを復活 w/ ChatGPT)→ ※多分間違っているので雰囲気だけ トレースとログの紐付け 61
  15. 成熟度の前進:2.1くらい? 出典:AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査

    トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 68
  16. 成熟度の前進:2.1くらい? 出典:AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査

    トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 オブザーバビリティの一歩を踏み出せた! 69
  17. 事例1:まとめ • OpenTelemetryとSaaSを組み合わせて運用することは十分可能 ◦ 知見の少ない、不安定なフェーズで採用するのはむしろあり ◦ 今はもっとスムーズな連携ができるようになっています(ログ周りなど) • 互換性については下記の点を要チェック ◦

    トレースフォーマット(SaaS側がOTLPに対応しているか?) ◦ トレースコンテキストフォーマット ▪ 双方向の通信でそれぞれInject, Extract可能か? ▪ W3C Trace Contextに対応していれば基本大丈夫です • 前のめりに活用して浸透させましょう✌ 82
  18. 技術構成 • Software: postgresml/pgcat ◦ Rust製のコネクションプーラー • VM: Compute Engine

    ◦ TCP接続が必要なため ◦ Blue/Green構成(Managed Instance Group) • Platform: Docker Container on Container-Optimized OS • Monitoring: Cloud Monitoring 89
  19. • Google Cloud Exporter • AWS CloudWatch Logs Exporter 多くのComponentで関連企業のエンジニアが

    Code Ownerになっているので安心! 出典:Contrib repository for the OpenTelemetry Collector ←googlerがいる ←AWSの人がいる 95
  20. OpenTelemetry Collectorが無かっ たら…… • Container-Optimized OS以外のOSを利用 ◦ Docker Engine、VM Managerなど構成管理が複雑化

    ◦ 設定漏れ等によるセキュリティリスク 出典:Container-Optimized OS の概要 | Google Cloud 107
  21. 事例2:まとめ • OpenTelemetryの豊富なComponentを組み合わせることで、プロダ クトやベンダーの差異を吸収しテレメトリ収集することが可能になる ◦ Receiver(Pull, Push問わず), Exporter ◦ Resource

    Detection Processorでプロダクトやベンダー特有の 情報もよしなに収集→Cloud Monitoringと調和 • OpenTelemetryでできることを知っておけば、いざというときに武器 になる💪 109