Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
Search
masayoshi
July 29, 2025
Technology
1
680
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
Hatena Engineer Seminar #34 オブザーバビリティの実現と運用編 の登壇資料です
https://hatena.connpass.com/event/361495/
masayoshi
July 29, 2025
Tweet
Share
More Decks by masayoshi
See All by masayoshi
これからSREになる人と、これからもSREをやっていく人へ
masayoshi
6
5.8k
メトリクス、ログ、トレースをうまく使い分けて可観測性を高めよう!
masayoshi
8
12k
Developers Summit 2021 summer
masayoshi
15
31k
2021-06-cloud-native-reg-event
masayoshi
8
2.6k
SRE_Culture_Organization
masayoshi
16
11k
cloudnative-kansai-2019
masayoshi
1
750
ミドルウェア実行環境の多様化を考慮したインフラアーキテクチャの一検討/study on web system architecture #2
masayoshi
0
3.8k
Webサービスにおけるインフラアーキテクチャの体系化と選択自動化の研究/study on web system architecture #1
masayoshi
0
3k
はてなのインフラストラクチャ設計構想 / The Concept of Hatena Infrastructure
masayoshi
1
5.5k
Other Decks in Technology
See All in Technology
ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立
rvirus0817
1
1k
会社紹介資料 / Sansan Company Profile
sansan33
PRO
15
400k
2人で作ったAIダッシュボードが、開発組織の次の一手を照らした話― Cursor × SpecKit × 可視化の実践 ― Qiita AI Summit
noalisaai
1
370
顧客との商談議事録をみんなで読んで顧客解像度を上げよう
shibayu36
0
130
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
1k
コスト削減から「セキュリティと利便性」を担うプラットフォームへ
sansantech
PRO
3
1.1k
制約が導く迷わない設計 〜 信頼性と運用性を両立するマイナンバー管理システムの実践 〜
bwkw
2
810
あたらしい上流工程の形。 0日導入からはじめるAI駆動PM
kumaiu
5
740
小さく始めるBCP ― 多プロダクト環境で始める最初の一歩
kekke_n
1
310
Kiro IDEのドキュメントを全部読んだので地味だけどちょっと嬉しい機能を紹介する
khmoryz
0
140
セキュリティ はじめの一歩
nikinusu
0
1.5k
Introduction to Bill One Development Engineer
sansan33
PRO
0
360
Featured
See All Featured
Context Engineering - Making Every Token Count
addyosmani
9
640
Mobile First: as difficult as doing things right
swwweet
225
10k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
0
430
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
290
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
GitHub's CSS Performance
jonrohan
1032
470k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.3k
What's in a price? How to price your products and services
michaelherold
247
13k
Optimising Largest Contentful Paint
csswizardry
37
3.6k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
0
3.4k
Transcript
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話 Hatena Engineer Seminar #34 オブザーバビリティの実現と運用編 2025/07/30 id:masayoshi
自己紹介 • id:masayoshi • 株式会社はてな ◦ Platform SRE をしているよ 株式会社はてなでSREとして勤務。
自身の可観測性を高めるために、健康診断に行ったところ、高血圧にひっかかり健康に怯えて生 活をしている。 しかし、エラーバジェットポリシーが設定されていなかったため、食生活の改善は見られない。
今日話すこと • Perlでトレースを使いたい! ◦ OpenTelemetryの導入に関して色々な悩みポイントがあった ◦ 今回はてなが選択したやり方を紹介するよ! • 注意点! ◦
細かい話多め ◦ Perl固有の話多め ◦ パワープレイ多め ◦ メジャーな言語ではそもそも問題になってない話題多め
(個人的)技術選定のときの心構え • あったら使え! ◦ 仕組みがあるのであれば逆らわずに使おう • 組み合わせて使え! ◦ 1個じゃ無理!でも合わせれば解決!ってパターン •
足りなければ作れ! ◦ どうしても足りないなら自分たちで付け足す • 出来たら乗り換えろ! ◦ 世の中は進化している。世の中に追いつかれたら乗り換える
あったら使え! • 世の中は大OpenTelemetry時代、Perl向けOpenTelemetry SDKがあれば使いたい! ◦ あった! ◦ https://github.com/jjatria/perl-opentelemetry • が、検討時
2024年春頃はまだいくつかの問題点があった ◦ まだ実装途中のところも多く、破壊的変更が多い ◦ OTLPのExporter周りの依存ライブラリやパフォーマンスの問題 • OpenTelemetry SDKを導入して終了!というわけにいかなかった
組み合わせて使え! • OpenTelemetry 以外の選択肢で AWS::XRay がある ◦ https://github.com/fujiwara/AWS-XRay ◦ 社内でも採用実績があり、AWS
XRayに送っているチームもいた ▪ トレースだけならXRayのままでも良い ▪ 社内はMackerelで運用しており、OpenTelemetryに対応したトレース機能 の実装を検討していた • OtelCollectorにXRayのトレースを受け取れる awsxrayreceiver がある • XRay を OpenTelemetry に変換して使おう! 正確には「Vaxila」というサービスを事業譲受しており、Mackerelとの統合を検討していた
大まかな方針 • PerlはXRayとしてトレースを取得、送信する • OtelCollector ◦ awsxrayreceiverでOpenTelemetryに変換 ◦ transform processor
で整形 ◦ OTLP exporter でMackerelに送信
XRayの良いところ • 仕様がシンプル! ◦ 特定のJSONフォーマットを作ってUDPで投げるだけ ▪ AWS::XRay も コア部分は500行以下のコードしかない ◦
UDPなので、送信処理が同期的でもボトルネックになりにくい ▪ TCPかつ、複雑なOTLPの処理と比較して軽量 • よって、自分たちでコードの付け足しなどが容易 ◦ OTLPの仕様やOpenTelemetry全体の仕様を把握するのは大変 ▪ 変化も激しい ◦ とりあえずJSONつくってUDPで送れれば良し!は相当楽
(参考)AWS::XRayと計装 • Plack::Middleware::XRay ◦ HTTPリクエストのspanを取るためのミドルウェア • Devel::KYTProf::Logger::XRay ◦ Devel::KYTProfというツールの出力をspanにするモジュール •
Devel::KYTProf::Profiler::DBI ◦ XRayとは直接関係はないが、DBのsqlを表示してくれるモジュール ◦ ↑のモジュールと合わせてXRayにDBのspanを送信できる • 更に詳しく見たい人は実装者のスライドを参照 ◦ https://speakerdeck.com/fujiwara3/yapc-tokyo-2019 XRay の segment = OpenTelemetry の span ここでは全部spanと呼ぶことにするよ
動いたが問題点もあり! • アトリビュート関係 ◦ 特定のアトリビュートのときに awsxrayreceiver でエラーになる ◦ アトリビュートのキー名を自由に設定できない •
トレースIDの伝搬 ◦ W3C Trace Context Headerに対応していない • 自動計装 ◦ 自動で計装されて欲しい
足りなければ作れ! • 後述する自動計装の拡張などもあって、結局自分たちで計装を拡張 ◦ AWS::XRay のwrapper ◦ Devel::KYTProf::Logger::XRay の awsxrayreceiver
対応版 ◦ Plack::Middleware::XRay の awsxrayreceiver 対応版 • やりたいこと ◦ Perlでアトリビュートを直感的に追加できる ◦ トレースがOtel SDKとPerlのXRayで相互に伝搬できるようになる ◦ 自動計装でサクセス!
XRayとawsxrayreceiverの仕様の違い { “hatena”: “waiwai”, "code": { "function.name": "test_func" } }
• awsxrayreceiver では map[string]map[string]any しか許容されない • AWS XRay では map[string]string でも良い 赤字部分がエラーになる
awsxrayreceiverの変換方法が微妙 “code”: { “function.name”: “test_func”, “line.number”: 10, } aws.xray.metadata.code =
{“function.name”:”test_func”, “line.number”:10} • prefixが追加される • 構造がフラットにならない
実際のアトリビュート変換の流れ map[string]map[string]any を満たすJSON
(参考)transform processorの設定 processors: transform/for_awsxray: error_mode: ignore trace_statements: # aws.xray.metadata.* の
prefix を削除 - replace_all_patterns(span.attributes, "key", "^aws\\.xray\\.metadata\\.(.*)", "$$1") # {"":"value"} の場合 value に展開 - replace_all_patterns(span.attributes, "value", "{\"\":\"?([^\"]*)\"?}", "$$1") # {"":["value"]} の場合 ["value"] に展開 - replace_all_patterns(span.attributes, "value", "{\"\":(\\[.*\\])}", "$$1") # エスケープされた改行(\\n)を改行(\n)に戻す - replace_all_patterns(span.attributes, "value", "\\\\n", "\n")
TraceIDの伝搬 • OpenTelemetryで一般的なW3C Trace Context 形式に対応したい • XRayは X-Amzn-Trace-Id Header形式なので相互変換が必要
◦ W3C Trace Context Header ⇔ X-Amzn-Trace-Id Header
TraceIDの伝搬 • W3C Trace Context Header ⇔ X-Amzn-Trace-Id Header 相互変換
00-0123456789abcdef0123456789abcdef-01234567890abcdef-01 Root=1-01234567-89abcdef0123456789abcdef;Parent=01234567890abcdef;Sampled=1 8桁 24桁 32桁 Trace ID 16桁 16桁 Parent ID (親のSpanID) Flags traceparent: X-Amzn-Trace-Id: 実際には他にも仕様があるけど関係あるところを最低限抜き出してます
(参考)Perl豆知識 ~正規表現処理~ my $pattern = qr/^([0-9a-f]{2})-([0-9a-f]{32})-([0-9a-f]{16})-([0-9a-f]{2})$/; my $traceparent = +{};
if ($header =~ $pattern) { $traceparent->{version} = $1; $traceparent->{trace_id} = $2; $traceparent->{parent_id} = $3; $traceparent->{trace_flags} = $4; return $traceparent; } else { return undef; } 文字列処理ならまかせろり!
自動計装 • 楽しいモンキーパッチ方式! ◦ 自動計装モジュールを読み込んだら自動で計装をインジェクトする • ①メジャーなライブラリを読み込んだときに専用の計装を有効にする ◦ Plack::Buiderがあったら、Plack::Middleware::XRay を有効
◦ ロードされるパッケージを確認して読み込み時にコードをインジェクト • ②関数名などを指定したら自動的にSpanを追加してくれる ◦ 今回はパッケージ変数で @TRACE_ENABLE という配列に入っている 関数にSpanをインジェクトする
(参考)自動計装の雰囲気 ~パターン ①~ # 利用側のコード # たったの1行! use XRay::AutoInstrument; builder
{ # enable # "+Plack::Middleware::XRay", # name => "MyApp", # sampling_rate => 1.0, # ; enable "Session", store => "File"; enable "Debug", panels => [ qw(DBITrace Memory Timer) ]; enable "+My::Plack::Middleware"; $app; }; 本来追加すべきコードを 勝手に入れて有効にしてくれる 設定値は環境変数で設定可能にする
(参考)自動計装の雰囲気 ~パターン ②~ package Hatena::De::Wasshoi365; use v5.40; our @TRACE_ENABLE =
qw/slow_function function_1/; sub slow_function () { }; sub function_1 () { }; 手動計装でやる例 capture でwrapする必要がある sub function_1 () { capture “span_name”, sub () { /* 処理 */ return “手動は大変”; }; };
(参考)Perl豆知識 ~Perlは自由~ my $orig_code = "MyPackage"->can("my_func"); *{"MyPackage::my_func"} = sub {
my @args = @_; # 前処理 # 本来のコード実行 $orig_code->(@args); # 後処理 }; MyPackage の my_funcの 実行前後に処理を追加する例 すっごい気軽に書き換えられるよ!! 気軽に書き換えてはいけない
実装した結果 • プロダクション環境でもすでに使われている ◦ GigaViewerやカクヨムで一部のコードが利用されている ◦ はてなの他のサービスでも順次トレースの利用が開始される予定 • トレースの伝搬がOtel ⇔
XRayでシームレスになった ◦ TypeScriptやScala、GoなどのOtel SDKとAWS::XRayで実績あり • 自動計装は現状あんまり使われていない ◦ 手動計装で細かく制御したい人が多い ◦ 工数があまりないプロダクトでは自動計装で片付けられるかも? はてなブックマーク、はてなブログなど https://speakerdeck.com/7474/gigaviewerniokerumackerel-apmdao-ru-noli-ce
今後の展望 • 更に拡張するぞ!と言いたいところだが ◦ 出来たら乗り換えろ!ということで ここ1,2年でPerlのOpenTelemetry SDKの実装がだいぶ進んだ ◦ 問題ないならこれらのコードを捨てて乗り換えたい •
社内オレオレライブラリのメンテより、OpenTelemetry SDKにコント リビュートしたほうが世の中のため、自分たちのためになる • とはいえ、まだまだPerlのトレースは発展途上、 バランスを見ながら取捨選択していきたい
OpenTelemetryやo11yに興味ある エンジニアを募集しております