Datadog Synthetics 活用事例紹介

2024/11/06 に開催された Datadog セミナー：ユーザー体験を守る！
活用事例から学ぶフロントエンド監視(https://www.datadoghq.com/ja/event/casestudies-seminar202411/) の登壇資料です。

Transcript

1. Datadog Synthetics 活用事例紹介 パフォーマンス最適化とサービス信頼性の向上 2024/11/06 Datadog Seminar
2. 自己紹介 猪熊 朔也 ( いのくま さくや ) / @sinocloudon - 株式会社 Red Frasco - インフラエンジニア ◆経歴 - 金融系 SIer, リクルート(SUUMO), 金融系スタートアップ, 現職 ◆その他コメント - うどんが好きです - ラーメン二郎が好きです - うどん脳 をプロフィールアイコンにすることが多いです 2
6. 目次 Datadog Synthetics について 弊社での活用事例を一挙紹介 運用で得た知見の共有
7. 7 本題に入る前に
8. 8 本セッションの前提
9. セッションの前提事項 • 監視・モニタリング運用を担当されている方であれば、基本的 にはスムーズに理解いただける内容だと思います。 • Datadog 利用有無や習熟度になるべく依存しないよう意識しています。 • 弊社では AWS を使用して基盤を構築・運用しています。 • プラットフォームが異なる場合は適宜読み替えをお願いします • 利用している AWS サービスに関する詳しい説明は割愛します。 9 ここがよくわからなかった、もっと詳しく聞いてみたいなどあれば、 ぜひ情報交換しましょう！！
10. 10 運用している基盤の概要
11. 11 基盤の全体構成
12. 12 カスタマー向け 不動産ポータルサイト クライアント向け 業務システム データパイプライン 基盤の全体構成
13. 13 基盤の全体構成 AWS アカウント: 14 Datadog Monitor: 316
14. 14 本題
15. 15 Datadog Synthetics について
16. Datadogで外形監視をするための機能 • 世界中のエンドポイントからシミュレートされたリクエストと やアクションを実行することができる。 • さまざまなプロトコルに対応(HTTP, SSL, DNS, TCP, ICMP, gRPCなど) • テストの種類も色々ある • シンプルなAPIテスト • Multistep API テスト • ブラウザテスト • モバイルアプリテスト • Synthetics の成功率を SLO の指標として利用することもできる。 16 参考URL：https://docs.datadoghq.com/ja/synthetics/
17. Synthetics Test の概要 その1 17 • テスト設定の概要と稼働実績を見ることができる 設定概要 稼働実績
18. Synthetics Test の概要 その2 18 • シュミレートされたリクエストのレスポンスの内訳が見れる ロケーションごとの レスポンスタイム レスポンスの 内訳
19. Synthetics Test の概要 その3 19 • 失敗したリクエストの詳細情報が見れる レスポンスの 内訳 レスポンスの 詳細
20. 20 弊社での活用事例を一挙紹介
21. Synthetics Test 一覧(いきなりまとめ) 分類 テスト概要 プロトコル 備考 1. 証明書 SSL/TLS証明書 SSL 2. 主要導線 サイトTOPページ(CDNあり) HTTP サイトTOPページ(CDNあり・オンコール専用) HTTP 15分継続したらアラート サイト一覧ページ(CDNあり) HTTP サイト検索ページ(CDNあり) HTTP サイト詳細ページ(CDNあり) HTTP サイト詳細ページ(CDNなし) HTTP 3. CDN 静的アセット(CDNあり) HTTP 4. 外部API ネイティブアプリAPI HTTP サーバーサイドGTM HTTP 物件画像配信サーバー HTTP 5. オンプレ(旧基盤) 旧サイトTOPページ(オンコール専用) HTTP オンプレミスオリジン ICMP ファイアウォール ICMP ロードバランサー ICMP 21
22. 22 1. 証明書
23. 証明書の有効性を監視する • 証明書が有効かどうか • 証明書の期限が近づいているか • TLSの最小/最大バージョン など 23
24. 24 2. 主要導線
25. サイトの主要導線のエラー・レスポンスタイムを監視する • サイトの主要導線を監視する • CDNを経由しているため、問題発生時の切り分けが複雑容易に なるような仕組みを実現する • 多段 Synthetics Test (あとで説明) • オリジンのレスポンスを監視するため、キャッシュさせないようなク エリ文字列を付与 • ランダムに詳細ページを表示する監視用エンドポイントを作成 • CDNキャッシュヒット単体の監視を入れる(あとで説明) 25
26. Variables を活用してリクエストを可変にする 26 2回目以降キャッシュ されないような変数を 設定する
27. 27 3. CDN
28. CDNキャッシュ(エッジサーバー)上に問題がないか監視する • 必ずキャッシュされるコンテンツを監視する • キャッシュヒット時の動作が通常通りかどうかがわかる • CDNで何か問題が発生した場合にすぐに検知できる • 最寄りのエッジロケーションのレスポンス遅延 • 最寄り以外のエッジロケーションからコンテンツ配信 28
29. 29 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html#HowCloudFrontWorksContentDelivery
30. テストOKパターン 30
31. テストNGパターン 31 通常は50ms程度なのに 1秒を超えている ロンドンから配信 されている
32. 32 4. 外部API
33. サイトで使用する外部APIを監視する • 外部API起因でサイトに問題が起きていないかを監視する • 関連システムのAPIやサーバーのエラー・レスポンスを監視 • 外部APIのエンドポイントにリバースプロキシしているエンドポ イントを監視する • あくまで確認したいのはサイトに問題が起きているかどうか • リクエスト課金のAPIを監視する場合はコストに注意 • リクエストベースの監視が難しければ、素直にログ監視 33
34. 34 5. オンプレ(旧基盤)
35. 最低限の監視を入れることで問題発生時のやり取りをスムーズに • 旧基盤はオンプレかつ別会社による運用・監視 • 監視設定を追加・修正したくてもすぐにはできない • 昔ながらの監視製品であるため、昨今の監視SaaSと比較すると、どうしても きめ細やかない監視・モニタリングが難しい • サーバーにAgentを入れるだけでなくネットワーク機器の監視も追加 • データセンター内ネットワーク(上位ISP含む) • ファイアウォール • ロードバランサ • 問題発生時に毎回全体を調べるのではなく、アラートの内容を基に 対象を絞り込んだ上で調査を開始できるようにした 35
36. 36 運用で得られた知見の共有
37. 最短・最速で監視を入れるなら Synthetics Test がおすすめ • 監視対象のURLやIPさえ分かれば、すぐに監視できる • インストール作業や初期設定が不要 • オンプレ(旧基盤)で発生した障害をキッカケにDatadogを導入 • 当時の状況をおさらいすると… • 繁忙期直前にパフォーマンス障害が発生 • 詳細な原因が分からないので、取り急ぎサーバー台数を増やす • 問題が再発した際に即座に検知して対応したい…! • よし、Datadog 入れようぜ 37
38. Synthetics Test を多段構成にする • 監視したいエンドポイントすべてにSynthetics を導入する • 主要導線に関わるすべてのURL • 通信経路上のすべてのエンドポイント 38
39. 1つではなく多段で見ることで切り分けをスムーズに • 多段 Synthetics にすることで、問題発生時の切り分けがスムーズ • ①, ②, ③ のどの部分から不調になっているかがすぐわかる 39 Route 53 CloudFront ELB ECS オンプレ基盤 Route 53 の部分だけではなく、すべての エンドポイントに対して Synthetics Test を実行する ① ② ③ 主要導線A 主要導線B 主要導線C
40. デフォルトで世界中からシュミレートされるのでコストに注意 • デフォルト設定のままだと Datadog Synthetics は全世界23リー ジョンから1分間隔でテストを実行する • 実際にあった事例 • 新規構築中のシステム向けの監視設定を夏休み前に追加 • 夏休み明け、Datadog Synthetics のテスト実行が爆発的に増えているこ とに気づく • その結果、3週間で通常時の1.5倍のコストがかかってしまった • 契約量の見直しやログ量削減によるコストカットによりトータルでの 予算超過を回避 40
42. 42 テスト実行数が通常時の4倍に跳ね上がっている ⇩ 通常の使用量
43. しきい値はどうやって決める？ • 例1: 試しに動かして決める • 1週間くらい動かしてみてベースラインを把握 • ベースラインよりも少し高い値をしきい値にする • 例2: 負荷テストを実施して決める • 90-99パーセンタイルの値をしきい値とする • アラートが鳴る = 即調査・即対応 • ノイズが増えるリスクと発見が遅れるリスクのバランスを取る • ボラティリティは考慮したしきい値にしないとオオカミ少年化 • レスポンスタイムは、without DNS がおすすめ(結構ぶれる) 43
45. Synthetics を監視のきっかけにしつつ Monitor を拡充する • シュミレートされたリクエストでしかない • Synthetics をキッカケにして必要なMonitorを拡充していく • 問題の原因や他メトリクスとの相関がよりわかりやすくなる仕 掛けを作る • レスポンスが遅くなったのは… • クローリングが一時的に増えた？( HTTP 3xx, 4xx Anomaly 監視) • SQLが遅くなった？ (ログやDBMによるスロークエリ監視) • リリース後に不具合が混入した？(HTTP 5xx Anomaly 監視、エラーログ監視) 45
46. 46 おわりに
47. 本セッションのまとめ • Synthetics Test 単体でも様々な監視ができる • 今回紹介したのは一部の機能のみ • しかし、Synthetics Test がすべてではありません • あくまで最低限の監視であると捉える • 他の機能と併用していくことで監視運用を高度化する 47 ぜひ情報交換しましょう！！(みなさんの運用も聞かせてください) 今後も様々な機能を駆使して監視運用を洗練させていきたい
49. END OF PRESENTATION ご清聴ありがとうございました
50. 50 Appendix. Synthetics Test 以外の監視設定
51. 目次 KPI監視・モニタリング ステータスコード監視・モニタリング アクセスブロック監視・モニタリング バウンスメール監視・モニタリング バッチ実行監視・モニタリング コストモニタリング
52. KPI 監視・モニタリング • 何を：CV(コンバージョン)数 • どうやって：しきい値監視 • なぜ：AWS移行中で大きなリリースが多いので、最終防衛ライ ンとしてCV数を常時監視 52
53. 事業に貢献できているかどうかを監視する • CV 数が下がっていないか常に注意を払う • 大きなリリース後でもCV数が落ちていない安心感を得られる 53 Database CV 数取得 メトリクスPUT • Database から CV 数を取得して、 Datadog に連携 • デバイスごと(PC/SP/App)に CV 数を監 視・モニタリング
54. ステータスコード 監視・モニタリング • 何を：HTTP ステータスコード(301, 302, 404, 499) • どうやって：Anomaly 監視 • なぜ：Bot, 攻撃などの短期間のアクセス傾向の変化を早期検知・対 処する 54 ※ 50x は、エラー監視という位置付けでしきい値監視してます
55. 監視 SaaS の機能を活用して「いつもと違う」を検知する • Datadog の Anomaly Monitor が便利 • 元々は、CTO がお試しでシュッと入れたのがはじまり • 本人も忘れた頃に Anomaly Monitor が鳴る • しきい値がよくわからない、しきい値では正しく検知できない ものは Anomaly 監視がかなり効く 55
56. WAF によるアクセスブロック監視・モニタリング • 何を：403 エラーレート • どうやって：しきい値監視、異常監視 • なぜ：脆弱性探索など不審なアクセスを検知する 56
57. ブロックされなかったアクセスは月次モニタリングで対処 • ブロックをすり抜けてきた怪しいアクセスを見つけ出す • IP や User Agent の上位層を時系列で見てあたりをつける 57
58. スロークエリ監視・モニタリング • 何を：SQL 実行時間 • どうやって：しきい値監視 • なぜ：レスポンス遅延発生時の切り分けに有効 58
59. バウンスメール監視・モニタリング • 何を：ハードバウンス • どうやって：しきい値監視 • なぜ：店舗への連絡やリカバリ対応を即時に行うため 59
60. バッチ実行監視・モニタリング • 何を：バッチ実行有無、バッチ実行結果 • どうやって：しきい値監視 • なぜ：バッチが想定通り動いていることを確認するため 60
61. 処理対象ファイル数監視・モニタリング • 何を：物件ファイル数 • どうやって：しきい値監視 • なぜ：処理対象データが全量届いているかどうか確認する 61
62. 開発環境の数もモニタリングしています • Feature ブランチごとの環境を自動生成しています • 環境数が増えすぎてコストを圧迫しないようモニタリング 62 ※ 環境自動生成やBGデプロイ周りの詳細は以下のスライド参照 https://speakerdeck.com/red_frasco/feature-huan-jing-nozi-dong-sheng-cheng-to-blue-green-deployment-dexiao-lu-de-katuan-quan- naririsupurosesuwogou-zhu
63. AWS コスト監視・モニタリング • 何を：利用料実績, 利用料予測(Org全体、各アカウント) • どうやって：しきい値監視 • なぜ：予算超過リスク、想定外の利用を早期検知して削減策を打つ 63
64. Monitor による検知と月次のダッシュボード確認でコスト最適化 • 実績だけでなく予測も監視していることで想定外のリソース使 用を検知できる • 例：急に誰かがGPUインスタンス立てたなど • ダッシュボードを併用して、全体を俯瞰 • 重点ポイントを見極め、必要に応じてコスト最適化策実施 • 実績例1：以下のような最適化策を実施して、15% 程度コスト削減 • 不要な VPC エンドポイント削除 • ログ出力量の最適化 • 実績例2：sandbox (検証用環境) の予算をあえてゼロにする • 誰かが使用したらすぐ検知できるので、消し忘れがないよう周知可能 64
65. 65 コストモニタリングダッシュボード@Datadog
66. 66 各アカウントのコスト状況