可観測性って何？から始まった 初めてのSRE ~Google Workspace カードのトランザクションと戦う初めてのクラウドネイティブ~

可観測性って何？から始まった 初めてのSRE ~Google Workspace カードのトランザクションと戦う初めてのクラウドネイティブ~

CloudNativeDays Winter 2025
LT三種盛り — 5分で語る若手初学者向けに実際経験したLT

上記にて発表したLTの資料です。

Transcript

1. 1 可観測性って何？から始まった 初めてのSRE Google Workspace カードの トランザクションと戦う初めてのクラウドネイティブ はるおつ @haruotsu_hy CloudNativeDays Winter 2025 2025.11.19
2. 2 ⾃⼰紹介 横⼭ 遥⼄ はるおつ • @haruotsu_hy/@haruotsu • 新卒2年⽬エンジニア • Go、Rubyをよく触ります。 • 呼吸をするようにドメインを買っています。 • cloudnativeな発表は初めてなので緊張しています
3. 昨⽇リリース！ 3 2025年11⽉18⽇ (昨⽇) Google Workspace カードが リリースされました！
4. 4 初めての信頼性向上に向けて 現在進⾏形で取り組んでいること、 つまずいたことについてお話しします 上長 「はるおつ、GWS カードっていう、やばいプロジェクトやるから、これを機に 既存サービスの信頼性向上に取り組んでバーンとやってみよう」 「可観測性..., SRE…, なにもわからないけど、やってみます！」 私
5. どんなシステムか 5 どんなシステムか GWS カード購入 プロダクトキー ドメイン選択 〇〇.com, 〇〇.jp, 〇〇.dev… 組織名, adminメールアドレス... GWS情報 ムームードメインロ グイン・登録 決済情報入力 処理開始 ruby
6. Saga Orchestrator 6 Saga Orchestrationパターンの採⽤ • 長時間トラザクションを小さなローカルトランザクションの連鎖 として実装 • 各トランザクションには補償トランザクション を定義 • 失敗時は実行済みステップを逆順で補償
7. Saga Orchestrator 7 Saga Orchestrator Step1 アカウント検証 Step2 カードの利用 Step3 契約作成DB書き込み Step4 決済完了 (3DS) Step5 クレカDB登録 Step6 ドメイン取得 Step8 GWS設定 (Google) Step9 注文確定 決済返金 skip 取得契約の削除 skip GWS設定解除job作成 カードの再有効化
8. 現状整理 8 まずは現状とやるべきことを把握 観点 現状 やるべきこと ログ 分散、非統一 集中、構造化 トレース 一部のAPM End-to-End 外部API 部分的 全て Saga ログのみ トレースで状態追跡 分散トレーシング Google Workspace カードという新機能を切り口として、可観測性を組み込むチャンス
9. 段階的アプローチを考える 9 段階的アプローチを取る • Phase1: OpenTelemetry基盤構築 → 全ての前提、ベンダーロックインを回避し観測の標準化 • Phase2: BaseControllerトレーシング追加 → 全コントローラアクションでの トレース, スパン自動付与 • Phase3: Sagaトーレシング → GWS カードにおける処理の根幹、最も影響が大きい • Phase4: 外部API可視化 → 外部API起因の障害の見える化。既存システムの信頼性向上 • Phase5: アラート、SLI/SLO設定 → 検知自動化で運用不可削減 GWS カードを切り口として価値の高い部分から小さくリリース していく
10. つまずきポイント 10 つまずきポイント • SpanContextの永続化問題 • Sagaパターンのトレーシング設計
11. SpanContextの永続化問題 11 SpanContextの永続化問題 • セッションとして保存・復元される Sagaパターンで、 補償処理実行時に元のステップの Spanと関連づけたい • OptenTelemetryのLink機能を使うためにSpanContextを使いたい セッションにSpanContextを保存してみた
12. SpanContextの永続化問題 12 • セッションとして保存・復元される Sagaパターンで、 補償処理実行時に元のステップの Spanと関連づけたい • OptenTelemetryのLink機能を使うためにSpanContextを使いたい セッションにSpanContextを保存してみた SpanContextの永続化問題とSpan属性による解決
13. SpanContextの永続化問題 13 SpanContextの実体 → NoMethodError なぜOpenTelemetryはSpanContextをシリアライズ可能にしていないか思いを巡らせてみる • SpanContextは実行時の一時オブジェクト • トレースはOTLP Exporterで送信される べき • アプリケーション側で永続化されることを想定していない → 3DS待ちや補償ステップなどの 関連付けはどうしたらいいか？
14. セッション保存 vs SpanContext 14 Linkをせずに Span属性で関連づける • セッション復元後も使用可能 • Grafana/Tempoで検索可能 • 因果関係の追跡が可能
15. Sagaパターンのトレーシング設計 15 Sagaパターンのトレーシング設計 Sagaパターンで可視化したいものの洗い出し • フロー全体: Saga実行の成功/失敗 • 個別ステップ: どのステップで失敗/遅延がおきたか • 補償処理: ロールバックが正しく動いたか
16. Sagaパターンのトレーシング設計 16 どこにSpanを貼るべきか saga.execute saga.step.verify_account saga.step.verify_domain saga.step.create_contract mysql (自動計装) saga.step.create_prepare_payment http.request (自動計装) 失敗時 saga.compensation.create_contract 親span 子span 子span 子span 子span 補償span • 階層構造で因果関係が一目瞭然 • 各ステップの実行時間を個別に測定 して改善可能 • 補償処理と元のステップの関係を追跡可 能
17. Sagaパターンのトレーシング設計 17 order_event_idによる全リクエスト追跡 複数HTTPリクエストに分断された後に追跡可能にする リクエスト1: 申し込み開始 → Saga → 3DS認証へリダイレクト (HTTP分断する可能性) リクエスト2: 3DS 認証完了 → Saga再開 → 完了 → 通常のtrace_idでは2つのリクエストが別々トレースに ... 例 ビジネスキー order_event_idで全体の紐付けを行う → ビジネスロジックとして DBに保存しているキーからトレースが可能になる
18. まとめと振り返り 18
19. まとめと振り返り • SpanContextを保存したい時の注意点 ◦ SpanContextはJSON化できない ◦ trace_id, span_idを文字列として保存し、 Linkではなくspan属性で関連付け • 分散システムには分散トレーシングが効果的 ◦ Sagaパターンのような分散システムにはログのみで確認するのは厳しい ◦ OpenTelemetryで階層構造のトレーシングを実現 ◦ 小さな切り口から開始して、価値のある場所から攻める 19
20. 20 Thank you! 店頭でみかけた際にあの時のあれだ！ アレが動いてるんだ！ となってくれたら嬉しいです。