非同期処理のトラブルシューティングを加速！Google Cloud × OpenTelemetry でトレースを繋ぐ / Accelerate Async Troubleshooting! Connecting Traces with Google Cloud & OpenTelemetry

2025 年 7 月 15 日から公開されている Cloud Operator Days Tokyo 2025 にて登壇した「非同期処理のトラブルシューティングを加速！Google Cloud × OpenTelemetry でトレースを繋ぐ」の講演資料です。
詳細はこちらをご覧ください。（https://cloudopsdays.com/ondemand）

Transcript

1. © NTT Communications Corporation All Rights Reserved. 非同期処理のトラブルシューティングを加速！ 
 Google Cloud × OpenTelemetry でトレースを繋ぐ 
 2025年7月15日
 NTTドコモビジネス株式会社 

2. © NTT Communications Corporation All Rights Reserved. 2 Tomonori Hayashi • NTT コミュニケーションズ株式会社 ◦ ノーコード AI 開発ツール「Node-AI」の開発/運用 ◦ ソフトウェアエンジニア ▪ Front：TypeScript - React/Next.js ▪ Infra：Google Cloud • Google Cloud Partner Top Engineer 2024 - 2025 • Google Cloud Tech Blog Challenge 2024 個人カテゴリ受賞 • Google Cloud All Certifications • Community ◦ Jagu’e’r （Google Cloud 公式ユーザーコミュニティ） ▪ Evangelist ▪ オブザーバビリティ分科会 • Conference Staff ◦ SRE Kaigi 2026
3. © NTT Communications Corporation All Rights Reserved. 3 アジェンダ 
 
 01. 非同期処理の全体像と設計ポイント 
 02. Google Cloud で構築する非同期処理 
 03. 非同期処理のオブザーバビリティ 

4. © NTT Communications Corporation All Rights Reserved. 4 目次
 01. 非同期処理の 
 全体像と設計ポイント 

5. © NTT Communications Corporation All Rights Reserved. 5 同期処理の課題を解決するために、タスクの完了を待たずに次の処理へ進む「ノンブロッキング」なアプローチである 非同期処理には大きなメリット
 同期処理と 非同期処理 
 ユーザー体験と応答性の向上 
 スケーラビリティとスループットの向上 
 システムの回復性と耐障害性の向上 
 • 時間のかかる処理をバックグラウンドに「オフロード」する
 • ユーザーには即座に応答を返す
 → ユーザーは待たさないことで、顧客満足度の低下を防ぐ
 • サービスを非同期メッセージで疎結合にすることで、各サービスは自身の 負荷に応じて独立してスケーリングする
 → システム全体のスループットが最大化
 • サービス間にメッセージキューを挟むことで、下流のサービスが一時的に 障害で停止しても、リクエストはキューに保持する
 → サービス復旧後に再処理し、システム全体の回復力を向上
 ユーザー体験の低下 
 リソース利用効率の悪化 
 連鎖的な障害の誘引 
 • 時間のかかる処理を同期的に実行すると処理完了まで UI が止まる
 • ユーザー応答のない画面で待つことを強いられる
 → 直接的な顧客満足度の低下
 • I/O 処理の完了を待つ間、実行スレッドは何もせずにただ待機する
 • CPU やメモリといった計算リソースの無駄遣い
 → システム全体のスループットを著しく低下
 • サービス間の同期的な連携では、呼び出し先のサービスで発生した遅延 や障害が即座に呼び出し元のサービスに伝播
 → 小さな問題がシステム全体を停止させる「連鎖的障害」を誘引
 同期処理の限界 
 非同期処理のメリット 

6. © NTT Communications Corporation All Rights Reserved. 6 非同期処理の 運用の難しさ 
 メッセージキューを介することで一連の呼び出しがリクエストスコープ内で分断される
 
 　　
 ？
 ？
 ？
 「ユーザーからのリクエストは成功だが、裏側の処理がどうなったかわからない」
 「どのメッセージが、どの処理を引き起こしたのか追跡できない」といった事象を引き起こす
7. © NTT Communications Corporation All Rights Reserved. 7 非同期処理設計の 3 つの柱
 非同期処理を採用することは、パフォーマンスやスケーラビリティの面でメリットを享受できる
 一方で、従来の処理ではあまり意識する必要のなかった新たな課題を考慮する必要がある
 
 
 
 
 
 
 
 
 
 
 
 冪等性
 分離と制御 
 追跡可能性 
 重複を前提とした安全な再処理 
 非同期システムの通信は
 「少なくとも 1 回（at-least-once）」配信 
 を基本としている
 
 メッセージの重複は障害でなく前提 
 として設計する必要がある
 
 この前提のもと
 安全なリトライや再処理を保証することで 
 信頼性を向上する ことが重要な点である
 障害の波及を防ぎフローを制御 
 同期システムでは 1 つのサービスの
 障害がシステム全体に波及する
 「連鎖的障害」 が発生しやすい
 
 非同期システムでは
 分離で障害の他サービスへの波及を防ぎ
 制御でプロセスがどう振る舞うかを管理する
 
 適切な「分離」と「制御」によってシステムの 
 回復力を高める ことが重要な点である
 分断された処理の追跡 
 非同期システムでは
 リクエストが複数のサービスやキューを横断し
 処理の全体像が「ブラックボックス」 化する
 
 個々のサービスのログはサイロ化しており 
 それらを連結する仕組み がなければ
 エンドツーエンドの追跡は極めて困難である 
 
 全ての処理に共通のIDを伝播させ 
 分断された処理を連結し可視化することで 
 可観測性を向上する ことが重要な点である

8. © NTT Communications Corporation All Rights Reserved. 8 目次
 02. Google Cloud で 
 構築する非同期処理 

9. © NTT Communications Corporation All Rights Reserved. 9 Google Cloud で構築する 非同期処理アーキテクチャ 
 一例として、直近で構築した AI モデルの学習用の非同期処理アーキテクチャを紹介

10. © NTT Communications Corporation All Rights Reserved. 10 Google Cloud で構築する 非同期処理アーキテクチャ 
 一例として、直近で構築した AI モデルの学習用の非同期処理アーキテクチャを紹介
 ① メッセージングとタスクキュー 
 非同期処理の契機となる 
 情報（イベントやタスク）を伝達・保持する役割 
 ③ イベントルーティングとワークフロー管理 
 イベントを適切な実行者に届ける役割 
 ② コンピューティング 
 実際にビジネスロジックを実行する役割 

11. © NTT Communications Corporation All Rights Reserved. 11 メッセージング とタスクキュー 
 Google Cloud には 2 つの主要なサービスがあるが、選択の鍵は「Implicit（暗黙的な通知）」 もしくは
 「Explicit（明示的な命令）」 か、という設計思想の違いにある
 Pub/Sub 
 Cloud Tasks 
 特徴 • 暗黙的な通知 • リアルタイム配信 ピックアップ機能 • シークと再生 確認応答済みのメッセージを未確認状態にして、メッ セージの再配信を強制 • デッドレタートピック 確認応答が取れないメッセージをデッドレタートピック に転送して一時的に退避 特徴 • 明示的な命令 • 信頼性の高い非同期タスク実行 ピックアップ機能 • メッセージの重複排除 キューに対して同一名称のタスクを送信することがで きないことで、重複排除が担保可能 • 構成可能な再試行 メッセージを Push 後に規定時間以内に 200~299 の HTTP レスポンスコードを受け取る規定回数の再試 行を実施
12. © NTT Communications Corporation All Rights Reserved. 12 メッセージング とタスクキュー 
 Google Cloud には 2 つの主要なサービスがあるが、選択の鍵は「Implicit（暗黙的な通知）」 もしくは
 「Explicit（明示的な命令）」 か、という設計思想の違いにある
 Pub/Sub 
 Cloud Tasks 
 特徴 • リアルタイム配信 • 暗黙的な通知 ピックアップ機能 • シークと再生 確認応答済みのメッセージを未確認状態にして、メッ セージの再配信を強制 • デッドレタートピック 確認応答が取れないメッセージをデッドレタートピック に転送して一時的に退避 特徴 • 信頼性の高い非同期タスク実行 • 明示的な命令 ピックアップ機能 • メッセージの重複排除 キューに対して同一名称のタスクを送信することがで きないことで、重複排除が担保可能 • 構成可能な再試行 メッセージを Push 後に規定時間以内に 200~299 の HTTP レスポンスコードを受け取る規定回数の再試 行を実施 引用：https://cloud.google.com/tasks/docs/comp-pub-sub?hl=ja Implicit（暗黙的な通知）と Explicit（明示的な命令） Pub/Sub 
 Cloud Tasks 
 特徴 • 暗黙的な通知 • リアルタイム配信 特徴 • 明示的な命令 • 信頼性の高い非同期タスク実行 Cloud Tasks の目的は サブスクライバーの実行の制御と管理の提供 サブスクライバーを指定して 処理を実行させる タスク実行のタイミング・レート・再試行ポリシー を細かく制御可能 = 実行の保証が強い Pub/Sub の目的は パブリッシャーとサブスクライバーの分離 パブリッシャーはサブスクライバーのことを 知らなくて良い システム全体の結合度を極めて下げることが可能 独立した開発・スケーリング・拡張性
13. © NTT Communications Corporation All Rights Reserved. 13 メッセージング とタスクキュー 
 Google Cloud には 2 つの主要なサービスがあるが、選択の鍵は「Implicit（暗黙的な通知）」 もしくは
 「Explicit（明示的な命令）」 か、という設計思想の違いにある
 Pub/Sub 
 Cloud Tasks 
 特徴 • リアルタイム配信 • 暗黙的な通知 ピックアップ機能 • シークと再生 確認応答済みのメッセージを未確認状態にして、メッ セージの再配信を強制 • デッドレタートピック 確認応答が取れないメッセージをデッドレタートピック に転送して一時的に退避 特徴 • 信頼性の高い非同期タスク実行 • 明示的な命令 ピックアップ機能 • メッセージの重複排除 キューに対して同一名称のタスクを送信することがで きないことで、重複排除が担保可能 • 構成可能な再試行 メッセージを Push 後に規定時間以内に 200~299 の HTTP レスポンスコードを受け取る規定回数の再試 行を実施 引用：https://cloud.google.com/tasks/docs/comp-pub-sub?hl=ja 今回は分離を優先 し制御はコンピューティングに任せる Pub/Sub 
 Cloud Tasks 
 特徴 • リアルタイム配信 • 暗黙的な通知 特徴 • 信頼性の高い非同期タスク実行 • 明示的な命令 Cloud Tasks の目的は サブスクライバーの実行の制御と管理の提供 サブスクライバーを指定して 処理を実行させる タスク実行のタイミング・レート・再試行ポリシー を細かく制御可能 = 実行の保証が強い Pub/Sub の目的は パブリッシャーとサブスクライバーの分離 パブリッシャーはサブスクライバーのことを 知らなくて良い システム全体の結合度を極めて下げることが可能 独立した開発・スケーリング・拡張性
14. © NTT Communications Corporation All Rights Reserved. 14 コンピューティング 
 非同期処理におけるコンピューティングの選択肢は大きく二つ、「Cloud Run」と「Batch」を取り上げる
 Cloud Run 
 Batch 
 特徴 • Services, Jobs, Functions といった ユースケースに沿った提供形態がある ピックアップ機能 • 同時実行制御（Services） 1 コンテナインスタンスあたり最大 1000 件の同時リ クエストを処理可能 • 並列処理（Jobs） 1 つのジョブを複数タスクに分割して、多数のコンテ ナインスタンスで並列実行可能 特徴 • VM ベースの大規模バッチ処理向け • HPC や長時間計算のワークロード ピックアップ機能 • 高度なマシン構成 vCPU、メモリ、ディスクに加え GPU の利用が可能と いった高い計算力にあった構成が可能 • 優先度とリトライ ジョブに優先順を付与したり、失敗時のリトライ戦略 を定義可能
15. © NTT Communications Corporation All Rights Reserved. 15 コンピューティング 
 Cloud Run は提供形態によって性質が大きく異なるので、それぞれで詳しく比較する
 Google Cloud のコンピューティングサービスはイベント駆動での連携がしやすくなっている
 Cloud Run services 
 Cloud Run jobs 
 Batch 
 Cloud Run functions 
 最大実行時間
 GPU利用
 CPU/メモリ上限 
 ジョブ実行環境
 1Hour GA : 24Hour Preview : 7Days 14Days Enable (asis-northeast1 Disable) Disable Enable 8vCPU / 32GB 8vCPU / 32GB 896vCPU / 224GB Cloud Run Cloud Run Compute Engine Second Gen : Cloud Run First Gen : Google Internal Second Gen : 4vCPU / 16GB First Gen : 2vCPU / 8GB Disable HTTP Trigger : 1Hour Event Trigger : 9Minutes
16. © NTT Communications Corporation All Rights Reserved. 16 コンピューティング 
 時間のかかる処理をオフロードする上では「最大実行時間」や AI/ML モデルの学習/推論といった場合には
 「GPU 利用」がポイントになる
 
 ※ 2025.06 時点のリリースノート参照
 Cloud Run services 
 Cloud Run jobs 
 Batch 
 Cloud Run functions 
 最大実行時間
 GPU利用
 CPU/メモリ上限 
 ジョブ実行環境
 1Hour GA : 24Hour Preview : 7Days 14Days Enable (asis-northeast1 Disable) Disable Enable 8vCPU / 32GB 8vCPU / 32GB 896vCPU / 224GB Cloud Run Cloud Run Compute Engine Second Gen : Cloud Run First Gen : Google Internal Second Gen : 4vCPU / 16GB First Gen : 2vCPU / 8GB Disable HTTP Trigger : 1Hour Event Trigger : 9Minutes
17. © NTT Communications Corporation All Rights Reserved. 17 コンピューティング 
 最大実行時間が要件内であり、周辺サービスとの親和性、盛り上がっているサービスでありアップデートの恩恵を享 受しやすい Cloud Run jobs を採用
 
 Cloud Run jobs 上で動かすアプリケーションで冪等性を担保 する
 Cloud Run services 
 Cloud Run jobs 
 Batch 
 Cloud Run functions 
 最大実行時間
 GPU利用
 CPU/メモリ上限 
 ジョブ実行環境
 1Hour GA : 24Hour Preview : 7Days 14Days Enable (asis-northeast1 Disable) Disable Enable 8vCPU / 32GB 8vCPU / 32GB 896vCPU / 224GB Cloud Run Cloud Run Compute Engine Second Gen : Cloud Run First Gen : Google Internal Second Gen : 4vCPU / 16GB First Gen : 2vCPU / 8GB Disable HTTP Trigger : 1Hour Event Trigger : 9Minutes
18. © NTT Communications Corporation All Rights Reserved. 18 イベントルーティング とワークフロー管理 
 Google Cloud サービスで発生したイベントをルーティングすることに特化した「Eventarc」と
 各サービスを連携させた処理のオーケストレーションに特化した「Workflows」が存在する
 Eventarc 
 Workflows 
 特徴 • イベントのルーティングに特化 • サービス間を分離して疎結合とする ピックアップ機能 • 標準化による統一されたイベント連携 従来はイベントを発生させるサービスごとに異なるイ ベントリッスンが必要だったが解消された 特徴 • 複数サービスをまたがる処理の オーケストレーションに特化 ピックアップ機能 • 柔軟なワークフロー構成 シーケンシャルな実行以外にも条件分岐や繰り返し 並列実行といった柔軟なワークフローの構成が可能
19. © NTT Communications Corporation All Rights Reserved. 19 イベントルーティング とワークフロー管理 
 Pub/Sub からのメッセージを受け取りを Workflows が各種処理を連結とデータの受け流しを行う
 Eventarc 
 Workflows 
 特徴 • イベントのルーティングに特化 • サービス間を分離して疎結合とする ピックアップ機能 • 標準化による統一されたイベント連携 従来はイベントを発生させるサービスごとに異なるイ ベントリッスンが必要だったが解消された 特徴 • 複数サービスをまたがる処理の オーケストレーションに特化 ピックアップ機能 • 柔軟なワークフロー構成 シーケンシャルな実行以外にも条件分岐や繰り返し 並列実行といった柔軟なワークフローの構成が可能
20. © NTT Communications Corporation All Rights Reserved. 20 Google Cloud で構築する 非同期処理アーキテクチャ 
 Cloud Run jobs のアプリケーションロジックで冪等性を担保 
 Pub/Sub と Eventarc によりイベント駆動で処理を開始 
 Pub/Sub でサービスを分離 して、Workflows と Cloud Run jobs で再実行などの処理を制御 
 Cloud SQL への書き込みは Cloud Run services からのみとして DB トランザクションをシンプルに 

21. © NTT Communications Corporation All Rights Reserved. 21 目次
 03. 非同期処理の 
 オブザーバビリティ 
 - Pub/Sub × OpenTelemetry - 

22. © NTT Communications Corporation All Rights Reserved. 22 非同期処理の オブザーバビリティの難しさ 
 同期処理では、一連の呼び出しが 1 つのリクエストスコープ内に収まるため、OpenTelemetry などを用い際に鍵とな るトレースコンテキストが伝播しやすい 
 コンテキスト伝播の流れ 

23. © NTT Communications Corporation All Rights Reserved. 23 非同期処理の オブザーバビリティの難しさ 
 一方で非同期処理では、Pub/Sub や Cloud Tasks のようなメッセージングサービスを介した場合に、コンテキストが 断絶される 
 
 パブリッシャーとサブスクライバーの処理を 1 つのトランザクションとして追跡するのが非常に困難 
 コンテキスト伝播の流れ 

24. © NTT Communications Corporation All Rights Reserved. 24 Pub/Sub × OpenTelemetry でシームレスな伝播 
 従来、非同期処理でトレースコンテキスト伝播したい時には手動でメッセージの属性付与してサブスクライバー側で抽 出することが必要あった
 コンテキスト伝播の流れ 
 パブリッシャーがメッセージ属性に
 トレースコンテキストをふ
 パブリッシャー側の実装としてトレースコンテキストを
 メッセージ属性に付与する必要がある
 サブスクライバー側の実装としてトレースコンテキストを
 メッセージ属性から抽出して後続の処理に適用する

25. © NTT Communications Corporation All Rights Reserved. 25 Pub/Sub × OpenTelemetry でシームレスな伝播 
 Google Cloud の Pub/Sub クライアントライブラリにはこの課題を解決すべく、
 Enable OpenTelemetry Tracing オプション が存在し、有効化によりトレースコンテキストが自動伝播する
 Pub/Sub クライアントのオプションを有効化するだけ
 パブリッシャー 
 Pub/Sub クライアントのオプションを有効化するだけ
 もしくはトレース ID を Workflows から環境変数として受け取る
 サブスクライバー 

26. © NTT Communications Corporation All Rights Reserved. 26 Pub/Sub × OpenTelemetry でシームレスな伝播 
 Google Cloud の Pub/Sub クライアントライブラリにはこの課題を解決すべく、
 Enable OpenTelemetry Tracing オプション が存在し、有効化によりトレースコンテキストが自動伝播する
 Pub/Sub クライアントのオプションを有効化するだけ
 メッセージングキュー 
 パブリッシャー 
 Pub/Sub クライアントのオプションを有効化するだけ
 もしくはトレース ID を Workflows から環境変数として受け取る
 サブスクライバー 

27. © NTT Communications Corporation All Rights Reserved. 27 Pub/Sub と OpenTelemetry があれば最小限の実装で非同期処理のオブザーバビリティを実現可能
 非同期処理でも 1 つのトランザクションとして処理を可視化できる
 Pub/Sub × OpenTelemetry でシームレスな伝播 
 Publisher Subscriber Publisher Pub/Sub Client パブリッシャーの実装 
 サブスクライバーの実装 

28. © NTT Communications Corporation All Rights Reserved. 28 サブスクライバーでエラーが発生しても、トレースを見ればどの処理で失敗したかが明確
 各スパンにはログが紐づいており、メッセージの内容と合わせてデバッグが可能 に
 Pub/Sub × OpenTelemetry でシームレスな伝播 
 Publisher Publisher Pub/Sub Client Subscriber エラースパン 

29. © NTT Communications Corporation All Rights Reserved. 29 まとめ
 非同期処理の運用の難しさ
 
 ◼ メッセージキューを介した処理はコンテキストが断絶し、パブリッシャーでの処理とサブスクライバーでの処理の関係性 が見えなくなる
 
 ◼ どの処理がどのリクエストに起因しているのかが追跡できず、障害発生時の原因特定に膨大な時間を要した
 
 
 設計のポイントとなる三本柱
 
 ◼ この難しさを乗り越えるために「冪等性」「分離と制御」「追跡可能性」を設計ポイントとした
 
 ◼ このポイントに基づき、Pub/Sub による分離 、Workflows による制御 、アプリケーションロジックによる冪等性を担保 したアーキテクチャを構築
 
 
 OpenTelemetry と Pub/Sub の連携によって生み出される価値
 
 ◼ Pub/Sub クライアントの Enable OpenTelemetry Tracing オプション を有効化するだけで、分断されていた処理が一 連の処理としてトレーシングできる
 
 ◼ パブリッシャーとサブスクライバーの処理が紐づくことで、迅速なトラブルシューティングが可能 となる

30. © NTT Communications Corporation All Rights Reserved. 30