Slide 1

Slide 1 text

Datadog Synthetics 活用事例紹介 パフォーマンス最適化とサービス信頼性の向上 2024/11/06 Datadog Seminar

Slide 2

Slide 2 text

自己紹介 猪熊 朔也 ( いのくま さくや ) / @sinocloudon - 株式会社 Red Frasco - インフラエンジニア ◆経歴 - 金融系 SIer, リクルート(SUUMO), 金融系スタートアップ, 現職 ◆その他コメント - うどんが好きです - ラーメン二郎が好きです - うどん脳 をプロフィールアイコンにすることが多いです 2

Slide 3

Slide 3 text

3

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5

Slide 6

Slide 6 text

目次 Datadog Synthetics について 弊社での活用事例を一挙紹介 運用で得た知見の共有

Slide 7

Slide 7 text

7 本題に入る前に

Slide 8

Slide 8 text

8 本セッションの前提

Slide 9

Slide 9 text

セッションの前提事項 • 監視・モニタリング運用を担当されている方であれば、基本的 にはスムーズに理解いただける内容だと思います。 • Datadog 利用有無や習熟度になるべく依存しないよう意識しています。 • 弊社では AWS を使用して基盤を構築・運用しています。 • プラットフォームが異なる場合は適宜読み替えをお願いします • 利用している AWS サービスに関する詳しい説明は割愛します。 9 ここがよくわからなかった、もっと詳しく聞いてみたいなどあれば、 ぜひ情報交換しましょう!!

Slide 10

Slide 10 text

10 運用している基盤の概要

Slide 11

Slide 11 text

11 基盤の全体構成

Slide 12

Slide 12 text

12 カスタマー向け 不動産ポータルサイト クライアント向け 業務システム データパイプライン 基盤の全体構成

Slide 13

Slide 13 text

13 基盤の全体構成 AWS アカウント: 14 Datadog Monitor: 316

Slide 14

Slide 14 text

14 本題

Slide 15

Slide 15 text

15 Datadog Synthetics について

Slide 16

Slide 16 text

Datadogで外形監視をするための機能 • 世界中のエンドポイントからシミュレートされたリクエストと やアクションを実行することができる。 • さまざまなプロトコルに対応(HTTP, SSL, DNS, TCP, ICMP, gRPCなど) • テストの種類も色々ある • シンプルなAPIテスト • Multistep API テスト • ブラウザテスト • モバイルアプリテスト • Synthetics の成功率を SLO の指標として利用することもできる。 16 参考URL:https://docs.datadoghq.com/ja/synthetics/

Slide 17

Slide 17 text

Synthetics Test の概要 その1 17 • テスト設定の概要と稼働実績を見ることができる 設定概要 稼働実績

Slide 18

Slide 18 text

Synthetics Test の概要 その2 18 • シュミレートされたリクエストのレスポンスの内訳が見れる ロケーションごとの レスポンスタイム レスポンスの 内訳

Slide 19

Slide 19 text

Synthetics Test の概要 その3 19 • 失敗したリクエストの詳細情報が見れる レスポンスの 内訳 レスポンスの 詳細

Slide 20

Slide 20 text

20 弊社での活用事例を一挙紹介

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

22 1. 証明書

Slide 23

Slide 23 text

証明書の有効性を監視する • 証明書が有効かどうか • 証明書の期限が近づいているか • TLSの最小/最大バージョン など 23

Slide 24

Slide 24 text

24 2. 主要導線

Slide 25

Slide 25 text

サイトの主要導線のエラー・レスポンスタイムを監視する • サイトの主要導線を監視する • CDNを経由しているため、問題発生時の切り分けが複雑容易に なるような仕組みを実現する • 多段 Synthetics Test (あとで説明) • オリジンのレスポンスを監視するため、キャッシュさせないようなク エリ文字列を付与 • ランダムに詳細ページを表示する監視用エンドポイントを作成 • CDNキャッシュヒット単体の監視を入れる(あとで説明) 25

Slide 26

Slide 26 text

Variables を活用してリクエストを可変にする 26 2回目以降キャッシュ されないような変数を 設定する

Slide 27

Slide 27 text

27 3. CDN

Slide 28

Slide 28 text

CDNキャッシュ(エッジサーバー)上に問題がないか監視する • 必ずキャッシュされるコンテンツを監視する • キャッシュヒット時の動作が通常通りかどうかがわかる • CDNで何か問題が発生した場合にすぐに検知できる • 最寄りのエッジロケーションのレスポンス遅延 • 最寄り以外のエッジロケーションからコンテンツ配信 28

Slide 29

Slide 29 text

29 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html#HowCloudFrontWorksContentDelivery

Slide 30

Slide 30 text

テストOKパターン 30

Slide 31

Slide 31 text

テストNGパターン 31 通常は50ms程度なのに 1秒を超えている ロンドンから配信 されている

Slide 32

Slide 32 text

32 4. 外部API

Slide 33

Slide 33 text

サイトで使用する外部APIを監視する • 外部API起因でサイトに問題が起きていないかを監視する • 関連システムのAPIやサーバーのエラー・レスポンスを監視 • 外部APIのエンドポイントにリバースプロキシしているエンドポ イントを監視する • あくまで確認したいのはサイトに問題が起きているかどうか • リクエスト課金のAPIを監視する場合はコストに注意 • リクエストベースの監視が難しければ、素直にログ監視 33

Slide 34

Slide 34 text

34 5. オンプレ(旧基盤)

Slide 35

Slide 35 text

最低限の監視を入れることで問題発生時のやり取りをスムーズに • 旧基盤はオンプレかつ別会社による運用・監視 • 監視設定を追加・修正したくてもすぐにはできない • 昔ながらの監視製品であるため、昨今の監視SaaSと比較すると、どうしても きめ細やかない監視・モニタリングが難しい • サーバーにAgentを入れるだけでなくネットワーク機器の監視も追加 • データセンター内ネットワーク(上位ISP含む) • ファイアウォール • ロードバランサ • 問題発生時に毎回全体を調べるのではなく、アラートの内容を基に 対象を絞り込んだ上で調査を開始できるようにした 35

Slide 36

Slide 36 text

36 運用で得られた知見の共有

Slide 37

Slide 37 text

最短・最速で監視を入れるなら Synthetics Test がおすすめ • 監視対象のURLやIPさえ分かれば、すぐに監視できる • インストール作業や初期設定が不要 • オンプレ(旧基盤)で発生した障害をキッカケにDatadogを導入 • 当時の状況をおさらいすると… • 繁忙期直前にパフォーマンス障害が発生 • 詳細な原因が分からないので、取り急ぎサーバー台数を増やす • 問題が再発した際に即座に検知して対応したい…! • よし、Datadog 入れようぜ 37

Slide 38

Slide 38 text

Synthetics Test を多段構成にする • 監視したいエンドポイントすべてにSynthetics を導入する • 主要導線に関わるすべてのURL • 通信経路上のすべてのエンドポイント 38

Slide 39

Slide 39 text

1つではなく多段で見ることで切り分けをスムーズに • 多段 Synthetics にすることで、問題発生時の切り分けがスムーズ • ①, ②, ③ のどの部分から不調になっているかがすぐわかる 39 Route 53 CloudFront ELB ECS オンプレ基盤 Route 53 の部分だけではなく、すべての エンドポイントに対して Synthetics Test を実行する ① ② ③ 主要導線A 主要導線B 主要導線C

Slide 40

Slide 40 text

デフォルトで世界中からシュミレートされるのでコストに注意 • デフォルト設定のままだと Datadog Synthetics は全世界23リー ジョンから1分間隔でテストを実行する • 実際にあった事例 • 新規構築中のシステム向けの監視設定を夏休み前に追加 • 夏休み明け、Datadog Synthetics のテスト実行が爆発的に増えているこ とに気づく • その結果、3週間で通常時の1.5倍のコストがかかってしまった • 契約量の見直しやログ量削減によるコストカットによりトータルでの 予算超過を回避 40

Slide 41

Slide 41 text

41

Slide 42

Slide 42 text

42 テスト実行数が通常時の4倍に跳ね上がっている ⇩ 通常の使用量

Slide 43

Slide 43 text

しきい値はどうやって決める? • 例1: 試しに動かして決める • 1週間くらい動かしてみてベースラインを把握 • ベースラインよりも少し高い値をしきい値にする • 例2: 負荷テストを実施して決める • 90-99パーセンタイルの値をしきい値とする • アラートが鳴る = 即調査・即対応 • ノイズが増えるリスクと発見が遅れるリスクのバランスを取る • ボラティリティは考慮したしきい値にしないとオオカミ少年化 • レスポンスタイムは、without DNS がおすすめ(結構ぶれる) 43

Slide 44

Slide 44 text

44

Slide 45

Slide 45 text

Synthetics を監視のきっかけにしつつ Monitor を拡充する • シュミレートされたリクエストでしかない • Synthetics をキッカケにして必要なMonitorを拡充していく • 問題の原因や他メトリクスとの相関がよりわかりやすくなる仕 掛けを作る • レスポンスが遅くなったのは… • クローリングが一時的に増えた?( HTTP 3xx, 4xx Anomaly 監視) • SQLが遅くなった? (ログやDBMによるスロークエリ監視) • リリース後に不具合が混入した?(HTTP 5xx Anomaly 監視、エラーログ監視) 45

Slide 46

Slide 46 text

46 おわりに

Slide 47

Slide 47 text

本セッションのまとめ • Synthetics Test 単体でも様々な監視ができる • 今回紹介したのは一部の機能のみ • しかし、Synthetics Test がすべてではありません • あくまで最低限の監視であると捉える • 他の機能と併用していくことで監視運用を高度化する 47 ぜひ情報交換しましょう!!(みなさんの運用も聞かせてください) 今後も様々な機能を駆使して監視運用を洗練させていきたい

Slide 48

Slide 48 text

48

Slide 49

Slide 49 text

END OF PRESENTATION ご清聴ありがとうございました

Slide 50

Slide 50 text

50 Appendix. Synthetics Test 以外の監視設定

Slide 51

Slide 51 text

目次 KPI監視・モニタリング ステータスコード監視・モニタリング アクセスブロック監視・モニタリング バウンスメール監視・モニタリング バッチ実行監視・モニタリング コストモニタリング

Slide 52

Slide 52 text

KPI 監視・モニタリング • 何を:CV(コンバージョン)数 • どうやって:しきい値監視 • なぜ:AWS移行中で大きなリリースが多いので、最終防衛ライ ンとしてCV数を常時監視 52

Slide 53

Slide 53 text

事業に貢献できているかどうかを監視する • CV 数が下がっていないか常に注意を払う • 大きなリリース後でもCV数が落ちていない安心感を得られる 53 Database CV 数取得 メトリクスPUT • Database から CV 数を取得して、 Datadog に連携 • デバイスごと(PC/SP/App)に CV 数を監 視・モニタリング

Slide 54

Slide 54 text

ステータスコード 監視・モニタリング • 何を:HTTP ステータスコード(301, 302, 404, 499) • どうやって:Anomaly 監視 • なぜ:Bot, 攻撃などの短期間のアクセス傾向の変化を早期検知・対 処する 54 ※ 50x は、エラー監視という位置付けでしきい値監視してます

Slide 55

Slide 55 text

監視 SaaS の機能を活用して「いつもと違う」を検知する • Datadog の Anomaly Monitor が便利 • 元々は、CTO がお試しでシュッと入れたのがはじまり • 本人も忘れた頃に Anomaly Monitor が鳴る • しきい値がよくわからない、しきい値では正しく検知できない ものは Anomaly 監視がかなり効く 55

Slide 56

Slide 56 text

WAF によるアクセスブロック監視・モニタリング • 何を:403 エラーレート • どうやって:しきい値監視、異常監視 • なぜ:脆弱性探索など不審なアクセスを検知する 56

Slide 57

Slide 57 text

ブロックされなかったアクセスは月次モニタリングで対処 • ブロックをすり抜けてきた怪しいアクセスを見つけ出す • IP や User Agent の上位層を時系列で見てあたりをつける 57

Slide 58

Slide 58 text

スロークエリ監視・モニタリング • 何を:SQL 実行時間 • どうやって:しきい値監視 • なぜ:レスポンス遅延発生時の切り分けに有効 58

Slide 59

Slide 59 text

バウンスメール監視・モニタリング • 何を:ハードバウンス • どうやって:しきい値監視 • なぜ:店舗への連絡やリカバリ対応を即時に行うため 59

Slide 60

Slide 60 text

バッチ実行監視・モニタリング • 何を:バッチ実行有無、バッチ実行結果 • どうやって:しきい値監視 • なぜ:バッチが想定通り動いていることを確認するため 60

Slide 61

Slide 61 text

処理対象ファイル数監視・モニタリング • 何を:物件ファイル数 • どうやって:しきい値監視 • なぜ:処理対象データが全量届いているかどうか確認する 61

Slide 62

Slide 62 text

開発環境の数もモニタリングしています • 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

Slide 63

Slide 63 text

AWS コスト監視・モニタリング • 何を:利用料実績, 利用料予測(Org全体、各アカウント) • どうやって:しきい値監視 • なぜ:予算超過リスク、想定外の利用を早期検知して削減策を打つ 63

Slide 64

Slide 64 text

Monitor による検知と月次のダッシュボード確認でコスト最適化 • 実績だけでなく予測も監視していることで想定外のリソース使 用を検知できる • 例:急に誰かがGPUインスタンス立てたなど • ダッシュボードを併用して、全体を俯瞰 • 重点ポイントを見極め、必要に応じてコスト最適化策実施 • 実績例1:以下のような最適化策を実施して、15% 程度コスト削減 • 不要な VPC エンドポイント削除 • ログ出力量の最適化 • 実績例2:sandbox (検証用環境) の予算をあえてゼロにする • 誰かが使用したらすぐ検知できるので、消し忘れがないよう周知可能 64

Slide 65

Slide 65 text

65 コストモニタリングダッシュボード@Datadog

Slide 66

Slide 66 text

66 各アカウントのコスト状況