Seeing Through Serverless: ADOT と CloudWatch Application Signals で実現する AWS Lambda のオブザーバビリティ（日本語版）/ Seeing Through Serverless (Japanese Edition)

AWS Ambassador・Top Engineer・Jr.Champion 大集結（2026年8月4日）で発表した資料です。AWS Community Day Singapore 2026 で登壇した英語版 https://speakerdeck.com/seike460/seeing-through-serverless-observability-for-aws-lambda-with-adot-and-cloudwatch-application-signals の日本語版です。ADOT と CloudWatch Application Signals を使ったサーバーレスのオブザーバビリティについて話しました。

Transcript

1. OSEKKAI × TECHNOLOGY Seeing Through Serverless 〜ADOTとCloudWatch Application Signalsで 実現するAWS Lambdaの可観測性〜 Fusic Tech Live Vol.32 2026-08-22 Fusic Co.,Ltd. Shiro Seike (@seike460)
2. 自己紹介 OSEKKAI × TECHNOLOG Y 清家 史郎 (@seike460) SHIRO SEIKE 技術コミュニティ室長 / シニアエバンジェリスト ・AWS Ambassador ・2025-2026 Japan AWS Top Engineers ・AWS Community Builder Serverless ・JAWS DAYS 2026 実行委員長 (1,400+名) 2 ©Fusic Co., Ltd.
3. Serverlessは運用を任せられる — しかし障害の調査は任せられない 障害が起きたとき、どこで何が失敗したのか分からない
4. 1 標準的なServerless構成と、見えない場所 ブラックボックス 4 ©Fusic Co., Ltd.
5. 非同期Serverlessの全体構成 HTTP API → api Lambda → custom bus → queue + DLQ → worker Lambda ← 呼び出し元へ202 Acceptedをすぐ返す DynamoDB 監査記録 (S3) + 定期batch 202 Acceptedは受付完了の応答です。処理が成功したかどうかは、まだ分かりません。 HTTP API自体はX-Rayのactive tracingに対応していません。アクセスログと、Lambda 以降のトレースを組み合わせて追跡します。 ©Fusic Co., Ltd. 5
6. Request 7f3a41がどこで失敗したか、 今のlogでは分からない API Gateway access log: 202まで → api Lambda PutEvents成功まで ✕ bus request単位のlogなし → queue queue depthのみ → worker Lambda batch単位のlog 手がかりはサービスごとにバラバラ。追跡は✕の位置で途切れる 6 ©Fusic Co., Ltd.
7. 2 「このrequestは本番で今、正常に動いているか」に3つのsignalで答える LambdaのObservability 7 ©Fusic Co., Ltd.
8. 構造化logだけではrequest全体を追跡できない の に含まれる1行 // api function log const line = { level: "info", requestId: "7f3a41", path: "/items/sync", status: 202, latencyMs: 84, }; // grep // worker invocation 構造化されていて 側の できる。ただし、 につながる情報がない 8 ©Fusic Co., Ltd.
9. handler codeではなくruntimeを計装する handler code — 変更しない runtime — Layer + SDK + wrapperを追加 telemetry → CloudWatch / X-Ray 実行環境はすぐ消えるため、agentもsidecarも置けない。計装はruntime側で行う 9 ©Fusic Co., Ltd.
10. 3 ADOT = AWS Distro for OpenTelemetry。 CJS bundle + Layer + wrapperで実現する ADOTによるゼロコード計装 10 ©Fusic Co., Ltd.
11. ADOTとは — AWSがサポートするOpenTelemetry OpenTelemetry trace・metric・logを集める 標準仕様 (OSS) AWSがビルド・ テスト・サポート ADOT AWS Distro for OpenTelemetry Lambda向けは Layerで提供 Lambda Layer handlerは変更しない 中身はOpenTelemetryそのもの。AWSが動作確認済みの形で配布している 11 ©Fusic Co., Ltd.
12. 設定の中心はこれ — ハンドラーのコードは変更しない ゼロコード計装の中心となる設定 // CDK — fn.addLayers(LayerVersion.fromLayerVersionArn(fn, "Otel", "arn:aws:lambda:" + region + ":615299751070" + ":layer:AWSOpenTelemetryDistroJs:14")); // 615299751070 AWS ADOT layer は が公開している の所有アカウント fn.addEnvironment("AWS_LAMBDA_EXEC_WRAPPER", "/opt/otel-instrument"); fn.addEnvironment("OTEL_SERVICE_NAME", "api"); // + active tracing: ACTIVE // + Application Signals IAM ( ) に必要な 権限 定義は省略 12 ©Fusic Co., Ltd.
13. 共通helperで計装設定を統一する 実際の を要約したもの // helper export function instrumentLambda(fn, serviceName) { assertActiveTracing(fn); fn.addLayers(fromArn(otelLayerArn(region))); fn.addEnvironment("AWS_LAMBDA_EXEC_WRAPPER", "/opt/otel-instrument"); fn.addEnvironment("OTEL_SERVICE_NAME", serviceName); fn.role.attachInlinePolicy(applicationSignalsPolicy); } // stack test Layer environment policy tracing で 、 、 、 を検証する 13 ©Fusic Co., Ltd.
14. 4 1つのrequestを複数のtraceで関連付ける 非同期処理をまたぐTrace 14 ©Fusic Co., Ltd.
15. TraceでLogにない呼び出し関係を確認する api: POST /items/sync (Lambda invocation) DynamoDB: PutItem EventBridge: PutEvents Initialization — cold start invocation 時のみ、 の外側 の構造。時間は省略) 自体のoverheadは分けて測れない — A/B測定が必要) (trace (Layer 15 ©Fusic Co., Ltd.
16. 非同期のつなぎ目の先は、別のtraceとしてlinkされる 理想: 1本のtrace 実際: 2本のtraceをlink trace 7f3a41 trace A api ↓ bus ↓ queue ↓ worker api ↓ bus 1本のtraceが最初から最後までつながる想定 ⇠ linked ⇢ trace B queue ↓ worker linkをたどって両方向に追跡できる X-Ray: trace linking / OTel: span links 16 ©Fusic Co., Ltd.
17. Probeでtrace linkを検証する と互換性のある // ADOT Layer CJS entry point const handler = async () => { await events.send(new PutEventsCommand({ Entries: [{ EventBusName: bus, Source: "probe", DetailType: "trace-probe", Detail: "{}" }], })); }; module.exports = { handler }; // rule probe handler // CLI put-events // trace context bus // emitter Lambda の後段にある と組み合わせる の は計装されていないため が へ入らない 計装済みの から送ると入る 17 ©Fusic Co., Ltd.
18. invocation spanは全件取得、indexは必要な分だけ new xray.CfnTransactionSearchConfig(this, "Tx", { indexingPercentage: stage === "preview" ? 100 : 1, }); // Lambda invocation span sampled flag // child span head sampling は Lambda spans capture invocation span: 常に全件 child span: head sampling次第 は の設定に従う Transaction Search に依存せず取得される index trace summaryのindex作成割合 preview: 100% production: 1% Transaction Searchは、CloudWatchへのspanの取り込みと、X-Rayのtrace summaryの index作成を別々に制御する機能です。 ©Fusic Co., Ltd. 18
19. 5 Application Signalsがmetricの生成と集計を自動化する MetricとSLO 19 ©Fusic Co., Ltd.
20. オンコールで見るメトリクスを3つに絞る Point.01 Latency — 処理にかかった時間 Point.02 Error — HTTP 4xxのリクエストエラー Point.03 Fault — HTTP 5xxまたはspan statusのerror 標準のアプリケーションメトリクスは、この3つです。 20 ©Fusic Co., Ltd.
21. Discovery権限はアカウントとRegionごとに1回 権限は には 、 と ごとに一度だけ設定する 、 を別途設定する // Discovery account Region // Lambda Layer wrapper IAM policy new appsignals.CfnDiscovery(this, "Signals", {}); 各 Latency / Error / Fault Layerを付けたLambda関数 — span → Application Signals → Application Map SLO 自動生成されますが、無料ではありません。 spanの取り込みとtrace summaryのindex作成を含め、料金は現行のCloudWatch料金体 系に従います。 ©Fusic Co., Ltd. 21
22. 計装済みserviceはApplication Mapに自動で載る api worker batch probe emitter probe handler telemetry → Application Map + health view Latency / Error / Fault を自動収集 計装済みservice 5つ・standard metric 3種・custom metric codeは0行 22 ©Fusic Co., Ltd.
23. SLOはrepositoryでコードとして管理する new appsignals.CfnServiceLevelObjective(this, "Avail", { name: "api-availability", sli: { /* availability SLI */ }, goal: { attainmentGoal: 99.5, interval: { rollingInterval: { duration: 7, durationUnit: "DAY" } } }, }); // service 2 SLO: p99 <= 500 ms // SLO burn-rate alarm // 14.4× / 1h 6× / 6h の 定義 同じ に つ目の とは別に 、 を設定する 23 ©Fusic Co., Ltd.
24. Lambdaが動かない経路にapplication spanはない この経路ではLambdaが動作しないため、application spanは生成されない DynamoDB Streams → EventBridge Pipes → Firehose → S3 (WORM audit) この経路はLambdaのauto-instrumentationでは監視できない DynamoDBからS3までの件数を毎日照合して監視する 24 ©Fusic Co., Ltd.
25. 6 OpenTelemetryのdataとAWS固有の運用を分けて考える 再利用できる計装 25 ©Fusic Co., Ltd.
26. OTel計装はそのまま、AWS固有の運用は作り直し Lambda + ADOT layer OTel span → 今はX-Ray形式 移行時に切替が必要 維持 — OTel instrumentationと semantic conventions 現在: CloudWatch + X-Ray 移行時: collector + OTLP exporterを追加 作り直す — exporter、認証、network、 SLO、alarm、Application Map、 trace contextの引き継ぎ 26 ©Fusic Co., Ltd.
27. AWSは新規のX-Ray計装にOpenTelemetryを推奨 2026-02 2026-08時点 EOL X-Ray SDKsが maintenance modeへ移行 公式の移行先は OTel / ADOT 未公表 以後はsecurity fixのみ このセッションで示したLayerが 推奨ルート 現行のAWS timelineに終了日の 記載はない 27 ©Fusic Co., Ltd.
28. L a m b d a を 計 装 し 、 S L O で 運 用 す る Point.01 ハンドラーのコードを変えずにOTelで計装できる Point.02 Application SignalsでメトリクスとSLOを運用する Point.03 計装はOTelなので再利用しやすい (運用は作り直す) ▶ まずは1つのLambda関数から始める — CJS bundle、Layer、wrapper、IAM、active tracing を確認する。service nameは必要に応じて設定する。 28 ©Fusic Co., Ltd.