過去の改善から考える オブザーバビリティの必要性

https://events.datadoghq.com/ja/events/abmseminar-202602
Ruby on Rails × Observability
～主要SaaS企業が語る、プロダクト価値を最大化する可観測性の最前線～
#datadog_ror_o11y

Transcript

1. 過去の改善から考える オブザーバビリティの 必要性 Ruby on Rails × Observability ～主要SaaS企業が語る、プロダクト価値を最大化する可観測性の最前線～ Feb 10, 2025 01 TimeTree
2. 02 TimeTree self.inspect #<SoftwareEngineer:0x0000002e3e07bcc3 @name="徳富太樹", @nickname=”Greg”, @company="TimeTree", @role="Backend Engineer", @team=[“SRE”, “技術基盤”], @location=”愛知”, @work_style=”Full Remote🏠” @github=”@ta1kt0me” @interests=[“🎧”, “🫖”, “☕”, “🍵”] >
3. 03 TimeTree Agenda 1. TimeTreeの紹介 2. アラートの事例 3. リクエスト増加の事例 4. スロークエリの事例 5. まとめ
4. 04 TimeTree
5. 05 TimeTree 日本語を含む13言語に対応 200ヶ国以上 サービス規模 国内3,100万、アメリカ、ド イツ、台湾、イギリス、韓 国では200万を超える規模 世界7,000万ユーザー 150億件の予定 17TiBのデータ
6. 06 TimeTree 誰でも気軽に予定情報を発 信できるプラットフォーム 基本のカレンダーシェア 予定を登録しただけで相手 に共有できる 共有カレンダー icon 事業モデル 公開カレンダー icon 予定と紐づいて役立つ情報 を届けるカレンダーならで はのプラットフォーム 広告プラットフォーム icon
7. 07 TimeTree TimeTreeでは、共有カレンダー・公開カレンダー・広告プラット フォーム全てを一つのRailsアプリケーションとして提供している。 TimeTree API Google Cloud Cloud Run
8. 1 アラート 08 TimeTree
9. 09 TimeTree - サービス全体のレイテンシが増加 - 広告配信に利用している外部パートナーのAPIでタイムアウトが 発生 ある⽇アラート発⽣ Google Cloud API
10. 010 TimeTree - サーキットブレーカーを導入 - 閾値のレイテンシでリクエストを強制的にタイムアウト - スループットを落とさずカスケード障害を抑制 解決策 Google Cloud API Proxy
11. 011 TimeTree - 特定のドメイン単位でリクエストを処理するサービス分割 - APIは同一のRailsアプリケーション - 公開するルーティングが異なり、pathベースで振り分け 解決策more Google Cloud BE API Proxy Ads API
12. 012 TimeTree - 影響範囲を限定してカスケード障害を防止 - サービスの傾向が観測できる状態 - スケールアウトやキャッシュの戦略を柔軟に選択 - コスト最適化 - 注意点 - システムの複雑さと開発や運用のバランス アーキテクチャの改善で安定性向上
13. 2 リクエスト増加 013 TimeTree
14. 014 TimeTree リクエスト傾向の変化 - クライアントリリース後、リクエストが増加 - サービス影響はないが、Cloud RunとSpannerのコスト増 - 前週比から影響したResourceを特定 - 仕様変更でAPIの呼び出しパターンが変化
15. 015 TimeTree - パフォーマンスのためにリソースの範囲を絞っているAPIで発生 - Singer has many Songs の時、Songsを取得するAPI - GET /singers/:singer_id/songs - 特定の条件で上位のリソース（Singer）を複数まとめて取得す るパターンが発生 - APIレベルでN+1が発生する 問題を理解する
16. 016 TimeTree - API設計の前提を見直す - Before: GET /singers/:singer_id/songs - After: GET /songs?singer_ids=[] - 注意点 - パフォーマンスのためパラメータの上限は必要 - Storageへのアクセスパターン 解決策
17. 017 TimeTree - 定期的な観測の習慣 - データ増加に伴うパフォーマンス悪化など、見えづらい問題 の発見に役立つ - 傾向の変化は自分たちの当たり前を見つめ直す機会 - 可用性、パフォーマンス、コストを考慮して解決策を選択 - 可用性とコスト - パフォーマンスとコスト 変化に合わせて前提を⾒直す
18. 3 スロークエリ 018 TimeTree
19. 019 TimeTree - User.where(created_at: ..1.day.ago).count - 22秒！ - ちなみに User.count は 11秒 - 適切なIndexで解決？ スロークエリ
20. 020 TimeTree クエリの発⽣場所 • 統計情報を集計する非同 期Job • 発行回数はDaily • Sidekiqで実行 問題を理解する 優先度 • メトリクス上、サービス への影響はなし • 今すぐ取り組むべき問題 か？ スケーラブルな対応 • 今後レコードが増加して も問題ないか？ • 要件の見直しで改善でき るか？
21. 021 TimeTree - BigQueryからデータ取得 - 元々テーブルをDailyでBigQueryにエクスポートしていた - ユーザーリクエストよりもレイテンシーの要件が緩い 解決策 Google Cloud Sidekiq Spanner BigQuery
22. 022 TimeTree - Railsはモノリシックなフレームワークで多くのシステムと連携 - 関連するシステムの得意・不得意を理解する - Rails way、行指向・列指向ストレージ etc - 問題の背景を踏まえてシステム全体で解決策を選択 - 一般的なプラクティスが適用可能か一歩引いて考える 得意‧不得意を理解してスケーラビリティ向上
23. まとめ 023 TimeTree
24. 024 TimeTree - アラートやメトリクスの変化は改善のチャンス - サービスが成長している嬉しい悲鳴 - オブザーバビリティはサービスの成長の糧になる - 設計・アーキテクチャの進化に影響を与える - システムの理解を深めて改善する - 選択肢にはトレードオフがある - 過去と未来を踏まえて判断する まとめ
25. Thank you! 025 TimeTree