7,000万ユーザーの信頼を守る「TimeTree」のオブザーバビリティ実践 ( Datadog Live Tokyo )

Transcript

1. 7,000万ユーザーの信頼を守る 「TimeTree」のオブザーバビリティ実践 01 TimeTree 2025/12/16(Tue.) Datadog Live Tokyo
2. 02 TimeTree 本名 : 小笹 彰太 ( Shota Ozasa ) ニックネーム : Bell ⾃⼰紹介 株式会社 TimeTree 技術本部 SREチーム エンジニア 趣味： お酒の飲み比べ、アニメ鑑賞
3. 03 TimeTree Agenda 1. TimeTree とオブザーバビリティの背景 2. 定点観測会の紹介 3. まとめ
4. 1 TimeTree と オブザーバビリティの背景 04 TimeTree
5. 05 TimeTree TimeTree とオブザーバビリティの背景 1. TimeTree とは？ 2. サービス規模 3. 技術スタック 4. Datadog 導入時期と導入理由 5. リリース頻度とリポジトリ構成 6. SRE チームの体制
6. 06 TimeTree TimeTree とは？ 予定の「共有」「可視化」と そこで生まれる「コミュニケーション」 によって、予定管理を誰にとっても 当たり前で簡単なものにします。 数あるサービスの中で、 パーソナル × 共有を軸に 価値提供しているプロダクトです。 06
7. 07 TimeTree 新しくつくられた予定、変更された予定は、 TimeTreeがあなたに代わって相手に素早くお知らせ します。 大切な予定を忘れることも、言った言わないのすれ ちがいも起きません。 TimeTree TimeTree 共有カレンダー TimeTreeを使ってだれでも気軽にイベント情報を発 信することもできます。 見逃してほしくない大事な予定情報を発信するオ フィシャルサイトが簡単につくれます。 公開カレンダー
8. 08 TimeTree 70M ユーザー↗ 13⾔語↗ サービス規模 登録ユーザー数が 7,000万 を突破、 その比率はおおよそ 50:50 (国内:海外) グローバルにサービスを展開、 200万ユーザーを突破している国も多数
9. 09 TimeTree Google Cloud ・Cloud Run ・Cloud Spanner ・Memorystore AWS ・Lambda ・CloudFront ・S3 技術スタック ( ⼀部抜粋 ) Ruby on Rails バックエンドアプリケーション GitHub Actions CI / CD インフラ構成 Terraform IaC
10. 010 TimeTree ・AWS -> Google Cloud 　への移行と豊富な 　インテグレーション ・サンプリング機能の 　優秀さ ・2025/10/01 頃に 　本格利用開始 ・以前は別の 　モニタリングツール 　を利用 Datadog 導⼊時期と導⼊理由  導⼊時期  導⼊理由
11. 011 TimeTree リリース頻度とリポジトリ構成 リリース内容 • 新機能の追加 • 既存機能のアップデート ・ほぼ毎日リリース ・金曜日と休日は除く Backend & Frontend ( Web App ) ・ほぼ毎週リリース ・1週間かけて段階的に Client App ( iOS, Android ) • 性能改善のための改修 • バグ修正 • etc...
12. 012 TimeTree リリース頻度とリポジトリ構成 ・モノレポ構成であるため、毎日リリースを行っても 　変更内容が大規模になることがある ・ユーザー規模からみても、特にリリース直後の問題は早期検知が重要 共有カレンダーのソースコード 公開カレンダーのソースコード etc… 1 Repository
13. 013 TimeTree SRE チームの体制 共有カレンダーチーム iOS, Android, Web, BE etc… 公開カレンダーチーム iOS, Android, Web, BE etc… ・各チームに SRE 担当が Join ・定点観測会もチームごとで開催 SRE チーム ※ この他にも Ads / Data チームなどもあります Join Join
14. 2 定点観測会の紹介 014 TimeTree
15. 015 TimeTree SRE チームによる メトリクス確認 修正・改善タスク Backend チームへの 確認・共有 定点観測会とは？ • SRE チームと Backend チームが 共同で行う会議体であり、 “メトリクス確認 〜 共有” までの 場をひとつにまとめ、効率的かつ 効果的な改善活動の取り組み • 高頻度なリリースによる指標の変化 を早期に検知するため、 週一の頻度で実施
16. 016 TimeTree SRE チームによる メトリクス確認 & Backend チームへの 確認・共有 修正・改善タスク 定点観測会とは？ • SRE チームと Backend チームが 共同で行う会議体であり、 “メトリクス確認 〜 共有” までの 場をひとつにまとめ、効率的かつ 効果的な改善活動の取り組み • 高頻度なリリースによる指標の変化 を早期に検知するため、 週一の頻度で実施
17. 017 TimeTree ・ほぼ毎日リリースされるバックエン 　ドの変更内容のうち、どの変更がど 　の指標に寄与しているかをスピー 　ディに判断することが、SRE チーム 　だけでは難しい状況 ・BE チームから SRE チームへのコ 　ミュニケーションパスが少ない状況 定点観測会 発⾜以前の課題 SRE × BE の連携強化 ・Cloud Run へのリクエスト数は 　2,000 req/s ~ 10,000 req/s ほど ・単一 API の些細な変更でも影響範囲 　次第では指標に大きな影響がある ・潜在的なパフォーマンスの悪化など 　に気づけるような、定期的なメトリ 　クス確認の場が少ない状況だった パフォーマンス意識の向上
18. 018 TimeTree 実際に使っているダッシュボードの紹介 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫
19. 019 TimeTree 先週⽐ ダッシュボード作成時に意識した視点 可能な限り先週比をパッと 見でわかるように 焦点を当てたい情報に絞り 込めるように 限られた時間枠で可能な限り 全体を俯瞰できるように フィルター 俯瞰的
20. 020 TimeTree 実際に使っているダッシュボードの紹介 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫 →
21. 021 TimeTree LB のリクエスト数とレスポンス数 ( Integration 機能 ) [ 確認できること ] ・LB へのリクエスト数 ・そのレスポンスが Cloud Run から 　なのか CDN Cache からなのか ・先週比 [ 必要性 ] ・祝日やイベントの影響を検知する 　ことができる
22. 022 TimeTree Path ごとの CDN Cache 状況 ( Integration 機能 ) [ 確認できること ] ・Path ごとの Cache Hit/Miss 数 ・Path ごとの Cache Hit Rate [ 必要性 ] ・CDN Cache を新規で設定した 　時の効果を測定できる ・CDN Cache の設定を調整した 　ときの影響を検知することも 　できる
23. 023 TimeTree Cloud Run のレスポンスコード ( Integration 機能 ) [ 確認できること ] ・レスポンスコード ( 2xx / 3xx / 　4xx / 5xx ) ごとのリクエスト数 [ 必要性 ] ・BE 側の改修やライブラリアップ 　デートの影響を検知できる ・API 呼び出しが適切に行われて　 いるかを検知できる
24. 024 TimeTree Cloud Run のレイテンシー ( Integration 機能 ) [ 確認できること ] ・Cloud Run のレイテンシー推移 　( 平均値や p95 など ) [ 必要性 ] ・BE 側の改修やライブラリアップ 　デートの影響を検知できる ・パフォーマンス改善の効果を 　測定できる
25. 025 TimeTree 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫 実際に使っているダッシュボードの紹介 →
26. 026 TimeTree クライアントアプリごとのリクエスト ( 1 ) ( Custom Metrics 機能 ) [ 確認できること ] ・iOS / Android / Web ごとの 　リクエスト比率 ・バージョン推移 [ 必要性 ] ・特定のクライアントアプリに 　偏った影響であるかを検知する 　ことができる ・どのバージョンから影響がでて 　いるかを検知することができる
27. 027 TimeTree [ 確認できること ] ・エンドポイント / クライアント 　アプリごとのリクエスト数の 　推移 [ 必要性 ] ・特定のエンドポイントが特定の 　クライアントからのみ呼び出さ 　れていないかを検知できる クライアントアプリごとのリクエスト ( 2 ) ( Custom Metrics 機能 )
28. 028 TimeTree 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫 実際に使っているダッシュボードの紹介 →
29. 029 TimeTree エンドポイント別のレイテンシー ( APM 機能 ) [ 確認できること ] ・エンドポイントごとのレイテン 　シー推移 ・優先して確認すべき(先週比での 　差が大きい)エンドポイント [ 必要性 ] ・パフォーマンス調整したエンド 　ポイントの効果を測定できる ・サービス全体に悪影響を与える 　エンドポイントの早期発見
30. 030 TimeTree ⾮同期 Job と 定期実⾏ Job 別のレイテンシー ( APM 機能 ) [ 確認できること ] ・非同期 Job と 定期実行 Job の 　パフォーマンスもエンドポイン 　ト別と同じように確認できる [ 必要性 ] ・パフォーマンス調整が必要な 　Job を検知することができる
31. 031 TimeTree 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫 実際に使っているダッシュボードの紹介 →
32. 032 TimeTree DB ( Spanner ) への Slow Query ( APM 機能 ) [ 確認できること ] ・遅いクエリ ・遅いクエリを使っている 　エンドポイント ・エンドポイントの Duration 　分布 [ 必要性 ] ・クエリのパフォーマンス調整に　 よる効果を測定できる
33. 033 TimeTree 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫 実際に使っているダッシュボードの紹介 →
34. 034 TimeTree エンドポイント別のエラー推移 ( APM 機能 ) [ 確認できること ] ・エンドポイントごとのエラー数 ・エラータイプごとのエラー推移 [ 必要性 ] ・バグ修正したエンドポイントに 　絞って、その後の経過を測定で 　きる ・関連して別のエラーが上昇して 　いないかも同時に確認できる
35. 035 TimeTree エラー数とクライアントアプリの内訳 ( Custom Metrics 機能 ) [ 確認できること ] ・特定のエラーがどのクライアン 　トで発生しているか ・特定のエラーがどのクライアン 　トバージョンから発生して 　いるか [ 必要性 ] ・クライアント側の変更に起因 　するエラーの場合、各チームへ 　相談する際の材料になる
36. 036 TimeTree 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫 実際に使っているダッシュボードの紹介 →
37. 037 TimeTree AI 機能のパフォーマンス ( APM 機能 ) [ 確認できること ] ・モデルごとのパフォーマンス ・AI 機能を使っているエンドポイ 　ントごとのパフォーマンス [ 必要性 ] ・プロンプト調整の効果を測定で 　きる ・モデルごとのパフォーマンス差 　を測定することができる
38. 038 TimeTree 1. クラウドインフラのパフォーマンス 2. クライアントアプリごとの分析 3. エンドポイントごとのパフォーマンス 4. DB への Slow query 分析 5. エラー分析 6. AI 機能のパフォーマンス分析 7. ダッシュボードを使いやすくする工夫 実際に使っているダッシュボードの紹介 →
39. 039 TimeTree ダッシュボードを使いやすくする⼯夫 ( 1 ) ( Dashboard 機能 ) [ 工夫ポイント ] ・ダッシュボード全体を必要な 　情報のみに Filter することが 　可能 [ 必要性 ] ・特定のエンドポイントの情報に 　絞って影響を検知することが 　できる ・Datadog に慣れていないメン 　バーでもある程度操作できる
40. 040 TimeTree ダッシュボードを使いやすくする⼯夫 ( 2 ) ( Dashboard 機能 ) [ 工夫ポイント ] ・ダッシュボードのウィジェット 　を右クリックして Filter に 　セットすることも可能 [ 必要性 ] ・より直感的な手順で、特定のエ 　ンドポイントの情報に絞った調 　査が可能になる
41. 3 まとめ 041 TimeTree
42. 042 TimeTree パフォーマンス状況を短 時間で俯瞰できる • 定点観測会用に整理した ダッシュボードがあるこ とで、30〜60分で全体 像を把握できる • 調査時間を大幅に節約 し、判断・改善に使える 時間を増やせる 定点観測会を実施する SRE のメリット SRE × BE の定期的な 対話が⽣まれる • 定期的に顔を合わせるこ とで、改善提案や相談が しやすい関係性が維持さ れる • チーム間の温度差や情報 ギャップが減る SRE だけでなく、開発者 と⼀緒に解きほぐせる • 実装背景や意図を把握し ながら原因調査ができ、 トラブルシューティング の精度が向上 • 実際にコードを書いた BE メンバーの知見を取 り入れられる
43. 043 TimeTree サービスパフォーマンス の俯瞰的な理解 • リクエストトレンドや負 荷状況などが可視化さ れ、全体像をつかみやす くなった • どこに課題があるかを把 握しやすくなり、改善の 方向性が明確になった 定点観測会が BE チームにもたらした変化 パフォーマンス意識の 向上 • これまで感覚的だった判 断が、データを踏まえた 認識に変わった • 数値を基に議論できるよ うになり、パフォーマン スを考慮する姿勢が強 まった トラブルシューティング の精度向上 • これまでとは異なる視点 で原因を追えるようにな り、調査がスムーズに • 問題の特定がしやすくな り、対応の質とスピード が向上した
44. 044 TimeTree ・ユーザー体験を左右するボトルネックを エンド・トゥ・エンドで把握 ・SRE プラクティスをプロダクト全体へ 広げ、全社的な改善文化を育てていく 今後の展望 クライアント ( iOS / Android ) まで含めた“E2E”の観測へ ・Bits AI などを取り入れ、調査・議論の 精度とスピードを向上させたい ・手動での確認に依存しない、自動化され た定点観測サイクルを実現させたい ※ その他、AI 以外の Datadog 機能を使 いこなしていきたい Datadog の AI 機能を活⽤した “効率的な観測”への進化
45. Thank you! Shota Ozasa SRE, TimeTree, Inc. bell@timetreeapp.com 045 TimeTree