Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DatadogAPMでAPIレイテンシを90%削減した話

 DatadogAPMでAPIレイテンシを90%削減した話

glaciermelt00

March 30, 2025
Tweet

Other Decks in Programming

Transcript

  1. 今更 Datadog APM の話 … ? - 話そうと思ったきっかけ - 未導入の方に

    APM の魅力を伝えたい - 数値で語れることの大事さ - 可視化の力
  2. 登壇のきっかけ - Datadog APM によるレイテンシ可視化がきっかけでプロダクトのパフォーマ ンスが劇的に改善 - 感動したので皆様にお裾分け - Datadog

    導入に足踏みされている方の後押しとなれば - より深い気づき - こんなサービスあるよ!など、フィードバックいただけるとありがたいです
  3. ボトルネックの特定と改善 - どのような問題があったのか? - 特定の API でレイテンシが高い状態 - どの指標を見て、どう改善を進めたのか? -

    p99 レイテンシが高い API の特定 - トレースのフレームグラフ で問題のある要素の特定 - コントローラ・シリアライザ・SQL クエリ・外部通信など
  4. 具体的な改善アプローチ - パフォーマンス悪化の原因 - historyUseCase.Listにて、はじめにGetByUseCase(企業 x UseCase) でDynamoDBから取得 し、それからメモリ上でフィルタリングしている。 -

    GetByUseCaseではカーディナリティが低く、時間と共に取得件数が単調増加してしまう。 - stage環境にて試したところ、DynamoDBからの取得で15万件ヒット、7~10秒かかっていた。 - 対応方針 - 第一フィルタリングをGetByUseCaseではなく、優先度に応じて1度だけ行うようにした。 - Objectのカーディナリティは極めて高く、フィルタリング効果が大きいのでObjectが指定され ているクエリについてはパフォーマンスが大きく改善する。 - 既存のhistory APIのコールを一通り確認したが、概ねObjectが指定されていたので全体的に改 善するのではないかと期待。 - 結果 - Object指定のリクエストについては 7s → 54ms に改善した。
  5. 継続的な改善と今後の展望 - monthly - APM > Service > Endpoints でレイテンシの高い

    API を特定 - 合計時間(ユーザーが消費した時間) > リクエスト数 > p99 レイテンシ を比較し、規 定以上の API を特定 - 例: 過去 1 ヶ月で 合計時間 30 min 以上、リクエスト数 100 以上、p99 レイテン シ 1s 以上の API
  6. まだ残っている課題と今後の改善ポイント - toB サービスの API が目標を上回っている状態 - toC サービスでもまれにスパイクが発生し、目標を上回ることが懸念される -

    月1 でバックエンドチームでレイテンシの状況確認 - 優先度をつけてパフォーマンス改善対象の API を特定 - PM チームに状況共有しチケット化・アサイン・リリース時期を調整