TelemetryAPIでLambda関数の外側を覗く

Transcript

1. TelemetryAPIでLambda関数の外側を覗く Media-JAWS × JAWS-UG 静岡支部 × 浜松支部 コラボ会 2026年5月22日（金）
2. TelemetryAPIでLambda関数の外側を覗く Media-JAWS × JAWS-UG 静岡支部 × 浜松支部 コラボ会 2026年5月22日（金）
3. 自己紹介 加藤 寛士（かとう ひろし） • クラウドエンジニア • JAWS-UG 名古屋運営 • AWS community builders(serverless) @Hircha12
4. Otel(OpenTelemetry)を初めて知る 「システムの内部を標準化された形式で観測できる」 カンファレンスで知ったこと ・OpenTelemetryはベンダー依存しないオブザーバビリティ標準規格 ・Traces / Metrics / Logsを同じ形式で収集できる ・DatadogやNewRelicも内部的にOTelを使っている
5. OpenTelemetryとは？ オブザーバビリティ標準規格 主な概念 Traces：リクエストの全体の流れ Metrics：数値データ （CPU・レイテンシー） Logs：テキストログ （アプリケーション出力） 主なコンポーネント SDK：アプリに計測を埋め込む Collector：データを受け取り ・加工・転送 Exporter：バックエンドへ送信 なぜ大事か ベンダーロックインしない Datadog・New Relicなどへ同じ コードで送信できる 「計測の仕方」を標準化し、アプリ・インフラが同じ形式でテレメトリーを出せるようになる
6. LambdaにTelemetryAPIがあった Lambdaのディベロッパーガイドを眺めていたところ…
7. TelemetryAPIとは？(概念図)
8. TelemetryAPIを使うと… 通常のLambda関数の実装からは「どこで何ミリ秒かかっているか」がわからない Lambda 関数から見えること ✓ 自分で出力したログ ✓ returnした結果 → 関数の「内側」しか見えない → 実行時間はCloudWatchLogsの Duration / Init Durationのみ （合計値・内訳なし） 実はLambdaはRuntimePlatform ✓ Runtimeの起動に何ms? ✓ importに何ms? → Lambda関数の「外側」で起きていることが CloudWatchLogsで見ることができない
9. TelemetryAPIで見える世界 Before：Lambda関数側の視点 API Gateway等から実行 ↓ lambda_handler() を書く ↓ CloudWatchLogs → Lambda =「関数を実行するもの」 → 遅ければ「コールドスタートが遅い」 としか言えなかった → 詳細な原因は語れず After：TelemetryAPIで見える世界 Lambda Runtime Environment └─ Extension Init（何ms?） └─ Runtime Init（何ms?） └─ Module Import（何ms?） └─ lambda_handler()（何ms?） → Lambda = RuntimePlatform → コールドスタートは複数処理の合計 → どの処理が重いか特定できる TelemetryAPI を使うことで、Lambda関数の「外側」で何が起きているかが分かる
10. TelemetryAPIでLambda関数の外側を観測 Lambda関数の変更は不要 Extension(レイヤー)を追加するだけで、Runtime内部が見えるようになる Lambda関数の外側にExtensionを追加 Collectorをレイヤーとして追加 TelemetryAPIでRuntime内部をサブスクライブ platformイベント（initStart / initReport / runtimeDone など） functionログ（print() の出力）を同じ時系列で受信 各処理を個別に計測 INIT_START → Extension Init → Runtime Init → Module Import
11. Lambdaの内部Phase 「Init Duration: 2,500ms」では内訳は不明だが、 Telemetry API なら各処理を個別計測できる INIT START 実行環境 起動開始 → Extension Init 拡張機能 初期化 → Runtime Init ランタイム 起動 → Module Import import boto3 など実行 → INIT REPORT 初期化完了 レポート Lambda関数の実行ログにある Init Duration はこの全体合計のみ（内訳は不明） Telemetry API で各処理の時間を個別に取得できる！どの処理が重いか特定できる
12. 拡張機能の作り方 — 4ステップ
13. INITからSHUTDOWNまで、全Phaseが見える
14. INITからSHUTDOWNまで、全Phaseが見える
15. 関数 × Collector × CloudWatch の関係
16. platformとfunctionとして受け取れる
17. Cold Start の内部構造
18. 色々やってみて違いを見てみる • Memory変更でINITは短縮する？ • ARM64で何が変わる？ • boto3 importでINITはどれだけ増える？
19. と、思ったのですが、、、
20. ADOT？？？
21. ADOT
22. ADOT
23. OpenTelemetry Collector とは？ テレメトリーの収集・加工・転送を担うエージェント Receiver テレメトリーを受信 OTLP / HTTP / gRPC Processor 加工・バッファリング batch / memory_limiter Exporter バックエンドへ転送 Jaeger / OTLP / X-Ray 公式配布の 4 種類のビルド otelcol-otlp OTLP受信・送信のみ。超軽量 otelcol OSSとして標準的なコンポーネント入り otelcol-k8s otelcol + Kubernetes向け追加 otelcol-contrib 全コンポーネント入り。巨大だが何でもできる 自分でCollectorを作った意義 ✓ register → subscribe → HTTP受信 の流れが理解できた ✓ print() でそのままCloudWatchに流せた → でも本番で使うにはもっと考慮が必要… → AWS公式版を発見した！ Receiver / Processor / Exporter のパイプラインを設定ファイルで自由に組み合わせられる
24. ADOT — AWS が公式に配布する Collector AWS Distro for OpenTelemetry ADOT とは otelcol-contrib をベースに AWS向けコンポーネントだけを追加した軽量ビルド 同梱されているもの ・AWS X-Ray Exporter ・Amazon CloudWatch Exporter ・Amazon Managed Service for Prometheus ・AWS ECS / EKS リソース検出 配布形態 ・Lambda レイヤーとして追加可能 ✓ ・ECS / ECS Fargate / EC2 / EKS 対応 自作 vs ADOT 自作C ollector ADOT セキュリティ 自己責任 AWS検証済み AWS統合 自分で実装 同梱済み Lambda対応 レイヤー自作 公式レイヤーあり 保守 自分でアップデー ト AWSがサポート 結論：仕組みを理解するために自作したのは正解。本番では ADOT をレイヤーに追加するだけ で同じことがで きる。
25. 学び TelemetryAPIを自分で動かしてみて、 LambdaとOpenTelemetryの理解が変わった。 • Lambdaは「関数を実行するもの」ではなくRuntimePlatform として動いている • 関数コードを一切変えずに、レイヤーを追加するだけで 内部観測できる • OpenTelemetryは標準規格であり、利用可能なコレク ターが配布されている(自作しなくてもいい)