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
Google Cloud Pub/Sub のデッドレター設定でハマったところ
Search
suna-big
September 12, 2024
Programming
0
290
Google Cloud Pub/Sub のデッドレター設定でハマったところ
Google Cloud Pub/Sub のデッドレター設定でハマったところがあったので紹介します。
suna-big
September 12, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
VS Code Update for GitHub Copilot
74th
2
640
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
290
PipeCDのプラグイン化で目指すところ
warashi
1
270
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.5k
PHPでWebSocketサーバーを実装しよう2025
kubotak
0
280
効率的な開発手段として VRTを活用する
ishkawa
0
140
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
86
28k
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
1
18k
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
510
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
3
470
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Adopting Sorbet at Scale
ufuk
77
9.5k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
4 Signs Your Business is Dying
shpigford
184
22k
Documentation Writing (for coders)
carmenintech
72
4.9k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Transcript
@suna_big Google Cloud Pub/Sub の デッドレター設定で ハマったところ 異なるタイプのサービスアカウントと権限、MaxExtensionについて
自己紹介 株式会社AI Shiftのバックエンドエンジニア 主にChatbot,Voicebotの開発をしています パブリッククラウドとソフトウェアデザイン設計に 強くなりたいです
Pub/Subとは? Pub/Subは、非同期でスケーラブルなメッセージングサービス メッセージの送信者 (パブリッシャー) と受信者 (サブスクライバ ー) を切り離す通信モデル パブリッシャーとサブスクライバーを分離し、独立して開発・運用 できるなどのメリットがある
Pub/Subとは? https://cloud.google.com/pubsub/docs/pubsub-basics?hl=ja#lifecycle_of_a_message_in
デッドレタートピックとは? Pub/Sub のデッドレター トピックとは、Pub/Sub サービスがメッセー ジの配信を試みたものの、サブスクライバーが確認応答できない場合 に、配信不能メッセージを転送するトピック Pub/Sub のデッドレター トピックに対してサブスクリプションを用意
し、GCSに保存することで後から問題のあるメッセージのトラブルシ ューティングと分析が容易になります
デッドレター トピック デッドレター サブスクリプシ ョン デッドレタートピックとは?
デッドレターに 入らない 起きたトラブル デッドレターに 流れたはずの メッセージが サブスクリプションから 流れ続ける 確認応答期限が 1分のはずが
60分かかる
デッドレターに 入らない 起きたトラブル デッドレターに 流れたはずの メッセージが サブスクリプションから 流れ続ける 確認応答期限が 1分のはずが
60分かかる
デッドレターに入らない デッドレタートピックを設定したのに、 なぜか流れない。。。 サブスクリプション デッドレター トピック デッドレター サブスクリプション
デッドレターに入らない Pub/Sub サブスクリプションの デッドレタリングの項目で 注意マークがついている部分の対応が必要だった しかし、Terraform上で どうやって表現したらよいかわからなかった 具体的には『このプロジェクトの Cloud Pub/Subサービスアカウント』とはなんだ?
複数のサービスアカウント 実はサービスアカウントには複数種類ある Google Cloud には、いくつかの異なるタイプのサービス アカウントがあります。 ユーザー管理のサービス アカウント: ユーザーが作成して管理するサービス アカウント。
多くの場合、これらのサービス アカウントはワークロードの ID として使用されます。 デフォルトのサービス アカウント: 特定の Google Cloud サービスを有効にするときに自動 的に作成される、ユーザー管理のサービス アカウント。これらのサービス アカウントは、 ユーザーの責任で管理する必要があります。 Google 管理のサービス アカウント: サービスがリソースにアクセスできるようにするため に、ユーザーに代わって Google が作成し、管理するサービス アカウント。 https://cloud.google.com/iam/docs/service-account-overview?hl=ja#types
複数のサービスアカウント 再度管理画面のチェックボックスをクリックして確認したら 確かにいた!(画像の赤枠) service-{project_number}@gcp-sa-pubsub.iam.gserviceaccount.com これをTerraformに設定
デッドレターに 入らない 起きたトラブル デッドレターに 流れたはずの メッセージが サブスクリプションから 流れ続ける 確認応答期限が 1分のはずが
60分かかる
デッドレターに流れたメッセージが サブスクリプションから流れ続ける Pub/Sub のデッドレター トピックにメッセージは入るが、サブスクリ プションにメッセージが残り続けて、無限にサブスクライバーが動き 続けていた
デッドレターに流れたメッセージが サブスクリプションから流れ続ける デッドレター トピック メッセージが 流れ続ける
権限不足 実はパブリッシャーロールしか設定していなかった。(画像) デッドレタートピックにパブリッシュするのだから サブスクライバーロールなんて何に使うんだと 考えていた しかし、サブスクライバーのロールが サブスクリプションからメッセージを削除する 役割があった
Terraformで権限を設定 メッセージがデッドレターに流れ、 サブスクリプションからは 削除されるようになった! Terraformに設定
デッドレターに 入らない 起きたトラブル デッドレターに 流れたはずの メッセージが サブスクリプションから 流れ続ける 確認応答期限が 1分のはずが
60分かかる
わざと失敗するリクエストを送り確認応答期限(1分)※* 配信の最大試行回数(5回)後にデッ ドレターに送られるはずがいっこうに送られない。。 それどころからログを見ると、そもそも再試行が行われておらず、60分後にようやく1回目の 再試行が行われていた。。 確認応答期限が1分のはずが60分かかる
MaxExtension MaxExtensionという Subscriptionが各メッセージの確認応答期限を 自動的に延長する最大期間の設定が Pub/Subのサブスクライバー用の ライブラリに存在していた これのデフォルトが60分であり、自動的に 各メッセージの応答期限が延長されていた
MaxExtension MaxExtensionは0未満に設定すると確認応答期限の延長がされなくなるので、-1に することで確認応答期限が1分になったことを確認できた
まとめ ・サービスアカウントは複数種類ある、デッドレターの設定にはGoogle 管理のサ ービスアカウントを利用する必要がある ・デッドレターの設定で利用するサービスアカウントにはパブリッシャーだけでな く、サブスクライバーの権限も付与しよう ・MaxExtensionによって確認応答期限が自動で延長されてしまうから気をつけよ う
ご清聴ありがとうございました