Slide 1

Slide 1 text

Datadog APM で API レイテ ンシを 1/10 に改善した話 ぐらめる

Slide 2

Slide 2 text

今更 Datadog APM の話 … ? - 話そうと思ったきっかけ - 未導入の方に APM の魅力を伝えたい - 数値で語れることの大事さ - 可視化の力

Slide 3

Slide 3 text

ある日の弊社 そろそろ APM 導入したいね。 原田さん、どう? やりましょう! 二つ返事で導入することに

Slide 4

Slide 4 text

Datadog は名前だけ聞いたことあるけど・・・ どんな サービス? 全くわからないところからスタート

Slide 5

Slide 5 text

よくよく社内のドキュメントを漁ると・・・ Datadog APM に トライしていた! が、本番環境でサー バーダウンするた め白紙に 再度チャレンジ!

Slide 6

Slide 6 text

早速営業の方にデモを見せてもらう めちゃくちゃ便利! 感動! 絶対に導入したい!

Slide 7

Slide 7 text

Who are you ? ぐらめる(原田 丈) ~‘21 生産技術・購買 @日産 ‘21~ SWE ‘23~ SRE main @スタイルポート

Slide 8

Slide 8 text

登壇のきっかけ - Datadog APM によるレイテンシ可視化がきっかけでプロダクトのパフォーマ ンスが劇的に改善 - 感動したので皆様にお裾分け - Datadog 導入に足踏みされている方の後押しとなれば - より深い気づき - こんなサービスあるよ!など、フィードバックいただけるとありがたいです

Slide 9

Slide 9 text

導入の背景 なぜ APM を導入しようと思ったの か? どのような課題があったのか?

Slide 10

Slide 10 text

導入のきっかけと背景 なぜ APM を導入しようと思ったのか? どのような課題があったのか? - API パフォーマンスがどの程度のレベルか把握できていない状態なので、現 状把握したい - パフォーマンスに問題がある場合、ユーザーからのフィードバックを待たずに 改善したい

Slide 11

Slide 11 text

インフラ構成 ECS Fargate 上で動作する Ruby on Rails アプリケーションに Datadog APM を 導入

Slide 12

Slide 12 text

ボトルネックの特定と改善 - どのような問題があったのか? - 特定の API でレイテンシが高い状態 - どの指標を見て、どう改善を進めたのか? - p99 レイテンシが高い API の特定 - トレースのフレームグラフ で問題のある要素の特定 - コントローラ・シリアライザ・SQL クエリ・外部通信など

Slide 13

Slide 13 text

具体例 8秒近くかかっているリクエストの内訳を見ると、/histories APIのリスト取得の 時間がほとんどだった。

Slide 14

Slide 14 text

具体的な改善アプローチ - パフォーマンス悪化の原因 - historyUseCase.Listにて、はじめにGetByUseCase(企業 x UseCase) でDynamoDBから取得 し、それからメモリ上でフィルタリングしている。 - GetByUseCaseではカーディナリティが低く、時間と共に取得件数が単調増加してしまう。 - stage環境にて試したところ、DynamoDBからの取得で15万件ヒット、7~10秒かかっていた。 - 対応方針 - 第一フィルタリングをGetByUseCaseではなく、優先度に応じて1度だけ行うようにした。 - Objectのカーディナリティは極めて高く、フィルタリング効果が大きいのでObjectが指定され ているクエリについてはパフォーマンスが大きく改善する。 - 既存のhistory APIのコールを一通り確認したが、概ねObjectが指定されていたので全体的に改 善するのではないかと期待。 - 結果 - Object指定のリクエストについては 7s → 54ms に改善した。

Slide 15

Slide 15 text

継続的な改善と今後の展望 - どのようにレイテンシをモニタリングし続けているか? - daily - Dashboards にレイテンシ用ダッシュボードを作成してモニタリング(目視) - 全体的に不安定なため、アラームは未設置

Slide 16

Slide 16 text

継続的な改善と今後の展望 - monthly - APM > Service > Endpoints でレイテンシの高い API を特定 - 合計時間(ユーザーが消費した時間) > リクエスト数 > p99 レイテンシ を比較し、規 定以上の API を特定 - 例: 過去 1 ヶ月で 合計時間 30 min 以上、リクエスト数 100 以上、p99 レイテン シ 1s 以上の API

Slide 17

Slide 17 text

まだ残っている課題と今後の改善ポイント - toB サービスの API が目標を上回っている状態 - toC サービスでもまれにスパイクが発生し、目標を上回ることが懸念される - 月1 でバックエンドチームでレイテンシの状況確認 - 優先度をつけてパフォーマンス改善対象の API を特定 - PM チームに状況共有しチケット化・アサイン・リリース時期を調整

Slide 18

Slide 18 text

Datadog APM のさらなる活用方法 - 他プロダクトへの横展開 - バックエンドチームが自律的に改善アクションできる仕組みづくり - 自らパフォーマンス改善へチャレンジ

Slide 19

Slide 19 text

ご清聴ありがとうございました!